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:[email protected] 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:[email protected]>; tag=3c14b434-8f39-de11-80f7-001e68131dce Call-ID: ae10b434-8f39-de11-80f7-001e68131dce@foxy To: <sip:[email protected]> 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 [email protected]. 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: [email protected] and [email protected] (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

44 In this example, IMS user Alice (identified called Bob Bob answered the call and after they were done talking, Alice terminated the call. The call flow is following: 44

45 Figure 4.4: IMS-to-IMS call flow example 45

46 Figure 4.4 shows the call initiation procedure in IMS: The calling user's UE constructs the initial INVITE request and sends it to its P-CSCF (which was discovered during connecting to the network or preconfigured). The INVITE request passes through the CSCF functions and finally reaches its intended recipient. The order of CSCFs in which the message is routed is following: The P-CSCF receives the message and forwards it to the S-CSCF of the calling user. The S-CSCF of the calling user forwards the message to the S-CSCF of the called user. In this scenario these two logical entities happen to be the same server instance so it seems that the S-CSCF is forwarding the message to itself. The S-CSCF of the called user forwards the message to the P-CSCF of the called user and it forwards the message to the called user's UE. The callee responds by sending a 101 Dialog establishment provisional response followed by 180 Ringing provisional response which indicates that the called user is being alerted about the call. The caller sends a PRACK request to the called user to acknowledge the reception of the 180 provisional response (the PRACK request was designed as a reliability mechanism for provisional responses like ACK request provides for 2xx final responses to INVITE. It is standardized in [26]). The 200 OK response to the PRACK request is sent from the called user to the calling user. The callee responds to the initial INVITE request by a 200 OK final response with SDP payload carrying the desired session parameters. The reception of the final response is acknowledged by sending an ACK back. When this request is received, the multimedia session is considered established and the call parties can start exchanging multimedia data as was negotiated. After the session is over, one party terminates it by sending a BYE request related to the session. The other party confirms the termination by responding with a 200 OK final response. 46

47 Every message in this sequence of messages between the call participants is routed through the IMS domain according to [22]. This Technical Specification defines the behavior of all related IMS functions and all IMS implementations must adhere to it. The progress of the session initiation setup will be evaluated in following sections when SIP-to-IMS interworking will be evaluated. 4.6 Encountered problems and suggested solutions The IMS installation could be done without any significant problems. A detailed step-by-step installation guide is provided and following it, the IMS was successfully installed. Only minor issues have shown up: There is no documentation available on what configuration files are to be changed when configuring the IMS to serve different domain than the default open-ims.test. The re-configuration script is useful but does not change all necessary files (e.g. the SQL scripts containing the domain information and user identities). The configuration files needed to be carefully examined to determine the needed changes. Binding the IMS entities to IP address to listen on all network interfaces does not work as expected, the CSCFs insert this address to SIP header fields and the messages are not handled properly. The servers need to be configured to listen on the particular IP address on a network interface. Advanced Linux knowledge and skills were needed to successfully administer and troubleshoot some IMS issues and to deploy it in virtual environment. Although not related to IMS, VirtualBox virtual machines had connectivity problems when attached to the virtual networking interfaces connected to the software bridge, especially when NAT and routing was performed on the host machine. Certain combinations of virtual machines and virtual networking interfaces did not work for unknown reason and after each reboot of the host machine, a different working combination had to be found. 47

48 5 SIP-to-IMS interworking As one of the main components in IMS architecture is the SIP protocol, the backward compatibility between an IMS network and pure SIP-enabled network is the main point of interest of this work. It would be beneficial if this interworking would work seamlessly. The SIP-based internetwork could be transitioned to IMS one domain at a time without a significant disruption of service. 5.1 Proposed scenarios To map the current situation with the OpenIMSCore reference implementation, several test cases were performed and evaluated. The attention was paid primarily on interworking between two disparate domains - IMS domain with OpenIMSCore and a SIP domain. There are two approaches in providing SIP-based VoIP services in current open-source industry: All-in-one feature-rich PBX solutions providing complex VoIP services in one single package. SIP routers providing basic specified functionality with no or limited functions. These routers can be extended by adding internal modules or external servers. With both the SIP server solutions, same test was performed: An IMS user was registered in his domain, a SIP user was registered in the SIP domain A VoIP session was initiated to test the interworking between IMS and SIP. Both parties were tested as the calling users, to check whether the behavior is consistent regardless of the call initiator. In all cases, the network traffic was captured on both virtual servers by tcpdump software and then analyzed in Wireshark network analyzer. Call flows were 48

49 drawn to illustrate the progress of session establishment and a were described in detail. 5.2 OpenIMSCore interconnected with OpenSER Server software SIP Express Router (SER) is a high-performance, configurable, free SIP server licensed under the open-source GNU GPL license. It can act as SIP registrar, proxy or redirect server. SER can be configured to serve specialized purposes such as load balancing or SIP front-end to application servers. Unlike Asterisk PBX, it is really only a SIP server - it offers functions provided by SIP. Additional functions and services can be provided by separate modules or application servers. This makes its logic much simpler. Being modular and written in C, it is lightweight and fast. Developers claim that it can handle thousands of calls per second being established and torn down on a single dual-cpu PC. Also, it is scalable to virtually unlimited number of subscribers [27]. This makes SER good choice for deploying as a SIP proxy on a backbone of a SIP infrastructure where many calls per second are signaled. The routing logic can be very simple or very complex, depending on the specific needs. In 2004, OpenSER project was started by two core developers of SER after moving of the team from Fraunhofer institute to company iptel.org. In 2008, it was renamed to Kamailio because of trademark issues. Shortly thereafter, the OpenSIPS project was created as a Kamailio fork because of a conflict between the core developers. Later in 2008, the Kamailio developers announced to join the original SER developers to form the sip-router project which aims to create a common collaboration framework for all projects related to SER. As a result, there are several possibilities when choosing a software for performing SIP routing, each with different support, documentation quality and development policy. 49

50 OpenSER was selected as the representative of the SER-based group of SIP server solutions. The version included in the Debian 4.0 was used. It is the version 1.1.0, which is quite old and stable release. It is also unaffected by the political changes in the project. Figure 5.1: IMS with OpenSER testing scenario topology Testing setup The OpenSER package was installed on the mayor.localdomain virtual machine and configured to provide services for the mayor.localdomain domain. The appropriate DNS SRV records for _sip, _sip._udp and _sip._tcp services were added to the DNS server. The OpenSER in default configuration provides user registration without authentication. A user with identification [email protected] was used to register (the same user will be used in the Asterisk-based scenario as well). Minimal changes were done to the default configuration, to avoid complexity of the SIP messages processing and test the behavior in most basic conditions. To specify domain for the router to server, following line was added to the openser.cfg file: alias=mayor.localdomain 50

51 5.2.3 IMS-to-SIP session establishment evaluation A call from an IMS domain to a user in a SIP domain was established with the following call flow (see Appendix C for SIP messages headers): Figure 5.2: IMS-to-SIP call flow using OpenSER Routing of the initial INVITE request was performed as follows: Alice's UE constructed the INVITE request and sent it to its P-CSCF (F1). At least two Route header fields should be inserted in the SIP request header (as specified by [22], sub-clause 5.1.2A.1.1) with the value of P-CSCF URI and S-CSCF URI received in the Service-Route header field saved from the 200 OK response to the last (re-)registration. However, only one Route header field containing the S-CSCF URI is present in the INVITE request. Also, the client must include the Accept header field with value application/sdp (required in sub-clause of [22], but not required by [4]). This is not the case, which does not conform to the specification. The P-CSCF sends back a 100 provisional response (F2). Alice's P-CSCF after modifying the header fields regarding the user identity (removal of P-Preferred-Identity header field and adding an appropriate P-Asserted-Identity header field), should remove its URI from the 51

52 top-most Route header field in the request (sub-clause of [22]). But as the client didn't insert this URI in the request, this step is not performed. Then it adds its own address to the Via header field and its SIP URI to the Record-Route header field to enforce routing of subsequent messages through itself. Afterwards, charging information is added to the P-Charging-Vector header field and the request is forwarded based on the top-most Route header field (in accordance with the procedures of [4]). In this case, the request is forwarded to the S-CSCF (F3). The S-CSCF sends back a 100 provisional response (F4). The S-CSCF removes its own SIP URI from the top-most Route header field. The request contains P-Preferred-Service header field indicating the service that the IMS user requests. S-CSCF should check whether the served user has this service subscribed and: if he does, remove the P-Preferred-Service header field and include a P-Asserted-Service header field, if he does not, either reject the request by returning a 403 Forbidden response, or remove the P-Preferred-Service header field and determine the service admission as if the request was received without this header field. The S-CSCF forwards the request with the original value of the P-Preferred- Service header field which seems to be non-conformant to the specification ([22], sub-clause , step 4B). The S-CSCF adds itself to Record-Route and Via header fields. The S-CSCF performs a DNS lookup for _sip._udp SRV record of the domain part of the Request-URI - _sip._udp.mayor.localdomain in this case. Then it forwards the request to the received destination. If such SRV record does not exist, the request is forwarded to just the domain part of the Request- URI. In this case the request is forwarded to the mayor.localdomain server at (F5). (F6). The mayor.localdomain SIP router sends back a 100 provisional response The OpenSER SIP router at mayor.localdomain processes the received request as a standard SIP request as described in [4] (sub-clause 16.5). First, it sends back the 100 provisional response. The proxy can determine the request 52

53 target because the user is registered. It rewrites the Request-URI from to and forwards the request to the UE of user 1000 (F7). The UE of the called user sends back two 100 Trying provisional responses. The first response (F8) is sent immediately, the second one (F9) shortly thereafter, with tag parameter added to the To header field. [4] (subclause ) specifies that the 100 provisional response MAY contain the tag in To header field (all other provisional responses MUST contain this tag). Ekiga softphone seems to be willing to be on the safe side either way. Routing of the 180 Ringing provisional response: The 180 Ringing provisional response is created and sent for the calling user. The SIP client copies the From, Call-ID, CSeq, Via, To (sub-clause of [4]) and Record-Route (sub-clause of [4]) header fields maintaining order of the values in Via and Record-Route header fields. Tag is added to the To header field. The response is forwarded according to SIP forwarding procedure to the address in top-most Via header field (the OpenSER router at mayor.localdomain) (F10). The OpenSER router processes the response according to [4] (sub-clause 16.7) - removes the top-most Via header field and forwards the response to the address in the new top-most Via header field (which is Alice's S-CSCF) (F11). The S-CSCF is required to insert a P-Charging-Function-Addresses header field populated with values received from the HSS if the message is forwarded within the S-CSCF home network ([22], sub-clause ). The message is forwarded to the P-CSCF inside the home network but no P- Charging-Function-Addresses header field is inserted, which is nonconformant. The response is forwarded as usually - with removing top-most Via header field and forwarding it to the address in the new top-most Via header field to the P-CSCF (F12). According to sub-clause of [22], the P-CSCF stores the information needed to keep the dialog state and forward the request in accordance with the procedures of [4]. As the P-Charging-Function- 53

54 Addresses header field is absent, the P-CSCF can not store its value although required to do so. The response is then forwarded to the Alice's UE (F13). Routing of the 200 OK final response: The 200 final response is forwarded the same way as the 180 provisional response (F14 through F17). Routing of the ACK request: The IMS UE populates this request with Route header fields with addresses of proxy routers found in Record-Route header fields of the received final response. The request is then forwarded to the called party through these routers (F18 through F21). Routing of the BYE request for session termination: The BYE request starts a new transaction within the SIP dialog, thus it is identified by new CSeq number. The tags in To and From header fields and the Call-ID header field value are the same as in the INVITE-related transaction. The route of the request is predetermined by the UE - Route header fields are inserted in the request like in the ACK request described above. The request is then forwarded through the P-CSCF, S-CSCF and OpenSER router to the other party. Each entity along the path adds its address to the Via header field (F22 through F25). Routing of the 200 OK final response: The final response to the BYE request is forwarded through the same set of entities according to the values in the Via header fields (F26 through F29). When it is delivered to the request originator, the session is successfully terminated. Although several deviations from the specification were discovered and the OpenIMSCore implementation doesn't exactly follow all the procedures defined in [22], these non-conformities are minor and regard charging-related or identity-related header fields. This doesn't prevent the IMS call destined to a SIP domain reach its intended recipient. The IMS extensions to SIP turned out to be done in such a way that interworking between an IMS domain and a SIP domain can be achieved. 54

55 The IMS-to-SIP call was established successfully, in the next test case, the other direction was tried: calling from a SIP domain to an IMS network SIP-to-IMS sesslion establishment evaluation The SIP client was configured with a SIP outbound proxy for this test case: this was done for the SIP messages to be routed to the IMS domain through the OpenSER router. Then the SIP client [email protected] placed a call for [email protected]. The call establishment procedure with evaluation follows (see Appendix C for SIP messages headers): Figure 5.3: SIP-to-IMS call flow using OpenSER Routing of the initial INVITE request: The SIP client creates the initial INVITE request according to [4], subclause The From, To, Call-ID and CSeq header fields are populated to identify a new transaction in a new dialog. The address of the preconfigured outbound proxy router is inserted in a Route header field and the request is forwarded to the outbound proxy (F1). 55

56 The OpenSER router receives the request and processes it as regular SIP request: first it responds by sending back a 100 Trying provisional response (F2). Subsequently it determines the next hop for the request as it does not service the recipient. The next hop is determined by resolving the _sip._udp SRV record of the domain part of the Request-URI from the DNS server. The response contains the FQDN of the I-CSCF function of the target IMS domain and the request is forwarded there. The router adds its address to the Via and Record-Route header fields before passing the request on (F3). The I-CSCF first queries the HSS about the S-CSCF assigned to the called user with a DIAMETER request (sub-clause , step 3 of [22]). Afterwards, it sends back a 100 Trying provisional response (F4). HSS returns the S-CSCF address and the I-CSCF inserts its URI as the top-most Route header field. Because no P-Charging-Vector header field was present in the received request, no action is taken regarding this header field. The request is then forwarded to the S-CSCF based on the top-most Route header field (F5) The S-CSCF sends back a 100 Trying provisional response (F6). The S-CSCF removes its URI from the top-most Route header field. Because the request does not contain a P-Asserted-Service, the S-CSCF may either reject the request by generating a 403 Forbidden response or evaluate the contents of the request and check whether the requested service matches the subscribed service of the called user. If not, the S-CSCF may also reject the request based on operator's policy ([22], sub-clause , step 3D). The S-CSCF is supposed to insert P-Charging-Function-Addresses header field into the request (step 5) but does not. It inserts address of P-CSCF to a Route header field and adds a P-Called-Party header field containing the Request- URI. As the request is not routed to an AS inside a trust domain, S-CSCF adds its URI to a Record-Route header field. It adds its address to the Via header field and the request is forwarded based on the top-most Route header field - to the P-CSCF (F7). The P-CSCF sends back a 100 Trying provisional response (F8). The P-CSCF adds its SIP URI to a Via header field and its URI to Record- Route header field and forwards the request to the UE (F9). 56

57 The UE sends back a 100 Trying provisional response (F10). Then it generates a 101 Dialog Establishment provisional response and sends it to the P-CSCF (F11). The Via and Record-Route header fields in this provisional response are copied from the received request, thus forcing the response to take the same path in reverse order. All the dialog- and transaction-identifying header fields are also copied to the response. Routing of the provisional responses: The P-CSCF adds a P-Asserted-Identity to the response. Otherwise, the response is routed to the call initiator based on the Via header (the top-most entry is removed and the request is forwarded to the address in the new topmost header field (F12 through F15). The UE then creates another provisional response, the 180 Ringing response and sends it back to the calling user (F16 through F20). This response is handled the very same way as the preceding 101 provisional response. Routing of the 200 OK final response: When the called user answers the call, the 200 OK final response is generated, sent and routed the same way as both provisional responses (F21 through F25). Routing of the ACK request: The calling user's UE generates an ACK request confirming the session. All the identification header fields are copied from the received final response, the new CSeq header field value is generated and all proxy servers listed in Record-Route header field of the final response are copied to Route header field of this request. As I-CSCF did not add its URI to Record-Route header field, this request and any subsequent messages in this dialog will not be routed through it. This request is then sent and reaches the other party of the just established call through the OpenSER router, S-CSCF and P-CSCF (F26 through F29). Routing of the BYE request: The calling user terminated the call by sending a BYE SIP request. The UE inserts addresses of the proxy routers along the route to the Route header 57

58 field. The request is then forwarded through the proxies in this order. Each proxy adds its address to the Via header field (F30 through F33). Routing of the 200 OK final response: The 200 OK final response to the BYE request is forwarded along the same path in the opposite direction based on the Via header field contents (F34 through F37). This testing scenario has also revealed that although some procedures defined in the specification [22] are not followed exactly, these non-conformities do not prevent SIP-to-IMS interworking from functioning. The deviations found might have impact on IMS-related functionality of the IMS domain like charging or user admission but the IMS core network is capable of receiving the VoIP calls from a SIP-based network. Both tests have shown that the OpenSER SIP server is capable of handling the SIP messages received from an IMS domain in such a way that interconnectivity is possible. Also, the messages sent to the IMS domain are handled properly and no intermediate message processing or translation is required. The interconnectivity is transparent for the end-users on both sides of the calls - neither the IMS user nor SIP user need to know that they are calling a user of a different network type. 5.3 OpenIMSCore interconnected with Asterisk Server software Asterisk is an implementation of a telephone private branch exchange (PBX) for VoIP. It allows connected user-agents to reach each other and to reach outside telephone services. It can be used as a PBX for switching calls, managing routes, providing features and connecting callers with the outside world over IP, analog (POTS) and digital connections. Asterisk provides many features to the users and is much more than a simple SIP proxy forwarding SIP messages. It can also provide services unrelated to SIP but common in telephony. 58

59 Examples of features and services in Asterisk are voic , IVR (Interactive Voice Response), call routing, forwarding, monitoring, ENUM support (used to translate "common" telephone numbers to SIP URIs using DNS), music on hold and much more. It supports many audio codecs and is capable of transcoding between them. Asterisk understand several signaling and VoIP protocol including SIP, H.323, MGCP or IAX (Inter-Asterisk Exchange) and is capable of translating signalization between them. As such, it can be used as a media and signaling gateway between multiple networks that wouldn't understand each other. The PBX is modular and therefore extensible. All these characteristics make Asterisk an excellent choice for PBX that endusers register to and use services of. Multitude of available features offer the endusers many services in addition to basic session establishment provided by SIP. Also, the administrators can benefit from a complete VoIP solution offered in one package. The downside of such complex solution is that it is resource-demanding. Being not only a SIP proxy server, it needs to process the SIP messages and take actions which are often resource-intensive (transcoding a call between two codecs or recording a message for an unavailable user and sending it to his mailbox, for example). To provide its functions, it works as a B2BUA: when a user dials an extension number, the call is set up between the UE and Asterisk itself. If Asterisk determines that the call is intended for another UE, it initiates a different session (call) to the intended recipient. Thus, it is not suitable for deployment as a SIP proxy that needs to process many SIP messages and just forward them to a correct destination. There are several VoIP solutions derived from Asterisk for various reasons. Some just add functions and facilitate the deployment process for the administrator and actually contain software bundled with Asterisk. An example of such product is trixbox (formerly asterisk@home). trixbox is a bootable CD that automatically changes a computer into an Asterisk PBX with graphical tools for configuration. It is very convenient to use a graphical front-end to configure a PBX, but it can be problematic, especially when advanced configuration 59

60 tasks are to be performed. The way the front-end creates and modifies the configuration files can conflict with manual changes that are sometimes desirable. Other projects are actual forks with own source code. CallWeaver (formerly known as OpenPBX.org) is one such example. Unlike original Asterisk (developed by a commercial company Digium), it is community-developed and vendorindependent. The project was created because of multiple reasons and general discontent with current Asterisk status and development by Digium [28]. These derivates have one thing in common with Asterisk - they offer a complete VoIP solution in one package and SIP is only one part of the whole product. For testing of SIP-to-IMS interworking, the original Asterisk project was selected. It was unnecessary to dedicate a separate server for the VoIP PBX which would be required in case trixbox would be selected and the configuration frontend was not needed as the configuration was minimal. Figure 5.4: IMS with Asterisk testing scenario topology Testing setup Version of Asterisk PBX was used as the newest version of the 1.4 branch. This version needed to be manually compiled and installed on the server. mayor.localdomain machine was used for this purpose. Asterisk was installed in parallel to the OpenSER from the previous tests. These two servers can not be run 60

61 simultaneously, so OpenSER needed to be shut down prior to launching Asterisk PBX. One SIP user was declared in Asterisk configuration, to be able to register to the PBX and receive VoIP calls. Following changes were done to the sip.conf configuration file (specifying the domain the PBX is serving and adding one user, realm=mayor.localdomain domain=mayor.localdomain [1000] type=friend host=dynamic username=1000 secret=pass dtmfmode=rfc2833 context=default callerid="andrej" <1000> qualify=yes nat=no canreinvite=no Following additional configuration in the [default] call context was done in the extensions.conf file: exten => _XXXX,1,Dial(SIP/${EXTEN},30) exten => exten => exten => [macro-uridial] ;; Cut out the ";user=phone..." bits at the end of SIP URI that some clients add exten => s,1,set(dialuri=${cut(arg1,\;,1)}) exten => s,n,dial(sip/${dialuri},120,tr) exten => s,n,congestion() This ensures that calls destined for any four-digit user in the served domain are forwarded by SIP to the user in the local domain. Also, it allows local clients to place calls to other SIP domains (from mayor.localdomain to open-ims.test in this case). As DNS records were already configured, they were kept the same as in the previous scenario. 61

62 5.3.3 IMS-to-SIP session establishment evaluation When trying to initiate a call from the IMS domain to a user in SIP domain, the call fails. A 420 (Bad extension (unsupported)) final error response is sent to the initial INVITE request. The UCT IMS Client is configured to request a QoS resource reservation prior to session setup by default. This is done by sending a Require: precondition header field in the SIP request with QoS requirements detailed in the SDP payload. [4] specifies: If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). This is the case and Asterisk behaves correctly. To successfully establish a call, QoS strength must be changed to None in UCT IMS Client of the calling user. Figure 5.5: IMS-to-SIP call flow using Asterisk The above call flow illustrates the call initiation from IMS domain to SIP domain served by Asterisk PBX. The messages in this scenario can be found on a DVD in Appendix E. The initial INVITE request is processed identically to the OpenSER scenario - the request was routed through P-CSCF and S-CSCF to the mayor.localdomain server. But Asterisk, unlike the OpenSER router, did not forward the SIP request like 62

63 a SIP router, but generated a new dialog to the called user, separate from the dialog being established from the caller. After the 180 Ringing provisional response was received from the called user, a separate 180 Ringing provisional response was created and sent back to the calling user. When the called user answered the call, the PBX replied to the 200 OK final response by sending an ACK SIP request. It then sent a separate final response to the calling user, which was then confirmed by an ACK request. At this time, two separate sessions representing two separate calls are established. In fact, both clients are sending multimedia data to the Asterisk PBX, which forwards the RTP data to the other call party. If necessary, transcoding between different codecs is performed. Asterisk is by default configured to re-invite the call participants in such a way that the RTP stream is established directly between them. But as this behavior complicates call initiation, it was turned off (by the canreinvite=off configuration directive). The signalization processing in this case was almost identical to the one performed with the OpenSER router. The fact that the call was not terminated directly at the called user's UE, was not affecting the processes in the IMS domain in any way. Also, Asterisk turned out to be capable of processing and generating SIP messages in a way that does not conflict with the SIP-to-IMS interworking SIP-to-IMS call establishment evaluation The SIP client was configured to use the Asterisk PBX as an outbound proxy similarly to the OpenSER testing setup. Figure 5.6 illustrates the call flow of this case. The messages in this scenario can be found on a DVD in Appendix E. 63

64 Figure 5.6: SIP-to-IMS call flow using Asterisk The call was initiated in very similar manner as in the OpenSER testing scenario with the substantial difference that Asterisk acted as a B2BUA. This however did not affect the way the SIP messages were routed between the IMS entities. The SIP UA generated an initial INVITE that was sent to the Asterisk PBX. Asterisk challenged the UA to authenticate itself with a 407 Proxy Authentication Required error response which was acknowledged by sending an ACK request. After Asterisk received the INVITE request with correct credentials, it responded with a 100 Trying provisional response and started to initiate a SIP session with the called user on behalf of the calling user. The created INVITE request was sent to the I-CSCF (address of which was retrieved from the DNS by resolving a SRV record for _sip._udp.open-ims.test domain). The request traversed I-CSCF, S- CSCF and P-CSCF on its way to the callee's UA. Each entity along the way responded to the request by sending a 100 provisional response. Two provisional responses were send by the callee's UA: 101 Dialog Establishment and 180 Ringing, 64

65 both of them were sent back along the same path (by means described above). The 200 OK Final response was generated and sent when the called user answered the call and took the same route. After receiving the final response, Asterisk sent an ACK request to the called user's UA and immediately sent a 200 OK Final response to the caller's UA. Caller's UA answered by sending the confirmation ACK request and the two sessions were set up. Both call participants sent their voice data to the Asterisk PBX which passed the streams to the other party. When the calling user wished to terminate the call, his UA generated a BYE request which was sent to Asterisk. It immediately responded by a 200 Final response and constructed a BYE request for the called user. It was received by the called user's UA and a 200 OK final response was sent back. This way both the sessions were torn down and the call was over. Similarly as in the OpenSER case, the I-CSCF did not include its URI to the Record-Route header field, thus no messages in the transactions following the initial INVITE-related transaction passed through it. This test has also revealed that calling between the IMS and SIP domains is possible. Call was established also when the called user's IMS UE was configured to require QoS resource reservation, as it does not declare this request when called. Calls in both ways could be established, but unlike the previous testing setup, it is not transparent to the user. When calling a user served by Asterisk, the calling user must disable the QoS requirements to be able to reach his recipient. This is in no way different to calling an IMS user with UE which does not support QoS mechanism but requires the calling user to adjust his UE preferences in case the QoS reservation is used. Besides that, the call establishment is working in both directions. The B2BUA behavior of Asterisk does not interfere with the call initiation in a way that would prevent the call to succeed and although there are in fact two SIP and media sessions established, the users do not need to know this or take any action because of it. Asterisk can be configured to transform the two media sessions to a direct bidirectional media flow between the call participants. This makes call initiation more 65

66 complicated by adding three more re-invites, but it may enhance the call quality (no transcoding is done and delay of media packets is reduced). This more-complicated call initiation also works seamlessly, the SIP messages are processed on all sides according to the required standards (with some minor deviations described above) thus they can interwork well. 5.4 SIP client used in IMS network The SIP clients can be used in two ways in IMS networks: to register directly with the IMS domain or to place calls to the IMS domain independently of their own domain (this can be achieved by not configuring an outbound proxy in the SIP client or by not registering to any SIP registrar at all) Registering to the IMS domain Several SIP clients were tested to assess their capability of registering in the IMS domain: Ekiga (formerly known as GnomeMeeting) - this client was used in all the previous test scenarios. It is easy-to-use and user-friendly open-source SIP client. Twinkle - a Qt-based free open-source SIP VoIP client for GNU/Linux. X-Lite - a popular free 5 SIP softphone created and distributed by CounterPath. To get traditional SIP clients to register in the IMS domain, additional configuration is required. The user (his private identity) needs to have Digest-MD5 authentication scheme enabled (all authentication schemes are enabled by default for IMS users). Also, S-CSCF needs to be configured - MD5 needs to be set as the default authentication scheme. This authentication scheme is not defined by 3GPP to be used in IMS, but OpenIMSCore implementation supports it as it is based on SIP specification. This is achieved by uncommenting the line modparam("scscf","registration_default_algorithm","md5") 5 free as in beer 66

67 in scscf.cfg configuration file. S-CSCF then needs to be restarted. The SIP client needs to be configured to use an outbound proxy - the P-CSCF. All tested clients support this possibility Ekiga After the S-CSCF in the IMS domain receives the REGISTER request, it challenges the UE to authenticate itself by adding the following header field to the 401 error response header: WWW-Authenticate: Digest realm="open-ims.test", nonce="1d5a61f4889c251e30645ec90d9d31d8", algorithm=md5, qop="auth,auth-int" The client is supposed to re-send the request with correct credentials and response computed from the user identity, pre-shared secret and the one-time challenge string received in the nonce parameter of the WWW-Authenticate header field in the error response. However, Ekiga does not send this REGISTER request and informs the user that the registration has failed. This client thus cannot be used for registration directly to the IMS domain Twinkle Twinkle softphone succeeds in registering to the IMS domain after the account is properly configured. The domain for SIP account and realm for SIP authentication should be set to open-ims.test, user name to bob and authentication name to [email protected] (for this particular user). Also, the Registrar should be set to pcscf.open-ims.test:4060 and outbound proxy should be configured and enabled (also to pcscf.open-ims.test:4060 ). Twinkle does not satisfy requirement defined in sub-clause of [22] - after receiving the 200 OK final response to the REGISTER request, it should send a SUBSCRIBE request for event notification of reg event package to the IMS domain. This is used to notify the UE about changes in the registration status. However, the client does not generate any request. 67

68 Calling from UCT IMS Client to Twinkle works, the fact that Twinkle does not use IMS-specific header fields does not prevent call setup from working. However, calling in the other direction does not work because Twinkle does not support handling of the Service-Route header field received in the final response to the REGISTER request. It does not populate the contents of Route header field with the contents of received Service-Route header field, thus the P-CSCF can not determine the next hop for the request and responds by a 400 Bad Request final error response with textual description Not following indicated Service-Routes X-Lite X-Lite can be also configured to succeed in registering with a IMS registrar. The same configuration values as for Twinkle apply, with the exception of SIP authentication realm which can not be set (it is derived from the SIP domain). The authenticated registration works, but like Twinkle, X-Lite fails to comply with the sub-clause of [22]. It sends a REGISTER request to the IMS domain, but the event package requested is message-summary, not reg. This event package is not supported by the OpenIMSCore, thus an error message 489 Event Package Not Supported is sent as a response. This does not cause registration to fail. Calling from X-Lite to the IMS domain works, the call setup is successful despite X-Lite is a SIP client and does not use IMS-specific header fields. Calls from UCT IMS Client to X-Lite can not be correctly established, though. UCT IMS Client can be configured to offer two audio codecs out of four available in the SDP media description sent in the INVITE request. Unfortunately, none of these codecs are supported by X-Lite and although it starts ringing (and sends 180 Ringing provisional response to the calling user), after answering the call, it is terminated immediately after its successful setup because no matching codecs were found on both sides of the call. The calling in the other direction works because UCT IMS Client can use codecs offered and used by X-Lite, but can not be configured to offer them in SDP. This series of tests revealed that although registration of SIP clients in IMS domains works itself (or at least partially), the full functionality of IMS can not be 68

69 exploited because the SIP clients can not fulfill the requirements that are placed on IMS clients Unregistered calls to the IMS domain All tested SIP clients were able to initiate a call to a registered user in the IMS domain. The clients were not registered to any service themselves. Figure 5.7: SIP-to-IMS call directly from a SIP client The clients resolved the _sip._udp.open-ims.test SRV record in DNS and learned the address of icscf.open-ims.test listening on the port The initial INVITE request was sent to this address and then forwarded from I-CSCF to the S- CSCF inside the IMS domain. S-CSCF sent the request to the called user's P-CSCF (the user was registered, so his location was known) and forwarded to the UE from there. Provisional responses, as well as the 200 OK final response sent after the call was answered, were sent along the same route in the opposite direction. The subsequent ACK request was sent from the SIP client directly to the S- CSCF (as the I-CSCF did not insert its URI to the Record-Route header field) and through the P-CSCF to the called user's UE. Also the BYE request for termination 69

70 was routed this way. Handling of the SIP messages by the entities in the IMS domain was identical to the handling described above. These tests have shown that an IMS user can be reached by a SIP client that simply places a call to his public SIP URI. The call in opposite direction is not possible for obvious reasons, the IMS user can reach the other party by placing a call directly to his IP address and port number, but this is not likely scenario. Even in this case the IMS specification does not hinder the initiation of the SIP call and it is successfully established. It must be noted though that I-CSCF in IMS architecture is a transition point to and from other IMS domains and it might not be always reachable from any address. Because the I-CSCF is also responsible for inserting the correct chargingrelated information to the SIP headers, it might be deployment- and operator's policydependent whether the call will succeed. 5.5 Encountered problems and suggested solutions While capturing the call flow messages, two different dumps needed to be done at once - one for each virtual server. It wouldn't suffice to sniff the traffic flowing between the virtual machines, as messages passed inside one virtual server needed to be tracked. Combining of these dumps turned out to be problematic and thus use of automatic SIP analysis software (such as SIP Scenario Generator 6 ) was complicated. The call flow analysis was thus done by hand, by examining the captured data in Wireshark network analyzer

71 6 Conclusion and future work In this thesis SIP protocol was introduced and its features, architecture and provided services were described. Also IMS with its standardization processes was characterized. An IMS example deployment was done and the process was documented. To ensure that the IMS can communicate with a different IMS domain, the IMS was installed on two servers and their interconnectivity was verified. Several scenarios testing the interworking capabilities between an IMS domain and a SIP domain (served by either the OpenSER or Asterisk server) were carried out and evaluated. A call initiation procedure between the two heterogeneous VoIP networks was examined in detail and every step was compared to the specifications and standards defining this process. Some minor non-conformities were found, but in general the interworking does work and calls to and from both domains can be placed with both tested server solutions. Also, possibility of using a non-ims SIP-based VoIP client in an IMS network was tested but with less success. It was revealed that a SIP client adhering to the standard procedures might work in certain cases, but tested implementations can not be reliably used in an IMS network. The extensions needed for a fully-working IMS client are substantial and the non-ims clients can not be expected to work as they were not developed with possible IMS use in mind. Using of these clients as ordinary VoIP clients calling to the IMS network was successful, though, and the IMS turned out to be compatible with SIP without IMS-specific extensions. Based on this work, several topics might be interesting for further research: A more complete evaluation of specification conformance of all processes in the IMS network can be carried out. It can be interesting to research charging procedures and possibilities of user charging within a single operator domain and charging of inter-operator calls. 71

72 Security of IMS is also a topic worth researching, whether in IMS itself (analysis of the current state of security and possibilities of securing the IMS network) or between IMS and SIP domains. Although IMS is designed to work with IPv6, where NAT is not a problem anymore, the transition from IPv4 to IPv6 is still pending, so it would be interesting to evaluate the ways of NAT traversal for IMS needs. 72

73 7 List of abbreviations ANSI ARIB ADSL B2BUA BGCF CSCF FOKUS DNS EDGE ETSI FQDN GPRS GPL GSM GNU HSS HTTP ISDN IAX IVR IBCF ITU-T IANA IETF IP I-CSCF IMS IPTV MGCF MRFC NAPTR NA(P)T NAT NGN POTS PTR PBX P-CSCF PES PSTN PoC QoS RTP American National Standards Institute Association of Radio Industries and Businesses Asynchronous Digital Subscriber Line Back-to-back User Agent Breakout Gateway Control Function Call Session Control Function Das Fraunhofer-Institut für Offene Kommunikationssysteme Domain Name System Entanced Data rates for GSM Evolution European Telecommunication Standards Institute Fully-Qualified Domain Name General Packet Radio Service General Public License Global System for Mobile communications GNU's Not Unix Home Subscriber Server HyperText Transfer Protocol Integrated Services Digital Network Inter-Asterisk Exchange Interactive Voice Response Interconnection Border Control Function International Telecommunication Union - Telecommunication Standardization Sector Internet Assigned Numbers Authority Internet Engineering Task Force Internet Protocol Interrogating Call Session Control Function IP Multimedia Subsystem IP Television Media Gateway Control Function Multimedia Resource Function Controller Naming Authority Pointer Network Address (Port) Translation Network Address Translation Next Generation Network Plain Old Telephone System Pointer (DNS record type) Private Branch Exchange Proxy Call Session Control Function PSTN/ISDN emulation subsystem Public Switched Telephone Network Push-to-talk over Cellular Quality of Service Real-time Transport Protocol 73

74 RFC Request For Comment S-CSCF Serving Call Session Control Function SDP Session Description Protocol SIP Session Initiation Protocol SER SIP Express Router SIPS SIP Secure SCTP Stream Control Transmission Protocol SQL Structured Query Language TR Technical Report TS Technical Specification TTA Telecommunications Technology Association TTC Telecommunications Technology Committee ENUM telephone NUMber mapping 3G Third Generation 3GPP Third Generation Partnership Project 3GPP2 Third Generation Partnership Project 2 TCP Transmission Control Protocol TLS Transport Layer Security URI Universal Resource Identifier UA User Agent UAC User Agent Client UAS User Agent Server UDP User Datagram Protocol UE User Equipment VoIP Voice over IP xdsl x-digital Subscriber Line 74

75 8 References [1] AHSON, Syed A., ILYAS, Mohammad, SIP handbook: services, technologies, and security of Session Initiation Protocol, CRC Press, 2008 [2] POIKSELKA, Miikka, NIEMI, Aki, KHARTABIL, Hisham, MAYER Georg, The IMS: IP Multimedia Concepts and Services, John Wiley & Sons Ltd., 2006 [3] [4] ROSENBERG, J., SCHULZRINNE, H., CAMARILLO, G., JOHNSTON, A., PETERSON, J., SPARKS, R., HANDLEY, M., SCHOOLER, E. SIP: Session Initiation Protocol RFC 3261 [5] [6] MEALLING, M., DENENBERG, R. Report from the Joint W3C/IETF URI Planning Interest Group: Uniform Resource Identifiers (URIs), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations RFC 3305 [7] ROACH, A. B. Session Initiation Protocol (SIP)-Specific Event Notification RFC 2543 [8] NIEMI, A. Session Initiation Protocol (SIP) Extension for Event State Publication RFC 3903 [9] CAMPBELL, B., ROSENBERG, J., SCHULZRINNE, H., HUITEMA, C., GURLE, D. Session Initiation Protocol (SIP) Extension for Instant Messaging RFC 3428 [10] SINNREICH, Henry, JOHNSTON, Alan B., Internet Communications Using SIP: Delivering VoIP and Multimedia Services with Session Initiation Protocol, Second Edition, Wiley Publishing, Inc., 2006 [11] CAMPBELL, B., MAHY, R., JENNINGS, C. The Message Session Relay Protocol (MSRP) RFC 4975 [12] HANDLEY, M., JACOBSON, V., PERKINS, C. SDP: Session Description Protocol RFC 4566 [13] SCHULZRINNE, H., CASNER, S., FREDERICK, R., JACOBSON, V. RTP: A Transport Protocol for Real-Time Applications RFC 3550 [14] [15] T/studygroups/com13/ngn2004/working_definition.html] [16] KOVACIKOVA, Tatiana, SEGEC, Pavol, BRUNCKO, Michal. Standardization paths for NGN IMS-based architecture. In: Communications: Scientific Letters of the University of Žilina - ISSN Vol. 10, No. 4 (2008), pp

76 [17] ETSI ES : Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture [18] ETSI TS : Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Network architecture [19] [20] 3GPP TS : 3rd Generation Partnership Project; Technical Specification Group Technical Specification Group Services and System Aspects; Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture [21] 3GPP TS : 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2 [22] 3GPP TS : 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 [23] [24] [25] [26] ROSENBERG, J., SCHULZRINNE, H. Reliability of Provisional Responses in the Session Initiation Protocol (SIP) RFC3262 [27] [28] FAQ 76

77 Appendix A: Header fields in SIP Accept: specifies the content types of bodies the UA understands and wishes to receive. Accept-Encoding: restricts the content-codings that are acceptable in the response. Accept-Language: indicates the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. Alert-Info: is used to specify an alternative ring tone or ringback tone. Allow: lists the set of methods supported by the UA generating the message. Authentication-Info: is used for mutual authentication with HTTP Digest. Authorization: contains authentication credentials of a UA. Call-ID: uniquely identifies a particular invitation or all registrations of a particular client. Call-Info: provides additional information about the caller or callee. Contact: provides a URI whose meaning depends on the type of request or response it is in. Content-Disposition: describes how the message body (or message body part for multipart messages) is to be interpreted by the UAC or UAS Content-Encoding: indicates (when present) what additional content codings have been applied to the entity-body. Content-Language: describes natural language of the intended audience of the message. Content-Length: indicates the size of the message body. Content-Type: indicates the media type of the message body sent to the recipient. CSeq: contains a single decimal sequence number and the request method. This header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if both the sequence number and the request method are identical. Date: contains the date and time. Error-Info: provides a pointer to additional information about the error status response. Expires: gives the relative time after which the message (or content) expires. From: indicates the initiator of the request. This header field may contain an optional display-name meant to be rendered by a human user interface. In-Reply-To: enumerates the Call-IDs that this call references or returns. Max-Forwards: is used to limit the number of proxies or gateways that can forward the request to the next downstream server. Min-Expires: conveys the minimum refresh interval supported for soft-state elements managed by that server. MIME-Version: is used to indicate what version of MIME was used to construct the message. Organization: conveys the name of the organization to which the SIP element issuing the request of response belongs. 77

78 Priority: indicates the urgency of the request as perceived by the client. This is intended for the receiving human or its agent. This header field does not influence the use of communications resources of network elements. Proxy-Authenticate: contains an authentication challenge. Proxy-Authorization: allows the client to identify itself to a proxy that requires authentication. Proxy-Require: is used to indicate proxy-sensitive features that must be supported by the proxy. Record-Route: is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy. Reply-To: contains a logical return URI that may be different from the From header field. Require: is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. Although this is an optional header field, it MUST not be ignored if it is present. Only option tags corresponding to standards-track RFCs can be used in this header field. Retry-After: can be used with some error responses to indicate when the called party anticipates being available again. Route: is used to force routing for a request through the listed set of proxies. Server: contains information about the software used by the UAS to handle the request. Subject: provides a summary or indicates the nature of the call. Supported: enumerates all the extensions supported by the UAC or UAS. Like in Required header field, only option tags corresponding to standards-track RFCs can be used in this header field. Timestamp: describes when the UAC sent the request to the UAS. To: specifies the logical recipient of the request. Unsupported: lists the features not supported by the UAS. User-Agent: contains information about the UAC originating the request. Via: indicates the path taken by the request so far and indicates the path that should be followed in routing responses. The branch ID parameter in the Via header field values serves as a transaction identifier, and is used by proxies to detect loops. Warning: is used to carry additional information about the status of a response. WWW-Authenticate: contains an authentication challenge. 78

79 Appendix B: Packages installed prior to OpenIMSCore installation acpid adduser ant apt apt-utils aptitude base-files base-passwd bash bind9 binutils bison bsdmainutils bsdutils build-essential busybox bzip2 console-common console-data console-tools coreutils cpio cpp cpp-4.1 cron debconf debconf-i18n debian-archive-keyring debianutils dhcp3-client dhcp3-common diff dmidecode dnsutils dpkg dpkg-dev dselect e2fslibs e2fsprogs ed eject file findutils flex g++ g gcc gcc-4.1 gcc-4.1-base gnupg gpgv grep groff-base grub gzip host hostname ifupdown info initramfs-tools initscripts installation-report iproute iptables iputils-ping java-common klibc-utils klogd laptop-detect less libacl1 libapr1 libaprutil1 libatm1 libattr1 libbind9-0 libblkid1 libbz2-1.0 libc6 libc6-dev libc6-i686 libcap1 libcomerr2 libconsole libdb4.2 libdb4.3 libdb4.4 libdbd-mysql-perl libdbi-perl libdevmapper1.02 libdns22 libedit2 libexpat1 libgcc1 libgcrypt11 libgdbm3 libglib2.0-0 libgnutls13 libgpg-error0 libgpmg1 libisc11 libisccc0 libisccfg1 libjaxp1.3-java libklibc libkrb53 libldap2 liblocale-gettext-perl libltdl3 liblwres9 liblzo1 libmagic1 libmysql++-dev libmysql++2c2a libmysqlclient15-dev libmysqlclient15off libncurses5 libncursesw5 libneon26 libnet-daemon-perl libnewt0.52 libopencdk8 libpam-modules libpam-runtime libpam0g libpcap0.8 libplrpc-perl libpopt0 libpq4 libreadline5 libsasl2 libsasl2-2 libselinux1 libsepol1 libsigc c2a libslang2 libsqlite3-0 libss2 libssl0.9.8 libssp0 libstdc++6 libstdc dev libsvn1 libtasn1-3 libtext-charwidth-perl libtext-iconv-perl libtext-wrapi18n-perl libusb libuuid1 libvolume-id0 libwrap0 libx11-6 libx11-data libxau6 libxdmcp6 libxerces2-java libxml2 libxml2-dev linux-image linux-image linux-kernel-headers locales login logrotate lsb-base m4 make makedev man-db manpages mawk mc mktemp module-init-tools mount mysql-client-5.0 mysql-common mysql-server mysql-server-5.0 nano ncurses-base ncurses-bin net-tools netbase netcat ntp ntpdate odbcinst1debian1 openbsd-inetd openssh-blacklist openssh-client openssh-server passwd patch perl perl-base perl-modules procps psmisc readline-common screen sed ssh subversion sun-java5-bin sun-java5-demo sun-java5-jdk sun-java5-jre sysklogd sysv-rc sysvinit sysvinit-utils tar tasksel tasksel-data tcpd tcpdump traceroute tzdata udev unixodbc update-inetd usbutils util-linux vim vim-common vim-runtime vim-tiny wget whiptail x11-common zlib1g zlib1g-dev 79

80 Appendix C: SIP Messages for described call flows IMS-to-SIP session establishment F1 INVITE SIP/2.0 Via: SIP/2.0/UDP :5063;rport;branch=z9hG4bK Route: From: "Alice" To: Call-ID: CSeq: 20 INVITE Contact: Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Max-Forwards: 70 User-Agent: UCT IMS Client Subject: IMS Call Expires: 120 P-Preferred-Identity: "Alice" P-Preferred-Service: urn:xxx:3gpp-service.ims.icsi.mmtel Privacy: none P-Access-Network-Info: IEEE a Require: sec-agree Proxy-Require: sec-agree Supported: 100rel Content-Length: 520 F2 SIP/ trying -- your call is important to us Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" To: Call-ID: CSeq: 20 INVITE Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0 F3 INVITE sip:[email protected] SIP/2.0 Record-Route: <sip:[email protected]:4060;lr> Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK Route: <sip:[email protected]:6060;lr> From: "Alice" <sip:[email protected]>;tag= To: <sip:[email protected]> Call-ID: CSeq: 20 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Max-Forwards: 16 User-Agent: UCT IMS Client Subject: IMS Call Expires: 120 P-Preferred-Service: urn:xxx:3gpp-service.ims.icsi.mmtel Privacy: none P-Access-Network-Info: IEEE a Supported: 100rel Content-Length:

81 P-Asserted-Identity: "Alice" P-Charging-Vector: icid-value="p-cscfabcd4a0e1f d";icid-generatedat= ;orig-ioi="open-ims.test" F4 SIP/ trying -- your call is important to us Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" To: Call-ID: CSeq: 20 INVITE Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0 F5 INVITE sip:[email protected] SIP/2.0 Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip:[email protected]:4060;lr> Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= To: <sip:[email protected]> Call-ID: CSeq: 20 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Max-Forwards: 15 User-Agent: UCT IMS Client Subject: IMS Call Expires: 120 P-Preferred-Service: urn:xxx:3gpp-service.ims.icsi.mmtel Privacy: none P-Access-Network-Info: IEEE a Supported: 100rel Content-Length: 520 P-Asserted-Identity: "Alice" <sip:[email protected]> P-Charging-Vector: icid-value="p-cscfabcd4a0e1f d";icid-generatedat= ;orig-ioi="open-ims.test" F6 SIP/ trying -- your call is important to us Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= To: <sip:[email protected]> Call-ID: CSeq: 20 INVITE Server: OpenSer (1.1.0-notls (i386/linux)) Content-Length: 0 F7 INVITE sip:1000@ :5061;transport=udp SIP/2.0 Record-Route: <sip: ;lr=on;ftag= > Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip:[email protected]:4060;lr> Via: SIP/2.0/UDP ;branch=z9hG4bK93ba.1b772fa7.0 Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= To: <sip:[email protected]> Call-ID: CSeq: 20 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Max-Forwards: 14 User-Agent: UCT IMS Client Subject: IMS Call 81

82 Expires: 120 P-Preferred-Service: urn:xxx:3gpp-service.ims.icsi.mmtel Privacy: none P-Access-Network-Info: IEEE a Supported: 100rel Content-Length: 520 P-Asserted-Identity: "Alice" P-Charging-Vector: icid-value="p-cscfabcd4a0e1f d";icid-generatedat= ;orig-ioi="open-ims.test" P-hint: usrloc applied F8 SIP/ Trying CSeq: 20 INVITE Via: SIP/2.0/UDP ;branch=z9hG4bK93ba.1b772fa7.0 Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" Call-ID: To: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F9 SIP/ Trying CSeq: 20 INVITE Via: SIP/2.0/UDP ;branch=z9hG4bK93ba.1b772fa7.0 Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F10 SIP/ Ringing CSeq: 20 INVITE Via: SIP/2.0/UDP ;branch=z9hG4bK93ba.1b772fa7.0 Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F11 SIP/ Ringing CSeq: 20 INVITE Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F12 SIP/ Ringing 82

83 CSeq: 20 INVITE Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" Call-ID: To: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F13 SIP/ Ringing CSeq: 20 INVITE Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F14 SIP/ OK CSeq: 20 INVITE Via: SIP/2.0/UDP ;branch=z9hG4bK93ba.1b772fa7.0 Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Contact: <sip:1000@ :5061;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 204 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F15 SIP/ OK CSeq: 20 INVITE Via: SIP/2.0/UDP :6060;branch=z9hG4bK93ba.e606ceb4.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Contact: <sip:1000@ :5061;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 204 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F16 SIP/ OK CSeq: 20 INVITE Via: SIP/2.0/UDP :4060;branch=z9hG4bK93ba.0c Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Contact: <sip:1000@ :5061;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 204 Record-Route: <sip: ;lr=on;ftag= >,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> F17 83

84 SIP/ OK CSeq: 20 INVITE Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" Call-ID: To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 204 Record-Route: F18 ACK SIP/2.0 Via: SIP/2.0/UDP :5063;rport;branch=z9hG4bK Route: Route: Route: <sip: ;lr=on;ftag= > From: "Alice" To: Call-ID: CSeq: 20 ACK Contact: Content-Type: application/sdp Max-Forwards: 70 User-Agent: UCT IMS Client Content-Length: 180 F19 ACK SIP/2.0 Via: SIP/2.0/UDP :4060;branch=0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK Route: Route: <sip: ;lr=on;ftag= > From: "Alice" To: Call-ID: CSeq: 20 ACK Contact: Content-Type: application/sdp Max-Forwards: 16 User-Agent: UCT IMS Client Content-Length: 180 P-Asserted-Identity: F20 ACK SIP/2.0 Via: SIP/2.0/UDP :6060;branch=0 Via: SIP/2.0/UDP :4060;branch=0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK Route: <sip: ;lr=on;ftag= > From: "Alice" To: Call-ID: CSeq: 20 ACK Contact: Content-Type: application/sdp Max-Forwards: 15 User-Agent: UCT IMS Client Content-Length: 180 P-Asserted-Identity: F21 ACK SIP/2.0 Record-Route: <sip: ;lr=on;ftag= > Via: SIP/2.0/UDP ;branch=z9hG4bK93ba.1b772fa7.2 Via: SIP/2.0/UDP :6060;branch=0 Via: SIP/2.0/UDP :4060;branch=0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" To: Call-ID:

85 CSeq: 20 ACK Contact: Content-Type: application/sdp Max-Forwards: 14 User-Agent: UCT IMS Client Content-Length: 180 P-Asserted-Identity: P-hint: rr-enforced F22 BYE SIP/2.0 Via: SIP/2.0/UDP :5063;rport;branch=z9hG4bK Route: Route: Route: <sip: ;lr=on;ftag= > From: "Alice" To: Call-ID: CSeq: 21 BYE Contact: Max-Forwards: 70 User-Agent: UCT IMS Client Content-Length: 0 F23 BYE sip:1000@ :5061;transport=udp SIP/2.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bKa3ba.eb0dd964.0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK Route: <sip:[email protected]:6060;lr> Route: <sip: ;lr=on;ftag= > From: "Alice" <sip:[email protected]>;tag= To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Call-ID: CSeq: 21 BYE Contact: <sip:alice@ :5063> Max-Forwards: 16 User-Agent: UCT IMS Client Content-Length: 0 P-Asserted-Identity: <sip:[email protected]> F24 BYE sip:1000@ :5061;transport=udp SIP/2.0 Via: SIP/2.0/UDP :6060;branch=z9hG4bKa3ba.77a07b87.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bKa3ba.eb0dd964.0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK Route: <sip: ;lr=on;ftag= > From: "Alice" <sip:[email protected]>;tag= To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Call-ID: CSeq: 21 BYE Contact: <sip:alice@ :5063> Max-Forwards: 15 User-Agent: UCT IMS Client Content-Length: 0 P-Asserted-Identity: <sip:[email protected]> F25 BYE sip:1000@ :5061;transport=udp SIP/2.0 Record-Route: <sip: ;lr=on;ftag= > Via: SIP/2.0/UDP ;branch=z9hG4bKa3ba.65710df5.0 Via: SIP/2.0/UDP :6060;branch=z9hG4bKa3ba.77a07b87.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bKa3ba.eb0dd964.0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Call-ID: CSeq: 21 BYE Contact: <sip:alice@ :5063> Max-Forwards: 14 User-Agent: UCT IMS Client Content-Length: 0 P-Asserted-Identity: <sip:[email protected]> P-hint: rr-enforced 85

86 F26 SIP/ OK CSeq: 21 BYE Via: SIP/2.0/UDP ;branch=z9hG4bKa3ba.65710df5.0 Via: SIP/2.0/UDP :6060;branch=z9hG4bKa3ba.77a07b87.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bKa3ba.eb0dd964.0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" Call-ID: To: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= > F27 SIP/ OK CSeq: 21 BYE Via: SIP/2.0/UDP :6060;branch=z9hG4bKa3ba.77a07b87.0 Via: SIP/2.0/UDP :4060;branch=z9hG4bKa3ba.eb0dd964.0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= > F28 SIP/ OK CSeq: 21 BYE Via: SIP/2.0/UDP :4060;branch=z9hG4bKa3ba.eb0dd964.0 Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= > F29 SIP/ OK CSeq: 21 BYE Via: SIP/2.0/UDP :5063;rport=5063;branch=z9hG4bK From: "Alice" <sip:[email protected]>;tag= Call-ID: To: <sip:[email protected]>;tag=b811b77f-1b40-de11-93a7-001e68131dce Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Record-Route: <sip: ;lr=on;ftag= > SIP-to-IMS session establishment F1 INVITE sip:[email protected] SIP/2.0 Route: <sip:mayor.localdomain:5060;lr> Date: Sat, 16 May :14:35 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport User-Agent: Ekiga/ From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE 86

87 Content-Type: application/sdp Content-Length: 387 Max-Forwards: 70 F2 SIP/ trying -- your call is important to us CSeq: 1 INVITE Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Server: OpenSer (1.1.0-notls (i386/linux)) Content-Length: 0 F3 INVITE sip:[email protected] SIP/2.0 Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> Date: Sat, 16 May :14:35 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 User-Agent: Ekiga/ From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 387 Max-Forwards: 69 P-hint: outbound F4 SIP/ trying -- your call is important to us CSeq: 1 INVITE Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0 F5 INVITE sip:[email protected] SIP/2.0 Route: <sip:scscf.open-ims.test:6060> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> Date: Sat, 16 May :14:35 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 User-Agent: Ekiga/ From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 387 Max-Forwards: 16 P-hint: outbound F6 87

88 SIP/ trying -- your call is important to us CSeq: 1 INVITE Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0 F7 Request-Line: INVITE sip:alice@ :5063;line=bca265ccb7900fb SIP/2.0 Record-Route: <sip:[email protected]:6060;lr> Route: <sip:[email protected]:4060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> Date: Sat, 16 May :14:35 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP :6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 User-Agent: Ekiga/ From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Type: application/sdp Content-Length: 387 Max-Forwards: 15 P-hint: outbound P-Called-Party-ID: <sip:[email protected]> F8 SIP/ trying -- your call is important to us CSeq: 1 INVITE Via: SIP/2.0/UDP :6060;branch=z9hG4bK592f.f ;rport=6060 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux)) Content-Length: 0 F9 Request-Line: INVITE sip:alice@ :5063;line=bca265ccb7900fb SIP/2.0 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> Date: Sat, 16 May :14:35 GMT CSeq: 1 INVITE Via: SIP/2.0/UDP :4060;branch=z9hG4bK592f.e5a Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 User-Agent: Ekiga/ From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]> Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE 88

