2011/6/11 Roman Shpount <[email protected]>: > Well, I do not think you are correct. First of all, if UA receives a > response over the second flow, it should process it properly based on the > basic SIP specs.
I never contradicted that. > There is nothing in SIP specifications that implies that > SIP transaction is associated with a particular TCP connection and should be > terminated or retried if the connection is closed. It would normally time > out but this is not something which is desired. I don't think so. RFC 3261 clearly says that if a TCP connection is closed while a client transaction was pending, the client transaction must generate a local 503 and pass it to the TU/core layer. The TU/core would then decide wheter to create a new transaction (i.e. based on DNS failover as RFC 3263 states). 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. The same for proxies: 16.9 Handling Transport Errors If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response. > RFC 5626 exists as a proposed solution for SIP connectivity for clients > located behind NAT. It covers both server and client behavior, including > request rerouting in case of flow failure. It does not cover the recovery > mechanism for flow failure while sending a SIP response. The general SIP > specification clearly does not work there since it directs to open a TCP > connection to sent-by address and port from the VIA, which will fail in case > of NAT. AFAIK there is nothing in any of the SIP standards that describes on > how one should deals with this situation. I fully agree. And honestly, I don't expect there is any solution for that. It doesn't matter whether the client had two connection (RFC 5626), as there is no way to server-1 to ask server-2 "please, send you this response to the UAC as my connection with him has been terminated". > The other, bigger question is, have anybody implemented a SIP client that > reliably uses TCP/TLS from behind NAT? I've never seen yet a SIP client implementing RFC 5626. However, the best SIP TCP/TLS clients I've tested inmediately open a new TCP connection if the existing connection is terminated, and also register again using the new TCP connection. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
