Beruflich Dokumente
Kultur Dokumente
LECTURE NOTE 5
Version: Datum: 2.3 22. 03. 2008
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
page: 2 / 25
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.
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/
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.
page: 4 / 25
P-CSCF
S-CSCF
I-CSCF
HSS
S-CSCF
P-CSCF
(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
Resource Reservation
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.
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
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.
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.
page: 8 / 25
page: 9 / 25
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.
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.
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.
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.
page: 12 / 25
Figure 4: (13) INVITE request received by the IMS terminal of the callee Author: Dipl.-Ing. Franz Edler page: 13 / 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=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
page: 14 / 25
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
The list of codecs received is the intersection of the codecs supported by both terminals.
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
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.
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.
page: 19 / 25
Figure 9: (31) UPDATE request sent by the IMS terminal of the caller
page: 20 / 25
page: 21 / 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.
page: 22 / 25
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
page: 23 / 25
page: 24 / 25
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
page: 25 / 25