IMS SIP CORE SERVER TEST BED

Mr. Birender Panwar Mobile solution group-2, IMS

LG Soft India, Bangalore, India birender.panwar@lgsoftindia.com

Mr. Keval Singh Mobile Solution Group-2, IMS LG Soft India, Bangalore, India keval.singh@lgsoftindia.com

Abstract—During IMS Client development, it is continuous

requirement that IMS test bed should be available to facilitate the IMS client development. IMS test bed need to be exact replica of real IMS network with reference to IMS Client so that IMS

Client should face minimum interoperability issues with the real IMS network. This article presents the IMS SIP Core Server test bed architecture, minimum server component required and

implementation challenges with their mitigation. This article helps in developing IMS SIP Core test bed in such a fashion that it simulate the real IMS Network for the IMS Client and IMS

Client can test all the services functionalities.

I. INTRODUCTION

IMS Core Network consist of various entities like P-CSCF,

I-CSCF, S-CSCF, MRFP, MRFC, and HSS and protocol used

are SIP, RTP/RTCP, H.248 and Diameter

For Testing of IMS Services like VoIMS, Image Share,

Video Share and Video-Telephony which are UE to UE

services. The following IMS-Components like I-CSCF,

MRFC, MRFP are not required in the test bed and can be

ignore.

II. TEST BED ARCHITECTURE

Figure 1. Test bed architecture

This section covers the minimum interface and component

required for the test bed.

A. Interfaces

1) Gm Interface: This is interface between UE and P-

CSCF and it makes use of SIP protocol. [1]

2) Mw Interface: This is the interface between P-CSCF

and S-CSCF and it make use of SIP protocol.1]

3) ISC Interface: This is the interface between S-CSCF

and SIP AS and it makes use of SIP protocol [1]

4) Cx Interface: This is the interface between S-CSCF and

HSS. This interface is used to send subscriber data to S-CSCF.

It makes use of Diameter protocol. For test bed this interface

can be replace with proprietary interface implementation for

simplicity [1]

B. Test-Bed Components

Following are the minimum components required for the

SIP Core test bed.

1) P-CSCF: P-CSCF is the entry point to the IMS-

Network for all IMS Client [4]. Hence P-CSCF component is

mandatory for the test-bed.

• Registration Support

• SigComp support

P-CSCF support SIP message compression and de-

compression at Gm interface.

• IPSec Support

Maintain Security Association between UE and P-CSCF

• P-CSCF-subscription for “reg” event to S-CSCF for User Registration status

P-CSCF subscribe for “reg” event to S-CSCF for getting

Notification whenever user registration status is changed.

• Stateful SIP Proxy.

P-CSCF should forward all SIP Request and Response

messages from UE to SCSCF and vice versa.

Below table shows the handling of 3GPP Private headers at P-CSCF.

TABLE I. SIP HEADERS (P-CSCF)

SIP headers Description

P-Access-Network-Info Header received in REGISTER request from UE. No need to process this header

P-Visited-Network-ID P-CSCF no need to add this header

P-Charging-Vector P-CSCF no need to add this header

P-Preferred-Identity This header is received in all request

messages from UE except REGISTER. It contains the registered public identity

of the UE. P-CSCF remove this header

before forwarding it to S-CSCF

P-Asserted-Identity P-CSCF adds this header before

forwarding the request to S-CSCF. It contain registered public identity

P-Associated-URI This is received in 200 OK of

REGISTER message from S-CSCF. It contain list of all associated public user

uri for the registered private user identity

Security-Client P-CSCF needs to process this header if

IPSec is supported. Otherwise P-CSCF can ignore it and removed it before

forwarding REGISTER request to S-

CSCF

Security-Verify P-CSCF needs to process this header if

IPSec is supported. Otherwise P-CSCF

can ignore it and removed it before forwarding request to S-CSCF

Security-Server P-CSCF needs to add this header in 401

response to REGISTER message if

IPSec is supported. before forwarding it to UE. It contains P-CSCF supported

and negotiated IPSec parameters. IF

IPSec is not supported then no need to add this header.

Path P-CSCF adds this header before

forwarding REGISTER request to S-CSCF. It contains P-CSCF address to

inform S-CSCF where to route the

