IMS Whitepaper Intro

8/9/2019 IMS Whitepaper Intro

1/24

Flexibility has been a well-known attribute of the session initiation protocol (SIP). SIP is at the heartof the IP multimedia subsystem (IMS), exemplifying the extensibility of the SIP protocol. This paperprovides a general discussion of the SIP protocol and highlights the differences between pure SIP clientsand IMS clients. Many books and white papers have been written about SIP and IMS, yet it is difficultto find a source of information that clearly identifies the differences between a SIP client and an IMSclient. This paper was created out of the common desire among the authors to provide a simplified viewof SIP/IMS clients and to point the reader to the appropriate specifications for more detailed research.

SIP was originally implemented for voice over internet protocol (VoIP) applications, initially forresidential and now for businesses. SIP has become the accepted signaling for VoIP, although SIP clientsand Proxies can contain certain liberties of the standards that might create issues when using differentSIP implementations. This first phase of SIP for VoIP was a solid design, stable in requirements, butfairly simple in nature.

Today, there is a new game in town that has thrust SIP into warp speed. That technology is IMS. SIPwas always designed to be more then just a vehicle for VoIP, and IMS will put that to the test. Standardsbodies are moving very fast to modify and extend standards for IMS. Since IMS is simply anarchitecture, the real winners are the applications running over the IMS architecture. Progress will movequickly as new applications will drive new requirements on SIP clients. This paper will examine whatnew requirements will be placed on a SIP client. Because of the nature of IMS, SIP client changes willgo beyond SIP. This paper will review the areas of changes that will affect the SIP client and will discuss:

1. SIP Extensions,

2. Signaling compression,

3. Security,

4. ENUM, and

5. Firewall/NAT traversal.

Introduction

N O R TH A M ER I C A: 800 498-JDSU (5378) WEBSITE: www.jdsu.comWORLDWIDE: +800 5378-JDSU

White Paper

IMS Simplified:

The Evolution of the SIP Client

WEBSITE: www.jdsu.com/test

Written by:

Jay Stewart

Director of Corporate IMS StrategyJDSU

Barry ConstantinePrincipal Member Technical Staff

JDSU

Lincoln LavoieSenior EngineerUniversity of New HampshireInterOperability Lab


2/24

There are standards bodies for all facets of telecommunications and data communications.For IMS to spanall technologies and networks, it is important to understand the broad range of standards that govern IMS.

The first standards body that greatly influences IMS is the International Telecommunication Union(ITU). The ITU created International Mobile Telecommunications-2000 (IMT-2000) which is theglobal standard for a 3G networka collaboration of standards bodies make up the IMT-2000. Insidethe IMT-2000 are two standards bodies that are the main focus for IMS: Third Generation PartnershipProject (3GPP) and 3GPP2. 3GPP deals with UMTS networks and 3GPP2 deals with code divisionmultiple access (CDMA) networks. Both have created standards for IMS, but most will refer to the3GPP standards. 3GPP introduced packet switched voice services in a standard called R4. IMS wasintroduced in standards R5/R6.

In R5, the standard calls for the use of SIP and IP as the basis for IMS, and this is where the InternetEngineering Task Force (IETF) comes in to play. IETF is responsible for SIP and other IP protocols.

While SIP is a powerful protocol, it needed to be extended to fit the 3GPP needs. 3GPP and IETFstarted working on extending the standards for SIP into the requirements for IMS.

In parallel, other groups such as CableLabs (cable company standards) started defining IMS support indata over cable services interface specification (DOCSIS) 2.0. Wireline groups such as the EuropeanTelecommunications Standards Institute (ETSI) and Telecoms & Internet converged Services & Protocolsfor Advanced Networks (TISPAN) began defining (EMEA) wireline extensions to IMS. The Alliance forTelecommunications Industry Solutions (ATIS) is developing IMS specs for the North America market.

These groups all have special needs of SIP and this also gets routed into the IETF. Within the IETF, theSIP working group is dedicated to driving all standards related to the SIP protocol. Once IMS choseSIP as a basis, it became clear that the SIP working group needed expansion. Therefore, the IETFcreated a new working group called SIPPING. The purpose of SIPPING is to gather SIP requirements

from all areas and prioritize work before it goes to the SIP working group.The group Open Mobile Alliance (OMA) is another body that needs to be mentioned. Even though thisgroup does not define any IMS specification, it does deal with applications that will ride on top of theIMS architecture. To date, they have defined Push to Talk and IM for IMS architectures.

Standards Organization Scope or Focus Standards Contributions

Internet Engineering All IP Networks SIP and other protocols (e.g. COPS,

Task Force (IETF) Diameter, etc.)

Thi rd G enerat ion U niversal Mobi le Te lecomm unicat ions S ervice IP Multimedia S ubsy stems ( IMS )

Partnership Project (3GPP) (UMTS)(Wideband Code Divis ion Multiple Access

[W-CDMA]) mobile networks and other access networks

Third Generation CDMA2000 mobile networks and other Multimedia Domain (MMD)

Part ners hip Project 2 (3GP P2) access network s

European Telecom Next generation wireline networks NGN effort by TISPAN

Standards Institute (ETSI)

Intern at ional Te lecommunication N ex t generat ion wire line network s Focus G roup on Next Generat ion

Union (ITU-T) Networks (FGNGN) effort by ITU-T SG13

NGN and other ITU-T Study Groups

CDMA Development Group (CDG) All mobile networks Open Mobile Alliance (OMA) and

Push-to-Talk over Cellular

CableLabs Cable IP networks PacketCable 2.0 Project

2White Paper: IMS Simplified: The Evolution of the SIP Client

2.0 Standards bodies driving IMS

Mobile

3GPP//2

OMAOpen Mobile

Applications

Fixed Line

ETSI

TISPAN

Cable

DOCSIS 2.0

IMS Architecture

IETF

SIP, SIP-T, RTP

Figure 2.1 Overview of the standards bodies driving IMS


3/24

3White Paper: IMS Simplified:The Evolution of the SIP Client

SIP is the key signaling protocol that is used in real-time IP communication sessions such as voice,video, and IM communications. For example, in VoIP, SIP is used as the call establishment protocoland converts the various PSTN phone mechanisms (off-hook, digit dialing, hold, etc.) into packetizedsignaling messages to establish voice calls across a network. SIP has established itself as the primarysignaling protocol for VoIP and has left the competing H.323 signaling protocol in a distant second place.

