2011/6/11 Roman Shpount <[email protected]>: > 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.
That is a very good point. And now I think you are 100% correct here. But that means that when the UAC is behind NAT, sends an INVITE and later the connection is closed, there is no way for the UAC to react and a transaction timeout will occur (as the proxy/server cannot send a new response to the UAC in any other way due NAT). > 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. I expect just a few SIP proxies/servers/UAs implement thisi exotic feature. Anyhow this will never work when the UAC uses TCP behind NAT. > 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. Very interesting solution :) > The bigger question is, whether this warrant an RFC or if there is a better > solution. AFAIK there is no specification for that. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
