Subject: Re: [rohc] SigComp Implementer's guide - SIP question

From: Pekka Pessi <[email-masked]>
Date: Tue, 14 Mar 2006 19:44:38 +0200

"Surtees, Abigail" <[email-masked]> writes:
>As discussed below, I believe there is potential for messages to be
>re-ordered, particularly if they are sent over different transports.

>I've been reading 3261 to look further into this and can't find the
>answer to my question, so am hoping that someone here will know.

>When you send a BYE (or any other request within a dialog), is there any
>restriction on the transport that is to be used?  In particular, does it
>have to be the same as for previous transactions within the dialog?  If
>not, then re-ordering is possible even within a dialog!

No, there is no restrictions. 

A dialog endpoint can force certain transport towars it by
including uri-parameter "transport" in the Contact or Record-Route
header.

--Pekka

>> -----Original Message-----
>> From: Surtees, Abigail [mailto:[email-masked]] 
>> Sent: Thursday, February 23, 2006 11:01 AM
>> To: Cristian CONSTANTIN
>> Cc: [email-masked]
>> Subject: RE: [rohc] Implementer's guide - it's that time again

>> Hi Cristian,

>> > cristian: hi! do you want to suggest here that the _same_ 
>> compartment
>> > from a certain peer should be able to receive messages _at the same_
>> > time on both tcp and udp (or any other transport protocol)?? 

>> Yes, I'm afraid that's exactly what I mean :-S

>> There are two points to make here:

>> 1) It's relatively unlikely, but it is theoretically possible to get
>> packets being out of order when they're sent over UDP only.  

>> 2) It depends on the compartment definition, however, if the same
>> compartment can be used for multiple dialogs (e.g. a compartment that
>> lasts for the duration of a registration) then it is pretty simple to
>> see that you could get re-ordering happening.

>> E.g.

>> --------------> INVITE sent over TCP due to size, takes a long time to
>> arrive

>> In the mean-time:

>> <------------- Smaller INVITE sent over UDP
>> --------------> Response to INVITE (e.g. 486 Busy Here or 180 Trying)
>> could arrive before the INVITE sent over TCP.

>> This is why I think that the implementer's guide should contain a
>> statement along the lines of 'this could happen and it's up to the
>> compressor to take account of it'.

>> > can a
>> > compartment in a peer communicate to more than 1 
>> compartment in other
>> > peers?

>> I'm not quite sure what you mean here.  Does the following answer your
>> question?

>> It is possible for an message sent from one compartment to refer to
>> state that has been created in another compartment but the sending
>> compressor must know that that state is there.  

>> There is a 1-1 mapping between compartments in peer endpoints (which
>> both ends must agree) and a message sent from one compartment can only
>> create/free state in its corresponding compartment.

>> Compartment definition depends on the application using SigComp.

>> 3GPP TS24.229 specifies that a compartment exists for the 
>> duration of a
>> SIP registration.

>> The IETF does not currently specify a compartment mapping for SigComp
>> for SIP, however, the 'Applying SigComp to SIP' draft is 
>> addressing this
>> issue and discusses having several compartments per endpoint (see
>> http://users.piuha.net/gonzalo/temp/draft-ietf-rohc-sigcomp-si
>> p-02.txt).

>> Note that this draft has been submitted and announced but for some
>> reason the IETF link doesn't work (I have reported it).

>> > could you please provide an example of a (SIP) 
>> > configuration/scenario when
>> > something like this happens?...

>> See above.

>> Best regards,

>> Abbie

>> > thanks.
>> > bye now!
>> > cristian
>> > -- 
>> >  _          | There are many people who use UNIX or Linux  
>> > (_'_        | who IMHO do not understand UNIX.
>> >   (_'rist   |              --David Korn  
>> > GPG public key at wwwkeys.de.pgp.net

>> _______________________________________________
>> Rohc mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/rohc

>_______________________________________________
>Rohc mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc