SIP-I and SIP with OpenSIPS 2.3

SIP-I considerations

The SS7 interconnections are always painful. Both as cost and technical difficulty/complexity. So, as a more accessible alternative, the carriers started to offer SIP interconnection via SIP-I (SIP Infrastructure). SIP-I  or SIP Infrastructure (define by ITU) is very similar to SIP-T or SIP for Telephones (defined by IEFT).

SIP-I is very powerful when it comes to SIP interconnection as:

• it is SIP based, so simple to deal with (comparing to SS7, of course 🙂 )
• it exposes SS7 specific data via the ISUP payload

So SIP-I is ideal for trunking/wholesale providers who just exchange traffic. Still, SIP-I is not suitable when reaching the final SIP end-point as most of such devices/applications cannot cope/understand with the ISUP payload. So, if you are a VoIP/SIP provider having a SIP-I trunk from a carrier, you cannot simply push the incoming call from the trunk directly to the end-point. You should covert the SIP-I to SIP (or gatewaying) !!

SIP-I scenarios

From the perspective of a SIP provider, there are two major scenarios where SIP-I is present:

• traffic exchange (wholesale), where you eventually need to look inside the ISUP payload in order to take routing decisions (based on caller/callee info, CLI management, billing information and many other important data coming from SS7 layer); sometimes, you may also need to change the ISUP part;
• end-user services, where calls from or to end-users may be shoveled to carriers via SIP-I interconnection trunks; and in such cases the carrier speaks SIP-I, while the  end-user speaks SIP; so you need to act as SIP-I to SIP gateway.

OpenSIPS and SIP-I

With the upcoming 2.3 release, OpenSIPS has a new “sip_i” module that provides a powerful SIP-I support able to:

• read and change the ISUP payload – using variables from script level, you can access any ISUP header (or sub-header) by simply using its name (according to the ITU specifications on ISUP):

## Test or change the caller privacy status

if ( $isup_param(Calling Party Number | Address presentation restricted indicator) == “restricted” ) {….}

$isup_param(Calling Party Number | Address presentation restricted indicator) = “allowed”;

• perform gatewaying between SIP and SIP-I – SIP traffic can be easily converted to SIP-I (and vice-versa) at the script level by using functions to add or remove ISUP payloads to the SIP messages; the module encapsulates some default logic (according to the ITU specifications) on building the ISUP packets, still OpenSIPS gives you the flexibility to customize (as values) the ISUP content using the script variable. Even if you are not an ISUP guru, it is trivial to script the SIP-I to SIP conversion.

Remarks

The SIP-I module combines simple usage with great achievements. The ability to handle and covert the SIP-I traffic comes with big benefits such as cost and capabilities. And SIP-I becomes more and more popular as a trunking option with the carrier.

The development of this module was promoted and sponsored by SIPPulse  – many thanks here to Flavio Goncalves for supporting the OpenSIPS project !

Also, even if a standard, there are many flavors of SIP-I when it comes to ISUP content and how it should be translated to SIP. Any testing and feedback will be greatly appreciated – it will help us make this module more flexible and powerful.

Do you have a SIP-I trunk and are you interested to run some tests with us ?