IMS Whitepaper Intro

White Paper
IMS Simplified:
The Evolution of the SIP Client
Introduction
Flexibility has been a well-known attribute of the session initiation protocol (SIP). SIP is at the heart
of the IP multimedia subsystem (IMS), exemplifying the extensibility of the SIP protocol. This paper
provides a general discussion of the SIP protocol and highlights the differences between pure SIP clients
and IMS clients. Many books and white papers have been written about SIP and IMS, yet it is difficult
to find a source of information that clearly identifies the differences between a SIP client and an IMS
client. This paper was created out of the common desire among the authors to provide a simplified view
of 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 for
residential and now for businesses. SIP has become the accepted signaling for VoIP, although SIP clients
and Proxies can contain certain liberties of the standards that might create issues when using different
SIP implementations. This first phase of SIP for VoIP was a solid design, stable in requirements, but
fairly simple in nature.
Today, there is a new game in town that has thrust SIP into warp speed. That technology is IMS. SIP
was always designed to be more then just a vehicle for VoIP, and IMS will put that to the test. Standards
bodies are moving very fast to modify and extend standards for IMS. Since IMS is simply an
architecture, the real winners are the applications running over the IMS architecture. Progress will move
quickly as new applications will drive new requirements on SIP clients. This paper will examine what
new requirements will be placed on a SIP client. Because of the nature of IMS, SIP client changes will
go 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.
Written by:
Jay Stewart
Director of Corporate IMS Strategy
JDSU
Barry Constantine
Principal Member Technical Staff
JDSU
Lincoln Lavoie
Senior Engineer
University of New Hampshire
InterOperability Lab
NORTH
WEBSITE : www.jdsu.com/test
AMERICA : 800 498-JDSU (5378) WORLDWIDE : +800 5378-JDSU WEBSITE : www.jdsu.com
White Paper: IMS Simplified: The Evolution of the SIP Client 2
2.0 Standards bodies driving IMS
There are standards bodies for all facets of telecommunications and data communications. For IMS to span
all 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 the
global standard for a 3G network—a collaboration of standards bodies make up the IMT-2000. Inside
the IMT-2000 are two standards bodies that are the main focus for IMS: Third Generation Partnership
Project (3GPP) and 3GPP2. 3GPP deals with UMTS networks and 3GPP2 deals with code division
multiple access (CDMA) networks. Both have created standards for IMS, but most will refer to the
3GPP standards. 3GPP introduced packet switched voice services in a standard called R4. IMS was
introduced 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 Internet
Engineering 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 IETF
started 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 in
data over cable services interface specification (DOCSIS) 2.0. Wireline groups such as the European
Telecommunications Standards Institute (ETSI) and Telecoms & Internet converged Services & Protocols
for Advanced Networks (TISPAN) began defining (EMEA) wireline extensions to IMS. The Alliance for
Telecommunications 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, the
SIP working group is dedicated to driving all standards related to the SIP protocol. Once IMS chose
SIP as a basis, it became clear that the SIP working group needed expansion. Therefore, the IETF
created 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 this
group does not define any IMS specification, it does deal with applications that will ride on top of the
IMS architecture. To date, they have defined Push to Talk and IM for IMS architectures.
IMS Architecture Standards Organization Scope or Focus Standards Contributions

