El Viernes, 6 de Noviembre de 2009, Andrei Pelinescu-Onciul escribió:
Not at all per RFC 3261. Perhaps the hyper-complex draft-outbound states that the TCP UA must bind on the source port from which the REGISTER is sent, no idea. But for sure RFC 3261 doesn't say that.
Yes, according to 3261 the behaviour is correct. However if it doesn't support receiving requests on the same port it used to send the REGISTER or other requests it's broken in practice, since it would never work behind a NAT.
100% agree.
It's like an udp UAC that has a different port in Via and expects new requests only on that port: it's perfectly valid according to 3261, but it will never work in practice due to NATs.
Yes, UDP asymmetric SIP clients. Fortunatelly they are dissapearing :)
or add an alias parameter to its Via (assuming that the port in Via _is_ 5074). If it does add "alias" to the Via, make sure you have tcp_accept_aliases=yes in the config.
What is an "alias" parameter in the Via header?
draft-ietf-sip-connect-reuse-00 - it's a parameter added to Via whend sending a request that means the remote side can alias the connection (add an internal ip:src_port as an alias for ip:via_port). The current version of the draft seems to be dealing only with TLS though (it looks like TCP alias is now in draft-jain-sip-transport-layer-connection-reuse-00).
Ok. so using "force_tcp_alias" then SR behaves as if the request contained "alias" in Via header and tcp_accept_aliases=yes in the config. So requests to that user are sent using an existing TCP connection. Now it's clear, thanks ;)