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. 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.
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 am bringing this to the mailing list to see if there any solutions that has been developed for this issue. The other, bigger question is, have anybody implemented a SIP client that reliably uses TCP/TLS from behind NAT? _____________ Roman Shpount On Fri, Jun 10, 2011 at 7:52 PM, Iñaki Baz Castillo <[email protected]> wrote: > 2011/6/10 Roman Shpount <[email protected]>: > > 1. Client registers and creates two TCP flows to two different edge > proxies > > 2. Client sends an INVITE message to edge proxy 1 which responds with 100 > > Trying and forwards it through the authoritative proxy to the final > > destination > > 3. Edge proxy 1 restarts and client flow to it is closed > > Hi Roman, I don't know very well RFC 5626, but I expect it does not > cover the case you describe. In fact, your SIP UA does not need an > extra specification for the case you describe: > > After point 3 above, your UAC should realize that the TCP connection > has been closed so should terminate the transaction and, maybe, > generate a new one. > > This is, AFAIK RFC 5626 exists for helping SIP TCP clients behind NAT > rather than helping servers replying such clients after the TCP > connection has been broken (since as you say, there is no real > solution for that). > > -- > Iñaki Baz Castillo > <[email protected]> > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