Figure 3.1 shows SIP relative to the TCP/IP stack as well as the other related protocols such as SDP, RTP,and DNS. Each of these protocols, together with SIP, is required to conduct real-time, multi-media callsover an IP network (private network or the public internet).

Figure 3.1 SIP in Relation to the TCP/IP Protocol Stack

SIP can ride on top of the user datagram protocol (UDP), an unreliable transport layer, or thetransmission control protocol (TCP), a reliable transport layer. Domain name service (DNS) is also acritical component of SIP communication sessions. Just as in normal internet web surfing, DNS is usedduring SIP session establishment to help convert SIP element names (i.e. SIP proxies) into IP addresses.

The real time protocol (RTP) layer resides on top of UDP. While SIP establishes the communicationsession for VoIP and Video sessions, the actual voice/video media streams are carried in RTP over UDP(sometimes just over UDP) across the network path established by the SIP set-up. Figure 3.2 is asimple ladder diagram that highlights the basic establishment of a voice/video communication and therole of SIP versus RTP.

3.0 Introduction to SIP

TCP

Application

Transport

Network

Physical/Data Link

UDP

SIP RTP DNS

Ethernet

IP

SDP Codecs


4/24


[email protected]

Calls Jane

SIP

Signaling

Talking

Hangs up

Rings

Answers

Talking

INVITE: sip:[email protected]

ACK

BYE

180Ringing

[email protected]

200OK

200OK

RTP

SIP

Signaling

Figure 3.2 Relationship of SIP and RTP during a Communication Session.

For the instant messaging (IM) scenario, SIP carries both the signaling establishment messages and theactual text associated with the IM session. Since IM is not a real-time media stream, this is not anexception to the rule; rather an efficient partition and usage of the native text implementation of theSIP protocol.

3.1 Fundamental SIP Elements and Session Flow

SIP provides two key services in the establishment of real-time communications across a network:

1. Establishing the presence of the various parties and locating the called parties during sessionestablishment (i.e. Jane is using her SmartPhone versus office phone and SIP ensures that this

presence and location are properly registered in the SIP network).

2. Establishing the multi-media capabilities of the session parties and negotiating the specificconfiguration parameters to be used during the actual media session (i.e. Party A is a soft phonesupporting G.726 codec, Party B supports G.726 and G.729).


5/24


To provide the presence and session negotiation services, SIP relies on various entities within a SIPbased network. These SIP entities include:

User Equipment (UE)*. This is the originating device or client of the multi-media session (i.e., PC,PDA, Cell Phone, etc...).

Registrar. UEs register their location with a Registrar who stores the location in the LocationServer.

Location Server functionality may be a separate entity or may be a database like function withinthe Registrar

Proxy. The SIP Proxy is the first point of contact in a SIP based network. SIP Sessions can be Peer-Peer, but this is mostly used in small scale implementations such as peer-peer gaming and LAN-based gaming.

*Note: In pure SIP, the IETF coined the term UA (user agent),while 3GPP uses UE (user equipment).

Throughout this document, the term UE is used for both instances.

Two of the most fundamental aspects of SIP communication in reference to the SIP Elements describedabove are:

1. SIP Registration

2. SIP Session Establishment

These scenarios are discussed in the following sections.

3.1.1 SIP RegistrationFor SIP Users to communicate with each other, the network must resolve a SIP (URI) into the usersphysical location and the network path to the called user (the called users IP address). Another way tothink of a SIP URI is to equate this to the users SIP phone number.

An example of a SIP URI is:

sip:joe.user@company_xyz.com

The concepts of public URI and private URI are very important to understand. A public URI is the SIPname that a calling party will use to reach the called party. Most times the public URI is very much likea public email address.

A Public URI is more of a logical address where a private URI is more of a physical address. Forinstance, Joe User may be using his PDA or his PC while in the office. For each of these locations, the

private URI would be:

sip:[email protected]_xyz.com


In SIP, there are means to register and resolve public and private URIs. In Figure 3.3, the SIP Registerprocess is indicated by steps (1) and (2) in the flow diagram.


6/24

Figure 3.3 SIP Elements and Message Flow for SIP Registration

First, Joe Users location is registered as his PC location by means of a SIP REGISTER message. Joes PCwill send this REGISTER message to the registrar (Step 1 in Figure 3.3). The registrar then forwards thisREGISTER message to the location server (Step 2 in Figure 3.3). In many cases, the registrar and locationserver are logically and physically contained in a single server. The result is a 200 OK message from theregistrar. The 200 OK message will contain the contact header field, with the actual addresses of any UEdevice associated with that URI, indicating the successful registration binding.

The location server now can resolve Joes public URI (sip:joe.user@company_xyz.com) to his private

URI (sip:[email protected]_xyz.com). And if Joe should log off of his PC and onto his PDA, thenthe register process occurs again and Joes private location would then be registered to his PDA(sip:[email protected]_xyz.com)

3.1.2 SIP Session Establishment

The following diagrams reflects the message flow if Jane User, the calling party, wants to initiate a voicecall to Joe User. Jane is using a PC client which supports SIP and VoIP. For the SIP sessionestablishment, Figure 3.4 will be used to discuss the message flow.

Figure 3.4 SIP Elements and Message Flow for SIP Session Establishment



sip:[email protected]

1 SIP Message

Proxysip:joe.user@company_xyz.com

Location

Server

Registrar

4 SIPM

essage

2WhereisJo

e?

3Answ

er


1 Register

Proxysip:joe.user@company_xyz.com

Location

Server Registrar

3 200OK

2 UploadLocation Information


7/24


First, Janes PC must locate Joes physical location (and IP address). Message 1 is an SIP INVITEmessage (more details on SIP message types and formats in Section 3.2) and this message is first sentto the SIP Proxy, who then obtains Joes location (IP address) from the registrar or location server.

Once the Proxy determines Joes location (messages 2 and 3) by querying the Location Server, the SIPINVITE message is forwarded to Joes PC and the flow of SIP messages required for session set-upcommences. Since the proxy has identified Joes location for the first INVITE message, subsequentmessages from Jane will not require a location look-up (unless of course Joes location has changedwhich is outside the scope of this introductory paper).