89 Content-Type: application/sdp Content-Length: 387 Max-Forwards: 14 P-hint: outbound P-Called-Party-ID: F10 SIP/ Trying Via: SIP/2.0/UDP :4060;branch=z9hG4bK592f.e5a Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" To: Call-ID: CSeq: 1 INVITE User-Agent: UCT IMS Client Content-Length: 0 F11 SIP/ Dialog Establishement Via: SIP/2.0/UDP :4060;branch=z9hG4bK592f.e5a Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> User-Agent: UCT IMS Client Content-Length: 0 F12 SIP/ Dialog Establishement Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> User-Agent: UCT IMS Client Content-Length: 0 P-Asserted-Identity: <sip:[email protected]> F13 SIP/ Dialog Establishement Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> 89

90 Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" To: Call-ID: CSeq: 1 INVITE Contact: <sip:alice@ :5063> User-Agent: UCT IMS Client Content-Length: 0 P-Asserted-Identity: <sip:[email protected]> F14 SIP/ Dialog Establishement Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> User-Agent: UCT IMS Client Content-Length: 0 P-Asserted-Identity: <sip:[email protected]> F15 SIP/ Dialog Establishement Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> User-Agent: UCT IMS Client Content-Length: 0 P-Asserted-Identity: <sip:[email protected]> F16 SIP/ Ringing Via: SIP/2.0/UDP :4060;branch=z9hG4bK592f.e5a Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE User-Agent: UCT IMS Client Require: 100rel RSeq: 1 P-Access-Network-Info: IEEE a Content-Length: 247 F17 90

