Subject: [rohc] SIP dialog and SigComp compartments relationship

From: "John Smith" <[email-masked]>
Date: Thu, 25 Mar 2004 14:21:09 +0000

Hi All,

A quotation from draft-ietf-rohc-sigcomp-sip-01.txt section 3:
"When SigComp is applied to SIP, there is a one-to-one relationship between 
a SIP dialog (see section 12 of [RFC-3261]) and a pair of peer SigComp 
compartments....
The only requirement is to maintain a local one-to-one mapping between a 
dialog ID and a compartment ID."

This kind of limitation might cause inefficiency. For exmaple, in case of 
UAC, which is configured to send all its' requests to an outbound proxy. 
Instead of using single compartment, that stores common data (all the 
outgoing requests share the same destination), each established dialog will 
trigger new compartment. It seems to be wasteful.

Generally, there might be several dialogs that share common data and had 
better if they would also share the same compartment, isn't it?

Thanks in advance,
John.

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

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

---

From: Chintan Thakker <[email-masked]>
Date: Thu, 25 Mar 2004 11:00:21 -0600

Is it that when we are done with a compartment, it frees up 
corresponding state at the State Handler (or just decreases the 
reference count). Additionally is it useful to have a different 
compression algorithm for every dialog that is established ? (3320 talks 
about the compression algorithm being a characteristic of the compartment).

Thanks,

John Smith wrote:

> "When SigComp is applied to SIP, there is a one-to-one relationship 
> between a SIP dialog (see section 12 of [RFC-3261]) and a pair of peer 
> SigComp compartments....
> The only requirement is to maintain a local one-to-one mapping between 
> a dialog ID and a compartment ID."
>
> This kind of limitation might cause inefficiency. For exmaple, in case 
> of UAC, which is configured to send all its' requests to an outbound 
> proxy. Instead of using single compartment, that stores common data 
> (all the outgoing requests share the same destination), each 
> established dialog will trigger new compartment. It seems to be wasteful.
>
> Generally, there might be several dialogs that share common data and 
> had better if they would also share the same compartment, isn't it?
>
> Thanks in advance,
> John.
>