SIP session establishment also supports the concept of endpoint capability negotiation. Consider thesituation where one endpoint can handle voice and video, while the other endpoint can only handlevoice. During the session establishment phase,SIP provides the ability for the endpoints to discover anddescribe the payload message contents and characteristics. To provide for this capability, SIP uses theSession Description Protocol (SDP) which is carried in the actual message body of the initial SIPmessages. Figure 3.5 is a more detailed message diagram of a SIP sessions establishment and providesan examination of the SDP components of the SIP session establishment.

Figure 3.5 SIP Session Establishment and Session Negotiation via SDP

First, Jane sends an SIP INVITE message to Joe and informs Joe of the various video and audiocapabilities present in Janes phone (or other UE device). Some of the more interesting fields withrespect to Janes session description are highlighted in Figure 3.5.

INVITE()

ACK()

100Trying()

100Ringing()

Jane UA Joe UA

200OK()

Janes

Capability

Description

Joes

Capability

Description

Content Type indicatesSDP message

Content Type indicatesSDP message

1

2

3

4

5


8/24

SDP involves session-level information and media-level information. Referencing Figure 3.5, the linesbefore the m line are session level and after the m line are media level information. In the sessionlevel section, Table 3.1 highlights these parameters:

Field Meaning

v=0 SDP Version is 0

o=36596161 33887 IN IP4 192.168.1.172 Owner of the session and session identifier

s=SIP Phone Session Name

c=IN IP4 192.168.1.172 Connection information

t=0 0 Time when the session is active (0 indicates immediately)

Table 3.1 Session Level Information in the Janes INVITE Message

The media level section is where audio/video capabilities of each party are established. The media levelsection contains a single m line and a variable number of a lines which describe the specifics aboutthe media capabilities. The media level values are described in Table 3.2.

Field Meaning

m=audio 6886 RTP/AVP 0 8 98 97 101 Audio is to be requested to be received on the port 6886 and the code numbers of the audio codecs that

supported.The alines below provide more specific detail for the audio codecs supported.

b=AS:64 Bandwidth information

a=r tpmap:0 PCMU/8000/1 Attributes of the 0 co dec reference in the m li ne; i n this c ase PCM uLaw encoding

a=r tpmap:8 PCMA/8000/1 Attributes of the 8 co dec reference in the m li ne; i n this c ase PCM ALaw encoding

a=rtpm ap: 98 G 726 -3 2/80 00/1 Att ributes of t he 9 8 codec reference in th e m l ine; in t his case G. 72 6 encoding

a=rtpm ap: 97 AM R/800 0/1 Att ributes of t he 97 codec reference in th e m l ine; in th is case Adaptive Mult i- rate R ate encoding

a=rtpmap:101 telephone-event/8000 Attributes of the 101codec reference in the mline;in this case PCM uLaw encoding

Table 3.2 Media Level Information in Janes INVITE Message

If Jane would have supported video and audio (instead of just audio) and Joe supported only audio,then the session would automatically be established as an audio only call.

Also note that in the INVITE message, the codec preference is implied with order presented in the SDPoffer. The answer from the receiver also has order of preference and the common highest preferencecoder-decoder (CODEC) is used.



9/24


3.2 SIP Message Format OverviewThis section provides a general overview of SIP message format. Like HTTP, SIP is a request/responsetype protocol. Messages such as INVITE and REGISTER, for example, are request-type messages, whilestatus messages like 100:TRYING, 200:OK, etc are response-type messages. Table 3.3 summarizes thevarious request messages defined by SIP, and Table 3.4 shows the response messages.

Message Description

ACK Confirms that the sender has received a 200:OK response from the receiver

BYE Terminates the call and can be done either the caller or called party

CANCEL Cancels calls that are in the process of being established

INFO Carries application level information along the SIP signaling path

INVITE Request from the caller to the calling party(ies) to join a media session

NOTIFY Notifies subscribers if event changes (i.e.location change of a user from a called group)

OPTIONS A query message to determine the capabilities of the called serversPRACK Insures reliability of provisional reliability 1xx responses;born out of needs in wireless domain to for the calling party path to send

PRACKs to let the calling party know that a call is in progress of being accepted.

PUBLISH Publishing event state,PUBLISH is similar to REGISTER in that it allows a user to create, modify,and remove state

REGISTER Registers the callers public URI address with the SIP Registrar

SUBSCRIBE Indicates that a user wishes to receive information about the status of a service session

UPDATE UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs).

MESSAGE MESSAGE requests carry Instant Messaging;the content is in the form of MIME body parts.

REFER This SIP extension requests that the recipient REFER to a resource provided in the request.This can be used to enable many applications,including

Call Transfer.

Table 3.3 SIP Request Message Summary

Message Description

1xx Information Responses

2xx Successful Responses

3xx Redirection Responses

4xx Client Failure Responses

5xx Server Failure Responses

6xx Global Failure Responses

Table 3.4 SIP Response Message Summary


10/24

4.1 IMS Network GroundworkThe IMS technologies are best described as an architecture designed to leverage and extend what is thenext generation network. The goal of the architecture is to unite mobile and fixed line services, whilestandardizing the platforms used to offer new services to the consumer. Figure 4.1, below, shows asimplified overview of the core components of an IMS network topology. As in plain-VoIP, SIP is usedas the session signaling and control mechanism between the IMS terminal (UE or user equipment) andthe IMS network. At the heart of these networks is the serving call session control function (S-CSCF),which functions as primary registrar and routing SIP proxy server. The S-CSCF is responsible forauthenticating the user, maintaining the registration state of that user, and routing SIP messages to andfrom that user. An important consequence to note regarding the IMS architecture is its design forhorizontal scalability. Nearly every component in the network may be replicated to facilitate loadbalancing and geographic diversity.

Figure 4.1 Simplified IMS Topology

