Browsed by
Tag: IMS

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.

Final V31

Final V31

We released the final V31, that means we will be focus on next very important version V32 which will be our next LTS version to replace V24.

In fact, lots of features have been merged into the latest V31, and we will stay with V31 for several months since it is the base line of V32.  Please refer to following sections for more details about the key points.

Tools upgraded

In Windows platforms, we upgrade several important tools for V31.  The VC++ is upgraded to VC2010, so new MSS is using VC2010 run-time libraries. It could be powerful and better than previous VC2008 which has several manifest problems in customers’ environments.

The basic SSL library is migrated from OpenSSL to LibreSSL in MSS for windows. In Linux system, we still keep OpenSSL at this time and will move to LibreSSL in future. LibreSSL provides official windows library and we think it is optimized to be better than OpenSSL. If you are deploying “SIP over TLS”, this modification could be much better and safer then previous versions.

SIP stack upgraded

In recent days, we work with several customers to process scenarios with different IMS networks. We have to say we met several strange and very old SIP call flows. That’s ok, V31 is refined to fit these requirements.

“18X with/without SDP” flows are supported. “18X” means 180 or 183, so you can see several possibilities, such as “180 with SDP”, “180 without SDP”, “183 with SDP”, “183 without SDP”, and so on, and their orders are different. Sometimes we receive 180 firstly, sometimes we receive 183 firstly. In most scenarios, these messages are used to play different ring-back tone, so it is not only something with SIP stack but also something with media connections which means MSS inner MG module is upgraded too.

Another key point is SIP-UPDATE. Some IMS networks don’t use 18x to bring ring-back tone media information, they use SIP-UPDATE messages.  In another IMS network, we find it use “SIP-UPDATE without SDP” to keep alive in dialog. It is an interesting topic and we hope to write another blog to describe these scenarios carefully. Anyway, V31 is upgraded to support part of SIP-UPDATE to work with such IMS networks. We don’t implement all features about SIP-UPDATE and MSS will not invoke SIP-UPDATE flow by itself. If MSS wants to change media, it always invokes reINVITE procedures.

“tel” number format is supported in V31. Traditional soft-switch networks could transfer this format to MSS when they work with PSTN networks. We don’t understand why these soft-switch don’t convert it to SIP URL. Now V31 can accept that. Of course, MSS will never send out such number format.

Work with Chinese CTC IMS network

Work with Chinese CTC IMS network

Yesterday, we helped a Chinese customer to deploy MSS to work with CTC IMS network. In this scenario, CTC IMS network has ZTE soft-switch (according to User-Agent header in SIP messages) , we need be careful to cooperate with it.

Since CTC provides user name and password for authorization, we configure “external line” in MSS to do that. Following sections will illustrate some key points.

Authorization user name

By default, we often use “External line (account)” as authorization user name, but ZTE softswitch requires full URI format, so we need configure “The authorization ID should include address information” in external line. Please refer to following figure for more details.

Authorization user name
Authorization user name

For example, if this item is selected, the authorization name will be “+8612345678@gd.ctcims.cn” according to above figure.

If it is not full format, IMS network will return “403 Forbidden” messages to reject it. In fact, we think it is a bug in ZTE softswitch since there is “realm” and “domain” parameters in SIP authorization header. No matter the user name is full format or not, the device should pass it according to successful authorization itself.

Anyway, if you have same problem to cooperate with other IMS networks, please pay attention to it and configure such item to take a try.

Proxy

In Chinese CTC-IMS network, its “SIP server” is logic domain, not a real SIP device and cannot be visited. In above scenario, “gd.ctcims.cn” is its domain, not its real address. SIP messages should be routed to another device (we think it is a SBC or proxy), so we need configure “Via” address in MSS external line configuration. Please refer to following figure.

SIP proxy in IMS
SIP proxy in IMS

RFC3262

RFC3262

RFC3262 defines a method to provide reliable provisional response messages in SIP dialog. Simply, it uses a new message which is PRACK to response “response” messages. We don’t think it is a good idea, and most traditional VoIP devices don’t following this RFC document.

But now in some interoperability scenarios with the PSTN, it is required to provide RFC3262 capability. Specially in some 4G-IMS networks, for example, in China telcom markets, mobile carriers’ networks will reject SIP calls if they don’t have this capablity.

So we upgrade MSS to V31 to support RFC3262. New MSS will add ‘100rel’ in outgoing calls to update peer sides or SIP phones that it has RFC3262 capability, they can decide to invoke it by themselves. For incoming calls, MSS will not invoke RFC3262 procedures automatically unless peer sides or SIP phones require that.

If you have problem to work MSS with your local ISP networks, please try the latest MSS and hope you can enjoy it.