UNIVERSITY OF ŽILINA DIPLOMA THESIS

Transcription

1 UNIVERSITY OF ŽILINA FACULTY OF MANAGEMENT SCIENCE AND INFORMATICS DIPLOMA THESIS STUDYING PROGRAM: INFORMATION SYSTEMS SPECIALIZATION: INFORMATION-COMMUNICATION NETWORKS Andrej Krivulčík IP Multimedia Subsystem (IMS) interoperability with VoIP SIP solutions Supervisor: Ing. Pavel Segeč, PhD. Reg. no. 107/2008 may 2009

2 ZADANIE ii

3 Abstract The objective of this thesis is to implement a working IP Multimedia Subsystem (IMS) installation, test and evaluate the possibilities of interworking with traditional SIP-based VoIP solutions. Interworking with two different SIP-based server solutions was tested and also capabilities of VoIP clients interworking with IMS were examined. The sample call flows were examined with regard to current standards and the conformance of the used IMS solution was evaluated. To accomplish these goals, extensive knowledge about Session Initiation Protocol (SIP) which is a base protocol in IMS was needed. In addition to these goals, the thesis introduces the SIP protocol, the IMS itself and also the Next Generation Network architecture where IMS plays important role. iii

4 Preface This report is a master thesis which was carried out in Master of Science program at Faculty of management science and informatics at University of Žilina. I would like to thank Ing. Pavel Segeč, PhD., the supervisor of this master's thesis, for the guidance, support and advice throughout the work on this project. Žilina, may 2009 Andrej Krivulčík iv

5 Table of Contents 1 Introduction VoIP SIP protocol by IETF Characteristics Architecture Features Addressing Address resolution for telephone numbers SIP messages SIP requests SIP responses Header fields in SIP messages SIP messages examples SIP authentication Services provided by SIP Presence Instant messaging Call redirecting and forking What SIP is not Protocols used with SIP Usage example IP Multimedia Subsystem NGN architecture IMS Core architecture SIP extensions for IMS User identification in IMS Services provided by IMS Example of IMS deployment OpenIMSCore description Installation Installation prerequisites Hardware Network Software Installation environment Installation procedure Configuration and customization Running Two-domains setup IMS call flow example Encountered problems and suggested solutions SIP-to-IMS interworking Proposed scenarios OpenIMSCore interconnected with OpenSER Server software Testing setup IMS-to-SIP session establishment evaluation SIP-to-IMS sesslion establishment evaluation OpenIMSCore interconnected with Asterisk...58 v

6 5.3.1 Server software Testing setup IMS-to-SIP session establishment evaluation SIP-to-IMS call establishment evaluation SIP client used in IMS network Registering to the IMS domain Ekiga Twinkle X-Lite Unregistered calls to the IMS domain Encountered problems and suggested solutions Conclusion and future work List of abbreviations References...75 Appendix A: Header fields in SIP...77 Appendix B: Packages installed prior to OpenIMSCore installation...79 Appendix C: SIP Messages for described call flows...80 IMS-to-SIP session establishment...80 SIP-to-IMS session establishment...86 Appendix D: DNS configuration files...97 Appendix E: DVD containing virtual machine images and call flows...99 Illustration Index Figure 2.1: SIP architecture...13 Figure 2.2: SIP transactions and dialogs...14 Figure 2.3: SIP example call flow...23 Figure 3.1: NGN architecture...28 Figure 3.2: IMS architecture...30 Figure 4.1: IMS Core architecture and reference points...35 Figure 4.2: IMS deployment topology...39 Figure 4.3: Two-domain IMS deployment topology...43 Figure 4.4: IMS-to-IMS call flow example...45 Figure 5.1: IMS with OpenSER testing scenario topology...50 Figure 5.2: IMS-to-SIP call flow using OpenSER...51 Figure 5.3: SIP-to-IMS call flow using OpenSER...55 Figure 5.4: IMS with Asterisk testing scenario topology...60 Figure 5.5: IMS-to-SIP call flow using Asterisk...62 Figure 5.6: SIP-to-IMS call flow using Asterisk...64 Figure 5.7: SIP-to-IMS call directly from a SIP client...69 Index of Tables Table 4.1: Reference points in IMS Core...36 Table 4.2: SQL scripts provided in the OpenIMSCore package...41 vi

7 1 Introduction The internet connectivity possibilities are becoming more and more common. The bandwidth of the internet connections, both fixed and mobile, is increasing as new technologies are designed and deployed. In past, this has caused transition of voice services from circuit-switched networks like Public Switched Telephone Network (PSTN) to packet-switched network - the Internet. The current trend is to converge all multimedia services to this single carrier. The connection characteristics allow the multimedia data to be successfully transferred through this medium without the need of a dedicated media channel. Voice over IP (VoIP) technology is currently very popular and it is already used by many companies which lets them lower the costs of voice communication. Provision of VoIP services is common and providers seek ways to convey more services to their customers. Integrating more multimedia services and bundling value-added services with the basic voice telephony services can be effective way to present more and better services to the customer. To make this possible, Next Generation Networks (NGN) architecture was designed. This architecture allows all information and services to be transported over one single packet-switched network. NGN is built around the Internet Protocol (IP) and related protocols which are already specified, implemented and commonly in use. Substantial part of an NGN architecture is the IP Multimedia Subsystem (IMS) which is an architectural framework that enables provision of various multimedia services to users regardless of their internet access method. It uses common internet-based protocols, mainly Session Initiation Protocol (SIP) which is the base protocol for carrying signalization information (i.e. information needed for establishment a voice call or multimedia session). SIP is commonly used to provide VoIP services and is well-suited for needs in the IMS. However, some changes were needed to adapt it for this use. Many companies are actively researching and developing IMS solutions to be integrated in their services. To present a reference implementation of a core IMS, The 7