Fixed Line Internet Engineering All IP Networks SIP and other protocols (e.g.COPS,
Mobile Cable Task Force (IETF) Diameter, etc.)
ETSI
3GPP//2 DOCSIS 2.0
TISPAN Third Generation Universal Mobile Telecommunications Service IP Multimedia Subsystems (IMS)
Partnership Project (3GPP) (UMTS)(Wideband Code Division Multiple Access
IETF
SIP, SIP-T, RTP [W-CDMA]) mobile networks and other access networks
Third Generation CDMA2000 mobile networks and other Multimedia Domain (MMD)
OMA Partnership Project 2 (3GPP2) access networks
Open Mobile European Telecom Next generation wireline networks NGN effort by TISPAN
Applications
Standards Institute (ETSI)
International Telecommunication Next generation wireline networks Focus Group on Next Generation
Union (ITU-T) Networks (FGNGN) effort by ITU-T SG13
NGN and other ITU-T Study Groups
Figure 2.1 Overview of the standards bodies driving IMS 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
3.0 Introduction to SIP
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 protocol
and converts the various PSTN phone mechanisms (off-hook, digit dialing, hold, etc.) into packetized
signaling messages to establish voice calls across a network. SIP has established itself as the primary
signaling 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 calls
over an IP network (private network or the public internet).
SDP Codecs
SIP RTP DNS Application
TCP UDP Transport
IP Network
Ethernet Physical/Data Link
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 the
transmission control protocol (TCP), a reliable transport layer. Domain name service (DNS) is also a
critical component of SIP communication sessions. Just as in normal internet web surfing, DNS is used
during 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 communication
session 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 a
simple ladder diagram that highlights the basic establishment of a voice/video communication and the
role of SIP versus RTP.
Joe@domain.com Jane@domain.com
“Calls” Jane INVITE: sip:jane@domain.com
180–Ringing Rings
SIP
Signaling
200–OK Answers
ACK
Talking RTP Talking
Hangs up BYE
SIP
Signaling 200–OK
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 the
actual text associated with the IM session. Since IM is not a real-time media stream, this is not an
exception to the rule; rather an efficient partition and usage of the native text implementation of the
SIP 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 session
establishment (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 specific
configuration parameters to be used during the actual media session (i.e. Party A is a soft phone
supporting G.726 codec, Party B supports G.726 and G.729).
To provide the presence and session negotiation services, SIP relies on various entities within a SIP
based 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 Location
Server.
– Location Server functionality may be a separate entity or may be a database like function within
the 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 described
above are:
1. SIP Registration
2. SIP Session Establishment
These scenarios are discussed in the following sections.
3.1.1 SIP Registration

For SIP Users to communicate with each other, the network must resolve a SIP (URI) into the user’s
physical location and the network path to the called user (the called user’s IP address). Another way to
think of a SIP URI is to equate this to the user’s 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 SIP
name that a calling party will use to reach the called party. Most times the public URI is very much like
a public email address.
A Public URI is more of a logical address where a private URI is more of a physical address. For
instance, 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:joe.user@pda.company_xyz.com
sip:joe.user@pc.company_xyz.com
In SIP, there are means to register and resolve public and private URIs. In Figure 3.3, the SIP Register
process is indicated by steps (1) and (2) in the flow diagram.
2 U
ploa
Infor d Locatio
mati n
on
1 R
egi ster
Location
Server Registrar
3 200 O
K sip:joe.user@pc.company_xyz.com
Proxy
Figure 3.3 SIP Elements and Message Flow for SIP Registration
First, Joe User’s location is registered as his PC location by means of a SIP REGISTER message. Joe’s PC
will send this REGISTER message to the registrar (Step 1 in Figure 3.3). The registrar then forwards this
REGISTER message to the location server (Step 2 in Figure 3.3). In many cases, the registrar and location
server are logically and physically contained in a single server. The result is a 200 OK message from the
registrar. The 200 OK message will contain the contact header field, with the actual addresses of any UE
device associated with that URI, indicating the successful registration binding.
The location server now can resolve Joe’s public URI (sip:joe.user@company_xyz.com) to his private
URI (sip:joe.user@pc.company_xyz.com). And if Joe should log off of his PC and onto his PDA, then
the register process occurs again and Joe’s private location would then be registered to his PDA
(sip:joe.user@pda.company_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 voice
call to Joe User. Jane is using a PC client which supports SIP and VoIP. For the SIP session
establishment, Figure 3.4 will be used to discuss the message flow.
Location
Server
2
3
Wh
Registrar
ere
An
sw
is J
er
oe
ge
essa
?
IP M
4 S
1 SIP Message sip:joe.user@pc.company_xyz.com
sip:jane.user@yahoo.com Proxy
Figure 3.4 SIP Elements and Message Flow for SIP Session Establishment
First, Jane’s PC must locate Joe’s physical location (and IP address). Message 1 is an SIP INVITE
message (more details on SIP message types and formats in Section 3.2) and this message is first sent
to the SIP Proxy, who then obtains Joe’s location (IP address) from the registrar or location server.
Once the Proxy determines Joe’s location (messages 2 and 3) by querying the Location Server, the SIP
INVITE message is forwarded to Joe’s PC and the flow of SIP messages required for session set-up
commences. Since the proxy has identified Joe’s location for the first INVITE message, subsequent
messages from Jane will not require a location look-up (unless of course Joe’s location has changed
which is outside the scope of this introductory paper).
SIP session establishment also supports the concept of endpoint capability negotiation. Consider the
situation where one endpoint can handle voice and video, while the other endpoint can only handle
voice. During the session establishment phase, SIP provides the ability for the endpoints to discover and
describe the payload message contents and characteristics. To provide for this capability, SIP uses the
Session Description Protocol (SDP) which is carried in the actual message body of the initial SIP
messages. Figure 3.5 is a more detailed message diagram of a SIP sessions establishment and provides
an examination of the SDP components of the SIP session establishment.
Jane UA Joe UA
1 INVITE() Content Type indicates

SDP message
Jane’s
2 100–Trying() Capability
Description
3 100–Ringing()
4 200–OK()
Content Type indicates
SDP message
5 ACK() Joe’s
Capability
Description
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 audio
capabilities present in Jane’s phone (or other UE device). Some of the more interesting fields with
respect to Jane’s session description are highlighted in Figure 3.5.
SDP involves session-level information and media-level information. Referencing Figure 3.5, the lines
before the “m” line are session level and after the “m” line are media level information. In the session
level 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 Jane’s INVITE Message
The media level section is where audio/video capabilities of each party are established. The media level
section contains a single “m” line and a variable number of “a” lines which describe the specifics about
the 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 “a”lines below provide more specific detail for the audio codecs supported.
b=AS:64 Bandwidth information
a=rtpmap:0 PCMU/8000/1 Attributes of the “0”codec reference in the “m”line; in this case PCM uLaw encoding
a=rtpmap:8 PCMA/8000/1 Attributes of the “8”codec reference in the “m”line; in this case PCM ALaw encoding
a=rtpmap:98 G726-32/8000/1 Attributes of the “98”codec reference in the “m”line; in this case G.726 encoding
a=rtpmap:97 AMR/8000/1 Attributes of the “97”codec reference in the “m”line; in this case Adaptive Multi-rate Rate encoding
a=rtpmap:101 telephone-event/8000 Attributes of the “101”codec reference in the “m”line; in this case PCM uLaw encoding
Table 3.2 Media Level Information in Jane’s 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 SDP
offer. The answer from the receiver also has order of preference and the common highest preference
coder-decoder (CODEC) is used.
3.2 SIP Message Format Overview

This section provides a general overview of SIP message format. Like HTTP, SIP is a request/response
type protocol. Messages such as INVITE and REGISTER, for example, are request-type messages, while
status messages like 100:TRYING, 200:OK, etc… are response-type messages. Table 3.3 summarizes the
various 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 servers
PRACK 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 caller’s 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

4.0 IMS Basics
4.1 IMS Network Groundwork

The IMS technologies are best described as an architecture designed to leverage and extend what is the
next generation network. The goal of the architecture is to unite mobile and fixed line services, while
standardizing the platforms used to offer new services to the consumer. Figure 4.1, below, shows a
simplified overview of the core components of an IMS network topology. As in “plain-VoIP”, SIP is used
as the session signaling and control mechanism between the IMS terminal (UE or user equipment) and
the 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 for
authenticating the user, maintaining the registration state of that user, and routing SIP messages to and
from that user. An important consequence to note regarding the IMS architecture is its design for
horizontal scalability. Nearly every component in the network may be replicated to facilitate load
balancing and geographic diversity.
Application
Home Subscriber AS Server
Server
SIP
HSS
S-CSCF
Diameter
SIP Call
I-CSCF Session
Control
SIP Functions
P-CSCF
SIP
Wireless Net
IMS UAs
(PDAs, smartphones, etc)
Figure 4.1 Simplified IMS Topology
Because the S-CSCF serves as the heart of the IMS architecture, it is protected from the harsh internet
and mobile worlds by the proxy-CSCF (P-CSCF) and interrogating-CSCF (I-CSCF.) From the
perspective 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 SIP
messages to this server and receive them from this server. Two important items should be noted about
the P-CSCF: 1) Once the user is registered, or authenticated, to the network, the same P-CSCF is used
throughout the lifetime of the registration; 2) The P-CSCF may or may not be located within the user’s
home domain/network. At this point, it is important for us to define some terms relating to IMS
networks.
– 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 entry
point into the operator’s domain. P-CSCF’s from inside and outside of the operator’s network will
locate the I-CSCF via domain-name-service (DNS) query, and the DNS systems shall provide a form of
load-balancing, by “routing” successive queries to different I-CSCF servers. It is important to note the
P-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 the
given UE. The home subscriber server (HSS) acts as the user database for the IMS network, storing
information such as public and private user identities, passwords, enabled services (and their trigger
information), and the S-CSCF assigned to the user. When the I-CSCF receives a message from the
P-CSCF server, it queries the HSS for the assigned S-CSCF, and forwards the message to the appointed
S-CSCF. That query is made using the DIAMETER protocol. Returning to the S-CSCF, the SIP server
responsible for authenticating and maintain the user registration states, it is apparent that the S-CSCF
also needs access to the information stored within the HSS. In this way, both the I-CSCF and S-CSCF
communicate with the HSS over an interface referred to as the Cx interface, which is standardized via
the DIAMETER protocol. Lastly, it should be noted that the Cx interface is only available within a
service providers own network and never exposed to either another operator’s network or the internet.
To this point, this paper has discussed the major components relating to the SIP signal routing within
the IMS architecture, leaving the discussion of the “peripherals:” application servers (AS), media
resource 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 architecture
because 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 those
services. These distinct networks are sometimes referred to as silos (vertical infrastructure). Because
IMS is a standardized architecture implementing a flexible signaling system (SIP), the service provider
should be able to deploy any new service over their network by simply turning up a new application
server and provisioning it within the HSS. Although this may seem over simplified, examine what is
already known. The IMS architecture defines the IP network topology and signaling mechanisms
between 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 of
the well-known services. Returning to the discussion of signaling to and from the AS, there are two
defined interfaces for the SIP-based AS, the ISC and the Sh . The ISC interface is SIP based between the
S-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 the
HSS for user information and configure parameters.
Lastly, there are three additional components to discuss: MRF, BGCF, and MGF. The BGCF and MGF
play 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) traffic
into the format required by the PSTN. This allows IMS users to place and receive calls to and from the
existing PSTN network. The MRF provides the media resources for features such as automated prompts
and announcement services.
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 registration
messages, sent initially from the UE device to the P-CSCF. However, before the UE can transmit the
REGISTER message to the P-CSCF, it must discover the IP network details for the physical network in
which it currently resides. Since the IMS architecture has been developed to remain independent of the
physical network (with the exception of some bandwidth and quality of service (QoS) requirements) this
process is not officially part of the IMS design. Instead these details are to remain a function of the physical
network and its underlying protocols, like DHCP for example,(see Note 1.)
IMS UE Mobile P-CSCF I-CSCF S-CSCF HSS