91 SIP/ Ringing Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: Record-Route: Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" To: Call-ID: CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE User-Agent: UCT IMS Client Require: 100rel RSeq: 1 P-Access-Network-Info: IEEE a Content-Length: 247 P-Asserted-Identity: <sip:[email protected]> F18 SIP/ Ringing Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE User-Agent: UCT IMS Client Require: 100rel RSeq: 1 P-Access-Network-Info: IEEE a Content-Length: 247 P-Asserted-Identity: <sip:[email protected]> F19 SIP/ Ringing Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE User-Agent: UCT IMS Client Require: 100rel RSeq: 1 P-Access-Network-Info: IEEE a Content-Length: 247 P-Asserted-Identity: <sip:[email protected]> F20 SIP/ Ringing 91

92 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: Record-Route: Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" To: Call-ID: CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE User-Agent: UCT IMS Client Require: 100rel RSeq: 1 P-Access-Network-Info: IEEE a Content-Length: 247 P-Asserted-Identity: <sip:[email protected]> F21 SIP/ OK Via: SIP/2.0/UDP :4060;branch=z9hG4bK592f.e5a Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp User-Agent: UCT IMS Client Content-Length: 247 F22 SIP/ OK Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK592f.f Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp User-Agent: UCT IMS Client Content-Length: 247 P-Asserted-Identity: <sip:[email protected]> F23 SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bK592f.e5f6cdb2.0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> 92