8 Fraunhofer Institute for Open Communication Systems (FOKUS) released its core IMS implementation as open source - the OpenIMSCore. In telecommunication industry, the compatibility with legacy technology is very important. The technology advances very quickly and although new technologies may exist, there will always be the need to communicate with older equipment. Thus, VoIP carried over Internet uses gateways for interconnection with the PSTN. Transition from traditional VoIP services to converged services in NGN is a process similar in nature to the change from PSTN to VoIP and ways of interconnection for these systems should be sought. The goal of this work was to research the possibilities of interworking between VoIP services provided by SIP and the IMS system (the OpenIMSCore implementation). Two commonly used SIP-based VoIP solutions were interconnected with the IMS and their compatibility was tested. Also, a conformance evaluation was done on the testing scenarios to examine whether the OpenIMSCore reference implementation complies with the standards defining the IMS. Another test was to evaluate the possibilities of using a SIP-based VoIP software phone in an IMS network. In the second chapter, the SIP protocol, as defined by Internet Engineering Task Force (IETF), is introduced. The IMS itself is described in the third chapter. Fourth chapter describes the deployment of the OpenIMSCore in practice. In the fifth chapter, the SIP-to-IMS interworking tests are performed and evaluated. 8

9 2 VoIP SIP protocol by IETF To establish any multimedia session, the endpoints must exchange information about the session being established, supported codecs on both sides and desired parameters of the session. If the users want to start a multimedia call, their user-equipment must agree on what media they want to exchange. The media parameters on both sides of the session must match. Several network protocols were designed to manage sessions - initialize, change their state and terminate them. Among the most widely adopted protocols for IP telephony (which is a multimedia session with a single voice media) is the Session Initiation Protocol (SIP). SIP forms a flexible, comprehensive signaling solution and allows for lightweight deployment of many service features. The simpler implementation and open collaboration of SIP make it the signaling protocol of choice for some advanced multimedia communication signaling. SIP is gaining in popularity and deployment and has been widely adopted by service providers to provide IP telephony, instant messaging, and other data services. The rising popularity of SIP is evidenced by its acceptance into the 3GPP (3rd Generation Partnership Project) as a signaling protocol for establishing multimedia sessions for mobile networks [1]. SIP was created with these design goals in mind: transport protocol neutrality - it can be run over reliable protocols (TCP or SCTP) and unreliable, but faster protocols (UDP); multiple options of request routing: direct routing (focused on performance) or proxy-routed (the provider can have more control and information); separation of signaling and media description - new applications and media can be added without interfering with the SIP protocol itself; extensibility - SIP messages can contain any headers and if the network element processing the message doesn't understand them, it simply ignores 9

10 them. This allows to transparently add functions to SIP while maintaining backwards compatibility; personal mobility - a SIP user can make himself available from anywhere by registering with his SIP server [2]. 2.1 Characteristics SIP is a session-layer signaling protocol used for establishment, modification and termination of sessions among participants. The sessions can include VoIP (Voice over IP) and video calls, voice or video conferencing, multimedia distribution, online games, presence information, instant messaging and more. SIP supports several aspects of establishing and tearing down multimedia communications: user location, user availability, user capabilities, session setup and session management. SIP is a plain-text protocol based on elements from the HyperText Transport Protocol (HTTP) used for web browsing. As its name implies, the primary function of SIP is session initiation, but it can be also used in other ways, such as presence notification and exchange of short messages (instant messaging). SIP is used for peer-to-peer communication: both parties are equal, there is no master or slave. However, SIP uses a client-server transaction model similar to HTTP: SIP client generates a SIP request, SIP server responds to the request by sending back a response. It is designed to be independent of the underlying transport protocol, thus can run on top of UDP, TCP or SCTP. In practice, mainly UDP is used, as some implementations don't support other transport protocols 1. As SIP is a protocol based upon HTTP, it borrows many elements from it: header syntax, encoding rules and status codes. Its plain-text based nature eases troubleshooting and inspecting progress of session management. 1 For example Asterisk, a very popular software VoIP PBX, didn't implement SIP over TCP until recently (although it is required by RFC 3261; not by RFC 2543, which was obsoleted by RFC 3261 in 2002) 10

11 2.2 Architecture There are two basic components in SIP: the SIP user agent (UA) and the SIP network server. UA is the end-point of a call and the server is a device that handles the signaling associated with multiple calls. The UA itself consists of two elements: client element, the User Agent Client (UAC) and a server element, the User Agent Server (UAS). The UAC initiates the calls and the UAS responds to requests. This internal division allows peer-to-peer calls to be made using a client-server protocol. The main function of the SIP network servers is to provide name resolution and user location, so that the calling user doesn't have to know IP addresses of the called party. Also, the servers are responsible for passing on messages to other servers when necessary. A SIP server can operate either in stateful or stateless mode: in stateful mode it keeps track of received requests, responses sent back and requests it sent. This allows it to make advanced decisions like forking a call (ringing two SIP clients at once, and canceling one of the calls when one of the clients answer). In stateless mode, the server does not remember any information about a request once it has been sent. Servers running in stateful mode are more resource-demanding. Thus, they are likely to be deployed as local servers for small groups of end-users. Stateless servers can operate faster and they can handle more calls with limited resources. They can be used as a backbone of a SIP infrastructure [3]. [4] specifies three server elements: Proxy, proxy server is an intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity closer to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. 11

12 A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs. The redirect server allows SIP Proxy Servers to direct SIP session invitations to external domains. It is important that this distinction between types of SIP servers is logical, not physical - one physical machine (even one server software) can contain any or all these components. An entity named back-to-back user agent (B2BUA) is also defined in [4]: it is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. This behavior causes a call between two participants to be split in two independent calls, from each participant to the B2BUA. The participants have no knowledge about the real location of the other party because they send their SIP messages and possibly the RTP media stream to the B2BUA address. The B2BUA relays these messages to the other party, but as a different call. Using B2BUA has several disadvantages: it doesn't keep the end-to-end nature of SIP, increases latency and thus increases delay in call setup. On the other hand, B2BUAs permit advanced call control and monitoring. Also, value added services, such as anonymizing call participants, can be provided using B2BUA. A SIP signaling gateway is also an important part of the SIP architecture. It converts signalization between SIP and other signaling protocol such as H.323 or PSTN signaling protocols. This enables interconnection of different telephony networks and call transition between them. Voice calls between networks which use different media codecs will also need a media gateway which transcodes the voice data between the codecs in use. 12