terminating request

Service-route P-CSCF need to process this header and

need to maintain the S-CSCF address

contained in the header.

2) S-CSCF: S-CSCF is the main part of IMS-Core

Network and performs session control services for UE. It

provides Registration and Filter Criteria services for access to

Application Servers [2] and hence the important part of the

test bed. It supports the following features:

• Acts as Registrar for IMS-Client

• Implicit Registration: Registration of multiple public identities using single registration procedure [2]

• Registration Fetch: Sending of Sip REGISTER request without the “Contact” header to S-CSCF for getting list of already registered contact addresses.

• AKA Support for IPSec

• Interact with HSS for User Data

• Initial filter Criteria : Originating and Termination filter Criteria

• UE and P-CSCF Subscription for “reg” event

• SIP Stateful Proxy

Below table shows the handling of 3GPP Private headers at

S-CSCF.

TABLE II. SIP HEADERS (S-CSCF)

SIP headers Description

P-Access-Network-Info S-CSCF no need to process this header

P-Visited-Network-ID S-CSCF no need to process this header

P-Charging-Vector S-CSCF no need to process this header

P-Asserted-Identity S-CSCF extracts public identity from

this header. S-CSCF allows the Request

only when the uri in this header is registered with the S-CSCF.

P-Associated-URI S-CSCF inserts this header and it

contains list of all implicit registered

public identities.

Path S-CSCF stores the content of path

header and uses this address for routing

the terminating request. This header contains P-CSCF address.

Service-Route The S-CSCF inserts the Service-Route

header that includes its own URI

including a character string in the user part to differentiate mobile originating

requests from mobile terminating

requests.

3) HSS: HSS contains the User related information like

Server Profile, User Authentication Data and Service Filter

Criteria. S-CSCF Interact with HSS using Diameter Protocol

[4]. For test Bed Interaction between S-CSCF and HSS can be

replace with Simple Proprietary Protocol. Following minimal data should be maintained in database

• User Authentication related data, User Service Profile, User Registration status.

• Filter-Criteria for all services

• IMS-Core Entities and Application-Server transport information

4) GUI: GUI Component required for server provisioning.

Following features are required

• Creation of HSS-User Profile

• Creation of Initial filter criteria

• Server transport addresses. It includes Sip Core transport address and AS transport addresses.

For each IMS Server entity, dedicated port is assigned and

which can be configured from GUI:

• Dedicated P-CSCF Port: UE and S-CSCF can interact with P-CSCF using this port

• Dedicated S-CSCF Port:

o S-CSCF SIP Port: P-CSCF and AS can interact with S-CSCF using this port

o S-CSCF HSS Port (TCP): HSS can interact with S-CSCF using this port

• Dedicated HSS Port (TCP): S-CSCF can interact with HSS using this port

Following server parameters provisioning is required for the

test bed

• HSS user profile

o creation, deletion, modification of user profile

o User Authentication data configuration

o Enabling of Services for the user

• IMS-SIP Core configuration: P-CSCF and S-CSCF transport configuration.

• Application Server transport Configuration

• Filter Criteria for each services

• Feature supported :: SigComp or/and IPSec Support

• IPSec Configuration :: Integrity Algorithms, Encryption Algorithms, Secure UAC and UAS Ports

III. IMS SERVICES

IMS services are broadly categories into three parts:

A. IMS-Core Services

These are UE to UE services through IMS-core and AS is

not required for these services. IMS-Core Services are

VoIMS, Image share and Video Share.

B. AS Services

These are UE to AS services and it required application

server. For Ex. Services like Presence, PoC, PTD and Instant

Messaging fall under this category.

C. AS 2 AS Services

These are Server to Server services. For example Presence

Services which required RLS to PS, RLS to RLS-XDMS, RLS

to Shared-XDMS, PS to PS-XDMS, PS-to Shared-XDMS

interaction.

IV. ADDITIONAL FEATURE SUPPORT

A. SigComp Support

It’s always a need to maximize the transport efficiency of

data over the network and also network must be carefully used

as there is a limitation in the per user bandwidth. Compression

of the messages from signaling protocols, such as SIP/SDP,

help in efficient use of the NW bandwidth. SigComp protocol