93 From: "Andrej Krivulcik" To: Call-ID: CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp User-Agent: UCT IMS Client Content-Length: 247 P-Asserted-Identity: <sip:[email protected]> F24 SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp User-Agent: UCT IMS Client Content-Length: 247 P-Asserted-Identity: <sip:[email protected]> F25 SIP/ OK Via: SIP/2.0/UDP :5068;branch=z9hG4bK2a9ee934-1c40-de11-93a7-001e68131dce;rport=5068 Record-Route: <sip:[email protected]:4060;lr> Record-Route: <sip:[email protected]:6060;lr> Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 1 INVITE Contact: <sip:alice@ :5063> Content-Type: application/sdp User-Agent: UCT IMS Client Content-Length: 247 P-Asserted-Identity: <sip:[email protected]> F26 ACK sip:alice@ :5063 SIP/2.0 Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce>,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> CSeq: 1 ACK Via: SIP/2.0/UDP :5068;branch=z9hG4bKdc c40-de11-93a7-001e68131dce;rport From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]>;tag= Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 F27 Request-Line: ACK sip:alice@ :5063 SIP/2.0 Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> Route: <sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> CSeq: 1 ACK Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.2 Via: SIP/2.0/UDP :5068;branch=z9hG4bKdc c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce 93

94 Call-ID: To: Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 69 P-hint: rr-enforced F28 Request-Line: ACK sip:alice@ :5063 SIP/2.0 Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> Route: <sip:[email protected]:4060;lr> CSeq: 1 ACK Via: SIP/2.0/UDP :6060;branch=0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.2 Via: SIP/2.0/UDP :5068;branch=z9hG4bKdc c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]>;tag= Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 16 P-hint: rr-enforced F29 Request-Line: ACK sip:alice@ :5063 SIP/2.0 Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> CSeq: 1 ACK Via: SIP/2.0/UDP :4060;branch=0 Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=0 Via: SIP/2.0/UDP ;branch=z9hG4bK592f.63b87db2.2 Via: SIP/2.0/UDP :5068;branch=z9hG4bKdc c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]>;tag= Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 15 P-hint: rr-enforced F30 BYE sip:alice@ :5063 SIP/2.0 Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce>,<sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> CSeq: 3 BYE Via: SIP/2.0/UDP :5068;branch=z9hG4bK0ad c40-de11-93a7-001e68131dce;rport From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]>;tag= Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 70 F31 Request-Line: BYE sip:alice@ :5063 SIP/2.0 Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> Route: <sip:[email protected]:6060;lr>,<sip:[email protected]:4060;lr> CSeq: 3 BYE Via: SIP/2.0/UDP ;branch=z9hG4bK392f.b603b447.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK0ad c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]>;tag=

