kamailio-ims Since release 4.0.0 Kamailio has incorporated support for basic IP Multimedia Subsystem – IMS – functionality – but what does this mean? This article aims to describe IMS as well as the history and current state of the IMS functionality in Kamailio 4.0.

The IP Multimedia Subsystem (IMS) was first introduced by 3GPP in 2005 and has since become the de facto standard for supporting voice and other multimedia services over LTE and other IP networks in an efficient, secure, reliable and billable manner. It bridges the gap between reliable circuit switched voice services and efficient IP technologies – and enables opportunities for the creation of advanced multimedia services and 3rd party applications. While IMS has been discussed widely outside service provider networks, it is still growing and is the focus of a migration away from old technologies in the carrier space.

Standard SIP with a set of SIP extensions

At its core IMS uses the Session Initiation Protocol (SIP) for session management, though many compulsory SIP extensions are required to ensure security and reliability. This session management is implemented in three Call Session Control Functions (CSCF)

the Proxy-CSCF
the Interrogating-CSCF and
the Serving-CSCF

An Emergency-CSCF is also required but is not currently supported in Kamailio IMS, see “Future work” below.

The CSCFs interact with a number of different elements

a Home Subscriber Server (HSS) for authentication
a Policy and Charging Rules Function (PCRF) for network authorization and policy control
an Online Charging Server (OCS)
an Offline Charging Server (OFCS) for charging

These interactions are facilitated by the Diameter protocol; Diameter is a flexible protocol based on Attribute Value Pairs (AVP) – applications ranging from authentication, authorization and charging can be built by extending the base protocol.

IMS is based on Open Standards – SIP and Diameter

As all components are based on open-standards, such as Diameter and SIP, it makes it fairly easy to use various components from different vendors. You may use Kamailio as your IMS-Core, you could use an Acme-Packet SBC as your Proxy-CSCF, you could use your own HSS for Subscriber Management and finally you might use a Ericsson Charging Server (if jBilling doesn’t provide enough features) to put a price on the services provided by your Application-Servers from Atos. This possibility of various combinations is one of the major benefits from an IMS-Architecture.

IMS is also intended to facilitate advanced multimedia services – this functionality is implemented in SIP Application Servers (AS) that host services. These SIP AS are selectively invoked by the CSCFs through the IMS Service Control (ISC) interface based on subscriber specific initial filter criteria.

The roots of this implementation: OpenIMScore.org

In 2006 Fraunhofer FOKUS released the Open Source IMS Core (http://www.openimscore.org/). This is an open source implementation of the CSCFs and a lightweight HSS, including an IMS Service Control (ISC) interface for advanced service creation. This project was a complete game changer that took what was previously only IMS theory and put it in the hands of academia and industry in the form of a practically implementable testbed.

Since 2006 IMS has come a long way as a technology and is being implemented in live networks the world over. There has also been much development and consolidation in the open source SIP space. Kamailio provides a rock solid SIP server conforming to the latest standards, capable of handling thousands of call setups per second and suitable for live network deployments. The Fraunhofer FOKUS OSIMS project created a branch of the then SIP Express Router project to implement the necessary IMS extensions, and has subsequently not kept abreast of the Kamailio advancements.

Thus was born the requirement to port and extend the IMS functionality, that was started by the FOKUS OSIMS project, to the latest Kamailio core. The first iteration of this is the set of IMS modules present in Kamailio 4.0.0.

Kamailio IMS capabilities

The Kamailio IMS extensions provide the full functionality of the P-CSCF, I-CSCF and S-CSCF. External functionality such as UE, PCRF, HSS, OCS and OFCS are not included. A Kamailio SIP Server could be used as an example SIP AS.

Typical IMS functionality that is now possible include:

Full IMS authentication over the Cx and Dx Diameter interfaces with a 3rd party HSS
Optional registration to the status of the signalling bearer – this happens at the P-CSCF over the Rx interface to a 3rd party PCRF
Full IMS session setup signalling with IMS routing through the CSCFs
Optional resource authorization for IMS sessions in the transport plane – this happens at the P-CSCF over the Rx Diameter interface to a 3rd part PCRF (NOTE This is still being fine tuned and will be included in the master branch soon)
Optional online charging authorisation for IMS sessions – this happens at the S-CSCF over the Ro Diameter interface to a 3rd party OCS (NOTE This is still being fine tuned and will be included in the master branch soon)
Advanced service creation by selectively invoking 3rd party SIP ASs – this requires a 3rd party HSS to provide subscriber specific filter criteria to select the relevant SIP AS, this interaction happens between the S-CSCF and SIP-AS over the ISC interface.

Kamailio IMS Module overview

There are a total of 9 IMS specific modules that implement this new functionality.

ims_auth: This module is is used for authentication in IMS. In IMS, the S-CSCF is merely the “middle-man” between the UE and the HSS. It communicates via the Cx interface to the HSS to retrieve subscribers’ authentication vectors. Currently the module supports MD5 and AKAv1/2 auth schemes. Of course, it will also depend on what auth schemes your HSS supports.
ims_isc:This module implements the IMS Service Control interface between the S-CSCF and SIP AS. It does the logic required at the S-CSCF to determine which SIP AS to invoke and when, based on subscriber specific initial filter criteria
ims_icscf: This module implements the functions required to build an IMS I-CSCF. It is triggered from the config file and can query a 3rd party HSS to find the relevant S-CSCF for a request.
ims_qos: This module implements the resource authorization functionality between P-CSCF and 3rd party PCRF. The config file triggers the P-CSCF to send Diameter authorisation requests to the PCRF. CDP, Dialog and Usrloc callbacks are used to signal when a dialog has ended, Diameter session has ended or user has de-registered.
ims_registrar_pcscf: This module simply implements the REGISTER processing logic for the REGISTER messages in a P-CSCF configuration.
ims_registrar_scscf: This module simply implements the REGISTER processing logic for the REGISTER messages in a S-CSCF configuration.
ims_usrloc_pcscf: This module is the IMS equivalent of the stock kamailio usrloc module. It stores IMS subscriber information at the P-CSCF. This module is required because at the P-CSCF a subscriber can be in many different states (not registered, registered, de-registered – yes these are all different 😉 ). Also, there is very different meta data for a subscriber compared to standard SIP, for example, IPSec information, Diameter Rx session information, multiple public identities (IMPU) per contact, etc.
ims_usrloc_scscf: Similar to ims_usrloc_pcscf module, this module serves as the subscriber storage module for IMS subscribers at the S-CSCF. This storage includes for example the IMS Subscription downloaded from the HSS for each subscriber, the charging function addresses, etc.
ims_ro_interface: This module implements an online charging mechanism using the IMS Diameter Ro interface. The Ro interface is meant to be used in a Kamailio S-CSCF configuration and linked to an Online Charging System (OCS). Currently, the module is purely time-based (ie, the unit charge and reservations are in seconds) and uses the Session-Charging-with-Unit-Reservation (SCUR) algorithm (see RFC 4006). The module depends on the dialog_ng module for tracking the “dialogs” to be charged, as well as tearing dialogs down once credit has been exhausted.
NOTE This is still being fine tuned and will be included in the master branch soon.

The IMS Diameter interfaces utilise the suspend functionality of the TM module – this allows a SIP request or response to trigger a Diameter request to be sent and then suspend the transaction, free-ing the process to continue with other work. When the Diameter response is received the transaction can be resumed on a different process. This asynchronous implementation has significant performance advantages over the FOKUS OSIMS synchronous implementation.

NOTE This functionality currently on exists for SIP requests, we are fine tuning this behaviour for SIP responses and it will be included in the master branch soon, to be part of Kamailio 4.1.0.

How to get started

Getting started is easy! Tweak the example P-CSCF, S-CSCF and I-CSCF Kamailio and Diameter config files in the examples folder to suit your environment and run Kamailio as normal. If you want to include optional functionality like resource authorisation or charging this can be enabled in each config file by uncommenting the relevant hash defines and tweaking Diameter config files.

Future work

The work is far from complete:

We are currently fine tuning resource authorisation for IMS sessions over the Rx Diameter interface and online charging over the Ro Diameter interface.
We are currently fine tuning the TM suspend functionality to work on SIP responses as well as SIP requests.
We need to implement IPSec on the Gm interface between the UE and P-CSCF. There is an existing module for this in the Fokus OSIMS project that can be used as a starting point.
An E-CSCF is required for emergency services – this needs to be implemented for a carrier grade telecommunications service.
Kamailio can be used as a SIP AS in the IMS architecture – future work needs to integrate existing Kamailio work on XDM and RCS with this IMS architecture.

All contributions are welcome and appreciated!

This article was written by Jason Penton, Richard Good and Carsten Bock. Jason and Richard work with Smile Telecoms in South Africa. Carsten Bock is the founder of NG Voice GMBH in Hamburg, Germany. All of them contribute to the IMS implementation in Kamailio, as well as other parts of Kamailio that needs to change to fulfill their needs. If you have questions, please use the sr-users mailing list!

What is the IP Multimedia Subsystem (IMS) in Kamailio 4.0?