2011/6/2 Dmitry Akindinov <[email protected]>: > 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.
If a proxy listening in TCP 1.1.1.1:5060 wants to contact destination 1.2.3.4:5060 and there is already an existing TCP connection between 1.2.3.4:48231 and 1.1.1.1:5060, I don't think proxy should assume that it can reuse this last connection. As I explain below, RFC 5923 explains in which cases this is possible (and current case is not listed there). > Then the proxy tries to find an active TCP connection matching the peer > and sends ACK in it. But why should the UAS allow the ACK coming from that TCP connection? Note that, for example, RFC 5923 (Connection Reuse in SIP) states that a UAC should just accept incoming request within a connection established by the UAC in case of: - Transport is TLS. - UAC announced "alias" in the first request it sent over such connection. Anyhow the scenario I ask about is totally different but I still think that RFC 3261 just allows option 2 above. This is, somewhere in RFC 3261 client transaction section there is something like "ACK for non-2XX final response must be sent to the same destination as the original INVITE. If it fails then perform procedures in RFC 3263 and so on...". Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