Because the S-CSCF serves as the heart of the IMS architecture, it is protected from the harsh internetand mobile worlds by the proxy-CSCF (P-CSCF) and interrogating-CSCF (I-CSCF.) From theperspective of an IMS terminal user, the P-CSCF is the first proxy server in the signaling/routing chain.The user equipment (UE) must discover the IP address of the P-CSCF via some outside protocol(DHCP, DHCPv6, or GSM function). Once the UE determines this address, it may only send SIPmessages to this server and receive them from this server. Two important items should be noted aboutthe P-CSCF: 1) Once the user is registered, or authenticated, to the network, the same P-CSCF is usedthroughout the lifetime of the registration; 2) The P-CSCF may or may not be located within the usershome domain/network. At this point, it is important for us to define some terms relating to IMSnetworks.


AS

SIP

SIP

SIP

SIP

Application

Server

Call

Session

Control

Functions

Home Subscriber

Server

Diameter

Wireless Net

IMS UAs

(PDAs, smartphones, etc)

S-CSCF

I-CSCF

P-CSCF

HSS

4.0 IMS Basics


11/24


Home network/domain operated by the service provider who holds the contract with the user. Visited network/domain operated by a service provider who does not hold a contract with the

user. The home network operator may or may not have a roaming contract with this operating,thereby enabling the user to receive services over this network.

Originating network hosting a user, who is initiating a session.

Terminating network hosting the user or service that is responding to the session initiation.

The I-CSCF is the last CSCF to be discussed. The function of the I-CSCF is to serve as an SIP entrypoint into the operators domain. P-CSCFs from inside and outside of the operators network willlocate the I-CSCF via domain-name-service (DNS) query, and the DNS systems shall provide a form ofload-balancing, by routing successive queries to different I-CSCF servers. It is important to note theP-CSCF may not always transmit SIP message to the same I-CSCF, while the S-CSCF will remain

constant through the registration lifetime.

It is important to understand how the I-CSCF server locates the appropriate S-CSCF server for thegiven UE. The home subscriber server (HSS) acts as the user database for the IMS network, storinginformation such as public and private user identities, passwords, enabled services (and their triggerinformation), and the S-CSCF assigned to the user. When the I-CSCF receives a message from theP-CSCF server, it queries the HSS for the assigned S-CSCF, and forwards the message to the appointedS-CSCF. That query is made using the DIAMETER protocol. Returning to the S-CSCF, the SIP serverresponsible for authenticating and maintain the user registration states, it is apparent that the S-CSCFalso needs access to the information stored within the HSS. In this way, both the I-CSCF and S-CSCFcommunicate with the HSS over an interface referred to as the Cx interface, which is standardized viathe DIAMETER protocol. Lastly, it should be noted that the Cx interface is only available within aservice providers own network and never exposed to either another operators network or the internet.

To this point, this paper has discussed the major components relating to the SIP signal routing withinthe IMS architecture, leaving the discussion of the peripherals: application servers (AS), mediaresource functions (MRF), border gateway control function (BGCF), and media gateway function(MGF). The AS is the driving motivation for shifting the current networks to the IMS architecturebecause service provides need to offer new and updated services to their customers to stay competitive.Historically, this has often required the deployment of entirely new/updated networks to support thoseservices. These distinct networks are sometimes referred to as silos (vertical infrastructure). BecauseIMS is a standardized architecture implementing a flexible signaling system (SIP), the service providershould be able to deploy any new service over their network by simply turning up a new applicationserver and provisioning it within the HSS. Although this may seem over simplified, examine what isalready known. The IMS architecture defines the IP network topology and signaling mechanismsbetween the core network and the IMS terminal equipment. That signaling mechanism is SIP, which is

defined to setup multimedia sessions, including: voice, video, and instant messaging, to name a few ofthe well-known services. Returning to the discussion of signaling to and from the AS, there are twodefined interfaces for the SIP-based AS, the ISC and the Sh . The ISC interface is SIP based between theS-CSCF and the AS, allowing for sessions between UE devices and the AS to be created and controlled.The Sh interface is DIAMETER based and exists between the HSS and AS, allowing the AS to query theHSS for user information and configure parameters.

Lastly, there are three additional components to discuss: MRF, BGCF, and MGF. The BGCF and MGFplay a key role in integrating the IMS architecture with the existing public switch telephone network(PSTN.) The BGCF serves as a broader controller, while the MGF converts VoIP session (RTP) trafficinto the format required by the PSTN. This allows IMS users to place and receive calls to and from theexisting PSTN network. The MRF provides the media resources for features such as automated promptsand announcement services.


12/24

4.2 Example IMS Call Flows

4.2.1 IMS UE Registration

The two most basic IMS signal flows are the registration flow and the establishment of a VoIP call flow.Just as within plain-VoIP SIP examples, the client device registers with the network, the user equipment(UE) device must also register within an IMS network. This process is accomplished using SIP registrationmessages, sent initially from the UE device to the P-CSCF. However, before the UE can transmit theREGISTER message to the P-CSCF, it must discover the IP network details for the physical network inwhich it currently resides. Since the IMS architecture has been developed to remain independent of thephysical network (with the exception of some bandwidth and quality of service (QoS) requirements) thisprocess is not officially part of the IMS design.Instead these details are to remain a function of the physicalnetwork and its underlying protocols, like DHCP for example,(see Note 1.)

Note 1: Before the UE device can contact the IMS network, it must establish the physical and data layer con-

nections.These are dependant upon the type of network on which the UE device is deployed.During this

process, the UE device may locate the appropriate P-CSCF server address through a external mechanism,such as DHCP, or pre-configuration.


Note 1

DNS Lookup

SIP for Domain

Buildauthorization

vectors

Checkauthorization

response

P-CSCF subscribes

to registration event

package

UE subscribes

to registration event

package

Select S-CSCF

Server for UE

Register

User Authorization Request

User Authorization Answer

MediaAuthorization

Answer

MediaAuthorization

Request

ServerAssignment

Answer

ServerAssignment

Request

Register

Register

Register

Register

Register

401 Auth Request401 Auth Request

401 Auth Request

200 OK

200 OK

200 OK

200 OK

SUBSCRIBE

200 OK

NOTIFY

200 OK

200 OK

200 OK

200 OK

P-CSCFMobileNetworkIMS UE I-CSCF S-CSCF HSS

SUBSCRIBE

SUBSCRIBE

NOTIFY

NOTIFY


13/24


