We typically develop and release the miniSIPServer software for Linux systems exclusively on Debian and Ubuntu, with versions distributed as deb installation packages by default. For users in the other major Linux ecosystem—the RPM camp—deploying miniSIPServer can be quite inconvenient. An increasing number of customers are expressing a desire to deploy miniSIPServer on operating systems such as SUSE, Fedora, openEuler, and so on.
Considering our limited resources (including manpower, equipment, etc.), we have decided to release the installation package in AppImage format, which is compatible with almost all non-Debian-based Linux systems. Of course, it currently only supports the x86_64 (AMD64) architecture and does not yet support the ARM64 architecture.
It is very simple to use and does not even require installation. Save the downloaded miniSIPServer software (for example, minisipserver_u500.AppImage) in any directory, and then set the “executable permission”:
chmod +x minisipserver_u500.AppImage
Double-click the file or run it directly from the command line:
./minisipserver_u500.AppImage
Everything else is the same as with the deb package installation method. Configuration files are also stored in the $HOME/.minisipserver directory.
We tested on openSUSE (Leap 16), Fedora 42, and openEuler (24.03 LTS SP2) respectively, with satisfactory results:
Run miniSIPServer on openSUSERun miniSIPServer on FedoraRun miniSIPServer on openEuler
The “hunting group” is a long-established enterprise communication service that was widely used in the circuit-switched telephone era and remains deployed by many businesses even in the VoIP era. However, times have changed, and the service itself must evolve to keep pace with the characteristics and requirements of IP networks. Based on recent customer needs and changes in the network environment, we have implemented several optimizations to the hunting group feature in miniSIPServer.
The focus has been on modifying and optimizing the “Operator” feature within the service. Please refer to the image below:
Change 1: One operator can now be assigned to multiple hunting groups simultaneously. Previously, an operator was restricted to a single hunting group, which no longer meets the needs of modern enterprises. As employees often handle multifaceted roles, there is a significant need for them to support multiple hunting groups at the same time. This new feature addresses this requirement.
During the era of circuit-switched telephony, phone terminals lacked sufficient capabilities. Therefore, hunting groups typically allowed operators to log in or out by dialing specific codes. However, for the following reasons, the new hunting group feature in miniSIPServer no longer supports manual operator login or logout:
(1) Most modern SIP terminals now have sufficient functionality to implement features like “Do Not Disturb” directly on the device side, making manual login/logout unnecessary.
(2) Now that one operator can support multiple hunting groups simultaneously, simple login/logout actions are inadequate. Operations would need to be performed for specific hunting groups, making dialing procedures cumbersome and unnecessary.
Change 2: For hunting groups using the “Linear” policy, operators can now be assigned a sequence number to define their selection order. Previously, the selection order was based solely on the sequence in which operators logged into the system, which essentially resulted in a random order and could not meet practical requirements. In real-world scenarios, certain operators often need different priority levels within the group.
An operator with a smaller “Linear sequence number” will be selected earlier by the hunting group. If multiple operators have the same sequence number, they will be sorted by their login time, with those who logged in earlier receiving priority.
Of course, this new configuration does not apply to the “round-robin” strategy. The round-robin strategy always strives to distribute calls as evenly as possible among operators to balance the workload.
The hunting group feature has been updated in both the on-premises and cloud versions of miniSIPServer. There are no differences in configuration or usage between the two versions. Please refer to the product documentation for more detailed information.
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:
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:
As we known, cloud miniSIPServer users can create IVR-XML files and audio files to build special communication services for their own companies. But these files had to be sent to our support team to upload to their virtual servers for them.
It is very cumbersome and inconvenient.
Now we upgrade cloud system to permit users to upload IVR-XML and audio files by themselves. Please click menu “Profile – IVR-XML file or System audio file” to do that.
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!
You can deploy enterprise VoIP network with Trixie, it is an exciting choice.
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.
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 latest version of miniSIPPhone is released today to support two key features: (1) Contact, and (2) Instant messages.
It has a new window to create and manage contact list like belowing:
In the contact window, you can select the target user and double click it to make a call out, or you can press ‘C’ key or click ‘Call’ button to do that.
If you want to send instant messages, you can select the target user and press ‘M’ key or click the ‘Message’ button, then you will get instant messages’ windows:
One instant message window is used for one user. Each window has three areas: (1) Display area. It displays both incoming messages and outgoing messages. (2) Input area. You can input the instant message content here, and press ‘Ctrl+Enter’ keys to send the message out. (3) ‘Send’ button. Click it to send the message out.
At this time, miniSIPPhone uses SIP-MESSAGE to send and receive instant messages, and can only support plain text messages, so you cannot insert images, files, audios and videos into the messages.
Of course, miniSIPPhone can run on Windows system and Linux system (including AMD64 and ARM64). In fact, the users in above figure run miniSIPPhone on different systems.
We got a news that shype will be retired on May 5, 2025, so we have to say goodbye to skype. If you want to contact us, please refer to the online contact page to get details.
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.
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:
