Browsed by
Category: miniSipServer Cloud

PBX in cloud for small business

Optimize the “hunting-group” service

Optimize the “hunting-group” service

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:

Operators configuration

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.

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
Upload IVR-XML and audio files

Upload IVR-XML and audio files

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.

Of course, the IVR-XML file should follow the IVR-XML specification and audio files should fit the miniSIPServer requirements.

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.

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"

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.

New web UI for miniSIPServer

New web UI for miniSIPServer

We upgrade web UI for miniSIPServer, including cloud miniSIPServer and local miniSIPServer. The new web UI is quite like GUI of local miniSIPServer. Please refer to the figure below.

We hope users who are familiar with local miniSIPServers can enjoy it and experience the cloud miniSIPServer system quickly.

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