When deploying a VoIP network, we often have one-way or no-way audio problems. It is caused by private network, for example, some SIP phones or miniSIPServer are behind routers and other SIP devices are in another different network which could be a private network or public network.
To resolve such problem, we often suggest to configure “forwarding ports” in routers manually. If you are familiar with routers, it is easy to do that.
But someone might not know how to do that, or someone might make mistake in router’s configuration. So we add a new feature in miniSIPServer to help that.
It is UPnP (Universal Plug and Play). UPnP can help miniSIPServer to map necessary ports automatically.
Firstly, you need confirm that your router can support UPnP and it has been enabled.
Then, you can click menu “Data – System” in miniSIPServer and enable the item “Enable UPnP to ask router to map ports”. Please refer to following figure.
UPnP configuration in miniSIPServer
By default, miniSIPServer will map SIP (over UDP) port and audio ports for relaying audio streams.
In another way, there is a limitation in routers. Most routers limit the number of UPnP ports, for example less than 30 ports. So if you are deploying a miniSIPServer for 50 clients or more, you will still have to configure “forwarding ports” manually.
How to deploy MSS behind NAT and provide public service
Some customers often request to deploy MSS behind NAT, but still need provide public service. That means MSS is in private network and some SIP phones/clients are in public network (internet), or MSS need work with public VoIP carriers’ network.
Following figure describes a simple network for this scenario:
Demo network
In this network, we can see
(1) Private network is connected to public network by a router whose public address is 8.8.8.8 and private address is 192.168.1.1
(2) MSS is deployed in private network with private address 192.168.1.2.
(3) Some SIP phones are in the same private network, such as local users 100 and 101. Some SIP phones are in public network, such as local user 102.
It is no problem for local user 100 and 101 to visit MSS since they are in the same network. So the problem is how to make outside local user (102) can visit MSS.
We can resolve it by forwarding some ports in router.
First, in the router, we can configure forwarding UDP port 5060, 10000~20000 to the PC where MSS is installed. Most routers can support this function. Port 5060 is standard SIP port. Ports 10000~20000 are RTP ports to transfer media streams.
Second, we must indicate MSS to work with public address. Please click menu “Data / System / SIP” and fill the “Main address” with the public address “8.8.8.8”. SIP phones/clients can use this public address to visit MSS.
There is another problem. In above scenario, the router is configured with a fixed public address. In normal, the router could be ADSL router and it maybe has a dynamic IP address. Outside users cannot use the dynamic address to visit MSS. Then, how can we provide public services?
To resolve it, we can use domain name, for example, we can use DynDNS to provide domain name for our MSS. The router must be able to support “Dynamic DNS”. In our example, we assume we get a domain name “sip.dyndns.org” from DynDNS and configure it in our router, then we can use this domain name as another miniSIPServer address. In following figure, we use such domain name as main address, and use the private address as additional address.
SIP configuration
SIP phones/clients must be able to use domain name as server address or proxy address, so they can configure “sip.dyndns.org” to visit MSS in our scenario and make calls.
In previous blog, we have discussed why there is one-way audio problem. In this blog, we will continue our discussion to find how to resolve this problem.
As we can see, the SIP phone (100) sends its private address to SIP client (101) and this makes the one-way problem, so we can think why not send its public address which is 8.8.8.8 to the SIP client? If it can do that, SIP client can send its audio stream to this public address and the router will transfer it to the SIP phone, then SIP phone can hear SIP client, right?
Right! It is a perfect solution. But we need ask: how can the SIP phone (100) know its public address?
The answer is STUN. STUN means “Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NATs)”. It is a very long definition. Simplely, STUN is a tool to discover public address for devices deployed in a private network.
Please refer to following figure:
STUN process
Before SIP phone makes a call, it asks STUN server firstly to get its public address. After that, in our previous scenario, when SIP phone begins to make a call, it can say: Hi, I am 100, my audio address is 8.8.8.8:10000. Please send audio stream to me.
By the way, here one public address means one public IP address plus one port. For example, in “8.8.8.8:10000”, “8.8.8.8” is public IP address, and “10000” is port. “8.8.8.8:10001” is another public address.
Since 8.8.8.8 is a public address, it is no problem for SIP client to send its audio stream to this address. Then, both call sides can hear each other now.
Almost all SIP devices, no matter SIP phones or SIP clients, can support STUN. The only thing we need know is we need indicate which STUN server we should use. In our step by step document, we give a simple example for X-lite, please refer to following document for details:
Can STUN resolve all one-way / no-way audio problem?
No, it can work well in most scenarios, but it cannot resolve all problems. It depends on the private network type. Simplely, it depends on the routers ( of course, in some network, it can be firewall probably too).
Special network for STUN
Please look at above figure. There are two sessions: one for request public address from STUN server. Another is call session between SIP phone and SIP client.
As we know, the router will keep the mapping relationship between public network address and private network address. By default, most routers will assign and keep the same mapping for different sessions if they are from the same device in the private network. So the SIP phone will have the same public address in these two sessions.
But some routers or networks will assign different mapping for different sessions, that means the sip phone will have different public address for these two sessions, so it still cannot know its public address of the session between it and SIP client.
If STUN cannot resolve your one-way audio problem, the root reason could be the router or your network type, and the final perfect solution is establish a VPN network to include all your SIP phones and SIP clients. That’s another topic.
Almost all of us will meet this problem when we deploy our first VoIP network. We are often confused: why I cannot hear peer guy but he can hear me? why we cannot hear each other?
The root reason is that there is private network and public network. If both sides are in different network, the problem will happen. Please look at below figure which desribe a very simple VoIP network:
One way audio problem network topology
In this simple network, we have two VoIP devices, one is SIP phone whose number is 100, another is SIP client whose number is 101.
SIP phone is in a private network and its private address is 192.168.1.100, and its router is connected to public network with address 8.8.8.8.
SIP client is installed in one PC which is in the public network with address 8.8.4.4.
So when SIP phone makes a call to the SIP client, what will happen?
SIP phone say: Hi, I am 100, my audio address is 192.168.1.100. Please send audio stream to me.
SIP client answers it: ok. I am 101, my audio address is 8.8.4.4. Please send your audio to me.
SIP phone sends audio stream to SIP client. Since “8.8.4.4 ” is a public address, it is no problem for SIP client to receive the audio stream from SIP phone. That means SIP client can hear SIP phone now.
SIP client sends its audio stream to SIP phone “192.168.1.100”. You can see it is a private address and cannot be reached by SIP client which is in public address. SIP client will fail to send its audio stream to SIP phone in fact.
So finally, SIP client can hear SIP phone, but SIP phone cannot hear SIP client. This is a very typical one-way audio problem.