is used for compression and decompression of SIP message

[7].

Comp=sigcomp parameter in Contact header of REGISTER

message from UE indicated the SigComp support at UE side.

Compression can be either in one direction or both.

Comp=sigcomp parameters in Via header of SIP request

message from UE to P-CSCF indicate that response to UE

should be sent compressed [3].

Request to terminating UE from P-CSCF should be sent

compressed if User had mentioned comp=sigcomp parameter

in the contact header of REGISTER message during

registration procedure [3].

B. IPSec Support

P-CSCF required support of ipsec-3gpp security mechanism

so that IMS-Client can securely communicate with the P-

CSCF [3]. AKA procedure is used for Security key generation

during registration procedure.

Table below represent the security features for IPSec [5]

TABLE III. SECURITY FEATURES

Sl.No Features Description

1. Security

Mechanism

Ipsec-3gpp

Security mechanism and security

association parameters are negotiated during SIP Registration

using SIP Security header and

security key is known using AKAv2 Authentication procedure.

2. SIP-Headers Security-Client, Security-Server,

Security-Verify, Require and

Proxy-Require

3. Integrity/Authenti

cation algorithm

HMAC-MD5-96 and HMAC-

SHA1-96

4. Encryption

Algorithms

DES-EDE3-CBC (mean 3DES in

CBC Mode) AES-CBC and NULL.

5. Security Protocol ESP.

For 3GPP-IMS ESP is required.

6. Security Mode Transport. For IPSec between UE and P-

CSCF, Transport mode is used.

SIP Security Headers in REGISTER message are used for

the negotiation of SIP secure port, security protocol, security

mode, integrity algorithm and encryption algorithms.

AKA is used for authentication and key agreement in the

IMS. AKA provide mutual authentication between UE and

IMS Core (i.e. S-CSCF).

As a result of authentication registration procedure using

AKA scheme, two pairs of unidirectional SAs between UE

and P-CSCF shall be established in P-CSCF and later in UE.

One SA pair is for traffic between a client port at UE and

server port at P-CSCF and other SA pair is for traffic between

client port at P-CSCF and server port at UE.

IK and CK are the integrity and encryption key which P-

CSCF extracts from WWW-Authentication SIP header of 401

response message from S-CSCF as a result of AKA procedure.

P-CSCF expand the key for ESP protocol

The Encryption key CK(esp) and integrity key IK (esp) is

same for the two pairs of simultaneous established SAs.

As a result of successful registration, secure link is created

between UE and P-CSCF and used further for secure

communication.

Any non-secure SIP messages on secure port are rejected by

the IPSec stack. Also Application should reject all the SIP

messages on non-secure port

V. IMPLEMENTATION CHALLENGES

This section list out the various implementation challenges

likely to occur during test bed development.

A. Stateful SIP Proxy

Building IMS Core as single executable server required

modification in SIP Dialog identification. P-CSCF and S-

CSCF make use of same SIP stack and running P-CSCF and

S-CSCF as stateful SIP proxy under same executable using

single SIP stack is the challenging task for the test bed. As SIP

dialog identifier remain same while forwarding SIP messages

from P-CSCF to S-CSCF and vice versa so differentiation of

SIP dialog is must and challenging one. It required the

extension of SIP Dialog identification.

SIP dialog is identified by Call-Id, From Tag and To tag

[6]. Additional parameters like Source Identification and

Destination identification can be used for actual dialog

segregation at P-CSCF and S-CSCF side.

B. Diameter Protocol

This protocol is required when S-CSCF interact with HSS.

IMS-Client does not have interaction with HSS and only IMS

Network component (S-CSCF) accesses the HSS. Hence this

protocol can be simulated which does not impact the IMS-

Client IOT. Simple message based protocol can be used for S-

CSCF and HSS interaction over TCP.

C. Service Filter Criteria

After applying IFC, S-CSCF needs to know where Initial

SIP Request to be forwarded i.e. either to P-CSCF or AS. AS

information in IFC only tells about the destination transport

addresses. It does not convey whether destination is P-CSCF

or AS. It needs additional information to segregate services

under IMS-Core Services, AS Services and AS 2 AS Services.

D. User Service Profile XML Scheme