Network
Note 1
Register
DNS Lookup Register

SIP for Domain User Authorization Request
User Authorization Answer
Select S-CSCF
Server for UE Register Media
Authorization
Request
Media
Authorization
401 Auth Request Answer
Build
401 Auth Request authorization
401 Auth Request
vectors
Register
Register Check
authorization
Register response
Server
Assignment
Request
Server
P-CSCF subscribes Assignment
to registration event 200 OK Answer
package
200 OK
200 OK
UE subscribes SUBSCRIBE
to registration event 200 OK
package NOTIFY
200 OK
SUBSCRIBE
SUBSCRIBE
200 OK
200 OK
NOTIFY
NOTIFY
200 OK
200 OK
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.
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 not
be within the user’s home network (the user may be roaming in another country) resolves the
appropriate I-CSCF through a DNS query for the SIP handler’s domain in the REGISTER request. Once
the I-CSCF is located, the P-CSCF inserts a number of additional headers responsible for network and
charging identification and forwards the message to the I-CSCF. The I-CSCF will query the HSS using
the User-Assignment-Request DIAMETER function for the S-CSCF that has been assigned to the user’s
public 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 a
stateful proxy, inserting its signaling address as a via header in the SIP message and forwards the
message 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-CSCF
with the authorization vectors required to build the SIP challenge responses (401 Authorization
Required) and the security association between the P-CSCF and the UE. The S-CSCF forwards this
message back to the I-CSCF. The I-CSCF relays this message to the P-CSCF, where the P-CSCF removes
any “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 401
Authorization required message, the UE will create a new REGISTER request, including the challenge
response and again forward this message to the P-CSCF. The P-CSCF again forwards this message to
the I-CSCF, where the HSS is queried and the S-CSCF is located, and, finally, the I-CSCF forwards the
request to the S-CSCF. The S-CSCF checks the challenge response to verify correctness. Again, assuming
no problems exist and the challenge response is correct, the S-CSCF informs the HSS of the
registration, 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 UE
device subscribe to the registration event package, via the SIP SUBSCRIBE method. This subscription
allows the network to inform the UE device of changes to the network. For example, the case where the
S-CSCF currently hosting the UE device is being taken down for maintenance or the user’s account has
been 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 following
example, shown below in figures A and B, the case of an IMS subscriber establishing a VoIP call with a
second subscriber is examined. In this example, both subscribers will be located within the same IMS
home network. The first subscriber (UE1) sends an INVITE request, targeting the second subscriber’s
public identity to the proxy-CSCF. The P-CSCF forwards the message to the user’s assigned S-CSCF.
The S-CSCF first evaluates the initial filter criteria, which in this simplified case, does not require any
actions. 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 should
contain an SDP offer, and that the SDP offer should include some QoS requirements. These
requirements are considered part of the preconditions, if the UE devices require QoS to be supported.
The SIP precondition mechanisms are defined by RFC-3312.
When UE2 receives the INVITE request, it should respond with the 183 session progress provisional
response. This response serves two purposes: it establishes an early dialog, and it should contain an
updated SDP answer (possibly including updated QoS requirements). It should be noted at this point
that 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. When
UE1 receives the response, it should process the response and SDP answer, responding with the PRACK
response. 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 provisional
response, and be responded to with a 200 OK response. Note: This is not the 200 OK final response to
the initial INVITE request. When UE2 receives the PRACK response, it should also begin the process of
reserving 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 offer
with the updated QoS support and requirements. The UPDATE message is transmitted within the early
dialog established by the INVITE/183 Session Progress transaction, and therefore must follow the same
routing path. The UPDATE message is responded to with a 200 OK response, containing the SDP
answer with UE2’s updated QoS resources. At this point the second subscriber is alerted about the
incoming call, as the required preconditions have now been met.
IMS UE1 IMS UE2 P-CSCF 1 I-CSCF S-CSCF HSS
INVITE
INVITE
S-CSCF evaluates
INVITE initial filter criteria
INVITE
183 Session
Progress
183 Session Progress
PRACK
PRACK
PRACK
PRACK
200 OK
200 OK
200 OK
200 OK
UPDATE
UPDATE
UPDATE
UPDATE
200 OK
200 OK
200 OK
200 OK
Figure A: Stage 1 of a basic IMS session establishment.

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 similar
PRACK, 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 response
to the original INVITE request. As defined by SIP, this final response is sent reliably and should be
responded to with an ACK response. At this point, the RTP media path should be established between
UE1 and UE2
IMS UE1 IMS UE2 P-CSCF 1 I-CSCF S-CSCF HSS
180 Ringing
UE2 alerts/rings
to request user 180 Ringing
actions
180 Ringing
180 Ringing
PRACK
PRACK
PRACK
PRACK
200 OK
200 OK
200 OK
200 OK
200 OK
UE2
accepts/answers 200 OK
the call
200 OK
200 OK
ACK
ACK
ACK
ACK
RTP and
Media
Figure B: Stage 2 of a basic IMS session establishment.

