6 Nov
2009
6 Nov
'09
5:45 p.m.
On Nov 06, 2009 at 12:16, I?aki Baz Castillo <ibc(a)aliax.net> wrote:
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).
Please, explain it again as I don't understand what you mean with "adds
src_ip:port_in_via as an alias for src_ip:src_port".
It means that requests to twinkle_ip:twinkle_via_port will be sent on
the tcp connection from twhinkle_ip:twinkle_src_port, if the connection
is still opened.
El Viernes, 6 de Noviembre de 2009, Andrei
Pelinescu-Onciul escribi?:
> On Nov 06, 2009 at 08:12, Juha Heinanen <jh(a)tutpro.com> wrote:
[...]
So answering to this question:
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.
is this twinkle's fault, i.e., should it put
in contact uri port 59056
instead?
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. 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? or should
sr figure out that twinkle in fact is behind the tcp
connection it created when it registered itself no matter what the port
in contact uri is?
You can force that, using force_tcp_alias() (adds src_ip:port_in_via as
an alias for src_ip:src_port).
If the port in Via is not 5074 then you can work around that too, using
force_tcp_alias(5074) (based maybe on looking at the contact?), but in
this case it's better to reconfigure/fix twinkle. However I ensure that Twinkle behaviour is totally
correct when using SIP TCP
and there is nothing to fix here. In short:
- Twinkle binds on port 5060 TCP (and UDP).
- It sends a REGISTER from random port (12345). "Via" and "Contact"
contains
port 5060.
- Twinkle would accept incoming requests to both ports 5060 and 12345.
Allowing incoming request to port 12345 helps with NAT, of course, but it's
not specified in RFC 3261 at all, and Twinkle (or any UA) could refuse a
request incoming from a port different than 5060 (the port it has announced as
listening port).
If it accepts request on 12345 then it's ok.
It should consider "advertising" it by adding alias to Via though (it's
just ;alias somewhere in the via params).
An example of Twinkle TCP REGISTER:
T 2009/11/06 12:13:26.472917 192.168.1.10:38609 -> XX.XX.XX.XX:5062
REGISTER sip:mydomain.net SIP/2.0
Via: SIP/2.0/TCP 192.168.1.10:6060;rport;branch=z9hG4bKsswrheos
Contact: <sip:ibc_aliax_net@192.168.1.10:6060;transport=tcp>;expires=600
Andrei
In general, especially if you have NATed UACs,
it's better to always have
force_tcp_alias() in the config. It will cause problems only if you have
non-NATed broken UACs that don't expect/support symmetric signalling
over TCP (e.g. open a new connection for each new request and expect
only replies to that request on the connection).
Symmetric signalling is about using the same src_ip:src_port - dst_ip:dst_port
within a transaction, which involves requests and its replies. It's not about
different transactions in both ways. For that there is a draft/RFC about TCP
reuse and so, but it requires a "Via" parameter and some stuff...
RFC 3261 doesn't state that a UA should accept incoming requests to a port
different than the binding port.
OTOH if you don't force_tcp_alias() and the
UACs don't add alias to the
Via, it's a very slim chance that NATed UACs will work over tcp.
I again ask what "add alias to the Via" means :)