In this new version, IVR-XML is supported and we can use XML to write IVR services. It is very easy and funny. We re-write auto-attendant service with IVR-XML, you can see it is very simple. The latest auto-attendant service file can be found in sub-directory ‘xml’ and file name is ‘aa.xml’.
The latest AA document is updated together, please refer to :
Some VoIP providers support “SIP trunking” services, most of them require user name and password for authorization.
To work with such SIP trunking, we need configure “external lines” in miniSipServer to establish connection with the VoIP carriers’ server.
In the external line configuration, we can configure peer server address (or domain name) , user name and password for authorization of register process and call process.
We are proud to announce that cloud-miniSipServer is upgraded today to support “caller prepaid” feature.
“Caller prepaid” service is an important service in local-MSS and has been deployed around the world. More and more customers use it to build some simple virtual VoIP carriers system with this feature.
Now, we can setup it in cloud communication. “Call prepaid” service in cloud, looks like very exciting, right? We believe this feature will benefit our customers to extend their VoIP business.
It is so easy to be a virtual VoIP carrier, why not take a try? Please visit http://minisipserver.com and sign up an account for free trial.
MSS V4 is updated (build 20110831) to support following features:
(1) Store CDR into database if MySQL database is active.
(2) In prepaid services, such as calling card, caller prepaid and so on, “one-time fee” is supported. This means the fee will be reduced from balance immediately one time when the call is answered.
We upgrade cloud-miniSipServer to support “Dial plan” features. Customers can use these features to control the calls very flexibly. When you sign in your account, you will get “Dial plan” features in command list at the left side .
And the trial duration of each call for trial accounts has been upgraded from 30 seconds to 60 seconds according to most customers’ requirements.
MSS stable versions are upgraded to V3.1.6 (build 20110813).
This version is upgraded to support voice mail nesting follow-me services. When a local extension has been configured with voice mail and following me services, the voice mail service will be triggerred if all follow-me parties don’t answer the incoming call.
Some bugs in web management are also fixed at the same time.
These modifications have been merged to V4 latest version.
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.
