Subject: [rohc] SIP-SigComp Questions

From: "James Ford" <[email-masked]>
Date: Mon, 24 Nov 2003 13:53:03 +0000

Hi,

I'm implementing now the SigComp feature in my SIP application and wondering 
about some undefined issues in the SigComp/SIP RFCs:

(1) Can SigComp messages be exchanged intermittently with uncompressed 
general SIP messages over the same SIP dialog (call)?

(2) Is it possible that two different Transactions in the same dialog (call) 
will use different Compartment Ids?

(3) A Quotation from the 7th section in RFC 3486 is:” 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.” What is the exact meaning of re-sending the same 
request? Should we use the same transaction for sending the uncompressed 
message or maybe we should promote the Cseq for handling the situation that 
the server-side actually received the compressed message, decompressed it 
and didn’t manage to reply yet? Moreover, should we change the ‘branch’ 
parameter (Via header) in the uncompressed message?

(4) Regarding the same quotation from the previous question, how should we 
handle the following scenario: A SIP message should be sent compressed 
(using SigComp) according to a route list (as a result of DNS request). This 
route list contains four explicit addresses but only the latter is a 
reachable address. If we’ll follow the RFC 3486 instructions, then the SIP 
message will be sent compressed, a timeout will expire,the same message will 
be re-sent uncompressed until another timeout will expire and so on. This 
process will be repeated for at least three times and might take too long, 
what can we do in order to avoid this slow mechanism?

(5) According to RFC 3261:” It is RECOMMENDED that connections be kept open 
for some implementation-defined duration after the last message was sent or 
received over that connection… This is to make it likely that transactions 
are completed over the same connection on which they are initiated (for 
example, request, response, and in the case of INVITE, ACK for non-2xx 
responses).” The standard recommends on sending all the dialog transactions 
over a single TCP connection. However, RFC 3486 says: “If a client does not 
know whether or not the server supports SigComp, but in case the server 
supported it, it would like to receive compressed responses, this client 
SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header 
field.  The request, however, as stated above, will not be compressed.” and 
then <draft-ietf-rohc-sigcomp-sip-00.txt> says in its 4th section:” 
Applications MUST NOT mix SIP messages and SigComp messages on a single TCP 
connection.  If the TCP connection is used to carry SigComp messages then 
all messages that are sent over the connection MUST have a SigComp header.”  
If we refer to both of the quotations we can conclude that the SigComp 
standards lead us to use different TCP connections in a single dialog as 
opposed to the RFC 3261 recommendation, isn’t it? How can we deal with this 
conflict?

Best Regards,
James.

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail

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

---

From: "Jan Christoffersson (LU/EAB)" <[email-masked]>
Date: Tue, 25 Nov 2003 15:33:01 +0100

Hi James

Your question number 5 is currently being debated on the ROHC list, see http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01809.html and follow-ups.

BR
Jan

> (5) According to RFC 3261:" It is RECOMMENDED that 
> connections be kept open 
> received over that connection... This is to make it likely that 
> transactions 
> responses)." The standard recommends on sending all the 
> dialog transactions 
> over a single TCP connection. However, RFC 3486 says: "If a 
> client does not 
> field.  The request, however, as stated above, will not be 
> compressed." and 
> then <draft-ietf-rohc-sigcomp-sip-00.txt> says in its 4th section:" 
> all messages that are sent over the connection MUST have a 
> SigComp header."  
> opposed to the RFC 3261 recommendation, isn't it? How can we 
> deal with this 
> conflict?
> 
> 
> Best Regards,
> James.
>

---

From: [email-masked]
Date: Thu, 27 Nov 2003 10:35:04 +0100

Hi James and others,

 Let me start with #5, the hot question:

 It is a very valid point you make here, I was about to raise this as well. If multiplexing is not allowed we'd have to open a new TCP connection every time the client is not sure whether or not the server supports compression, as the first message of the dialog must be non-SigComp. This is quite a likely case if the server's address was  discovered by external mechanisms (DNS, DHCP, email, etc.). This would effectively delay the session setup as opposed to the main goal of RFC 3320.

 Now to the other questions:

#1 
Yes, as long as the obey the rules of RFC3486. If there is comp=sigcomp in the Via: header in the initial transaction, but not in the others, SIP and SigComp messages are interspersed in the same dialog.

#2
This is not clearly defined, and depends on how do you handle compartments (e.g. is it for one dialog or longer, do you use multiple compartments, etc.). I would say a SHOULD (be in the same compartment).

#3 
In case of UDP it should be part of the SIP retransmission mechanism (e.g. first two retransmissions are compressed, third retransmission is non-SigComp). In case of TCP you may do nothing and wait for timeout, or resend the same message non-SigComp, risking multiple retransmissions if there is a general network failure. I favor the second option for the sake of robustness, although it is not really recommended by SIP. I would not advise to promote CSeq, since this cannot be done with SIP responses, only requests.

#4
I do not really see the case here, could you elaborate? Do you refer to forking functionality, or why would one send the request to four different addresses?

BR,
Robert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> James Ford
> Sent: November 24,2003 14:53
> To: [email-masked]
> Subject: [rohc] SIP-SigComp Questions
> 
> 
> Hi,
> 
> 2) Is it possible that two different Transactions in the 
> same dialog (call) 
> (3) A Quotation from the 7th section in RFC 3486 is:" If a 
> SIP client sends 
> using compression." What is the exact meaning of re-sending the same 
> and didn't manage to reply yet? Moreover, should we change 
> the 'branch' 
> reachable address. If we'll follow the RFC 3486 instructions, 
> then the SIP