Study Program Master Telecommunications and Internet Technologies

Course Application Prototyping

LECTURE NOTE 5
Version: Datum: 2.3 22. 03. 2008

IP MULTIMEDIA SUBSYSTEM (IMS)

Session Control

Dipl.-Ing. Franz Edler

Part 5: Session Control

CONTENTS:
1. Overview.......................................................................... Fehler! Textmarke nicht definiert. 1.1. Content of the Course ................................................ Fehler! Textmarke nicht definiert. 1.2. Structure of the Course .............................................. Fehler! Textmarke nicht definiert. 1.3. Preconditions and further readings and exercises........ Fehler! Textmarke nicht definiert. 1.4. Questions and exercises ............................................. Fehler! Textmarke nicht definiert. 1.5. Target audience.......................................................... Fehler! Textmarke nicht definiert. 2. Basic Session Setup .................................................................................................................5 2.1. The IMS terminal sends an INVITE request......................................................................6 2.2. The originating P-CSCF processes the INVITE request ....................................................8 2.3. The originating S-CSCF processes the INVITE request ..................................................10 2.4. The terminating I-CSCF processes the INVITE request ..................................................10 2.5. The terminating S-CSCF processes the INVITE request..................................................11 2.6. The terminating P-CSCF processes the INVITE request..................................................11 2.7. The IMS terminal of the callee processes the INVITE request.........................................12 2.8. Processing of the 183 Session Progress response .........................................................15 2.9. The callers IMS terminal processes the 183 response ......................................................16 2.10. The callees IMS terminal processes the PRACK request ...............................................18 2.11. The callers IMS terminal finishes resource reservation..................................................19 2.12. The callees IMS terminal finishes resource reservation .................................................19 2.13. Finishing of session setup .............................................................................................21 3. Exercises and Questions ........................................................................................................24 4. References.............................................................................................................................25 4.1. Books on Session Initiation Protocol...............................................................................25 4.2. Books on IP Multimedia Subsystem................................................................................25

Author: Dipl.-Ing. Franz Edler

page: 2 / 25

Part 5: Session Control

1. OVERVIEW
1.1. CONTENT OF THE COURSE
The course offers in depth knowledge on the IP Multimedia Subsystem (IMS). IMS means the architecture and concepts of the new Internet based communications networks, which will replace the traditional TDM1 based fixed and mobile networks in the coming years. The IP Multimedia Subsystem is based on SIP2 and therefore will provide not only voice services (telephony) but also multimedia communications. The IMS further on enables the integration of all available internet protocols and services even if not known today.

1.2. STRUCTURE OF THE COURSE

The course actually comprises the following parts: 1. IMS Overview and Standards 2. Basic Technologies: SIP recap and new protocols and extensions 3. IMS network architecture 4. IMS Identities, Authentication and Registration 5. Basic Session Control 6. User Profile and Provision of Services 7. Charging and Security Architecture 8. Access networks and PCC 9. Presence and Push-to-Talk 10. PSTN Simulation and Emulation 11. IP-TV

1.3. PRECONDITIONS AND FURTHER READINGS AND EXERCISES

The students should have as precondition for this course a solid background in basic internet technologies, in SIP and some of the SIP protocol extensions. Part 2 of this course (Basic Technologies) covers some of the mentioned technologies more as a short recap without offering all details. The student is encouraged to recap the knowledge from other courses, other literature or the Internet3. The author also encourages the students to look up in the mentioned standards, because this is the only firm basis in case of some issues and discussions in your future professional career. There are also some books available, which give deep insight into IMS. Two of them (the yellow and the red book) are preferred by the author. But of course there are more books available meanwhile and further books will come up in the future (see chapter 4). For the best result of the course practical exercises should be done in parallel. The Open IMS Core project of Fraunhofer Fokus4 (an Open Source project) offers an ideal basis to challenge
1 2

TDM = Time Division Multiplex SIP = Session Initiation Protocol, RFC 3261 3 I strongly recommend the Tech-Invite portal http://www.tech-invite.com/ 4 Open IMS Core project of Fraunhofer Fokus http://www.openimscore.org/

Author: Dipl.-Ing. Franz Edler

page: 3 / 25

Part 5: Session Control the theoretical knowledge. Due to the limited amount of time for the course the author can only give some hints and examples how to handle the Open IMS Core software on Linux. To overcome the barriers of installation a VMware image of Open IMS Core is also available for download including some How-To instructions. There is also an implementation of OpenIMSCore on a public server of the University available, which gives a more realistic environment for e.g. development of master theses of students.

1.4. QUESTIONS AND EXERCISES

At the end of each part the student can find some questions which should help to get feedback on the core points of the course. The student should be able to answer the questions and exercises at the end of the course.

1.5. TARGET AUDIENCE

The target audience of this course are students on bachelor degree in the upper classes on telecommunications systems and students for the master degree of Telecommunications und Internet-technology.

Author: Dipl.-Ing. Franz Edler

page: 4 / 25

Part 5: Session Control

2. BASIC SESSION SETUP

