Frequently asked questions
Some customers need invoice information. Most of them are on behalf of companies. To fit these requirements, we suggest you to purchase MSS through Avangate which is listed in our “buy now” page.
Please visit Avangate F.A.Q document:
http://www.avangate.com/shopper-support/shopper-faq.php
In this document, please refer to session “4. How do I receive the invoice?” for more details.
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’.
One of our customers has two different VoIP accounts, for example (1) 1234 and (2) 5678. It is required to select account “1234” if users dial “9xxxx” numbers and select account “5678” if users dial “8xxxx” numbers. The final numbers should delete these prefix “9” or “8” and “xxxx” should be sent to VoIP providers.
We can use MSS powerful “dial plan” features to fit this requirement.
By default, MSS uses called number prefix “9” to distinguish outgoing calls to outsides. If there are several external lines and without any special configuration, MSS will select one of them in round-robin for each call. Now what we need do is to configure different called number prefix and select different external line for them.
In this step, we need configure a record to delete number prefix “8” or “9” from called numbers. Please click menu “Dial plan / Transition” to add a record illustrated below.
Transition ID = 1 Transition type = delete Start position = 0 Length = 1
According to requirement, we need indicate MSS to analyze called number prefix “8” and “9” to use different specific external line. Please click menu “Dial plan / Analyze called number” to add two records.
Record 1: analyze called number prefix “9”
Dial plan = default Called number prefix = 9 Route type = external line Specific external line = 1234 <== use specific external line Change called number = yes Transition ID = 1 <== configured in step 1 Re-analyze after transition = no
Record 2: analyze called number prefix “8”
Dial plan = default Called number prefix = 8 Route type = external line Specific external line = 5678 <== use specific external line Change called number = yes Transition ID = 1 <== configured in step 1 Re-analyze after transition = no
Some customers will find that their external lines configuration were gone when they sign into their cloud-mss accounts.
What happened to their accounts?
The root reason is that these customers maybe configure wrong external lines information, such as invalid password, then cloud-mss fails to register these external lines to VoIP carriers. cloud-mss will try to register them for lots of times. In this scenario, peer VoIP carriers could treat cloud-mss as a spammer or an attacker, and they will block or filter cloud-mss messages, that could effect other cloud-mss customers.
To avoid that, if cloud-mss always fail to register an external line for lots of times, it will report this external line to background administrator system, and this external line will be deleted automatically.
That’s why you cannot find your external line information. So please double check your information or check with your VoIP providers, then try to configure them again.
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.
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:
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:
http://www.myvoipapp.com/docs/faq/setup_ippbx_for_small_business_step_by_step/index.html#faq_stun
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.
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:
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.
Then, how can we resolve it? To be continue …… 🙂
We are often asked this question about audio codec or video calls. Some customers want to confirm whether miniSIPServer can work well with their SIP phones/clients who can support several audio codecs or video calls.
We often answer that it depends on their own SIP phones/clients. miniSIPServer, not matter local-miniSIPServer or cloud-miniSIPServer, doesn’t care media codec by default.
Why we say that?
Please have a look at following figure which describes a basic media process model of miniSIPServer in a normal basic call.
From this figure, we can see:
(1) miniSIPServer only controls call signals.
(2) Media stream is processed by the clients themselves.
This model will reduce the work-load of the server since all media streams are bypass server, so it is unnecessary for the server to support several media codecs.
But in some service scenarios, miniSIPServer need play audio to the SIP phones. For example, in auto-attendant or calling card services, miniSIPServer need prompt audio announcement and collect user input information. Obviously, miniSIPServer is required to support audio codecs in these scenarios.
That’s right. If miniSIPServer need process audio stream, it can support two audio codecs: G711a (PCMA) and G711u (PCMU).
By the way, after playing audio stream, the final media stream will be processed still in end-to-end model. Please refer to following media model of miniSIPServer for these scenarios:
When some customers use miniSipServer cloud ( for local minisipserver, the same) to process their voice mail, but they are often confused why cannot receive voice mail in their email box.
In fact, we have an online document to describe how to use voice mail feature. Please refer to:
http://www.myvoipapp.com/docs/mss_services/voice_mail/index.html
For MSS cloud, there is a little difference. First, MSS cloud doesn’t support MWI (message waiting indication), so it can only send voice messages to your email address. Sometimes, customers often forget to configure SMTP server information which is necessary for MSS cloud to send your voice mail, or they often forget to cofigure email address of specific extensions.
So let’s describe more details about these. Before this, I assume that you have signin into your MSS cloud account. If not, please sign-up one.
Step 1: configure SMTP server information
Please look at the figure. You need click “system information” linker, then fill your SMTP information there. By the way, for Gmail accounts, they are always required to configure secure connection.
If SMTP information are all right, MSS will use it to send voice mail.
Step 2: configure email address of extension
Please click “local users” linker and select or add one extension to edit. For voice mail feature, you must configure “eMail address” to make MSS cloud know where the voice mail should be sent to.
Of course, you also need configure “voice mail” service right to this local user / extension.
So after that, for no-answer incoming calls, MSS will prompt the caller party to leave messages and save/mail them to the user’s email address.
It is a often asked question. In MSS, you can use “external line” to connect to your fxo gateway. In our forum, we give a simple description about how to link to linksys 3102. Maybe you can refer to this document for help.
http://www.myvoipapp.com/forums/viewtopic.php?f=5&t=419
(Sorry, since our forums have been removed, above document cannot be visited. Please refer to online F.A.Q document. Thanks. )