Some virtual servers in cloud-MSS system have been changed, please pay attention to these items.
Each virtual SIP server will enable STUN feature. For example, if the SIP server address is “1234.s1.minisipserver.com”, its STUN server can also be the same address. That means “1234.s1.minisipserver.com” is also its STUN server address.
Now we suggest “stun.minisipserver.com” by default. It is a simple public STUN server for all virtual SIP servers. Of course, you can still configure your virtual SIP server address as your STUN server.
In voice-mail feature, we need a SMTP server to send emails with attached audio files. Each virtual SIP server can be configured with customers’ own SMTP servers. But we find it could make several problems. For example, most customers try to use Gmail SMTP server. Gmail SMTP server requires that you need enable POP/SMTP firstly, and grand other access. Most customers don’t know how to do that.
So we disable SMTP server configurations. All voice mails will be sent from our own SMTP server. Most important is that you will need check your spam box if you cannot find voice email in ‘inbox’.
csipsimple is a very good sip client software in Android, we often suggest our customers to use it if they want to deploy voip network with Android phones.
As we know, there are always one-way or no-way audio problem. To solve this problem, STUN should be configured in softphone. But some customers often response it is hard to set STUN in csipsimple.
In fact, it is easy to do that. Please follow below steps which are described in csipsimple website too:
(1) Go on setting Settings > Network – Tick “Use Stun” and fill a stun server on the field bellow. If you are cloud-mss subscriber, you can use your virtual server address as your STUN server too. Of course, you can use csipsimple default STUN server.
(2) You can also try to use ICE in addition to STUN if STUN alone doesn’t solve the problem : Settings > Network – Tick “Use ICE”.
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 22.214.171.124 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:
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 126.96.36.199: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 “188.8.131.52:10000”, “184.108.40.206” is public IP address, and “10000” is port. “220.127.116.11:10001” is another public address.
Since 18.104.22.168 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).
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.