Subject: RE: [rohc] Questions about SigComp over SIP

From: [email-masked]
Date: Mon, 10 Nov 2003 11:42:30 -0500

Hi John,

Just to be accurate, the email subject would be better to read
"SIP over SigComp".

Please see comments in line.

BR,
Zhigang

> 1.	Quoting from RFC3486 (Compressing the Session 
> Initiation Protocol): "The 
> presence of this parameter (comp=sigcomp) in a URI indicates that the 
> request has to be compressed using SigComp, as defined in 
> [2]" (section no. 
> 2).
> Then, below in section no.7 it continues with: "If a SIP 
> client sends a 
> compressed request and the client transaction times out 
> without having 
> received any response, the client SHOULD retry the same 
> request without 
> using compression."  This quotation instructs us to send the 
> same message 
> without specifying the following details:
> ·	Is the parameter 'comp=sigcomp' has to be removed from 
> the original 
> request URI before re-sending the uncompressed SIP request message?

My understanding of RFC3486 (if correct) is that it's not needed.
The parameter "comp=sigcomp" is mainly to indicate the *receiver's* 
support of SigComp, not a mandate for a sender to send it. See quoted
text from section 2 below. (I agree the "hast to" wording mentioned above
is confusing. I don't know how it ended up there.)

   Therefore, the presence of comp=sigcomp indicates that the SIP entity
   identified by the URI or by the Via header field supports SigComp and
   is willing to receive compressed messages.  Having comp=sigcomp mean
   "willingness" as well as "support" allows the receiver of a SIP
   message to influence the decision of whether or not to use SigComp at
   a given time.

> ·	In case that a SIP message has to be re-sent 
> uncompressed, should it 
> contain different Via branch value (as it is done after transmission 
> failure, when using DNS) or different CSeq?

The values should be set according to SIP, regardless whether or not
SigComp is used. SigComp is just a transport.

> 2.	Is there any example of SigComp state that is created 
> dynamically and is 
> used by more than a single compartment? I'm looking for an 
> example of state 
> that is not 'global' or created during initialization process 
> (such as state 
> that keeps the dictionary or state that keeps 
> compression/decompression 
> algorithm).

I don't have one from the top of my head. 
 
> 3.	Do the compression/decompression algorithms instruct us 
> which states and 
> how many of them have to be created in order to support the 
> SigComp feature? 
> or Does the states creation depend on the way that SigComp is 
> implemented?

Those depend on the compressor (sender). SigComp essentially 
specifies the expected behaviour/constraints of the decompressor
(receiver). It's up to the compressor implementation on how
to use the SigComp framework and drive the operations.
Think about Java VM and applet. 

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

---

From: "West, Mark" <[email-masked]>
Date: Mon, 10 Nov 2003 16:58:53 +0000 (GMT Standard Time)

Hi John, Zhigang,

A very small additional comment to one of Zhigang's answers...

> I don't have one from the top of my head.

Well, isn't the bytecode an example of this?

It depends what you mean by 'initialisation', but the bytecode is not
'universal'.  Whereas, the 'static dictionary' is, I would imagine, always
present -- it's hard to imagine the dictionary (for example) being *sent*
by an endpoint... (I can only really see it being use if its presence is
advertised / mandated for the particular environment).

In any case, it's not really clear why it's important to have an
example... it can happen and is explicitly supported in the definition of
state management in RFC 3320.  So an implementation has to handle it, even
if you don't think that it's going to occur very often...

Cheers,

Mark.