Browsed by
Category: Docs & FAQ

MyVoipApp documents and FAQ

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"

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.

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

Reliability of Provisional Responses

Reliability of Provisional Responses

As we know, RFC3262 defines SIP reliability of provisional responses. It is an old feature and miniSIPServer ( both local versions and cloud versions) can support it for a long time. When working with traditional telcom carriers, this feature is mandatory, that means carriers will reject all incoming calls if they cannot support reliability of provisional responses.

RFC3262 defines a “100rel” parameter to indicate reliability of provisional responses, so we call it “100rel” capability. In normal, when invoking a call, the caller should make itself clearly that it can support “100rel” capability, and of course, the callee side should also make itself clearly that it requires to use “100rel” capability.

Basic call flow with 100rel
Basic call flow with 100rel

In the RFC3262, we can get following details:

…… the initial request contained a Supported or Require header field listing 100rel, and that there is a provisional response to be sent reliably. ……

UAS core … MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field.

Then both sides can establish reliability of provisional responses. Above figure describes the basic call flow. When UAC receives a 18x message which is a provisional response, UAC should send a PRACK message back to tell UAS that UAC has received its 18x message.

This is not a complex call procedure. We thought it wasn’t until several days ago. One of our cloud miniSIPServer customers reported he cannot make calls out. Then we traced his calls and get following call flow described below.

405 error in a 100rel procedure
405 error in a 100rel procedure

Unbelievable …… this voip provider requires “100rel” in its 183 messages, but once miniSIPServer sends PRACK messages to confirm that, it returns “405 method not allowed” to reject them, and it causes every call failed.

Why?! If it cannot accept or support PRACK messages, why does it require “100rel” in its provisional responses?

It is quite easy to fix that. Just remove its “require 100rel” from 18x messages, miniSIPServer will not send PRACK messages back. But unfortunately, the team of this voip provider doesn’t know how to do that.

Our customer is blocked and his service has to be stopped. In another way, I personally think some VoIP providers use public open source servers, such as Asterisk, FreeSwitch, and so on, to build their solutions, maybe they don’t have enough experts to understand what they built.

So we update miniSIPServer to add an option in external lines configuration to disable reliability of provisional responses. Please refer to the figure below.

Disable 100rel capability
disable reliability of provisional responses

If you check this item, the INVITE messages sent from miniSIPServer will not have “support 100rel” parameter. Once you meet such a ridiculous VoIP provider, you can try this.

Gnome Calls

Gnome Calls

As we know, miniSIPServer can run on Linux systems. Sometimes customers ask us about SIP clients which can run on Linux systems at the same time. In fact, there are lots of choices, such as linphone, jami, and so on.

Recently there is a new SIP client released. Most important, it is a core application in Gnome project. It is “Calls”. In Debian library, its definition is “Make and receive PSTN phone calls”. In fact, the latest version can support SIP protocol. In the Gnome project, we can see the description is changed to “Make phone and SIP calls”.

It is quite easy to install “Calls”. Just input following command:

sudo apt install gnome-calls

Please refer to the figure below for more details about its main window.

Gnome calls main window
Gnome calls main window

Click menu “VoIP Accounts” to add a new SIP account. Most items are same with other SIP clients. For example, miniSIPServer is at “192.168.3.42” and the account is “100”. Please refer to the figure below.

Configure VoIP account in Calls
Configure an account

Please pay attention that (1) the default port is 0, we need to change it to 5060; (2) we need to enable the account. Calls doesn’t display its status, so we can check miniSIPServer local users’ window to check their status.

When making outgoing calls, we can dial the target number in the “Dial Pad” panel directly.

make outgoing calls
Make a call out

If there is an incoming call, just answer or reject the call.

Incoming calls
Incoming call

Obviously “Gnome Calls” is very simple at this time and it will be developed with more functions. If we are deploying a simple VoIP network and hope to build all elements on Linux, it could be a good choice.

Hope you can enjoy it.

miniSIPServer on Ubuntu 22.04

miniSIPServer on Ubuntu 22.04

Ubuntu 22.04 (Jammy Jellyfish) is the latest LTS (long tem support) version, so it is quite important for miniSIPServer to support this version.

We try to install and run miniSIPServer on Ubuntu 22.04, it is very easy! And we are very glad that it is perfect to run miniSIPServer on it. Please refer to the figure below.

miniSIPServer on Ubuntu 22.04
miniSIPServer on Ubuntu 22.04

If you are going to deploy a new VoIP network, it could be a good choice to run miniSIPServer on Ubuntu 22.04.

Run miniSIPServer on Debian 11 (Bullseye)

Run miniSIPServer on Debian 11 (Bullseye)

Debian 11 (Bullseys) was released at August 14th, 2021. It is the latest stable version and very important for business deployment. So we run miniSIPServer on this system and make some tests. The result is perfect!

It is no problem to run miniSIPServer on Debian 11. You can refer to online document for more details about how to run miniSIPServer on Linux systems.

run miniSIPServer on Debian 11
run miniSIPServer on Debian 11
Monitor events in IVR call flow

Monitor events in IVR call flow

In miniSIPServer, we can use IVR-XML script to enable our own services, such as automatic-attendant. With previous IVR-XML set, ‘callto’ action will invoke a call to destination and finish the whole IVR process.

But if we want to monitor some events in the call flow, such as we want to check ‘busy’ event and change the IVR flow to a new action, what should we do?

Now V37 is released and a key feature is updated in IVR-XML. We can use ‘monitor-events’ in ‘callto’ action to monitor some events and change the call flow if they are caused.

For example, the ‘callto’ action can be configured as below.

<action method="callto" name="mainAction">
    <destination>100<destination>
    <monitor-events>
        <monitor-event detection="busy" nextaction="callto101"/>
    </monitor-events>
</action>

In this example, if the call invoked by ‘callto’ action is busy, IVR procedure will be changed to next action ‘callto101’.

Please refer to IVR-XML document for more details about “monitor-events” element.

Above zip file is an example of new ‘callto’ action. You can save and unzip it into ‘xml’ sub-directory where miniSIPServer is installed and configure a new record to test it.

Configure miniSIPServer to trigger IVR-XML
Configure miniSIPServer to trigger IVR-XML
T-MSS and L-MSS

T-MSS and L-MSS

Some customers deploy several miniSIPServer nodes to build their unified VoIP network around the world.

We give a simple document to describe this network and its configuration. There are two important concepts: T-MSS and L-MSS.

L-MSS means “Local miniSIPServer” which are deployed in local branches or offices to service their local SIP phones or gateways.

T-MSS means “Trunk miniSIPServer” which is used to bridge all L-MSS servers.

Please click here to get more details.