5.0 SIP Clients for IMS
While the IMS architecture is a relatively complex network of components, from the perspective of the
end consumer, the most important of those components is the user equipment (UE). This interface
represents the face of IMS to the user and will be the vehicle for delivering these new services and
applications 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 standards
have defined what may be considered a SIP usage profile. The profile defines which SIP standards
should be included in IMS devices, and how SIP should be used to establish and control the media
sessions. Of key focus in these definitions are: security, reliability, bandwidth, and performance. In the
following 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 RFC
3455, “[The] 3GPP notified the IETF SIP and SIPPING working groups that the existing SIP documents
provided almost all of the functionality needed to satisfy the requirements of the IMS, but that they
required some additional functionality in order to use SIP for this purpose.” This section will attempt
to 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 the
Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP),” this RFC defines
6 additional header fields for use within SIP messages. Some of these header fields must be used by UE
implementations, while others exist only within the IMS network for security purposes. From the
perspective 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 charging
within 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 be
thought of as the definition of a usage profile. The base SIP specification is RFC-3261, and includes the
methods necessary to establish and control basic sessions. SIP has been further expanded upon by
additional 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 additional
specifications mandatory. RFC-3262 defines the mechanisms necessary to ensure the delivery of 1xx
provisional responses within the SIP protocol. The 1xx responses are used to establish an early dialog
during the process of establishing a session. Within the IMS architecture, these 1xx responses play a
critical role in the selection of the QoS requirements and must not be lost due to network or
transmission errors. For this reason, the IMS SIP profile requires the use of the 100rel header and
support of the PRACK method, as described by RFC-3262.
Beyond the P-header and PRACK extensions, the IMS SIP profile requires the support of several other
SIP methods (defined within various RFCs). For example, RFC-3265 describes the SUBSCRIBE and
NOTIFY methods, as seen above in the registration ladder diagrams, are relied upon to inform the UE
and P-CSCF of network initiated changes to the UE registration state. Additionally, RFC-3312 describes
the mechanisms for incorporating quality of service extensions into the SIP and SDP signaling, referred
to 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; access
security (security between the UE device and the IMS network) and user/network authentication. Both
of 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 transport
security mechanisms. As such, it relies on other means to ensure the security of the connection between
two SIP devices. In “plain-VoIP”, this is often accomplished using transport layer security (TLS) to
encrypt the SIP messages on a hop-by-hop basis, in the same way Internet shopping traffic is encrypted
between the web server and browser. Obviously, there are other security protocols available, such as IP
security (IPsec). Within the IMS architecture, access security (the security associations between the
network and the UE devices) is accomplished using IPsec. The IPsec security associations are negotiated
during the registration phase and are based upon the IK and CK values stored within the HSS and
transmitted to the P-CSCF within the 401 authorization required message. Once the IPsec session has
been 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 major
players 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 REGISTRATION
request, which includes a mostly empty authorization header field. When the request reaches the
S-CSCF, it queries the HSS. The HSS returns a set of authentication vectors to the S-CSCF. These
vectors include a random value and the expected UE response, which is based on a mathematical
operation between the shared secret and the random value. The vector also includes some of the values
used 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 response
back to the UE. The UE receives the challenge response and extracts and checks the value of the AUTN
to authenticate the network. The UE must then build the challenge response from its shared secret and
the 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 in
3GPP specification 33.203, while the network security is defined within 3GPP 33.210. The AKA digest
based authentication is defined in RFC-3310. The 3GPP 24.229 document also describes the UE
procedures in detail.
5.3 Signaling compression

