Why the NAT becomes an ISSUE for VOIP phone with SIP Protocol and why we need NAT traversal through expressway.
Phone-A—–NAT-DEVICE—Internet—Phone-B
Phone-A private IP 10.1.1.10
Phone-B Public IP 64.12.30.10
For Outbound Calls, NAT Device translates the private IP address 10.1.1.10 to 64.12.31.1
Scenario without STUN protocol.
Phone-A tries to establish a call to Phone-B.
Phone-A sends a SIP Invite message; in the Invite message, Phone-A puts the Private IP address 10.1.1.10 and port 8214 in the Contact field as shown below:
Contact: : <sip:1001@10.1.1.10:8214….>
Therefore Phone-A is requesting the Phone-B to try to establish a connection by sending SIP messages back to IP address 10.1.1.10 and port 8214.
The Phone-B will try to establish the connection but since this is a private IP address, it is not routable on the internet and therefore the response is dropped by the ISP. Since packets are dropped, the connection cannot be established.
Scenario with STUN protocol.
Phone-A sends a STUN resolution request to the STUN server which can be the Expressway-E. The purpose of the STUN protocol is to allow the Phone-A behind the NAT-Device to discover its public IP 64.12.31.1 and the port translation 5410.
In the “Contact” field in the SIP Invite message the Phone-A replaces its own IP address (10.1.1.10) with the external IP address (64.12.31.1) and external Port (5410) discovered by making a STUN resolution before sending the SIP Invite message as shown below;
Contact: <sip:1001@64.12.31.1:5410….>
Now the Phone-B can establish a connection with the Phone-A by sending SIP responses to IP address 64.12.31.1 on port 5410 which is the mapped to IP address 10.1.1.10 and port 8214 on the NAT-Device.
Demystify and Simplify 