The following chapters describe the message flow of a basic session setup between two IMS terminals. For simplicity reasons we assume that no additional services are associated, that means no application server is involved. Figure 1, Figure 6 and Figure 11 show the message flow during this simple session setup divided into three parts. We start at Figure 1. On the first view we see a lot of messages and network nodes involved and we also recognize that both terminals (Alice and Bob) are roaming. Therefore we have four different networks involved (Originating and Terminating Visited Network, Originating and Terminating Home Network). This is the more general case. The P-CSCF of Alice and Bob are not attached at their home networks.
Originating Visited Network Originating Home Network Terminating Home Network Terminating Visited Network

IMS Terminal of Alice

P-CSCF

S-CSCF

I-CSCF

HSS

S-CSCF

P-CSCF

IMS Terminal of Bob

(1) INVITE (2) 100 Trying (3) INVITE (2) 100 Trying Evaluation of initial filter criteria (5) INVITE (6) 100 Trying

(7) Diameter LIR (8) Diameter LIA (9) INVITE (10) 100 Trying Evaluation of initial filter criteria (11) INVITE (12) 100 Trying (13 INVITE (14) 100 Trying (15) 183 Session Progress

PreAlert

(20) 183 Session Progress

(19) 183 Session Progress

(18) 183 Session Progress

(17) 183 Session Progress

(16) 183 Session Progress

Resource Reservation

Figure 1: Basic session setup - part 1

Author: Dipl.-Ing. Franz Edler

page: 5 / 25

Part 5: Session Control Before we go into details we should recognize from a high level view: The signalling flow always includes the two P-CSCFs allocated to both terminals. This is necessary because of the security association between the terminal and the P-CSCF, the compression/decompression algorithm in place and because of the role of the P-CSCF as a border node between untrusted and trusted network. The signalling flow also always includes the two associated S-CSCF of both session participants: the S-CSCF of the originating home network and the S-CSCF of the terminating home network. In the more general case also application servers are involved on both sides. By inclusion of both S-CSCF in a session we can separate the session setup in two halves: - from the originating IMS terminal to the originating S-CSCF, and - from the terminating S-CSCF to the terminating IMS terminal. This is also called the half-call model of IMS5. The I-CSCF and the HSS are only involved at the terminating side. This is due to the fact that on the originating side the associated originating S-CSCF is well known to the IMS-terminal thanks to the Service-Route header field received during the IMS registration.

The above observation on signalling nodes involved in session setup applies only to signalling messages. The media stream is totally separated from signalling and flows directly between the IMS terminals as shown later in Figure 11.

2.1. THE IMS TERMINAL SENDS AN INVITE REQUEST

The IMS terminal of Alice creates an INVITE request (1) as shown in Figure 2. The RequestURI and the To header field contain the Public-User-Identity of Bob in our example in a different network (home2.net). The Via- and Contact- header fields show that the IMS client uses signalling compression. The port indicates the server port of the security association (IPsec). The responses to the INVITE request and of following requests from the session partner within the dialog will be sent to this security port. The Route header shows a preloaded route which consists of the associated P-CSCF and the assigned S-CSCF learned during registration (Service-Route header field). The SIP address of the S-CSCF includes a user part orig which helps the S-CSCF to identify an incoming request as an originating one. The P-Preferred-Identity header field tells the P-CSCF which originating identity should be used by the terminal. This will be checked by the P-CSCF and if it is a valid one (one of the set of identities received during registration in the P-Associated-URI header field) it will be replaced by a P-Asserted-Identity header later on. The Require header field shows that the originating terminal requires SDP preconditions for certain QoS available before session setup continues. Also the security-agreement extensions is in place. The terminal also supports the 100rel extensions (reliable provisional responses) which will be necessary for negotiating QoS later. In SDP part of the request we see an audio and a video component of media stream requested. For both streams the precondition attributes (a=curr, a=des) are included.
5

See also TS 23.218: IM call model Stage 2

Author: Dipl.-Ing. Franz Edler

page: 6 / 25

Part 5: Session Control The P-Access-Network-Info header field included by the terminal carries information about the available access technology and the location if available. It can be used by the home network of Alice to optionally offer specific services, but it should be noted that this information is not delivered to the terminating network due to sensitivity.
INVITE sip:bob@home2.net SIP/2.0 Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059; comp=sigcomp;branch=z9hG4bK9h9ab Max-Forwards: 70 Route: <sip:pcscf1.visitedl.net:5058;lr;comp=sigcomp>, <sip:orig@scscf1.homel.net;lr> P-Preferred-Identity: "Alice Smith" <sip:alice@homel.net> Privacy: none P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net> Call-ID: 3sO9csO3 Cseq: 127 INVITE Require: precondition, sec-agree Proxy-Require: sec-agree Supported: l00rel Security-Verify: ipsec-3gpp; q=0.1;alg=hmac-sha-l-96; spi-c=98765432; spi-s=909767;port-c=5057; port-s=5058 Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Content-Type: application/sdp Content-Length: 569 v=0 o 1073055600 1073055600 IN IP6 1080::8:800:200C:417A s=c=IN IP6 1080::8:800:200C:417A t=0 0 m=video 8382 RTP/AVP 98 99 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 a=rtpmap:99 MP4V-ES m=audio 8283 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event

Figure 2: (1) INVITE request sent by the IMS terminal

Author: Dipl.-Ing. Franz Edler

page: 7 / 25

Part 5: Session Control The Privacy header field tells the network that the user in this case does not require any privacy against untrusted parties (like the callee). It should be noted that the From header field is not policed by any network node. The content has only end-to-end significance and may be set to any arbitrary identity (valid or not). This is why the P-Asserted-Identity header has been defined additionally for IMS. The INVITE request is sent to the associated P-CSCF of the IMS terminal via the secure channel established during the IMS registration.

2.2. THE ORIGINATING P-CSCF PROCESSES THE INVITE REQUEST

The originating P-CSCF now receives the INVITE request via the secure channel associated to the specific IMS terminal. The P-CSCF first does some policing of the request and checks if the IMS terminal acts correctly as follows: It verifies the Route header if the Service-Route has been honoured. If it is not correct it either rejects the request or corrects the Route header. It checks the P-Preferred-Identity header field. If it matches one of the associated Public User Identities of the terminal the P-CSCF uses this identity as the asserted identity. Otherwise or if the P-Preferred-Identity header field is missing it takes the default identity associated with the terminal. It checks the SDP if there is a media stream requested which is not supported by the access network and in this case rejects the request.

The P-CSCF removes and modifies the header fields that relate to the security agreement. It removes the P-Preferred-Identity header field and replaces it with the P-Asserted-Identity header field. The P-CSCF puts also its address in a Record-Route header field of the INVITE request because it always must be included in subsequent exchange of requests within the dialog and the ServiceRoute is only valid for initial requests. It also adds a P-Charging-Vector header field with a unique icid-value (IMS charging identifier). This icid value remains unmodified throughout the lifetime of the dialog and is transferred to all network nodes involved. This enables an easy correlation of charging records generated by different network nodes. The P-CSCF also updates the Via-, Route- and Max-Forwards header fields according to regular SIP routing rules and forwards the request to the next hop (3) which is the S-CSCF according to the Route header field. From now on the INVITE request is handled unencrypted and uncompressed. Figure 3 shows the INVITE request forwarded by the P-CSCF.

Author: Dipl.-Ing. Franz Edler

page: 8 / 25

Part 5: Session Control

INVITE sip:bob@home2.net SIP/2.0 Via: SIP/2.0/UDP pcscf1.visitedl.net;branch=z9hG4bKoh2qrz Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059; comp=sigcomp;branch=z9hG4bK9h9ab Max-Forwards: 69 Route: <sip:orig@scscf1.homel.net;lr> Record-Route: <sip:pcscf1.visitedl.net;lr> P-Asserted-Identity: "Alice Smith" <sip:alice@homel.net> Privacy: none P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=C359A3913B20E P-Charging-Vector: icid-value="W34h6dlg" From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net> Call-ID: 3sO9csO3 Cseq: 127 INVITE Require: precondition Supported: l00rel Contact: <sip: [1080::8:800:200C:417A]:5059;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Content-Type: application/sdp Content-Length: 569 v=0 o=- 1073055600 1073055600 IN IP6 1080::8:800:200C:417A s=c=IN IP6 1080::8:800:200C:417A t=0 0 m=video 8382 RTP/AVP 98 99 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 a=rtpmap:99 MP4V-ES m=audio 8283 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event

Figure 3: (3) INVITE request forwarded by P-CSCF

Author: Dipl.-Ing. Franz Edler

page: 9 / 25

Part 5: Session Control

2.3. THE ORIGINATING S-CSCF PROCESSES THE INVITE REQUEST

The S-CSCF receives the INVITE request. The Route header field (derived from the ServiceRoute header field inserted into the 200 OK response to the REGISTER request) tells the S-CSCF that it is an originating request6. The S-CSCF checks the P-Asserted-Identity header field to identify who originated the INVITE request. If everything goes correct it will than evaluate the initial filter criteria (iFC) being part of the user profile downloaded during registration (Diameter SAA message). The filter criteria contain a collection of triggers that determine whether a request has to traverse one or more Application Servers that provide services to the user. It must be noted that the S-CSCF does not execute services itself, but triggers services to be executed by Application Servers. The S-CSCF always evaluates the initial filter criteria on initial SIP requests7. For simplicity reason we now assume that no filter criteria matches and therefore the request will not be forwarded to an application server. The S-CSCF like the P-CSCF policies the SDP and applies a home network policy. The user might not receive e.g. streaming video if he had not subscribed a corresponding service. In this case the INVITE request will be rejected with 488 Not Acceptable Here. After all that it is now the first time that the destination of the request (the request URI) is looked at. In case of a SIP URI the S-CSCF of the originating home network now tries to route the request to the destination network8. Regular SIP routing according to RFC 32639 applies which means that via DNS query a set of host names and port numbers has been received. These are I-CSCFs of the destination network (terminating home network). The S-CSCF adds another P-Asserted-Identity header field. We remember that for each Private User Identity also a TEL URI is assigned. This TEL URI is necessary for interworking with the circuit switched network based on E.164 numbers. The TEL URI is added now because even if the destination address (request URI) is a SIP URI there may be situations where the session will terminate in the PSTN (e.g. in case of call diversion at the terminating user). Before the S-CSCF forwards the INVITE request to one of the I-CSCFs (5) of the terminating home network it takes care on sensitive information and removes the P-Access-Network-Info header field. It also adds a Record-Route header field because it always will remain in the path for subsequent signalling10 requests.

2.4. THE TERMINATING I-CSCF PROCESSES THE INVITE REQUEST

When the I-CSCF receives the INVITE request it looks at the request URI and tries to find the S-CSCF which cares for the user addressed by the request URI. Remember that during successful registration an S-CSCF was assigned and the address of the S-CSCF was stored in the HSS. The I-CSCF therefore queries (7) the HSS with a Diameter Location-Information-Request (LIR) and as a response gets back (8) a Diameter Location-Information-Answer (LIA) with the address
6

It is worth to mention that this is the only possibility for a S-CSCF to discriminate originating from terminating requests, which is important according to the half call model. 7 Initial requests are those SIP requests that either create a dialog or are stand-alone requests (not subsequent requests). 8 In case of a TEL URI routing is different: the request is resolved to a SIP URI via ENUM or if that is not possible is forwarded to a BGCF. 9 RFC 3263: Locating SIP Servers 10 From 3GPP Release 6 onwards there is more flexibility on Record-Routing of S-CSCF. It might also be possible that the S-CSCF does not record-route if an application server does.

Author: Dipl.-Ing. Franz Edler

page: 10 / 25

Part 5: Session Control of the assigned S-CSCF for the terminating user. It than modifies the SIP routing header fields (e.g. Route,Via, Max-Forwards, etc) according to generic SIP routing rules and forwards the INVITE request to this S-CSCF in the terminating home network (9). In some cases when the terminating network applies special security policies via the I-CSCF the I-CSCF may put its address into the Record-Route header. Thereby it makes sure that every request further on in the dialog passes the I-CSCF and it can obscure any header field which contains an address of a network internal node by encryption (topology hiding). The example in Figure 1 does not assume topology hiding and therefore the I-CSCF does not record-route.

2.5. THE TERMINATING S-CSCF PROCESSES THE INVITE REQUEST

The S-CSCF in the terminating home network first identifies the called user (address of the request URI) and evaluates the initial filter criteria of this user. This procedure is comparable to the procedure executed at the originating S-CSCF for the originating user, but this time done at the terminating S-CSCF for the terminating user. In case any filter criteria which have been downloaded as part of the user profile during the registration matches, the request is forwarded to the corresponding application server. Again we assume in this example that there is no match of a filter criteria and therefore no application server is involved. The S-CSCF now adds its address in the Record-Route header field, because it usually also will remain in the path for subsequent signalling11 requests. The next step is now to forward the INVITE request to the callee. Therefore the S-CSCF replaces the request URI with the Contact address learned during the registration, but before replacing this address it saves the original address of the request URI in a new P-Called-Party-ID header field. It is important to save original address and add it in the request because otherwise this information is lost and if the callee uses multiple Public User Identities it will not know via which identity it has been reached. There might be e.g. different alerting tones assigned to different Public User Identities. The S-CSCF also takes the content of the Path-header which has been stored in the S-CSCF previously during registration and adds the path-addresses into a new Route header. The Path header field at least contains the address of the P-CSCF where the terminating IMS terminal is attached to. In case of enhanced security requirements (topology hiding) the Path header might also contain the address of an I-CSCF. In the simple example in Figure 1 this is not the case and therefore the Route header field only contains one address the address of the P-CSCF. The S-CSCF now forwards the INVITE request (11) to the P-CSCF according to generic SIP routing rules.

2.6. THE TERMINATING P-CSCF PROCESSES THE INVITE REQUEST

The P-CSCF inspects the request URI which already contains the Contact address of the terminating IMS terminal. Based on the IP address (or host name) and port and the P-CalledParty-ID header field the corresponding security channel is identified to forward the INVITE request toward the IMS terminal. The P-CSCF also saves a copy of the P-Called-Party-ID header field for creating a P-AssertedIdentity header field later on in responses.
11

From 3GPP Release 6 onwards there is more flexibility on Record-Routing of S-CSCF. It might also be possible that the S-CSCF does not record-route if an application server does.

Author: Dipl.-Ing. Franz Edler

page: 11 / 25

Part 5: Session Control Before forwarding the request the P-CSCF has to care for privacy which is may be requested. In case the Privacy header field is set to the value id the P-Asserted-Identity header field has to be removed before forwarding to an untrusted network node (the callee). In our example this is not the case (Privacy header field is set to none) and therefore the P-Asserted-Identity header field is kept. The P-CSCF also inserts a P-Media-Authorization header field which will be used by the IMS terminal to authorize a QoS request at the transport layer and forwards the request (13).

2.7. THE IMS TERMINAL OF THE CALLEE PROCESSES THE INVITE REQUEST
The INVITE request (13) shown in Figure 4 is now received at the IMS terminal of the callee. The SDP included in the INVITE request contains the details of the media stream the caller wants to apply and the address and ports where it wants to receive media data. The Require header field tells the IMS terminal that it has to follow the precondition attributes of the SDP and that it has to satisfy these requirements before it alerts the callee. The terminal now enters the pre-alert phase where it will soon start a QoS reservation mechanism. The terminal extracts and stores the P-Asserted-Identity and the P-Called-Party-ID header field for later use when the IMS terminal will be alerted. For now the terminal creates a 183 Session Progress response with the following data: The IMS terminal inserts a P-Access-Network-Info header field which might be used in the terminating home network to apply specific services. The IMS terminal inserts a Require header field with the value 100rel because the precondition extension requires a reliable transmission of responses. The IMS terminal inserts also the SDP to be used on the terminating side with all parameters to control preconditions. The IMS terminal inserts a Privacy header field with the valued id in case privacy of identity is required. In the example no privacy is required and therefore the value none is set. On the terminating side there might also be additional Public User Identities and the caller optionally wants to know which user identity answers. This information is not to be provided by the IMS terminal because the network already knows which identity responds. Therefore the P-CSCF at the terminating network will later insert the correct P-Asserted-Identity header field.

The IMS terminal now has prepared the 183 Session Progress response as shown in Figure 5. Further to be mentioned is the following: The IMS terminal also inserts an a=conf:qos attribute into the SDP which forces to IMS terminal of the caller to send a confirmation when the required QoS preconditions are reached. The Contact header field of the response also contains the proper port of the security channel and the comp=sigcomp attribute to apply for signalling compression.

The 183 Session Progress response is now sent back according to regular SIP response routing rules based on the Via header field (15). It passes all network nodes which were passed by the INVITE request.

Author: Dipl.-Ing. Franz Edler

page: 12 / 25

Part 5: Session Control

INVITE sip:[1081::5:800:200A:B2B2]:5055;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP pcscf2.visited2.net:5056;comp=sigcomp; branch=z9hG4bK2a2qr Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bKvp2yml Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bKralar Via: SIP/2.0/UDP scscf1.homel.net;branch=z9hG4bKslppO Via: SIP/2.0/UDP pcscfl.visitedl.net;branch=z9hG4bKoh2qrz Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Max-Forwards: 65 Record-Route: <sip:pcscf2.visited2.net:5056;lr;comp=sigcomp> Record-Route: <sip:scscf2.home2.net;lr> Record-Route: <sip:scscf1.homel.net;lr> Record-Route: <sip:pcscf1.visitedl.net;lr> P-Asserted-Identity: "Alice Smith" <sip:alice<3homel.net>, <tel:+l-212-555-1234> P-Called-Party-ID: sip:bob@home2.net Privacy: none P-Media-Authorization: 0020000100100101706466312e686f6d65312e6 From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net> Call-ID: 3sO9csO3 Cseq: 127 INVITE Require: precondition Supported: l00rel Contact: <sip:[1080::8:800:200C:417A]:5059;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE Content-Type: application/sdp Content-Length: 569 v=0 o=- 1073055600 1073055600 IN IP6 1080::8:800:200C:417A s=c=IN IP6 1080::8:800:200C:417A t=0 0 m=video 8382 RTP/AVP 98 99 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 a=rtpmap:99 MP4V-ES m=audio 8283 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event

Figure 4: (13) INVITE request received by the IMS terminal of the callee Author: Dipl.-Ing. Franz Edler page: 13 / 25

Part 5: Session Control

SIP/2.0 183 Session Progress Via: SIP/2.O/UDP pcscf2.visited2.net:5056;comp=sigcomp; branch=z9hG4bK2a2qr Via: SIP/2.O/UDP scscf2.home2.net;branch=z9hG4bKvp2yml Via: SIP/2.O/UDP icscf2.home2.net;branch=z9hG4bKralar Via: SIP/2.O/UDP scscfl.homel.net;branch=z9hG4bKslppO Via: SIP/2.O/UDP pcscfl.visitedl.net;branch=z9hG4bKoh2qrz Via: SIP/2.O/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Record-Route: <sip:pcscf2.visited2.net:5056;lr;comp=sigcomp>, <sip:scscf2.home2.net;lr>,<sip:scscf1.homel.net;lr>, <sip:pcscf1.visitedl.net;lr> Privacy: none P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net>;tag=d92119 Call-ID: 3sO9csO3 Cseq: 127 INVITE Require: l00rel Contact: <sip: [1081::5:800:200A:B2B2]:5055;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE RSeq: 9021 Content-Type: application/sdp Content-Length: 634 v=0 o=- 3021393216 3021393216 IN IP6 1081::5:800:200A:B2B2 s=c=IN IP6 1081::5:800:200A:B2B2 t=0 0 m=video 14401 RTP/AVP 98 99 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=conf:qos remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=O a=rtpmap:99 MP4V-ES m=audio 6544 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=conf:qos remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7;

Figure 5: (15) 183 Session Progress sent by the IMS terminal of the callee

Author: Dipl.-Ing. Franz Edler

page: 14 / 25

Part 5: Session Control

2.8. PROCESSING OF THE 183 SESSION PROGRESS RESPONSE

The 183 Session Progress response passes all network nodes which were passed by the INVITE request. The first one, the terminating P-CSCF is the border between untrusted and trusted network area and therefore it verifies if the terminal has created the response correctly. It checks if the Via header field is correct, otherwise an IMS terminal could forget to include some network nodes which produce charging records. The same happens to the Record-Route header field. If anything is wrong the P-CSCF has again two choices: either discard the response or correct the errors. The P-CSCF also inserts a P-Asserted-Identity header field which it populates with the content of the previously saved P-Called-Party-ID header field. The S-CSCF of the terminating network removes the P-Access-Network-Info header field before it forwards the response via the I-CSCF to the originating network (17). The P-CSCF of the originating network removes the P-Asserted-Identity header field in case of privacy (depending on the content of Privacy header field). The P-CSCF also inserts a P-MediaAuthorization header field which will be used by the terminal during resource reservation. The response is now forwarded to the IMS terminal of the caller (20). This is the last step shown in Figure 1.

Author: Dipl.-Ing. Franz Edler

page: 15 / 25

Part 5: Session Control The early dialog is now established. Both terminals have exchanged the first message and now processing continues to follow the QoS precondition requirements. The next part of the signalling flow is shown in Figure 6 below.

Resource Reservation

Figure 6: Basic session setup part 2

2.9. THE CALLERS IMS TERMINAL PROCESSES THE 183 RESPONSE

The callers IMS terminal now focuses on the SDP within the 183 response (20). It checks if the callee has accepted both media streams (audio and video) offered in the INVITE request. It stores the IP address and port numbers where to send later the media streams. It also checks the codecs which are offered by the callee12. The important step now is that the caller exactly selects one codec for audio and video to precisely decide upon the resources required for the session. Otherwise if not narrowed down to exactly one codec the resource reservation would perhaps result in a waste or lack of bandwidth situation. The IMS terminal of the caller sends the codec decision in a PRACK request to the callee (21). In parallel it starts the bandwidth reservation using the P-Media-Authorization token received. It also recognizes that the received SDP contains a a=conf:qos attribute which requires confirmation when the callers terminal has finished resource reservation. The PRACK request sent by the callers terminal is shown in Figure 7.
12

The list of codecs received is the intersection of the codecs supported by both terminals.

Author: Dipl.-Ing. Franz Edler

page: 16 / 25

Resource Reservation

Part 5: Session Control The PRACK request traverses al network nodes that have asked to remain in the signalling path during dialog establishment (Record-Route mechanism). We can see that the I-CSCF of the terminating network is not involved any more and also the HSS. In the simple case we have four network nodes which are involved further on during the dialog: - the P-CSCF and the S-CSCF of the originating side (originating half call) - the P-CSCF and the S-CSCF of the terminating side (terminating half call) In case of application servers being involved additional signalling hops are included.
PRACK sip:[1081::5:800:200A:B2B2]:5055;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E Route: <sip:pcscf1.visitedl.net:5058;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr>,<sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr> From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net>;tag=d92119 Call-ID: 3sO9csO3 Cseq: 128 PRACK Require: precondition, sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96; spi-c=98765432; spi-s=909767; port-c=5057; port-s=5058 RAck: 9021 127 INVITE Content-Type: application/sdp Content-Length: 553 v=0 o=- 1073055600 1073055602 IN IP6 1080::8:800:200C:417A s=c=IN IP6 1080::8:800:200C:417A t-0 0 m=video 8382 RTP/AVP 98 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 m=audio 8283 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event

Figure 7: (21) PRACK request sent by the callers IMS terminal

Author: Dipl.-Ing. Franz Edler

page: 17 / 25

Part 5: Session Control It should be mentioned that the callers IMS terminal now uses a different preloaded route. At the start of the dialog the terminal used the Service-Route as a preloaded route. Now after the Record-Route header has been received in the first response it switches to the dialog route.

2.10. THE CALLEES IMS TERMINAL PROCESSES THE PRACK REQUEST

The callees IMS terminal receives the PRACK request (25) and simply confirms the reception by sending a 200 OK response (26) including an SDP answer (Figure 8). The SDP answer is necessary to finish the 2nd offer/answer exchange. Nothing has to be negotiated anymore.
SIP/2.0 200 OK Via: SIP/2.O/UDP pcscf2.visited2.net:5056;comp=sigcomp; branch=z9hG4bK2a2qr Via: SIP/2.O/UDP scscf2.home2.net;branch=z9hG4bKvp2yml Via: SIP/2.O/UDP scscf1.homel.net;branch=z9hG4bKslppO Via: SIP/2.O/UDP pcscf1.visitedl.net;branch=z9hG4bKoh2qrz Via: SIP/2.O/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net>;tag=d92119 Call-ID: 3sO9csO3 Cseq: 128 PRACK Content-Type: application/sdp Content-Length: 610 v=0 o=- 3021393216 3021393218 IN IP6 1081::5:800:200A:B2B2 s=c-IN IP6 1081::5:800:200A:B2B2 t=0 0 m=video 14401 RTP/AVP 98 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=conf:qos remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=O m=audio 6544 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=conf:qos remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event

Figure 8: (26) 200 OK sent by the IMS terminal of the callee

Author: Dipl.-Ing. Franz Edler

page: 18 / 25

Part 5: Session Control The callee indicates in SDP that no resources are available yet (a=curr:qos local none) and that it still insists on confirmation when resources on the caller side are available (a=conf:qos remote). At the same time the callees terminal starts resource reservation on the (local) access segment. The 200 OK response traverses back to caller according to the Via header fields.

2.11. THE CALLERS IMS TERMINAL FINISHES RESOURCE RESERVATION

When the IMS terminal of the caller receives the 200 OK response (30) it maybe still be engaged in the resource reservation process. Once the reservation is finished (signalled by messages at the transport layer) an UPDATE request is sent to the callee (31). Figure 9 shows this UPDATE request. The UPDATE request contains another SDP offer where the IMS terminal indicates that resources are reserved at the local segment of the caller (a=curr:qos local sendrecv).

2.12. THE CALLEES IMS TERMINAL FINISHES RESOURCE RESERVATION

When the IMS terminal of the callee receives the UPDATE request (35) it also may still be engaged in the resource reservation process or may have it already finished. In both cases it has to respond to the UPDATE request with a 200 OK response reflecting the actual status of resource reservation. In our example we assume that resource reservation at the callee has already been finished as shown in Figure 10 (a=curr:qos local sendrecv). Therefore the callee also can now be alerted. The 200 OK response (36) is sent back on the same route as the UPDATE request based on the Via header.

Author: Dipl.-Ing. Franz Edler

page: 19 / 25

Part 5: Session Control

UPDATE sip:[1081::5:800:200A:B2B2]:5055;comp=sigcomp SIP/2.0 Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E Route: <sip:pcscf1.visitedl.net:5058;lr;comp=sigcomp>, <sip:scscf1.homel.net;lr>,<sip:scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr> From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net>;tag=d92119 Call-ID: 3sO9csO3 Cseq: 129 UPDATE Require: sec-agree Proxy-Require: sec-agree Security-Verify: ipsec-3gpp; q=0.1;alg=hmac-sha-l-96; spi-c=98765432; spi-s=909767;port-c=5057; port-s=5058 Content-Type: application/sdp Content-Length: 561 v=0 o=- 1073055600 1073055604 IN IP6 1080::8:800:200C:417A s=c=IN IP6 1080::8:800:200C:417A t=0 0 m=video 8382 RTP/AVP 98 b=AS:75 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 m=audio 8283 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local sendrecv a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event

Figure 9: (31) UPDATE request sent by the IMS terminal of the caller

Author: Dipl.-Ing. Franz Edler

page: 20 / 25

Part 5: Session Control

SIP/2.0 200 OK Via: SIP/2.0/UDP pcscf2.visited2.net:5056;comp=sigcomp; branch=z9hG4bK2a2qr Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bKvp2yml Via: SIP/2.0/UDP scscfl.homel.net;branch=z9hG4bKslpp0 Via: SIP/2.0/UDP pcscfl.visitedl.net;branch=z9hG4bKoh2qrz Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net>;tag=d92119 Call-ID: 3sO9csO3 Cseq: 129 UPDATE Content-Type: application/sdp Content-Length: 571 v=0 o=- 3021393216 3021393220 IN IP6 1081::5:800:200A:B2B2 s=c-IN IP6 1081::5:800:200A:B2B2 t=0 0 m=video 14401 RTP/AVP 98 b=AS:75 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 m=audio 6544 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local sendrecv a=curr:qos remote sendrecv a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; maxframes=2 a=rtpmap:96 telephone-event

Figure 10: (36) 200 OK sent by the callee

2.13. FINISHING OF SESSION SETUP

The last part of session setup is show in Figure 11. Now the callee is alerted and the IMS terminal sends a 180 Ringing response (41) back to the caller. This response is also shown in Figure 12. When the callers terminal receives the 180 Ringing response (46) it will generate a ringing tone to indicate the caller that the callee now is alerted. This response is also sent reliably (Require: l00rel) and therefore it is acknowledged by a separate PRACK / 200 OK sequence (47 56).

Author: Dipl.-Ing. Franz Edler

page: 21 / 25

Part 5: Session Control

Figure 11: Basic session setup part 3 When the callee finally accepts the session the 200 OK on INVITE (57) is sent is sent to the caller and acknowledged by the ACK request (63). The ACK request sent by the caller is shown in Figure 13. One might detect in above message flow that 180 Ringing response and 200 OK response to INVITE still traverses the I-CSCF. The reason for that are the Via headers accumulated during processing the INVITE request. Only new requests within the dialog and their responses omit the I-CSCF because it did not record-route. So in the end after exchanging 67 messages the session is set up and media stream can flow. One can easily imagine the tear down of the session. There is no additional complexity anymore.

Author: Dipl.-Ing. Franz Edler

page: 22 / 25

Part 5: Session Control

SIP/2.0 180 Ringing Via: SIP/2.0/UDP pcscf2.visited2.net:5056;comp=sigcomp; branch=z9hG4bK2a2qr Via: SIP/2.0/UDP scscf2.home2.net;branch=z9hG4bKvp2yml Via: SIP/2.0/UDP icscf2.home2.net;branch=z9hG4bKralar Via: SIP/2.0/UDP scscf1.home1.net;branch=z9hG4bKslpp0 Via: SIP/2.0/UDP pcscf1.visitedl.net;branch=z9hG4bKoh2qrz Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Record-Route: <sip:pcscf2.visited2.net:5056;lr;comp=sigcomp>, <sip:scscf2.home2.net;lr>,<sip:scscf1.homel.net;lr>, <sip:pcscf1.visitedl.net;lr> P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E From: <sip:alice@homel.net>;tag=ty20s To: <sip:bob@home2.net>;tag=d92119 Call-ID: 3sO9csO3 Cseq: 127 INVITE Require: l00rel Contact: <sip:[1081::5:800:200A:B2B2]:5055;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE RSeq: 9022 Content-Length: 0

Figure 12: (41) 180 Ringing response sent by the IMS terminal of the callee
ACK sip:[1081::5:800:200A:B2B2]:5055;comp=sigcomp SIP/2.0 Via: SIP/2.O/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp; branch=z9hG4bK9h9ab Max-Forwards: 70 P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E Route: <sip:pcscf1.visitedl.net:5058;lr;comp=sigcomp>, <sip:scscf1.homel.net;lr>,<sip: scscf2.home2.net;lr>, <sip:pcscf2.visited2.net;lr> From: <sip:alice@homel .net>;tag=ty20s To: <sip:bob@home2.net>;tag=d92119 Call-ID: 3sO9csO3 Cseq: 127 ACK Content-Length: 0

Figure 13: (63) ACK request sent by the IMS terminal of the caller

Author: Dipl.-Ing. Franz Edler

page: 23 / 25

Part 5: Session Control

3. EXERCISES AND QUESTIONS

After studying this part of the lecture you should be able to answer the following questions: Chapter 2 Basic Session Setup: Why are P-CSCFs always include in message flow to or from the IMS terminals? What is the half call model in IMS? Which are the IMS specific header field inserted by an IMS terminal in an INVITE request? How is the Route header field populated in an initial request (like INVITE)? What happens with the P-Preferred-Identity header field at the P-CSCF? What happens with the P-Access-Network-Info header field? What is it used for? What is the role of the Privacy header field? How is the initial request forwarded to the correct S-CSCF of the terminating network? How can resource (bandwidth) policies be applied at the P-CSCF and S-CSCF? Why does the S-CSCF of the originating home network add another P-Asserted-Identity header field? Which are the network nodes that usually always record-route to remain in the signalling path? What does topology hiding mean? Where are the points during session setup where initial filter criteria are evaluated? What is the P-Called-Party-ID header field used for? Explain the three offer/answer cycles during a generic session setup? Which messages carry which information? Where does the media stream flow regarding the IMS network nodes?

Author: Dipl.-Ing. Franz Edler

page: 24 / 25

Part 5: Session Control

4. REFERENCES
4.1. BOOKS ON SESSION INITIATION PROTOCOL
Henry Sinnreich und Alan B. Johnston: Internet Communcications Using SIP Wiley & Sons, ISBN-10: 0471776572 2nd edition: 2006 Alan B. Johnston: SIP Understanding the Session Initiation Protocol Artech House, ISBN 1-58053-168-7 2. Auflage November 2003

Henry Sinnreich, Alan B. Johnston und R. Sparks: SIP beyond VoIP VON Publishing LLC, www.vonmag.com ISBN: 0-9748130-0-1

4.2. BOOKS ON IP MULTIMEDIA SUBSYSTEM

The yellow book: G. Camarillo, M. Garcia-Martin: The 3G IP Multimedia Subsystem (IMS) Wiley & Sons, ISBN-10: 0470516623 ISBN-13: 978-0470516621 3rd Edition, Nov. 2008 The red book: M.Poikselka, G.Mayer, H. Khartabil: The IMS - IP Multimedia Concepts and Services Wiley & Sons, ISBN-10: 0470721960 ISBN-13: 978-0470721964 3rd Edition, March 2009

Author: Dipl.-Ing. Franz Edler

page: 25 / 25