Browsed by
Tag: voip

Secure enterprise SIP communication

Secure enterprise SIP communication

Enterprise communication systems are typically deployed within private networks, with Session Border Controllers (SBCs) or voice gateways installed at the network edge to facilitate external communication. Therefore, in most scenarios, enterprise communications remain highly secure. However, a growing number of businesses are now deploying SIP servers in the cloud, while an increasing volume of SIP terminals within enterprises are accessing these corporate SIP servers from external networks. This shift has exposed part (or all) of enterprise communication systems to public networks, making security concerns increasingly severe.

The security of enterprise SIP communication involves many aspects of the network system, such as firewalls. Focusing solely on the SIP communication itself, it must be encrypted to prevent the exposure of communication information to other network users. Encrypted SIP communication consists of two parts: (1) SIP message (signaling) encryption, and (2) voice stream (RTP) encryption, as illustrated in the figure below:

Secure enterprise SIP communication network topology

Certainly, enterprises can deploy VPNs to encrypt the entire network system — not just communication systems but also office systems and more. Encrypted SIP communication can also be established over a VPN. However, setting up an enterprise VPN involves relatively high costs and complex systems. This article focuses solely on encrypted SIP communication and does not cover other network security technologies such as VPNs.

SIP message encryption is achieved through “SIP over TLS.” Both cloud-based miniSIPServer, on-premises miniSIPServer, and miniSIPPhone support SIP over TLSv1.2 / TLSv1.3. Please refer to the online documentation for details, as this article will not elaborate further on this topic.

Voice streams are encrypted through SRTP transmission. The master key and master salt for SRTP are transmitted and negotiated via the SDP (RFC4568) in SIP messages. Therefore, only when SIP messages are encrypted can the critical information of SRTP be ensured not to be leaked. Simply encrypting voice streams with SRTP while transmitting SIP messages in plaintext cannot guarantee the overall security of SIP communication.

RFC4568 defines several cryptographic suites. Currently, we have chosen to support the default AES_CM_128_HMAC_SHA1_80 and do not yet support other encryption suites.

The SRTP protocol family includes numerous extensions. Currently, miniSIPServer and miniSIPPhone support the most fundamental RFC3711 protocol, which is also the basic SRTP protocol supported by the vast majority of SIP devices (including servers, PBXs, SBCs, and endpoints). DTLS-SRTP is not currently supported, primarily due to the following considerations: (1) SIP over TLS already ensures the security of the master key & salt, achieving an effect equivalent to that of DTLS; (2) although internet technologies like WebRTC widely adopt DTLS-SRTP, most SIP devices do not support it, which would lead to interoperability issues in the realm of enterprise SIP communication.

miniSIPServer and miniSIPPhone can enable SRTP by default without requiring additional configuration. Some SIP devices need explicit configuration to select SRTP. For example, when configuring an account in MicroSIP, the “Media Encryption” setting must be configured as follows:

MicroSIP SRTP configuration
Welcome! Debian 13 (Trixie)!

Welcome! Debian 13 (Trixie)!

Debian 13 (Trixie) was released yesterday. It is the latest stable version and quite suitable for business deployments. We are big fans of Debian, so we immediately run and test miniSIPServer on this system. All test cases are passed. Perfect!

Run miniSIPServer on Debian 13.

You can deploy enterprise VoIP network with Trixie, it is an exciting choice.

miniSIPPhone supports SIP over TCP/TLS

miniSIPPhone supports SIP over TCP/TLS

Yes, we upgrade miniSIPPhone. Again!

miniSIPPhone V10.10 can support SIP over TCP and TLS now. In the account configuration, there is a new item ‘Transport’ to indicate which transport should be used to connect to SIP server.

miniSIPPhone account configuration, including transport configuration.

If SIP is over TLS, the messages are encrypted. It is quite necessary for enterprise communication if the servers or clients are deployed in public networks. As we know cloud miniSIPServer can support SIP over TLS and all virtual servers are deployed in the public network, so if you deploy miniSIPPhone at the same time, it could be safer for the whole VoIP network.

Of course, miniSIPPhone can work with other SIP servers who can support SIP over TCP/TLS to build a complete and safe enterprise VoIP system.

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.

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.

Refine miniSIPServer

Refine miniSIPServer

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)

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.

Run miniSIPServer on Ubuntu 24.04

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.

RequestURI parameter of external lines

RequestURI parameter of external lines

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.

Additional parameter of Request URI configuration

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.

Checking DNS results

Checking DNS results

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
Run miniSIPServer on Debian 12 (bookworm)

Run miniSIPServer on Debian 12 (bookworm)

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.

Run miniSIPServer on Debian 12 system.

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.