13 Figure 2.1: SIP architecture Two important terms should be introduced: A SIP transaction occurs between a UAC and a UAS and comprises all messages from the first request sent from the client to the server up to a final (non- 1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier (included in Call-ID header field of a SIP message), local tag (tag parameter in From or To header field), and a remote tag (tag parameter in the To or From header field). 13

14 Figure 2.2. Figure 2.2: SIP transactions and dialogs Several transactions are usually a part of a single SIP dialog as illustrated in 2.3 Features Addressing The users in SIP are addressed by an Universal Resource Identifier (URI). General URI syntax is standardized in [6]: URI consists of the scheme (like http, mailto or sip 2 ), a colon and a scheme-specific part. The last part is always interpreted depending on the scheme used. The IANA register of schemes also lists the standards that specify the syntax of this scheme-specific part. The SIP URI is identified by the sip scheme and its general form is sip:user:password@host:port;uri-parameters?headers 2 official register of available URI schemes is maintained by IANA at [5] 14

15 In the most basic form the SIP URI consists of only the user and host part (e.g. Using the password field is strongly discouraged, because the URI is often sent in plain text and the password could be easily compromised. Port can be specified if it is different from the default The uri-parameters contains parameters affecting a request constructed from the URI. URI parameters are added after the hostport component and are separated by semi-colons. Among other parameters, transport type, time-to-live or SIP method to be used can be defined here. Header fields to be included in a SIP request constructed from the URI can be set in the headers part of the URI. The URI syntax, possible uri-parameters and header fields along with their interpretation is specified in detail in [4] Address resolution for telephone numbers One of the important objectives while designing SIP and related protocols for VoIP use was to maintain mutual interconnectivity between legacy PSTN and the IPbased VoIP network. With using appropriate media and signaling gateways, calling between these two domains is possible. Addressing the users of the IP network is problematic though, as the input possibilities of users in PSTN is limited (the devices are usually equipped with a dial pad, with no or limited alphabetical input possible). The ENUM (telephone NUMber mapping) suite of protocols was designed to allow identification and reachability of a client by a definite identifier - telephone number. PSTN uses number specifies in International Telecommunication Union- Telecommunication Standardization Sector (ITU-T) recommendation E.164. ENUM provides a way to translate an international telephone number in E.164 format to one or more internet URI (SIP URI or other), which presents access to various voice services (IP telephone, PBX,...), as well as other services ( , www) using just one telephone number. ENUM uses DNS (Domain Name System) to store data needed for such translation in a hierarchic and distributed way. The required information is stored as a NAPTR (Naming Authority Pointer) record for a zone derived from the telephone number in international format. The records are stored hierarchically in such a way 15

16 that any prefix of telephone numbers can have common record and any more specific prefix can have different record, or even be delegated to other DNS server. This resembles the way PTR reverse records are stored. The top-level zone for ENUM records is e164.arpa. (also similar to in-addr.arpa. zone used for reverse records resolving). Translating telephone numbers to URIs is the primary function of ENUM and although allowing PSTN-to-VoIP calls is not its only function, it is obvious and useful utilization of its capabilities SIP messages SIP is a text-based protocol similar to HTTP. Like HTTP, it uses client-server architecture with requests sent by the UAC and responses sent back by the UAS. The messages used in SIP are therefore of two types: requests and responses SIP requests SIP requests are distinguished by having a Request-Line for a start-line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space character. [4] specifies six methods: REGISTER - used by UA for registering contact information: the UA notifies the registrar about its current IP address and the URIs for which it would like to receive calls. INVITE - used to establish multimedia sessions between user agents. ACK - used for confirmation of receiving a final response to INVITE requests. CANCEL - used to terminate a pending request of session establishment. BYE - used to terminate an existing session. OPTIONS - used for querying servers about their capabilities. These are basic SIP request methods, but to keep SIP extensible, additional methods can be defined in subsequent RFCs. Request-URI is a SIP (or SIPS) URI indicating the user or service to which this request is being addressed. 16

17 SIP-version indicates that the message is indeed a SIP message and the version of the standard it follows. Applications compliant with [4] must use string SIP/2.0 as SIP-version SIP responses SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase (Reason-Phrase), with each element separated by a single space character. The Status-Code is a 3-digit integer code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase gives short textual description of the Status-Code. Status-Code is intended for automatic processing, whereas Reason-Phrase is intended for the human user and is not important in evaluation of the response. The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. SIP/2.0 allows six values for the first digit: 1 (Status-Codes 100 through 199, also called 1xx responses) - Provisional: request received, continuing to process the request. 2xx - Success: the action was successfully received, understood and accepted. 3xx - Redirection: further action needs to be taken in order to complete the request. 4xx - Client Error: the request contains bad syntax or cannot be fulfilled at this server. 5xx - Server Error: the server failed to fulfill a valid request. 6xx - Global Failure: the request cannot be fulfilled at any server. The actual status codes are very similar to HTTP status codes from where many of them are borrowed (e.g. 200 OK, 404 Not Found, 403 Forbidden...). 17

18 Header fields in SIP messages Also the header fields in SIP messages are similar to HTTP header fields: they consist of the field name, followed by a colon and the field value. An example of a header field is Subject: Important call SIP messages examples INVITE sip:alice@example.com SIP/2.0 Date: Thu, 02 May :10:09 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP :5065;branch=z9hG4bKb6e9b434-8f39-de11-80f7-001e68131dce;rport User-Agent: Ekiga/ From: "Andrej Krivulcik" <sip:thefox@example.com>; tag=3c14b434-8f39-de11-80f7-001e68131dce Call-ID: ae10b434-8f39-de11-80f7-001e68131dce@foxy To: <sip:alice@example.com> Contact: <sip:thefox@ :5065;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 387 Max-Forwards: 70 The first line of the above message indicates that it is a request with the INVITE method calling alice@example.com. The meaning and use of the header fields can be found in Appendix A. The From header field contains a tag parameter in addition to logical identity of the initiator of the request. This parameter (in both From and To header fields) along with the Call-ID serves as a general mechanism to identify a dialog between participants. The Call-ID header field acts as a unique identifier to group together a series of messages. A response to the above request can look as follows: 18

19 SIP/ Decline Via: SIP/2.0/UDP :5065;received= ; branch=z9hg4bkb6e9b434-8f39-de11-80f7-001e68131dce;rport=5065 From: "Andrej Krivulcik" tag=3c14b434-8f39-de11-80f7-001e68131dce To: Call-ID: CSeq: 1 INVITE Content-Length: 0 The first line distinguishes the message as a SIP response with error code 603 (which is defined as a rejection of the call - callee was successfully contacted but he explicitly does not wish or cannot participate). The textual representation of this status code is Decline, which may be displayed to the calling user. The client can however display any other message, such as localized message or explanation of the status code. The header fields have the same meaning as in the above request. The To header field is extended with a new tag and any messages in this dialog (all the provisional responses sent before this message and the ACK message following it) have the same values of the Call-ID and tags in From and To header fields SIP authentication SIP uses a challenge-based mechanism for authentication. When a proxy server or UA receives a request, it may challenge the initiator of the request to confirm its identity based on a secret pre-shared between the proxy and the request initiator. The proxy sends a challenge in an error response (which is then acknowledged by sending an ACK message). The request initiator computes a response based on several parameters, including the one-time challenge received from the proxy server and the secret. The response is then sent along with the original request to the proxy once again. After asserting the initiator identity (and preferably checking that it is authorized to place received request), the proxy further processes the request. The challenge-response nature of this authentication mechanism provides message authentication and protection against replay attacks. Message integrity and confidentiality is not guaranteed and must be achieved by other means. 19

20 2.4 Services provided by SIP Session establishment is only one of the services that can be provided by SIP. Although main function of SIP is session establishment and management, thanks to its extensibility it can be used for several other services Presence Presence service allows participants to see other users' status. This offers several advantages: The calling user knows whether the callee is available online, where is he (work/home) and if he is willing to accept the call. The caller can avoid unsuccessful calls and send an or instant message instead. The client software can maintain a list of contact and visualize their presence information in a convenient way. Calling a user from this list won't require typing in his SIP URI or number, but rather clicking his icon and choosing to call him. The client software can group multiple contacts into one meta-contact representing a single person. The software then chooses the best way of contacting the recipient with respect to their presence information. Presence service is offered by means of SIP extensions defined in [7]. This RFC specifies two SIP request methods: SUBSCRIBE and NOTIFY. Event notification as defined in this specification consists of two phases: First the client sends a request with SUBSCRIBE method to a Notifier (a user agent capable of sending NOTIFY requests) and declares its willingness to receive notification about certain events stated in the request. The Notifier sends the current state of the resource to the subscriber immediately after receiving, accepting and confirming the SUBSCRIBE request. After that, any change of the resource state triggers a NOTIFY request sent to the subscriber. This alone is not enough to provide full-scale presence service because the Notifier may not know about the status of domain's registered users. To allow SIP entities to announce some information to other SIP entities, a PUBLISH request 20

21 method was standardized in [8]. A SIP client can publish its status to the Notifier, which in turn can notify the subscribers watching presence status of this new status Instant messaging Instant messaging is the real-time (or almost real-time) exchange of text messages between the users. SIP offers two possibilities of instant messaging: short individual messages, mostly text: this is accomplished by exchanging MESSAGE requests. MESSAGE method is a SIP extension standardized in [9]; establishing a instant messaging session: this is beneficial when transferring large files or secure tunneling through NAT and firewalls between domains is needed [10]. The protocol for this session mode is called the Message Session Relay Protocol (defined in [11]). Exploiting existing SIP infrastructure for delivering instant messages unifies the communication between users. Users don't have to use separate applications, devices and infrastructures for different means of communication thus enhancing the user experience Call redirecting and forking Although not actually a service, SIP offers possibilities to perform advanced call routing logic such as redirecting based on user-defined criteria. For example an office worker can tell the VoIP service to redirect all calls to a mailbox during a lunch break. But when his boss needs to call him, the call is redirected to his cell phone. Call forking is performed by stateful SIP proxy servers. When a user is called, the proxy sends the INVITE request to two or more registered devices. They all start ringing and the called user can answer the call at any of them, whichever is nearer or more convenient for him. After the call is answered, the proxy server cancels all other pending session establishment request so the other devices stop ringing. 21

22 2.5 What SIP is not SIP is very powerful and extensible protocol. But its primary function is to perform signaling - establish, maintain and manage sessions. It is not a transfer protocol such as HTTP. Small amounts of data - although not related to session setup - are well suited for SIP and are transferred by SIP for instant messaging as described above. Large amount of data are though not suited for carrying by SIP. SIP itself is not a VoIP protocol although VoIP is one of the most popular services offered by a SIP infrastructure. SIP acts only as a signaling protocol for establishing VoIP calls and other protocols (such as Session Description Protocol (SDP), carried in SIP message body) are needed to negotiate the call parameters. SIP is neither a resource reservation or prioritization protocol. It cannot guarantee or reserve Quality of Service (QoS). It can only interwork with other protocols designed to support QoS. 2.6 Protocols used with SIP Because SIP is not a transfer protocol, it alone can not provide all functions needed for VoIP services. SDP is used in SIP message body to transfer information about the media in the session being established. This is also a plain-text protocol using name-value pairs to describe a media session. SDP is standardized in [12]. To transfer the actual media data - the voice in a phone call - Real-time transport protocol (RTP) is used. RTP is a standardized packet format for delivering audio and video over a packet-switched network. It is defined in [13]. 2.7 Usage example To illustrate a simple SIP call establishment, let's examine a call between two users registered at a SIP proxy: 22

23 Figure 2.3: SIP example call flow The first INVITE request contains a SDP payload describing the session Alice wants to establish. When the proxy receives it, it sends back a 100 Trying provisional response to let Alice's UA know that it received the request and is processing it. When the proxy server processes the request, it finds out that the request needs to be forwarded to Bob's UA (whose location needs to be known to the proxy server). Proxy server forwards the request, Bob's UA receives it, confirms its receipt by a 100 Trying provisional response and takes appropriate action - starts to alert Bob about the incoming call. Another provisional response (180 Ringing ) is sent back (through the proxy to Alice's UA) to inform Alice about this fact. After Bob answers the call, a final 200 OK response is sent to Alice's UA (again, through the proxy server). This message contains SDP body with session parameters Bob's UA selected from supported parameters sent by Alice's UA in the first INVITE request. This final response is acknowledged by the ACK message and the multimedia session is fully established - Alice and Bob can talk to each other in case of VoIP call. After they are done exchanging the multimedia data and want to tear down the session, one party sends a BYE request (in this case it was Bob). The other party sends a 200 OK response back and the session is properly terminated. This 23

24 response is not acknowledged by an ACK message - an ACK is only sent in response to a response to an INVITE request. 24

25 3 IP Multimedia Subsystem The connectivity possibilities for users have been enhanced greatly during the past decades. Gone are the days when bandwidth was measured in tens of kilobits per second. The speed of internet connection has risen as new technologies were implemented: mostly dial-up connections over POTS (Plain Old Telephone System) and ISDN (Integrated Services Digital Network) were used until several years ago when faster and cheaper ADSL (Asynchronous Digital Subscriber Line) became widely available. Currently, optical networks offering even higher speeds are often used to connect end-users to the internet. The users are not limited to fixed internet access. Mobile networks are also capable of delivering data to end-user devices: be it over the GSM, GPRS, EDGE or lately 3G services. The users have possibility to be connected anywhere, anytime and the speed and quality of both fixed and mobile internet access is being continuously enhanced. Users have available devices that are always on (cell phones). These mobile devices are also evolving: they are no longer single-purpose tools but have resources for running complicated applications, have high-resolution displays and built-in cameras. Users can be conveniently always connected through a fast link to the Internet using these devices. All of these connectivity possibilities have one thing in common: they provide IP packet-switched connectivity, whether mobile or fixed. With the convergence of data and voice services towards the IP, it is becoming more and more important that the devices can connect to each other. This is not always possible, especially between networks belonging to different providers. This is why we need a global system - the IP Multimedia Subsystem (IMS), which allows applications in IP-enabled devices to establish peer-to-peer and peer-to-content connections easily and securely. The IMS can be defined as follows: 25

26 IMS is a global, access-independent and standard-based IP connectivity and service control architecture that enables various types of multimedia services to end-users using common Internet-based protocols [2]. This means that the users are able to access the provided multimedia services no matter where they are and how are they connected to the internet. Using existing standardized protocols makes development easier and faster and can provide compatibility with non-ims world. IMS provides a unified architecture that supports a wide range of IP-based services over both packet- and circuit-switched networks, employing a range of different wireless and fixed access technologies. A user could, for example, pay for and download a video clip to a chosen mobile or fixed device and subsequently use some of this material to create a multimedia message for delivery to friends on many different networks. A single IMS presence-and-availability engine could track a user's presence and availability across mobile, fixed, and broadband networks, or a user could maintain a single integrated contact list for all types of communications [14]. 3.1 NGN architecture A Next Generation Network (NGN) is a packet-based network able to provide services including Telecommunication Services and able to make use of multiple broadband, QoS-enabled transport technologies and in which servicerelated functions are independent from underlying transport-related technologies. It offers unrestricted access by users to different service providers. It supports generalized mobility which will allow consistent and ubiquitous provision of services to users [15]. The NGN enables the deployment of access independent services over converged fixed and mobile networks the NGN is packet based and uses IP to transport the various types of traffic (voice, video, data and signaling). 26

27 Triple play services (Voice, Internet and TV) are available via Cable and xdsl already. The NGN brings mobility into the picture and the opportunity for further bundling of high revenue services for customers. The IMS is at the core of the harmonized all-ip NGN network. It is the element that enables and drives efficient converged service offerings. IMS provides the framework for a common service and session control layer standardized on IP, with SIP controlling all media sessions. The NGN framework is set by the ITU-T and ETSI, especially its Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TS TISPAN). Other standardization organizations and fora 3 are also actively involved in defining NGN standards. TISPAN is responsible for all aspects of standardization for present and future converged networks including the NGN, service aspects, architectural aspects, protocol aspects, QoS studies, security related studies, mobility aspects within fixed networks, using existing and emerging technologies. TC TISPAN developed a functional architecture for NGN which comprises a number of subsystems and is structured in two layers: service layer and IP-based transport layer [16]. The architecture described in [17] and related subsystems specifications is a functional architecture. Each subsystem is specified as a set of functional entities and related interfaces. As a result implementers may choose to combine functional entities where this makes sense in the context of the business models, services and capabilities being supported. Figure 3.1 provides an overview of the NGN architecture as designed in [17]. 3 Such as the IETF, 3GPP, 3GPP2, ANSI, CableLabs, Multi-Service Forum and Open Mobile Alliance 27

