Subject: [Sip] Questions about SigComp over SIP

From: "John Smith" <[email-masked]>
Date: Thu, 06 Nov 2003 15:13:31 +0000

Hi,

I would like to develop SigComp over SIP, and find some issues unclear:

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?
·	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?

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

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?

I would appreciate answers to any of my questions.

Thank You,
John.

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip