For miniSIPServer V60, the lowest requirement of Debian is changed to the “oldoldstable” version which is Debian V10 at this time. That means Debian V8 and V9 will not be supported now.
Of course, the lowest requirement of Ubuntu is also changed to Ubuntu V18.04.
Please refer to the document for more details about Linux systems.
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.
FXS gateways can help to connect traditional phones to VoIP deamon. The common topology is below.
VoIP deamon <--> miniSIPServer <--> FXS gateway <--> traditional phone
In normal, one FXS gateway connects to one traditional phone, but some FXS gateways can connect to several phones at the same time. We need to pay attention to this scenario.
The FXS gateway need to bind several SIP users accounts since it can connect to several phones. In another way, the gateway uses one URI address (including IP address and port together) to register these SIP accounts to miniSIPServer. That meas several SIP users will connect to miniSIPServer with the same address.
If one of the users is configured with wrong information, and the gateway keeps sending SIP messages to miniSIPServer, it will trigger ‘fail to ban’ feature, then the gateway’s address will be blocked by miniSIPServer. As we said, since the gateway uses one address to register several SIP users to miniSIPServer, other SIP users will have to be blocked together.
In this scenario, we need to stop ‘fail to ban’ for the gateway. We can add the address of the gateway into white list. Please click menu ‘services – IP address black-white list’ to add a record to accept the IP address. For example:
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.
miniSIPServer recently is upgraded to support TLSv1.3. This modification doesn’t affect configuration, so you need to do nothing if you upgrade your miniSIPServer to the latest versions.
Two modules could use TLS transport: (1) SIP server, and (2) Embeded HTTP server. If your SIP phones can support TLSv1.3, it is better to use TLSv1.3 to protect communication. Please refer to “SIP over TLS” document for more details. Both local miniSIPServer and cloud miniSIPServer can support SIP over TLSv1.3 now.
By default, miniSIPServer starts an embeded HTTP server for web management. If you want to manage it through the pubilc network, you have to enable TLS transport to protect HTTP information. In another way, most navigators, such as Chrome, Edge, Firefox and so on, can support TLSv1.3 now. Please refer to “web management” document to enable encrypted HTTP.
As we know, miniSIPServer has some versions for Raspberry Pi and they are all for armhf architecture. Recently, more and more customers ask us for miniSIPServer versions for ARM systems. Most are arm64 architecture, and the customers want to run miniSIPServer on ARM servers or cards.
So we change the specific miniSIPServer version for Pi to the common miniSIPServer version for ARM64. Of course, raspberry pi can support arm64 architecture too, so this modification can cover most ARM scenarios and devices, including Pi.
In another way, most customers want to run miniSIPServer command line version on their ARM servers or systems. That means it is unnecessary for them to have a GUI interface, and they only need ‘minisipserver-cli’. By default, miniSIPServer requires ‘qtbase5-dev’ package to provide GUI. In this scenario, the ‘qtbase5-dev’ package will not be necessary, so we move this package from ‘Depends’ section to ‘Suggests’ section of miniSIPServer’s deb-control.
If you want to run miniSIPServer with GUI, you can still install the libraries with the following command:
sudo apt install gcc g++ qtbase5-dev
If you only need a command line version, you can install the libraries without qtbase5-dev, like following:
sudo apt install gcc g++
“Call forwarding” is a very traditional service in VoIP or communication fields. By default, SIP clients can send 3xx messages to miniSIPServer to invoke a forwarding. In another way, miniSIPServer can also directly invoke forwarding by itself.
But when the callee side is being forwarding, the caller side knows nothing about it. In most scenarios, the caller parties don’t care the forwarding. but some customers sometimes need to know what happens when the call is being forwarded.
miniSIPServer can send 181 “Call Is Being Forwarded” messages back to the caller side to update it that callee side is being forwarding. In the 181 messages, miniSIPServer will add a Call-Info header to indicate the forwarding information. Please refer to the figure below.
In this figure, there are two forwardings, (1) user B is being forwarded to user C; and (2) user C is being forwarded to user D.
The Call-Info header of the 181 message will indicate (1) the call is being forwarded, (2) who is being forwarded, and (3) who is being forwarded to. Please refer to the Call-Info header of the first 181 message which indicates user B is being forwarded to user C.
Call-Info: purpose=forwarding, username="userb", contact="userc"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.
sudo apt install dnsutils