28 Figure 3.1: NGN architecture The transport layer provides the IP connectivity for NGN users. The transport layer comprises a transport control sublayer on top of transport processing functions in the access and core networks. The network control sublayer is further divided into the Network Attachment Subsystem (NASS) and the Resource and Admission Control Subsystem (RACS). The NASS provides registration at the access level and initializes terminal accessing to NGN services. The RACS is the subsystem responsible for the implementation of procedures and mechanisms handling policy-based resource reservation and admission control for traffic in access networks and core networks. The service layer is composed of: The Core IP Multimedia Subsystem; PSTN/ISDN emulation subsystem (PES); IPTV subsystem; Common components - functional entities that can be accessed by more than one subsystem. The "Core IMS" is a subset of the 3GPP IMS defined in [18] and is restricted to the session control functionality. 28

29 3.2 IMS Core architecture The IMS was designed and standardized by the 3GPP (3rd Generation Partnership Project). 3GPP is a collaboration between groups of telecommunications associations, to make a globally applicable third generation (3G) mobile phone system specification. It was created in December 1998 by ETSI, ARIB, Committee T1, TTA and TTC. Its purpose was to prepare, approve and maintain globally applicable Technical Specifications (TS) and Technical Reports (TR) for a 3rd Generation Mobile System based on the evolved GSM core networks, and the radio access technologies supported by the organizational partners. Later, preparation, approval and maintenance of TSs and TRs for an evolved IMS developed in an access independent manner was added to the 3GPP Agreement [19]. 3GPP does not produce standards, but rather TSs and TRs. Once approved, they are submitted to the organizational partners to be standardized. 3GPP uses a system of parallel releases - sets of specifications which provide developers with stable platform for implementation and allow for the addition of new features required by the market. Each release contains many individual standards documents and it is frozen on certain date, after which no functions are added to this release. The IMS was introduced in Release 5 released in [20] designs the functional architecture of IMS and IMS entities and functions are standardized in [21]. [21] defines these functional entities (see Figure 3.2): Call Session Control Function (CSCF) establishes, monitors, supports and releases multimedia sessions and manages the user's service interactions. The CSCF can act as Proxy CSCF, Serving CSCF or Interrogating CSCF, functions of these are described in sub-section 4.1. Media Gateway Control Function (MGCF) provides the ability to control a trunking media gateway function through a standardized interface. Such control includes allocation and deallocation of resources of the media gateway, as well as modification of the usage of these resources. Multimedia Resource Function Controller (MRFC) provides a set of resources within the core network for supporting services. 29

