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

From: [email-masked]
Date: Thu, 25 Mar 2004 13:29:40 -0500

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

It will "physically" delete a state, if it is the only compartment
in which the state is created. SigComp allows a state to be created
multiple times in different compartment. So, an implementation
would maintain a reference count and perform the actual deletion when
the count decremented down to zero.

However, see the comments from Mark about extending the lifetime of
a state beyond that of a compartment. Being "compartment-less", the
same sate can be used to compress messages from different dialogs.

> Additionally is it useful to have a different 
> compression algorithm for every dialog that is established ? 

The sender can choose whichever algorithm for a dialog, or even for 
a message, as long as the decompression bytecode is made available
to the remote receiver. So, it's more related to state than compartment.

> (3320 talks about the compression algorithm being a characteristic of the 
> compartment).

I have to double check the text in RFC 3320. But I think it is not the
intention to limit an implementation.

BR,
Zhigang

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

---

From: "West, Mark" <[email-masked]>
Date: Thu, 25 Mar 2004 23:53:52 +0000 (GMT)

Hi all,

Some more comments...

> to the remote receiver. So, it's more related to state than compartment.

Absolutely -- this is the heart of the sigcomp world-view: only the
decompressor is defined; the compressor can do whatever it likes, so long
as it fits.  And the granularity of data-access is state.

Algorithms are expressed (within sigcomp) as bytecode.  Depending upon the
application (SIP), you could use different bytecode for each dialog, or
keep it the same.  Hopefully your compressor makes the choice as best it
can to achieve the best overall efficiency...

> intention to limit an implementation.

It is absolutely not the intention to limit an implemention (other than by
the rules for decompression/UDVM).  A compartment may have one or more
compression algorithms associated with it [== state-items containing
bytecode].  How this is managed, of course, is a non-trivial
implementation issue.  But there is nothing in 3320 that stops you having
an arbitrary number of compression algorithms stored at the decompressor
and choosing between these (or even uploading a new one) as the compressor
sees fit...

Cheers,

Mark.