Subject: [Sip] SIP and NAT

From: "Ashhar Farhan" <[email-masked]>
Date: 26 Dec 2001 13:33:03 -0000

SIP and NAT

i have worked on an independent small footprint telephony protocol that works through the NAT and SOCKS 5 proxies. this is called the Lightweight Telephony Protocol. As this is SIP list and not LTP, i will not talk much about it. However, our last 2 years of experience in evolving the LTP tells us the following:

1. It is not enough that just SIP makes it through the NAT. Even the RTP packets have to make it through. Otherwise, SIP is useless for all practical telephony purpose (although messaging will still work).

2. While traversing either the NAT or the SOCKS 5 (UDP), the public Internet facing port is unknown by the user agent (on the intranet).

3. Therefore, there is no way to indicate the RTP's UDP port to the server.

4. The only way to implicitly signal the UDP port is by making the RTP/UDP and SIP/UDP ports the same. And signal this somehow in the SDP so that it means 'this very port used by the SIP'. this is sort of in-band signalling. The SIP and RTP packets are easily demultiplexed by looking at the first byte of the UDP packet.

5. there are three possible traversal behaviours with this scheme.

5.1 Client is NATted, server is not: in this case, the client will only be able to call the server if the INVITE arrives directly or after a redirect. The server will not be able to handle a proxy request because the port opened for the association between the proxy server and the client will not respond to the server->client UDP.

5.2: Server is NATted, client is not: in this case, the client will onlly be able to call the server if the request is proxied. This is because the port association would have been opened by the REGISTER message sent from the server to the proxy server (assuming that proxy and location servers are colocated and share the same port). In such a case, although the INVITE will be proxied, the response should be directly sent from the server to the client so that the port association is established at the server NAT between the client and the server.

5.
roxy for the RTP as well as SIP is required at a public IP address. There is no way to really talk from NAT to NAT.

6. it should be noted that most of the current long distance telephony operators are faced with 5.2 (client behind NAT) situation which this scheme solves.

the above behaviour assumes that we are using the regular NAT as opposed to making specific changes to the NAT implementation. The simplest change to NAT is that you should rewrite the SIP messages (just like NAT rewrites ftp port commands) to reflect the NAT ports.

- Ashhar Farhan
[email-masked] (remove 123 from the email-id) 

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 26 Dec 2001 17:00:10 -0500

You might actually try reading some of the work on traversing sip 
through non-ALG and non-midcom aware nats, before proposing solutions 
that break things in countless ways. You might be surpised to find that 
people have actually been working on it.

http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-nat-scenarios-00.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-stun-00.txt
http://www.ietf.org/internet-drafts/draft-rosenberg-midcom-turn-00.txt
http://search.ietf.org/internet-drafts/draft-davies-fw-nat-traversal-01.txt
http://search.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-00.txt

-Jonathan R.

Ashhar Farhan wrote:

> SIP and NAT
> 
> i have worked on an independent small footprint telephony protocol that
> works through the NAT and SOCKS 5 proxies. this is called the
> Lightweight Telephony Protocol. As this is SIP list and not LTP, i will
> not talk much about it. However, our last 2 years of experience in
> evolving the LTP tells us the following:
> 
> 1. It is not enough that just SIP makes it through the NAT. Even the RTP
> packets have to make it through. Otherwise, SIP is useless for all
> practical telephony purpose (although messaging will still work).
> 
> 2. While traversing either the NAT or the SOCKS 5 (UDP), the public
> Internet facing port is unknown by the user agent (on the intranet).
> 
> 4. The only way to implicitly signal the UDP port is by making the
> RTP/UDP and SIP/UDP ports the same. And signal this somehow in the SDP
> so that it means 'this very port used by the SIP'. this is sort of
> in-band signalling. The SIP and RTP packets are easily demultiplexed by
> looking at the first byte of the UDP packet.
> 
> 5.1 Client is NATted, server is not: in this case, the client will only
> be able to call the server if the INVITE arrives directly or after a
> redirect. The server will not be able to handle a proxy request because
> the port opened for the association between the proxy server and the
> client will not respond to the server->client UDP.
> 
> 5.2: Server is NATted, client is not: in this case, the client will
> onlly be able to call the server if the request is proxied. This is
> because the port association would have been opened by the REGISTER
> message sent from the server to the proxy server (assuming that proxy
> and location servers are colocated and share the same port). In such a
> case, although the INVITE will be proxied, the response should be
> directly sent from the server to the client so that the port association
> is established at the server NAT between the client and the server.
> 
> 5.
> roxy for the RTP as well as SIP is required at a public IP address.
> There is no way to really talk from NAT to NAT.
> 
> 6. it should be noted that most of the current long distance telephony
> operators are faced with 5.2 (client behind NAT) situation which this
> scheme solves.
> 
> the above behaviour assumes that we are using the regular NAT as opposed
> to making specific changes to the NAT implementation. The simplest
> change to NAT is that you should rewrite the SIP messages (just like NAT
> rewrites ftp port commands) to reflect the NAT ports.
> 
> 
> - Ashhar Farhan

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com