30 Breakout Gateway Control Function (BGCF) determines the next hop in SIP routing. Interconnection Border Control Function (IBCF) provides application specific functions at the SIP/SDP protocol layer in order to perform interconnection between two operator domains. Also reference points and protocols between these entities are defined. The IMS Core entities and reference points are further described in sub-section 4.1. Figure 3.2: IMS architecture 3.3 SIP extensions for IMS IMS is a Media-over-IP network and uses SIP as its base signaling protocol. The 3GPP chose SIP as its base protocol because previous telecom signaling protocols (e.g. H.323) failed to comply with all IMS requirements. Because SIP is an internet protocol, it can accommodate convergence, and has the potential to meet all the needs of the IMS architecture. 30

31 While offering the right foundation, SIP in its IMS form has proven to be quite complex and presented many technological challenges. There were many gaps between the SIP initially defined by the IETF, and the features required for full IMS support. To solve this problem the 3GPP defined dozens of SIP extensions - additions that are specific to IMS networks. Some of these extensions are defined in [22], some are standardized as RFC documents. Major extensions include: SigComp (RFC 3320): defines how to compress SIP textual signaling data, which can be very large and problematic to transmit, causing delay. P-headers (RFCs 3455 and 3325): additional headers defined by 3GPP targeted at solving specific IMS network problems, such as obtaining information about the access network (cell ID) and the visited network (roamed network), determining caller identity and conveying charging information. Security Agreement (RFC 3329): specifies how to negotiate security capabilities for multiple types of endpoints. AKA-MD5 (RFC 3310): determines how terminals and networks are authenticated using already defined mechanism (e.g. ISIM), as well as specific key exchange. IPSec: is used on various IMS interfaces and between different IMS networks to provide security of the transported data. Media Authorization (RFC 3313): ensures that only authorized media resources are used. Mobile Registration (RFCs 3327 and 3608): on IMS networks, the terminal registration process is more complicated, as it includes various security extensions and must deal with registration from a visited network. Reg-event Package (RFC 3680): used by the terminal and the P-CSCF to know the terminal registration status on the network. Preconditions (RFC 4032): specifies method for negotiating QoS, security and other required call behavior between two terminals. IMS Resource Reservation (RFC 3312): defines how to make resource reservations for phone calls or sessions [23]. 31

32 3.4 User identification in IMS In IMS, two different identities are defined in [21]: The private user identity is a unique global identity defined by the operator, which may be used within the home network to uniquely identify the user from a network perspective. It does not identify a particular user, only the user's subscription. Therefore, it is mainly used for authentication purposes (during registration, re-registration and de-registration). The private user identity will be permanently allocated to a user and valid for the duration of the user's subscription. It may optionally be present in charging records. The public user identity is used by any user for requesting communications to other users. Every IMS user should have one or more public user identities. Both telecom numbering and Internet naming schemes can be used to address users. Public user identities are not authenticated by the network during registration. In IMS, one or more private user identities are assigned to a single IMS user. These identities can be used in different IMS terminals. Each private user identity can be linked to one or more public user identities. Thus, a single IMS user can be reached via multiple public user identities using multiple IMS devices (with each device authenticated by one private user identity). 3.5 Services provided by IMS The IMS is capable of providing all the services that SIP provides - multimedia session management, presence and instant messaging. Several IMSspecific services were designed for delivery in an IMS network, such as: Push-to-talk over Cellular (PoC) is a walkie-talkie type of service. Users press and hold a button when they want to say something and after a signal from their terminal they can speak. After they are done, they release the button. More than two users can participate in a PoC session and everyone's speech is sent to all the participants. 32

33 Conferencing is a conversation between multiple participants. Conferencing is not limited to audio - video and text conferences (chatting) is also popular. Voice call continuity maintains a multimedia session persistence, when the User Equipment (UE) moves between circuit-switched and packet-switched domains. Modern cell phones often have multiple means of internet connectivity (e.g. GPRS and WiFi), one circuit-switched and the other packet-switched. This technology provides uninterrupted service when moving from one network to another. Other services (such as voic , interactive voice response (IVR), etc.) can be provided by attaching application servers to the IMS. 33

