RFC 3261 section 18.2.2 appears to me to completely forget about stateless proxies for routing responses over TCP/TLS and, in fact, I don't see how it can work. Clearly this is solved in the field, though, so I'm hoping someone can elucidate this for me.
The RFC states the following: "If the "sent-protocol" is a reliable transport protocol such as TCP or SCTP, or TLS over those, the response MUST be sent using the existing connection to the source of the original request that created the transaction, if that connection is still open. This requires the server transport to maintain an association between server transactions and transport connections." This makes sense, but only for stateful proxies that actually have transactions. Without transactions, how can the server possibly look up the existing connection? With the Via header, all you have is the IP address and the remote *listening port*, as specified in the section 18 intro where it states: "When the connection is accepted by the transport layer, this index is set to the source IP address, port number, and transport." So, the connection is indexed according to the remote port (from the server's perspective), but the Via header has the listening port, leaving no way to look up the connection for routing the response. What gives? The only solution I can see is actually storing some state using the branch ID at the transport layer of the stateless proxy, but this is not specified anywhere. In fact, how to look up the transport connection for a stateless proxy for reliable transports is not specified anywhere as far as I can tell, as the only explanation involves the use of transactions. Thanks very much. -Adam _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
