6 Nov
2009
6 Nov
'09
6:05 p.m.
El Viernes, 6 de Noviembre de 2009, Andrei Pelinescu-Onciul escribió:
100% agree.
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 ;)
--
Iñaki Baz Castillo <ibc(a)aliax.net>
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. 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?