34 4 Example of IMS deployment To demonstrate IMS capabilities and test the installation and deployment process, an IMS domain was installed on a server and its functionality was verified by registering IMS users and performing an IMS call. An experimental IMS implementation developed by The Fraunhofer Institute for Open Communication Systems FOKUS (Das Fraunhofer-Institut für Offene Kommunikationssysteme) - OpenIMSCore [24]- was used as server-side software. UCT IMS Client [25] - an open IMS client developed by the Communications Research Group at the University of Cape Town, South Africa and designed to be used with the OpenIMSCore - was used on the client side. Because IMS was designed to work with IP version 6 (IPv6) where we can assume full connectivity between all users and no Network Address Translation- (NAT-)related problems exist, all the elements of this scenario are located in a single IP network where no NAT takes place. This way, although using IP version 4 (IPv4), all entities can connect to each other. Also, no firewalls were used. The goal of this test is to deploy a demonstration installation of the OpenIMSCore, perform a sample IMS call and evaluate its progress. 4.1 OpenIMSCore description IP Multimedia Subsystem is not a specification of network elements, servers and entities being involved in multimedia calls. It is just a framework that specifies functions in the system and the reference points (interfaces) between these functions. Protocols and messages used at these reference points are defined as well. It is implementation-dependent what entities will be used for carrying out specific parts of this specification. It is important that the messages exchanged at particular reference points follow the standards, but the elements connected to these reference 34

