Subject: [rohc] sigcomp compartments

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Fri, 19 Nov 2004 08:57:51 +0100

Hi,
read in the meeting minutes about the discussions of possible compartment definitions for sigcomp. 

"Second issue is about the definition of compartments, as they need
to be well-defined to avoid accidental push-outs. The original
proposal was to use SIP dialogs, but another idea is to have three
different compartments for; registration related messages (R),
dialog-related messages (D), and subscription-related messages (S)."

I'm curious to know why this would be needed. Of course you need to know how long a compartment lasts, but why the need for different compartment types? Wouldn't a compartment that lasts throughout the users registration be sufficient?

Best regards,
Jan

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

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Nov 2004 09:51:20 +0100

> I'm curious to know why this would be needed. Of course you need to 
> know how long a compartment lasts, but why the need for different 
> compartment types? Wouldn't a compartment that lasts throughout the 
> users registration be sufficient?

For IMS, yes, this is the way it (IMS) is defined.

For SIP in the general Internet, there might not be a registration.
In general, compartments should be attached to the pieces of state kept 
by the SIP speakers.
So far, we have identified calls (generalized in SIP as dialogs), 
subscriptions, and registrations.

Note that the term "compartment" is a bit misleading: If two SIP 
speakers engage in messages that are allocated to more than one 
compartment at a decompressor, the compressor can actually make use of 
the state from all these compartments in any of the messages.  So 
allocating additional (from the point of view of IMS) compartments to 
dialogs and subscriptions just means that less state will be pushed out 
of the registration compartment defined by IMS.
In other words, a general Internet SigComp/SIP decompressor is 
interoperable (if not maximallyy efficient) with an IMS SigComp/SIP 
compressor.
A general Internet SigComp/SIP compressor will assume the existence of 
more compartments at the decompressor than defined by IMS.
With NACK (which everybody should be implementing by now) and some 
generous caching of expired state at the decompressor, this will 
probably not hurt too much (assuming that it is even sensible to think 
about a general Internet SIP speaker talking to an IMS SIP speaker).

I've been spending my copious free time the last couple of days trying 
to nail down the SIPspeak terminology for this compartment allocation 
strategy; I hope to finish that today and submit 
draft-ietf-rohc-sigcomp-sip-02.txt based on the above deliberations and 
my findings.
This will include language that allows private agreements about 
compartment allocation (as in IMS).

Gruesse, Carsten