I guess, my only issue with your argument is what is considered "connection failure" in TCP. I always assumed that this means not being able to establish a TCP connection. Connection closure after sending the request is not considered an error. TCP error while sending a request is not an error and typically requires another attempt to connect (otherwise connection reuse does not work). If connection closure is an error, then what is the point of 18.2.2:
If that connection is no longer open, the server SHOULD open a connection to the IP address in the "received" parameter, if present, using the port in the "sent-by" value, or the default port for that transport, if no port is specified. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. My solution was inserting a via parameter (I have reused the gr parameter in my case) which is set to private GRUU key for the GRUU associated with this connection. If the edge proxy no longer has the connection to the client, it checks the GRUU database if the valid flow exists, modifies the top via to match it and sends this request to another edge proxy. This is something that is not exactly standard but this seem to work and the only non-standard part is inside the proxy code I control. This helps to reduce number of call failures dues to proxy re-starts. The bigger question is, whether this warrant an RFC or if there is a better solution. _____________ Roman Shpount On Fri, Jun 10, 2011 at 8:23 PM, Iñaki Baz Castillo <[email protected]> wrote: > 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