Once the UE has begun the registration process by transmitting a REGISTER message to the P-CSCF,the next several messages become the responsibility of the IMS network. The P-CSCF, which may notbe within the users home network (the user may be roaming in another country) resolves theappropriate I-CSCF through a DNS query for the SIP handlers domain in the REGISTER request. Oncethe I-CSCF is located, the P-CSCF inserts a number of additional headers responsible for network andcharging identification and forwards the message to the I-CSCF. The I-CSCF will query the HSS usingthe User-Assignment-Request DIAMETER function for the S-CSCF that has been assigned to the userspublic ID. If the S-CSCF has not yet been assigned, it is the responsibility of the I-CSCF to select the S-CSCF from a list provided by the HSS. For the REGISTER request, the I-CSCF is required to act as astateful proxy, inserting its signaling address as a via header in the SIP message and forwards themessage to the S-CSCF.

When the S-CSCF receives the message, it will query the HSS using the media-authorization-request

DIAMETER function. The media-authorization-answer message from the HSS provides the S-CSCFwith the authorization vectors required to build the SIP challenge responses (401 AuthorizationRequired) and the security association between the P-CSCF and the UE. The S-CSCF forwards thismessage back to the I-CSCF. The I-CSCF relays this message to the P-CSCF, where the P-CSCF removesany secure headers before forwarding the message to the UE device.

Assuming that the UE device has all the information needed to create the correct response to the 401Authorization required message, the UE will create a new REGISTER request, including the challengeresponse and again forward this message to the P-CSCF. The P-CSCF again forwards this message tothe I-CSCF, where the HSS is queried and the S-CSCF is located, and, finally, the I-CSCF forwards therequest to the S-CSCF. The S-CSCF checks the challenge response to verify correctness. Again, assumingno problems exist and the challenge response is correct, the S-CSCF informs the HSS of theregistration, via a Server-Assignment-Request (DIAMETER Message) and forwards a SIP 200OK

response to the UE through the I-CSCF and P-CSCF.Lastly, looking closely at the final steps of the above ladder diagram, we see the P-CSCF and the UEdevice subscribe to the registration event package, via the SIP SUBSCRIBE method. This subscriptionallows the network to inform the UE device of changes to the network. For example, the case where theS-CSCF currently hosting the UE device is being taken down for maintenance or the users account hasbeen terminated. The term applied in these cases is network initiated de-registration.

4.2.2 IMS Session Establishment (VoIP call example)

In the IMS architecture, sessions are established and controlled using the SIP protocol. In the followingexample, shown below in figures A and B, the case of an IMS subscriber establishing a VoIP call with asecond subscriber is examined. In this example, both subscribers will be located within the same IMShome network. The first subscriber (UE1) sends an INVITE request, targeting the second subscriberspublic identity to the proxy-CSCF. The P-CSCF forwards the message to the users assigned S-CSCF.The S-CSCF first evaluates the initial filter criteria, which in this simplified case, does not require anyactions. The S-CSCF then locates the registration and contact information for the second subscriber(UE2), (for this example, it is assumed that the second subscriber is registered to the same S-CSCF).From here, the INVITE request is relayed to UE2. It should also be noted that this initial INVITE shouldcontain an SDP offer, and that the SDP offer should include some QoS requirements. Theserequirements are considered part of the preconditions, if the UE devices require QoS to be supported.The SIP precondition mechanisms are defined by RFC-3312.


14/24

When UE2 receives the INVITE request, it should respond with the 183 session progress provisionalresponse. This response serves two purposes: it establishes an early dialog, and it should contain anupdated SDP answer (possibly including updated QoS requirements). It should be noted at this pointthat UE2 has not alerted the second subscriber of the incoming call, as a result of the preconditions.Lastly, the 183 provisional response should be sent reliably, therefore including the 100rel header. WhenUE1 receives the response, it should process the response and SDP answer, responding with the PRACKresponse. At this time, UE1 should also be able to establish the QoS reservations on its local network.The PRACK response should follow the same routing logic of the initial request and the 183 provisionalresponse, and be responded to with a 200 OK response. Note: This is not the 200 OK final response tothe initial INVITE request. When UE2 receives the PRACK response, it should also begin the process ofreserving the network requirements to meet the precondition.

Once UE1 has reserved the necessary network resources to meet the QoS requirements of the

preconditions, it should update the session using the SIP UPDATE method, carrying a new SDP offerwith the updated QoS support and requirements. The UPDATE message is transmitted within the earlydialog established by the INVITE/183 Session Progress transaction, and therefore must follow the samerouting path. The UPDATE message is responded to with a 200 OK response, containing the SDPanswer with UE2s updated QoS resources. At this point the second subscriber is alerted about theincoming call, as the required preconditions have now been met.

Figure A: Stage 1 of a basic IMS session establishment.


S-CSCF evaluates

initial filter criteria

INVITE

INVITE

PRACK

183 Session Progress



PRACK

PRACK

200 OK

200 OK

200 OK

200 OK

UPDATE

UPDATE

INVITE

200 OK

200 OK

UPDATE

P-CSCF 1IMS UE1 IMS UE2 I-CSCF S-CSCF HSS

INVITE

183 SessionProgress

PRACK

200 OK

UPDATE

200 OK


15/24


During the second stage of the session establishment, UE1 is notified that UE2 is alerting the subscriber,via the 180 Ringing provisional response, which again must be sent reliably. This results in a similarPRACK, 200 OK transaction as the 183 Session Progress provisional response.

Lastly, the second subscriber answers the incoming call, causing UE2 to send the 200 OK final responseto the original INVITE request. As defined by SIP, this final response is sent reliably and should beresponded to with an ACK response. At this point, the RTP media path should be established betweenUE1 and UE2

Figure B:Stage 2 of a basic IMS session establishment.

UE2 alerts/ringsto request user

actions

UE2accepts/answers

the call

180 Ringing

180 Ringing

PRACK

180 Ringing

PRACK

PRACK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

P-CSCF 1IMS UE1 IMS UE2 I-CSCF S-CSCF HSS

PRACK

ACK

ACK

ACK

ACK

200 OK

200 OK

RTP andMedia

180 Ringing


16/24