The user profile XML schema needs to be sent over Sh

interface by HSS to S-CSCF [4]. For test bed all parameter

not required for the user profile. Instead minimum set of

parameters can be taken for the user profile.

• Public and Private user Identity

• User Authentication Data: realm, domain name, password, Algorithm, scheme, QoP, State are the mandatory parameter.

• Initial filter Criteria: SPT and Server contact points

S-CSCF can fetch this information from Database directly

during registration procedure.

E. Easy to add filter criteria for future services

IMS being an emerging network and scope for new services

are always expected. IMS-Core need to be flexible for any

new IMS Services and it required easy to add new filter

criteria for new services.

F. Server 2 Server Communication through S-CSCF

Terminating filter criteria make use of Request-Uri for the

Public User Identity. In Case of As2As communication

Request-Uri may contains Public-uri which is not registered

and hence request will be reject by the S-CSCF.

In such case S-CSCF should make use of P-Asserted-

Identity header which contains Server Identity and forward the

Request to other Server.

VI. TEST BED LAB ENVIRONMENT

Figure 2. Test lab environment

The above figure 2 shows the lab environment for testing of

IMS-Core services like Video Sharing.

A. Test Setup

IMS-Clients and Test Server are connected to the IP

Network.

The following configurations need to be done at IMS-Client

and IMS test Server.

1) SipCore Server Configuration:

a) Configure the IPAddress and Port for P-CSCF, S-

CSCF and HSS components.

b) Create User Profile: User profile need to be created

and stored into the data based for both of the IMS Clients.

Following parameters need to be configure for the user profile

• Public identity and private identity, password, Realm, Domain name, Algorithm, Scheme, QoP and Stale

• Services enabler( enable VSC Service)

• Initial Filter Criteria for VSC Service

Method – INVITE, OPTIONS,

SESSION CASE – Originating,

SESSION MODE – IMS-Core-Service,

Header Name – Accept-Contact,

Header Value – “+g.3gpp.cs-voice”,

Condition Negated – FALSE (0)

2) IMS Client Configuration: Following parameters need

to be configured at IMS client

a) public identity and private identit, Authentication

password, Algorithm, Scheme, Quality Of Protection(QoP)

and Stale

b) P-CSCF IP Address and Port.

B. VSC Flow

Both the client gets registered with the IMS-Core server.

Figure 3. VSC call procedure

Figure 3 shows the VSC call procedure. It shows the SIP

message flows between client and the IMS test server. In this

test environment same P-CSCF is the contact point for the

VSC clients, means, and same P-CSCF acts as originating

PCSCF for VSC Client1 and as terminating P-CSCF for the

VSC Client2.

During VSC call, both clients send OPTIONS request for

other client capability understanding. S-CSCF on receive of

OPTIONS request, apply the initial-filter-criteria and found

that this request is for VSC service and so forward the request

to P-CSCF(Terminating PCSCF) for the terminating VSC

Client.

Once capability exchange procedure is completed, VSC

client1 initiate VSC call by sending INVITE request to the

PCSCF.

ACKNOWLEDGMENT

The Authors would like to express their thanks to LGE and

LGSI for providing the opportunity and resources for the

paper. They would also like to thank all the reviewers

especially to Mr. Sunil Odayoth and Mr. Sundaresan for their

comments.

DISCLAIMER

The views and contents expressed in this

article/presentation are solely that of the author and do not

represent the views of LG Soft India.

REFERENCES

[1] 3GPP TS 23.218 V6.2.0 (2004-09)-IP Multimedia Session Handling; IM Call Model ,Stage 2 (Release 6)

[2] 3GPP TS 23.228 V6.8.0 (2004-12)-IP Multimedia Subsystem (IMS);Stage 2 (Release 6)

[3] 3GPP TS 24.228 V5.11.0 (2005-01)-Signaling flows for the IP multimedia call control based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);Stage 3 (Release 5)

[4] 3GPP TS 29.228 V6.5.0 (2004-12)-IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signaling flows and message contents (Release 6)

[5] 3GPP 33.203 v7.4.0 (2006-12) -Access Security for IP based services

[6] RFC 3261–Session Initiation Protocol

[7] RFC 3320–Signaling Compression(SigComp)