SIP server for windows and Ubuntu system
Please refer to following compose configuration:
Please pay attention to the items hostname and mac_address. You can set these items with values you want, but they must be fixed since miniSIPServer will use them to bind the license key.
The newly released miniSIPServer (V70 build 20250402) supports an interesting feature: you can use a WebRTC-compatible browser (such as Chrome, Firefox, etc.) to make calls through miniSIPServer to devices within the SIP domain, including IP phones, gateways and other endpoints. The network topology is shown in the figure below:
The audio stream is transmitted via DTLS-SRTP with end-to-end encryption and interconnected with miniSIPServer. Currently, only voice calls are supported; video calls are not available.
The web side adopts a simplified signaling protocol (MCCP, miniSIPServer Call Control Protocol) for call control, and interconnects with miniSIPServer via encrypted WebSocket connections (WSS, WebSocket Secure). Currently, only calls initiated from the Web domain to the SIP domain are supported; reverse calls from the SIP domain to the Web domain are not available.
Simply enter the following URL in the browser to initiate a call to the SIP domain (for example, extension 100 calling extension 101):
https://www.myvoipapp.com/miniwebphone2/lite.html?server=192.168.3.70&clr=100&pwd=100&cld=101
The URL adopts a command-line-like format, with each parameter explained as follows:
https://www.myvoipapp.com/miniwebphone2/lite.html is a simple webpage. After being loaded in a browser, it can establish a WSS connection with the specified miniSIPServer server and initiate calls. You may download this webpage along with its related resources to your local device or a local web server; calls can also be initiated normally by opening the local file in a browser.server specifies the address of the miniSIPServer. The miniSIPServer must have successfully loaded the certificate and private key, and enabled the WSS service. By default, miniSIPServer always runs the WSS service on TCP port 5062.clr specifies the caller number for initiating a call. This number must be a valid extension number assigned on miniSIPServer.pwd stands for the authentication password of the caller, which is the password configured for the corresponding extension in miniSIPServer. miniSIPServer authenticates calls by verifying the combination of caller number and password. Only authenticated calls are allowed to connect; otherwise, the call will be rejected directly by miniSIPServer.cld indicates the called number, which can be a local extension number or an outbound dialing number.The audio stream is transmitted over DTLS-SRTP with end-to-end negotiation and encryption, requiring no additional configuration on miniSIPServer.
To enable the WSS service and accept MCCP call messages from browsers, miniSIPServer only requires configuration of certificate and private key.
miniSIPServer has the following requirements: (1) Certificates and private keys must be stored in the wrtcCert subdirectory under the application data directory; (2) Files must be in PEM format; (3) The certificate must be named server.crt and the private key must be named server.key. For example, on Linux systems, these two files should be located as follows:
$HOME/.minisipserver/wrtcCert/server.crt
$HOME/.minisipserver/wrtcCert/server.key
If the certificate and private key are loaded successfully, miniSIPServer will start the WSS service and prompt the following message:
If using a self-signed certificate, be sure to allow the self-signed certificate to be loaded in browsers such as Chrome and Firefox.
In the field of SIP communication, there are two types of keep-alive mechanisms: device-level keep-alive and session (dialog) keep-alive.
Device-level keep-alive currently has mature and unified solutions that comply with RFC 3261, namely detection using the OPTIONS method. If the peer device returns a 200 OK response, the device is considered alive. Terminals can also detect device-level keep-alive using REGISTER requests.
Manufacturers have never had a unified solution for session keep-alive. Although RFC 4028 defines reINVITE and UPDATE for session keep-alive detection, these two operations are too complex for such purpose. They can trigger media renegotiation, which impairs call quality.
At present, manufacturers share basically the same idea: since normal reINVITE and UPDATE operations will trigger new media negotiation, can we use them without SDP directly for session keep-alive? reINVITE is an exception: reINVITE without SDP has already been used in the 3PCC procedure, so it can no longer be used for session keep-alive.
Based on our experience in interconnecting with equipment from various manufacturers over the years, we summarize the following operations for session keep-alive:
Default behavior of the latest version of miniSIPServer:
If the above three types of SIP messages are received during a session, the server will enter the session keep-alive processing flow. If the session exists, a 200 OK response will be returned.
UPDATE and INFO can only be transmitted within a session by nature, so they inherently meet the requirements of keep-alive. We recommend using INFO first, as it is explicitly defined in RFC3261 and will definitely be supported by all manufacturers’ equipment. In contrast, the UPDATE method is defined in a supplementary specification. Some manufacturers’ equipment may not support UPDATE, let alone UPDATE without SDP.
MESSAGE can be transmitted both within a session and outside a session, and is used to deliver instant messages. We restrict MESSAGE without SDP to be transmitted only within a session and reserve it for the session keep-alive process.
In previous versions of miniSIPServer, in order to enable “SIP over TLS”, it was necessary to configure certificate and key files (including self-signed certificates and keys). If these files were not present in the configuration directory, miniSIPServer would not enable SIP over TLS by default.
Most customers deploy “SIP over TLS” using self-signed certificates and keys. Linux systems come with the openssl tool built-in, making it very easy and convenient to create these files. However, Windows systems do not have the openssl tool by default, requiring customers to download the tool to create certificates and keys, which is slightly more troublesome.
To reduce the workload for our customers, we have streamlined the steps for enabling “SIP over TLS” in miniSIPServer:
miniSIPServer now enables “SIP over TLS” by default. If certificate and key files are configured, it uses the customer’s provided certificates and keys to encrypt SIP messages. If no certificate or key files are configured, miniSIPServer automatically creates a self-signed certificate and key to encrypt SIP.
Therefore, when miniSIPServer starts, we can see the TLS port information, indicating that “SIP over TLS” has been enabled.
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 or DTLS-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). miniSIPServer can also support RFC5763 which is the basic protocol for DTLS-SRTP. (At present, some SIP clients don’t support DTLS-SRTP, so if you want to deploy that, please check their capabilities carefully.)
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:
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.
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.
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.