While the IMS architecture is a relatively complex network of components, from the perspective of theend consumer, the most important of those components is the user equipment (UE). This interfacerepresents the face of IMS to the user and will be the vehicle for delivering these new services andapplications to that consumer. To that end, an IMS UE device will be much more than a simple SIP-based phone. The initial feature list being targeted by many vendors includes: voice, instant messaging,multimedia, gaming, and fixed/mobile convergence. To meet these requirements, the IMS standardshave defined what may be considered a SIP usage profile. The profile defines which SIP standardsshould be included in IMS devices, and how SIP should be used to establish and control the mediasessions. Of key focus in these definitions are: security, reliability, bandwidth, and performance. In thefollowing section, some of these requirements and the standards used to define them are discussed.

5.1 SIP Extensions

The IMS architecture adopts and uses SIP as the signaling and session control protocol. From RFC3455,[The] 3GPP notified the IETF SIP and SIPPING working groups that the existing SIP documentsprovided almost all of the functionality needed to satisfy the requirements of the IMS, but that theyrequired some additional functionality in order to use SIP for this purpose. This section will attemptto highlight some of these extensions, by pointing out key areas where developers should pay attention.

Continuing on with a discussion of RFC-3455, titled Private Header (P-Header) Extensions to theSession Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP), this RFC defines6 additional header fields for use within SIP messages. Some of these header fields must be used by UEimplementations, while others exist only within the IMS network for security purposes. From theperspective of a UE device, the following new header fields will be important:

P-Associated-URI header

P-Called-Party-ID header P-Access-Network-Info header

RFC 3455 also defines the following other header fields, which play roles in security and chargingwithin the IMS network:

P-Visited-Network-ID header

P-Charging-Function-Addresses header

P-Charging-Vector header

In addition to the definition of the new header fields, the IMS architecture utilization of SIP may bethought of as the definition of a usage profile. The base SIP specification is RFC-3261, and includes themethods necessary to establish and control basic sessions. SIP has been further expanded upon byadditional RFCs, such as RFC-3262,Reliability of Provisional Responses in Session Initiation Protocol(SIP). The usage profile of SIP for the IMS architecture makes the support of many of these additionalspecifications mandatory. RFC-3262 defines the mechanisms necessary to ensure the delivery of 1xxprovisional responses within the SIP protocol. The 1xx responses are used to establish an early dialogduring the process of establishing a session. Within the IMS architecture, these 1xx responses play acritical role in the selection of the QoS requirements and must not be lost due to network ortransmission errors. For this reason, the IMS SIP profile requires the use of the 100rel header andsupport of the PRACK method, as described by RFC-3262.


5.0 SIP Clients for IMS


17/24


Beyond the P-header and PRACK extensions, the IMS SIP profile requires the support of several otherSIP methods (defined within various RFCs). For example, RFC-3265 describes the SUBSCRIBE andNOTIFY methods, as seen above in the registration ladder diagrams, are relied upon to inform the UEand P-CSCF of network initiated changes to the UE registration state. Additionally, RFC-3312 describesthe mechanisms for incorporating quality of service extensions into the SIP and SDP signaling, referredto in IMS as preconditions.

5.2 Security

Security within IMS is certainly a topic that deserves a white-paper of its own, being a broad and multi-facetted topic. For this purpose, this paper will discuss two small pieces of security within IMS; accesssecurity (security between the UE device and the IMS network) and user/network authentication. Bothof these processes take place during the initial registration of the UE device to the IMS network, as

described previously.

The first security component in the IMS is access security. SIP by itself does not include any transportsecurity mechanisms. As such, it relies on other means to ensure the security of the connection betweentwo SIP devices. In plain-VoIP, this is often accomplished using transport layer security (TLS) toencrypt the SIP messages on a hop-by-hop basis, in the same way Internet shopping traffic is encryptedbetween the web server and browser. Obviously, there are other security protocols available, such as IPsecurity (IPsec). Within the IMS architecture, access security (the security associations between thenetwork and the UE devices) is accomplished using IPsec.The IPsec security associations are negotiatedduring the registration phase and are based upon the IK and CK values stored within the HSS andtransmitted to the P-CSCF within the 401 authorization required message. Once the IPsec session hasbeen established between the UE and P-CSCF, all SIP messages should use the security transport.

The second component of IMS security is network and user authentication. In contast to plain VoIP,the IMS architecture required AKA authentication instead of digest-MDS. In this process, the majorplayers are the UE device, the S-CSCF, and the HSS. The shared secret value is only held in two places,the ISIM on the UE device and the HSS database. The UE device sends the initial REGISTRATIONrequest, which includes a mostly empty authorization header field. When the request reaches theS-CSCF, it queries the HSS. The HSS returns a set of authentication vectors to the S-CSCF. Thesevectors include a random value and the expected UE response, which is based on a mathematicaloperation between the shared secret and the random value. The vector also includes some of the valuesused for the IPsec security association, as described above. The S-CSCF inserts all of these values(except the expected response) into the 401 authorization required response and forwards the responseback to the UE. The UE receives the challenge response and extracts and checks the value of the AUTNto authenticate the network. The UE must then build the challenge response from its shared secret andthe random value and include these values in the second REGISTER request. When the S-CSCF receives

the second request, it compares the response to the expected response, and, if the values match,responses with a 200 OK final response.

It is important to reference the appropriate standards for IMS security. The access security is defined in3GPP specification 33.203, while the network security is defined within 3GPP 33.210. The AKA digestbased authentication is defined in RFC-3310. The 3GPP 24.229 document also describes the UEprocedures in detail.


18/24

5.3 Signaling compressionSignaling compression (RFC 3320) is a method to compress a message generated by protocols such asSIP. Although the RFC is written in an application independent manner, the major driver for signalingcompression is SIP. Most multimedia applications use text-based protocols and are designed for largercommunication pipes. With IMS this means that applications are moving to the wireless networks andhandsets. These devices and network may not be able to handle the large bandwidth needed when usingSIP text based signaling. SigComp is designed to handle this situation and is used between UE-PCSCFlink (access link) -- not the other links where bandwidth is generally abundant.

SigComp is a layer between the application and the transport layer and is made up of two basiccomponents: compression and decompression. Decompression is by a universal decompressor virtualmachine (UDVM) optimized for the task of running decompression algorithms. The UDVM can beconfigured to understand the output of many well-known compressors such as DEFLATE (RFC-1951).

The diagram below shows SigComp architecture.

Other RFCs associated with SigComp are

RFC 3320 - Signaling Compression (SigComp) RFC 3485 - The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static

