Subject: RE: [rohc] SIP dialog and SigComp compartments relationship

From: "West, Mark" <[email-masked]>
Date: Thu, 25 Mar 2004 17:50:11 -0000

Hi,

The intention was that compartments relate to dialogs (rather than any longer-lived, or more tenuous concept).  This has a number of implications on storage, security models, etc.  When we last discussed this (there's a mail somewhere in the archive!) we talked in terms of the application being able to allow state to persist after the compartment has closed.  This could be advertised to the peer application such that the state is available for some [defined] time.  (But also allows the application to bound the memory usage in the case where you have a large number of registered subscribers, few of whom are doing anything).

Additional thoughts on this subject are very welcome, however!

Cheers,

Mark.

> -----Original Message-----
> From: Chintan Thakker [mailto:[email-masked]]
> Sent: 25 March 2004 17:00
> To: John Smith
> Cc: [email-masked]
> Subject: Re: [rohc] SIP dialog and SigComp compartments relationship
> 
> 
> 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:
> 
> > 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
> >
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: [email-masked]
Date: Thu, 25 Mar 2004 13:04:41 -0500

Agreed. As stated in the editor's note, the current text only serves
as a starting point. A more flexible mapping of SIP messages to 
compartment is needed. Besides combining multiple dialogs, it would
also help improve compression for SIP messages outside of a dialog.

Zhigang

> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> John Smith
> Sent: 25 March, 2004 08:21 AM
> To: [email-masked]
> Subject: [rohc] SIP dialog and SigComp compartments relationship
> 
> 
> Hi All,
> 
> "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....
> mapping between a 
> dialog ID and a compartment ID."
> 
> 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.
> 
> data and had 
> better if they would also share the same compartment, isn't it?
> 
> Thanks in advance,
> John.
>