IMS Simplified The Evolution of the SIP Client (en)

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 AMERICA : 800 498-JDSU (5378) WEBSITE : www.jdsu.com/test 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 Mobile 3GPP//2 Fixed Line ETSI TISPAN IETF SIP, SIP-T, RTP OMA Open Mobile Applications Standards Organization Cable DOCSIS 2.0 Internet Engineering Task Force (IETF) Third Generation Partnership Project (3GPP) Third Generation Partnership Project 2 (3GPP2) European Telecom Standards Institute (ETSI) International Telecommunication Union (ITU-T) CDMA Development Group (CDG) CableLabs® Scope or Focus All IP Networks Standards Contributions SIP and other protocols (e.g.COPS, Diameter, etc.) IP Multimedia Subsystems (IMS) Universal Mobile Telecommunications Service (UMTS)(Wideband Code Division Multiple Access [W-CDMA]) mobile networks and other access networks CDMA2000 mobile networks and other Multimedia Domain (MMD) access networks Next generation wireline networks NGN effort by TISPAN Next generation wireline networks Figure 2.1 Overview of the standards bodies driving IMS All mobile networks Cable IP networks Focus Group on Next Generation Networks (FGNGN) effort by ITU-T SG13 NGN and other ITU-T Study Groups Open Mobile Alliance (OMA) and Push-to-Talk over Cellular PacketCable 2.0 Project White Paper: IMS Simplified: The Evolution of the SIP Client 3 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. White Paper: IMS Simplified: The Evolution of the SIP Client 4 Joe@domain.com Jane@domain.com “Calls” Jane INVITE: sip:jane@domain.com 180–Ringing SIP Signaling 200–OK Rings Answers ACK Talking RTP Talking Hangs up SIP Signaling BYE 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). White Paper: IMS Simplified: The Evolution of the SIP Client 5 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 PeerPeer, but this is mostly used in small scale implementations such as peer-peer gaming and LANbased 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. White Paper: IMS Simplified: The Evolution of the SIP Client 6 2 U ploa Infor d Locatio mati n on Location Server 3 1 R egi ster Registrar 200 O K sip:joe.user@pc.company_xyz.com Proxy sip:joe.user@company_xyz.com 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 ? oe is J ere Wh er sw An Registrar essa ge IP M 4 S 1 SIP Message sip:joe.user@pc.company_xyz.com sip:jane.user@yahoo.com Proxy sip:joe.user@company_xyz.com Figure 3.4 SIP Elements and Message Flow for SIP Session Establishment White Paper: IMS Simplified: The Evolution of the SIP Client 7 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 2 100–Trying() Jane’s 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. White Paper: IMS Simplified: The Evolution of the SIP Client 8 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 v=0 o=36596161 33887 IN IP4 192.168.1.172 s=SIP Phone c=IN IP4 192.168.1.172 t=0 0 Meaning SDP Version is “0” Owner of the session and session identifier Session Name Connection information 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 m=audio 6886 RTP/AVP 0 8 98 97 101 b=AS:64 a=rtpmap:0 PCMU/8000/1 a=rtpmap:8 PCMA/8000/1 a=rtpmap:98 G726-32/8000/1 a=rtpmap:97 AMR/8000/1 a=rtpmap:101 telephone-event/8000 Meaning 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. Bandwidth information Attributes of the “0”codec reference in the “m”line; in this case PCM uLaw encoding Attributes of the “8”codec reference in the “m”line; in this case PCM ALaw encoding Attributes of the “98”codec reference in the “m”line; in this case G.726 encoding Attributes of the “97”codec reference in the “m”line; in this case Adaptive Multi-rate Rate encoding 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. White Paper: IMS Simplified: The Evolution of the SIP Client 9 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 ACK BYE CANCEL INFO INVITE NOTIFY OPTIONS PRACK PUBLISH REGISTER SUBSCRIBE UPDATE MESSAGE REFER Description Confirms that the sender has received a 200:OK response from the receiver Terminates the call and can be done either the caller or called party Cancels calls that are in the process of being established Carries application level information along the SIP signaling path Request from the caller to the calling party(ies) to join a media session Notifies subscribers if event changes (i.e.location change of a user from a called group) A query message to determine the capabilities of the called servers 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. Publishing event state, PUBLISH is similar to REGISTER in that it allows a user to create, modify, and remove state Registers the caller’s public URI address with the SIP Registrar Indicates that a user wishes to receive information about the status of a service session UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs). MESSAGE requests carry Instant Messaging; the content is in the form of MIME body parts. 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 1xx 2xx 3xx 4xx 5xx 6xx Description Information Responses Successful Responses Redirection Responses Client Failure Responses Server Failure Responses Global Failure Responses Table 3.4 SIP Response Message Summary White Paper: IMS Simplified: The Evolution of the SIP Client 10 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 Server Home Subscriber Server AS SIP HSS Diameter S-CSCF SIP I-CSCF SIP P-CSCF SIP Call Session Control Functions 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. White Paper: IMS Simplified: The Evolution of the SIP Client 11 – – 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. White Paper: IMS Simplified: The Evolution of the SIP Client 12 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 Note 1 Register DNS Lookup SIP for Domain Select S-CSCF Server for UE Register User Authorization Request User Authorization Answer Register Media Authorization Request Media Authorization Answer Build authorization vectors Check authorization response Server Assignment Request Server Assignment Answer Mobile Network P-CSCF I-CSCF S-CSCF HSS 401 Auth Request 401 Auth Request Register Register Register 401 Auth Request P-CSCF subscribes to registration event package 200 OK 200 OK UE subscribes to registration event package SUBSCRIBE SUBSCRIBE 200 OK 200 OK NOTIFY NOTIFY 200 OK 200 OK SUBSCRIBE 200 OK NOTIFY 200 OK 200 OK Note 1: Before the UE device can contact the IMS network, it must establish the physical and data layer connections. 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. White Paper: IMS Simplified: The Evolution of the SIP Client 13 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 SCSCF 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. White Paper: IMS Simplified: The Evolution of the SIP Client 14 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 INVITE INVITE INVITE INVITE 183 Session Progress 183 Session Progress 183 Session Progress 183 Session Progress PRACK PRACK PRACK PRACK 200 OK 200 OK 200 OK 200 OK S-CSCF evaluates initial filter criteria P-CSCF 1 I-CSCF S-CSCF HSS UPDATE UPDATE UPDATE UPDATE 200 OK 200 OK 200 OK 200 OK Figure A: Stage 1 of a basic IMS session establishment. White Paper: IMS Simplified: The Evolution of the SIP Client 15 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 UE2 alerts/rings to request user actions IMS UE2 180 Ringing P-CSCF 1 I-CSCF S-CSCF HSS 180 Ringing 180 Ringing 180 Ringing PRACK PRACK PRACK PRACK 200 OK 200 OK 200 OK 200 OK 200 OK UE2 accepts/answers the call 200 OK ACK 200 OK 200 OK ACK ACK ACK RTP and Media Figure B: Stage 2 of a basic IMS session establishment. White Paper: IMS Simplified: The Evolution of the SIP Client 16 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 SIPbased 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. White Paper: IMS Simplified: The Evolution of the SIP Client 17 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 multifacetted 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. White Paper: IMS Simplified: The Evolution of the SIP Client 18 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 Dispatcher State Handler Compressor 1 State 1 Compressor Dispatcher 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 White Paper: IMS Simplified: The Evolution of the SIP Client 19 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:name@domain.com Dialed +1-919-111-2222 SIP Proxy “Call Setup” Response DNS Lookup 2.2.2.2.1.1.1.9.1.9.1.e164.arpa SIP:name@domain.com DNS Server White Paper: IMS Simplified: The Evolution of the SIP Client 20 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. White Paper: IMS Simplified: The Evolution of the SIP Client 21 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 White Paper: IMS Simplified: The Evolution of the SIP Client 22 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 White Paper: IMS Simplified: The Evolution of the SIP Client 23 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 White Paper: IMS Simplified: The Evolution of the SIP Client 24 All statements, technical information and recommendations related to the products herein are based upon information 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 TEL : 1 866 228 3762 FAX : +1 301 353 9216 LATIN AMERICA TEL : +55 11 5503 3800 FAX : +55 11 5505 1598 ASIA PACIFIC TEL : +852 2892 0990 FAX : +852 2892 0770 EMEA TEL : +49 7121 86 2222 FAX : +49 7121 86 1222 WEBSITE : www.jdsu.com/test