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

From: "Surtees, Abigail" <[email-masked]>
Date: Tue, 28 Feb 2006 11:10:46 -0000

Hi All,

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!

Best regards,

Abbie

> -----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