Problem - When making a VoIP call [especially using SIP], you can dial the phone number, but once you answer the call, there is a voice or only one way.
Reason - I am sure that no matter what protocol you will use to solve your VoIP solution, I will have the same reason. So this is definitely a problem with SIP, but I have not confirmed it with other protocols.
The problem occurs because VoIP uses a dynamic UDP port for each call. This can cause problems when traversing the NAT device for two reasons; the NAT device changes the source port of the outbound packet during the NAT process. The second is because UDP is essentially designed for one-way traffic [broadcast, video streaming, etc.]. If TCP traffic is bidirectional on a connection, UDP can have one inbound connection and the other for outbound, which means they can use different ports. If the inbound connection uses a different port as the outbound connection, the inbound traffic is dropped because the NAT device does not have a mapping in its NAT table. If you are confused now, I suggest you read NAT first.
What is SIP, why it is important for VoIP Just as TCP/IP itself is not a protocol, but a series of protocols such as TCP, IP, PPP, PPTP, ARP, etc., so it is VoIP. There are several protocols that can be used with VoIP, each with its own pros and cons. We will focus on SIP in this article. SIP stands for Session Initiation Protocol. It is responsible for setting up calls, ringing, signaling, meshing, etc.
In most SIP environments, multiple VoIP calls will be used simultaneously. Each of these calls will be managed through a VoIP switch, each requiring its own voice channel. Each channel [or another way to view the phone] must use a unique port. If you are using 100 concurrent VoIP calls, you must have 100 ports available for the VoIP switch to assign to each call. This is where SIP comes in. It basically controls everything you need to set up a call. For each call, SIP will find an alternate port, assign it, send these details to all parties, set up the call and ring the phone. Once the call is over, the SIP terminates the session and informs the telephone switch that the port can be reassigned to another call.
The port range is usually configurable, for example, Avaya allows you to configure it in the VoIP portion of the system configuration. The default range for Avaya VoIP is 49152 to 53246. This gives us the possibility of 4,094 concurrent VoIP call permissions.
In a LAN environment, this is not a problem because the firewall typically allows all traffic on all ports of all devices. Once the Internet is involved, traffic must pass through NAT and firewall, and we run into problems. In the Avaya example above, it can select any port in the range of 49152 to 53246. You cannot just open this port range to the Internet. The open 4000 port range is not very secure.
How SIP works on the Internet Like all network traffic, an endpoint must first initiate a connection. This means that at least one port must be opened using port forwarding to the VoIP switch. SIP typically runs on port 5060. In order for two offices to call each other, both sites must forward this port to the telephone switch. When you read the documentation about SIP, most people will say that this is all you need to do... but it is likely that this is not the case.
The following happens when you dial a VoIP number:
- You dial the number and the local VoIP switch matches it to the site ID, which is used to find the public IP address of the remote location.
- Your local VoIP will use SIP to connect to the remote IP on port 5060 [this is why the port must be open].
- The two telephone exchanges now negotiate and set up the phone. A few things were done during the negotiation process, but the most important thing [for this article] is the port they will use to transport UDP voice streams.
The problem here is that SIP doesn't know that it is behind NAT. Suppose your local switch IP is 192.168.1.1 and the remote IP is 192.168.2.1. Although NAT modifies a SIP packet to a public IP while traversing the Internet, it does not change the actual data in the SIP packet itself [payload]. The payload contains information about the port and IP address used for the actual phone call. Local VoIP tells remote VoIP [via SIP] to send voice data to its local IP 192.168.1.1 and vice versa. As we all know, this situation will never work as Internet routers drop packets from private IP addresses. Once the call is established and the UDP voice data actually begins to be sent, it will be sent to the private IP and thus discarded. So how do we solve this problem?
STUN Stun stands for NAT's Session Traversal Utilities, and you may have guessed its name, a set of utilities that help traverse NAT devices.
STUN [in our case] helps the program or device know if it is behind a NAT and modifies the package accordingly. It requires the help of a third-party server on the Internet, called the STUN server. This means that our VoIP phone can modify its SIP content to include public IP instead of private IP. Some people may think that the same problem will affect the port.
It is also common for NAT to change the source port of an outbound packet to a new randomly generated packet. When the remote device responds, it responds to this new random port. When a packet re-enters this port, NAT allows it to pass because it maps this port to the internal client. You may have guessed that this is also a problem with SIP. The STUN server also takes this into account. The STUN client [VoIP switch] sends UDP packets outbound on the port it wishes to use for VoIP calls to the STUN server. This will be NATTED to public IP and a new port number. The STUN server sends back this information, preventing the VoIP switch from learning its public IP and mapping [modifying] the external port of voice traffic. Now we have all the information we need to modify the SIP data and use the correct information to traverse the NAT. The local switch now connects to the remote switch via SIP and tells it to send UDP voice calls to its public IP and public ports. Once this data is returned, the NAT maps it in the NAT table and sends it to the internal VoIP switch. This I think how it should work... I was trapped in this time...
The reason I was stuck was not because of a lack of understanding of technology [honesty], but because I set up a stupid document for SIP [from Avaya] and my confidence in it was correct. I checked all the content again and found that I had done all the operations correctly and then it hit me... I want to "wait, when the UDP voice packet starts to enter the ON A RANDOM port, when the only port forwards I , it is how the SIP through the NAT device is "5060"
I deliberately misled you to see if you can find it yourself. I said there is a mapping of incoming UDP traffic in the NAT table, but not. You and I may have assumed this because you don't need to port any other ports. If traffic is requested from an outbound connection for the first time, traffic can pass through the NAT without port forwarding to enter your network. The outbound connection adds an entry in the NAT table to the incoming packet on this port to the internal client. This adds to my confusion. The documentation clearly states that you only need to migrate 5060 forward but the voice call uses a random UDP port, so how do you pass NAT? If you are still confused, it will be because you don't understand [or have forgotten] a fundamental difference between UDP and TCP, which is very important to us.
TCP requires an endpoint to first establish a connection in order to send back data. We know that you have inbound and outbound connections. If I am setting up an outbound connection, then it is the inbound connection on the other end. Inbound connections require port forwarding, which we did not set in this scenario. In addition, a socket must be created for the data to be sent back. This is very important because it is not a requirement for UDP. UDP is connectionless memory [see the differences between TCP and UDP for details]. It can send data without knowing the remote location. It is this key difference between TCP and UDP that allows you to traverse NAT using UDP without port forwarding. This technique is called UDP puncturing.
UDP punching lets us add all the technology so far to get a viable solution. Two VoIP switches learn public IPs and ports from each other through the STUN server. They then use SIP to send this information to the other party on port 5060, and then they use UDP punching to transmit VoIP packets.
UDP punching is a clever technique. It creates a NAT map by "punching" the NAT device. Local VoIP sends UDP packets to the remote VoIP to the port and it is told the public IP to use from the SIP data. When this data arrives at the NAT device at the remote location, it will not be able to transmit because there is no port forwarding and no outbound data is requested. The exact same process from remote VoIP to local VoIP is lost. This purpose is not to send packets, but it is "puncturing" through NAT and creating external ports and IP mapping to Internet ports and IP, especially allowing incoming traffic on this port. Since this happens at both ends, we now connect the NAT mapping of these ports to the internal client. Because these mappings now exist, the NAT device treats these mappings as outbound...
Orignal From: Fix one-way VoIP audio (SIP, NAT and STUN)
No comments:
Post a Comment