Dictionary for Signaling Compression (SigComp)

RFC 3486 - Compressing the Session Initiation Protocol (SIP)

RFC 4077 - A Negative Acknowledgement Mechanism for Signaling Compression

RFC 4464 - Signaling Compression (SigComp) Users' Guide

RFC 4465 - Signaling Compression (SigComp) Torture Tests

RFC 1951 - DEFLATE Compressed Data Format Specification version 1.3


Transport Layer

Local Application

Compressor 1

Compressor 2

Compressor

Dispatcher

Decompressor(UDVM)

State 1

State Handler

SigComp Layer

SigComp Message

Compartment IdentifierApplication Message

Compartment Identifier Decompressed Message

SigComp Message

State 2

Compressor

Dispatcher


19/24


5.4 ENUMSince one of the first applications that might be used in an IMS environment is voice, it is important tounderstand ENUM and E.164. Also it is possible that a single phone number could be assigned for eachdevice and service for the Public User Identities instead of the traditional URI.

The first thing to understand is E.164. E.164 is an ITU standard that defines telephone numbers. E.164Telephone numbers can be up to 15 digits long. The E.164 specifies country code, national destinationnumber and subscriber number.

The ITU and IETF have adopted a standard to map E.164 numbers using URI and DNS. The goal ofthe ENUM standard is to provide a single number to replace the multiple numbers and addresses foran individual's home phone, business phone, fax, cell phone, and e-mail. RFC 3761 describes themapping of E.164 numbers to a URI for DNS.

To review how the mapping of E.164 numbers would work, refer to a standard E.164 number+1-919-111-2222.

1. Remove all non numerical characters from the string 19191112222.

2. Next you reverse the order of the digits 22221119191

3. Dots are placed between the numbers 2.2.2.2.1.1.1.9.1.9.1

4. Add .e164.arpa to the end of the string 2.2.2.2.1.1.1.9.1.9.1.e164.arpa

Now the number has been translated into an internet name and is ready for a DNS lookup.

Below is an example of how a voice call flow could be using ENUM Lookup. In this example, thesubscriber has signed up for services using SIP. The caller makes a query based on the telephone

number, in which DNS returns the SIP address which the SIP proxy uses to set up the call.

SIP Proxy SIP Proxy

DNS Server

DNS Lookup2.2.2.2.1.1.1.9.1.9.1.e164.arpa

ResponseSIP:[email protected]

Dialed

+1-919-111-2222

SIP:[email protected] Call Setup


20/24

5.5 NAT traversalSince it is most likely that the client will be behind a network address translator (NAT), it is importantto understand how to communicate through the NAT.

The NAT involves re-writing the source and/or destination address of IP packets as they pass through aRouter or firewall. The reason people use NAT is to allow for multiple private IP addresses to be mappedto one Public IP address. NAT became very popular as a method to deal with the IPv4 address shortage.

The first method that should be looked at is STUN (Simple Traversal of UDP through NATs, based onRFC 3489). STUN allows the client to determine its public address and the type of NAT it is behind.This allows for communication of two clients behind firewalls.

STUN is a client-server protocol and the server must be a publicly addressable server. The STUN clientmust have the address of a STUN server in which to communicate to. A basic flaw to STUN is that it

will not work behind a symmetrical NAT. Another method that is being proposed in the IETF istraversal using relay NAT (TURN). TURN addresses the symmetrical NAT issue. The TURN servermust be in the customers demilitarized zone (DMZ) or in the service providers network. There isanother IETF draft called Interactive Connectivity Establishments. This is not a protocol, but methodsto explore the environment in which the client is located.

Another security area that is pertinent to IMS is RFC 3581 - An Extension to the Session InitiationProtocol (SIP) for Symmetric Response Routing. Currently, SIP provides the client with the source IPaddress that the server saw in the request, but not the port. The source IP address is conveyed in the"received" parameter in the topmost SIP Via header field value of the response. This information hasproven useful for basic NAT traversal, debugging purposes, and support of multi-homed hosts.However, it is incomplete without the port information. This extension defines a new parameter for theVia header field, called "rport", that allows a client to request that the server send the response back to

the source IP address and port where the request came from. The "rport" parameter is analogous to thereceived parameter, except "rport" contains a port number, not the IP address.

NATs can also cause problems where IPsec encryption is applied and in cases where multiple devicessuch as SIP phones are located behind a NAT. Phones that encrypt their signaling with Ipsec,encapsulate the port information within the IPsec packet meaning that NA(P)T devices cannot accessand translate the port. In these cases, the NA(P)T devices revert to simple NAT operation. This meansthat all traffic returning to the NAT will be mapped onto one client causing the service to fail. There area few solutions to this problem: one is to use TLS which operates at layer4 in the OSI Reference Modeland therefore does not mask the port number, or to encapsulate the IPsec within UDP - the latter beingthe solution chosen by TISPAN to achieve secure NAT traversal.

(Reference http://en.wikipedia.org/wiki/Network_address_translation)

5.6 IPv6 Support

Although IPv6 brings many improvements to IPv4, one of the major improvements is obviously theexpanded address space. With clients moving to mobile handsets and other endpoints, IPv4 does nothave enough address space for all end points. Most applications should not notice a change and IPv6should be transparent. This is not the case with SIP. SIP is very dependant on the IP addressing scheme.In the 3GPP Release 5, standards IPv6 was the only version supported. Release 6 added IPv4 support.

IPv6 has been anticipated for many years, and many believe that IMS may really be the application thatwill bring IPv6 into the mainstream. While NATing for IPv4 may be feasible in IMS landlineapplications, it would be very unwieldy (if not impossible) for mobile operators to deploy a NAT-edIPv4 networks. The trend certainly appears to be in favor of IPv6 for mobile networks.



21/24


The subject of IMS is immense and very complicated. The intent of this white paper was to provide thereader with a starting point to understand the standards surrounding IMS, the basic concepts of the SIPprotocol, IMS fundamental call flows, and the various SIP extensions required to support IMS.

This white paper should also serve as a launching point for the reader to drill down into the morespecific areas of IMS client operation (i.e. SIGCOMP, Security, SIP extensions, etc.). Section 7 providesa comprehensive list of the key standards which are required for IMS.

One final note for the really adventurous readers: just like any complicated networking subject, there isa difference between reading about the protocol and actually using the protocol. The authors have allgained much more insight into IMS by deploying an open source IMS infrastructure and IMS clients.

The following provides links to an open source IMS infrastructure, IMS client, and a packet capture/analysis tool.

IMS Infrastructure: www.openimscore.org

UCT IMS Client: uctimsclient.berlios.de

Packet capture tool: www.wireshark.org

6.0 Conclusions


22/24

7.1 SIP and SIP extensions for IMS RFC 2327 SDP:Session Description Protocol, Apr 98

RFC 2976 The SIP INFO Method,Oct 00

RFC 3261 SIP: Session Initiation Protocol

RFC 3262 Reliability of Provisional Responses in the SIP, Jun 02

RFC 3263 Session Initiation Protocol (SIP):Locating SIP Servers,Jun 02

RFC 3264 Offer/Answer Model with the Session Description Protocol (SDP), Jun 02

RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification,Jun 02

RFC 3310 Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)

