[Users] TCP-alias and NAT - one more try to get an answer

Alexander Ph. Lintenhofer lintenhofer at aon.at
Wed Oct 26 11:51:21 CEST 2005


Hi All,

I just wanted to ask you once again about the TCP-alias riddle. I found out, that there is a problem with the combination of fix_nated_contact(), force_tcp_alias() and NAT:

Imagine following situation:

Alice behind NAT: socket 172.16.0.6:2421
Nat-Box translates this to 192.168.0.13:6007

The Outbound-Proxy of Alice is 192.168.0.1

Bob is registered with 192.168.1.1

1.)
Her INVITE:
====================================================================
INVITE sip:bob at 192.168.1.1:2331;transport=tcp;line=wxqurd1s SIP/2.0
[...]
Via: SIP/2.0/TCP 172.16.0.6:2421;received=192.168.0.13;
                branch=z9hG4bK-wm9jcstcboys;rport=6007
From: "Alice" <sip:alice at atlanta.com>;tag=sufzmxi0us
To: "Bob" <sip:bob at biloxi.com>;tag=c9550czwtn
[...]
Contact: <sip:alice at 172.16.0.6:2421;transport=tcp;line=fyyuh6tl>
[...]
====================================================================

2.)
fix_nated_contact() doesn't work with TCP (look at nathelper.c).
force_tcp_alias() now creates following tuple as TCP-alias: 192.168.0.13:6007 to 192.168.0.13:2421

Reason:
The TCP-alias is not built solely from the Via-header as suggested in the draft. The portnumber is taken from the Via-header and the IP-address is taken from the source of the incoming datagram. I read it in the sourcecode and assured it by contacting Andrei!

3.)
So as a result of the notfixed Contact-header of Alice's INVITE the BYE of Bob is addressed to 172.16.0.6:2421. But no TCP-alias exists for this socket :-(

4.)
I made following test by rewriting the Contact-header....
====================================================================
if (method=="INVITE")
{
   replace("Contact: <sip:alice at 172.16.0.6:2421;transport=tcp;",
           "Contact: <sip:alice at 192.168.0.13:2421;transport=tcp;");
}
====================================================================
...with success. Now TCP-alias works as you can see on my Ethereal-trace below!
Compare the destination port of the packet to the destination port of the RURI!
====================================================================
[...]
Transmission Control Protocol, Src Port: 5060 (5060), Dst Port: 6007 (6007), ...
Session Initiation Protocol
Request-Line: BYE sip:alice at 192.168.0.13:2421;transport=tcp;line=fyyuh6tl SIP/2.0
Message Header
 [...]
 From: "Bob" <sip:bob at biloxi.com>;tag=kcsveifugd
 To: "Alice" <sip:alice at atlanta.com>;tag=ricaq5cy15
 Contact: <sip:bob at 192.168.1.1:2331;transport=tcp;line=wxqurd1s>
 [...]
====================================================================

Another solution:
Comment the lines in nathelper.c which force the return in case of TCP or TLS. Now all works well!

But why??????????????

regards,
Philipp







More information about the Users mailing list