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.
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
