Solving IMS Problems when IMS Tools 2010 Bootcamp IMS is ...
IMS Whitepaper Intro
-
Upload
jayesh-nambiar -
Category
Documents
-
view
214 -
download
0
Transcript of 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
-
8/9/2019 IMS Whitepaper Intro
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
-
8/9/2019 IMS Whitepaper Intro
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
-
8/9/2019 IMS Whitepaper Intro
4/24
4White Paper: IMS Simplified: The Evolution of the SIP Client
Calls Jane
SIP
Signaling
Talking
Hangs up
Rings
Answers
Talking
INVITE: sip:[email protected]
ACK
BYE
180Ringing
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).
-
8/9/2019 IMS Whitepaper Intro
5/24
5White Paper: IMS Simplified: The Evolution of the SIP Client
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
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.
-
8/9/2019 IMS Whitepaper Intro
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
6White Paper: IMS Simplified: The Evolution of the SIP Client
sip:[email protected]_xyz.com
1 SIP Message
Proxysip:joe.user@company_xyz.com
Location
Server
Registrar
4 SIPM
essage
2WhereisJo
e?
3Answ
er
sip:[email protected]_xyz.com
1 Register
Proxysip:joe.user@company_xyz.com
Location
Server Registrar
3 200OK
2 UploadLocation Information
-
8/9/2019 IMS Whitepaper Intro
7/24
7White Paper: IMS Simplified: The Evolution of the SIP Client
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/9/2019 IMS Whitepaper Intro
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.
8White Paper: IMS Simplified: The Evolution of the SIP Client
-
8/9/2019 IMS Whitepaper Intro
9/24
9White Paper: IMS Simplified: The Evolution of the SIP Client
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
-
8/9/2019 IMS Whitepaper Intro
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.
10White Paper: IMS Simplified: The Evolution of the SIP Client
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
-
8/9/2019 IMS Whitepaper Intro
11/24
11White Paper: IMS Simplified: The Evolution of the SIP Client
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.
-
8/9/2019 IMS Whitepaper Intro
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.
12White Paper: IMS Simplified: The Evolution of the SIP Client
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
-
8/9/2019 IMS Whitepaper Intro
13/24
13White Paper: IMS Simplified: The Evolution of the SIP Client
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.
-
8/9/2019 IMS Whitepaper Intro
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.
14White Paper: IMS Simplified: The Evolution of the SIP Client
S-CSCF evaluates
initial filter criteria
INVITE
INVITE
PRACK
183 Session Progress
183 Session Progress
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
-
8/9/2019 IMS Whitepaper Intro
15/24
15White Paper: IMS Simplified: The Evolution of the SIP Client
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
-
8/9/2019 IMS Whitepaper Intro
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.
16White Paper: IMS Simplified: The Evolution of the SIP Client
5.0 SIP Clients for IMS
-
8/9/2019 IMS Whitepaper Intro
17/24
17White Paper: IMS Simplified: The Evolution of the SIP Client
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.
-
8/9/2019 IMS Whitepaper Intro
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
18White Paper: IMS Simplified: The Evolution of the SIP Client
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
-
8/9/2019 IMS Whitepaper Intro
19/24
19White Paper: IMS Simplified: The Evolution of the SIP Client
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
-
8/9/2019 IMS Whitepaper Intro
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.
20White Paper: IMS Simplified: The Evolution of the SIP Client
-
8/9/2019 IMS Whitepaper Intro
21/24
21White Paper: IMS Simplified: The Evolution of the SIP Client
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
-
8/9/2019 IMS Whitepaper Intro
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
22White Paper: IMS Simplified: The Evolution of the SIP Client
7.0 References
-
8/9/2019 IMS Whitepaper Intro
23/24
23White Paper: IMS Simplified: The Evolution of the SIP Client
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
-
8/9/2019 IMS Whitepaper Intro
24/24
24White Paper: IMS Simplified: The Evolution of the SIP Client
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