[sr-dev] why new tcp connection?

[Andrei Pelinescu-Onciul]

On Nov 06, 2009 at 12:16, I?aki Baz Castillo <ibc at aliax.net> wrote:
> El Viernes, 6 de Noviembre de 2009, Andrei Pelinescu-Onciul escribi?:
> > On Nov 06, 2009 at 08:12, Juha Heinanen <jh at tutpro.com> wrote:

[...]
> 
> So answering to this question:
> 
> > 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.

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.

> 
> 
> 
> > 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).

> 
>  
> > > 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.
> 
> 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.

> 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 at 192.168.1.10:6060;transport=tcp>;expires=600  
> 
> 
>  
> > 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 :)
> 

Andrei