SIP server for windows and Ubuntu system
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.
By default SIP network always uses SIP URI to carry information, such as From, To, and so on. For example:
sip:+8613901088888@ims.bj.chinamobile.com
But for traditional telecommunication networks, they always use E.164 telephone numbers which are different with SIP URI. So ETSI (or 3GPP) defines a new URI, that is TEL URL. For example:
tel:+8613901088888
So when working with IMS networks, there could have two URI formats, SIP URI and TEL URI. miniSIPServer can support both formats, it can process TEL URI of incoming calls automatically, but all outgoing calls always use SIP URI formats.
It could be a problem. Fortunately IMS networks consider it very carefully. For example, China Mobile can accept TEL URI and SIP URI with special parameter ‘user=phone‘ which is described below.
sip:+8613901088888@ims.bj.chinamobile.com;user=phone
If we configure external lines of miniSIPServer to work with China Mobile networks, it can be no problem because miniSIPServer will automatically add ‘user=phone’ to Request-URI. But in some markets, China Mobile requires to establish SIP trunk connections, then it could be a problem. miniSIPServer will not add ‘user=phone’ in Request-URI since we think it is a ‘server to server’ scenario.
To fix that, we add a ‘additional parameter of Request-URI’ parameter in SIP trunk outgoing call configuration. Please refer to the figure below.
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.
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.
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.
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.
In the SIP session, we can set ‘ptime’ parameter of SDP to negotiate RTP packages between two call parties. If one side has different idea about the RTP package size, it can send its own ‘ptime’ parameter back with the value it wishs. But the world is so complex, some SIP devices don’t care ‘ptime’ paramter and they don’t tell other sides which values they like, they just send RTP packages back directly. It could cause problem.
For example, as we know, ‘call recording‘ service requires miniSIPServer to mix two audio streams from both call parties. In order to make the work easy, miniSIPServer will set ‘ptime’ to 20 which means the call parties should send their audio streams in RTP packages every 20 milliseconds, then miniSIPServer get two packages every 20 milliseconds and mix them into local audio files. Now surprised, some devices send RTP packages every 30 milliseconds, some send RTP packages every 40 milliseconds. When miniSIPServer has to mix these packages, some bytes have to been lost since the time is different and the package size is different too. It makes the audio quality of local audio files very poor.
Of course, the perfect solution is all SIP devices respect ‘ptime’ parameter, but we cannot count on it.
So miniSIPServer is upgraded to V40 (build 20220922) to fix it. The new version will try to cache RTP packages of both sides and smooth the mixing procedures. And we have to say that it will increase the workload of miniSIPServer.
We updated miniSIPServer to fit 4K screen recently, but we find that we have to upgrade our tool chains at the same time if we want to get a perfect result.
Unfortunately the new tool chains cannot support Windows XP/2003 systems, so it is time to say good bye and move on now.
The latest version (V40) is released yesterday and it requires Windows 7 or abover version if you want to deploy miniSIPServer on Windows system. V40 is also rebuilt for Debian / Ubuntu systems to fit higher DPI screens.
Please enjoy the new versions. And please update us if you have any questions or opinions. Thanks.
Our customers report a bug when running miniSIPPhone with a 4K screen. Please refer to the figure below.
When building GUI (including miniSIPPhone and miniSIPServer), we use absolute positions and lengths to assign components, so they are quite small or tight if the screen has hight resolution ratio, for example, a 4K screen.
To fix that, we change the absolute values to relative positions and lengths. Of course, both miniSIPServer (V39 build 20220823) and miniSIPPhone (V8.4) are updated.
In another way, we refine dialogs sizes and styles of miniSIPServer at the same time. It should be more comfortable now.
Sometimes, customers want to know some details about history calls, such as who released such calls and why they were released. Because they were not real-time information, we cannot use miniSIPServer trace tool to get the results, so we update CDR function to save more informations for deep research.
In the FCI (Furnish Call/Charge Information) section, we add two parameters “callTag=” and “cause=”. Please refer to the CDR records as below.
“callTag=” parameter will be used to save the position where the call is released in miniSIPServer. We can know where and who release the call. For example, the call might be released because it received a BYE message from caller side, and so on. The tag value is an inner value and it will not be published to customers.
“cause=” parameter is used to save the cause value. If miniSIPServer receives 4xx or 5xx messages from the called side, and there is “Reason” header which has ’cause’ parameter, miniSIPServer will use this value to release the call,otherwise, miniSIPServer will use inner cause value. And of course, this parameter will be saved in FCI of CDR records.
By default, miniSIPServer opens UDP port 5080 to receive call-back message to invoke calls. If miniSIPServer is deployed in public network, it is possible to receive lots of other UDP packages. Of course, we can configure “application server address” for IP address authorization, but unfortunately its default value is blank and it could be dangerous.
So we update call-back service to protect the system and refine its service logic. Please refer to the configuration window firstly.
(1) The default value of “Application server address” is changed to a local loop address “127.0.0.1”, so outsides UDP packages will be disabled. Of course, we can still keep it to be blank to accept all packages from any address, but we suggest not to do that.
(2) Local listen port can be zero which is used to close UDP socket. If the port is zero, miniSIPServer will disable the whole call-back service since it is impossible to receive any outsides UDP packages now. If you don’t use call-back service, it is better to set it to be zero.
(3) Cancel “external line mode” item. Some cutomers always ask us what it is and always confused with this item. It is just to add ‘out group prefix” automatically before the called numbers in two sessions. In fact, it is not flexible if we want to call local users and outsides users at the same time. So we discard it, if we want to call outsides users, we can add ‘out group prefix’ manually in the REQUEST messages. That means application server should be responsible for the numbers format and dial plan result.
Please refer to call-back service document for more details.
With old Debian version, we can start miniSIPServer on boot by updating ‘/etc/rc.local’ file. Since most Debian versions have been migrated to systemd, so we have to change to other ways to do that.
The first way is to keep “rc.local”, so we need to enable “rc-local.service” in systemd. This service is disabled by default, we can use command below to activate it.
sudo systemctl enable rc-localIt is not a very good way because we have to update “rc-local.service” to fit miniSIPServer requirements which might affect other applications defined in the same “/etc/rc.local” file.
It is better to define an independent service to start miniSIPServer in systemd. In fact, it is quite easy. Lets explain the details in Raspberry Pi system for example. In this scenario, we will indicate Pi to start miniSIPServer (command line) at boot and the default user is “pi”.
First, please create a “minisipserver.service” file in directory “/lib/systemd/system” with content below.
[Unit]
Description=miniSIPServer
After=network.target mariadb.service
Requires=network.target mariadb.service
[Service]
Type=simple
User=pi
KillMode=process
ExecStart=/opt/sipserver/minisipserver-cli
[Install]
WantedBy=multi-user.targetThen, you can use command to activate this service.
sudo systemctl enable minisipserverOnce “minisipserver.service” is enabled, miniSIPServer (command line) will start up automatically when the system is reboot.
In the “minisipserver.service” file, we can see two important sections, [Unit] and [Service], and we need to describe more details about them.
Unit
(Please click here to get more details about unit section in systemd.)
We care “After=” and “Requires=” parameters.
Since miniSIPServer is a network application, so it requires network is ready and need to be started up after the network.
In our environment, miniSIPServer is connected with Mariadb/MySQL database, so it requires the database is ready too. If you don’t need database, you can remove “mariadb.service” from “After=” and “Requires=” parameters .
Service
(Please click here to get more details about service section in systemd.)
We care “User=” and “ExecStart=” parameters.
“User=” parameter indicate systemd who is trying to run this service and start specific application. Since we are using Raspberry Pi system and the default user is “pi”, we set this parameter to “pi”. You need to change it to your own user name in your own Linux system.
By default, miniSIPServer is installed at “/opt/sipserver” directory and the command line file is “minisipserver-cli”, so we set “ExecStart=” parameter to indicate systemd where to get the executing file and run it.
miniSIPServer old versions save CDR records into some binary files in “AppData/cdr” directory. If you want to check history records, you have to start miniCDR tool to open them. If you want to do more research, you will have to use miniCDR to convert them into CSV format files.
Now miniSIPServer new version ( I mean V39 or newer) will save CDR records into CSV files directly. Of course, all these .csv files are still stored in “AppData/cdr” directory. Since .csv files are text format, you can use any text tools, such as notepad in Windows and Gedit in Linux, to open them. If you have Excel, you can use it to open and analyze these CDR files directly too.
And miniCDR is upgraded at the same time to be able to process previous .cdr files and new .csv files.