ims part5 ims session control

Upload: franz-edler

Post on 08-Aug-2018

284 views

Category:

Documents


2 download

TRANSCRIPT

  • 8/22/2019 IMS Part5 IMS Session Control

    1/25

    Study Program

    Master Telecommunications and Internet Technologies

    Course

    Application Prototyping

    LECTURE NOTE 5

    Version: 2.3

    Datum: 22. 03. 2008

    IP MULTIMEDIA

    SUBSYSTEM (IMS)Session Control

    Dipl.-Ing. Franz Edler

  • 8/22/2019 IMS Part5 IMS Session Control

    2/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 2 / 25

    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

  • 8/22/2019 IMS Part5 IMS Session Control

    3/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 3 / 25

    1. OVERVIEW1.1.CONTENT OF THE COURSEThe 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 willreplace 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 COURSEThe course actually comprises the following parts:

    1. IMS Overview and Standards2. Basic Technologies: SIP recap and new protocols and extensions3. IMS network architecture4. IMS Identities, Authentication and Registration5. Basic Session Control6. User Profile and Provision of Services7. Charging and Security Architecture8. Access networks and PCC9. Presence and Push-to-Talk10.PSTN Simulation and Emulation11.IP-TV

    1.3.PRECONDITIONS AND FURTHER READINGS AND EXERCISESThe 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

    1TDM = Time Division Multiplex

    2SIP = Session Initiation Protocol, RFC 3261

    3I strongly recommend the Tech-Invite portal http://www.tech-invite.com/

    4Open IMS Core project of Fraunhofer Fokus http://www.openimscore.org/

  • 8/22/2019 IMS Part5 IMS Session Control

    4/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 4 / 25

    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 over-

    come 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 EXERCISESAt 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 AUDIENCEThe 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.

  • 8/22/2019 IMS Part5 IMS Session Control

    5/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 5 / 25

    2.BASIC SESSION SETUPThe 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.

    IMSTerminal

    of Alice P-CSCF I-CSCF HSSS-CSCF

    (1) INVITE(2) 100

    Trying

    S-CSCF P-CSCF

    (3) INVITE

    Evaluation of initial

    filter criteria

    (5) INVITE

    (2) 100

    Trying

    (6) 100

    Trying(7) Diameter

    LIR

    (8) Diameter

    LIA

    (9) INVITE(10) 100Trying

    Evaluation of initial

    filter criteria

    (11) INVITE

    (12) 100Trying

    (13 INVITE

    (15) 183Session

    Progress

    (14) 100Trying

    (16) 183

    SessionProgress(17) 183

    Session Progress(18) 183

    Session

    Progress

    (19) 183

    SessionProgress

    (20) 183

    Session

    Progress

    Pre-

    Alert

    Resource

    Reservation

    IMSTerminal

    of Bob

    Originating

    Visited

    Network

    Originating

    Home

    Network

    Terminating Home NetworkTerminating

    Visited

    Network

    Figure 1: Basic session setup - part 1

  • 8/22/2019 IMS Part5 IMS Session Control

    6/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 6 / 25

    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 isnecessary 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 sessionparticipants: 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 thaton 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 signallingmessages. 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 REQUESTThe IMS terminal of Alice creates an INVITE request (1) as shown in Figure 2. The Request-

    URI 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.

    5See also TS 23.218: IM call model Stage 2

  • 8/22/2019 IMS Part5 IMS Session Control

    7/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 7 / 25

    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:[email protected] SIP/2.0

    Via: SIP/2.0/UDP [1080::8:800:200C:417A]:5059;

    comp=sigcomp;branch=z9hG4bK9h9ab

    Max-Forwards: 70

    Route: ,

    P-Preferred-Identity: "Alice Smith"

    Privacy: none

    P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E

    From: ;tag=ty20s

    To:

    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:

    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 99b=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 sendrecva=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

  • 8/22/2019 IMS Part5 IMS Session Control

    8/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 8 / 25

    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 channelestablished during the IMS registration.

    2.2.THE ORIGINATING P-CSCF PROCESSES THE INVITE REQUESTThe 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 iteither rejects the request or corrects the Route header.

    It checks the P-Preferred-Identity header field. If it matches one of the associated Public UserIdentities 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 accessnetwork 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 Service-

    Route 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.

  • 8/22/2019 IMS Part5 IMS Session Control

    9/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 9 / 25

    INVITE sip:[email protected] 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:

    Record-Route:

    P-Asserted-Identity: "Alice Smith"

    Privacy: none

    P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=C359A3913B20E

    P-Charging-Vector: icid-value="W34h6dlg"

    From: ;tag=ty20s

    To:

    Call-ID: 3sO9csO3

    Cseq: 127 INVITE

    Require: precondition

    Supported: l00rel

    Contact:

    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

  • 8/22/2019 IMS Part5 IMS Session Control

    10/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 10 / 25

    2.3.THE ORIGINATING S-CSCF PROCESSES THE INVITE REQUESTThe S-CSCF receives the INVITE request. The Route header field (derived from the Service-

    Route 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 ofthe 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 moreApplication 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 3263

    9applies 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 terminatinghome 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 REQUESTWhen 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

    6It 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 Servers10

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

  • 8/22/2019 IMS Part5 IMS Session Control

    11/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 11 / 25

    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 whichcontains 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 REQUESTThe 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-CSCFpreviously 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 REQUESTThe 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-Called-Party-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-Asserted-

    Identity header field later on in responses.

    11From 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.

  • 8/22/2019 IMS Part5 IMS Session Control

    12/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 12 / 25

    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 IMSterminal 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 REQUESTThe 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 SessionProgress response with the following data:

    The IMS terminal inserts a P-Access-Network-Info header field which might be used in theterminating home network to apply specific services.

    The IMS terminal inserts a Require header field with the value 100rel because theprecondition extension requires a reliable transmission of responses.

    The IMS terminal inserts also the SDP to be used on the terminating side with all parametersto control preconditions.

    The IMS terminal inserts a Privacy header field with the valued id in case privacy ofidentity 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 calleroptionally 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 IMSterminal 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 channeland 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.

  • 8/22/2019 IMS Part5 IMS Session Control

    13/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 13 / 25

    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:

    Record-Route:

    Record-Route:

    Record-Route:

    P-Asserted-Identity: "Alice Smith"

  • 8/22/2019 IMS Part5 IMS Session Control

    14/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 14 / 25

    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=z9hG4bKoh2qrzVia: SIP/2.O/UDP [1080::8:800:200C:417A]:5059;comp=sigcomp;

    branch=z9hG4bK9h9ab

    Record-Route: ,

    ,,

    Privacy: none

    P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E

    From: ;tag=ty20s

    To: ;tag=d92119

    Call-ID: 3sO9csO3

    Cseq: 127 INVITE

    Require: l00rel

    Contact: 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 nonea=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 sendrecva=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

  • 8/22/2019 IMS Part5 IMS Session Control

    15/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 15 / 25

    2.8.PROCESSING OF THE 183SESSION PROGRESS RESPONSEThe 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-Routeheader 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-Media-

    Authorization 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 shownin Figure 1.

  • 8/22/2019 IMS Part5 IMS Session Control

    16/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 16 / 25

    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.

    ResourceReservation

    ResourceReservatio

    n

    Figure 6: Basic session setup part 2

    2.9.THE CALLERS IMS TERMINAL PROCESSES THE 183 RESPONSEThe 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.

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

  • 8/22/2019 IMS Part5 IMS Session Control

    17/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 17 / 25

    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: ,

    ,,

    From: ;tag=ty20s

    To: ;tag=d92119

    Call-ID: 3sO9csO3Cseq: 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:417At-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 nonea=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

  • 8/22/2019 IMS Part5 IMS Session Control

    18/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 18 / 25

    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 REQUESTThe 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=C359A3913B20EFrom: ;tag=ty20s

    To: ;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

  • 8/22/2019 IMS Part5 IMS Session Control

    19/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 19 / 25

    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 UPDATErequest 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 RESERVATIONWhen 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 ofresource 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.

  • 8/22/2019 IMS Part5 IMS Session Control

    20/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 20 / 25

    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: ,

    ,,

    From: ;tag=ty20s

    To: ;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

  • 8/22/2019 IMS Part5 IMS Session Control

    21/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 21 / 25

    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: ;tag=ty20s

    To: ;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 SETUPThe 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 thecaller. 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).

  • 8/22/2019 IMS Part5 IMS Session Control

    22/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 22 / 25

    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.

  • 8/22/2019 IMS Part5 IMS Session Control

    23/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 23 / 25

    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: ,

    ,,

    P-Access-Network-Info: 3GPP-UTRAN-TDD;utran-cell-id-3gpp=C359A3913B20E

    From: ;tag=ty20s

    To: ;tag=d92119

    Call-ID: 3sO9csO3

    Cseq: 127 INVITE

    Require: l00rel

    Contact:

    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: ,

    ,,

    From: ;tag=ty20s

    To: ;tag=d92119

    Call-ID: 3sO9csO3

    Cseq: 127 ACK

    Content-Length: 0

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

  • 8/22/2019 IMS Part5 IMS Session Control

    24/25

    Part 5: Session Control

    Author: Dipl.-Ing. Franz Edler page: 24 / 25

    3.EXERCISES AND QUESTIONSAfter 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 thesignalling 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?

  • 8/22/2019 IMS Part5 IMS Session Control

    25/25

    Part 5: Session Control

    4.REFERENCES4.1.BOOKS ON SESSION INITIATION PROTOCOLHenry 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 IPMULTIMEDIA SUBSYSTEMThe 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