Signaling compression (RFC 3320) is a method to compress a message generated by protocols such as
SIP. Although the RFC is written in an application independent manner, the major driver for signaling
compression is SIP. Most multimedia applications use text-based protocols and are designed for larger
communication pipes. With IMS this means that applications are moving to the wireless networks and
handsets. These devices and network may not be able to handle the large bandwidth needed when using
SIP text based signaling. SigComp is designed to handle this situation and is used between UE-PCSCF
link (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 basic
components: compression and decompression. Decompression is by a universal decompressor virtual
machine (UDVM) optimized for the task of running decompression algorithms. The UDVM can be
configured to understand the output of many well-known compressors such as DEFLATE (RFC-1951).
The diagram below shows SigComp architecture.
Local Application
Application Message
Compartment Identifier Decompressed Message Compartment Identifier
Compressor Compressor
Dispatcher Dispatcher
State Handler
Compressor 1 State 1
Decompressor
(UDVM)
Compressor 2 State 2
SigComp Layer
SigComp Message SigComp Message
Transport Layer
Other RFC’s 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
5.4 ENUM
Since one of the first applications that might be used in an IMS environment is voice, it is important to
understand ENUM and E.164. Also it is possible that a single phone number could be assigned for each
device 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.164
Telephone numbers can be up to 15 digits long. The E.164 specifies country code, national destination
number and subscriber number.
The ITU and IETF have adopted a standard to map E.164 numbers using URI and DNS. The goal of
the ENUM standard is to provide a single number to replace the multiple numbers and addresses for
an individual's home phone, business phone, fax, cell phone, and e-mail. RFC 3761 describes the
mapping 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, the
subscriber 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

Dialed
+1-919-111-2222
SIP:name@domain.com “Call Setup”
Response
SIP:name@domain.com
DNS Lookup
2.2.2.2.1.1.1.9.1.9.1.e164.arpa
DNS Server
5.5 NAT traversal

Since it is most likely that the client will be behind a network address translator (NAT), it is important
to 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 a
Router or firewall. The reason people use NAT is to allow for multiple private IP addresses to be mapped
to 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 on
RFC 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 client
must 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 is
traversal using relay NAT (TURN). TURN addresses the symmetrical NAT issue. The TURN server
must be in the customer’s demilitarized zone (DMZ) or in the service provider’s network. There is
another IETF draft called Interactive Connectivity Establishments. This is not a protocol, but methods
to 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 Initiation
Protocol (SIP) for Symmetric Response Routing. Currently, SIP provides the client with the source IP
address 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 has
proven 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 the
Via 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 the
received 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 devices
such 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 access
and translate the port. In these cases, the NA(P)T devices revert to simple NAT operation. This means
that all traffic returning to the NAT will be mapped onto one client causing the service to fail. There are
a few solutions to this problem: one is to use TLS which operates at layer4 in the OSI Reference Model
and therefore does not mask the port number, or to encapsulate the IPsec within UDP - the latter being
the 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 the
expanded address space. With clients moving to mobile handsets and other endpoints, IPv4 does not
have enough address space for all end points. Most applications should not notice a change and IPv6
should 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 that
will bring IPv6 into the mainstream. While NATing for IPv4 may be feasible in IMS landline
applications, it would be very unwieldy (if not impossible) for mobile operators to deploy a NAT-ed
IPv4 networks. The trend certainly appears to be in favor of IPv6 for mobile networks.
6.0 Conclusions
The subject of IMS is immense and very complicated. The intent of this white paper was to provide the
reader with a starting point to understand the standards surrounding IMS, the basic concepts of the SIP
protocol, 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 more
specific areas of IMS client operation (i.e. SIGCOMP, Security, SIP extensions, etc.). Section 7 provides
a 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 is
a difference between reading about the protocol and actually using the protocol. The authors have all
gained 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
7.0 References
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.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
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
NORTH AMERICA LATIN AMERICA ASIA PACIFIC EMEA WEBSITE :

TEL : 1 866 228 3762 TEL : +55 11 5503 3800 TEL : +852 2892 0990 TEL : +49 7121 86 2222 www.jdsu.com/test
FAX : +1 301 353 9216 FAX : +55 11 5505 1598 FAX : +852 2892 0770 FAX : +49 7121 86 1222

IMS Whitepaper Intro

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

IMS Whitepaper Intro

Încărcat de

Drepturi de autor:

Formate disponibile

White Paper

IMS Architecture Standards Organization Scope or Focus Standards Contributions

SIP RTP DNS Application

TCP UDP Transport

Ethernet Physical/Data Link

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

“Calls” Jane INVITE: sip:jane@domain.com

Talking RTP Talking

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

3.1 Fundamental SIP Elements and Session Flow

3.1.1 SIP Registration

3.1.2 SIP Session Establishment

1 SIP Message sip:joe.user@pc.company_xyz.com

1 INVITE() Content Type indicates

Table 3.1 Session Level Information in the Jane’s INVITE Message

Table 3.2 Media Level Information in Jane’s INVITE Message

3.2 SIP Message Format Overview

Table 3.3 SIP Request Message Summary

Table 3.4 SIP Response Message Summary

4.1 IMS Network Groundwork

4.2 Example IMS Call Flows

4.2.1 IMS UE Registration

IMS UE Mobile P-CSCF I-CSCF S-CSCF HSS

DNS Lookup Register

4.2.2 IMS Session Establishment (VoIP call example)

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

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

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

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

5.1 SIP Extensions

5.3 Signaling compression

SigComp Message SigComp Message

Other RFC’s associated with SigComp are

SIP Proxy SIP Proxy

5.5 NAT traversal

5.6 IPv6 Support

7.1 SIP and SIP extensions for IMS

7.5 Nat Traversal

7.6 3GPP Specifications

Test & Measurement Regional Sales

NORTH AMERICA LATIN AMERICA ASIA PACIFIC EMEA WEBSITE :

S-ar putea să vă placă și