Subject: [rohc] Implementer's guide - it's that time again

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 2 Feb 2006 11:54:07 -0000

Hi All,

The implementer's guide expired in January so it's time to update it
again.  There's one comment outstanding about clarifying section 3.2
MULTILOAD
(http://www1.ietf.org/mail-archive/web/rohc/current/msg03949.html).

Are there any other issues that should be clarified in the implementer's
guide?  If so, please raise them on the list by Friday Feb 10th.

Best regards,

Abbie

Abbie Surtees
Senior Engineer
Roke Manor Research Ltd
Old Salisbury Lane
Romsey, SO51 0ZN
Tel:   +44 (0) 1794 833131

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

---

From: "Surtees, Abigail" <[email-masked]>
Date: Thu, 23 Feb 2006 11:01:25 -0000

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