RFC 3311 The Session Initiation Protocol (SIP) UPDATE Method,Sept 02

RFC 3312 Integration of Resource Management and Session Initiation Protocol (SIP)

RFC 3313 Private SIP Extensions for Media Authorization,Jan 03

RFC 3320 signaling compression (SigComp)

RFC 3322 Signaling Compression (SigComp) Requirements & Assumptions

RFC 3323 A Privacy Mechanism for the Session Initiation Protocol (SIP), Nov 02

RFC 3326 The Reason Header Field for the Session Initiation Protocol (SIP), Dec 02

RFC 3327 SIP Extension Header Field for Registering Non-Adjacent Contacts, Dec 02

RFC 3329 Security Mechanism,Jan 03

RFC 3428 SIP Extension for Instant Messaging,Dec 02

RFC 3455 Private Header (P-Header) Extensions to the SIP for the 3rd-Generation Partnership Project (3GPP), Jan 03

RFC 3515 The Session Initiation Protocol (SIP) Refer Method,Apr 03

RFC 3608 SIP Extension Header Field for Service Route Discovery During Registration, Oct 03

RFC 3680 Session Initiation Protocol (SIP) Event Package for Registrations, Mar 04

RFC 3841 Caller Preferences,Aug 04

RFC 3891 Replaces Header,Sept 04

RFC 3892 Referred By,Sept 04

RFC 3903 SIP Extension for Event State Publication,Oct 04

RFC 3911 Join Header,Oct 04

RFC 4028 Session Timers,Apr 05

RFC 4457 The P-User-Database P-Header

draft-ietf-mmusic-media-loopback-05 - An Extension to the Session Description Protocol (SDP) for Media Loopback SIP End-to-End Performance Metrics -

draft-malas-performance-metrics-06.txt

7.2 Security RFC 4346 The TLS Protocol Version 1.1

RFC 4366 Transport Layer Security ( TLS) Extensions

RFC 4474 Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)

7.3 ENUM RFC 3482 Number Portability in the Global Switched Telephone Network (GSTN): An Overview

RFC 3764 enumservice registration for SIP Addresses-of-Record

RFC 3762 ENUM Service Registration for H.323 URL

RFC 3761 The E.164 to URI DDDS Application (ENUM)

RFC 3953 Enumservice Registration for Presence Services

RFC 4002 IANA Registration for ENUMservices web and ft

RFC 4114 E.164 Number Mapping for the Extensible Provisioning Protocol (EPP)

RFC 4355 IANA Registration for Enumservices email, fax, mms,ems and sms

RFC 4415 IANA Registration for Enumservice Voice

RFC 4414 An ENUM Registry Type for the Internet Registry Information Service (IRIS)

RFC 4769 IANA Registration for an Enumservice Containing Public Switched Telephone Network (PSTN) Signaling Information

RFC 4725 ENUM Validation Architecture


7.0 References


23/24


7.4 RTP/RTCP RFC 3550 RTP: A Transport Protocol for Real-Time Applications

RFC 3611 RTP Control Protocol Extended Reports (RTCP XR)

RFC 3711 The Secure Real-time Transport Protocol (SRTP)

Internet Draft:Extensions to RTP for Diffie-Hellman Key Agreement for SRTP

draft-wing-avt-rtp-noop-01 - RTP No-Op Payload Format

7.5 Nat Traversal RFC 3489 STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

RFC 3581 An Extension to SIP for Symmetric response routing

RFC 3605 RTCP attribute in SDP

draft-ietf-behave-turn Obtaining Relay Addresses from Simple Traversal of UDP Through NAT (STUN)

draft-ietf-mmusic-ice-13 - Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols

draft-rosenberg-midcom-turn-08 Traversal Using Relay NAT (TURN):

draft-ietf-sip-outbound - Managing Client Initiated Connections in SIP

7.6 3GPP Specifications TS23.002 - Network Architecture

TS24.229 - IMS call control protocol based on SIP and SDP

TS29.228 - IMS Cx and Dx interfaces:signalling flows and message contents

TS29.229 - IMS Cx and Dx interfaces based on the Diameter protocol; Protocol details

TS29.328 - IMS Sh interface:signalling flows and message content

TS29.329 - IMS Sh interface based on the Diameter protocol; Protocol details

TS31.103 - Characteristics of the IMS Identity Module (ISIM) application

TS33.203 - 3G security;Access security for IP-based services


24/24


All statements, technical information and recommendations related to the products herein are based upon informa-

tion believed to be reliable or accurate. However, the accuracy or completeness thereof is not guaranteed, and no

responsibility is assumed for any inaccuracies. The user assumes all risks and liability whatsoever in connection with

the use of a product or its application. JDSU reserves the right to change at any time without notice the design,

specifications, function, fit or form of its products described herein, including withdrawal at any time of a product

offered for sale herein. JDSU makes no representations that the products herein are free from any intellectual

property claims of others. Please contact JDSU for more information. JDSU and the JDSU logo are trademarks of

JDS Uniphase Corporation. Other trademarks are the property of their respective holders. 2007 JDS Uniphase

Corporation. All rights reserved. 30149196 000 0907 IPVIDEOQOS.WP.ACC.TM.AE

Test & Measurement Regional Sales

IMS Whitepaper Intro

Documents

Transcript of IMS Whitepaper Intro