95 Contact: Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 69 P-hint: rr-enforced F32 Request-Line: BYE sip:alice@ :5063 SIP/2.0 Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> Route: <sip:[email protected]:4060;lr> CSeq: 3 BYE Via: SIP/2.0/UDP :6060;branch=z9hG4bK392f.e4825e72.0 Via: SIP/2.0/UDP ;branch=z9hG4bK392f.b603b447.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK0ad c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]>;tag= Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 16 P-hint: rr-enforced F33 Request-Line: BYE sip:alice@ :5063 SIP/2.0 Record-Route: <sip: ;lr=on;ftag=bc9ee834-1c40-de11-93a7-001e68131dce> CSeq: 3 BYE Via: SIP/2.0/UDP :4060;branch=z9hG4bK392f.a471b455.0 Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK392f.e4825e72.0 Via: SIP/2.0/UDP ;branch=z9hG4bK392f.b603b447.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK0ad c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy To: <sip:[email protected]>;tag= Contact: <sip:1000@ :5068;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE Content-Length: 0 Max-Forwards: 15 P-hint: rr-enforced F34 SIP/ OK Via: SIP/2.0/UDP :4060;branch=z9hG4bK392f.a471b455.0 Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK392f.e4825e72.0 Via: SIP/2.0/UDP ;branch=z9hG4bK392f.b603b447.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK0ad c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 3 BYE User-Agent: UCT IMS Client Content-Length: 0 F35 SIP/ OK Via: SIP/2.0/UDP :6060;received= ;rport=6060;branch=z9hG4bK392f.e4825e72.0 Via: SIP/2.0/UDP ;branch=z9hG4bK392f.b603b447.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK0ad c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 3 BYE 95

