Browsed by
Category: Releases

Product release messages, including LTS, stable, development versions and patches.

the tel URI

the tel URI

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.

the tel URI network

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.

the tel URI configuration of SIP trunk in miniSIPServer.

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.

miniSIPPhone for Linux (Debian/Ubuntu)

miniSIPPhone for Linux (Debian/Ubuntu)

Finally, miniSIPPhone is upgraded to V10. The most important thing is that it can support Linux system now. Of course, the distro must be Debian or Ubuntu. As same as miniSIPServer, Debian must be V10 (Buster) or higher versions, and Ubuntu must be V18.04 (Bionic Beaver) or higher versions.

Both X86_64 (amd64) and ARM64 (AArch64) are supported.

It is quite easy to run SIP phone on Linux system now. Please visit our website to download the latest version:

For example, you download “msp_v10_amd64.deb” and install it with following command:

sudo dpkg --install msp_v10_amd64.deb

Then you can click the linker to run miniSIPPhone:

If you want to uninstall miniSIPPhone, you can run following command directly to remove it:

sudo apt remove minisipphone
Conference room and others

Conference room and others

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.

Support TLSv1.3

Support TLSv1.3

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.

181 “Call Is Being Forwarded”

181 “Call Is Being Forwarded”

“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.

Call fowarding with 181 messages

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"

Security problem

Security problem

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.

Additional parameter of Request-URI

Additional parameter of Request-URI

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.

Additional parameter configuration
Additional parameter configuration

Say goodbye to Windows XP/2003

Say goodbye to Windows XP/2003

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.

For the 4K screen

For the 4K screen

Our customers report a bug when running miniSIPPhone with a 4K screen. Please refer to the figure below.

miniSIPPhone main window
miniSIPPhone main window mixed up

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.

call tag and cause

call tag and cause

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.

FCI parameters
FCI parameters

“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.