7/14/2023 0 Comments Nat not detected onsipExample deployment using the Edgemarc devices will be a topic of later blog posts. At N2Net, we rely on the Edgewater Networks Edgemarc device to deal with NAT issues in complex client infrastructures. Some SIP ALG’s can be problematic, but with the right tweaking, can be made to do exactly what you want. These devices are able to rewrite SIP packets with the correct IP address information as the traffic flows through them. This feature of a firewall / router is commonly referred to as a SIP ALG (Application Layer Gateway). The phone system will actually replace all the instances of local (private) address with the public address of the NAT device before sending the packet to the NAT device to be forwarded on to the VoIP Providers network.Īnother option used to address SIP/NAT issues is to implement what is called a SIP aware firewall/router. Most have a provision which lets them know they are behind a NAT device. The provider’s VoIP equipment cannot route the private 192.168.1.179 address across the internet which means this call, if left as is, will result in ‘no audio’ or ‘one way audio.’ This is a common complaint when NAT is causing problems on a VoIP network. That’s telling the provider’s VoIP equipment where to send the audio for this call, which is problematic. Take a look at the second from the last underlined IP address. The two VoIP devices will use the SDP information in the INVITE and OK SIP methods to negotiate a path over which the audio stream will travel. ![]() The problem arises is in the second half of the payload – at the SDP (Session Description Protocol). When the provider’s VoIP equipment sees this packet, it may be OK and route a response back as needed. The NAT device on this network is going to replace the local source IP address with a publicly routable source address, but only for the IP header on this packet. Let’s look at a SIP INVITE request from a phone on a local network:Īs you can see from all the underlined IP addresses, the local IP address frequently appears in the payload of the SIP message. ![]() NAT attempts to fix this by replacing the local source IP address with an IP address which is routable on the public internet, hence the “translation.” NAT is translating a private IP to a public IP.įor protocols that do not embed address information into the payload of the data packet, NAT works just fine. That local network address will not be publicly routable due to the fact that the LAN is using a private IP addressing scheme (typically .x or 10.0.x.x.). ![]() That’s not an issue until the public resource tries to use that information to send data back to you. When your computer makes a request for a resource out on the public internet, that request will have a source address consistent with the local LAN addressing scheme. It is helpful to understand what NAT (Network Address Translation) does before you see why this causes a problem with SIP (Session Initiation Protocol). When dealing with VoIP traffic on today’s networks it is inevitable that you will run across an issue involving NAT and SIP.
0 Comments
Leave a Reply. |