Subject: [rohc] SIP-SigComp Questions

From: "James Ford" <[email-masked]>
Date: Tue, 25 Nov 2003 09:08:14 +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) 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?

(2) 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?

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

_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE* 
http://join.msn.com/?page=features/junkmail

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