96 User-Agent: UCT IMS Client Content-Length: 0 F36 SIP/ OK Via: SIP/2.0/UDP ;branch=z9hG4bK392f.b603b447.0 Via: SIP/2.0/UDP :5068;branch=z9hG4bK0ad c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 3 BYE User-Agent: UCT IMS Client Content-Length: 0 F37 SIP/ OK Via: SIP/2.0/UDP :5068;branch=z9hG4bK0ad c40-de11-93a7-001e68131dce;rport=5068 From: "Andrej Krivulcik" <sip:[email protected]>;tag=bc9ee834-1c40-de11-93a7-001e68131dce To: <sip:[email protected]>;tag= Call-ID: b69ae834-1c40-de11-93a7-001e68131dce@foxy CSeq: 3 BYE User-Agent: UCT IMS Client Content-Length: 0 96

97 Appendix D: DNS configuration files open.ims.test zone configuration file: $ORIGIN open-ims.test. $TTL 1D IN SOA mayor.localdomain. thefox.neonus.sk. ( ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum NS mayor.localdomain. pcscf 1D IN A open-ims.test. 1D IN A icscf 1D IN A _sip _sip._udp _sip._tcp 1D SRV icscf 1D SRV icscf 1D SRV icscf open-ims.test. 1D IN NAPTR "s" "SIP+D2U" "" _sip._udp open-ims.test. 1D IN NAPTR "s" "SIP+D2T" "" _sip._tcp scscf 1D IN A hss 1D IN A ue 1D IN A presence 1D IN A open-ims2.test zone configuration file: $ORIGIN open-ims2.test. $TTL 1D IN SOA mayor.localdomain. thefox.neonus.sk. ( ; serial 3H ; refresh 15M ; retry 1W ; expiry 1D ) ; minimum NS mayor.localdomain. pcscf 1D IN A open-ims2.test. 1D IN A icscf 1D IN A _sip _sip._udp _sip._tcp 1D SRV icscf 1D SRV icscf 1D SRV icscf open-ims2.test. 1D IN NAPTR "s" "SIP+D2U" "" _sip._udp open-ims2.test. 1D IN NAPTR "s" "SIP+D2T" "" _sip._tcp scscf 1D IN A hss 1D IN A ue 1D IN A presence 1D IN A

98 Appendix E: DVD containing virtual machine images and call flows 98