Hello, On 2011-06-02 13:04, Iñaki Baz Castillo wrote: > Hi, let's suppose that a proxy (with public IP) relays an INVITE via > TCP to the UAS. Later the UAS replies 480 but it does it by opening a > new connection to the Via sentby of the INVITE (maybe because the TCP > connection has been broken). > > RFC 3261 allows it, but my question is: where should the proxy send > the ACK? should it use the same TCP connection used for the INVITE > (which is down now)? or could it send it using the new TCP connection > the UAS has opened to send the 480? > > So there are three options (AFAIK): > > 1) Send the ACK using the already broken connection used for the > INVITE (which obviously would fail). > 2) Same as 1 but opening a new connection with the UAS. > 3) Send the ACK using the connection created by the UAS to the proxy > when it sent the 480. > > I expect 2) is the way to go, but perhaps I miss something.
2) should work but 3) looks more effective. A proxy can maintain a list of TCP connections (both incoming and outgoing) sorted by their peer ID (IP:port for example). A response coming from a fresh TCP connection is a clear indication that the original TCP stream is not used any more by UAS, so 1) is most likely to fail and should not be tried. That original TCP connection should be disposed of and the new (the one where the response is received) added to the list. Then the proxy tries to find an active TCP connection matching the peer and sends ACK in it. A failure to find such a connection or send in the found connection (already closed by the other side?) would lead to 2) as the fallback scenario - opening a new connection and sending within it. The tricky part here is to compose that peer ID for incoming TCP connections created for a response. If the transaction object is lost at the proxy you can't really create a proper outgoing connection - that's just one more vote for reusing the connection for the ACK. If you have the transaction object (which may keep references to outgoing TCP connections it creates) you can try to find it using the topmost Via in the response. > Thanks a lot. > -- Best regards, Dmitry Akindinov. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
