As we known, the VoIP (SIP) domain always uses SIP URI to establish call sessions. To work with traditional PSTN networks, we need gateways (or SBC) to bridge two networks. Most of these gateways can support SIP URI, so we can always use SIP trunk to estanlish connections between VoIP and PSTN with SIP URIs which are as same as connections between VoIP domains.
But some gateways cannot support SIP URIs, they can only accept traditional telephone numbers which are the tel URIs defined in RFC3966. The URI is in “<tel: xxx>” format, not in “<sip:name@address>”format. Please refer to the figure below.
miniSIPServer can always accept the tel URI from peer sides, but never send out the tel URI. In recent months, several customers ask us to support sending out the tel URI through SIP trunks to work with some PSTN gateways. So we upgrade miniSIPServer to V60 (build 20250208) to update the SIP trunk functions. In the “outgoing call” of SIP trunk, we can select “Use the tel URI” item, then miniSIPServer will use <tel> URI to make outgoing calls for the SIP trunk.
For incoming calls of the SIP trunk, it is unnecessary to configure anything since miniSIPServer can accept both SIP URI and TEL URI.
By the way, cloud miniSIPServer still can only support SIP URI.
miniSIPServer is upgraded to V60 which is the latest stable version for business development. The first big thing is “conference room” feature which provides conference calls for local users. At most 5 clients can join the same conference call. Please refer to the service document for more details. Cloud miniSIPServer is also upgraded to support this feature.
In another way, as we have posted in previous blog, several services are finally removed from local miniSIPServer, such as calling-card and call-shop. These features were important for some of our customers, but it is time to say good-bye now.
As we know, miniSIPServer was developed about 20 years ago. Lots of services and features are added into miniSIPServer to support more and more customers.
Recently we have reviewed all these services. Some services have so long history that we have to think whether they are suitable for current environments, for example call-shop, calling card, and so on.
Next version will focus on refining or clearing some services. miniSIPServer will step into next stage and be more faster, more stabler.
Run miniSIPServer on Ubuntu 24.04 LTS (Noble Numbat)
Ubuntu 24.04 is the latest LTS (long-term support) version, so it will be deployed widely in business environment. We install miniSIPServer on this important version and make some tests. The result is perfect! Please refer to the figure below.
If you want to deploy a new VoIP network on Linux system, Ubuntu 24.04 could be a good choice.
Please refer to online document for more details about how to run miniSIPServer on Linux system.
When miniSIPServer sends out SIP messages, such as REGISTER or INVITE messages, to VoIP providers, it will add a parameter ‘user=phone’ after Request-URI. It is required by China Mobile network. In most scenarios, it is no problem since URI parameters are defined in RFC3261.
But unfortunately, some customers recently reported us that their miniSIPServers failed to connect to their VoIP providers because these providers’ servers cannot recognize parameters of Request-URI. Of course, the easy way is that the VoIP providers upgrade their servers to fit RFC3261, then everybody will be comfortable.
Some of them insist on their status and refuse to make any change. Then we have to make a change in external lines’ configuration. Please refer to the figure below.
We add a new item “additional parameter of Request URI” in external lines’ outgoing call configuration. Then customers can control the parameter according to their real network environments.
In another way, if the GUI is in Chinese which means the customer might configure miniSIPServer for China networks, the default value of such item will be “user=phone”. Otherwise, its default value is blank. We think it will flexibly fit the network requirements around the world.
One of miniSIPServer cloud customers reported a bug that all his phones cannot register to the cloud system. We checked our networks and cloud nodes and found nothing.
We tried to capture SIP messages from his side but still got nothing. That means all SIP messages from his phones were lost, but his local network was OK, only SIP system was broken.
It is very strange. The customer finally found his local DNS was changed for unknown reasons. His local ISP returned wrong DNS records of our cloud system to his network. After changing the DNS server to Google DNS server, the problem was fixed and his VoIP network came back.
If all your SIP phones are offline and your network is confirmed to be ready, you can try to check DNS records. We suggest following tips to check the DNS records between Google DNS and your local ISP.
If you are working on windows system, you can use nslookup command to check DNS results. For example, we want to check the DNS result of virtual SIP server ‘1425.s1.minisipserver.com’ from Google DNS server which is ‘8.8.8.8’, we can use the command below.
nslookup 1425.s1.minisipserver.com 8.8.8.8
If you are working on Linux system, you can use dig command to check DNS result like following.
dig @8.8.8.8 1425.s1.minisipserver.com
You can check the DNS results from your local ISP’s DNS server. If its result is different with Google DNS result, that means your local ISP blocks our VoIP cloud system or its DNS results are contaminated for unknown reasons.
Personally, I suggest to use Google DNS server which is ‘8.8.8.8’ or cloudflare DNS server which is ‘1.1.1.1’.
By the way, Debian systems don’t have dig command by default. You need to install the dnsutils package to get such tool.
Debian 12 (bookworm) was released. It is the latest stable version and will be widely deployed in business environment absolutely. So we run and test the latest miniSIPServer on this system as usual. Of course, the result is perfect.
Please refer to the figure below.
If you want to build a VoIP system on Linux system, Debian 12 is a good choice.
Please refer to our online document for more details about how to install and run miniSIPServer on Debian systems. And I’m sure you’ll like the combination of Debian and miniSIPServer.
OpenSSL released new versions to fix several serious security problems. miniSIPServer uses the OpenSSL library to provide the SIP over TLS feature and we upgrade miniSIPServer to V40 (20230221) versions which use the latest OpenSSL library.
If you have deployed “SIP over TLS” in your VoIP network, we strongly recommend that you upgrade miniSIPServer to the latest versions.
As we know, RFC3262 defines SIP reliability of provisional responses. It is an old feature and miniSIPServer ( both local versions and cloud versions) can support it for a long time. When working with traditional telcom carriers, this feature is mandatory, that means carriers will reject all incoming calls if they cannot support reliability of provisional responses.
RFC3262 defines a “100rel” parameter to indicate reliability of provisional responses, so we call it “100rel” capability. In normal, when invoking a call, the caller should make itself clearly that it can support “100rel” capability, and of course, the callee side should also make itself clearly that it requires to use “100rel” capability.
Basic call flow with 100rel
In the RFC3262, we can get following details:
…… the initial request contained a Supported or Require header field listing 100rel, and that there is a provisional response to be sent reliably. ……
UAS core … MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field.
Then both sides can establish reliability of provisional responses. Above figure describes the basic call flow. When UAC receives a 18x message which is a provisional response, UAC should send a PRACK message back to tell UAS that UAC has received its 18x message.
This is not a complex call procedure. We thought it wasn’t until several days ago. One of our cloud miniSIPServer customers reported he cannot make calls out. Then we traced his calls and get following call flow described below.
405 error in a 100rel procedure
Unbelievable …… this voip provider requires “100rel” in its 183 messages, but once miniSIPServer sends PRACK messages to confirm that, it returns “405 method not allowed” to reject them, and it causes every call failed.
Why?! If it cannot accept or support PRACK messages, why does it require “100rel” in its provisional responses?
It is quite easy to fix that. Just remove its “require 100rel” from 18x messages, miniSIPServer will not send PRACK messages back. But unfortunately, the team of this voip provider doesn’t know how to do that.
Our customer is blocked and his service has to be stopped. In another way, I personally think some VoIP providers use public open source servers, such as Asterisk, FreeSwitch, and so on, to build their solutions, maybe they don’t have enough experts to understand what they built.
So we update miniSIPServer to add an option in external lines configuration to disable reliability of provisional responses. Please refer to the figure below.
disable reliability of provisional responses
If you check this item, the INVITE messages sent from miniSIPServer will not have “support 100rel” parameter. Once you meet such a ridiculous VoIP provider, you can try this.
Recently lots of customers reported that they didn’t receive activation emails when they signed up miniSIPServer cloud accounts. All of them are using free email systems, such as gmail, and so on.
At first we think such systems move our emails to spam boxes, but customers still cannot find them there, so we think our emails are blocked.
We completely understand that. Since lots of email are sent from our cloud system to free email systems, including activation emails, balance notification emails, and so on, some email systems detect us to be a spammer.
It confuses us and we don’t want that, so we decide that our cloud system cannot accept customers use free email addresses to sign up miniSIPServer cloud accounts. We hope our cloud system to be treated as a serious virtual VoIP system, and we hope our custmers can understand that.