35 points are not defined. Thus, any software that implements required interfaces can be used as a part of IMS implementation. These standardized parts of IMS are in theory interchangeable without any impact on the IMS as a whole. Theoretically, the whole IMS could be implemented as one monolithic piece of software with all the reference points inside, but the increased complexity of such implementation would make it next to impossible to maintain. Furthermore, modular approach of several separate entities facilitates development of both new and existing parts of the IMS. Development of new services and enhancing existing functions can be performed individually without any relation with other parts of the IMS. Figure 4.1): The core of an IMS infrastructure consists of four elementary entities (see Proxy Call Session Control Function (P-CSCF) is the first contact point for users within the IMS. All SIP signaling traffic from the UE is sent to P- CSCF. Likewise, all terminating traffic from the IMS network is sent from the P-CSCF to the UE. Interrogating Call Session Control Function (I-CSCF) is a contact point within an operator's network for all connections destined to a subscriber of that network operator. Figure 4.1: IMS Core architecture and reference points Serving Call Session Control Function (S-CSCF) is the central point of the IMS: it is responsible for handling the registration processes, making routing decisions, maintaining session states and storing the service profiles. 35

36 Home Subscriber Server (HSS) is the main data storage for all subscriber and service-related data of the IMS. The main data stored in the HSS include user identities, registration information, access parameters and servicetriggering information. At least these components are mandatory for any IMS implementation. The reference points in the IMS core are defined as follows: Reference point Protocol used Functions Gm SIP SIP signaling transport between the UE and P-CSCF UE registration session control transactions Mw SIP registration session control transactions Cx DIAMETER location management user data handling user authentication Table 4.1: Reference points in IMS Core The OpenIMSCore implements all these functions interconnected by the defined interfaces (reference points). All the CSCFs are in fact SIP servers, so they are based upon the SIP Express Router (SER). The HSS function uses MySQL as the user data storage backend and itself is developed in Java. The HSS in OpenIMSCore provides a built-in web-based administration interface for user data provisioning. 4.2 Installation OpenIMSCore developers provide several ways for installing and deploying OpenIMSCore. Source code is available for download (via subversion repository), compilation and configuration. This is the preferred way of installation. No releases are made and nothing but the newest source code revision is supported by the developers. 36

37 Every day a snapshot of current repository state is pulled, compressed and made available for download. These are not releases, though and are provided for convenience only. Virtual Machine images, ready-to-use with the free-to-use VMware Player, are available for download from the OpenIMSCore developers. These images consist of a full Linux operating system with all the necessary things to get IMS up and running. These images contain the preconfigured OpenIMSCore installation with demonstration users already provisioned. These images are not released often and if not based on newest source code, are not supported. The installation from source code was chosen for this deployment because the newest source code can be used and easily updated when needed Installation prerequisites Hardware Any current Linux desktop class machine should be enough. It is recommended to go for the high-end of server hardware with plenty of memory, as many CPUs as possible and fast Gigabit network connection for ultimate performance, but for demonstrating simple deployment none of this is needed Network To deploy a working IMS installation for use on the Internet, a public IP address is needed to avoid unnecessary problems with possible NA(P)T which would be needed if the IMS server was behind a router in a private network. As this installation was not done on the open Internet, simply placing all the computers in one IP network ensured full connectivity between all the network nodes. Because IMS (like SIP) is strongly dependent on correct DNS entries, a controllable DNS server is needed. The server can be either external to the OpenIMSCore machine or on the same server. It is important that all participating machines use the needed DNS entries. This can be achieved by officially delegating the relevant DNS zones to the DNS server under control, or by configuring the 37

38 computers to use the right server for DNS resolving. Because this installation was done in private test bed, the second option was used Software Several software requirements must be met in order to successfully compile and install OpenIMSCore: ~100 MBytes of disk space; GCC3/4, make, JDK1.5, ant; MySQL installed and started; bison, flex; libxml2 (> 2.6), libmysql - both with development headers; Linux kernel 2.6 and ipsec-tools (optional); Optional: openssl for the TLS security; bind installed and running (this is optional - DNS server can be external); web browser on the box or that can connect to the box (for user provisioning). The complete list of Debian packages installed on the server prior to the compilation and installation of OpenIMSCore can be found in Appendix B Installation environment Since performance was not critical in this demonstration, the benefits of virtualization were exploited. The OpenIMSCore was installed inside a virtual machine on a standard laptop workstation. The virtualization technology used was Sun xvm VirtualBox because of ease of use and friendly license 4. When installing a single OpenIMSCore instance, the network layout is simple: one virtual machine attached to a software bridge provided by the host operating system. The Linux bridge acts as a switch for physical computers, thus both the machines could be placed in single private IP network eliminating any routing and NAT-related problems that could emerge. Following illustration shows the layout: 4 VirtualBox comes in two versions: Open Source Edition is distributed under the terms of the GNU GPL. Full VirtualBox package (which was used) is distributed under Sun's VirtualBox Personal Use and Evaluation License (PUEL) which permits unlimited personal and educational use 38

39 Figure 4.2: IMS deployment topology The OpenIMSCore itself was installed on the ims virtual machine, IMS clients were run on the foxy host physical machine. Distinct virtual machine ( mayor ) was used for DNS service. This was because of multiple reasons: It was already configured and used before and it was advantageous to have DNS located externally to the IMS domain (both the IMS domains in later scenario). It was easier to sniff the DNS traffic which had to pass through the software bridge in this setup. Linux operating systems were used: Ubuntu 8.04 (Hardy Heron) on the physical computer and Debian 4.0 (Etch) on the virtual machines. No special software was needed (except the OpenIMSCore itself) Installation procedure The first step is to retrieve the source code. OpenIMSCore is preconfigured to run from default path /opt/openimscore, so the source code should be downloaded there. mkdir -p /opt/openimscore/ cd /opt/openimscore svn checkout ser_ims svn checkout FHoSS 39

40 When the newest source code revision is downloaded, the SER router and FHoSS must be compiled: cd ser_ims make install-libs all cd.. cd FHoSS ant compile ant deploy cd Configuration and customization If all the required software is installed, the compilation in the previous step finishes successfully. Now the environment for running OpenIMSCore must be set up: DNS: an example zone is provided in the package ready to be used. However, it is suitable only when the OpenIMSCore is used locally - on the same machine as the client and DNS server is. To change this, all IP addresses must be changed to the IP address of the server. Then this zone can be used for the DNS server. The default domain is open-ims.test, if this is to be different, it needs to be changed in the zone as well. MySQL: database schema is available in the package for the MySQL database in form of SQL scripts. These can be easily imported as follows (executed in the installation directory /opt/openimscore): mysql -u root -p -h localhost < ser_ims/cfg/icscf.sql mysql -u root -p -h localhost < FHoSS/scripts/hss_db.sql mysql -u root -p -h localhost < FHoSS/scripts/userdata.sql installation: The scripts contain basic values needed for a working OpenIMSCore 40

41 Script icscf.sql hss_db.sql Contents Database structure of the I-CSCF service with sample data (trusted domains and available S-CSCF entities Database structure of the HSS service. userdata.sql Data for HSS service - account information for two default users (alice and bob) and one application server information (for presence service) are the most important Table 4.2: SQL scripts provided in the OpenIMSCore package All the data is intended for the default open-ims.test domain and if used for different domain, have to be changed accordingly. When the environment is correctly set up and code is compiled, the parts of the IMS must be configured. The recommended procedure is to copy all the configuration files to a single directory (e.g. /opt/openimscore) and customize them afterwards: cp /opt/openimscore/ser_ims/cfg/*.cfg /opt/openimscore/ cp /opt/openimscore/ser_ims/cfg/*.xml /opt/openimscore/ cp /opt/openimscore/ser_ims/cfg/*.sh /opt/openimscore/ If the IMS installation is to be accessible from computers other than localhost, all IP addresses in all.cfg and.xml files must be changed to an external interface address. This address must correspond to the address specified in the records specified in DNS server and must be reachable both externally and from the local machine. Also, the domain name must be changed if it is different from the default open-ims.test. To avoid changing all these values by hand (which is tedious and error-prone) a simple re-configuration script (configurator.sh) is available with the OpenIMSCore. The script asks for the new IP address and domain name and changes them in selected configuration files. It is possible to edit all relevant configuration files at once. One drawback of this script is that it is based on replacing text patterns and does not work on files that were already re-configured. In case that such reconfiguration is needed, either the original files should be copied over the customized ones or the script can be edited to reflect the current state of the configuration files. 41

42 To run the HSS service, the user which will run it has to have JAVA_HOME environment variable set correctly. In this setup, its value should be /usr. To avoid manually setting it by hand, a line export JAVA_HOME=/usr can be added to the.bashrc file of the user. 4.3 Running All components of the OpenIMSCore installation must be executed separately and run in parallel. This is done by running the pcscf.sh, icscf.sh and scscf.sh scripts for CSCF functions and fhoss.sh script for HSS service. All these services output much debugging information which is useful for troubleshooting and checking connected services and users. The paths in these startup scripts are absolute and need to be edited if the installation directory is different from /opt/openimscore/. Now, the installation is operational and accessible for the two default users: alice@open-ims.test and bob@open-ims.test (or different domain if all the necessary changes were done). 4.4 Two-domains setup When deploying two distinct IMS domains on two machines, very similar logical topology was used: one virtual machine ims2 was attached to the software bridge and same software was installed as on the ims machine. Then, OpenIMSCore was configured to provide services for the open-ims2.test domain. 42

43 Figure 4.3: Two-domain IMS deployment topology All the changes mentioned in the previous section needed to be performed: the domain in all configuration files and SQL scripts was changed; the listen IP address in configuration files was changed; the DNS zone was edited accordingly (DNS configuration files for both open-ims.test and open-ims2.test zone are in Appendix D). This setup was done to test the possibility of configuration of OpenIMSCore in practice. The steps described above were sufficient to deploy another IMS domain on different server and perform IMS calls between these two domains. The virtual machine images of all the servers in this scenario are included on the DVD in Appendix E. 4.5 IMS call flow example A simple call between two IMS users within the same IMS domain will be described and evaluated here. The single-domain setup (see Figure 4.2) was prepared in order to demonstrate this call. 43