training ims sip

IMS_SIP_NSN0910 -

Special Training

INACON GmbH Kriegsstrasse 154 76133 Karlsruhe

Germany www.inacon.com

e-mail: [email protected]

Licensed to Srihari Avula, Nokia Siemens Networks. No further distribution allowed.

Cover design by Stefan Kohler © 1999 - 2010 INACON GmbH Kriegsstrasse 154 76133 Karlsruhe All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this publication, the publisher and authors assume no responsibility for errors or omissions. Neither is any liability assumed for damages resulting from the use of the information contained herein. For more information, contact INACON GmbH at www.inacon.com.


Legend: All INACON publications use the same color codes to distinguish mandatory from optional or conditional parts in frame formats or optional from mandatory data blocks or signaling messages in scenarios. The different color codes are explained underneath:

• Color Codes in Frame Formats:

• Color Codes in Scenarios:

Signaling Message

(mandatory)

Signaling Message

(optional)

Data

(mandatory)

Data

(optional)


k Foreword of the Publisher: Dear Reader: Note that this book is primarily a training document because the primary business of INACON GmbH is the training and consulting market for mobile communications. As such, we are proud to providing high-end training courses to many clients worldwide, among them operators like AT&T Wireless, INMARSAT or T-MOBILE and equipment suppliers like ERICSSON, MOTOROLA, NOKIA or SIEMENS. INACON GmbH is not one of the old-fashioned publishers. With respect to time-to-market, form-factor, homogenous quality over all books and most importantly with respect to after-sales support, INACON GmbH is moving into a new direction. Therefore, INACON GmbH does not leave you alone with your issues and this book but we offer you to contact the author directly through e-mail ([email protected]), if you have any questions. All our authors are employees of INACON GmbH and all of them are proven experts in their area with usually many years of practical experience. The most important assets and features of the book in front of you are:

• Extreme degree of detailed information about a certain technology. • Extensive and detailed index to allow instant access to information about

virtually every parameter, timer and detail of this technology. • Incorporation of several practical exercises. • If applicable, incorporation of examples from our practical field

experiences and real life recordings. • References to the respective standards and recommendations on virtually

every page. Finally, we again like to congratulate you to the purchase of this book and we like to wish you success in using it during your daily work. Sincerely,

Gunnar Heine / President & CEO of INACON GmbH

PS: Please check for our UMTS online encyclopaedia at www.inacon.com.


SIP, SDP and other NGN Protocols – Signaling & Protocol Analysis

© INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or unauthorized use of this material is prohibited and will be prosecuted to the full extent of German and international laws. Version Number: 2.100

K

Table of Contents

Introducing the Playground of SIP / Reviewing SIP and SDP Basics......................................................1

What are the driving Forces behind the NGN-Hype? .........................................5 Easy Offering of Multimedia Services becomes possible ...............................................5 Data and Voice Network Convergence...........................................................................5 Mobile and Fixed Network Convergence ........................................................................5 Service Convergence / Offering of Triple-Play Services .................................................5

Next Generation Networks and their Components.............................................7 Typical Configuration and Interconnection of Next Generation Networks.......................7

Network Type 1: Evolved ISP ..................................................................................................7 Network Type 2: Former Telecom-Operator ............................................................................7 Network Type 3: 3GPP Mobile Network Operator ...................................................................7 Network Type 4: WIMAX Network Operator ............................................................................7

Limitations of the Release 99 Network & Software Architecture ......................9 Which new services become realistic with Rel. 99?........................................................9 How do the narrow-band MSC’s handle broadband service requests? ..........................9 How can the user gain access to these new services?...................................................9

The New Circuit-Switched CN Architecture with Release 4.............................11 Introduction of MSC-Servers (MSC-S)..........................................................................11 Introduction of Media Gateways (MGW).......................................................................11 Introduction of New Interfaces Mc, Nb and Nc..............................................................11 Introduction of New Protocols BICC, H.248 (MEGACO) and Nb-FP ............................11

Access and Core Network Architecture with Release 4 ..................................13 Important Architectural Changes with Release 5 .............................................15

IP-Multimedia Subsystem (IMS)....................................................................................15 Home Subscriber Server (HSS) ....................................................................................15 New Gm-Interface.........................................................................................................15 GERAN Core Network Connection as Iu-Interface ..................................................15 Iub-, Iu-cs- and Iur-Interface alternatively IP-based......................................................15

New Features with Release 5 .............................................................................17 Fixed Mobile Convergence.................................................................................19

The User Domain ...................................................................................................................19 The Device Domain................................................................................................................19 The Access Domain ...............................................................................................................19 The Service Domain...............................................................................................................19

OSA (Open Service Access).........................................................................................21 What is OSA?.........................................................................................................................21 How does OSA work?............................................................................................................21

Multimedia Call Control .................................................................................................23 SIP (Session Initiation Protocol) ............................................................................................23 H.324M...................................................................................................................................23 H.323......................................................................................................................................23

Why is an Architecture Evolution necessary?..................................................25




Integration of E-UTRAN with its new Concepts .....................................................................25 Integration of Non-3GPP RAT's is sub-optimum in Rel. 7 because ... ..................................27 Therefore, legacy operators of Non-3GPP-RAT's cannot adopt the existing 3GPP-CN-Architecture ............................................................................................................................29

Release 8 / 9 Architecture Overview..................................................................31 Zoom into the EPS ..............................................................................................33

The eNB........................................................................................................................35 Mobility Management Entity (MME) ..............................................................................39 Mobility Management Entity – Interfaces & Protocols...................................................41 Mobility Management Entity – Tasks & Functions ........................................................43

S1-Signaling towards the eNodeB.........................................................................................43 S-GW and P-GW Selection...........................................................................................45

Other Selection Functions......................................................................................................45 E-UTRAN Organization and Identifiers .........................................................................47

Tracking Areas .......................................................................................................................47 TAI and TAI-list ......................................................................................................................47 E-UTRAN Pool Areas.............................................................................................................47 MME Pool's and MMEI...........................................................................................................47

UE Identifiers – M-TMSI and S-TMSI............................................................................49 UE Identifiers – GUTI ....................................................................................................51 The Serving Gateway (S-GW) ......................................................................................53 S-GW – Interfaces & Protocols .....................................................................................55

Tasks & Functions..................................................................................................................55 The PDN Gateway (P-GW)...........................................................................................57 P-GW – Interfaces & Protocols .....................................................................................59

Tasks & Functions..................................................................................................................59 Enhanced Packet Data Gateway (ePDG) – Interfaces & Protocols..............................61

Tasks & Functions..................................................................................................................61 Distinction Trusted vs. Non-Trusted Non-3GPP RAT's....................................63

Distinction Trusted vs. Non-Trusted Non-3GPP RAT's.................................................65 e-UTRAN – eHRPD Roaming Architecture...................................................................67 … and the Protocol Stack with HRPD RAT...................................................................69

Security Architecture – Overview & Introduction.............................................71 Security Architecture – Overview & Introduction...........................................................73 The Authentication Quintuplet of UMTS- and IMS-AKA................................................75

AK...........................................................................................................................................75 AMF........................................................................................................................................75 AUTN......................................................................................................................................75 CK ..........................................................................................................................................75 IK ............................................................................................................................................75 RAND .....................................................................................................................................75 XRES......................................................................................................................................75 MAC .......................................................................................................................................75

Key Derivation Function (KDF) for K(ASME) – Rel.8....................................................77 EPS-AKA during Initial Attach Procedure .....................................................................79 The Use of EAP-AKA' Authenticaton for eHRPD..........................................................85

IPv6 Protocol Elements Inherited from IPv4 .....................................................89 The IPv6 Protocol Format .............................................................................................91 The IPv6 Address Types...............................................................................................93 IPv6 Address Notation ..................................................................................................94 IPv6 Address Notation ..................................................................................................95 IPv6 Address Configuration Options.............................................................................97

High Level View at the IMS and its Environment..............................................99




Mobility Issues ..............................................................................................................99 Relationship to other Networks .....................................................................................99 User Terminals..............................................................................................................99 What is the IMS?.........................................................................................................101

Involved Standards Organizations ..................................................................103 3GPP ..........................................................................................................................103 3GPP2 ........................................................................................................................103 TISPAN .......................................................................................................................103 CableLabs...................................................................................................................103 DSL-Forum .................................................................................................................103

The 3GPP-Version of the IMS...........................................................................105 Introduction .................................................................................................................105 Architectural Overview (Network Perspective)............................................................107 And what is inside the IMS?........................................................................................109 The Perspective of the 3GPP-User Agent ( Mobile Station) ...................................111

Overview of the other IMS-Approaches ..........................................................113 TISPAN .......................................................................................................................113 Some Remarks on the TISPAN NGN-Solution ...........................................................115 3GPP2 ........................................................................................................................117 Some Remarks on the 3GPP2 IMS-Solution ..............................................................119 Cable Labs..................................................................................................................121 DSL-Forum .................................................................................................................123 Performance Figures of the Different IP-CAN’s ..........................................................125

UTRAN................................................................................................................................ 125 GERAN ............................................................................................................................... 125 WLAN / WiFI ....................................................................................................................... 125 WIMAX ................................................................................................................................ 125 cdma2000 ........................................................................................................................... 125 CableTV .............................................................................................................................. 125 xDSL.................................................................................................................................... 125

(1) Summary & Conclusions.............................................................................127 Chances of the Different Players ................................................................................127

Telecom Operator ............................................................................................................... 127 Mobile Telecom Operator ................................................................................................... 127 CableTV Operator ............................................................................................................... 127 ISP....................................................................................................................................... 127

(2) Summary & Conclusions.............................................................................129 Wireless vs. Wireline Technologies ............................................................................129 Cell Performance vs. User Performance.....................................................................129 Conclusion: “Bandwidth” and “Access to the Customer” is all that matters ................129

The Service Perspective of the IMS .................................................................131 Service Types and Service Enablers ..........................................................................131

Conversational Services...................................................................................133 Two-Party Audio Calls.................................................................................................133 Multiparty Audio Calls .................................................................................................133 Call-Related Supplementary Services ........................................................................133 Multimedia Calls..........................................................................................................133 Non-Real Time Messaging..........................................................................................133 Instant Messaging.......................................................................................................133 Chat Rooms ................................................................................................................133

Audiovisual Entertainment Services ...............................................................135




TV Broadcast ..............................................................................................................135 Radio Broadcast .........................................................................................................135 Video on Demand (VoD) .............................................................................................135 Audio on Demand (AoD) .............................................................................................135 Gaming .......................................................................................................................135

Service Enablers ...............................................................................................137 Fixed Mobile Convergence (FMC) ..............................................................................137 Presence.....................................................................................................................137

Triple Play and Quadruple Play........................................................................139 Initial Situation.............................................................................................................139

Cable-TV Operators ............................................................................................................ 139 Telecom Operators ............................................................................................................. 139 Internet Service Provider..................................................................................................... 139

Triple Play ...................................................................................................................141 Quadruple Play ...........................................................................................................143

Conclusions.......................................................................................................145 sInter IP-CAN Roaming (Practical Exercise)...............................................................146 Inter IP-CAN Roaming (Practical Exercise) ................................................................147

Description of the IMS-Network Architecture .................................................149 Overview .....................................................................................................................149 Detailed View ..............................................................................................................151

P-CSCF (Proxy Call Session Control Function)..............................................153 Tasks & Functions ......................................................................................................153 Typical Use Cases ......................................................................................................157

P-CSCF Involvement during Registration........................................................................... 159 P-CSCF Involvement for Session Setup and Policing ........................................................ 161 Step 1: Session Start .......................................................................................................... 161 Step 2: Media Tunnel Establishment .................................................................................. 163 Step 3: Media Tunnel Established ...................................................................................... 165 Step 4: Preconditions fulfilled / Confirmation on SIP-Layer ................................................ 167

Example: Resource Reservation if IP-CAN = GERAN/UTRAN ..................................169 Selection of 3GPP-specific QoS-Parameters ..................................................................... 169 Activation of QoS-aware Media Tunnel .............................................................................. 169

… and the change with LTE / SAE .............................................................................171 P-CSCF Involvement during Ungraceful Session Release................................................. 175 P-CSCF Interworking with the TrGw................................................................................... 177

Facts Sheet.................................................................................................................179 Characteristics .................................................................................................................... 179 Interfaces to other Network Elements................................................................................. 179 Protocol Stacks of the P-CSCF........................................................................................... 179

I-CSCF (Interrogating Call Session Control Function) ...................................181 Tasks & Functions ......................................................................................................181 Typical Use Cases ......................................................................................................185

I-CSCF Involvement during UA Registration ( Initial UE-Authorization and S-CSCF Assignment) ........................................................................................................................ 185 I-CSCF Involvement during IMS-Incoming Transactions.................................................... 187 Topology Hiding through the I-CSCF.................................................................................. 189 Tokenization........................................................................................................................ 189 Header Field Alteration ....................................................................................................... 189 TrGw-Interworking and Operation as IMS-ALG (with NAT)................................................ 191

Facts Sheet.................................................................................................................193 Characteristics .................................................................................................................... 193 Interfaces to other Network Elements................................................................................. 193




Protocol Stacks of the I-CSCF ............................................................................................ 193 S-CSCF (Serving Call Session Control Function) ..........................................195

Tasks & Functions ......................................................................................................195 Typical Use Cases of the S-CSCF..............................................................................197

Involvement during IMS-Originating Transactions.............................................................. 197 Involvement during IMS-Terminating Session .................................................................... 199

Facts Sheet.................................................................................................................201 Characteristics .................................................................................................................... 201 Interfaces to other Network Elements................................................................................. 201 Protocol Stacks of the S-CSCF........................................................................................... 201

BGCF (Breakout Gateway Control Function)..................................................203 Tasks & Functions ......................................................................................................203 Use Case of the BGCF ...............................................................................................205 Facts Sheet.................................................................................................................207

Characteristics .................................................................................................................... 207 Interfaces to other Network Elements................................................................................. 207 Protocol Stacks of the BGCF .............................................................................................. 207

MGCF (Media Gateway Control Function) / MGW (IMS-MGW).......................209 Tasks & Functions ......................................................................................................209 Typical Use Cases of the MGCF and the IMS-MGW..................................................211

Involvement during IMS-MOC towards PSTN or CS-Domain (Mobile Originating Call) .... 211 Involvement during IMS-MTC from PSTN or CS-Domain .................................................. 213

Facts Sheet MGCF .....................................................................................................215 Characteristics .................................................................................................................... 215 Interfaces to other Network Elements................................................................................. 215 Protocol Stacks of the MGCF ............................................................................................. 215

Facts Sheet IMS-MGW (IMS-Media Gateway) ...........................................................217 Characteristics .................................................................................................................... 217 Interfaces to other Network Elements................................................................................. 217 Protocol Stacks of the IMS-MGW ....................................................................................... 217

MRF (Multimedia Resource Function) .............................................................219 Tasks & Functions ......................................................................................................219 Typical Use Cases of the MRF (MRFC and MRFP) ...................................................221

Involvement during chat-room based instant messaging ................................................... 221 Announcement Playing ....................................................................................................... 223

Facts Sheet MRFC (Multimedia Resource Function Controller) .................................225 Characteristics .................................................................................................................... 225 Interfaces to other Network Elements................................................................................. 225 Protocol Stacks of the MRFC.............................................................................................. 225

Facts Sheet MRFP (Multimedia Resource Function Processor).................................227 Characteristics .................................................................................................................... 227 Interfaces to other Network Elements................................................................................. 227 Protocol Stacks of the MRFP.............................................................................................. 227

And where are SIP, SDP and all the other Protocols used?..........................231 SIP Use within NGN....................................................................................................231

DIA (DIAMETER)) ............................................................................................................... 231 H.248 / MEGACO .......................................................................................................231 RTP / SRTP (Real-time Transport Protocol / Secure Real-time Transport Protocol)..231

Protocols within the IMS-Control Plane ..........................................................233 SIP and SDP ....................................................................................................................... 233 DIA (DIAMETER)) ............................................................................................................... 233 COPS .................................................................................................................................. 233 H.248 / MEGACO................................................................................................................ 233 BFCP / TBCP ...................................................................................................................... 233




IP, IPsec and TLS ............................................................................................................... 233 Protocols within the IMS-User Plane...........................................................................235

RTP / RTSP / SRTP............................................................................................................ 235 MSRP.................................................................................................................................. 235 Resource Allocation Protocols ............................................................................................ 235 QoS-Control Protocols ........................................................................................................ 235

Some details of the DIAMETER Protocol....................................................................236 Some details of the DIAMETER Protocol....................................................................237 DIAMETER Overview..................................................................................................239 IMS-specific Amendments to DIAMETER Protocol.....................................................240 IMS-specific Amendments to DIAMETER Protocol.....................................................241 Selected Diameter Commands used by IMS ..............................................................243 RTP / RTCP ................................................................................................................245

The Real Time Transport Protocol (RTP and RTCP) ......................................247 Operation of RTP and RTCP ......................................................................................247 (1) Format of the RTP-Header ....................................................................................249

Version ................................................................................................................................ 249 P-Bit (Padding).................................................................................................................... 249 Ext-Bit (Header Extension) ................................................................................................. 249 CSRC-Count ....................................................................................................................... 249 M-Bit (Marker) ..................................................................................................................... 249 Payload Type ...................................................................................................................... 251 Sequence Number .............................................................................................................. 251 Timestamp .......................................................................................................................... 253 Synchronization Source (SSRC)......................................................................................... 253 Contributing Source (CSRC)............................................................................................... 253

Example of an RTP-Frame .........................................................................................255 Tasks and Functions of RTCP ....................................................................................257

Quality Report Transfer....................................................................................................... 257 Session Control................................................................................................................... 257 CNAME SSRC Binding .................................................................................................. 257

Example of an RTCP-Frame (Sender Report) ............................................................259 The H.248- / MEGACO-Protocol .......................................................................261

Introduction .................................................................................................................261 Principles of Media Gateway Operation......................................................................261 Contexts and Terminations .........................................................................................263

Terminations ....................................................................................................................... 263 Contexts .............................................................................................................................. 263

The H.248 Command Set ...........................................................................................265 Example of Media Gateway Operation through H.248 ...................................267 IPsec...................................................................................................................269

IPsec in Transport Mode.............................................................................................269 Transport Mode and AH...................................................................................................... 269 Transport Mode and ESP ................................................................................................... 269

IPsec in Tunnel Mode .................................................................................................271 Tunnel Mode and AH .......................................................................................................... 271 Tunnel Mode and ESP........................................................................................................ 271

VPN with IPsec in Tunnel Mode and Transport Mode ................................................273 VPN with IPsec in Tunnel Mode ......................................................................................... 273 VPN with IPsec in Transport Mode ..................................................................................... 273

The IPsec Authentication Header (AH)............................................................275 Next Header (8 bit)......................................................................................................275 Payload Length (8 bit) .................................................................................................275 Reserved (16 bit) ........................................................................................................275




Security Parameters Index (SPI) (32 bit) ....................................................................275 Sequence Number (32 bit) ..........................................................................................275 Authentication Data (n bit) ..........................................................................................275

The IPsec Encapsulating Security Payload (ESP)..........................................277 Security Parameters Index (SPI) (32 bit) ....................................................................277 Sequence Number (32 bit) ..........................................................................................277 Payload Data (n bit) ....................................................................................................277 Padding (0 – 255 octets) .............................................................................................277 Padding Length (8 bit).................................................................................................277 Next Header (8 bit)......................................................................................................277 ESP Authentication Data (n bit) ..................................................................................277

The Security Association (SA) .........................................................................279 SIP – Protocol Structure ...................................................................................281

Sublayers within SIP ...................................................................................................281 Transport Layer Control ...................................................................................................... 281 Transaction Handling (UAC and UAS)................................................................................ 281 Transaction User / Core...................................................................................................... 281

SIP-Network Architecture .................................................................................283 Overview .....................................................................................................................283 User Agents ................................................................................................................285

Dedicated VoIP-Phones...................................................................................................... 285 Mobile Stations.................................................................................................................... 285 Softphones .......................................................................................................................... 285 Game Boxes ....................................................................................................................... 285 Set Top Boxes..................................................................................................................... 285

SIP-Servers.................................................................................................................287 Stateless SIP-Proxy Server ................................................................................................ 287 Stateful SIP-Proxy Server ................................................................................................... 287 SBC (Session Border Controller), B2BUA (Back-to-Back User Agent) .............................. 287

Special SIP-Servers ....................................................................................................289 Registrar.............................................................................................................................. 289 Application Server ............................................................................................................... 289 Media Gateway Controller .................................................................................................. 289 Application Layer Gateway (ALG)....................................................................................... 289

Operation of Stateless SIP-Proxy Servers ..................................................................291 Advantages of Stateless SIP-Proxies ................................................................................. 291 Disadvantages of Stateless SIP-Proxies ............................................................................ 291 Other Assets of Stateless SIP-Proxies ............................................................................... 291

Operation of Stateful SIP-Proxy Servers.....................................................................293 Operation of Registrars...............................................................................................295 Operation of Redirect Servers.....................................................................................297

Introduction ......................................................................................................................... 297 Procedure Description......................................................................................................... 297

(1) Operation of Forking SIP-Proxy Servers (always stateful) ....................................299 Operation of B2BUA and SBC ....................................................................................303

Example: VoD-for a Mobile Client with limited Access Rates............................................. 305 Operation of Event Servers.........................................................................................307

Introduction ......................................................................................................................... 307 Event Subscription .............................................................................................................. 307 Event Publishing and Notification ....................................................................................... 307 The Presence Event............................................................................................................ 307

Soft Switches and their Controllers .............................................................................309 Summary.....................................................................................................................311 Why SIP is used and not H.323 or other Alternatives? ...............................................313




Scope of SIP ......................................................................................................315 Session Establishment................................................................................................315 Clarification of the Term “Session”..............................................................................315 Session Modification ...................................................................................................315 Session Release .........................................................................................................315 Philosophy of SIP-Operation.......................................................................................317

Session Establishment Phase ............................................................................................ 317 Session Completion Phase................................................................................................. 319 Session Active Phase ......................................................................................................... 321

Comparison between SIP and HTTP..........................................................................323 Simple Example of a SIP-Scenario: VoIP Call Setup with SIP.......................325

Overview .....................................................................................................................325 Summary: Some SIP-Terminology..............................................................................327

Message Types................................................................................................................... 327 SIP-Methods ....................................................................................................................... 327 Response Types ................................................................................................................. 327

Important SIP-Terminology / Step 1: Two UA’s …..........................................329 Transaction) ................................................................................................................329 Dialog / Call / Early Dialog (Definition) ........................................................................329 Session (Definition).....................................................................................................331 Dialog Identification (two Users / with or w/o Proxies) ................................................333 Session Identification and Distinction..........................................................................333 Transaction Identification (two UA’s / no Proxies).......................................................335

The Branch Parameter........................................................................................................ 335 Magic Cookie "z9hG4bK".................................................................................................... 335 Example .............................................................................................................................. 337 Sequence Numbering (CSeq)............................................................................................. 337

Relationship between SIP, the IMS and 3GPP-Networks...............................339 Generic SIP-Servers vs. IMS-specific SIP-Servers.....................................................341 The Mobile’s Way to SIP Registration and SIP-Sessions ...........................................343

Step 1: GPRS-Attachment .................................................................................................. 343 Step 2: Primary PDP-Context Activation Procedure / P-CSCF Discovery ......................... 343 Step 3: SIP-Registration ( REGISTER)........................................................................... 343 Step 4: SIP-Invitation ( INVITE) ...................................................................................... 343

IMS-related User Identities ...............................................................................345 Overview / the ISIM.....................................................................................................345 Private User Identity (IMPI) .........................................................................................345 Public User Identity (IMPU).........................................................................................345 Details of Private User Identities (IMPI) ......................................................................347 Details of Public User Identities (IMPU) ......................................................................349 Use of Private and Public User Identities in REGISTER-Msgs...................................350 Use of Private and Public User Identities in REGISTER-Msgs...................................351

Home Network Domain Name ............................................................................................ 351 Use of Private User Identity ................................................................................................ 351 Use of Public User Identity.................................................................................................. 351 Use of Temporary Public User Identity ............................................................................... 351

Registration to the IMS in 3GPP-Networks (Overview) ..................................353 Dependency between APN-Setting and P-CSCF-Selection .......................................353 Subscriber registers to IMS while located in H-PLMN ................................................355 Subscriber is Roaming................................................................................................357

Authentication in 3GPP-based IMS..................................................................359 Authenticating the Network towards the MS/UE .........................................................361 The “base64”-Encoding Process.................................................................................363




The IMS-AKA Authentication Process ........................................................................365 Application of IPsec between MS/UE and P-CSCF ....................................................367

(1) Registration to the IMS in 3GPP (Detailed Scenario) ................................369 Initial Conditions..........................................................................................................369 Applicability of this Procedure.....................................................................................369 Description ..................................................................................................................369 (1) Transaction Identification (two UA’s / with Proxies)...............................................377

Transaction Identification through “branch” is done Hop-by-Hop ....................................... 377 Transaction Numbering through “CSeq:” applies end-to-end............................................. 379

Transaction-specific Messaging..................................................................................383 Option 1: Request = INVITE / Transaction = successful .................................................... 383 Option 2: Request = INVITE / Transaction = unsuccessful ................................................ 385 Option 3: Request = INVITE / Transaction = cancelled ...................................................... 387 Option 4: Request = REGISTER......................................................................................... 389 Option 5: All Other Requests .............................................................................................. 391

Amendments in case of more than two Peers ................................................395 Introducing Different Contact Addresses per User......................................................395 Behavior of Forking Proxies........................................................................................395 The Terms Call, Dialog, Session and Transaction in case of Forking ........................395 (1) Message and Parameter Details ...........................................................................397 Summary.....................................................................................................................401

SIP-Message Format .........................................................................................403 General Information ....................................................................................................403 Request Messages .....................................................................................................403 Response Messages ..................................................................................................403

SIP-Message Contents......................................................................................405 The Request Line (Request Messages only) ..............................................................405 (1) The Different Method-Types..................................................................................407

REGISTER.......................................................................................................................... 407 INVITE................................................................................................................................. 407 ACK..................................................................................................................................... 407 CANCEL.............................................................................................................................. 407 BYE ..................................................................................................................................... 407 OPTIONS ............................................................................................................................ 407 INFO.................................................................................................................................... 407 MESSAGE .......................................................................................................................... 409 SUBSCRIBE ....................................................................................................................... 409 NOTIFY ............................................................................................................................... 409 PUBLISH............................................................................................................................. 409 PRACK................................................................................................................................ 409 REFER ................................................................................................................................ 409 UPDATE.............................................................................................................................. 409

Address Specification / Request-URI..........................................................................411 The “tel”-URI ....................................................................................................................... 411 The SIP(S)-URI ................................................................................................................... 413

The Status Line...........................................................................................................415 Status Code and Reason Phrase ....................................................................................... 415

The “From:” and the “To:” Header Fields ....................................................................417 Display-Name...................................................................................................................... 417 Tag ...................................................................................................................................... 417

The “Call-ID:” and “Max-Forwards:” Header Fields.....................................................419 Call-ID ................................................................................................................................. 419 Max-Forwards ..................................................................................................................... 419

The “CSeq:” Header Field ...........................................................................................421




The “Via:” Header Field...............................................................................................423 The “Contact:” Header Field .......................................................................................425

SIP-Timers..........................................................................................................427 Overview .....................................................................................................................427 INVITE Transaction (UAC-Side - Response: 200-OK)................................................429

Overview ............................................................................................................................. 429 Reception of Provisional Response .................................................................................... 429 Reception of Response: 200-OK ........................................................................................ 429 Timer 1, Timer A and Timer B in case of 3GPP-Networks ................................................. 429

INVITE Transaction (UAC-Side - Response: 3XX – 6XX) ..........................................431 Overview ............................................................................................................................. 431 Reception of Provisional Response .................................................................................... 431 Reception of Response: 3XX – 6XX................................................................................... 431

INVITE Transaction (UAC-Side - no Response received) ..........................................433 Overview ............................................................................................................................. 433 Expiry of Timer A................................................................................................................. 433 Expiry of Timer B................................................................................................................. 433

INVITE Transaction (UAS-Side sent 3XX – 6XX – wait for ACK) ...............................435 Overview ............................................................................................................................. 435 Expiry of Timer G ................................................................................................................ 435 Expiry of Timer H ................................................................................................................ 435 Timer 1, Timer 2, Timer G and Timer H in case of 3GPP-Networks .................................. 435

INVITE Transaction (UAS-Side sent 200-OK – wait for ACK) ....................................437 Overview ............................................................................................................................. 437 Expiry of UAS-Core Timer (T1)........................................................................................... 437 Expiry of 2.UAS-Core Timer (64 x T1) ................................................................................ 437 Timer 1 and Timer 2 in case of 3GPP-Networks ................................................................ 437

“None“-INVITE Transaction (UAC-Side - Response: 2XX – 6XX) ..............................439 Overview ............................................................................................................................. 439 Timer E and Timer F ........................................................................................................... 439 Timer K................................................................................................................................ 439 Timer 1, Timer E, Timer F and Timer K in case of 3GPP-Networks................................... 439

”None“-INVITE Transaction (UAC-Side - no Response).............................................441 Overview ............................................................................................................................. 441 Timer E................................................................................................................................ 441 Expiry of Timer F................................................................................................................. 441 Timer 1, Timer 2, Timer E and Timer F in case of 3GPP-Networks ................................... 441

“None“-INVITE Transaction (UAS-Side - final Response sent)...................................443 Overview ............................................................................................................................. 443 Timer J ................................................................................................................................ 443 Timer 1 and Timer J in case of 3GPP-Networks ................................................................ 443

The Session Description Protocol (SDP) ........................................................445 Structure of SDP-Parameters within a SIP-Message (Example) ................................445 Logfile Example: Session and Media Descriptors through SDP .................................447

Session Description Items................................................................................449 Overview .....................................................................................................................449 The “v=”-Line (Version) ...............................................................................................449 The “s=”-Line (Session Name)....................................................................................449 The “o=”-Line (Origin) .................................................................................................451

Username............................................................................................................................ 451 Session-ID........................................................................................................................... 451 Session-Description-Version............................................................................................... 451 Network-type ....................................................................................................................... 451 Address-type ....................................................................................................................... 451 Address ............................................................................................................................... 451




The “c=”-Line (Connection Info) ..................................................................................453 The Meaning of SDP...................................................................................................455

Time Description Items.....................................................................................457 Overview .....................................................................................................................457 The “t=”-Line (Time) ....................................................................................................457

Media Description Items ...................................................................................459 Overview .....................................................................................................................459 Presence of Attributes.................................................................................................459 The “m”-Line (Media Announcement) .........................................................................461

Media Type (MIME)............................................................................................................. 461 Port-Number........................................................................................................................ 461 Transport............................................................................................................................. 461 Payload-Type-List ............................................................................................................... 461

“m”-line Media Type Attribute (MIME) / some Examples ............................................463 Media Type = application / Subtype = pdf........................................................................... 463 Media Type = message / Subtype = CPIM ......................................................................... 465

(1) “m”-line / Details of the Transport Protocol Types .................................................467 RTP/AVP............................................................................................................................. 467 RTP/AVPF........................................................................................................................... 467 RTP/SAVP .......................................................................................................................... 467 TBCP (Talk Burst Control Protocol) .................................................................................... 469 TCP (Transmission Control Protocol) ................................................................................. 469 TCP/BFCP (TCP / Binary Floor Control Protocol) .............................................................. 469 TCP/MSRP (Message Session Relay Protocol) ................................................................. 471 TCP/RTP/AVPF .................................................................................................................. 471 TCP/TLS/BFCP (Transport Layer Security / Binary Floor Control Protocol) ...................... 471 TCP/TLS/MSRP (Transport Layer Security / Message Session Relay Protocol)............... 473 UDP (User Datagram Protocol) .......................................................................................... 473 UDPTL (UDP Transport Layer)........................................................................................... 473

Use Case Example: Floor Control during Push-to-Talk (BFCP) .................................475 Configuration of the Participants and the Floor Control Server .......................................... 475 BFCP-Operation during a Conference Session.................................................................. 477

The “b”-Line (Bandwidth Information) .........................................................................479 CT (Conference Total) ........................................................................................................ 479 AS (Application Specific)..................................................................................................... 479 TIAS (Transport Independent Application Specific)............................................................ 479 RR (Rtcp bandwidth for data Receiver) and RS (Rtcp bandwidth for data Sender)........... 479 Details of the Bandwidth Modifiers “RR” and RS”............................................................... 481

“a”-Lines (Attributes) ...................................................................................................483 Example 1: Attribute “recvonly / sendonly” ......................................................................... 483 Example 2: AMR-Codec Definition and Parameterization .................................................. 485 Example 3: TCP-Connection Definition .............................................................................. 487

The Offer / Answer Model .................................................................................489 Session Identification Parameters at both Peers ........................................................491

Question 2: What happens if Provisional Responses get lost?....................493 Provisional Response Messages are those with Status Code 100 – 199...................493 Solution: Provide for the Option to acknowledge provisional Responses ...................495 Indicating Support or Requirement of acknowledged provisional Responses ............495 Indicating Lacking Support for a Required Feature.....................................................497 Using PRACK to acknowledge Provisional Responses..............................................499 Transaction Abort in Case of Lacking PRACK............................................................501 Summary.....................................................................................................................503

Question 3: How to assure appropriate Resource Allocation in both Ways before alerting the Called Party? .....................................................................505




Consequences of this Lack of Sophistication..............................................................505 Call Drop (No common Codec)........................................................................................... 505

Answer: We define an additional Handshaking Procedure .........................................507 Overview: Resource Management using SIP and SDP..............................................509

Positive Outcome – Resource Reservation successful ...................................................... 509 Negative Outcome – Preconditions cannot be met ............................................................ 511 Option 1: Related SDP was contained in a SIP-Request (INVITE / UPDATE) .................. 511 (1) Option 2: Related SDP was contained in a SIP-Response........................................... 513 One Media Stream is rejected altogether ........................................................................... 517

Handling the Precondition Attributes “a = curr:” and “a = des:”..................519 Overview .....................................................................................................................519 The new Option Tag “precondition”.............................................................................521 The “m = …” Line / Port Number and Payload Type...................................................523 Interpretation of “local” and “remote” Direction-Tags ..................................................525 Interpretation of the “current-status” Attribute (“a = curr:”) ..........................................527 The “desired-status” and “confirm-status” Attributes...................................................529 Preconditions fulfilled: the final Status ........................................................................531 Example 1: Resource Reservation if IP-CAN = GERAN/UTRAN ...............................533

Selection of 3GPP-specific QoS-Parameters ..................................................................... 533 Activation of QoS-aware Media Tunnel .............................................................................. 533

Example 2: Resource Reservation if IP-CAN = WIMAX .............................................535 Selection of WIMAX / 802.16-specific QoS-Parameters..................................................... 535 Activation of QoS-aware Media Tunnel .............................................................................. 535

Example 3: Resource Reservation if IP-CAN = IntServ-aware ...................................537 Selection of IntServ-specific QoS-Parameters ................................................................... 537 Activation of QoS-aware Media Tunnel .............................................................................. 537

Example 4: Unsuccessful Outcome ............................................................................539 Summary.....................................................................................................................541

Question 4: Are there any Means for Secondary Call Treatment..................545 Answer: Yes, there are means for...............................................................................545 User Busy ...................................................................................................................545 Call Forwarding Unconditional ....................................................................................545 User not Responding ..................................................................................................545 The “Do not Disturb” Feature ......................................................................................545 The “Find Me” Feature ................................................................................................545 (1) User Busy and “Do not Disturb” Feature – Detailed Message Sequence Chart....547 (1) “Call Forwarding Unconditional” / “User not Registered” – Detailed Message Sequence Chart ..........................................................................................................553 (1) User not Responding – Detailed Message Sequence Chart .................................559 (1) Find me / Follow me – Detailed Message Sequence Chart...................................569

Tackling NAT-Issues within the IMS ................................................................585 Introducing NAT and NAPT ........................................................................................585 Liabilities of NAT / NAPT.............................................................................................587 Network Configuration (UA behind two NAT’s) ...........................................................589 Step 1: Registration behind two NAT’s .......................................................................591

SIP: REGISTER-Messages ................................................................................................ 591 SIP: 200-OK Response Message ....................................................................................... 593 X-CSCF- and NAPT-Associations after Registration.......................................................... 595

Step 2: UA Originating Session Establishment behind 2 NAT’s .................................597 Problem Description............................................................................................................ 597 SIP: INVITE-Message......................................................................................................... 599 SIP: 183-Session Progress Response Message................................................................ 601 Audio Data Flow through the NAT’s – UE Originating ........................................................ 603 Audio Data Flow through the NAT’s– UE Terminating ....................................................... 605




IMS and IP-CAN use NAT / How many TrGw’s are required? (Practical Exercise)....607

Responses to the Question Sections................619

List of Acronyms v2.2 .........................................628

Index: ....................................................................655


IMS_SIP_NSN0910 Special Course

© INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or unauthorized use of this material is prohibited and will be prosecuted to the full extent of German and international laws. Version Number: 2.100 - 0 -

Intentionally left blank




Introducing the Playground of SIP / Reviewing SIP and SDP Basics

Detailed Consideration of Formal SIP-Protocol Aspects

Detailed Consideration of Formal SDP-Protocol Aspects

Advanced Use of SIP and SDP

SIP, SDP and DBP in 3GPP-Networks




OObbjjeeccttiivveess After this Lecture the Student will:

• Be aware of the technical and commercial meaning of Next Generation Networks (NGN) and the means to realize them

• Know which protocols like SIP (Session Initiation Protocol) are used within NGN’s to address which requirements

• Have seen a simple session setup and release through SIP




OObbjjeeccttiivveess • Be aware of the technical and commercial meaning of Next Generation Networks (NGN) and the means to realize them

First of all, this relates to answering the basic question why NGN’s are implemented in the first place. Secondly, we will illustrate the network elements within NGN’s and their tasks. Finally, we will illustrate the IMS (IP Multimedia Subsystem) as an essential part of NGN’s.

• Know which protocols like SIP (Session Initiation Protocol) are used within NGN’s to address which requirements In this section, we will emphasize on the core protocols within NGN’s and we will shortly illustrate their tasks and meaning.

• Have seen a simple session setup and release through SIP We will confront the reader with this scenario without previously looking at SIP- or SDP-formalisms.




WWhhaatt aarree tthhee ddrriivviinngg FFoorrcceess bbeehhiinndd tthhee NNGGNN--HHyyppee??

• Easy Offering of Multimedia Services becomes possible All protocols behind VoIP support the offering of multimedia services. These protocols allow the user to easily add video or whiteboard functionality to an existing voice call. The same applies vice versa.

• Data and Voice Network Convergence If regular telephone services are also transported via IP then there is no need for installing and supporting two different network types.

• Mobile and Fixed Network Convergence The protocols used for Next Generation Networks (NGN) have been designed to allow the convergence of fixed and mobile telecommunication networks.

• Service Convergence / Offering of Triple-Play Services Next Generation Networks and the underlying IP-based call and media control protocols allow Cable-TV operators, ISP’s (Internet Service Provider) and telecom operators (both mobile and fixed) to attack each others markets. That is, the formerly separated business cases are merged together.




WWhhaatt aarree tthhee ddrriivviinngg FFoorrcceess bbeehhiinndd tthhee NNGGNN--HHyyppee?? NGN relates to Next Generation Networks

Easy Offering of Multimedia Services becomes possible Please compare this to today’s network environment: the simultaneous use of voice and video is still exotic and adding whiteboard functionality to an existing call is impossible.

Data and Voice Network Convergence This merger inherently means cost savings and reduces the number of potential error sources.

Mobile and Fixed Network Convergence Firstly, this is due to the fact that the IMS can offer its services independent from the access network type (fixed or mobile) and secondly this is due to the inherent roaming capability of the underlying SIP (Session Initiation Protocol).

Service Convergence / Offering of Triple-Play Services “Triple Play Services” is a marketing term that relates to the offering of plain 1) internet access, 2) television and 3) telephone services through only one service provider. This service provider may be an ISP, a cable-TV operator or the telecom operator (fixed or mobile).




NNeexxtt GGeenneerraattiioonn NNeettwwoorrkkss aanndd tthheeiirr CCoommppoonneennttss • Typical Configuration and Interconnection of Next Generation Networks




NNeexxtt GGeenneerraattiioonn NNeettwwoorrkkss aanndd tthheeiirr CCoommppoonneennttss Typical Configuration and Interconnection of Next Generation Networks The figure illustrates the most likely configuration of NGN’s and it provides information about the services offered (Triple-Play). Most interestingly, the figure includes two wireless access networks of which only one is based on 3GPP while the other one is based on WIMAX.

Network Type 1: Evolved ISP This type of network now provides telephone services, VoD-services (Video on Demand) and obviously still standard ISP-services (not shown). Through the operation of public hotspots, the ISP also gets the flavor of wireless operation. All multimedia services and the VoIP-services are controlled through the operator owned IMS (IP Multimedia Subsystem).

Network Type 2: Former Telecom-Operator The former Telecom-Operator still has strong ties towards the PSTN. As the figure illustrates, part of the IMS is a soft switch ( combination of Media Gateway and Media Gateway Controller) which allows the VoIP-subscribers the communication with regular PSTN-subscribers. Note that this Telecom-Operator also operates a number of application servers for all kinds of services like VoD or Presence Services. Nothing hinders the Telecom-Operator to allow other operators like the Network Type 1 operator to also use these application servers.

Network Type 3: 3GPP Mobile Network Operator The 3GPP mobile network operator is no different from the previously mentioned operators with one exception: The primary way of accessing an IMS is through GERAN or UTRAN. With bandwidths of up to 2 Mbit/s, the 3GPP-network operator can offer similar or the same services as wireline operators (who are bandwidth limited through the physical limitations of DSL). In the long run, only the operator owned IMS interconnects calling mobile subscribers towards the PSTN. That’s why we did not include the circuit-switched core network domain of the mobile network operator.

Network Type 4: WIMAX Network Operator The upcoming WIMAX-network operators may emerge to a combination of a wireless network operator and an evolved ISP. WIMAX is a very strong DSL-competitor and WIMAX has the potential to become a cellular standard. Note that in case of network type 4 we did not put in an IMS. Its functions are accomplished through a series of dedicated SIP-servers and soft switches.

Note: The IP-CAN towards the customer for wireline operators is usually realized through DSL. Still, cable-TV operators may rather use their evolved cable-TV lines. And WIMAX or UMTS are yet other options of IP-CAN’s.




LLiimmiittaattiioonnss ooff tthhee RReelleeaassee 9999 NNeettwwoorrkk && SSooffttwwaarree AArrcchhiitteeccttuurree




LLiimmiittaattiioonnss ooff tthhee RReelleeaassee 9999 NNeettwwoorrkk && SSooffttwwaarree AArrcchhiitteeccttuurree With a Release 99 compliant implementation of the network architecture, there are only a few differences to our current perception and experience of mobile communication. In fact, the major changes are the advent of UMTS and EDGE in the access network domains. The major consequence of this is the resolution of the bandwidth bottleneck on the air interface. However, many other issues remain unresolved:

Which new services become realistic with Rel. 99? The new UTRAN is definitely much better suited for new services with stringent and variable QoS-requirements on possibly many different data streams than the GSM-based access network. However, the major question is which new services can be offered by mobile network operators that will generate new revenue streams. In addition to the business and marketing aspects of this question there are technical issues. These technical issues relate in particular to the lacking call or session control capabilities of the core network and the terminals. Another issues is the end-to-end negotiation capabilities of specific QoS-requirements. In that respect, the circuit-switched core network should play a major role since it can inherently provide real-time QoS. However, the circuit-switched core network is based on 20 years old ISDN equipment that is not well suited for the communication of the 21st century.

How do the narrow-band MSC’s handle broadband service requests? Nowadays, the circuit-switched core network is primarily based on the MSC’s which are basically ISDN-switches, tailored for the use in mobile networks. These ISDN-switches and the accompanying equipment like modem banks can perfectly handle telephone calls with 64 kbit/s. However, their update into broadband switches that can digest and process new services on multiple simultaneous data streams doesn’t make much sense, considering the alternative of flexible media gateways with smaller footprint which are already available.

How can the user gain access to these new services? This appears to be a minor issue. However, how do you select a video telephony service on your device? Which number do you dial from which application? Finally, the available terminals today are still rather plain telephones than multi-function communicator devices. This issue cannot be resolved with Rel. 99. New call and session control software within these terminals is required to make new applications happen. The advent of SIP and the approach of Open Services Access (OSA), inherited from the IT-world, may provide alternatives in the future. However, neither SIP nor OSA are applicable with Rel. 99.

Conclusion: • With Rel. 99, new services primarily relate to the packet-switched core network domain. These new services are enabled by a more sophisticated

QoS-concept and by the higher bandwidths on the air interface which are enabled by UTRA and EDGE. • The circuit-switched core network domain with Rel. 99 remains identical to previous releases and becomes a bottleneck for new services. • Both Rel. 99 and Rel. 4 do not support new multimedia call control concepts like SIP in neither the core network nor the mobile station.




TThhee NNeeww CCiirrccuuiitt--SSwwiittcchheedd CCNN AArrcchhiitteeccttuurree wwiitthh RReelleeaassee 44




TThhee NNeeww CCiirrccuuiitt--SSwwiittcchheedd CCNN AArrcchhiitteeccttuurree wwiitthh RReelleeaassee 44 Introduction of MSC-Servers (MSC-S) An MSC-Server takes over the call control tasks from the MSC. It is therefore used to process the incoming signaling data and relay it to a GMSC-Server. In addition, the MSC-server incorporates the function of the VLR. The MSC-Server also takes care of controlling the resource management which is the most important task of the Media Gateways (MGW). The MSC-Server which is first accessed during call establishment remains the Anchor MSC-Server Introduction of Media Gateways (MGW) Media Gateways take care of dynamically providing the necessary resources to suit the user’s service requirements and the required QoS. One MGW may therefore be the slave of one or more MSC-S’s. The function of the MSC-Server is described in 3GTS 23.002 (4.1.2.1.2). Introduction of New Interfaces Mc, Nb and Nc ⇒ The Mc-interface is the interface between an MSC-S and an MGW. It is usually based on IP and uses the H.248- / MEGACO-protocol to allow the

communication between MSC-S and MGW. ⇒ The MGW’s are not directly connected to each other. They are rather part of an IP-network. Still, there is the virtual Nb-interface which is applicable for

all information between two MGW’s. As already mentioned, this interface is usually based on RTP/UDP/IP. An alternative is to use AAL-2 in the transport network. If AAL-2 is used, then ALCAP is required in the transport network control plane. For an RTP/UDP/IP-based transport network, the IP BCP (Bearer Control Protocol) is used. The Nb-interface is described in 3GTS 29.414 / 3GTS 29.415.

⇒ Similar rules apply for the Nc-interface. Through the Nc-interface, the different MSC-S’s communicate with each other. This interface is usually based on IP but could also be based on AAL-5. The transport network options for the Nc-interface are described in 3GTS 29.202.

Introduction of New Protocols BICC, H.248 (MEGACO) and Nb-FP ⇒ The new call control protocol to be applied among MSC-S’s is called BICC. It is very similar to ISUP but allows for the provision of binding ID’s to be

used by the transport network control plane to relate requests to responses. BICC is described in ITU-T Q.1902.1 – 6 and ITU-T Q.1912.1. ⇒ The H.248- / MEGACO-protocol is a joined development of the IETF and the ITU-T. This protocol is tailored to allow an MSC-S to control the resource

administration within an MGW. The respective RFC-number is RFC 3015, the ITU-T calls the protocol H.248. ⇒ The Nb-FP-protocol is the only 3GPP-specific protocol in this consideration. It provides for the embedding and most importantly for the

synchronization of the embedded real-time data between media gateways.

Note: • The packet-switched core network remains identical with Release 4 and Release 5. • The illustrated changes affect the circuit-switched core network only. The mobile station remains unchanged. Most importantly, even with Release 4,

advanced call control protocols e.g for VoIP or multimedia transactions are missing.




AAcccceessss aanndd CCoorree NNeettwwoorrkk AArrcchhiitteeccttuurree wwiitthh RReelleeaassee 44




AAcccceessss aanndd CCoorree NNeettwwoorrkk AArrcchhiitteeccttuurree wwiitthh RReelleeaassee 44 An overview of the entire network architecture with Rel. 4 is provided in the figure. Please note the following specifics: ⇒ Both the A-interface and the Iu-cs-interface are divided into a data part and a control part. The data part terminates at the MGW while the control part

terminates at the MSC-S. ⇒ The figure implies a monolithic architecture which is intentional with Rel. 4, considering the fact that there is a one-on-one relationship between RNC /

BSC on one hand and MSC-S / MGW on the other hand (as mentioned and explained before). ⇒ Obviously, there may and will be mixed configurations of MSC’s (< Rel. 4) and MSC-S / MGW (Rel. 4). In such a case, interworking between ISUP

and BICC is required and needs to be provided through the MSC-Server. ⇒ Please consider that many Rel. 4 implementations will go for an all-IP core network which translates into an IP-cloud interconnecting the various

network elements. [3GTS 23.002]




IImmppoorrttaanntt AArrcchhiitteeccttuurraall CChhaannggeess wwiitthh RReelleeaassee 55




IImmppoorrttaanntt AArrcchhiitteeccttuurraall CChhaannggeess wwiitthh RReelleeaassee 55 The figure illustrates the most important architectural changes with 3GPP’s Rel. 5 recommendations:

IP-Multimedia Subsystem (IMS) The IMS represents a new core network domain consisting of different network elements like the P-CSCF (Proxy Call Session Control Function) or the MGCF (Media Gateway Control Function). The IMS provides new IP-based call and session control functionality to the PLMN ( SIP in particular). The IMS is connected to the PLMN exclusively through the packet-switched core network domain ( GGSN).

Home Subscriber Server (HSS) With Rel. 5, the HLR is replaced by the more powerful HSS. Opposed to the HLR, the HSS is capable to communicate with the new IMS core network domain and the HSS can provide subscription services for multimedia services.

New Gm-Interface Between the UE or the MS and the P-CSCF within the IMS, there is a new virtual interface, the Gm-interface for the exchange of SIP-related signaling messages. The virtual Gm-interface is established via the access network (GERAN or UTRAN) and the packet-switched core network domain.

GERAN Core Network Connection as Iu-Interface With Rel. 5, the A- and Gb-interfaces can be replaced by Iu-cs- and Iu-ps-interfaces. Consequently, the GERAN can be connected to the core network domains the same way as the UTRAN. This reduces the number of protocols to be supported and simplifies the network architecture.

Iub-, Iu-cs- and Iur-Interface alternatively IP-based With UMTS Rel. 4, the circuit-switched core network can be built on an IP-network. With Rel. 5, this strategy is expanded down to the Iub-, Iu-cs- and the Iur-interface. Therefore, NodeB’s can be interconnected to their C-RNC using IP. The same applies to the interconnection between RNC’s on one hand and MSC-S and MGW on the other hand. Obviously, the Iur-interface can also be based on IP.




NNeeww FFeeaattuurreess wwiitthh RReelleeaassee 55




NNeeww FFeeaattuurreess wwiitthh RReelleeaassee 55 The figure illustrates the access network independent new features with Release 5:

• Fixed Mobile Convergence With the provision of packet-switched voice services in both landline and mobile networks the border of fixed and mobile telephony becomes fuzzy. More details will be provided on the following page.

• Open Service Access (OSA) OSA provides for the definition of an Application Programming Interface (API) to allow 3rd party developers the provision of new or adjusted applications on top of the OSA interface. The applications are provided through internal or external Application Servers (AS) and make use of the service capabilities that the underlying network provide.

• Multimedia Call Control Multimedia call control protocols allow for the definition and control of possibly multiple bearers for multiple media streams. Different options exist to implement multimedia call control.

• Generic Call Control Generic call control is essential for the provision of OSA-features. Through generic call control commands, the OSA is able to access the service functions of the network.




FFiixxeedd MMoobbiillee CCoonnvveerrggeennccee




FFiixxeedd MMoobbiillee CCoonnvveerrggeennccee The figure illustrates one possible future of mobile communications that will be possible with 3GPP’s Rel. 5 specifications. In our presentation, the differences between mobile access and fixed line access become fuzzy and rather transparent to the user.

Note: The new dimension of communications is enabled through the Session Initiation Protocol (SIP) which provides, similar to a mobile network, for the location dependent registration of a subscriber to a “Registrar” called database. Most importantly, this registrar stores the location ( IP-address) of the subscriber and will route incoming transaction requests to that IP-address. In a 3G mobile network, this function is part of the IMS (IP Multimedia Subsystem). In that respect, the IMS does not only provide access to multimedia services but also to simple VoIP.

The access to services can be split into four domains:

The User Domain This domain simply consists of an advanced (U)SIM with additional SIP-identities and security means for the internet ( IPsec). To provide for the full scale of roaming among different devices and access networks, this (U)SIM needs to be delivered in a standardized, widely used shell, e.g. in a USB-plug.

The Device Domain The device domain varies with the users’ habits and over time. It may consist of the usual mobile devices which may be more or less advanced and therefore offer more or less advanced features. Alternatively, the user may insert the USB-plug into a laptop computer and use software applications to run different services (e.g. softphone). Also, imagine a cradle at home or in the airplane where you may insert your USB-plug to be reachable over the respective home or airplane telephone

The Access Domain In the access domain we can find the full range of access networks of today and tomorrow. Our examples shall only provide an overview. Most importantly, these access networks vary largely in their capability to provide different, adjustable and guaranteed QoS, depending on the users’ requirements. In general, this constraint also applies to all transport networks between the user and the application.

The Service Domain Finally, there is the service domain. This service domain includes the full range of possibilities from regular PSTN, offering POTS up to multimedia networks that are able to offer content rich applications to the user.




OOSSAA ((OOppeenn SSeerrvviiccee AAcccceessss))




OOSSAA ((OOppeenn SSeerrvviiccee AAcccceessss)) The Open Service Access is already part of the Rel. 4 series of specifications but without the IMS, it is difficult to define, develop and provide feature-rich services. Therefore, with Rel. 5, OSA may become an essential aspect of how to increase the number and quality of available end user services, provided through the PLMN. The basic question remains: What is OSA and how does it work?

What is OSA? The Open Service Access (OSA) provides a network- and vendor independent interface to PLMN-internal and external applications that provide new and enhanced services to PLMN-subscribers. Examples for such services time- or location dependent services that a PLMN-subscriber registers for: ⇒ A road map or public transportation guideline is automatically transferred to a subscriber once arriving in a new city. ⇒ When roaming to another PLMN, the related roaming charges are conveyed to the subscriber. ⇒ The regional traffic jams are sent to a subscriber. ⇒ Online Shopping and Online Charging: Registered applications allow the subscriber to purchase any goods. Charging is trustworthy done through the

telephone bill.

How does OSA work? ⇒ The basic principle of OSA is that new services, provided through the operator or through 3rd party application developers shall be able to access the

available network capabilities like call control, multimedia call control, messaging and subscriber locating features (provided through MM/GMM-protocols or location based services) through network independent generic functions. These functions are called SCF (Service Capability Feature) and they are available to the applications through one or more SCS’s (Service Capability Server). The applications are based on the principle that the application software calls an SCF like an internal subroutine (e.g. CALL {Subscriber_Location_Service [parameters]}) without the need to deal with any GSM- /GPRS- /UMTS-specific details.

⇒ Before an application is allowed to provide its services to PLMN-subscribers, it needs to authenticate and register with the PLMN. This important function is achieved through a special OSA-SCS, called the “Framework”.

⇒ Only after this authentication and registration, subscribers are allowed to use a service which usually involves another authentication between subscriber and application.

[3GTS 22.127, 3GTS 23.127, 3GTS 29.198, 3GTS 29.998]




MMuullttiimmeeddiiaa CCaallll CCoonnttrrooll




MMuullttiimmeeddiiaa CCaallll CCoonnttrrooll With Rel. 5, three different options exist:

SIP (Session Initiation Protocol) SIP-call control can be used for plain VoIP-services, for setting up conferences and for controlling multimedia services. The SIP-protocol suite will be explained in the next chapter. Note that SIP by definition of the 3GPP will always use the packet-switched domain to interconnect a subscriber to the IMS. Obviously, subscribers may also route SIP-messages transparently to a SIP-registrar which is external to the PLMN.

[RFC 3261, 3GTS 23.228, 3GTS 24.228, 3GTS 24.229]

Note: Neither the IMS nor SIP require a circuit-switched core network domain.

H.324M The ITU-T- standard H.324M (⇔ M = modified) is the suggested multimedia call control option for use through the circuit-switched core network domain. H.324 is a modification to H.323 which is also using H.245 for call control functions. The suggested bearer protocols for H.324M are the AMR-voice coder for audio and H.263 or MPEG 4 for video.

[ITU-T H.324, ITU-T H.245, 3GTS 26.111, 3GTS 26.112]

H.323 Although H.323 is today the most frequently used protocol for VoIP and multimedia services, its use and interworking with PLMN-network elements is not supported by the 3GPP-specifications. Still, operators may decide to offer H.323-based multimedia services through proprietary architecture.

[3GTS 23.121]




WWhhyy iiss aann AArrcchhiitteeccttuurree EEvvoolluuttiioonn nneecceessssaarryy??




WWhhyy iiss aann AArrcchhiitteeccttuurree EEvvoolluuttiioonn nneecceessssaarryy??

Integration of E-UTRAN with its new Concepts • IP-centric setup

At the end of the day, E-UTRAN is only there to provide powerful IP-bearers to the users.

Consequentially, the offering of voice services over E-UTRAN is only possible as VoIP. This means a hard cut compared to previous 3GPP-technologies and illustrates the reasoning behind the considerations of circuit-switched fallback.

• Low Latency Requirements E-UTRAN imposes specific maximum latencies to be achieved for state changes within the E-UTRAN control plane (e.g. from RRC-idle to RRC-connected) and, even more important, during the traversal of user data through the user plane. In that respect, for the control plane state change latencies of app. 50 ms are the target. User data shall be delayed by no more than 5 ms in the ideal case when traversing through E-UTRAN. Note that this value does not take into account latencies within the EPC or beyond!"Packet-switched only" requires a serious QoS-integration with respect to e2e-integration and service differentiation The full-scale integration of QoS is a precondition for the operation of any carrier-grade services over E-UTRAN. If different services of the same or different users cannot be distinguished and differently treated, based e.g. on their latency requirements, then E-UTRAN will probably fail. Amendment of network controlled bearer management -> instead of UE-managed only as in Rel. 6 This important change relieves the UE from the responsibility to request the establishment of real-time bearers and allows the network, esp the PCRF to take care of this function.




WWhhyy iiss aann AArrcchhiitteeccttuurree EEvvoolluuttiioonn nneecceessssaarryy?? ((ccoonntt..))




WWhhyy iiss aann AArrcchhiitteeccttuurree EEvvoolluuttiioonn nneecceessssaarryy?? ((ccoonntt..)) Integration of Non-3GPP RAT's is sub-optimum in Rel. 7 because ... • Mobility between 3GPP-RAT and Non-3GPP-RAT does almost not exist

At the current time, the major difference between former approaches (Rel. 6 ) and SAE with respect to macro-mobility, is the definition of so called optimized handover procedures for certain access network combinations (cdma2000 <=> E-UTRAN). Without optimization, at the current time SAE pretty much relies on the capability of the UE to operate two simultaneous radio links to enable seamless roaming between different access network types (e.g. WiFi => cdma2000)

• In Rel. 6 and 7, non-3GPP-RAT's are conceptually treated as "alien" technologies to be amended to existing 3GPP-RAT's There is no possibility in Rel 6 and 7 to consider specifics of foreign access networks when interconnecting them to a 3GPP-network. Therefore, this interconnection is merely done on AAA-level with a transparent IPsec-tunnel between the UE and through that access network towards the 3GPP-network.




WWhhyy iiss aann AArrcchhiitteeccttuurree EEvvoolluuttiioonn nneecceessssaarryy?? ((ccoonntt..))




WWhhyy iiss aann AArrcchhiitteeccttuurree EEvvoolluuttiioonn nneecceessssaarryy?? ((ccoonntt..)) Therefore, legacy operators of Non-3GPP-RAT's cannot adopt the existing 3GPP-CN-Architecture • Which is very critical for those operators who want to adopt LTE / E-UTRAN in addition to their already existing Non-

3GPP-RAT's (e.g. cdma2000 / WiMAX) Consider an operator who has no 3GPP-access networks in operation at this time but who intends to use LTE (E-UTRAN) in the future. Without an evolved system architecture those operators would have to operate two core networks in parallel; one for E-UTRAN and the other one for their legacy access networks. This in turn is not feasible because of the high OPEX.

• Which would be quite beneficial as 3GPP provides proven "off-the-shelf" solutions The number of 3GPP core networks exceeds by far any other implementation in the market. Their price and stability prospers quite a bit from the related volume of scales effects. The other possibility has clearly been shown during recent years in the WiMAX-area: The IEEE had only defined the air interface and therefore, a core network and all protocols and procedures were missing. It was finally the WiMAX-forum that jumped in and filled out those gaps but it took years and a considerable expenses which have to be settled among less shoulders.




RReelleeaassee 88 // 99 AArrcchhiitteeccttuurree OOvveerrvviieeww




RReelleeaassee 88 // 99 AArrcchhiitteeccttuurree OOvveerrvviieeww ⇒ The image is split into two parts: in the upper part, the image illustrates the legacy network parts and clouds which already exist with 3GPP Rel. 6 and

7. ⇒ These network parts and clouds are illustrated in gray color. ⇒ In the lower part, the new network clouds with Rel. 8 are depicted. They have been colorized to provide for a better distinction from the legacy network

clouds. ⇒ I-WLAN IP access from non-3GPP non-trusted access network may be achieved either directly (lower option) or through the packet-switched core

network domain (upper option).

• EPC vs. EPS The two terms EPC and EPS can be distinguished as illustrated: ⇒ The EPC represents the core component of the EPS. ⇒ The EPS contains the EPC and the E-UTRAN (LTE) access network. However, it does not contain the other access networks. [3GTS 23.401, 3GTS 23.402]

• Non-3GPP Access Networks (trusted / non-trusted) ⇒ In the legacy part (gray) the image illustrates the so called non-3GPP non trusted access networks which have been supported by 3GPP-

recommendations since Rel. 6. ⇒ New with Rel. 8 and SAE are the so called trusted non-3GPP access networks. Those trusted non-3GPP access networks comply to an EPC-

operator's security requirements [3GTS 33.402 (4.2)] and are therefore granted direct access to the EPC. More details are provided in chapter 2. Whether a non-3GPP access network is trusted or untrusted is ...

1. either pre-configured in the UE or ... 2. .the UE learns the trust relationship during EAP-AKA authentication through that access network from its home-PLMN. 3. Yet another option is that the selected access network does not at all support EAP-AKA authentication in which case the UE determines that it

camps on an untrusted non-3GPP access network. The major difference for the UE with respect to the trust relationship of the selected non-3GPP access network is that in "untrusted case" the UE must establish an IPsec-tunnel through IKEv2 with an ePDG in the EPC [3GTS 33.402 (8)]. The illustrated IPsec-tunnel through the non-3GPP trusted access network is only necessary in case the S2c-interface is used and it comes without interface name.




ZZoooomm iinnttoo tthhee EEPPSS




ZZoooomm iinnttoo tthhee EEPPSS ⇒ The image depicts another time the two network clouds EPC and E-UTRAN and illustrates the physical interconnections (black lines) of the various

network elements to the two IP-backbone networks. [3GTS 23.401 (5.3.2)]

• Functional Overview of Core Network Elements within the EPC ⇒ The MME or Mobility Management Entity takes care of various control plane functions like mobility management and session management. ⇒ The S-GW or Serving Gateway is the peer of the MME within the user plane and its functions evolve around packet data routing and forwarding. ⇒ The PDN-Gateway has similar functions as the Serving Gateway but it remains the anchor during a packet data connection even if MME and S-GW

are swapped. It is feasible to assume that GGSN's will typically be upgraded into PDN-GW's. S-GW and PDN-GW may easily be integrated into a single box in order to save hardware and latency. A combination of MME and S-GW is probably less appealing because the MME is a very slim hardware box. ⇒ The ePDG is required to interconnect non-trusted non-3GPP networks to the EPC. Its functions evolve around tunnel termination towards the UE and

the non-trusted non-3GPP access network.




TThhee eeNNBB




TThhee eeNNBB ⇒ Selection of MME at attachment

Since there is the S1-flex feature more than one MME can be connected to the same eNB. The eNB select which MME it connects the UE to according to the load situation and the operator the UE belongs to.

⇒ Scheduling of paging messages Once the UE is in the idle state there are neither location areas nor routing areas but tracking areas. Then the UE needs to be paged on TA level. The TA is having a function like the URA but is also replacing LA and RA.

⇒ Routing of user plane data to Serving GW It is for further study which node is establishing the user plane tunnel and whether it is established at RRC establishment.

⇒ PDCP Please note here that PDCP is used for both control and user plane. In UTRAN there is no PDCP in the control plane.




TThhee eeNNBB ((ccoonntt’’dd))




TThhee eeNNBB ((ccoonntt’’dd)) ⇒ RRM/RRC

The RRC is issuing commands executing the decisions of the RRM. ⇒ RLC

Since L1 RLC and MAC are in the eNB there is the possibility to adapt the RLC-PDU size flexibly to the transport block size in MAC. ⇒ MAC

Nothing to add to what is stated in the image. ⇒ Complete L1 functionality

See layer 1 sections.

[3GTS 36.300 (4.1), 3GTR 25.912 (9)]




MMoobbiilliittyy MMaannaaggeemmeenntt EEnnttiittyy ((MMMMEE))




MMoobbiilliittyy MMaannaaggeemmeenntt EEnnttiittyy ((MMMMEE)) ⇒ NAS signalling

Once the UE is idle but stays registered the MME keeps the context of the UE in order to allow for a fast reconnection. ⇒ Inter CN node signaling (3GPP networks)

The MME is interconnecting to the SGSN and the HSS as well as to the Serving GW and it has the responsibility to select the right code network nodes – especially in a handover situation.

⇒ Security management Nothing to add to what is stated in the image.

[3GTS 23.401 (4.4.2), 3GTS 36.300 (4.1)]




MMoobbiilliittyy MMaannaaggeemmeenntt EEnnttiittyy –– IInntteerrffaacceess && PPrroottooccoollss




MMoobbiilliittyy MMaannaaggeemmeenntt EEnnttiittyy –– IInntteerrffaacceess && PPrroottooccoollss Image Description ⇒ The green color used for the interfaces indicates the control plane relationship of a protocol or an interface. ⇒ The interface towards the UE is depicted to illustrate the NAS-protocol involvement of the MME. Obviously, this interface is realized over S1-AP and

Uu. ⇒ The S102-interface towards the cdma2000 access network is only necessary in case of circuit-switched fallback for cdma2000-networks. [3GTS 23.401 (5.1)]




MMoobbiilliittyy MMaannaaggeemmeenntt EEnnttiittyy –– TTaasskkss && FFuunnccttiioonnss




MMoobbiilliittyy MMaannaaggeemmeenntt EEnnttiittyy –– TTaasskkss && FFuunnccttiioonnss The MME and the UE use the physical resources of the LTE-Uu-interface and the S1-interface to exchange NAS-signaling [3GTS 24.301] which relates to EMM and ESM.

S1-Signaling towards the eNodeB MME and eNodeB use the S1-AP-protocol for various tasks as stated in the image. [3GTS 36.413]




SS--GGWW aanndd PP--GGWW SSeelleeccttiioonn




SS--GGWW aanndd PP--GGWW SSeelleeccttiioonn Image Description ⇒ It is the eNodeB that selects the MME out of an MME-pool. ⇒ The selection of the S-GW is done based on O&M-constraints.

Nevertheless, if the possibility is there to select an S-GW which is integrated with the selected P-GW, the MME shall prefer this choice.

⇒ The selection of the P-GW is either predefined through a decision of the HSS of the registering UE or the MME may apply route optimizing decisions, e.g. by selecting a local P-GW in the V-PLMN in case of roaming.

The aforementioned route optimization is frequently called local breakout [3GTS 23.882 (7.2)]

[3GTS 23.401 (4.3.8)]

Other Selection Functions ⇒ In addition to the aforementioned selection functions the MME is also responsible to select the new MME in case of a handover with MME-change. ⇒ Besides, the MME will select the SGSN in case of inter-RAT handovers to GSM or UMTS, if the packet-switched core network in the 2G/3G-domain

supports the IuFlex-feature.




EE--UUTTRRAANN OOrrggaanniizzaattiioonn aanndd IIddeennttiiffiieerrss




EE--UUTTRRAANN OOrrggaanniizzaattiioonn aanndd IIddeennttiiffiieerrss Tracking Areas Tracking areas may contain one or more cells and they are comparable to location areas (2G) and routing areas (3G). In the image, tracking areas are identified by different fill colors of the cell coverage areas while E-UTRAN pool areas are identified by different line colors of these cell coverage areas.

TAI and TAI-list Tracking areas never overlap [3GTR 24.801 (5.1.1.1)] but the MME may indicate to the UE a whole list of TAI's during attachment (maximum 16 different TAI's). As long as the UE remains within the coverage area of these tracking areas, no regular tracking area update scenario is performed. TAI: [3GTS 23.003 (19.4.2.3)] The coverage area of tracking areas cannot be precisely aligned with the coverage area of 2G/3G location areas and routing areas because these are different radio technologies with different radio frequencies and possibly different site locations.

E-UTRAN Pool Areas An E-UTRAN pool area comprises all the eNodeB's which have access to the MME's which belong to the same MME-pool. As illustrated, E-UTRAN pool areas may overlap (the green tracking area is part of both E-UTRAN pool areas) and the eNodeB's within the green tracking area may select MME's out of both indicated tracking areas. Note the two notions of overlapping: 1.The MME in the middle overlaps between both MME-pools, it is therefore member of both MME-pools. Consequentially, this MME is the only one that can be accessed from eNodeB's within both E-UTRAN pool areas. 2.The green tracking area overlaps between both E-UTRAN-pool areas and it is therefore member in both E-UTRAN pool areas. One consequence is that the eNodeB's inside the green tracking area can access all MME's in both MME-pools. The benefit is that these eNodeB's have access to more MME-resources. This is particularly appealing for an area with temporarily heavy traffic (e.g. a sport arena lies inside the coverage area of the green tracking area).

MME Pool's and MMEI The MME Group ID identifies a certain MME-pool. MME's may be part of more than one MME-pool. The identification of an MME is given by the MMEI which in turn is not unique, because a given MME may be part of more than one MME-pool. [3GTS 23.002 (3.15a, 3.16)]




UUEE IIddeennttiiffiieerrss –– MM--TTMMSSII aanndd SS--TTMMSSII




UUEE IIddeennttiiffiieerrss –– MM--TTMMSSII aanndd SS--TTMMSSII Note the NRI which is used to indicate in Rel. 5, 6 and 7 which SGSN or VLR allocated this TMSI / P-TMSI. The NRI therefore uniquely identifies an SGSN or VLR within a pool of SGSN's or VLR's. [3GTS 23.003 (2.4, 2.8)] The M-TMSI is allocated and administered by the MME. In that respect, the MME must be able to relate an allocated M-TMSI to the IMSI of a subscriber. The S-TMSI is used for paging purposes and is constructed by the paging MME from the M-TMSI of the UE plus the MME-code of that MME. The M-TMSI (or any other TMSI) cannot act as permanent UE-identifier. This function prevails with the IMSI (smart card Id) and the IMEI (device Id). Certificates may not be used as permanent UE-identifiers.




UUEE IIddeennttiiffiieerrss –– GGUUTTII




UUEE IIddeennttiiffiieerrss –– GGUUTTII ⇒ The GUTI has been introduced as combination of MCC/MNC, MME-identification and M-TMSI to provide for an unambiguous identification of a UE

without the need to reveal a permanent identity (e.g. IMSI) of that UE. ⇒ The GUTI has a meaning only while the UE operates towards the EPC through E-UTRAN or through GERAN/UTRAN. ⇒ The GUTI is not used if the UE is connected to the EPC through other access networks. [3GTS 23.003 (2.8), 3GTS 24.301 (9.9.3.10)]




TThhee SSeerrvviinngg GGaatteewwaayy ((SS--GGWW))




TThhee SSeerrvviinngg GGaatteewwaayy ((SS--GGWW)) ⇒ Termination of U-plane packets for paging reasons

Once data is arriving in the downlink and the UE is in EMM-REGISTERED & ECM-IDLE then the Serving Gateway is initiating the paging procedure before forwarding the data packets further.

⇒ Support of UE mobility anchoring by switching U-plane during inter eNB handover At any time each UE has just one Serving GW. Once the UE does not leave the zone of the Serving GW the Serving GW stays the same (anchoring).

⇒ Transport Packet Marking According to QCI The marking of the packets is helping the eNB to reinforce the right QoS.

⇒ Mobility anchoring for inter-3GPP mobility It terminates the S4 interface towards the SGSN for 2G/3G traffic.

⇒ Packet routing and forwarding In handover situations involving different code network entities the packets need to be forward to the target Serving GW before the handover is complete.

⇒ Charging support Nothing to be added to what is stated above.

⇒ Lawful interception The Serving GW has to support tapping the user plane for lawful interception purposes.

[3GTS 23.401 (4.4.3.2), 3GTS 36.300 (4.1)]




SS--GGWW –– IInntteerrffaacceess && PPrroottooccoollss




SS--GGWW –– IInntteerrffaacceess && PPrroottooccoollss Image Description ⇒ The green color of an interface indicates the control plane relationship of a protocol or an interface. Likewise, orange color indicates user plane

relationship.

Note that on S5 and S8 interface it is an operator choice to implement either GTP or PMIPv6 together with GRE. Irrespective of this choice, the S-GW must support GTP on various other interfaces like for example towards MME, eNodeB or RNC.

[3GTS 23.401 (5.1), 23.402 (5.1)]

Tasks & Functions ⇒ Packet Routing / Relaying ⇒ Legal Interception ⇒ QCI-based Packet Tagging

When the S-GW receives IP-packets in uplink or downlink direction it will check the related QCI-value based on the relationship of the packet to a certain service data flow and handle the packet accordingly, e.g. relay it to the responsible GTP-tunnel or GRE-tunnel.

⇒ Accounting [3GTS 23.401 (4.4.3.2), 23.402 (4.3.3.2)]




TThhee PPDDNN GGaatteewwaayy ((PP--GGWW))




TThhee PPDDNN GGaatteewwaayy ((PP--GGWW)) ⇒ Termination towards of PDN’s

If the UE using more than one PDN it may use more than one PDN GW. Once the UE connects to a PDN GW for a service then it stays connected to this PDN GW as long as the service is consumed.

⇒ Policy enforcement Nothing to add to what is stated in the image.

⇒ Charging support For users visiting the network the charging policies may be downloaded from its home PLMN.

⇒ DHCPv4 and DHCPv6 functions The PDN GW will provide the IP addresses to the UE’s.

[3GTR 23.882 (7.2.2), 3GTS 23.401 (4.4.3.3), 3GTS 36.300 (4.1)]




PP--GGWW –– IInntteerrffaacceess && PPrroottooccoollss




PP--GGWW –– IInntteerrffaacceess && PPrroottooccoollss Image Description ⇒ The image reuses the color codes from chapter 2. The green color indicates the control plane relationship of a protocol or an interface. Likewise,

orange color indicates user plane relationship. ⇒ The ESP-tunnel over S2c has been established using EAP-AKA over IKEv2. ⇒ The protocol layer “Application” comprises among others http, SIP, RTP (with voice or video). ⇒ [3GTS 23.401 (5.1), 23.402 (5.1)]

Tasks & Functions ⇒ UE IP Address Allocation ⇒ QCI-based Packet Tagging

The P-GW performs this task as part of the classification and according to the installed QoS-policy. Based on the installed DL-TFT, the QCI is determined and traffic handling rules are determined.

⇒ Policy Enforcement Traffic shaping: Delay data packet transmission until resources become available. Traffic policing: Discard packet if no resources to transmit them are available.

⇒ Legal Interception ⇒ Home Agent Function [3GTS 23.401 (4.4.3.3), 23.402 (4.3.3.3)]




EEnnhhaanncceedd PPaacckkeett DDaattaa GGaatteewwaayy ((eePPDDGG)) –– IInntteerrffaacceess && PPrroottooccoollss




EEnnhhaanncceedd PPaacckkeett DDaattaa GGaatteewwaayy ((eePPDDGG)) –– IInntteerrffaacceess && PPrroottooccoollss

Image Description ⇒ The image reuses the color codes from chapter 2. The green color indicates the control plane relationship of a protocol or an interface. Likewise,

orange color indicates user plane relationship. The black lines represent physical links which are used to piggyback the SWu-interface. ⇒ The ESP-tunnel over S2c has been established using EAP-AKA over IKEv2. ⇒ The Gxb-interface as depicted in the image is currently not specified. [3GTS 23.401 (5.1), 23.402 (5.1)]

Tasks & Functions ⇒ ESP-Tunnel Mgmt towards UE's

The allocated IP-address is just relayed by the ePDG. It stems from the P-GW. ⇒ QoS-specific Packet Tagging in UL-Direction ⇒ Legal Interception ⇒ MAG-Function for PMIPv6 [3GTS 23.402 (4.3.4)]




DDiissttiinnccttiioonn TTrruusstteedd vvss.. NNoonn--TTrruusstteedd NNoonn--33GGPPPP RRAATT''ss




DDiissttiinnccttiioonn TTrruusstteedd vvss.. NNoonn--TTrruusstteedd NNoonn--33GGPPPP RRAATT''ss The UE shall fall back to non-trusted operation if the trust relationship between the access network and the H-PLMN network operator cannot be determined [3GTS 24.302 (6.2.4)].

The trust relationship of an access network is ultimately decided upon by the H-PLMN network operator. The UE either possesses pre-configured trust relationship information or the trust relationship between access network and H-PLMN is conveyed to the UE during the EAP-AKA-based access authentication. [3GTS 24.302 (4.1), (6.2)]




DDiissttiinnccttiioonn TTrruusstteedd vvss.. NNoonn--TTrruusstteedd NNoonn--33GGPPPP RRAATT''ss




DDiissttiinnccttiioonn TTrruusstteedd vvss.. NNoonn--TTrruusstteedd NNoonn--33GGPPPP RRAATT''ss The S101- and S103-interfaces are only applicable if the trusted non-3GPP access network is a cdma2000 network. In that case, these two interfaces are used for handover optimization. [3GTS 23.402 (6)]




ee--UUTTRRAANN –– eeHHRRPPDD RRooaammiinngg AArrcchhiitteeccttuurree




ee--UUTTRRAANN –– eeHHRRPPDD RRooaammiinngg AArrcchhiitteeccttuurree The HRPD RAT is based on Mobile IP, where the HSGW will act as MAG function / FA and the PDN-GW will act as LMA function / HA. As a consequence, the S5 / S8 interface will typically use PMIPv6 for signaling and GRE for data tunneling instead of GTP C/U.




…… aanndd tthhee PPrroottooccooll SSttaacckk wwiitthh HHRRPPDD RRAATT




…… aanndd tthhee PPrroottooccooll SSttaacckk wwiitthh HHRRPPDD RRAATT the alternative access network protocol stack for eHRP, is based on Mobile IP and Vendor Specific Network Control Protocol (VSNCP) over PPP. Keypoint is that this access network alternative to e-UTRAN is based on generic IP technologies. The signaling towards the Core Network is either PMIPv6 or MIPv4. The data is routet through an GRE tunnel towards the CN.




SSeeccuurriittyy AArrcchhiitteeccttuurree –– OOvveerrvviieeww && IInnttrroodduuccttiioonn




SSeeccuurriittyy AArrcchhiitteeccttuurree –– OOvveerrvviieeww && IInnttrroodduuccttiioonn Please note that eNodeB also includes home eNodeB's.





What are the reasons from your perspective to introduce security on two different layers?




TThhee AAuutthheennttiiccaattiioonn QQuuiinnttuupplleett ooff UUMMTTSS-- aanndd IIMMSS--AAKKAA




TThhee AAuutthheennttiiccaattiioonn QQuuiinnttuupplleett ooff UUMMTTSS-- aanndd IIMMSS--AAKKAA AK AK is used to conceal SQN.

AMF AMF is used as input parameter to generate the MAC

AUTN Concatenation of (SQN (XOR) AK), AMF and MAC

CK Used for encryption between RNC and UE in UMTS-networks

IK Used for integrity protection.

RAND Used to generate MAX, XRES, CK, IK and AK

XRES Authentication Response which is calculated from RAND and Ki

MAC Used for Network Authorization towards the MS/UE.

See later security section for IMS Authentication and Registration process – Rel6. [3GTS 33.102]

Abbreviations: AKA: ______________________________________________________________________ RAND (128 bit): ______________________________________________________________ IK (128 bit): _________________________________________________________________ AMF (16 bit): ________________________________________________________________ MAC (64 bit): ________________________________________________________________

XRES (32 .. 128 bit): __________________________________________________________ CK (128 bit): _________________________________________________________________ AK (48 bit): __________________________________________________________________ SQN (48 bit): ________________________________________________________________ AUTN: ______________________________________________________________________




KKeeyy DDeerriivvaattiioonn FFuunnccttiioonn ((KKDDFF)) ffoorr KK((AASSMMEE)) –– RReell..88




KKeeyy DDeerriivvaattiioonn FFuunnccttiioonn ((KKDDFF)) ffoorr KK((AASSMMEE)) –– RReell..88

Fill in the input parameters to derive K(ASME) applying the S(10) key derivation function.

Input Parameters The secret input parameters are IK and CK with a length of 16 octets each. They stem from a previous run of UMTS-AKA [3GTS 33.102]. Other input parameters are the serving network identity (MCC + MNC) and SQN (xor) AK which also stems from the previous run of UMTS-AKA.

Although CK and IK together provide a key length of 256 bits and although the length of K(ASME) is 256 bit, the efficient key length is ultimately restricted by the subscriber key Ki with a length of only 128 bit.

[3GTS 33.401 (A.2)]




EEPPSS--AAKKAA dduurriinngg IInniittiiaall AAttttaacchh PPrroocceedduurree




EEPPSS--AAKKAA dduurriinngg IInniittiiaall AAttttaacchh PPrroocceedduurree ((ccoonntt..))




TThhee UUssee ooff EEAAPP--AAKKAA'' AAuutthheennttiiccaattoonn ffoorr eeHHRRPPDD




TThhee UUssee ooff EEAAPP--AAKKAA'' AAuutthheennttiiccaattoonn ffoorr eeHHRRPPDD ⇒ PPP LCP negotiation occurs. EAP is negotiated as the authentication protocol. ⇒ The HSGW sends an EAP-Request / Identity message to the UE over the A10 main signaling connection. ⇒ The UE responds with EAP-Response / Identity (NAI). If UE uses its permanent NAI, it shall use the IMSI-based Network Access Identifier (NAI)

format ⇒ The HSGW forwards the unmodified NAI received in the EAP-Response/Identity message via the 3GPP2 AAA Proxy to the EAP Server in the 3GPP

AAA. It also conveys the access type (i.e., RAT type), and NAS-ID = {the FQDN of the HSGW} and the access network identity to assist the 3GPP AAA server in determining the access network name.

⇒ The 3GPP AAA Server will terminate the EAP protocol. If the UE identified itself with the pseudonym, the 3GPP AAA server determines the real identity of the UE and derives the IMSI from it. The 3GPP AAA Server checks that it has an unused authentication vector with AMF separation bit = 1 and the matching access network identifier available for that subscriber. If not, a set of new authentication vectors is retrieved from HSS using IMSI. In order to retrieve the new vectors from the HSS, the 3GPP AAA server determines the network name and ensures that the given access network is authorized to use the claimed name. The access network name determined by the 3GPP AAA is included in the AT_KDF_INPUT attribute of the message sent to HSS.

⇒ New keying material is derived from IK’ and CK . A new pseudonym and/or re-authentication ID may be chosen and if chosen are protected (i.e., encrypted and integrity protected) using keying material generated from EAPAKA’.

⇒ The 3GPP AAA Server sends RAND, AUTN, a message authentication code (MAC), AT_KDF, AT_KDF_INPUT and two user identities (if they are generated): protected pseudonym and/or protected re-authentication id in EAP Request/AKA’-Challenge message towards the UE. The sending of the reauthentication ID depends on the operator's policies on whether to allow fast re-authentication processes or not. It implies that, at any time, the 3GPP AAA Server decides (based on policies set by the operator) whether to include the re-authentication id or not, thus allowing or disallowing the triggering of the fast re-authentication process. The 3GPP AAA Server may use a protected success indication by including the AT_RESULT_IND attribute in the EAP Request/AKA’- Challenge message, in order to indicate to the UE that it would like result indications in both successful and unsuccessful cases.. The inclusion of the result indications for the protection of the result messages depends on home operator's policies.

[3GTS 33.402, 3GPP2 X.S0057-0 (5.2.5), draft-arkko-eap-aka-kdf]




TThhee UUssee ooff EEAAPP--AAKKAA'' AAuutthheennttiiccaattoonn ffoorr eeHHRRPPDD ((ccoonntt..))




TThhee UUssee ooff EEAAPP--AAKKAA'' AAuutthheennttiiccaattoonn ffoorr eeHHRRPPDD ((ccoonntt..)) ⇒ The UE runs the AKA algorithms on the UE. The UE verifies that AUTN is correct and thereby authenticates the network. If AUTN is incorrect, the

terminal rejects the authentication (not shown in this example). If the sequence number is out of synch, the terminal initiates a synchronization procedure (not shown in this example), . If AUTN is correct, the UE computes RES, IK’ and CK’. The UE derives required additional new keying material, including the key MSK, from the new computed IK’ and CK’, and checks the received MAC with the new derived keying material. If a protected pseudonym and/or re-authentication identity were received, then the UE stores the temporary identity(s) for future authentications.

⇒ The UE calculates a new MAC value covering the EAP message with the new keying material. UE sends EAP Response/AKA’-Challenge containing calculated RES and the new calculated MAC value towards the 3GPP AAA Server. The UE includes in this message the result indication if it received the same indication from the Server before. Otherwise, the UE omits this indication.

⇒ The 3GPP AAA Server checks the received MAC and verifies the AT-RES value to the XRES value from the AKA vector receive. If the 3GPP AAA Server sent a pseudonym and/or fast re-authentication identity to the UE before, it now associates these identities with the permanent identity of the UE.

⇒ If the 3GPP AAA Server requested previously to use protected result indications and received the same result indications from the UE , Server and the UE will optionally exchange the AKA notification result.

⇒ The 3GPP AAA Server creates an EAP-Success message that also includes the subscription profile that has been retrieved from the HSS and the MSK ), in the underlying AAA protocol message (i.e., not at the EAP level).

⇒ The HSGW stores the keying material to be used in communication with the authenticated UE as required. The HSGW also stores the other parameters sent in the AAA message. The HSGW signals EAP-Success to the UE. If the UE received the pseudonym and/or fast reauthentication identity, it now accepts these identities as valid for next authentication attempt.

⇒ The authentication process may fail at any moment, for example because of unsuccessful checking of MACs or no response from the UE after a network request. In that case, the EAP AKA process will be terminated and an indication shall be sent to the HSS.

[3GTS 33.402, 3GPP2 X.S0057-0 (5.2.5), draft-arkko-eap-aka-kdf]




IIPPvv66 PPrroottooccooll EElleemmeennttss IInnhheerriitteedd ffrroomm IIPPvv44




IIPPvv66 PPrroottooccooll EElleemmeennttss IInnhheerriitteedd ffrroomm IIPPvv44 The most important differences between the headers of IPv4 and IPv6 can be deducted from the image: Address Range The address range of IPv4 is restricted by the 32 bit length and allows, in theory, for 232 different IP-addresses. In practice, the number of addresses is essentially smaller because of sub-optimum address organization. Opposed to that, IPv6 allows for 2128 different IP-addresses and therefore can cope better with the ever increasing demand for IP-addresses. Header Simplicity The IPv4-header contains many more different fields than the IPv6-header. These fields need to be evaluated and partly altered by intermediate routers. The best example is the “header checksum” which changes with every hop, because the TTL-field changes with every hop. The field “IHL” Internet Header Length is no longer needed, as IPv6 uses another concept for the internet options by means of Add-On Headers. All IPv4 header fields related to fragmentation have been moved to an Add-on header in IPv6 Use of “Next Headers” In IPv6, many conditional functions and information elements like security, mobility or fragmentation have been relayed in the optional “Next Header” section. This way, those information elements are only present if actually needed. [RFC 791, RFC 2460]




TThhee IIPPvv66 PPrroottooccooll FFoorrmmaatt




TThhee IIPPvv66 PPrroottooccooll FFoorrmmaatt With the increasing transmission and processing speed of today’s networks and the request for multimedia data streams, functional enhancements over the existing Internet Protocol (IP) have been required. The first draft specification has been published by the IETF in 1995 known as next generation IP (IPng). This specification was turned into a standard in 1996, known now as Internet Protocol Version 6 (IPv6). One additional major driving force for this standard was the limited address range of IPv4 which didn’t follow the explosive growth of the Internet and the private networks connected to it. The IPv6 header has a length of 40 octets and is described in detail on the following page. Beside the IPv6 header there may be none, one or several extension headers, most of them of variable size. The length of an extension header is always a multiple of 8 octets. If extension headers are included then the sequence below shall be as followed: Hop-by-Hop Options Header This header includes optional information that must be examined in every node along a packet’s delivery path. Currently there are only two padding options defined. The presence of this header is indicated by a zero value in the next header field in the IPv6 header Destination Options Header This optional information has to be examined only by the packet’s destination node. The header is identified by a value of 60hex in the preceding next header field. Again, only two padding options are actually defined. When there are options included that are to be processed by the first destination plus destinations listed in the routing header then this header shall follow immediately the hop-by-hop options header. When there are options to be processed only by the final destination of the packet then the header will be put at the last position. Routing Header Includes one or more intermediate nodes that have to be “visited” on the way to a packet destination. Header identification appears by value 43hex in the preceding next header field. Fragment Header This header is used by an IPv6 source (not by a path along router) to send a packet that is too large to fit in the path MTU of the path to its destination. A source node may divide the packet into fragments and send each fragment as a separate packet, to be reassembled at the receiver. The option is identified by the value 44hex in the preceding next header field. Authentication Header This header offers authentication service for the delivered packet. It is identified by the value 33hex in the preceding next header field. Encapsulating Security Payload Header This optional information offers encryption and authentication services. For identification the value 32hex in the preceding next header field is used. [RFC 2460, RFC 2402, RFC 2406]




TThhee IIPPvv66 AAddddrreessss TTyyppeess




TThhee IIPPvv66 AAddddrreessss TTyyppeess Anycast Addresses cannot syntactically be distinguished from Multicast Addresses. Unicast Addresses This is an identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. Multicast Addresses An identifier for a set of interfaces which typically belong to different nodes. A packet sent to a Multicast Address is delivered to all interfaces identified by that address. Anycast Addresses An identifier for a set of interfaces which typically belong to different nodes. A packet sent to an Anycast Address is delivered to one of the interfaces identified by that address.

Note, that there are no broadcast addresses in IPv6, their function is being provided by multicast addresses

Reserved Multicast Addresses FF00:0:0:0:0:0:0:0 FF01:0:0:0:0:0:0:0 FF02:0:0:0:0:0:0:0 FF03:0:0:0:0:0:0:0 FF04:0:0:0:0:0:0:0 FF05:0:0:0:0:0:0:0 FF06:0:0:0:0:0:0:0 FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0 FF09:0:0:0:0:0:0:0 FF0A:0:0:0:0:0:0:0 FF0B:0:0:0:0:0:0:0 FF0C:0:0:0:0:0:0:0 FF0D:0:0:0:0:0:0:0 FF0E:0:0:0:0:0:0:0 FF0F:0:0:0:0:0:0:0

[RFC 2373 (2)]




IIPPvv66 AAddddrreessss NNoottaattiioonn




IIPPvv66 AAddddrreessss NNoottaattiioonn care needs to be taken with shortcut forms as this colon separation is very similar to port notations. [RFC 2373, RFC 4291]




IIPPvv66 AAddddrreessss CCoonnffiigguurraattiioonn OOppttiioonnss




IIPPvv66 AAddddrreessss CCoonnffiigguurraattiioonn OOppttiioonnss The type of address configuration that is possible may be mandated by routers with the configuration of the M and O flags in ICMPv6 Router Advertisement messages. Selection of Address Configuration ⇒ Managed Address Configuration Flag (M-flag)

When set to 1, this flag instructs the host to use a configuration protocol (DHCPv6) to obtain stateful addresses. ⇒ Other Stateful Configuration Flag (O-Flag)

When set to 1, this flag instructs the host to use a configuration protocol (DHCPv6) to obtain other configuration settings such as DNS addresses or SIP configurations.




HHiigghh LLeevveell VViieeww aatt tthhee IIMMSS aanndd iittss EEnnvviirroonnmmeenntt




HHiigghh LLeevveell VViieeww aatt tthhee IIMMSS aanndd iittss EEnnvviirroonnmmeenntt The figure illustrates how an IMS is embedded into the overall network architecture and infrastructure.

Mobility Issues ⇒ Two levels of mobility need to be distinguished: 1) The macro-mobility which allows a user to register from different IP-CAN’s to the same IMS and 2)

the micro-mobility which allows a user to roam within a given IP-CAN. ⇒ In that respect, micro-mobility is a function that resides in the IP-CAN and which is provided to the user by the IP-CAN. Obviously, the availability of

micro-mobility depends on the type of access network. Inherently, only cable-free IP-CAN’s will allow for micro-mobility. ⇒ On the other hand, macro-mobility may be provided by the IMS depending on operator preferences by allowing the user to access the IMS through

different types of IP-CAN’s.

Relationship to other Networks ⇒ The IMS takes on the role of a mediator between the user terminal on one side and the services on the other side. Services are provided by “other

networks” which include heterogeneous networks like the PSTN, other IMS’s or stand-alone application servers in an “Applications & Services” network cloud.

⇒ As illustrated in the figure, the IMS will mandatorily interconnect to various other networks but support for different access networks is optional.

User Terminals ⇒ The range of user terminals is wide and includes legacy analog telephones as well as multi-mode PDA’s, supporting various different IP-CAN’s. This

depends on customer preferences and on the operator type ( fixed line telephone companies need to slowly migrate their analog users to the new world and therefore they need to support these analog user terminals at least medium term).

⇒ In that respect, the type of user terminal also determines or limits the service types that a particular user is able to access. Obviously, an analog PSTN-terminal is unable to support video calls or instant messaging.




WWhhaatt iiss tthhee IIMMSS??

• The IMS allows the network operator to structure all IP-based service delivery and network control functions under one umbrella That is, the IMS defines the set of network control nodes and, more importantly, the way they interwork to accomplish these functions.

• With respect to the previous bullet: Network control also relates to functions like access to the network, billing, authentication and media encryption

• Network access control has a notion of mobility management as the IMS is aware of a client’s presence and location That is, the clients may register to “their” IMS from different access networks.

• The IMS has originally been developed by the 3GPP for use in mobile networks Nowadays, the IMS has been adopted also by fixed telecom operators and others to take care of the aforementioned functions




WWhhaatt iiss tthhee IIMMSS?? • The IMS allows the network operator to structure all IP-based service delivery and network control functions under one

umbrella IP-based services represent a wide range of service like for instance fast internet access, video on demand, instant messaging or telephony. This list is certainly not exhaustive.

• With respect to the previous bullet: Network control also relates to functions like access to the network, billing, authentication and media encryption

• Network access control has a notion of mobility management as the IMS is aware of a client’s presence and location • The IMS has originally been developed by the 3GPP for use in mobile networks




IInnvvoollvveedd SSttaannddaarrddss OOrrggaanniizzaattiioonnss




IInnvvoollvveedd SSttaannddaarrddss OOrrggaanniizzaattiioonnss 3GPP The 3rd Generation Partnership Project is the major player in the definition of 3rd generation mobile communication systems. 3GPP signs responsible for UMTS and is also the inventor of the IMS to allow the migration of the mobile environment towards an IP-based session control.

3GPP2 Mainly driven by US-organizations, 3GPP is responsible for the standardization of cdma2000 as alternative to UMTS. 3GPP2 adopted the IMS from 3GPP and tailors it towards the specific network architecture requirements of cdma2000-based networks.

TISPAN The “Telecoms & Internet converged Services & Protocols for Advanced Networks” working group has been setup within ETSI for tailoring the IMS for NGN’s in the fixed network domain. One important predecessor of TISPAN within ETSI is definitely TIPHON (Telecommunications and Internet Protocol Harmonization Over Networks). Since TISPAN is dominated by European telecom operators, the North American telecom operators setup a similar working group called ATIS (Alliance for Telecommunications Industry Solutions). Note that TISPAN leaves all standardization work of the IMS itself fully to 3GPP and solemnly focuses on issues like fixed line access and registration.

CableLabs Yet another organization involved in IMS standardization and adoption is CableLabs. As the name suggests, the playground of CableLabs’ are the TV-cables, either coaxial or fiber. These obviously high performance access links can serve very well to provide IMS-controlled services to end users.

DSL-Forum The focus of the DSL-forum is obvious. Like the aforementioned organizations, the DSL-forum targets at the adoption and adaptation of the IMS to the requirements of their specific clientele. This clientele can be found within ISP’s and fixed line telecom operators.




TThhee 33GGPPPP--VVeerrssiioonn ooff tthhee IIMMSS

• Introduction …

… It was the 3GPP that initially defined the IMS as service delivery platform based on SIP as peer communication protocol towards subscribers

… Focus of 3GPP are obviously IP-CAN’s which are supported by the 3GPP-recommendations This relates namely to (E)GPRS and UTRA but also to UMA, WLAN/WiFi and WIMAX.

… All 3GPP-IMS compliant user devices are and need to be equipped with an ISIM or at least a SIM or USIM The presence of a hardware subscriber identity module allows for the use of subscriber related symmetric keys to be used for authentication and encryption.




TThhee 33GGPPPP--VVeerrssiioonn ooff tthhee IIMMSS Introduction

• It was the 3GPP that initially defined the IMS as service delivery platform based on SIP as peer communication protocol towards subscribers The IMS was included first in the Rel. 5 series of specifications.

• Focus of 3GPP are obviously IP-CAN’s which are supported by the 3GPP-recommendations Only Rel. 6 and 7 allow for other IP-CAN types than (E)GPRS, UTRA or UMA. This freedom was not part of Rel. 5. Namely WLAN/WiFi is mentioned as alternative radio access technology / IP-CAN with Rel. 6 and Rel. 7 (e.g Annex D of 3GTS 24.229 “Use of I-WLAN …”). Still, there are many issues like NAT- or IP-version Interworking if the IMS shall interoperate with arbitrary access networks.

• All 3GPP-IMS compliant user devices are and need to be equipped with an ISIM or at least a SIM or USIM The statements on the graphics page require some more explanation: ⇒ The provision of a SIM-card to the subscriber and the availability of the related smart card slot in every mobile device allow a subscriber to identify

himself/herself in every situation and it allows the operator to authenticate and authorize a subscriber whenever desired. ⇒ Without hardware SIM-card, authentication/encryption can be device-based through hard-coded configuration data (e.g. symmetric keys) or they can

be based on some kind of public key confidentiality (e.g. X.509-certificates).




AArrcchhiitteeccttuurraall OOvveerrvviieeww ((NNeettwwoorrkk PPeerrssppeeccttiivvee))




AArrcchhiitteeccttuurraall OOvveerrvviieeww ((NNeettwwoorrkk PPeerrssppeeccttiivvee)) The figure intentionally simplifies the perspective. In that respect, the circuit-switched core network domain has been completely neglected. The reason for this is the focus on the IMS (which exclusively accesses the UE’s through the packet-switched domain) and the emphasis on the difference between the IMS-solution in 3GPP-based networks and others which we will present later in this sequence.

Note that the GGSN needs to be expanded to a PDG (Packet Data Gateway) before a WLAN- or WIMAX-based IP-CAN can be connected to it.

[3GTS 23.221]




AAnndd wwhhaatt iiss iinnssiiddee tthhee IIMMSS??




AAnndd wwhhaatt iiss iinnssiiddee tthhee IIMMSS?? The IMS is entirely based on IP as transport protocol. It therefore hosts IP-driven servers of which the majority uses SIP (Session Initiation Protocol) to communicate internally and externally. These servers are SIP-servers. Still, other protocols are also used within the IMS. Other network elements within the IMS are media gateways. [3GTS 23.228]




TThhee PPeerrssppeeccttiivvee ooff tthhee 33GGPPPP--UUsseerr AAggeenntt (( MMoobbiillee SSttaattiioonn))




TThhee PPeerrssppeeccttiivvee ooff tthhee 33GGPPPP--UUsseerr AAggeenntt (( MMoobbiillee SSttaattiioonn)) ⇒ The figure illustrates in sufficient detail the complexity of a multi-mode mobile station to use the IMS as peer. Again, focus of any 3GPP-compliant UA

( mobile station) will be the support for 3GPP-endorsed access networks like GERAN, UTRAN or UMAN. Still, this does neither preclude mobile vendors nor network operators to allow a mobile station access to the network operator’s IMS also through e.g. a generic IEEE 802.11 radio access network.

⇒ The figure emphasizes the protocol stack of such a mobile station. ⇒ Note that despite of all its complexity, the figure still suppresses many complications like the possible need for dual-stack IP-operation (IPv4 and IPv6)

or the detailed protocols within the GERAN, UTRA-FDD and UMAN “black boxes”.

In that respect it is noteworthy that the GERAN- and UTRA-FDD-boxes in this new environment have become little more than modems.




OOvveerrvviieeww ooff tthhee ootthheerr IIMMSS--AApppprrooaacchheess • TISPAN




OOvveerrvviieeww ooff tthhee ootthheerr IIMMSS--AApppprrooaacchheess TISPAN The figure illustrates the TISPAN-adaptation of the genuine IMS-approach. Most importantly, TISPAN adds the network clouds PES, RACS and NASS to the original IMS.

The functions of the RACS are: ⇒ Admission Control ⇒ Resource Reservation ⇒ Policy and QoS Control ⇒ NAT-Identification and Provision of NAT-Traversal The functions of the NASS are: ⇒ IP-Address Allocation to UE’s ⇒ User Authentication and Service Authorization The function of the PES is: ⇒ The emulation of PSTN/ISDN-like services to legacy user equipments that are interconnected to the IP-based PES through gateways.

[ETSI TS 181 005: “Service and Capabilities Requirements for TISPAN NGN; Release 1”, ETSI TS 282 001: “NGN Functional Architecture Release 1”, ETSI TS 282 002: “TISPAN; NGN: Functional architecture for PSTN/ISDN Emulation”, ETSI TS 282 003: “NGN RACS”, ETSI TS 282 004: “NGN NASS”]

Abbreviations: DSLAM: ____________________________________________________________________ NASS: ______________________________________________________________________ PDBF: ______________________________________________________________________

PES: _______________________________________________________________________ RACS: _____________________________________________________________________




SSoommee RReemmaarrkkss oonn tthhee TTIISSPPAANN NNGGNN--SSoolluuttiioonn • TISPAN views the IMS only as an important portion of its overall NGN-

Architecture TISPAN adopted the IMS from 3GPP “as is” and added specific network clouds for network attachment (NASS) and resource allocation control (RACS).

• The target of the TISPAN IMS is to provide multimedia and PSTN/ISDN-like services Currently, TISPAN’s access network focus is on DSL-lines but obviously, the vast majority of subscribers will be connected through analog copper cables, using their legacy telephones.

• TISPAN and 3GPP cooperate in the expansion of the genuine IMS-definition to allow all kinds of IP-CAN’s In that respect, TISPAN leaves all IMS-related specification changes to 3GPP. TISPAN only formulates their requirements.




SSoommee RReemmaarrkkss oonn tthhee TTIISSPPAANN NNGGNN--SSoolluuttiioonn • TISPAN views the IMS only as an important portion of its overall NGN-Architecture

The RACS and the NASS complement the packet-switched core network functions which are inherently there in a 3GPP-solution.

• The target of the TISPAN IMS is to provide multimedia and PSTN/ISDN-like services The final statement on this bullet on the graphics page illustrates that TISPAN needs to take into account completely different issues than 3GPP. Legacy customer telephones will neither support multimedia services nor fancy features like authentication. Still, they require some gateway function because otherwise they cannot be interconnected to the NGN.

• TISPAN and 3GPP cooperate in the expansion of the genuine IMS-definition to allow all kinds of IP-CAN’s Note that TISPAN does not mandate the use of IPv6 in their IMS and towards their user equipments. They explicitly allow for the use of IPv4.

???? Question Section 1 ???? ⇒ Why is TISPAN’s initial focus on DSL as access network solution and not on IMS-based service provision for legacy telephones (POTS)?




33GGPPPP22




33GGPPPP22 The figure illustrates how 3GPP2-based mobile networks shall deploy the IMS to provide multimedia services to subscribers that use 3GPP2-based radio access networks like cdma1 and cdma2000.

[3GPP2 X.S0013-000-A; “All-IP Core Network Multimedia Domain / Overview”, 3GPP2 X.S0013-002-A; “All-IP Core Network Multimedia Domain / IP Multimedia Subsystem – Stage 2”]

Abbreviations: PDS: _______________________________________________________________________

PDSN: ______________________________________________________________________




SSoommee RReemmaarrkkss oonn tthhee 33GGPPPP22 IIMMSS--SSoolluuttiioonn

• In 3GPP2, the IMS is called MMD (Multimedia Domain) Still, the IMS logical architecture is entirely adopted from 3GPP.

• The most important differences between 3GPP and 3GPP2 are: ⇒ No HSS is used in 3GPP2-IMS but rather an AAA-server because the (U/I)SIM is not mandatory within 3GPP2-UE’s. ⇒ Since there is no GGSN in the 3GPP2-architecture, the PEF (Policy Enforcement Function) needs to be a standalone network element or it needs to be functionally integrated into the Mobile IP Home Agent. ⇒ 3GPP2 relaxes the requirement on the IP-version: Explicitly, IPv4 is allowed not only intermediately but as standard.

• In general, 3GPP2 tries to reuse as many existing procedures and protocols as possible without adjustment The emphasis is on “without adjustment”. Opposed to 3GPP2, 3GPP tailors even IP-based protocols to provide for an optimum operation.




SSoommee RReemmaarrkkss oonn tthhee 33GGPPPP22 IIMMSS--SSoolluuttiioonn • In general, 3GPP2 tries to reuse as many existing procedures and protocols as possible without adjustment

An obvious example is the lacking definition of a specific GGSN in 3GPP2. They rather use the generic concept of Mobile IP to allow a subscriber to roam around and to attach to their packet-switched core network.




CCaabbllee LLaabbss




CCaabbllee LLaabbss ⇒ Cable TV operators use a completely different access network type towards their subscribers than what we presented so far: Their access networks

are based on either coaxial copper cables or on fiber that they distributed towards residential customers. ⇒ As illustrated, the genuine use of cable TV is based on broadcast transmission towards those residential customers and there is no cable modem

required in this case. ⇒ Only the use of telephone services or advanced VoD- or fast internet access services requires the provision of a cable modem at the customer

premises. This is usually no issue since the cable modem is plugged into the existing coaxial network like a TV or VCR. ⇒ At the other end of the HFC-network (Hybrid Fiber Cable) there is a cable modem termination system that bridges the IP-based traffic into a cable TV

operator owned IP-network. ⇒ It is noteworthy that cable TV operators are actively marketing their networks also for telephone services. Accordingly, they do already have soft

switches in their networks already. These existing “kernels” need to be expanded into an IMS-solution in the next step. [http://www.cablemodem.com/specifications/specifications20.html]




DDSSLL FFoorruumm




DDSSLL--FFoorruumm We illustrate the DSL-forum’s efforts mainly from the perspective of ISP’s. Still, the DSL-forum’s work also pertains to regular telecom operators who want to use their 2-wire copper cables for broadband service provision.

⇒ As the figure shows, the ISP’s premises are usually behind the telecom operator’s DSLAM and IP-network. ⇒ Similarly to cable TV operators, some ISP’s already compete against the telecom operators for POTS and therefore these ISP’s already have some

soft switches available. These need to be expanded into an IMS within the next years, if the ISP wants to move on to become an integrated services network operator.

Note that we included an alternative WIMAX-based access network which is particularly interesting for the ISP as competitor of the telecom operator. Although apparently WIMAX has nothing to do with DSL it is frequently called “Wireless DSL” and it allows specifically the ISP to become independent from the telecom operator.

[http://www.dslforum.org/index.shtml]




PPeerrffoorrmmaannccee FFiigguurreess ooff tthhee DDiiffffeerreenntt IIPP--CCAANN’’ss




PPeerrffoorrmmaannccee FFiigguurreess ooff tthhee DDiiffffeerreenntt IIPP--CCAANN’’ss UTRAN 14.4 MBit/s indicates the maximum throughput rate in UTRAN, if HSDPA is used under ideal radio conditions and almost the entire cell is dedicated to one UE. This throughput rate is downlink only and cannot be achieved in uplink direction. The maximum in uplink would be 5.76 MBit/s with HSUPA.

GERAN 360 kbit/s stem from using EGPRS with 59.2 kbit/s per timeslot and six timeslots being used by a single mobile station. Similarly to UTRAN, this throughput rate is downlink only and cannot be achieved at the same time in uplink direction.

WLAN / WiFI The “b”, “a/g” and “n” indicate the different IEEE 802.11 variants and their performance figures. Most impressive is IEEE 802.11n with a targeted maximum throughput rate of 480 MBit/s using MIMO-technology. Compared to all other IP-CAN technologies presented on this page, WLAN/WiFi is a short range radio technology that is most suitable for cable less in-home and in-house signal distribution.

WIMAX The IEEE 802.16 standard is very appealing as it combines a very high throughput rate with long range and mobility. But even without mobility, WIMAX is very appealing as DSL-replacement or alternative.

cdma2000 The figure indicates the maximum throughput rate of 1xEV-DV (Evolution Data and Voice). Like UTRAN and GERAN, cdma2000 offers full mobility.

CableTV This first cable-based IP-CAN technology already fully exploits and demonstrates the superiority of wired technologies with respect to throughput rate. CableTV easily offers and achieves a throughput rate of 100 MBit/s in downstream direction and sufficient throughput rates in upstream.

xDSL Like CableTV, DSL is a wired technology and with VDSL, a throughput rate of 100 MBit/s becomes realistic. However, VDSL is a short range technology with ranges of less than 1000 m. But even at longer range, the ADSL2+ technology offers throughput rates of 25 MBit/s.




((11)) SSuummmmaarryy && CCoonncclluussiioonnss • Chances of the Different Players

Telecom Operator: (1) Excellent Subscriber Base, (2) excellent access means towards the users, (3) perceived as reliable service provider, (4) maybe too slow and to big for the new age?. Mobile Telecom Operator: (1) Excellent Subscriber Base, (2) reasonable access means towards the users with additional mobility, (3) perceived as reliable service provider, (4) a lot of momentum from the past 15 years. CableTV Operator: (1) Reasonable Subscriber Base, (2) excellent access means towards the users, (3) perceived as reliable service provider for entertainment services, (4) not well experienced in the telecom world. ISP: (1) Insufficient Subscriber Base, (2) no own access means towards the users, (3) perceived as plain bitpipe provider and internet content provider, (4) usually young staff with lots of ideas to be channelized.




((11)) SSuummmmaarryy && CCoonncclluussiioonnss Chances of the Different Players Telecom Operator Mobile Telecom Operator CableTV Operator ISP




((22)) SSuummmmaarryy && CCoonncclluussiioonnss • Wireless vs. Wireline Technologies

The throughput rates of wired systems will always be superior to wireless technologies of the same generation, if the same physical technologies are applied.

• Cell Performance vs. User Performance Wireline technologies usually communicate the “real” throughput rate per user line while wireless technologies tend to communicate the throughput rate per cell.

• Conclusion: “Bandwidth” and “Access to the Customer” is all that matters Of course, the not so obvious effects of perception within the market and momentum must not be neglected.




((22)) SSuummmmaarryy && CCoonncclluussiioonnss Wireless vs. Wireline Technologies It is like the older rabbit / turtle race: Whenever the wireless standards have advanced to yesterday’s wireline throughput rates, these wireline technologies already apply the same state-of-the-art physical achievements in forward and backward error correction, receiver sensitivity and, in general, in C/I-requirement and therefore get higher throughput rates. Wireless technologies scored in the past 15 years predominantly through the value added asset of mobility which inherently could not be offered by wireline technologies. Still, through the IMS at least nomadic use becomes realistic also with wireline technologies.

Cell Performance vs. User Performance The throughput rate per cell is a resource that all subscribers currently served by that cell need to share. This compromises the performance of wireless technologies essentially and hinders the provision of high definition video transmission through wireless technologies.

Conclusion: “Bandwidth” and “Access to the Customer” is all that matters In that respect it is very important to own the access network resource. Please consider the ISP that depends on the competitor’s access network (DSL). How shall such an operator type be successful in the long run?




TThhee SSeerrvviiccee PPeerrssppeeccttiivvee ooff tthhee IIMMSS




TThhee SSeerrvviiccee PPeerrssppeeccttiivvee ooff tthhee IIMMSS Service Types and Service Enablers The figure illustrates the different types of services to be offered through the IMS. The only exception to this rule is “Fast Internet Access” which is the inherent service domain of ISP’s but which does not require an IMS as mediator or service controller. On the other hand, fast internet access is the necessary precondition for all operator types (ISP, telecom operator, cable TV operator) who want to use the IMS as service delivery platform. In that respect, it also becomes a new service for all operator types except ISP’s. Service enablers are functionalities that could be considered as implicit services. One important example is fixed mobile convergence which is not really a service by itself but rather enables new services.




CCoonnvveerrssaattiioonnaall SSeerrvviicceess




CCoonnvveerrssaattiioonnaall SSeerrvviicceess Conversational services are the domain of telecom operators. Please note that the telecom operator may be a regular one or a mobile network operator.

Two-Party Audio Calls As illustrated, this service type also contains PoC, because PoC is no longer a proprietary service when offered through the IMS.

Multiparty Audio Calls The bullet is colored partly yellow because the conduction of multiparty calls becomes much more common, inherent and easy to use with the IMS.

Call-Related Supplementary Services Any IMS-solution has to continue offering the legacy call-related supplementary services like caller representation, call on hold or call forwarding. However, the IMS will add new call-related supplementary services like “black lists” for callers or simultaneous forking.

Multimedia Calls Through the IMS, the setup and selection of video calls will be simplified (although video calls have been around for quite some time). In addition, the IMS offers the combination of more media types than just audio + video. For instance, a service offering may combine audio + whiteboard + instant messaging to provide for advanced audio conferencing.

Non-Real Time Messaging This bullet is colored partly yellow because some form of non-real time messaging has been there also prior to the IMS. However, SMS is (usually) a new service type for wireline telecom operators and definitely the famous e-mail push service is new.

Instant Messaging Instant messaging has become an important means to communicate but it is a new type of service for telecom operators (both fixed and mobile).

Chat Rooms The same applies what was said for instant messaging.

Please note the remarks on the right hand side of the graphics page. The color for new and legacy services only applies for telecom operators but not necessarily for other operator types, offering triple play services. One example is instant messaging which is a new service for telecom operators but which definitely is a legacy service from the perspective of ISP’s.




AAuuddiioovviissuuaall EEnntteerrttaaiinnmmeenntt SSeerrvviicceess




AAuuddiioovviissuuaall EEnntteerrttaaiinnmmeenntt SSeerrvviicceess Audiovisual entertainment services are the domain of cable TV operators.

TV Broadcast TV broadcast is the core business of cable TV operators. It relates to both, public and pay TV stations.

Radio Broadcast The same applies as to TV broadcast

Video on Demand (VoD) Opposed to TV broadcast, VoD is a point to point service. Customers select a certain movie from a list and start it at an arbitrary time. They can interrupt the service for instance to accept an incoming phone call and they will be charged per movie.

Audio on Demand (AoD) The same applies as for VoD.

Gaming Gaming is a very promising entertainment service. This applies for both variants: Variant 1 allows for two ore more individuals to play against each other and in variant 2 an individual is challenged by a computer. Online gaming is could be the next step of video gaming. The IMS offers gaming service providers an excellent and reliable mediation service to their customers in addition to CD’s and DVD’s.




SSeerrvviicceess EEnnaabblleerrss




SSeerrvviiccee EEnnaabblleerrss The new service types with the IMS have been illustrated on the previous slides. In addition, we need to consider the service enablers which are provided by the IMS. These are no services by themselves but they enable new services.

Fixed Mobile Convergence (FMC) FMC becomes possible with the IMS because subscribers register their availability to the registrar ( S-CSCF) within the IMS. Whether they do this from a fixed user equipment device or from a mobile device or both is arbitrary. This will change the way how we communicate and it will therefore offer a whole bunch of new services.

Presence Similarly to FMC, presence is not a service by itself but it enables new services. For example, presence allows for fleet management services that many companies are quite interested in and if combined with location based services, presence becomes even more interesting.

The final bullet contains question marks. Certainly, our list is not exhaustive and definitely there are many yet unrevealed new services and service enablers. It is a good time for entrepreneurs!




TTrriippllee PPllaayy aanndd QQuuaaddrruuppllee PPllaayy

• Initial Situation




TTrriippllee PPllaayy aanndd QQuuaaddrruuppllee PPllaayy Initial Situation Cable-TV Operators Historically, cable TV operators have been focusing on the provision of audio visual entertainment services through their HFC-infrastructure (Hybrid Fiber- / Coaxial-cable). The business model was originally based on broadcast services like television and standard radio exclusively. This explains two inherent assets of cable TV operators: They frequently lack capacity in the upstream direction (from user to network) and they prefer flat rate charging models.

Telecom Operators The genuine business of telecom operators is the provision of conversational services to clients. The dominant conversational service always has been plain voice telephony. The telecom operators are historically the oldest operator type shown here: They are around since about 100 years. It was only one or two decades ago that market liberalization encouraged the spin off of mobile telecom operators and the foundation of new and independent fixed and mobile telecom operators with more or less market success.

Internet Service Provider Historically, the ISP is the “new kid on the block” compared to the two other types of operators. Originally, the exclusive business of the ISP was interfacing residential and business customers to the internet or even making these customers part of the internet. In that respect, the majority of customers (at least almost all residential customers) were interconnected to the internet through dial-up modem connections that required the presence of a telephone line which however is owned by the telecom operator. Basically, this is still true although many if not most residential users today use DSL over their telephone lines to interconnect to their ISP. Still, the disadvantage remains: ISP’s usually suffer from the lack of an independent access network between themselves and their customers. This is a serious drawback when it comes to the chances of becoming a successful triple-play-services provider. Note that ISP’s started out very early (with the advent of DSL) to encourage or at least allow their customers to use VoIP to experience cheaper telephone calls. In that respect, ISP’s were the first ones to cannibalize part of the business of another type of operator.




TTrriippllee PPllaayy




TTrriippllee PPllaayy The term “Triple Play “ represents nothing else but the fact that every operator type is now able to offer all three ( “triple”) types of service to their customers. Basically, “Triple Play” is enabled by the fact that all three operator types already migrated or at least can migrate to an all-IP-based transport network. And IP has been equipped to suit all potential applications: 1. Audiovisual entertainment services in point-to-point, multicast or broadcast form 2. Conversational services like telephony, messaging or video telephony. Fast internet access is the inherent service and application that can be offered.




QQuuaaddrruuppllee PPllaayy




QQuuaaddrruuppllee PPllaayy The term “Quadruple Play” is younger than the term “Triple Play”. It simply relates to the fact that a mobile telecom operator is also able to offer triple-play services with the amendment of mobility as 4th service to the user.

Note that at the end of the day the red bubble in the bottom may refer to any operator type with a mobile access network at their disposal. This statement is a thread for mobile telecom operators at relates to the advent of WLAN/WiFi/WIMAX network operators.




CCoonncclluussiioonnss

• The different standards organizations tailor the genuine IMS-core to suit the requirements of their specific clients These requirements primarily relate to the specific type of IP-CAN and scope of service.

• Properly implemented and upgraded, the IMS allows any type of operator to threaten the business models of the other operator types For instance, cable TV operators may (through the IMS) not only offer new entertainment services like VoD but also conversational services like telephony or other services like fast internet access.

• The different types of IP-CAN’s offer an essentially different performance in terms of throughput and QoS Both Characteristics throughput and QoS are crucial for the success of an operator’s business model on the IMS.

• Most likely, operators of different type will sign roaming agreements to allow users to access services through the other operators’ IP-CAN A typical example is the partnership between a mobile network operator and a cable-TV operator.




CCoonncclluussiioonnss • The different standards organizations tailor the genuine IMS-core to suit the requirements of their specific clients

That means that at the end of the day there will be different types of IMS’s,

• Properly implemented and upgraded, the IMS allows any type of operator to threaten the business models of the other operator types Please recall from the presentation of services that the IMS provides for or at least eases the implementation of many services n the area of audiovisual entertainment and conversation.

• The different types of IP-CAN’s offer an essentially different performance in terms of throughput and QoS It is obviously favorable to be inherently able to offer the highest throughput rates. This applies particularly to cable TV operators who can provide the broadest pipeline to their customers.

• Most likely, operators of different type will sign roaming agreements to allow users to access services through the other operators’ IP-CAN




PPrraaccttiiccaall EExxeerrcciissee::

• Please fill in the missing node, network and domain names Consider the constraints listed on the text page to resolve the issue.

s




Inter IP-CAN Roaming (Practical Exercise)

• The mobile device in (1) is equipped with a WLAN-transceiver. It needs to register to the IMS in (4) but the only IP-CAN available is the combination of the residential WLAN with the cable TV network in (2)

• Please fill in the missing links and the names of the different network nodes, network clouds and the domain names (e.g. domain 2 = “domain of cable TV operator”) to allow the mobile device registering to the IMS.

Notes:

???? Question Section 2 ???? ⇒ Who will allocate the IP-address to the mobile device? Please mark the potential “points of attachment” with a red cross and consider the different

aspects of the different configuration possibilities.




DDeessccrriippttiioonn ooff tthhee IIMMSS--NNeettwwoorrkk AArrcchhiitteeccttuurree • Overview




DDeessccrriippttiioonn ooff tthhee IIMMSS--NNeettwwoorrkk AArrcchhiitteeccttuurree Overview The figure illustrates a simplified IMS (IP Multimedia Subsystem) in its environment. Focus is on the 3GPP-version of the IMS as we also included the HSS which is 3GPP-specific. The term “simplified” in the previous sentence means that not all internal relations and network elements within the IMS have been included. With respect to the IMS-architecture please note the following: ⇒ P-CSCF and the other X-CSCF’s represent SIP-servers with different functions. In that respect, the P-CSCF is the interface of the IMS towards user

equipments (e.g. mobile stations). ⇒ The PDF is used for policing (QoS). ⇒ The MRFC and MRFP are used for announcements towards subscribers (e.g.”This user is currently not reachable.”) ⇒ BGCF, MGCF and MGW are required for PSTN-interworking. ⇒ There is no requirement that each logical node (X-CSCF, PDF, …) is represented by a separate physical node. ⇒ The Gm-interface between the UE and the P-CSCF is obviously a virtual interface that is physically realized through the packet-switched core network

domain and the respective access network.

[3GTS 23.002, 3GTS 23.228]

Abbreviations (please fill in): P-CSCF: ____________________________________________________________________ X-CSCF: ____________________________________________________________________ PDF: _______________________________________________________________________ ISC-Interface: ________________________________________________________________ BGCF: ______________________________________________________________________

HSS: _______________________________________________________________________ MGCF: _____________________________________________________________________ MRFC: _____________________________________________________________________ MGW: ______________________________________________________________________




DDeettaaiilleedd VViieeww




DDeettaaiilleedd VViieeww The figure illustrates in more detail which protocol is used on which interface. Please note the respective color codes. Note also that the orange colored interfaces can be used for any user data protocol (RTP, SRTP or RTSP) as mentioned on the previous slide.




PP--CCSSCCFF ((PPrrooxxyy CCaallll SSeessssiioonn CCoonnttrrooll FFuunnccttiioonn)) Tasks & Functions

• Represents the peer and the first point of contact within the IMS towards the User Equipment All SIP-signaling from and to the UE that is IMS-related traverses the P-CSCF.

• Compresses the SIP-Signaling to the User Equipment If configured and most useful for mobile user equipments ( 3GPP)

• Relays SIP-Signaling towards the other CSCF’s within the IMS Note that these SIP-messages will never be compressed.

• Authenticates the User Equipment The P-CSCF is a mediator that receives authentication quintuplets from the S-CSCF and relays the challenge to the UE. The P-CSCF also relays the response back to the S-CSCF.




PP--CCSSCCFF ((PPrrooxxyy CCaallll SSeessssiioonn CCoonnttrrooll FFuunnccttiioonn)) Tasks & Functions

• Represents the peer and the first point of contact within the IMS towards the User Equipment Unlike a plain SIP-proxy server, the P-CSCF shall be able to autonomously initiate and release SIP-dialogs. This means that the P-CSCF represents at least a B2BUA. The release of an ongoing session may be triggered by the reception of a related request from the PEP (Policy Enforcement Point), e.g. the GGSN that IP-CAN service (e.g. radio coverage) was lost.

• Compresses the SIP-Signaling to the User Equipment Compression is done according to SigComp [RFC 3320] which typically applies predefined libraries to compress SIP-signaling.

• Relays SIP-Signaling towards the other CSCF’s within the IMS Obviously, this works both ways! That is, the P-CSCF sends and receives SIP-messages through the Mw-interface.

• Authenticates the User Equipment The authentication quintuplet consists of RAND, XRES, CK, IK and AUTN. These parameters are inherited from plain UMTS. Since the UE will not continuously exchange SIP-messages with the P-CSCF, the P-CSCF needs to maintain a database for currently registered UE’s. [3GTS 24.229 (5.1.1.5), 33.203 (6), RFC 3310]

[3GTS 23.228 (4.6.1)]




TTaasskkss && FFuunnccttiioonnss ((ccoonnttiinnuueedd))

• Performs Policy Control towards the IP-CAN In the generic policy architecture, the P-CSCF is called AF (Application Function) which relates the session control signaling to bearer policy control messaging (COPS, DIAMETER).

• Establishes and maintains two Security Associations towards the User Equipment SA’s are established during the authentication process and solemnly serve the integrity protection of the SIP-messages between UE and P-CSCF. There is no encryption of SIP-messages.

• Incorporates an IMS-ALG if IP-version or NAT Interworking towards the User Equipment or media stream observation is necessary This optional IMS-ALG function is a Rel. 7 extension of the P-CSCF. In that case, the IMS-ALG within the P-CSCF controls a TrGw or IMS-AG which intercepts the media stream.




TTaasskkss && FFuunnccttiioonnss ((ccoonnttiinnuueedd)) • Performs Policy Control towards the IP-CAN

Policy control relates to communication among P-CSCF and PDF on one hand and PDF and PEP on the other hand. We will illustrate in more detail how this is done in a few slides [3GTS 29.207, 3GTS 29.208, 3GTS 29.209].

• Establishes and maintains two Security Associations towards the User Equipment [3GTS 33.203 (7)]

• Incorporates an IMS-ALG if IP-version or NAT Interworking towards the User Equipment or media stream observation is necessary ⇒ At least in Rel. 7, the IP-version Interworking is considered the major function of the IMS-ALG / TrGW network nodes. Most interestingly, the

specification is not even stable enough yet to determine whether the so called IMS-AG (Access Gateway) can be the same as the TrGW which is used at the other edge of the IMS at the I-CSCF and S-CSCF [3GTS 23.228 (5.18, Annex G)].

⇒ Yet another option is to incorporate the TrGw- / IMS-AG into the P-CSCF and therefore upgrade the P-CSCF from a B2BUA to an SBC. [3GTS 23.228 (4.6.1), 3GTS 24.229 (5.2)]




TTyyppiiccaall UUssee CCaasseess




TTyyppiiccaall UUssee CCaasseess The figure illustrates the P-CSCF, operating in its environment. The figure also illustrates, which protocols are applied on which interfaces. Note that on the Go-interface, COPS is used and on the Gq-interface, DBP is used. The following slides illustrate the operation of the P-CSCF in more detail. [3GTS 24.229 (5.2), (6.2)]




PP--CCSSCCFF IInnvvoollvveemmeenntt dduurriinngg RReeggiissttrraattiioonn




PP--CCSSCCFF IInnvvoollvveemmeenntt dduurriinngg RReeggiissttrraattiioonn ⇒ The figure illustrates the subscriber registration with authentication which is invoked by the S-CSCF. Most importantly, we use two additional colors to

emphasize the flow of IPsec- and authentication related information among the different network elements. ⇒ The MS/UE initiates the process by sending a Request: REGISTER-message to the P-CSCF. This message contains private and public user identities

(IMPI and IMPU) and it includes in the header field “Security-Client:” IP-sec related information like the SPI (Security Parameters Index / 32 bit) and the secure port number (e.g. port number 1357 but definitely not 5060) at which the MS/UE wishes to receive IPsec-protected SIP-messages.

⇒ The P-CSCF forwards the registration attempt through possibly various other SIP-proxies towards an S-CSCF in the IMS within the H-PLMN of this subscriber. During initial registration, there will be at least an I-CSCF to select the very S-CSCF to take on the registration of that subscriber.

⇒ The S-CSCF uses DIAMETER and the subscriber’s IMPI to retrieve authentication quintuplets from the HSS of this subscriber. Accordingly, the HSS provides an arbitrary number (4 - 5) of authentication quintuplets to the S-CSCF.

⇒ The S-CSCF selects one quintuplet and base64-encodes the indicated parameters (most importantly RAND, AUTN and IK) into the Response: 401-Unauthorized message. This message finds its way back to the P-CSCF.

⇒ The P-CSCF adds a new header field “Security-Server:” and puts its own IP-sec related information inside. This information includes most importantly the port number at which the P-CSCF will now be ready to receive IPsec-protected information from this MS/UE.

Please note that the P-CSCF will only accept unprotected REGISTER-requests on SIP’s default port number 5060.

⇒ The MS/UE extracts the different parameters and performs the necessary calculations to obtain RES and IK and to authenticate the network. ⇒ Now that the MS/UE has IK available it can integrity protect its next registration attempt and send it towards the P-CSCF. Note that this Request:

REGISTER will contain the base64-encoded RES-parameter and it will be sent towards the IPsec-aware port number that the P-CSCF previously conveyed to the MS/UE.

⇒ When the Request: REGISTER is received by the S-CSCF, the S-CSCF will prove that RES matches XRES and if yes, authentication is successful at both peers.

⇒ In this case, the S-CSCF will issue a Response: 200-OK that finally reaches the MS/UE on the IP-sec aware port number. This message contains a “Service Route:”-header field with the SIP-URI of the S-CSCF which is stored by the P-CSCF for future use.

Note that there are two security associations established during the aforementioned process: One for transactions which origin from the MS/UE (this one is shown) and another one for transactions that origin from the P-CSCF (not shown). Both are different but use the same IK.

[3GTS 33.203 (6), 3GTS 24.229 (5.1.1.5), (5.2.2), RFC 3310]




PP--CCSSCCFF IInnvvoollvveemmeenntt ffoorr SSeessssiioonn SSeettuupp aanndd PPoolliicciinngg • Step 1: Session Start




PP--CCSSCCFF IInnvvoollvveemmeenntt ffoorr SSeessssiioonn SSeettuupp aanndd PPoolliicciinngg Step 1: Session Start It is the task of the P-CSCF to authorize the use of resources within an IP-CAN. That is, the P-CSCF will upon reception of a SIP: INVITE-message from the UA (bullet 1) communicate the session establishment request onwards ( backhaul communication) but it will also communicate, possibly internally, with the PDF (Policy Decision Function). The PDF will allocate a media authorization token (bullet 2) and provide it to the P-CSCF. This media authorization token is sent back (bullet 3) to the UA through the next possible SIP-message (most likely through a provisional response message). [3GTS 29.209 (4, 5)]




SStteepp 22:: MMeeddiiaa TTuunnnneell EEssttaabblliisshhmmeenntt




SStteepp 22:: MMeeddiiaa TTuunnnneell EEssttaabblliisshhmmeenntt After the reception of the media authorization token through the UA, the SIP-client within the UA will relay this media authorization token towards the IP-CAN-specific resource reservation protocol (bullet 4). Depending on the IP-CAN, different procedures exist for the activation of the media tunnel / real-time bearer:

Note: • If the IP-CAN is an IntServ-aware network ( RFC 1633) then the protocol to reserve the real-time bearer will be RSVP. • If the IP-CAN is UTRAN- or GERAN-based, then the protocol to reserve the real-time bearer will be SM (session management) and the procedure to

be conducted will be secondary PDP-context activation, activation of a second (primary) PDP-context or modification of the existing (primary) PDP-context [3GTS 24.229 (Annex B.2.2.5)]. We will illustrate this case on the next slides.

• If the IP-CAN is WIMAX-based, then the protocol to reserve the real-time bearer will be MAC and the procedure to do it will be DSA (Dynamic Service Addition).

Note that the respective peer ( called IP-CAN specific NE in the figure) of the UA within the IP-CAN will verify the UA’s authorization to activate a real-time bearer by involving the PEP (Policy Enforcement Point) (bullet 6) which in turn will use COPS through the Go-interface (bullet 7) to get authorization approval from the PDF. Irrespective of the IP-CAN, the PEP will usually not be a separate network element but it will be integral part of some other network element. In case of GERAN- / UTRAN-based IP-CAN’s, the GGSN also includes the PEP [3GTS 29.209 (4)].




SStteepp 33:: MMeeddiiaa TTuunnnneell EEssttaabblliisshheedd




SStteepp 33:: MMeeddiiaa TTuunnnneell EEssttaabblliisshheedd The figure emphasizes the tunnel character of the real-time bearer through the IP-CAN. The figure also illustrates the independence of the X-CSCF’s from the media streams.




SStteepp 44:: PPrreeccoonnddiittiioonnss ffuullffiilllleedd // CCoonnffiirrmmaattiioonn oonn SSIIPP--LLaayyeerr




SStteepp 44:: PPrreeccoonnddiittiioonnss ffuullffiilllleedd // CCoonnffiirrmmaattiioonn oonn SSIIPP--LLaayyeerr After the real-time bearer has been established, the UE will inform the peer about the successful resource reservation procedure. The SDP-preconditions from step 1 have successfully been fulfilled. Session establishment can continue.

Which means in case of voice calls that the called party (UE or peer) may be alerted.




EExxaammppllee:: RReessoouurrccee RReesseerrvvaattiioonn iiff IIPP--CCAANN == GGEERRAANN//UUTTRRAANN




EExxaammppllee:: RReessoouurrccee RReesseerrvvaattiioonn iiff IIPP--CCAANN == GGEERRAANN//UUTTRRAANN ⇒ The figure illustrates the case when the IP-CAN of the invited party is based on GERAN or UTRAN. In this case, the Request: INVITE will contain a

media authorization token which is used by the UA / mobile station as “entry ticket” into real-time QoS. The media authorization token has previously been conveyed by the PEP (Policy Enforcement Point) to the PDF (policy decision function) upon request of the PDF. The PEP is usually part of the GGSN.

⇒ Upon reception of the Request: INVITE, the UA needs to interpret the received SDP-parameters and translate them into IP-CAN-specific QoS-parameters which in this case means 3GPP-specific QoS-parameters.

Selection of 3GPP-specific QoS-Parameters ⇒ Since the media type is audio or video rather than message, application or data the traffic class is selected with “Conversational Class”. Alternatively,

is the media stream would be marked as “sendonly” or “recvonly”, the traffic class would have been selected with “Streaming Class”. ⇒ The transfer delay is requested with 100 ms. ⇒ The SDP-parameter bandwidth “b=AS: 29” translates into “Guaranteed Bitrate” and “Maximum Bitrate” with app. 32 kbit/s (the additional bandwidth is

there to considering RTCP-reporting). ⇒ Of course there are many other QoS-parameters which are not illustrated here.

Activation of QoS-aware Media Tunnel ⇒ Completely independent from SIP, the UA / mobile station then activates a secondary PDP-context through SM-signaling messages (Session

Management). The UA / MS sends out an ACT_SEC_PDP_CT_REQ-message (Activate Secondary Packet Data Protocol Context Request) to the SGSN and upon successful PDP-context establishment it receives back an ACT_SEC_PDP_CT_RSP-message (Activate Secondary Packet Data Protocol Context Response).

⇒ As illustrated, the UA / mobile station needs to include the media authorization token into the ACT_SEC_PDP_CT_REQ-message. After reception by the GGSN, the PEP (Policy Enforcement Point) which is physically part of the GGSN will check with the PDF (Policy Decision Function) which is part of the P-CSCF whether the requested resources have really been authorized and are necessary.

⇒ For more details about PDP-context activation please refer to the INACON-book “GPRS – Signaling & Protocol Analysis (RAN & Mobile Station)”. [3GTS 23.060, 3GTS 24.008, 3GTS 29.208]




…… aanndd tthhee cchhaannggee wwiitthh LLTTEE // SSAAEE




…… aanndd tthhee cchhaannggee wwiitthh LLTTEE // SSAAEE Initial Conditions ⇒ The UE changed into ECM-CONNECTED state some time before to be able to exchange the SIP-messages with the IMS, supposedly over the

already established default EPS-bearer. ⇒ We can see the SIP-signaling inside the different pipes “EPS-bearer” and “S5-bearer”. ⇒ When the SDP-descriptors within the SIP-messages indicate that a real-time bearer is required, the P-CSCF inside the IMS will communicate with the

PCRF to authorize the QoS-request and to trigger the establishment of that real-time bearer (DIA: AAR-message). Detailed Description ⇒ Having received the DIA: AAR-message, the PCRF will trigger the PDN-GW to initiate the dedicated EPS-bearer activation procedure by sending a

DIA: RAR-message to it. DIAMETER: AAR, AAA: [3GTS 29.214] DIAMETER: RAR: [3GTS 29.212 (5.6.4)]




…… aanndd tthhee cchhaannggee wwiitthh LLTTEE // SSAAEE ((ccoonntt..))




…… aanndd tthhee cchhaannggee wwiitthh LLTTEE // SSAAEE ((ccoonntt..)) Detailed Description ⇒ The PDN-GW will send a GTP: Create-Bearer-Request-message to the S-GW. This message contains, among others, the “linked bearer Id” which

relates to the related default EPS-bearer Id. The message also conveys the GTP TEID of the new bearer from the P-GW to the S-GW. ⇒ The S-GW will relay the also included bearer description to the MME. Of course, the S-GW has to include the GTP TEID of its user plane to allow the

MME to relay this information to the eNodeB.The MME will build two messages: An ESM: DED_EPS_BEARER_CX_REQ-message and an S1-AP: E-RAB_SETUP_REQ-message. The ESM-message contains the NAS-description of the new bearer while the S1-AP-message serves as carrier for the ESM-message and it contains the radio resource description of the new bearer for the eNodeB.

⇒ The eNodeB will take the ESM-message and will embed it into an RRC_CONN_RECONF-message that is also used to convey the radio resource related information of the new bearer to the UE.

⇒ The UE shall setup the new bearer and shall confirm this to the eNodeB by sending RRC_CONN_RECONF_CMP. ⇒ Similarly, the ESM-layer shall build an ESM: DED_EPS_BEARER_CX_ACC-message which will be transparently sent to the eNodeB which in turn will

transparently relay it to the MME. ⇒ Only after having received this ESM-message, the MME shall confirm EPS-bearer establishment to the S-GW and this message also includes the

GTP-U TEID of the eNodeB for the new bearer. ⇒ Finally, the S-GW confirms bearer establishment to the P-GW. ⇒ The P-GW must still respond to the PCRF's DIA: RAR-message by sending DIA: RAA with a successful result code. ⇒ In turn, the PCRF shall confirm bearer setup to the IMS (precisely to the P-CSCF). ⇒ What we did not include is the continuing SIP-signaling for call setup for which the voice data will be sent on the newly established bearer. GTP Create-Bearer-Request / Response: [3GTS 29.274 (7.2.3), (7.2.4)] S1-AP E-RAB Setup: [3GTS 36.413 (8.2)] ESM Dedicated EPS Bearer Context Request [3GTS 24.301 (6.4.3) RRC Connection Reconfiguration [3GTS 36.331 (5.3.5)] ESM Dedicated EPS Bearer Context Accept [3GTS 24.301 (6.4.1) DIAMETER: RAA: [3GTS 29.212 (5.6.5)]




PP--CCSSCCFF IInnvvoollvveemmeenntt dduurriinngg UUnnggrraacceeffuull SSeessssiioonn RReelleeaassee




PP--CCSSCCFF IInnvvoollvveemmeenntt dduurriinngg UUnnggrraacceeffuull SSeessssiioonn RReelleeaassee ⇒ The P-CSCF plays an important role during ungraceful session release. Of course, there are multiple reasons that may lead to an ungraceful session

release of which the P-CSCF only takes care of a few. They are mainly related to loss of radio coverage (call drop / broken radio link). ⇒ In such a case, the entire procedure is triggered by a broken radio link (1). The issue is that by definition the P-CSCF will not be able to recognize

such a broken radio link because the media channels remain transparent to the P-CSCF. ⇒ However, the GGSN is well suited to recognize the lack of data packets (2). This function is based on some packet inspection function inside the

GGSN which is initialized for certain IP-address / port number associations. It can be sophisticated enough to evaluate the quality of the data packets but this is not very likely.

⇒ When the GGSN detects that there are no more packets arriving in upstream direction for a certain period of time it may internally communicate towards the PEP that the radio link is interrupted and that there won’t be any recovery.

⇒ Consequentially (3), the PEP will use COPS and the DRQ-message (Delete Request State) to tell the PDF that the media tunnel is broken. Accordingly, the PDF will internally or externally communicate with the P-CSCF that the media authorization has been withdrawn and …

⇒ Since the P-CSCF is a B2BUA, it will disconnect the session by sending a Request: BYE-message to both peers. [3GTS 29.207, 3GTS 29.208, RFC 2748]




PP--CCSSCCFF IInntteerrwwoorrkkiinngg wwiitthh tthhee TTrrGGww




PP--CCSSCCFF IInntteerrwwoorrkkiinngg wwiitthh tthhee TTrrGGww Basically, the Interworking with a TrGw is only required in case of the following situations: 1. The UE operates in an arbitrary IP-CAN and has been allocated a private IP-address. The allocation of a private IP-address may remain transparent to

the UE and can only be detected by the P-CSCF (we handle this issue in great detail in the chapter “From the IMS to the IMS-Solution”. 2. The UE has been allocated an IPv4-address and the IMS is expecting IPv6-addresses. In this case, the P-CSCF handles the IP-address conversion for

the SIP-signaling but there needs to be a TrGw for the IP-address conversion of the media paths.




FFaaccttss SShheeeett




FFaaccttss SShheeeett The figure illustrates some genuine characteristics of the P-CSCF.

Characteristics ⇒ The presence of the P-CSCF is a must in an IMS, considering its specific tasks of e.g. SIP-compression or establishment of security associations

towards the UE. ⇒ The P-CSCF needs to be at least a B2BUA but it may even be an SBC, if the IMS-Access Gateway or TrGw becomes integral part of the P-CSCF. In

such a case, the Iq/Ix-interface is no longer an open interface.

Interfaces to other Network Elements The Gm-interface to the UE is obviously mandatory; the Gq-interface is only there when the PDF is not integrated into the P-CSCF; the Go-interface is only there when the PDF is integrated into the P-CSCF and this integrated PDF communicates through the Go-interface with the PEP (Policy Enforcement Point). In case of 3GPP, the PEP is integrated into the GGSN; the Mw-interface is mandatory as it allows the P-CSCF to communicate with the other CSCF’s; the Iq/Ix-interface is optional and only there, if NAT- and/or IP-version Interworking with the IP-CAN are necessary or if the TrGw is external to the P-CSCF.

Protocol Stacks of the P-CSCF Please note that on the Gm-interface there is a new compression layer between UDP and SIP. All SIP-based interfaces only show UDP as transport protocol but specifically TCP is also possible.

Note that each P-CSCF is identified by its FQDN/IP-address and a SIP-URI (e.g. sip: [email protected]).

[3GTS 23.228 (4.6.1)]




II--CCSSCCFF ((IInntteerrrrooggaattiinngg CCaallll SSeessssiioonn CCoonnttrrooll FFuunnccttiioonn)) Tasks & Functions

• First point of contact for IMS-incoming transactions In such a case, the I-CSCF interrogates the SLF/HSS to which S-CSCF the SIP-Request shall be routed.

• During the registration process the I-CSCF selects the S-CSCF in which the UE shall be registered The I-CSCF also interrogates the HSS of a subscriber whether the subscriber may register in the first place. If more than one HSS is there, the I-CSCF needs to access the SLF previously to determine the very HSS of that subscriber.

• May be in the chain of network elements also in case of IMS-outgoing / UE originating transactions This is true particularly if the operator wishes to hide the IMS-internal architecture and addresses from outside. To do so, the “Via:”-header field will be tokenized.




II--CCSSCCFF ((IInntteerrrrooggaattiinngg CCaallll SSeessssiioonn CCoonnttrrooll FFuunnccttiioonn)) Tasks & Functions

• First point of contact for IMS-incoming transactions. To clarify: This bullet relates to transactions which are destined to a UA that is registered within the IMS to which this I-CSCF belongs to. Please recall that each transaction consists of a SIP-request message and the related responses. The exceptions to this rule are IMS-incoming transactions which origin from the PSTN as they come through the MGCF rather than through the I-CSCF.

• During the registration process the I-CSCF selects the S-CSCF in which the UE shall be registered Interrogation of the HSS occurs through the Cx-interface and interrogation of the SLF occurs through the Dx-interface. In both cases, the DIAMETER-protocol is used, applying the Cx-specific amendments to DIAMETER which are defined in 3GTS 29.229.

• May be in the chain of network elements also in case of IMS-outgoing / UE originating transactions To clarify: This bullet relates to transactions which origin from a UA that is registered within the IMS to which this I-CSCF belongs to. In addition to what was already said on the graphics page please consider the case when a UA is accessing the own IMS through a foreign P-CSCF or SIP-proxy. In this case, the home operator may select to put an I-CSCF between the S-CSCF and the foreign SIP-proxy or P-CSCF. In such a case, if topology hiding shall be applied, the two I-CSCF’s will be in the communication chain.

[3GTS 23.228 (4.6.2), 3GTS 24.229 (5.3)]




TTaasskkss && FFuunnccttiioonnss ((ccoonnttiinnuueedd))

• Topology Hiding Was already mentioned in the previous bullet: The I-CSCF replaces all already existing “Via:”-header fields by a token to hide IMS-internal SIP-server addresses from externals.

• TrGw-Interworking There may be a TrGw connected to the I-CSCF to provide for IP-version Interworking and to tackle NAT-issues.

• May need to act as IMS-ALG This becomes necessary if IP-version or NAT-Interworking are required in the SIP-signaling plane.




TTaasskkss && FFuunnccttiioonnss ((ccoonnttiinnuueedd)) • Topology Hiding

Topology hiding will be explained in more detail on the following slides.

• TrGw-Interworking This relates to H.248 / MEGACO communication with the TrGw to control the users’ media streams. In that respect, control relates to IP-version or NAT-interworking but it also allows for media stream observation, legal interception or codec conversion ( transcoding).

• May need to act as IMS-ALG The IMS-ALG function is working the same way as is done in case of the P-CSCF. The intention is obviously different; it targets “the other side”: While the P-CSCF operates towards the UA, the I-CSCF operates towards external networks. The implementation of an IMS-ALG into the I-CSCF also allows for the use of NAT/NAPT internally within a network operator’s domain.

[3GTS 23.228 (4.6.2), 3GTS 24.229 (5.3)]




TTyyppiiccaall UUssee CCaasseess • I-CSCF Involvement during UA Registration ( Initial UE-Authorization and

S-CSCF Assignment)




TTyyppiiccaall UUssee CCaasseess I-CSCF Involvement during UA Registration ( Initial UE-Authorization and S-CSCF Assignment) ⇒ Initially, the I-CSCF performs the “user registration status query” procedure (DIAMETER: UAR- and UAA-messages) to find out whether the user is

allowed to register and to check whether the user is already registered in a specific S-CSCF from a different device (bullet 4). ⇒ If there is more than one HSS, the I-CSCF needs to query the SLF first (bullet 3) to find out which HSS is responsible for this private user identity

(IMPI). ⇒ When the HSS approves the registration, the I-CSCF needs to select an S-CSCF based on different considerations like the geographical situation

( the closest S-CSCF to that IP-CAN), the S-CSCF capabilities, load sharing or customer type (pre-paid / contract). Which considerations apply depends on operator requirements.

⇒ Alternatively, the HSS may tell the I-CSCF that the user is already registered from a different device to a specific S-CSCF. In such case, the HSS will indicate the SIP-URI of that S-CSCF to the I-CSCF as “Server-Name” (bullet 4).

⇒ In step 5 (bullet 5), the I-CSCF relays the Request: REGISTER-message towards the S-CSCF. [3GTS 24.229 (5.3.1)]

???? Question Section 3 ???? ⇒ Please identity precisely under which conditions case 1a, 1b or 1c applies. ⇒ Which party can in which way enforce case 1a? ⇒ In which network access situation does the 3GPP-specific setting of the APN have no meaning? ⇒ How can an IMS-operator avoid case 1b and 1c and divert the UA to case 1a?




II--CCSSCCFF IInnvvoollvveemmeenntt dduurriinngg IIMMSS--IInnccoommiinngg TTrraannssaaccttiioonnss




II--CCSSCCFF IInnvvoollvveemmeenntt dduurriinngg IIMMSS--IInnccoommiinngg TTrraannssaaccttiioonnss To clarify: This slide relates to transactions which are destined to a UA that is registered within the IMS to which this I-CSCF belongs to. Please recall that each transaction consists of a SIP-request message and the related responses. The most important function of the I-CSCF in this case is to retrieve routing information from the HSS of the terminating party as to where (next hop / S-CSCF) the SIP-Request shall be routed to.

Note that in all cases the illustrated I-CSCF receives the incoming SIP-Request message because a previous DNS-query of the source network for the SIP-URI of the called party resulted in the address of that I-CSCF to reach a certain subscriber (e.g. DNS-query for sip:[email protected] results in the provision of the FQDN or IP-address of the responsible I-CSCF).

⇒ Bullet 1a relates to the case when another UA (belonging to another operator’s IMS) tries to get in touch with the UA on the left hand side. The respective SIP-Request message may for instance be a Request: INVITE or a Request: MESSAGE.

⇒ Bullet 1b is similar to bullet 1a but in this case, the source network is not an IMS but an arbitrary IP-multimedia network that not necessarily applies IMS-specific advanced SIP-operation.

⇒ Bullet 1c is like bullet 1b but it illustrates the specific case of an incoming audio session from a VoIP-network. ⇒ Bullet 1d is related to a transaction (e.g Request: NOTIFY) from an external application server. ⇒ Bullet 1e is the same as bullet 1a with the exception that the transaction origins from a UA within the same IMS where the target UA is registered.

[3GTS 24.229 (5.3)]




TTooppoollooggyy HHiiddiinngg tthhrroouugghh tthhee II--CCSSCCFF




TTooppoollooggyy HHiiddiinngg tthhrroouugghh tthhee II--CCSSCCFF Tokenization The figure illustrates the impact and meaning of topology hiding within SIP-messages that leave an IMS towards external networks or IP-CAN’s. Topology hiding is achieved by tokenizing all address information about network elements within the affected IMS. The only exceptions to this rule are the UE and the I-CSCF which tokenizes: For both, the address information is left within the SIP-message. Tokenization applies to all header types that could reveal internal configuration information. This relates particularly to the “Via:”-header field but also to the “Route:”-, “Record-Route:-” or “Service-Route:”-header fields.

Header Field Alteration In the example, the I-CSCF / THIG (Topology Hiding Internet Gateway) tokenizes a “Via:”-header field. As illustrated, the tokenization affects the “Via”-entries of the P-CSCF and the S-CSCF. Both are encrypted into a token (78g65H44G3537jkrtezu653) that can only be decrypted by the I-CSCF. Note that the I-CSCF will also add a parameter to the token-string which is “tokenized-by= IMS-operator.net” so that everybody along the upcoming communication chain will know which network did the tokenization.

[3GTS 24.229 (5.3.3, 7.2A.3)]




TTrrGGww--IInntteerrwwoorrkkiinngg aanndd OOppeerraattiioonn aass IIMMSS--AALLGG ((wwiitthh NNAATT))




TTrrGGww--IInntteerrwwoorrkkiinngg aanndd OOppeerraattiioonn aass IIMMSS--AALLGG ((wwiitthh NNAATT)) ⇒ The figure illustrates another interesting use case of the I-CSCF as controller of a TrGw in conjunction with NAT. Although NAT will be dealt with in

more detail in the following chapter we like to say at this time that in this example use case, the I-CSCF incorporates a NAT-router for private IP-address translation.

⇒ Accordingly, the I-CSCF also incorporates an IMS-ALG to alter the SIP-content with respect to replacing private IP-addresses or tokenizing them in case of topology hiding.

Basically, the assumption for this figure is that the IMS uses private IP-addresses internally. IMS-internal use of private IP-addresses is advisable because of the inherent firewall function of NAT ( internal nodes remain inaccessible for outside intruders).

⇒ The IMS-internal IP-address of the I-CSCF is 10.0.0.254, its external IP-address is 69.20.20.30. Of course, these are arbitrary IP-addresses. ⇒ Since private IP-addresses are used also for the media stream, a TrGw is required at the network edge to provide for IP-address translation. The IMS-

internal IP-address of the TrGw is 10.0.0.255 and its external IP-address is 69.20.20.20. ⇒ The I-CSCF most likely uses H.248 / MEGACO signaling to control the media stream flow through the Trgw.




FFaaccttss SShheeeett The figure illustrates some genuine characteristics of the I-CSCF.

Characteristics ⇒ The presence of the I-CSCF is a must in an IMS, considering its specific tasks of assignment of an S-CSCF during registration or routing an incoming

transaction to the next hop. ⇒ The I-CSCF needs to be a stateful SIP-proxy server [3GTS 24.229 (5.3.1.1), (5.3.2.1)]. That means that the I-CSCF needs to maintain transaction

state. This applies in particular if topology hiding is applied. ⇒ Whether the I-CSCF incorporates in addition an IMS-ALG, depends on the necessity of IP-address conversion and NAT-interworking with external

networks. In that respect, “external network” does not relate to the IP-CAN but rather to foreign IMS’s, VoIP-networks and packet data networks in general.

Interfaces to other Network Elements The Mw-interface is mandatory and interconnects the I-CSCF to the other CSCF’s. The DIAMETER-based Dx-interface towards the SLF is only necessary if there is more than one HSS in that PLMN. If the operator allows for incoming and outgoing transactions towards generic SIP-proxies then there will be an Mm-interface. The Iq/Ix-interface is optional and only there, if NAT- and/or IP-version Interworking with the IP-CAN are necessary or if the TrGw is external to the P-CSCF.

Protocol Stacks of the I-CSCF Please note that 3GPP mandates the use of SCTP as transport layer for DIAMETER on the Cx- and Dx-interfaces. SIP-based interfaces only show UDP as transport protocol but specifically TCP is also possible.

Each I-CSCF is identified by its FQDN/IP-address and a SIP-URI (e.g. sip: [email protected]).

[3GTS 23.228 (4.6.2)]




SS--CCSSCCFF ((SSeerrvviinngg CCaallll SSeessssiioonn CCoonnttrrooll FFuunnccttiioonn)) Tasks & Functions

• Represents the Registrar within the IMS This most important function of the S-CSCF means that subscribers need to register their current IP-address to an S-CSCF. The S-CSCF in turn holds the entire subscriber profile which is downloaded from the HSS.

• Represents an Application Server for the “reg”-Event This allows the S-CSCF to actively deregister subscribers from the IMS.

• Next Hop Routing and Service Access Control in case of Originating Transactions The S-CSCF is in the loop for all SIP-request messages coming from subscribers that are currently registered in that S-CSCF.

• Next Hop Routing and Service Access Control in case of Terminating Transactions The S-CSCF is in the loop for all SIP-request messages destined to subscribers that are currently registered in that S-CSCF. Depending on operator policy, this case includes sequential or simultaneous forking.




SS--CCSSCCFF ((SSeerrvviinngg CCaallll SSeessssiioonn CCoonnttrrooll FFuunnccttiioonn)) Tasks & Functions

• Represents the Registrar within the IMS There may be multiple S-CSCF’s within a given IMS. They may all be alike or they may differ with respect to capacity or functionality.

Note that every IMS-subscriber always registers to an S-CSCF in his/her home-IMS irrespective of where he or she is roaming.

• Represents an Application Server for the “reg”-Event Note that the genuine SIP-standard provides no possibility to deregister subscribers nor does it allow the registrar to actively inform a subscriber about their registration state. The application server notion is an amendment of 3GPP to the genuine SIP-standard.

• Next Hop Routing and Service Access Control in case of Originating Transactions To clarify: This relates to transactions which are triggered by a UA that is registered within this S-CSCF. Please recall that each transaction consists of a SIP-request message and the related responses.

• Next Hop Routing and Service Access Control in case of Terminating Transactions To clarify: This relates to transactions which are destined to a UA that is registered within this S-CSCF.

[3GTS 23.228 (4.6.3), 3GTS 24.229 (5.4)]




TTyyppiiccaall UUssee CCaasseess ooff tthhee SS--CCSSCCFF • Involvement during IMS-Originating Transactions




TTyyppiiccaall UUssee CCaasseess ooff tthhee SS--CCSSCCFF Involvement during IMS-Originating Transactions How a UA-originating SIP-request message reaches the S-CSCF, obviously depends on the point of attachment of that UA. Note that for a better distinction we used two different colors to identify S-CSCF incoming and outgoing SIP-messages. ⇒ The UA may access the S-CSCF through a P-CSCF which is part of the same IMS to which the S-CSCF belongs to (bullet 1a). In this case, the IP-

CAN may still belong to another operator (bullet 1b). Alternatively, the UA is using the P-CSCF of another IMS-operator which also means that the IP-CAN belongs to another operator (bullet 1c). And finally, the UA may use a generic SIP-proxy which belongs to or is related to the operator who owns the IP-CAN through which the UA registered previously (bullet 1d).

⇒ If the own P-CSCF is used then there will be no I-CSCF between the P-CSCF and the S-CSCF (bullet 2a). Note that at registration, the P-CSCF stores the address of the S-CSCF to be able to route UA-originating SIP-requests. However, an I-CSCF may be in the loop in case a foreign P-CSCF or generic SIP-Proxy is used (bullets 2b and 2c). This is an operator decision.

⇒ The S-CSCF may need to involve the help of a DNS-server (bullet 3) to be able to take the next hop decision to bring the SIP-request message closer to its destination. And definitely the S-CSCF will invoke service access control functions to check whether the UA is legitimate in the first place to send this SIP-request message.

⇒ Bullet 4a relates to the case that the UA wants to send a SIP-request message (e.g. SUBSCRIBE, PUBLISH, INVITE) to an Application Server. ⇒ Bullet 4b, 5a and b and 6a and b relate to the case of audio call establishment request towards a destination within the PSTN or within the circuit-

switched domain of another PLMN (the MS-ISDN of a mobile phone was dialed and the DNS-query in bullet 3 resulted in a target within the PSTN / PLMN). The distinction between 5a / 5b and 6a / 6b is the geographic point of breakout into the PSTN / towards the second PLMN.

⇒ Bullet 4c relates to the case when the targeted SIP-URI resolves into another IMS or towards an outside generic SIP-proxy. It depends on operator policy ( e.g. topology hiding y/n) whether the S-CSCF needs to route the SIP-request message through an I-CSCF or not.

⇒ Bullet 4d relates to the UA wanting to setup a conference session or accessing a chat room for instant messaging. In such case, the UA will send a Request: INVITE-message towards the MRFC.




IInnvvoollvveemmeenntt dduurriinngg IIMMSS--TTeerrmmiinnaattiinngg SSeessssiioonn




IInnvvoollvveemmeenntt dduurriinngg IIMMSS--TTeerrmmiinnaattiinngg SSeessssiioonn The attempt to send a SIP-request message to a UA and/or to establish a SIP-dialog may stem from various different sources. Note that for a better distinction we used two different colors to identify S-CSCF incoming and outgoing SIP-messages. ⇒ Bullet 1a illustrates a case in which an application server tries to send a SIP-request message to a UA. This SIP-request will most likely be a NOTIFY

but other possibilities also exist. The illustrated case really relates to an operator controlled application server because for external application servers there should be an I-CSCF between the application server and the S-CSCF.

⇒ Bullet 1b relates to PSTN-originated voice calls for UA’s which are registered in that S-CSCF. Note that such voice calls first enter in the circuit-switched network domain before the HSS decides to route a call through the IMS. The aforementioned obviously relates to 3GPP-based mobile networks.

⇒ Bullet 1c and 1d relate to SIP-requests, originating from other SIP-networks (case 1c specifically addresses the possibility that the access is coming from another IMS).

⇒ Having received the SIP-request messages, the S-CSCF checks whether the UA is legitimate to receive that message and secondly the S-CSCF determines the next hop towards the UA.

⇒ This next hop decision may involve simultaneous or sequential forking. That is, a UA may be registered from different contact IP-addresses at the same time and the S-CSCF starts trying to reach the UA at the contact-address with the highest priority (q-value / please refer to course book “SIP, SDP and other NGN-Protocols – Signaling and Protocol Analysis”).

⇒ Our figure illustrates four different cases plus (in case of audio calls) voicemail system as fallback. Case 2a indicates the interesting possibility that the UA is registered in the PSTN, e.g. at his home phone number. Since the PSTN does not allow telephones or subscribers to register temporarily, this case needs to be considered as a hard-coded registration that remains in the S-CSCF for good. Note that there are two options where the breakout into the PSTN may occur; which one is actually chosen depends on operator policy but in general the interconnection charges within the PSTN shall be minimized (for further details please refer to BGCF explanations a few pages later).

⇒ Bullets 2b, 2c and 2d relate to cases in which the UA has registered from different IP-CAN’s and different P-CSCF’s and external SIP-proxies. Note that in cases when an external SIP-proxy or an external P-CSCF is the next hop, the S-CSCF may involve an I-CSCF on its way to this P-CSCF or SIP-proxy.

⇒ Bullet 2e illustrates a voicemail system as target destination but any other medium than a voice message is also possible.




FFaaccttss SShheeeett The figure illustrates some genuine characteristics of the S-CSCF.

Characteristics ⇒ The presence of the S-CSCF is mandatory in an IMS, because the S-CSCF represents the registrar within the IMS. ⇒ The S-CSCF needs to be a B2BUA [3GTS 24.229 (5.4.5.1)]. That is, the S-CSCF is able to autonomously send BYE-messages to the peers of a call if

certain conditions apply (e.g. service revocation). ⇒ In addition, the S-CSCF is an application server for the “reg”-event state to which the UA and the P-CSCF subscribe to.

Interfaces to other Network Elements ⇒ The Mw-interface is mandatory and interconnects the S-CSCF to the other CSCF’s. ⇒ The presence of Mg- and Mi-Interface depends on the presence of MGCF and BGCF. That is, if calls from and to the PSTN and the circuit-switched

domain shall be supported, then the MGCF and the BGCF are necessary and the Mg- and Mi-interfaces will be there. ⇒ The DIAMETER-based Cx-interface is necessary to allow the S-CSCF the interworking with the HSS. Its presence is mandatory. ⇒ The DIAMETER-based Dx-interface towards the SLF is only necessary if there is more than one HSS in that PLMN. ⇒ If the operator allows for incoming and outgoing transactions towards generic SIP-proxies then there may be an Mm-interface or the I-CSCF is

between the generic SIP-proxies and the S-CSCF. ⇒ The ISC-interface allows the S-CSCF the access to and from application servers. ⇒ Through the Mr-interface, the S-CSCF may invoke services from the MRFC like announcement playing.

Protocol Stacks of the S-CSCF Please note that 3GPP mandates the use of SCTP as transport layer for DIAMETER on the Cx- and Dx-interfaces. All SIP-based interfaces only show UDP as transport protocol but specifically TCP is also possible.

Each S-CSCF is identified by its FQDN/IP-address and a SIP-URI (e.g. sip: [email protected]).

[3GTS 23.228 (4.6.3)]




BBGGCCFF ((BBrreeaakkoouutt GGaatteewwaayy CCoonnttrrooll FFuunnccttiioonn)) Tasks & Functions

• For IMS-originated audio calls towards the PSTN, the BGCF decides where the breakout to the PSTN occurs The BGCF is there to save interconnection charges.

• Operation as IMS-ALG and controller of the TrgW These functions are only necessary in case of IP-version and NAT-interworking.




BBGGCCFF ((BBrreeaakkoouutt GGaatteewwaayy CCoonnttrrooll FFuunnccttiioonn)) Tasks & Functions

• For IMS-originated audio calls towards the PSTN, the BGCF decides where the breakout to the PSTN occurs The BGCF requires access to a BGCF-internal or external lookup database which relates a TEL-URI ( called target telephone number) to the next hop from the perspective of the BGCF. This breakout point may be an MGCF or a BGCF in the own IMS or it may be a BGCF in another IMS.

• Operation as IMS-ALG and controller of the TrgW As was said for the I-CSCF and the P-CSCF: The operation as IMS-ALG is necessary in case of IP-version or NAT-interworking in the control plane and the interaction with a TrGw is necessary if IP-version or NAT-interworking are necessary in the user plane (media).

[3GTS 23.228 (4.6.4), 3GTS 24.229 (5.6)]




UUssee CCaassee ooff tthhee BBGGCCFF




UUssee CCaassee ooff tthhee BBGGCCFF The figure illustrates how the BGCF operates in more detail: ⇒ Bullet 1: In case of IMS-originating audio calls towards the PSTN, the S-CSCF will route the Request: INVITE-message towards a BGCF. ⇒ Bullet 2: The BGCF requires access to a BGCF-internal or external lookup database which relates the called TEL-URI ( called target telephone

number) to the next hop from the perspective of the BGCF. ⇒ Bullet 3: In our example, the called PSTN-user is far away and the BGCF in the originating IMS decides to route the call towards a BGCF in another

IMS which is closer to the called PSTN-destination. ⇒ As illustrated, there are three options how this routing may occur: (1) directly from BGCF to BGCF through the Mk-interface or (2) involving an I-CSCF

within the own IMS which sends the Request: INVITE directly to the BGCF in the target IMS or (3) sending the Request: INVITE to an I-CSCF in the target IMS which then needs to take care that the Request: INVITE gets relayed to a BGCF.

Note that the interface between BGCF and I-CSCF is not named in the standard but it is certainly a SIP-based interface which is compliant with the Mw-, Mk or Mm-interface.

⇒ The next bullets highlight the operation of the BGCF in the IMS where the breakout to the PSTN finally occurs. ⇒ Bullet 4: The BGCF also invokes the help of its own lookup database to determine the next hop decision for the Request: INVITE-message. ⇒ Bullet 5: In this case, the outcome of the lookup is to route the Request: INVITE to an MGCF within the own IMS. ⇒ In the following, the MGCF and the media gateway provide for the interworking with the PSTN. This will be elaborated in more detail on the following

pages. ⇒ Bullet 6 tries to indicate that because of NAT or different IP-versions between the two IMS’s a TrGw becomes necessary. In this case, the BGCF

needs to operate as IMS-ALG and it needs to control the TrGw to take care of the audio streams.




FFaaccttss SShheeeett The figure illustrates some genuine characteristics of the BGCF.

Characteristics ⇒ The presence of the BGCF is conditional. It depends on the need to support IMS-originating transactions and call setups with PSTN-destinations. ⇒ The BGCF does not need to be a B2BUA. It may even be sufficient to use a stateless SIP-proxy if only UDP as transport protocol shall be used and if

no operation as IMS-ALG is necessary. However, usually stateful SIP-proxies will be used to allow the BGCF to fulfill these functions. The implementation as stateful proxy is also recommended to be able to use TCP for the next hop towards another IMS and apply TLS (Transport Layer Security) on this hop.

Interfaces to other Network Elements ⇒ If the BGCF is present then the interfaces to the S-CSCF ( Mi-interface), to the MGCF ( Mj-interface) and to another BGCF ( Mk-interface) are

mandatory for the BGCF to fulfill its tasks. ⇒ The Iq-/Ix-interface is optional and only necessary in case of IP-version or NAT-interworking.

Protocol Stacks of the BGCF The Mi-, Mj and Mk-interfaces are SIP/SDP-interfaces. The Iq-/Ix-interface towards the Trgw has not been specified yet ( Rel. 7) but will most likely be based on H.248.

Each BGCF is identified by its FQDN/IP-address and a SIP-URI (e.g. sip: [email protected]).

[3GTS 23.228 (4.6.4)]




MMGGCCFF ((MMeeddiiaa GGaatteewwaayy CCoonnttrrooll FFuunnccttiioonn)) // MMGGWW ((IIMMSS--MMGGWW)) Tasks & Functions

• For voice calls to and from PSTN-destinations or to or from the circuit-switched domain, the MGCF takes care of the signaling conversion SIP ISUP/BICC In the direction of the called UA the MGCF takes on the role of the calling UA.

• The MGCF controls the entire behavior and processing of the IMS-MGW It is the MGCF that triggers the interconnection or disconnection of user connections and it is the MGCF that tells the MGW to use a specific codec type.

• The IMS-MGW takes care of the interworking with the PSTN and with the circuit-switched domain in the user plane That is, the IMS-MGW takes care of codec conversion from and to PCM.




MMGGCCFF ((MMeeddiiaa GGaatteewwaayy CCoonnttrrooll FFuunnccttiioonn)) // MMGGWW ((IIMMSS--MMGGWW)) Tasks & Functions

• For voice calls to and from PSTN-destinations or to or from the circuit-switched domain, the MGCF takes care of the signaling conversion SIP ISUP/BICC Note that it is an implementation option to involve a separate signaling gateway in addition to the MGCF to take care of the actual signaling conversion.

• The MGCF controls the entire behavior and processing of the IMS-MGW H.248 / MEGACO is used for this purpose.

• The IMS-MGW takes care of the interworking with the PSTN and with the circuit-switched domain in the user plane The codec type selection within the IMS and towards the IP-CAN / UA is in the courtesy of the network operator. In 3GPP-based IMS’s, the use of AMR as voice codec is pre-dominant. However, other voice codecs like the iLBC (internet low bitrate codec) are also legitimate choices.

[3GTS 23.002 (4a.7.2), 3GTS 24.229 (6.4)]




TTyyppiiccaall UUssee CCaasseess ooff tthhee MMGGCCFF aanndd tthhee IIMMSS--MMGGWW • Involvement during IMS-MOC towards PSTN or CS-Domain




TTyyppiiccaall UUssee CCaasseess ooff tthhee MMGGCCFF aanndd tthhee IIMMSS--MMGGWW Involvement during IMS-MOC towards PSTN or CS-Domain (Mobile Originating Call) The figure illustrates how the MGCF and the IMS-MGW handle IMS-originating voice calls towards the PSTN and towards the circuit-switched domain of the same or another PLMN. ⇒ Bullet 1: The UA sends a Request: INVITE towards the P-CSCF. ⇒ Bullet 2: The P-CSCF relays the Request: INVITE towards the S-CSCF. ⇒ Bullet 3: The S-CSCF determines from the TEL-URI that the call needs to be routed to the PSTN or to the circuit-switched domain of the called

subscriber and accordingly relays the Request: INVITE towards a BGCF. ⇒ Bullet 4: The BGCF determines that breakout into the PSTN or the circuit-switched shall occur within the IMS and accordingly relays the Request:

INVITE towards the MGCF. ⇒ The MGCF performs the translation from SIP into BICC/ISUP (or invokes the help of a signaling gateway to do so) and acts as SIP peer user agent

towards the calling subscriber. That is, the MGCF generates the SIP-responses for the Request: INVITE and may generate other SIP-requests autonomously after the SIP-dialog has been established.

⇒ Bullet 5 indicates the allocation of a UDP-port number within the media gateway to serve as peer UDP-port number for RTP-frames with audio information inside that the calling UA sends to its peer (bullet 8). The MGCF, acting as UA will relay the IP-address of the media gateway and the respective UDP-port number back to the calling UA as SDP-receiver IP-address and port number.

⇒ At the same time (still bullet 5) the IMS-MGW needs to allocate a PCM-timeslot number to be used in the direction of the PSTN or an appropriate resource in case of interworking with the circuit-switched domain. This may be a UDP-port number or an AAL-2 resource or something else and depends on the used transport network.

⇒ Bullet 6a and 6b: Depending on whether the called party is located in the PSTN or in the circuit-switched domain of this or another PLMN, the MGCF sends an ISUP/BICC: IAM-message (Initial Address Message) towards the respective GMSC / G-MSC-server (Gateway) or CCS7-exchange.

⇒ The further call setup in the control plane is not illustrated here. ⇒ Bullets 7a and 7b indicate the interworking of the IMS-MGW with the PSTN-exchange (bullet 7b) and with the MGW within the circuit-switched domain

(bullet 7a). ⇒ In case of Interworking with the PSTN, the IMS-MGW most likely converts the IMS-internally used audio data into PCM-encoding but in case of

interworking with the circuit-switched domain, the two media gateways may not do any audio codec conversion ( transcoder-free operation). ⇒ with the IMS-MGW (bullet 5) would have occurred




IInnvvoollvveemmeenntt dduurriinngg IIMMSS--MMTTCC ffrroomm PPSSTTNN oorr CCSS--DDoommaaiinn




IInnvvoollvveemmeenntt dduurriinngg IIMMSS--MMTTCC ffrroomm PPSSTTNN oorr CCSS--DDoommaaiinn The figure illustrates how the MGCF and the IMS-MGW handle IMS-MTC’s (Mobile Terminating Calls) which origin in the PSTN or in the circuit-switched domain of the same or another PLMN. ⇒ Bullet 1a: The MSC-server in the circuit-switched domain of the H-PLMN operator of the called subscriber receives an incoming call establishment

request from a PSTN-exchange. At the same time a PCM-timeslot is established towards the related MGW in the circuit-switched domain. ⇒ Bullet 1b: The call establishment request is received from a GERAN/UTRAN within the circuit-switched domain of the H-PLMN-operator. ⇒ Bullet 1c indicates the establishment of the user plane connection. ⇒ Bullet 2: The Gateway-MSC-server (GMSC-S) uses the MAP-protocol to retrieve routing information from the HSS.

Note that the entire procedure up to this point is legacy and used in GSM since 1991.

⇒ Still Bullet 2: The HSS checks its database and decides that the call shall be routed through the IMS rather than through the circuit-switched domain (e.g. because the subscriber is not IMSI-attached but he or she registered through a cable TV based IP-CAN). Based on this decision, the HSS provides to the GMSC-S the CCS7-address of the MGCF and it attaches the SIP-URI of the S-CSCF.

⇒ Bullet 3a: The GMSC-S uses H.248 for the communication with its MGW to prepare the allocation of an appropriate user plane resource towards the IMS. This appropriate resource may be a UDP-port number or an AAL-2 resource or something else and depends on the used transport network.

⇒ Bullet 3b: The GMSC-S sends an ISUP/BICC: IAM-message (Initial Address Message) towards the respective MGCF. This message also contains the SIP-URI of the S-CSCF and an identification of the user plane resource that the MGW allocated (bullet 3a).

⇒ Bullet 3c: and 3d: The MGCF requests the IMS-MGW to establish the user plane resource towards the MGW in the circuit-switched domain. The IMS-MGW also allocates a connection address (SDP c-line) and UDP-port number to be used by the called user agent as target address for the upcoming audio stream (bullet 7)

⇒ Bullet 4: The MGCF translates the ISUP/BICC: IAM-message into a SIP: INVITE-message and initiates as user agent a new call setup within the IMS. To do so, the MGCF transfers the Request: INVITE-message towards the S-CSCF of that subscriber.

⇒ Bullet 5 and 6: The S-CSCF routes the Request: INVITE through the P-CSCF towards the called user agent and the call setup continues.

Note: • This scenario has not yet been described in the specifications, not even for Rel 7. • Especially the provision of the S-CSCF’s SIP-URI in bullet 2 is not specified yet in 3GTS 29.002. • As alternative to providing the SIP-URI of the S-CSCF through MAP in bullet 2, the MGCF could be staffed with a DIAMETER-based interface towards

the HSS to obtain routing information to the S-CSCF of a subscriber.




FFaaccttss SShheeeett MMGGCCFF




FFaaccttss SShheeeett MMGGCCFF The figure illustrates some genuine characteristics of the MGCF.

Characteristics ⇒ The presence of the MGCF is conditional. It depends on the need to support IMS-originating and terminating transactions with peers within the PSTN

and the circuit-switched domain. ⇒ The MGCF represents a media gateway controller and as such includes a SIP UA to be able to communicate with the peer SIP-UA. ⇒ Whether or not the MGCF also includes the SGW (signaling gateway function) for ISUP/BICC SIP or whether this function is taken care of a by

dedicated SGW is an implementation decision.

Interfaces to other Network Elements ⇒ There needs to be an interface (not named) either to the G-MSC-server (Gateway) within the circuit-switched domain or to the SGW. In the latter case,

the SGW interconnects towards the G-MSC-server. ⇒ The same applies for the interface to the PSTN. Either the MGCF interconnects directly or through an SGW. ⇒ If the MGCF is present then interfaces towards the S-CSCF ( Mg-interface), towards the BGCF ( Mj-interface) and towards the IMS-MGW ( Mn-

interface) are mandatory.

Protocol Stacks of the MGCF The Mg- and Mj-interfaces are SIP/SDP-interfaces which also applies for the interface towards the SGW (if present). The Mn-interface is working with H.248/MEGACO. The interfaces towards the G-MSC-server and towards the PSTN-exchange work with ISUP/BICC and most likely, the interface towards the PSTN-exchange is CCS7-based while the interface towards the G-MSC-server may alternatively support an IP-transport network.

Each MGCF is identified by its FQDN/IP-address and a SIP-URI (e.g. sip: [email protected]) for communication with SIP-UA’s but it also requires CCS7-identifiers like MSC’s do. Those are E.164-based.

[3GTS 23.002 (4a.7.2)]




FFaaccttss SShheeeett IIMMSS--MMGGWW ((IIMMSS--MMeeddiiaa GGaatteewwaayy))




FFaaccttss SShheeeett IIMMSS--MMGGWW ((IIMMSS--MMeeddiiaa GGaatteewwaayy)) The figure illustrates some genuine characteristics of the IMS-MGW.

Characteristics ⇒ The presence of the IMS-MGW is conditional. It depends on the need to support IMS-originating and terminating transactions with peers within the

PSTN and the circuit-switched domain. ⇒ The IMS-MGW represents a media gateway that is in charge for the user plane. Every IMS-MGW is controlled by exactly one MGCF but each MGCF

may control more than one MGW.

Interfaces to other Network Elements ⇒ If the IMS-MGW is present then interfaces towards the MGCF ( Mn-interface) and towards the serving IP-CAN ( Mb-interface) are mandatory.

The Mb-interface may for instance be an interconnection to a GGSN if the IP-CAN is based on GERAN/UTRAN. ⇒ Obviously, the IMS-MGW also requires interfaces (not named) towards the circuit-switched media gateway and towards the PSTN.

Protocol Stacks of the IMS-MGW The Mn-interface is working with H.248/MEGACO. The protocol stack on the Mb-interface and towards the circuit-switched media gateway is usually based on RTP/UDP but needs to be negotiated during session setup. On top of e.g. RTP/UDP will be the also negotiated audio codec (e.g. AMR). Note that the interface towards the circuit-switched media gateway may also be based on AAL-2 ( legacy and implementation depending). Towards the PSTN-exchange, the IMS-MGW needs to support the PCM-codec ( a-law and/or µ-law).

Each MGW requires one or more IP-addresses on the Mb-interface but it also requires trunk-ID towards the PSTN-exchange. The addressing towards the circuit-switched media gateway depends on the used transport and may be ATM-based (NSAP) or IP-based (IP-address(es)).

[3GTS 23.002 (4a.7.3)]




MMRRFF ((MMuullttiimmeeddiiaa RReessoouurrccee FFuunnccttiioonn)) Tasks & Functions

• Playing of Tones and Announcements to users Controlled by the S-CSCF, the MRF acts as user agent for playing announcements and generating tone signals towards UA’s within and outside the IMS.

• Chatroom Server The MRF may be equipped with SIP-URI’s that identify chatrooms (Public Service Identity). In that respect, the MRF acts as user agent. We will illustrate an example on the next pages.

• Mixing and Floor Control in case of Conferences and Multiparty Sessions The MRF sits in the middle between the participants, possibly mixing the media streams together (predominantly for audio conferences) and possibly orchestrating the use of the available resources (floor control).




MMRRFF ((MMuullttiimmeeddiiaa RReessoouurrccee FFuunnccttiioonn)) Tasks & Functions

• Playing of Tones and Announcements to users Consider for example the mixing of music and ringback-tone (today an IN-application) and playing it towards a calling user. Another possibility are multimedia announcements if the calling UA supports them. For example, users record video messages for times when they are not reachable.

• Chatroom Server • Mixing and Floor Control in case of Conferences and Multiparty Sessions

In that respect, the use of e.g. BFCP (Binary Floor Control Protocol) is a feasible option. PoC-servers do the same through TBCP (Talk Burst Control Protocol).

Note that the MRF is split into a control plane and a user plane function. The MRFC takes care of the control plane ( SIP) and the MRFP takes care of the user plane (RTP, MSRP…)

[3GTS 23.228 (4.7), 3GTS 24.229 (5.8)]




TTyyppiiccaall UUssee CCaasseess ooff tthhee MMRRFF ((MMRRFFCC aanndd MMRRFFPP)) • Involvement during chat-room based instant messaging




TTyyppiiccaall UUssee CCaasseess ooff tthhee MMRRFF ((MMRRFFCC aanndd MMRRFFPP)) Involvement during chat-room based instant messaging ⇒ Bullet 1a, 1b and 1c: Three user agents access “their” chatroom through the MRF. This access is triggered by each UA sending a Request: INVITE

through the P-CSCF to their S-CSCF’s. As illustrated, all users come from different IP-CAN’s and therefore they use different P-CSCF’s. However, the users at bullet 1b and 1c at least share the same S-CSCF. The SDP in the INVITE’s will identify “message” as media type and MSRP/TCP as transport protocol (example m-line: m = message 7348 TCP/MSRP *). Of course, the MIME-types of the messages also need to be negotiated through SDP.

⇒ Bullet 2a, 2b and 2c: Based on the called SIP-URI ( which identifies the chatroom) the S-CSCF routes the Request: INVITE towards the MRFC. ⇒ Bullet 3: The MRFC uses H.248/MEGACO to inform the MRFP about the port number and protocol to be used to send messages to the new arriving

UA’s. What is not shown is the remaining session setup through SIP in which the MRFC informs the UA’s about the IP-address, TCP-port numbers and MIME-encodings where and how the MRFP is ready to receive instant messages.

⇒ Bullet 4a, 4b and 4c: The UA’s can send messages of the specified MIME-types to the MRFP and receive messages from the MRFP.

???? Question Section 4 ???? ⇒ Considering the chat room on this slide: How would you differentiate the three instant messaging options “Page Mode IM”, “Session Based IM” and

“Chat Room”? ⇒ What are the different network configurations to support them?




AAnnnnoouunncceemmeenntt PPllaayyiinngg




AAnnnnoouunncceemmeenntt PPllaayyiinngg The figure illustrates what may happen when a called UA within an IMS is unable or unwilling to establish a dialog and sends back a negative response: 1. The calling UA sends a Request: INVITE to its SIP-proxy which … 2. … is relayed towards an I-CSCF of the home-IMS of the called party. 3. The I-CSCF determines the S-CSCF of the called party (through HSS-enquiry) and relays the Request: INVITE towards that S-CSCF. 4. The S-CSCF checks whether the called UA is authorized to receive the call and it checks where to route the call establishment request and then sends

the Request: INVITE towards the P-CSCF of the called UA. 5. The P-CSCF relays the Request: INVITE towards the called UA and … 6. … receives back a negative response (e.g. Response: 486 – User Busy). 7. The P-CSCF relays this negative response to the S-CSCF and the S-CSCF terminates the INVITE-transaction towards the called party by sending

back ACK to the P-CSCF ( 8. and 9.). 10. Because of internal logic and because of the user profile which was downloaded from the HSS during registration, the S-CSCF forks (sequentially) the

Request: INVITE and sends it to the MRFC, identifying to play a standard or special announcement. 11. The MRFC accepts the invitation and uses H.248 / MEGACO to activate the respective announcement within the MRFP. What is not shown in this

scenario 12. Then the MRFC returns a provisional Response: 183-Session Progress to the S-CSCF which contains a changed SDP-description (e.g. a=sendonly)

that traverses all the way back to the calling party (13., 14 and 15.).

What is not shown is the confirmation of the calling party which accepts the changed SDP-description and therefore enables the playing of the announcement.

16. Finally, the recorded announcement is played towards the calling party.

If there is a time constraint related to the announcement playing, then the MRFC will send a Request: BYE through the S-CSCF to the calling party to finish the call.




FFaaccttss SShheeeett MMRRFFCC ((MMuullttiimmeeddiiaa RReessoouurrccee FFuunnccttiioonn CCoonnttrroolllleerr))




FFaaccttss SShheeeett MMRRFFCC ((MMuullttiimmeeddiiaa RReessoouurrccee FFuunnccttiioonn CCoonnttrroolllleerr)) The figure illustrates some genuine characteristics of the MRFC.

Characteristics ⇒ The presence of the MRFC is conditional. It depends on the need to support the illustrated functions of chatroom, mixing and conferencing. ⇒ The MRFC represents a media gateway controller when it controls the MRFP but it also represents a SIP UA which is able to communicate through

SIP with other user agents.

Interfaces to other Network Elements ⇒ If the MRFC is present then the interfaces towards the S-CSCF ( Mr-interface) and towards the MRFP ( Mp-interface) are mandatory.

Protocol Stacks of the MRFC The Mr-interface is a SIP/SDP-interfaces. The Mp-interface will most likely be working with H.248/MEGACO but at least Rel 7 does not specify the protocol on the Mp-interface.

Each MRFC is identified by its FQDN/IP-address and a SIP-URI (e.g. sip: [email protected]). The MRFC may also incorporate various public service identities to identify different chatrooms which are also SIP-URI’s.

[3GTS 23.002 (4A.7.4), 3GTS 23.218 (8), 23.228 (4.7)]




FFaaccttss SShheeeett MMRRFFPP ((MMuullttiimmeeddiiaa RReessoouurrccee FFuunnccttiioonn PPrroocceessssoorr))




FFaaccttss SShheeeett MMRRFFPP ((MMuullttiimmeeddiiaa RReessoouurrccee FFuunnccttiioonn PPrroocceessssoorr)) The figure illustrates some genuine characteristics of the MRFP.

Characteristics ⇒ The presence of the MRFP is conditional. It depends on the need to support the illustrated functions of chatroom, mixing and conferencing. ⇒ The MRFP represents a database for tone signals and multimedia announcements and it also represents a media gateway which can operate as

mixer for data streams (e.g. audio).

Interfaces to other Network Elements ⇒ If the MRFP is present then the interfaces towards the MRFC ( Mp-interface) and towards IP-CAN’s and PDN’s (Packet Data Networks) ( Mb-

interface) are mandatory.

Protocol Stacks of the MRFP The Mp-interface will most likely be working with H.248/MEGACO but at least Rel 7 does not specify the protocol on the Mp-interface. The Mb-interface is an IP-based interface.

Each MRFC is identified by its FQDN/IP-address and a SIP-URI (e.g. sip: [email protected]). The MRFC may also incorporate various public service identities to identify different chatrooms which are also SIP-URI’s.

[3GTS 23.002 (4A.7.4a), 3GTS 23.218 (8), 23.228 (4.7)]




Bootcamp Intorduction




AAnndd wwhheerree aarree SSIIPP,, SSDDPP aanndd aallll tthhee ootthheerr PPrroottooccoollss uusseedd?? • The figure illustrates which components within 3GPP-based NGN’s use

which protocols to communicate Note that SIP and SDP are used for both: The peer-to-peer signaling between customer nodes and the internal communication among the network control nodes.




AAnndd wwhheerree aarree SSIIPP,, SSDDPP aanndd aallll tthhee ootthheerr PPrroottooccoollss uusseedd?? SIP Use within NGN It is noticeable that SIP is used as well for end-user signaling as among SIP-proxies and towards the media gateway controllers. However, SIP requires SDP to describe the media of a session and therefore, the previous statement also applies to SDP. [RFC 3261 ( SIP), RFC 2327, RFC 3266, RFC 3264] The figure also highlights the use of many more protocols:

DIA (DIAMETER)) The DIAMETER Protocol is very important as it allows the SIP-proxy servers to interrogate and interact with databases like the HSS (Home Subscriber Server). DIAMETER in general is there to exchange subscriber related information like: (1) Is a subscriber authorized to use a service? (2) Provide the authentication information for that subscriber etc. (3) QoS-Authorization over the Gq-interface. DIAMETER is also used to for session offline and online charging. In many aspects, DIAMETER can be compared with the MAP-protocol of 3GPP’s 3GTS 29.002. DIAMETER is frequently considered the successor of RADIUS with extended capabilities. This is also the explanation of the strange term “Diameter” in the protocol name: A diameter is twice the radius and in terms of protocols, DIAMETER shall be considered as successor of RADIUS. DIAMETER is defined as a base protocol ( DBP) to be supported by all implementations and application specific amendments. 3GPP for instance defined various amendments to the DBP for use on the Cx- Dx- and Sh-interfaces. [RFC 3588, RFC 3589, 3GTS 29.229, 3GTS 29.329]

H.248 / MEGACO As mentioned before, this protocol allows the MGC to control one ore more media gateways. [ITU-T H.248, RFC 3015]

RTP / SRTP (Real-time Transport Protocol / Secure Real-time Transport Protocol) All three protocols are there to convey user data. Neither protocol provides real-time capability by itself or by definition but they require some additional means like DiffServ, IntServ or MPLS to provide the necessary QoS. SRTP adds integrity protection and encryption to the capabilities of RTP. [RFC 3550 ( RTP), RFC 3711 ( SRTP)]

Note that the figure on the graphics slide does not illustrate various SIP-servers from the previous slide like the BGCF or the different X-CSCF’s. The reason is that all these IMS-specific servers are nothing else but SIP-proxy servers with special functions.




•• PPrroottooccoollss wwiitthhiinn tthhee IIMMSS--CCoonnttrrooll PPllaannee




PPrroottooccoollss wwiitthhiinn tthhee IIMMSS--CCoonnttrrooll PPllaannee SIP and SDP It is noticeable that SIP is used for end-user signaling ( UNI) (bullet 1) as well as among SIP-proxies ( NNI) (bullet 2) and towards application servers (bullet 3). However, SIP requires SDP to describe the media of a session and therefore, the previous statement also applies to SDP. [RFC 3261 ( SIP), RFC 2327 ( SDP) draft-ietf-mmusic-sdp-new-26.txt ( SDP), RFC 3266, RFC 3264]

DIA (DIAMETER)) The DIAMETER Protocol (bullet 4 and 5) is very important as it allows the SIP-proxy servers to interrogate and interact with databases like the HSS (Home Subscriber Server). DIAMETER in general is there to exchange subscriber related information like: Bullet 5, 6 7: Is a subscriber authorized to use a service and provision of the authentication information for that subscriber etc. Bullet 4: QoS-Authorization over the Gq-interface. DIAMETER is also used to for session offline and online charging. In many aspects, DIAMETER can be compared with the MAP-protocol of 3GPP’s 3GTS 29.002. DIAMETER is frequently considered the successor of RADIUS. This is also the explanation of the strange term “Diameter” in the protocol name: A diameter is twice the radius and in terms of protocols, DIAMETER shall be considered as successor of RADIUS. DIAMETER is defined as a base protocol ( DBP) to be supported by all implementations and application specific amendments. 3GPP for instance defined various amendments to the DBP for use on the Cx-, Dx-, Sh- and charging interfaces. [RFC 3588, RFC 3589, http://www.diameter.org/, 3GTS 29.229, 3GTS 29.329]

COPS The Common Open Policy Service Protocol is used for policing between the PDF and the PEP (bullet 4) [RFC 2748].

H.248 / MEGACO H.248 / MEGACO (bullet 9) allow the MGC to control one ore more media gateways. Control relates particularly to the seizure and release of resources for user data transfer [ITU-T H.248, RFC 3015].

BFCP / TBCP Binary Floor Control Protocol (bullet 8) and Talk Burst Control Protocol are used for floor control within the IMS. TBCP is restricted to use within the PoC-service [draft-ietf-xcon-bfcp-05].

IP, IPsec and TLS The IMS uses IPv4 or IPv6 in the transport network and IPsec or TLS to provide for secure links between IMS-facilities.




PPrroottooccoollss wwiitthhiinn tthhee IIMMSS--UUsseerr PPllaannee




PPrroottooccoollss wwiitthhiinn tthhee IIMMSS--UUsseerr PPllaannee RTP / RTSP / SRTP All three protocols are there to convey user data. Neither protocol provides real-time capability by itself or by definition but they require some additional means like DiffServ, IntServ or MPLS to provide the necessary QoS. SRTP adds integrity protection and encryption to the capabilities of RTP. [RFC 3550 ( RTP), RFC 2326 RTSP), RFC 3711 ( SRTP)]

MSRP The MSRP is used within the IMS for embedding IM-messages which can be differently encoded [draft-ietf-simple-message-sessions-XX]

Resource Allocation Protocols The bullet 4 relates to the IP-CAN specific resource allocation protocol which is used between UA and IP-CAN to obtain real-time QoS. In case of 3GPP-UTRAN / GERAN this would be session management.

QoS-Control Protocols Different IP-transport networks may support different QoS-control protocols like IntServ, DiffServ or MPLS.




SSoommee ddeettaaiillss ooff tthhee DDIIAAMMEETTEERR PPrroottooccooll




SSoommee ddeettaaiillss ooff tthhee DDIIAAMMEETTEERR PPrroottooccooll DIAMETER base protocol which is used to interact and interrogate the databases like HSS and AAA. ⇒ DIAMETER is frequently considered the successor of RADIUS. This is also the explanation of the strange term “Diameter” in the protocol name: A

diameter is twice the radius and in terms of protocols, DIAMETER shall be considered as successor of RADIUS. ⇒ DIAMETER is also used to for session offline and online charging. In many aspects, DIAMETER can be compared with the MAP-protocol of 3GPP’s

3GTS 29.002. ⇒ The online charging is applied to users who pay for their services periodically e.g. on monthly basis or at the end of month. ⇒ The offline charging is applied for prepaid customers and used for prepaid services. It is also called credit-based charging. [RFC 3588, RFC 3589, http://www.diameter.org/, 3GTS 29.229, 3GTS 29.329




DDIIAAMMEETTEERR OOvveerrvviieeww




DDIIAAMMEETTEERR OOvveerrvviieeww Diameter protocol was designed as an improved version of the RADIUS protocol. A goal was to maximize compatibility and ease migration from RADIUS to Diameter. For example, a Diameter message, like a RADIUS message, conveys a collection of attribute-value pairs (AVP). Diameter consists of the Diameter Base Protocol (DBP), a transport profile and a set of applications. The applications NASREQ and Mobile IPv4 provide for Authentication, Authorization and Accounting access, The Diameter Cryptographic Message Syntax (CMS) application provides end-to-end authentication, integrity, confidentiality at the AVP level. DBP provides basic mechanisms for reliable transport, message delivery, and error handling and must be used in conjunction with a Diameter application. Each application relies on the services of the base protocol to support a specific type of network access. DBP defines the basic Diameter message format. Data is carried within a Diameter message as a collection of AVPs.




IIMMSS--ssppeecciiffiicc AAmmeennddmmeennttss ttoo DDIIAAMMEETTEERR PPrroottooccooll




IIMMSS--ssppeecciiffiicc AAmmeennddmmeennttss ttoo DDIIAAMMEETTEERR PPrroottooccooll 1. The DIAMETER protocol consists of a base protocol (DBP) to be supported by all implementation and of implementation specific amendments. 2. 3GPP defined various IMS-specific amendments for DIAMETER for different interfaces like Cx, Dx or Sh, Ro and Rf.

⇒ DIAMETER is defined as a base protocol (DBP) to be supported by all implementations and application specific amendments. 3GPP for instance defined various amendments to the DBP for use on the Cx-, Dx-, Sh- and charging interfaces.

⇒ The DIAMETER applications can extend the base protocol, by adding new commands and attributes. An application is not a program but a protocol based on DIAMETER.

⇒ The DIAMETER application for different interfaces allows to download and update the user data, and to request and send notifications on changes on user data.

⇒ For each Command, there is a Request and an Answer Command. Moreover, each Command is assigned a code which is used for both requests and answers.

⇒ Cx interface is used to communicate between I-CSCF/S-CSCF and HSS. ⇒ Dx interface is used by I-CSCF/S-CSCF to find a correct HSS in a multi-HSS environment. ⇒ Sh interface is used to exchange information between SIP-AS/OSA-SCS and HSS. ⇒ The charging interfaces in an IMS are referred as Rf and Ro. ⇒ Rf is an offline charging interface. It is used to send accounting information between an IMS network entity or AS and CCF. The CCF collects all

information and builds CDR. ⇒ Ro is an online charging interface. It is used to send accounting information between an AS or MRFC and ECF

[RFC 3588, RFC 3589, http://www.diameter.org/, 3GTS 29.229, 3GTS 29.329, 3GTS 32.229, 3GTS 32.299]




SSeelleecctteedd DDiiaammeetteerr CCoommmmaannddss uusseedd bbyy IIMMSS




SSeelleecctteedd DDiiaammeetteerr CCoommmmaannddss uusseedd bbyy IIMMSS some Diameter commands which are important to IMS. 3GTS 29.229, 3GTS 29.329




RRTTPP // RRTTCCPP




RRTTPP // RRTTCCPP A session is established through SIP but it is not part of SIP. The term “Session” is considered to be “an exchange of data between an association of participants”. [RFC 3261 (p. 8)]

If SDP is used to describe a session, then the session is identified by the parameters Session-ID’s, and the addresses and the port numbers which are used for the multimedia session.

RTP shall always use an even-numbered destination port (2 * x) while the related RTCP-signaling shall occur on the following port (2 * x + 1). The actual port numbers to be used are negotiated between the peers through the very session control protocol (e.g. SIP, H.323) before RSVP is reserving the related resources for RTP-streams.

The RTCP which is mentioned in the headline is used to convey high level measurement reports to provide e.g. for jitter calculation.




TThhee RReeaall TTiimmee TTrraannssppoorrtt PPrroottooccooll ((RRTTPP aanndd RRTTCCPP)) • Operation of RTP and RTCP




TThhee RReeaall TTiimmee TTrraannssppoorrtt PPrroottooccooll ((RRTTPP aanndd RRTTCCPP)) Operation of RTP and RTCP The operation of RTP and RTCP is illustrated in the figure, using the example of three parallel data streams which are transmitted by the sender on the left side to an invisible receiver. The three parallel data streams carry video information ( on UDP-port 1), combined audio information ( on UDP-port 9 and 10) and whiteboard information.

Note: • Without previously invoking resource reservation through RSVP, RTP is not capable of providing real-time service. • RTP shall always use an even-numbered destination port ( 2 * x) while the related RTCP-signaling shall occur on the following port ( 2 * x + 1). • The actual port numbers to be used are negotiated between the peers through the very session control protocol (e.g. SIP, H.323) before RSVP is

reserving the related resources for RTP-streams.

• SSRC (Synchronization Source / 32 bit) Each sender is uniquely identified in an RTP-stream through its SSRC which is randomly selected by the sender and relates for instance to a camera.

• Payload Type / Media Type The media type which is conveyed within an RTP-stream is uniquely identified through the Payload Type-field which is part of the header of each RTP-frame.

• CSRC (Contributing Source / 32 bit) In our example, the two separate audio streams are de-multiplexed at the sender through a “mixer”. To still identify the modules which contributed to the combined audio stream, the two SSRC’s of the two audio separate audio devices is inserted in the header of the related RTP-frames as CSRC-field.

• Timestamp Information To provide for jitter calculations at the receiver side, each RTP-frame carries a 32 bit long timestamp which identifies the very time when the first data octet within that RTP-frame was sampled.




((11)) FFoorrmmaatt ooff tthhee RRTTPP--HHeeaaddeerr




((11)) FFoorrmmaatt ooff tthhee RRTTPP--HHeeaaddeerr Version This 2 bit long field identifies the version of RTP. The current version is ‘2’. The value ‘1’ is used by the first draft version of RTP and the value’ 0’ is used by the protocol initially implemented in the VAT-audio tool.

P-Bit (Padding) If the padding bit is set, the RTP-packet contains one or more additional padding octets at the end which are not part of the payload. The last octet of the padding actually identifies the number of padding octets (incl. this last octet). Padding may be needed by some encryption algorithms (e.g. IPsec) with fixed block sizes or for carrying several equally sized RTP packets in a lower-layer protocol data unit.

Note that in UMTS on the Nb- and Iu-cs-interface no padding is allowed.

Ext-Bit (Header Extension) This bit identifies whether the regular RTP-header is followed by a payload specific extension header.

Note that in UMTS on Nb- and Iu-cs-interface no extension header is allowed.

CSRC-Count This 4 bit long field identifies whether and how many CSRC’s are included in the header. Between 0 and 15 CSRC’s are possible.

Note that in UMTS on the Nb- and Iu-cs-interface, no CSRC’s must be present ( CSRC-Count = 0).

M-Bit (Marker) The M-bit may be used by an application to indicate certain events to the receiver like the end of a certain period or frame.

Note that in UMTS on the Nb- and Iu-cs-interface, the M-bit shall be ignored.

[RFC 1889, RFC 1890, 3GTS 25.414, 3GTS 29.414]




((22)) FFoorrmmaatt ooff tthhee RRTTPP--HHeeaaddeerr Payload Type This 7 bit long field identifies the format of the RTP payload. Some examples for audio and video coder types that are identified through the Payload Type field are indicated on the graphics page.

Note: • In UMTS on the Nb- and Iu-cs-interface the sending RTP-peer shall use a Payload Type between 96dec and 127dec. These Payload Types are

reserved for dynamic allocation by an application. • The end-to-end payload type values between users have to be negotiated through the SDP (Session Description Protocol). The respective SDP-

elements are nested into SIP-messages.

Sequence Number The 16 bit long sequence number increments by one for each RTP data packet sent and may be used by the receiver to detect packet loss and to restore packet sequence. The initial value of the sequence number is random (unpredictable) to make attacks on encryption more difficult.

Note that in UMTS on the Nb- and Iu-cs-interface the sending RTP-peer shall provide an increasing sequence number. The use of this sequence number by the receiver is optional.

[RFC 1889, RFC 1890, 3GTS 25.414, 3GTS 29.414]




((33)) FFoorrmmaatt ooff tthhee RRTTPP--HHeeaaddeerr Timestamp The 32 bit long Timestamp represents the time of sampling of the first octet in the payload of the RTP-frame. The initial value of the Timestamp is random and shall consecutively be incremented to allow jitter calculation at the receiver side. The resolution of the underlying clock should be bigger or equal to the used sampling period. Example: GSM Fullrate works with a sampling rate of 13 kbit/s, hence the used clock to determine the Timestamp value should be ≥ 13 kHz.

Note that in UMTS on the Nb- and Iu-cs-interface the sending RTP-peer shall deploy a clock frequency of 16 kHz for the Timestamp value. The use of the Timestamp information is optional for the receiver in UMTS (on Iu-cs- and Nb-interface).

Synchronization Source (SSRC) The 32 bit long Synchronization Source identifies the source of the information which is included in this RTP-frame. The SSRC is assigned by the sender and represents a random number. Examples for synchronization sources are a camera or a microphone.

Contributing Source (CSRC) Optionally, the RTP-header may include up to 15 CSRC’s of which each is 32 bit long. CSRC’s are necessary, if a mixer is deployed that multiplexes streams from different sources of the same type together. Example: A mixer is used to merge the audio data streams during a telephone conference that stem from the same network before the only one RTP-stream is transmitted to destinations outside the network. In such a case, each CSRC represents the original SSRC which contributed to this data stream. The SSRC-field in such a frame will be that of the mixer.

Note that in UMTS on the Nb- and Iu-cs-interface the sending RTP-peer shall never combine RTP-streams. Accordingly, the CRSC-list will always be empty.

Extension Header The optional extension header is for future use.

Note that in UMTS on the Nb- and Iu-cs-interface there must be no extension header.

[RFC 1889, RFC 1890, 3GTS 25.414, 3GTS 29.414]




EExxaammppllee ooff aann RRTTPP--FFrraammee

Length of the entire UDP-frame (incl. header / 8 octets). Considering the RTP-header length of 12 octets, the RTP-frame contains 160 data octets.

Even destination port number for RTP RTP-Port Number = 2 * x

related RTCP-port number = 2 * x + 1

A-law encoded PCM (as selected by the user)

No CRSC’s: ⇒ Content stems from only one source.




EExxaammppllee ooff aann RRTTPP--FFrraammee





TTaasskkss aanndd FFuunnccttiioonnss ooff RRTTCCPP




TTaasskkss aanndd FFuunnccttiioonnss ooff RRTTCCPP Quality Report Transfer The most important function of RTCP is the periodical transmission of quality reports. During an RTP-session, the receiver generates quality reports ( Receiver Report) which allow the computation of network jitter and the recognition of other network problems (e.g. congestion). If the receiver is also a sender and has transmitted any RTP-frames since the previous quality report was sent, a Sender Report will be generated instead of a Receiver Report.

Session Control Although session control will most likely be taken care of by another higher layer protocol, RTCP at least offers the possibility to communicate session control commands for an RTP-session. This relates in particular to the BYE-packet which can be used by a session participant to indicate that it will no longer be active.

CNAME SSRC Binding The SSRC used in RTP-headers may change during a conference which requires the binding of the SSRC to a unique identifier of the data source. The CNAME shall consist of a fully qualified domain name (e.g. [email protected]) or an IP-address.




EExxaammppllee ooff aann RRTTCCPP--FFrraammee ((SSeennddeerr RReeppoorrtt))

The 1.SSRC of the Destination of this Sender Report (in this case, only one SSRC exists)

Who sent this Sender Report

How many packets / octets have been sent by the originator of this Sender Report.

Number of Packets that have not been received by the sender (based on sequence number). The result can be negative, because duplicate receptions are counted twice.

The average jitter experienced by the originator of this report for any two consecutive packets received from the destination of this Sender Report. Example (if clock = 16 kHz) ⇒ 249/16000 = 15.56 ms




EExxaammppllee ooff aann RRTTCCPP--FFrraammee ((SSeennddeerr RReeppoorrtt))





TThhee HH..224488-- // MMEEGGAACCOO--PPrroottooccooll




TThhee HH..224488-- // MMEEGGAACCOO--PPrroottooccooll Introduction The H.248-protocol from the ITU-T is actually the same protocol as MEGACO which is published by the IETF. Therefore, MEGACO / H.248 is a joined development of both organizations.

Note: Organization specific amendments are provided through appendices.

⇒ The H.248 / MEGACO-protocol is necessary, if the call control functions shall be physically located in a different device than the media provision functions. Therefore, H.248 / MEGACO is also referred to as Gateway Control Protocol.

⇒ This is the case, if the MSC’s are replaced by MSC-Servers for the call control and MGW’s for the media provision. ⇒ We introduced this as split architecture some slides before. The split architecture bears important advantages when it comes to load sharing and the

possibility of dedicated MGW’s for different types of services (e.g. one MGW for multimedia services in the entire network).

Principles of Media Gateway Operation ⇒ Media Gateways operate through so called contexts. ⇒ Each context represents the association between different links that are interconnected through this context. ⇒ The links are called terminations and represent e.g. AAL-2- or IP/UDP/RTP-bearer channels. ⇒ Controlled by an MSC-S and through the H.248- / MEGACO-protocol, the MGW creates a context and adds terminations to this context. ⇒ During the lifetime of a context, the properties (e.g. bandwidth) of these terminations may be modified. New terminations may be added while others

are subtracted or moved to another context ( handover). [ITU-T H248, IETF RFC 3015, 3GTS 29.232]




CCoonntteexxttss aanndd TTeerrmmiinnaattiioonnss




CCoonntteexxttss aanndd TTeerrmmiinnaattiioonnss Terminations ⇒ Each termination represents an uni-directional or bi-directional information stream with variable properties like for example throughput rate, possibly

multiplexed media types, modem type or applicable inband signaling tones. ⇒ Each termination comes with its Termination ID (1 – 8 Octets) ⇒ Physically, a termination is based on a dynamically created AAL-2-channel or a pre-configured RTP-link between the MGW and another entity like

another MGW or the RNC. ⇒ The other termination type are the permanently present 64 kbit/s-channels towards the PSTN. These terminations are terminated in the so called Null

Context, if they are currently unused.

Contexts ⇒ As the figure illustrates, a number of terminations is associated to each other through a single context. ⇒ Each context within an MGW is described through its unique Context ID (4 Octets). ⇒ A context comes with a topology descriptor that describes how the configured terminations are interconnected to each other. [ITU-T H.248 (6.1), (6.2)]




TThhee HH..224488 CCoommmmaanndd SSeett




TThhee HH..224488 CCoommmmaanndd SSeett • Notify

The Media Gateway informs the MSC-Server of an event.

• Service Change The Media Gateway informs the MSC-Server that it is available again for service or that some terminations are about to be taken out of service or back into service.

• Add The MSC-Server adds a termination to a context.

• Modify The MSC-Sever uses the Modify-Command to change the properties of a termination (e.g. coder type).

• Subtract The MSC-Server subtracts a termination from a context.

• Move The MSC-Server moves a termination to another context (handover).

• Audit Value The Audit-Value-Command contains the previously requested properties of a set of terminations to the MSC-Server.

• Audit Capabilities The Audit Capabilities-Command will return the entire set of previously requested properties of a Media Gateway to the MSC-Server. [ITU-T H.248 (7), IETF RFC 3015 (7)]




EExxaammppllee ooff MMeeddiiaa GGaatteewwaayy OOppeerraattiioonn tthhrroouugghh HH..224488




EExxaammppllee ooff MMeeddiiaa GGaatteewwaayy OOppeerraattiioonn tthhrroouugghh HH..224488 The figure illustrates how H.248 signaling is used within the IMS by an MGCF to setup a new context within an MGW. This new context takes on two terminations.

• Termination 1 This termination is nothing more a UDP/IP-identification, consisting of an IP-address and a UDP-port number. After provision of these identifiers by the MGW, the MGCF can relay this information to the UA as target for the audio frames. In addition, the MGCF tells the MGW through H.248 which codec type shall be used on this termination, in this case AMR.

• Termination 1 Termination 2 represents a PCM-timeslot. Through H.248, the MGCF asks the MGW for the allocation of this PCM-timeslot and after its provision, the MGCF can embed the PCM-timeslot identifier into the IAM-message that it sends to the PSTN-exchange.




IIPPsseecc • IPsec in Transport Mode




IIPPsseecc The operation mode of a VPN depends mainly on how the two networks to be connected and the hosts to communicate among each other are configured. In that respect, a major role is given to IPsec which can operate in transport mode and in tunnel mode. Transport mode is only possible for end-to-end IPsec configurations, that is, IPsec is used all the way between host A and host B. On the other hand, tunnel mode is used if IPsec is implemented between host A and an IPsec gateway or between two IPsec gateways.

IPsec in Transport Mode In transport mode, the original IP-header is kept as is (except for fields that need to be changed like Protocol (ESP = 32hex / AH = 33hex) or Total Length. The actual security that is added depends on whether AH or ESP is used:

Transport Mode and AH ⇒ With AH, the entire IP-frame is authenticated and cannot be altered. Authentication is appended in form of an IPsec-header. However, everybody can

still read the IP-frame on its way through the network.

Note that due to the specifics of IP-frame some fields in the IP-header like Total Length and TTL cannot be authenticated because they are altered by intention.

Transport Mode and ESP ⇒ With ESP, the data part of the IP-frame is encrypted and (optionally) padded to avoid traffic estimations based on the sent frames sizes. If ESP shall

also provide authentication information, authentication data need to be added at the end of the IP-frame. In addition, there is also an IPsec-header added which is not encrypted but authenticated.

[RFC 2401 / RFC 2402 / RFC 2406]




IIPPsseecc iinn TTuunnnneell MMooddee




IIPPsseecc iinn TTuunnnneell MMooddee Tunnel mode is only possible between two IPsec-aware and enabled routers or firewalls. It provides more security than transport mode but requires more data to be sent.

Tunnel Mode and AH ⇒ With AH, the entire IP-frame is authenticated and cannot be altered. Authentication is appended in form of an IPsec-header. However, everybody can

still read the IP-frame on its way through the network. The new IP-header in the front contains the IP-addresses of the two IPsec-aware routers / firewalls.

Tunnel Mode and ESP ⇒ With ESP, the entire IP-frame is encrypted and (optionally) padded to avoid traffic estimations based on the sent frames sizes. If ESP shall also

provide authentication information, authentication data need to be added at the end of the IP-frame. In addition, there is also an IPsec-header added which is not encrypted but authenticated. Like with AH in tunnel mode, the new IP header in the front contains the IP-addresses of the two IPsec-aware routers / firewalls.

[RFC 2401 / RFC 2402 / RFC 2406]




VVPPNN wwiitthh IIPPsseecc iinn TTuunnnneell MMooddee aanndd TTrraannssppoorrtt MMooddee




VVPPNN wwiitthh IIPPsseecc iinn TTuunnnneell MMooddee aanndd TTrraannssppoorrtt MMooddee If IPsec and VPN-technology is deployed, the two operation modes transport and tunnel mode need to be distinguished:

VPN with IPsec in Tunnel Mode The standard mode of VPN-operation is the tunnel mode. In tunnel mode, two network operators have negotiated a service level agreement (SLA) and have exchanged relevant security information. Whenever needed or permanently, an IPsec tunnel is established between the two networks. The end users who communicate between the two networks remain unaware of the security mode and of any details related to security. Another implementation of tunnel mode is indicated through the blue dotted line: Remote Host A has established an IPsec tunnel to the security gateway of the corporate network. This implementation is almost end-to-end as the communication through the blue link is secured also on its way through network C.

The tunnel mode is very appealing for PLMN operators offering GPRS. For certain subscribers (to be identified through their IMSI), the PLMN-operator offers an IPsec-tunnel to the corporate network of these subscribers. Obviously, there can be as many tunnels to as many corporate networks as necessary.

VPN with IPsec in Transport Mode In transport mode we really have no VPN at all. As a matter of fact, in transport mode there needs to be an IPsec “tunnel” established between any two hosts on two different networks (in our example it is Remote Host B and Local Host B).

[RFC 2401 / RFC 2402 / RFC 2406]




TThhee IIPPsseecc AAuutthheennttiiccaattiioonn HHeeaaddeerr ((AAHH))




TThhee IIPPsseecc AAuutthheennttiiccaattiioonn HHeeaaddeerr ((AAHH)) The AH-header contains the following fields:

Next Header (8 bit) Is actually the Protocol-field of the original IP-frame that was authenticated. Example: if a TCP-frame is included in the IP-frame, the Next Header = ‘6’.

Payload Length (8 bit) The Payload Length field will contain the length of the IPsec-header in units of 4 octets (32 bits) – ‘2’. Example: If the IPsec-header has a length of 192 bit ( 6 x 32 bit), the Payload Length will be ‘4’.

Reserved (16 bit) The Reserved field is reserved and shall not be used. It has to be encoded with ‘00’.

Security Parameters Index (SPI) (32 bit) The Security Parameter Index is a pointer towards the Security Association (SA) that shall be used for that IP-frame. The SA has previously been negotiated upon setup of the IPsec-connection. Note that values 1 – 255dec are reserved by ICANN and must not be used. SPI value ‘0’ is only for local use and must also not be applied.

Sequence Number (32 bit) The Sequence Number shall be incremented per IP-frame sent and shall disable any possibility for replaying. The Sequence Number is initialized to ’00 00’ upon IPsec-connection setup.

Note: The Sequence Number is a modulo 232 counter that is not allowed to outrun its modulo. When the maximum value ( 4,294,967,294) of IP-frames has been transmitted in one direction, the two peers of the IPsec-connection shall negotiate another Security Association and reset the Sequence Number.

Authentication Data (n bit) The Authentication data will contain the Integrity Check Value (ICV) that validates and authenticates the IP-frame, using AH. Padding may be applicable and shall be supported by all implementations.

[RFC 2402]




TThhee IIPPsseecc EEnnccaappssuullaattiinngg SSeeccuurriittyy PPaayyllooaadd ((EESSPP))




TThhee IIPPsseecc EEnnccaappssuullaattiinngg SSeeccuurriittyy PPaayyllooaadd ((EESSPP)) The ESP-header contains the following fields:

Security Parameters Index (SPI) (32 bit) The Security Parameter Index is a pointer towards the Security Association (SA) that shall be used for that IP-frame. The SA has previously been negotiated upon setup of the IPsec-connection. Note that values 1 – 255dec are reserved by ICANN and must not be used. SPI value ‘0’ is only for local use and must also not be applied.

Sequence Number (32 bit) The Sequence Number shall be incremented per IP-frame sent and shall disable any possibility for replaying. The Sequence Number is initialized to ’00 00’ upon IPsec-connection setup. Like for AH, the sequence number is not allowed to outrun its modulo.

Payload Data (n bit) The original IP-frame

Padding (0 – 255 octets) Padding may be applied for the following reasons: 1. to suit the requirements of a given encryption algorithm 2. to pad to a 4 octet boundary 3. to conceal the length of the actual payload. If not demanded else by the encryption algorithm, the padding octets shall be encoded with ‘1’, ‘2’, 3’, ‘4’, ….

Padding Length (8 bit) Padding Length identifies, how many octets have been added for padding.

Next Header (8 bit) Is actually the Protocol-field of the original IP-frame that was encrypted (and authenticated). Example: if a TCP-frame is included in the IP-frame, the Next Header = ‘6’.

ESP Authentication Data (n bit) The Authentication data will contain the Integrity Check Value (ICV) that validates and authenticates the IP-frame, using the authentication algorithm that has been negotiated for ESP. Padding may be applicable and shall be supported by all implementations. [RFC 2406]




TThhee SSeeccuurriittyy AAssssoocciiaattiioonn ((SSAA))




TThhee SSeeccuurriittyy AAssssoocciiaattiioonn ((SSAA)) For every IPsec tunnel, at least two Security Associations (SA) needs to be established.

Per direction of an IPsec tunnel at least one Security Association needs to be established that defines the algorithms etc. to be used for IP-frame transmission in this direction.

⇒ The SA is identified through the SPI, which is also part of every IPsec-frame and which points to the SA to be used. ⇒ The SA is a second time identified through the destination IP-address and informs the receiver whether AH or ESP shall be used. ⇒ In addition the SA contains information about the algorithms to be used for AH and / or ESP.

[RFC 2401]




SSIIPP –– PPrroottooccooll SSttrruuccttuurree • Sublayers within SIP




SSIIPP –– PPrroottooccooll SSttrruuccttuurree Sublayers within SIP As illustrated in the figure, SIP itself is divided into a set of sublayers:

Transport Layer Control This part of the SIP handles all aspects of interfacing a SIP-software implementation towards lower layers of the protocol stack, particularly towards the transport layer. This transport layer is usually based on UDP but TCP also needs to be supported in every implementation. Note that the well known port number of SIP is 5060 for UDP, TCP and SCTP and 5061 in case of TLS. [RFC 3261 (18.1.1)]

Transaction Handling (UAC and UAS) This part comprises the UAC and UAS (User Agent Client and User Agent Server). Please note that SIP is entirely based on the concept of transactions. Each transaction consists of a) a request which is coming from the UAC and which is sent to the UAS and b) of the zero or more provisional responses and one final response. [RFC 3261 (17)]

Transaction User / Core The TU is controlling the establishment, handling and release of transactions. It controls whether responses are received in time and whether retransmissions need to be sent. It also interfaces the SIP-protocol stack towards the application, towards the user. [RFC 3261 (5)]




SSIIPP--NNeettwwoorrkk AArrcchhiitteeccttuurree • Overview




SSIIPP--NNeettwwoorrkk AArrcchhiitteeccttuurree Overview The figure illustrates a typical network which uses SIP for session management functions. Please note the following information: ⇒ We specifically distinguished between the orange colored lines that the data take on one hand and the green colored lines for SIP-signaling

messages. To be more precise: With the exception of an SBC (Session Border Controller), no SIP-proxy server or MGC deals with the data themselves.

⇒ The implicated physical network architecture with the two (SIP-independent) standard routers is an arbitrary possibility to interconnect the various network elements. We only added these routers to avoid irritations. Still, our focus is the logical network architecture. That’s why we hid these routers behind shades.

⇒ Sessions towards the PSTN require by default the interaction of soft switches ( MGC + MGW). ⇒ Sessions towards external PDN’s or to the internet will either traverse a firewall or they will traverse an SBC.

???? Question Section 5 ???? ⇒ Why are there SIP-proxies to relay SIP-messages? Why is this task not taken care of by simple IP-routers?




UUsseerr AAggeennttss




UUsseerr AAggeennttss The following list may not be exhaustive.

Dedicated VoIP-Phones With VoIP becoming more and more commonly used by corporations and residential customers, dedicated VoIP-phones are also becoming a typical SIP-user device. Although below the surface these dedicated VoIP-phones are nothing more but regular computers with a simple operating system and a SIP-softphone, we considered them as important enough to be listed separately.

Mobile Stations Mobile stations with an integrated SIP-client will be the typical user devices of tomorrow’s 3GPP-networks. This is obvious, since 3GPP bases its entire IMS session control on SIP. We list the dedicated mobile station separate.

Softphones The best known and most widespread SIP user agent is certainly the softphone. These softphones are nowadays available for literally every operating system and every platform. Probably the best about them is that they usually come free-of-charge and that they can be downloaded from the internet. In the figure we illustrate a PDA and a desktop PC as bearers for softphones. Note that the PDA with softphone is still a different type of user agent than the dedicated mobile station since the PDA will tendentiously allow much more software configuration and updating than the mobile station. That is, the mobile station and the dedicated VoIP-phone are rather telephones or communication devices while the PDA still represents a generic computer with add-on SIP capability.

In the long run, softphones will mutate to become generic devices supporting any potential SIP and IMS-application.

Game Boxes The flexibility and range of SIP user agents becomes obvious when comparing the previous devices with the game box which allows remote users to play games against each other or against application servers.

Set Top Boxes Another type of SIP user agent is a set top box. Set top boxes are no telephones but they represent the other end of SIP user agents, dedicated for VoD or audio on demand.

Note that the support of both, UDP and TCP as transport layer protocols has been mandated for UA’s with RFC 3261 (18).




SSIIPP--SSeerrvveerrss




SSIIPP--SSeerrvveerrss Stateless SIP-Proxy Server Unlike stateful proxies, stateless proxies do not maintain or observe the state of a SIP-transaction which is routed through them. That is why we did not include any UAC or UAS functions into the stateless proxy. Stateless proxies will also not retransmit SIP-messages. Still, stateless SIP-proxies will also inspect the content of SIP-messages and they may add header fields autonomously. However, like stateful SIP-proxies, a stateless SIP-proxy is not allowed to autonomously generate SIP-Requests. In contrast to stateful SIP-proxies, the stateless SIP-proxy cannot generate CANCEL-Requests. And stateless SIP-proxies cannot redirect a Request: INVITE-message to a new direction if they receive a redirection response ( Response: 3XX) from a redirect server. And more, stateless proxies cannot be used for forking. More details about stateless SIP-proxies follow later in this section. [RFC 3261 (16.11)]

Stateful SIP-Proxy Server In general, a SIP-proxy is a device which is addressable by a SIP-User Agent or by another SIP-proxy server through a SIP-URI (Uniform Resource Identifier). Usually, SIP-proxies will relay SIP-messages somewhat closer to their final destination. However, with one exception a SIP-proxy server is not allowed to generate SIP-requests autonomously. The exception are Request: CANCEL-messages which need to be generated by the proxy server e.g. after a called SIP-device has been ringing for some time and now the call shall be forked to the next possible device. Stateful SIP-proxy servers maintain and observe the state of every transaction which is routed through them. Note that they do not maintain dialog or call state, this is the domain of B2BUA’s. Only stateful proxies can be used as redirect server or as registrar. And only stateful proxies can be used for forking. [RFC 3261 (16.2)]

Proxies may switch between stateless and stateful operation depending e.g. on the authentication state of a requester. Hence, the boundary between stateless and stateful SIP-proxies is fuzzy.

SBC (Session Border Controller), B2BUA (Back-to-Back User Agent)

Note that the terms “Session Border Controller” or “SBC” have no representation in IETF standards as such.

In practice, SBC’s represent the combination of B2BUA’s (which actually have been defined in RFC 3261) and media gateway like equipment that allows for media stream observation and even modification (e.g. change of codec type). Examples of SBC operation follow on the next side. Most importantly, B2BUA’s represent SIP-proxy servers that act like user agents. That is, B2BUA’s can autonomously generate SIP-Requests and they can autonomously terminate a session ( through a Request: BYE) which is something that a SIP-proxy cannot do. When B2BUA’s are also used for media transversal then they become SBC’s.




SSppeecciiaall SSIIPP--SSeerrvveerrss




SSppeecciiaall SSIIPP--SSeerrvveerrss Registrar A SIP-registrar is at least a stateful SIP-proxy server ( RFC 3261 p.50) with an additional database to allow for the registration of user agents. This database will be accessed in case of incoming calls to locate a user agent and to route a call to their current point of presence. A registrar may also be a B2BUA which applies in case of the S-CSCF of the IMS. [RFC 3261 (10.1)]

Application Server Application Servers are SIP-User Agents that allow other SIP-User Agents to access services like games or databases through this server. A typical example of an application server is a VoD-Server or a presence server.

Media Gateway Controller An MGC is a logical network element that may deploy SIP-signaling ( or BICC, or…) on one side of the network and ISUP to the other side ( towards the PSTN). MGC’s are sometimes also referred to as “soft switch” or “call agent”. As the figure illustrates, the media gateway controller fulfills most importantly the two functions 1. Controlling the Media Gateway and 2. Converting from SIP-signaling into ISUP and vice versa. [RFC 3398 (p. 3)]

Application Layer Gateway (ALG) ALG’s are no network elements by themselves nor do they represent actual SIP-servers. They are rather integral part of other network elements like NAT-routers or other SIP-servers to allow for some SIP-specific information conversion. Well known examples for information conversion are NAT-specific adjustments of SIP-messages or IP-version Interworking [3GTS 23.228 (4.6.5), (5.18)]




OOppeerraattiioonn ooff SSttaatteelleessss SSIIPP--PPrrooxxyy SSeerrvveerrss




OOppeerraattiioonn ooff SSttaatteelleessss SSIIPP--PPrrooxxyy SSeerrvveerrss The figure illustrates the typical use of a stateless SIP-proxy: It acts similar to a tandem switch or STP (Signaling Transfer Point) in the PSTN as a relay among different private IP-networks.

Advantages of Stateless SIP-Proxies ⇒ Stateless operation provides for the maximum throughput of SIP-messages. Neither memory nor any processing power needs to be spent on

transaction state monitoring. This makes stateless operation ideal to cope with DoS-attacks (Denial of Service). SIP-proxies may initially operate stateless, taking on initial REGISTER-messages and switch to stateless operation after credentials have been provided.

⇒ The capacity of SIP-servers can be measured in number of “Calls per Second”, “Transactions per Second” or “Messages per Second” that can be simultaneously handled by such a server.

Conclusion: Stateless SIP-Proxies are geared for capacity.

Disadvantages of Stateless SIP-Proxies ⇒ Since no transaction state is held in a stateless SIP-proxy server, forking is impossible. The term “forking” relates to the relay of an incoming Request:

INVITE not only to a single UAS but to multiple UAS’s. Forking represents the parallel search for an invited party at different devices simultaneously. ⇒ Stateless SIP-proxies cannot generate or keep track of billing information. ⇒ Stateless SIP-proxies cannot use TCP as transport protocol. ⇒ Stateless SIP-proxies cannot fork. ⇒ Stateless SIP-proxies cannot react upon a redirection response message.

Conclusion: Advanced operation requires stateful SIP-Proxies.

Other Assets of Stateless SIP-Proxies ⇒ Despite the fact that no transaction state is held in a stateless SIP-proxy server, it must still add a “via:”-header field with a unique branch-parameter.

In the design of a stateless SIP-proxy server, special measures have to ensure that the branch-parameter is the same for retransmissions of a SIP-Request message [RFC 3261 (p.116/p.117)].

⇒ Like stateful SIP-proxy servers, stateless SIP-proxy servers may add SIP-header fields to SIP-messages, including the “Record-Route:”-header field which ensures that all following requests within that dialog also traverse this SIP-proxy server.




OOppeerraattiioonn ooff SSttaatteeffuull SSIIPP--PPrrooxxyy SSeerrvveerrss




OOppeerraattiioonn ooff SSttaatteeffuull SSIIPP--PPrrooxxyy SSeerrvveerrss Stateful SIP-proxies come with a lot more functionality than stateless SIP-proxies as the figure indicates. These additional capabilities are:

• Forking Forking means that a proxy server can either sequentially or simultaneously relay an incoming session establishment request to different target destinations of a single user agent. A single user agent may be reachable through a home phone, an office phone and a mobile phone simultaneously. We will later provide more details and examples about forking.

• Maintains Transaction State Only stateful proxies use timer C to observe the state of a transaction and only stateful proxies are able to retransmit SIP-requests (which usually does not happen as the user agent should trigger the retransmission). Still, the observation of the transaction state allows for the use of stateful proxies for charging purposes which the stateless proxy cannot do.

• Can use TCP as Transport Protocol Although UDP is the default transport protocol for SIP-messages, TCP may be necessary if TLS (Transport Layer Security) shall be applied. Note that secure links can alternatively be provided over UDP if IPsec is used. Besides, TCP may be desirable to avoid NAPT-associations (IP-address port number) from expiring too fast (expiration time with UDP ≈ 5 minutes / TCP ≈ 24 hours [RFC 4008].

• Can act as Registrar Only stateful SIP-proxies can act as registrars because they need to maintain transaction state. This is due to the fact that a registrar needs to be able to distinguish consecutive registrations of the same user agent ( which carry incremental “CSeq:”-numbers) from retransmitted registration attempts ( which carry the same “CSeq:”-number).

• Can act as Redirect Server A redirect server is a proxy which responds to an incoming SIP-request message (most likely a Request: INVITE) with a final response: 3XX. All response codes 3XX are called redirection responses. Every 3XX-response includes a list of alternative SIP-URI’s to be contacted instead to reach the desired user. This usually triggers a second transaction by the recipient of the 3XX-response which, however, will leave the redirect server out of the communication chain. Obviously, a redirect server needs to obtain its routing information from some database so usually a redirect server is also a registrar. [RFC 3261 (8.3)]




OOppeerraattiioonn ooff RReeggiissttrraarrss




OOppeerraattiioonn ooff RReeggiissttrraarrss The figure illustrates the operation and tasks of a registrar. End users register their current “address-of-record” / their current IP-address(es) to a special stateful SIP-proxy. The specialty of this SIP-proxy is the database that will store the relationship between the end user’s SIP-URI and the IP-address for a certain time period. This time period is configurable. It is also interesting that end users can simultaneously register from different devices and therefore from different IP-addresses, possibly with different preference (e.g. mobile device, office phone, home phone and voicemail as last resort). The registration to the registrar allows other end users to obtain routing information from the registrar in case that a dialog shall be established to that end user. [RFC 3261 (10.1)]




OOppeerraattiioonn ooff RReeddiirreecctt SSeerrvveerrss




OOppeerraattiioonn ooff RReeddiirreecctt SSeerrvveerrss Introduction A redirect server is a SIP-proxy server or a SIP-registrar that responds an incoming Request: INVITE with a Response: 3XX (e.g. 302-“Moved Temporarily”). This response includes in the “Contact:”-header field the one or more current user device’s addresses that shall be contacted instead or directly by the originating party.

Procedure Description As illustrated in the figure, UserA sends an INVITE / sip: [email protected] to its SIP-proxy server A ( message 1). The proxy server invokes the help of one or more DNS-servers to resolve the IP-address of nebelhorn.de ( message 2, 2a and 3). Consequently, proxy A relays the INVITE-message to SIP-proxy server B ( message 4). ⇒ Proxy B sends the INVITE-message to the responsible SIP-registrar ( message 5). ⇒ The SIP-registrar will issue a final Response: 302-“Moved Temporarily” which traverses all the way back to UserA ( message 6, 7, 8) and which

ultimately is the message that will trigger the redirection of the request.

Note the comment on the graphics slide: Either SIP-proxy server could react on the Response: 302-Moved Temporarily autonomously and redirect the Request: INVITE to its new destination directly.

⇒ As mentioned before, this response message type always carries in its “Contact:”-header field the current IP-address or FQDN where the requested part can be found. In our case, this is the fully qualified domain name desktop500.nebelhorn.de.

⇒ Before another INVITE to UserB at desktop500.nebelhorn.de can be sent, UserA needs to finish the previous INVITE-transaction by issuing a Request: ACK and sending it to the registrar in local IP-network 2 ( message 9, 10, 11).

⇒ To be able to send an INVITE-message to sip: [email protected], UserA invokes the support of one ore more DNS-servers to resolve the FQDN into an IP-address ( messages 12, 12a and 13).

⇒ Finally, UserA can send a Request: INVITE / sip: [email protected] directly to UserB. No SIP-proxy server is used ( message 14).

Redirection is well suited to reduce the load of SIP-proxies but it is not well suited for carrier based services which require at least a SIP-proxy server for charging purposes.

[RFC 3261 (8.3)]

???? Question Section 6 ???? ⇒ If either SIP-proxy would autonomously redirect the INVITE to its new destination, would this be a stateful or a stateless proxy server or both?




((11)) OOppeerraattiioonn ooff FFoorrkkiinngg SSIIPP--PPrrooxxyy SSeerrvveerrss ((aallwwaayyss ssttaatteeffuull))




((11)) OOppeerraattiioonn ooff FFoorrkkiinngg SSIIPP--PPrrooxxyy SSeerrvveerrss ((aallwwaayyss ssttaatteeffuull)) ⇒ The figure illustrates a case in which the forking proxy is not the registrar but it is an intermediate SIP-proxy server that receives a Response: 3XX for

a Request: INVITE and autonomously redirects the Request: INVITE to all contact-addresses received within the Response: 3XX. ⇒ Of course, the registrar could have done the same in which case the registrar would be the forking proxy. This is an implementation issue.

• Bullet 1: As illustrated, the call starts with User A sending a Request: INVITE to its proxy server. The invitation is for Mary with the SIP-URI sip: [email protected]. This SIP-URI is the only information that User A has about Mary.

• Bullet 2: The SIP-proxy relays the Request: INVITE towards the registrar of Mary and receives back a Response: 3XX (e.g. Response 302-Moved Temporarily which includes a list of addresses to be contacted instead. This list of addresses is 1. sip: [email protected], 2. sip: [email protected] and 3. sip: [email protected]. Note that Mary’s registrar operates as redirect server. Having received the Response: 3XX-message, the SIP-proxy has to reply a Request: ACK-message which is not shown for simplicity in the figure.

• Bullet 3: The proxy server uses the received contact information and sends out the invitation again but this time to all three received contact addresses / devices simultaneously. Consequentially, all three devices will start ringing more or less simultaneously.

This process of trying to reach the called user on different devices at the same time is called simultaneous forking.

• Bullet 4: Device 2 is the only one or the earliest one to send a Response: 200-OK to the forking proxy server. As illustrated, this successful response is relayed towards User A immediately. Accordingly, User A sends a Request: ACK through the forking proxy towards Mary’s device 2. The session is active between User A and Mary’s device 2 and media data are exchanged. However, since forking occurred, the still open INVITE-transactions towards device 1 and device 3 need to be handled. Please refer to the next page. [RFC 3261 (16.7.10)]




((22)) OOppeerraattiioonn ooff FFoorrkkiinngg SSIIPP--PPrrooxxyy SSeerrvveerrss ((aallwwaayyss ssttaatteeffuull))




((22)) OOppeerraattiioonn ooff FFoorrkkiinngg SSIIPP--PPrrooxxyy SSeerrvveerrss ((aallwwaayyss ssttaatteeffuull)) • Bullet 5:

As soon as one device (in this case device 2) has returned a Response: 200-OK, the forking proxy shall send Request: CANCEL-messages for all still pending invitations.

• Bullet 6: Since CANCEL represents its own transaction, each Request: CANCEL-message shall be responded to by a Response: 200-OK.

• Bullet 7 and 8: From the protocol perspective, there are still final responses outstanding for the two Request: INVITE-messages. Accordingly and as a consequence of the cancellations, device 1 and 3 each issue a final Response: 487-Request Terminated which relate to the received Request: INVITE-messages. The forking SIP-proxy needs to end the INVITE-transactions by sending Request: ACK-messages to device 1 and 3.




OOppeerraattiioonn ooff BB22BBUUAA aanndd SSBBCC




OOppeerraattiioonn ooff BB22BBUUAA aanndd SSBBCC The figure illustrates some applications of an SBC. And the figure also illustrates the two-folded nature of an SBC: It consists of a B2BUA plus a media gateway for data mediation. The following list of functions of the B2BUA is by definition not exhaustive:

• Network Address Translation NAT allows using private IP-addresses network internally. Hence, the B2BUA will replace all internal IP-addresses by its own public IP-address. We will later talk in detail about SIP and NAT. Note that with respect to the NAT-function, the IETF uses the term ALG (Application Layer Gateway).

• Topology Hiding Operators may want to hide the internal network structure from externals. This relates particularly to the inherent exposure of SIP-proxy host names within the “Via:”-header field. The B2BUA will simply tokenize all previous entries in the SIP-header field before a SIP-message is forwarded to an external destination.

• Dialog and Session Termination Operators have a need to be able to intercept and possible even interrupt ongoing dialogs and sessions (e.g. if a prepaid service expires). We will later illustrate the possible application of this in more detail.

• Autonomous Dialog Management and SIP-Parameter Alteration Regularly, the B2BUA establishes two apparently independent dialogs between two user agents (dialog 1 and dialog 2). This means that the B2BUA generates SIP-Requests and even entire dialogs autonomously. Also not possible for a SIP-proxy server is a reduction of the “expires”-parameter in case of registrations of user agents which enforce a more frequent re-registration. This is standard operational behavior for B2BUA’s.

And, in the media gateway:

• Network Address Translation The SBC enforces the media streams to be routed through itself. Additionally, NAT allows for the internal use of private IP-addresses.

• Code Type Switching Operators are able to restrict the use of media codecs to only a few types and they can convert to a different codec type before the data is relayed.

• Media Stream Observation Operators may want to observe media streams (e.g. for legal interception or for ungraceful session release).




EExxaammppllee:: VVooDD--ffoorr aa MMoobbiillee CClliieenntt wwiitthh lliimmiitteedd AAcccceessss RRaatteess




EExxaammppllee:: VVooDD--ffoorr aa MMoobbiillee CClliieenntt wwiitthh lliimmiitteedd AAcccceessss RRaatteess The figure illustrates a typical use-case of an SBC: ⇒ A mobile client has requested a movie from a VoD-server somewhere outside the scope of the current network operator. ⇒ The SBC with the network’s IMS intercepts all outgoing SIP-signaling messages and alters their content if necessary or appropriate (e.g for topology

hiding, NAT, etc.). ⇒ One possibility is that the SBC acts as B2BUA on the SIP-level, representing the UAS for the mobile client UAC and setting up an independent

second dialog towards the VoD-server. This case is illustrated in the figure. ⇒ This allows the SBC to enforce the network internal use of a low bit rate video codec like MPEG4 rather than using MPEG2 which shall in the example

be the only video format that the VoD-server supports. ⇒ This codec enforcement works through the adjustment of the requested codec types: That is, even if the mobile client indicated the wish to use

MPEG2, the B2BUA will replace this SDP-parameter by the already mentioned low bit rate codec in its response to the mobile client. ⇒ In the second dialog towards the VoD-server, the SBC leaves the codec type unchanged but the MGW within the SBC will be the receiver of the video

data which origin from the VoD-server. ⇒ The MGW then needs to transcode from MPEG2 to the low bit rate video codec and issue this data towards the mobile client.




OOppeerraattiioonn ooff EEvveenntt SSeerrvveerrss




OOppeerraattiioonn ooff EEvveenntt SSeerrvveerrss Introduction Event servers most importantly are a specific type of SIP-AS’s (Application Servers). They can be used by user agents and by other SIP-AS’s (called users in the following) to be informed ( notified) about events which occur to user agents. In our figure, the users are illustrated on the right side while the event server itself is located in the middle. The list of possible events is obviously not exhaustive.

Event Subscription The notification of events through an event server requires the previous subscription of users for these events towards the event server. To achieve this, the user has to send a Request: SUBSCRIBE-message towards the event server. This message specifies the event itself and event parameters (e.g. under which circumstances a notification shall be done). Such subscriptions expire after configurable times and require refreshing Request: SUBSCRIBE.

Event Publishing and Notification The user agent for which the event shall be monitored has to update the event server by sending a Request: PUBLISH-message to the event server when an event occurs. Example: the user agent has finished a session and is now available to setup a new session. This in turn may trigger a notification to a user who wants to call that user agent or it may trigger a message waiting indication (through a Request: NOTIFY) to the same user agent who published its new state that there are messages on the voicemail. [RFC 3265]

The Presence Event Just another event is the “presence” state of a publishing subscriber. The presence event has created a lot of attention as it allows for many interesting applications like intelligent address books that illustrate whether a party to be called is “online” in the first place. The event package for “presence” has been described in RFC 3856. If the presence event is amended by other events like “movement” ( draft-ietf-sip-location-conveyance-01.txt) it becomes also interesting for location based services. [RFC 3856]




SSoofftt SSwwiittcchheess aanndd tthheeiirr CCoonnttrroolllleerrss




SSoofftt SSwwiittcchheess aanndd tthheeiirr CCoonnttrroolllleerrss ⇒ Definitely very important components of next generation networks are the media gateways which are frequently also called “soft switches”. ⇒ As the figure illustrates, media gateways are controlled by a media gateway controller (MGC). In the 3GPP-terminology this MGC becomes the MGCF

(Media Gateway Control Function).

Media gateways and media gateway controllers are required to interface IP-based communication towards the legacy PSTN.

⇒ The control function between MGC and MGW is performed through a protocol called H.248 ( ITU-T terminology) or MEGACO ( IETF-terminology / RFC 3015).

⇒ The H.248 / MEGACO protocol allows for the seizure and release of resources that are controlled by the media gateway. This also relates to the control and conversion of codec types (AMR, PCM a-law, PCM µ-law, …).

⇒ Accordingly, the MGC terminates the call control signaling information from both sides: The SS7-signaling (ISUP) from the PSTN as well as the IP-based call or session control information (usually H.323 or SIP).

⇒ On the other hand, the MGW terminates all PCM-links ( timeslots on the different PCM-trunks) and it is able to interconnect these PCM-links to packet-switched resources on the IP-network side (usually identified through the combination of Source IP-Address / Source UDP-Port Number and Destination IP-Address / Destination UDP-Port Number).

⇒ As the figure illustrates, media gateways and media gateway controllers usually are interconnected to the IP-network through more than one NIC (Network Interface Card) which means through more than one IP-address. This is done for load balancing and congestion control.

The figure tries to indicate what makes soft switches so appealing to network operators: • They are connected to the IP-network simply through standard IP-network cables (e.g. RJ-45). No error-prone patch panel wiring is necessary. • They usually do not require sophisticated configuration but they use some auto configuration to obtain IP-addresses etc.. • They usually have a smaller footprint than their predecessors, the public exchanges of the SS7-world.




SSuummmmaarryy

• The SIP-Network Architecture is dominated by SIP-Servers Examples are stateful and stateless SIP-proxy servers.

• Specialized SIP-Servers are Registrars and Redirect Servers Stateful SIP-proxy servers may “fork” INVITE-Requests to multiple destinations.

• Professional SIP-based networks also require soft switches Soft switches allow for the interconnection towards the PSTN.

• Back-to-Back User Agents and Session Border Controllers represent more powerful SIP-Servers The SBC has not been defined in the specifications, yet, it is required to provide carrier based services.

• Various Application Servers may be there to provide IN-related and additional services Typical application servers are event servers like the presence server.




SSuummmmaarryy • The SIP-Network Architecture is dominated by SIP-Servers

Stateful SIP-proxies are better suited, if advanced services shall be provided (e.g. forking). Stateless SIP-proxies are geared for capacity.

• Specialized SIP-Servers are Registrars and Redirect Servers Registrars are needed to allow subscribers to register to the network. One user may register several devices simultaneously which allows for forking incoming invitations for this user to all registered devices at the same time.

• Professional SIP-based networks also require soft switches Soft switches are the combination of media gateway and media gateway controller. Within the MGC, the conversion between SIP and ISUP takes place.

• Back-to-Back User Agents and Session Border Controllers represent more powerful SIP-Servers We illustrated the need for an SBC with respect to NAT and media stream tailoring. At a later stage we shall illustrate more applications for the SBC like media stream observation.

• Various Application Servers may be there to provide IN-related and additional services Note that application servers are also accessed by other servers and by user agents through SIP, irrespective of the session type (audio, video, other) to be established.




WWhhyy SSIIPP iiss uusseedd aanndd nnoott HH..332233 oorr ootthheerr AAlltteerrnnaattiivveess ……

… SIP has the advantage that it can be used for end-user signaling and between nodes in the backbone Even the same message types and parameters are used for both types of messaging.

… SIP together with SDP is simpler than the H.323-protocol suite The term “simple” relates to the fact that SIP and SDP are ASCII-based protocols with SIP using the same format as the well-proven HTTP. On the other hand, H.323-protocols use binary formatting with ASN.1 PER (Packed Encoding Rules).

And, perhaps most importantly:

… Any H.xyz standard smells too much like a non-IP-driven protocol After all, the SIP-standard is written in RFC’s and it is therefore an output of the IETF (and not of the ITU-T or ETSI).




WWhhyy SSIIPP iiss uusseedd aanndd nnoott HH..332233 oorr ootthheerr AAlltteerrnnaattiivveess?? SIP has the advantage that it can be used for end-user signaling and between nodes in the backbone Please compare to the PSTN: Within the backbone network, ISUP, SCCP, TCAP and IN or CAMEL are used and between the network and the subscriber we use LAPD and Q.931-signaling (in mobile networks the call control protocol is used).

SIP together with SDP is simpler than the H.323-protocol suite Despite this widespread assumption one has to accept that SIP and SDP are already becoming quite complex and complicated with the amendment of many new features to address the various new requirements. SIP and SDP will have to prove in practice whether they can really provide the same or even better communication services at a lower price.

Additional Information

⇒ The Packed Encoding Rules (PER) that we mention on the graphics slide allow the compression of specifically encoded ( ASN.1) text into binary, machine readable constructs. That is, also H.323-protocols are written in plain ASCII-text but converted through the PER into binary code.

⇒ PER is described in the ITU-T recommendation X.691.

Any H.xyz standard smells too much like a non-IP-driven protocol The H.323-protocol suite is largely based on ISUP- / Q.931-like messages like SETUP, CALL_PROC and is very much focusing on VoIP-applications. The future will reveal whether IETF-based standards are able to provide a telephone service which is as reliable as the PSTN.

Altogether, the H.323-protocol suite is best suited and tailored for plain voice over IP (VoIP). SIP on the other hand is a session control protocol which scope is therefore much wider. Note that in addition SIP allows for the embedding of XML-content into the SIP-message bodies.




SSccooppee ooff SSIIPP




SSccooppee ooff SSIIPP The figure illustrates the major tasks and functions of SIP which are:

Session Establishment SIP-signaling messages are used to establish a session between two peers or between an originator and various other parties (e.g. conference call). In that respect it is important to understand the independence between the signaling protocol SIP and the session to be established. This independence is remarkable when comparing SIP with other “call control” protocols like the ISDN protocols that have been tailored to establish speech or fax calls between users.

Clarification of the Term “Session” SIP serves as a means to establish sessions; we understand this from the previous bullet. In the SIP-terminology a session is defined as “an exchange of data between an association of participants” [RFC 3261 (page 8)]. This abstract definition should be supported at this time through some practical examples: Sessions established through SIP include basic voice calls or video calls between two or more parties, real-time games between users or between a user and an application server where SIP is used in its genuine function to orchestrate the session setup, management and release. Yet another session example is instant messaging (IM). Obviously, this list is not exhaustive.

Session Modification During a session it may become necessary or it is desired by either party to modify that session. Typical examples for session modification are the addition or reduction of a video component during a call or the addition or removal of participants. Although SIP does not contribute anything to most sessions, it will jump in again for performing this session modification.

Session Release Eventually, any session has to be released. SIP is invoked again to perform this action.




PPhhiilloossoopphhyy ooff SSIIPP--OOppeerraattiioonn • Session Establishment Phase




PPhhiilloossoopphhyy ooff SSIIPP--OOppeerraattiioonn Session Establishment Phase ⇒ The figure illustrates it: During the session establishment phase, the two UA’s may require a number of SIP-proxy servers to route and handle session

establishment requests. At this time, we don’t want to be specific about the type of SIP-proxy. ⇒ Note the two layers: The SIP-layer requires physical transport of the SIP-messages through the IP-layer and through the routers which are used there.




SSeessssiioonn CCoommpplleettiioonn PPhhaassee




SSeessssiioonn CCoommpplleettiioonn PPhhaassee ⇒ Note that the SIP-proxy servers drop out of the communication chain. This is the regular way of processing in SIP. That is, after the setup of the

communication channel, there is no more involvement required of the proxies. ⇒ This statement is, however, only true if standard conditions apply: No NAT, no media conversion is needed, no IP-version Interworking between the

two peers…)

Note that operators may also configure certain means to assure that the proxies remain in the signaling chain and are also receiving keep-alive messages periodically from one or both peers.




SSeessssiioonn AAccttiivvee PPhhaassee




SSeessssiioonn AAccttiivvee PPhhaassee ⇒ While the session is active, the two peers exchange media data, e.g. embedded into RTP-frames. These data frames are packed into IP-frames of

which every single one can take a different route between the two UA’s. ⇒ Note that there is no SIP-proxy in between.




CCoommppaarriissoonn bbeettwweeeenn SSIIPP aanndd HHTTTTPP




CCoommppaarriissoonn bbeettwweeeenn SSIIPP aanndd HHTTTTPP • To get a better feeling about SIP a comparison with HTTP is helpful

⇒ HTTP is the protocol behind and underneath web browsing and it is extremely prominent on the World Wide Web. HTTP enables all applications on the internet that are accessed through a web browser. Typical examples for web browsers are the Internet Explorer or Firefox.

⇒ The message format, the request/response philosophy and many response codes (e.g. 200-OK) of SIP have been inherited from HTTP. One can legitimately say that SIP is at least formally based on HTTP.

⇒ Note that HTTP is the transfer and control protocol for the “content” but the content itself is not HTTP. It consists of HTML-/XML-encoded information which in turn may incorporate other information like JAVA or JAVA-SCRIPT.

Note: • In difference to SIP, HTTP is also used to embed the previously mentioned “content” into HTTP-packets for its transfer between peers. • In HTTP, a “session setup” occurs inherently and static with the first HTTP-message exchange that identifies the capabilities of both peers and which

clarifies whether these peers can exchange “content” in the first place. In other words, the actual session setup phase is very simple.

⇒ Usually, a client or user accesses an HTTP-server from his/her web browser to download a website from that server to the browser and afterwards the client will, possibly interactive, process the downloaded content through his/her web browser.

⇒ SIP on the other hand uses a “user client device” to manage a session between that “user client device” and other “user client devices” or towards an application server.

Problem for SIP: • The vast number of possible session types (e.g. telephone calls, games, location services using RTP, MSRP or SRTP as bearers) to be established

through SIP makes it difficult to provide or define a standardized generic “user client device” like the web browser for HTTP to support all possible session types.

• Still, we are almost convinced that such a definition will occur to enable the development of an unlimited number of applications on top of SIP. After all, it was only the invention of the web browser about 10 years ago with its GUI which made the internet gain speed for applications beyond mail.

Conclusion: Those who want to use SIP as basis for application development need to clarify in a first step which additional features SIP provides compared to HTTP (e.g. multi-party vs. two-party, user-to-user communication is possible…). In a second step a generic “SIP-browser” may need to be invented that will allow for the necessary economies of scale and that will enable the application development itself rather seamlessly.




SSiimmppllee EExxaammppllee ooff aa SSIIPP--SScceennaarriioo:: VVooIIPP CCaallll SSeettuupp wwiitthh SSIIPP • Overview




SSiimmppllee EExxaammppllee ooff aa SSIIPP--SScceennaarriioo:: VVooIIPP CCaallll SSeettuupp wwiitthh SSIIPP Overview The figure illustrates a very simple example for SIP-session establishment on our intranet. Both parties have a SIP-softphone installed and are connected to the intranet and the (private) IP-address of each party is known to each other party. In this example, we like to highlight the basic call establishment rules of SIP. ⇒ The Request: INVITE-message is sent to the called party. Most importantly, it contains the SDP-descriptors that describe this session and the media

to be used from the perspective of the calling party. That means these SDP-descriptors tell the called party in case of a voice call, on which port number the calling party is prepared to receive information from the called party using which audio codec(s).

⇒ The Response: 100 (Trying)-message is quite redundant in this case where both parties are connected directly to each other. If a session setup ranks over various networks, each SIP-proxy server will respond to an INVITE-message with 100 (Trying), if the INVITE-message can be processed.

⇒ As soon as the called party is alerted (the softphone indicates incoming call to the user), the Response: 180 (Ringing)-message is sent back to the calling party.

⇒ When the called party accepts the call, a Response: 200 (OK)-message is sent to the calling user. This message also contains the SDP-description from the called party’s perspective. That means these SDP-descriptors tell the calling party in case of a voice call, on which port number the called party is prepared to receive information from the calling party using which audio codec(s).

⇒ The calling party acknowledges the reception of this final response by sending a Request: ACK-message to the called party. ⇒ The call is active. ⇒ When either party intends to release the call a Request: BYE-message is sent to the peer. The reception of this message and the end of the call is

indicated through a final Response: 200 (OK)-message.




SSuummmmaarryy:: SSoommee SSIIPP--TTeerrmmiinnoollooggyy • Message Types

Only two message types exist: Requests and Responses. Almost every Request must be responded by at least one Response.

• SIP-Methods The SIP-method defines a transaction. Many different method types have been defined of which the indicated INVITE-, ACK- and BYE- methods are only examples.

• Response Types There are provisional and final responses. Final responses terminate a transaction and they indicate whether a transaction was successful or not. Many different status codes exist to distinguish different transaction outcomes.




SSuummmmaarryy:: SSoommee SSIIPP--TTeerrmmiinnoollooggyy Message Types In general, SIP-Requests are used to initiate a transaction while SIP-Responses are used to indicate the possibly intermediate result of a transaction which was previously invoked by a related SIP-Request message. In our example, the initial message Request: INVITE receives the following three Response messages and the transaction ends. Obviously, there are exceptions to the aforementioned rule: In the example we see one example: The Request: ACK-message does not initiate a transaction and it does not require a response as it is only there to confirm the dialog establishment which has been achieved when the Response: 200-OK is sent and received. Another example of an exception is CANCEL which does not initiate a transaction but which is used to cancel a previous Request: INVITE.

SIP-Methods The “real” message type in SIP is the “method-type”. It is the method type that indicates what the target of a transaction is. In that respect, the illustrated INVITE-method is the most important method type as it is the only method type to establish sessions between peers. The example also includes the BYE-method which is used to initiate the release of an established session. Many more method types exist which will be presented later.

Response Types With the exception of the aforementioned method type ACK, every SIP-Request message needs to be responded to with at least one response message which is called the “final response” message. Final response messages are those with a status code between 200 and 699. In that respect, there is a primary distinction between successful transaction results ( status code = 2XX) and unsuccessful transaction results ( status code = 3XX – 6XX). Further distinction of unsuccessful responses is possible through the 3, 4, 5 and 6 at the front of the status codes which indicate whether a transaction needed to be terminated unsuccessfully because of server error, client error or global errors. More details will be provided later.




IImmppoorrttaanntt SSIIPP--TTeerrmmiinnoollooggyy // SStteepp 11:: TTwwoo UUAA’’ss ……




IImmppoorrttaanntt SSIIPP--TTeerrmmiinnoollooggyy // SStteepp 11:: TTwwoo UUAA’’ss …… We start with the limitation of only two users (no SIP-forking) to simplify things initially. In a second step we shall handle the case of multiple users).

Transaction) Each SIP-transaction consists of a single request message which is sent by a UAC (User Agent Client) and the related final response message which is sent by the adjacent UAS (User Agent Server). If the request message is an INVITE, then there are zero or more provisional responses between the INVITE and the final response message. Note that the term “adjacent” in the previous sentence means that transactions ultimately exist between adjacent SIP-entities (e.g. UA and proxy) and not necessarily between peers (the two UA’s in the graphics) [RFC 3261 (p.24)].

The exception to this rule is indicated in the figure: The successful dialog establishment through the initial INVITE-transaction shall be acknowledged by a Request: ACK-message which is considered to be a second transaction but which is not responded at all (although it is a SIP-Request). The Request: ACK really is a new transaction, considering the fact that a new branch-value is used. However, as we will see later, the transaction number ( CSeq) does not get incremented from the Request: INVITE that the Request: ACK relates to [RFC 3261 (p.24)].

Dialog / Call / Early Dialog (Definition) ⇒ Dialog establishment is initiated when a UAC sends a Request: INVITE-message towards another peer, with this message possibly traversing one or

more SIP-proxies. ⇒ Dialog establishment can only be triggered by Request: INVITE and (new with RFC 3515) also by Request: REFER. ⇒ Dialogs only exist between two UA’s / peers. There can be no dialogs between a UA and a SIP-proxy. ⇒ A dialog has been established as soon as a UAS responds to a Request: INVITE with a non-failure final response message ( 200-OK). This rule

means that the reception of a 2XX-response by a UAC establishes a dialog between these two users. This also is the start of the session. ⇒ An early dialog is there, if a UAS responds to a Request: INVITE with a provisional Response: “101 – 199” message ( which excludes “100”

(Trying)) [RFC 3261 (12.1)]. The benefit of the definition of an “early dialog” is that the UAC may send further SIP-Requests (e.g. UPDATE) to the UAS already while the dialog is in its early state [RFC 3261 (13.2.2.1)].

⇒ In SIP, a call consists of one or more dialogs [RFC 3261 (p.78)]. More than one dialog per call is only possible for multiparty calls. ⇒ Dialogs are terminated by either party by sending a Request: BYE-message. Early dialogs can be terminated by the UAC by sending a Request:

CANCEL-message

Each dialog is identified by the Call-ID-value which is initially allocated by the peer that sent the Request: INVITE-message and by the “To:”- and “From:”-tag values. We will get back to these identifiers in a few slides.




SSeessssiioonn ((DDeeffiinniittiioonn))




SSeessssiioonn ((DDeeffiinniittiioonn)) A session is established through SIP but it is not part of SIP. The term “session” is considered to be “…an exchange of data between an association of participants.” [RFC 3261 (p. 8)]. Usually, a session relates to the transfer of user data through some other protocol like RTP or SRTP. Another example of a session protocol is MSRP. Like a dialog, a session is established with the reception of a final Response: 200-OK.

If SDP is used to describe a session, then the session is identified by the parameters session-ID’s and the addresses and port numbers which are used for the multimedia session.

A session manifests itself in the user plane while the SIP-dialog manifests itself in the control plane.




DDiiaalloogg IIddeennttiiffiiccaattiioonn ((ttwwoo UUsseerrss // wwiitthh oorr ww//oo PPrrooxxiieess))




DDiiaalloogg IIddeennttiiffiiccaattiioonn ((ttwwoo UUsseerrss // wwiitthh oorr ww//oo PPrrooxxiieess)) ⇒ Note that at least today, dialogs in SIP can only be established through the INVITE-method and through the REFER-method [RFC3515]. ⇒ Each dialog is identified through the “Call-ID:”-header field and additionally through the “tag”-attributes in the “To:”- and “From:”-header fields. The

UAC that issues the REFER or INVITE will allocate the “From:”-tag and the UAS that sends the response messages has to allocate the “To:”-tag. ⇒ Note that only the final recipient of a REFER or INVITE can allocate the “To”-tag but intermediate SIP-proxies may not. Therefore, the Response: 100-

Trying-messages which are generated by intermediate SIP-proxies will be sent without the “To:”-tag. ⇒ “From:”- and “To:”-tags shall have at least 32 bit of randomness [RFC 3261 (19.3)].

Note: • The “From:”- and “To:”-header fields preserve their direction in response messages. • That is, a dialog is established by the party that is identified in the “From:”-header field and it is destined to the party that is identified in the “To:”-

header field. • Although confusing, the related response messages are sent by the called party but the called party still is identified within the response messages

through the “To:”-header field.

⇒ When a UAC issues an INVITE (or a REFER that establishes a dialog), the “Call-ID:”-header field shall be built from the UA’s host name or IP-address

and a random string which may include the current time and day to distinguish it from any other “Call-ID”. ⇒ Note that in the figure all transactions are part of the same call / dialog ( the “Call-ID” is the same).

Note: • Registrations do not represent dialogs although the “Call-ID:”-header field and “To”- and “From:”-header fields with tag values are present. • Likewise, the registering client in a registration scenario has to allocate the “From:”-tag but the registrar will allocate the “To:”-tag in the response

message.

[RFC 3261 (8.1.1.4), (20.8)]

Session Identification and Distinction Sessions are identified through the IP-address / port number combinations of the SDP-content which is embedded in the SIP-messages. The session is not illustrated in the figure.




TTrraannssaaccttiioonn IIddeennttiiffiiccaattiioonn ((ttwwoo UUAA’’ss // nnoo PPrrooxxiieess))




TTrraannssaaccttiioonn IIddeennttiiffiiccaattiioonn ((ttwwoo UUAA’’ss // nnoo PPrrooxxiieess)) As mentioned on the previous slide, each transaction consists of a SIP-Request message and the related final response message. If the request was an INVITE, then provisional response messages may be present between the two. This is the basis of the example illustrated on the graphics slide.

The Branch Parameter The branch parameter is one parameter of the “via:”-header field which shall be present in every “via:”-header field. It is allocated by the UAC and it represents an alphanumeric value of arbitrary length.

Note: • A UAC shall generate a new branch parameter for every new transaction which ultimately means for every new SIP-request message. • The exceptions to this rule are Request: ACK-messages for unsuccessful INVITE-transactions and Request: CANCEL-messages. In both cases, the

branch-parameter shall be the one of the INVITE-transaction which is acked or cancelled. We will illustrate this later in this book. • Generation of branch-parameters is left to the implementation but some general rules are described in RFC 3261 (p.105). • All response messages (provisional and final) which are sent to answer a request message shall carry the same branch-parameter value as this

request message.

Magic Cookie "z9hG4bK" Each branch-value shall start with the character sequence "z9hG4bK" ( case sensitive) to indicate compliance of a UAC with RFC 3261 rather than with the older RFC 2543. Unfortunately, both standards use the version No 2.0. [RFC 3261 (8.1.17) / p.39)]

???? Question Section 7 ???? ⇒ Taking into account the aforementioned statement about the magic cookie: Is the SIP-scenario which we show in chapter 1 using RFC 2543 compliant

software or RFC 3261 compliant software? ⇒ Why is “branch” there in the first place?




EExxaammppllee

Request-Line: REGISTER sip:192.168.2.106 SIP/2.0 Message Header Via: SIP/2.0/UDP 192.168.2.104:5060;branch=z9hG4bKba8118b73532d From: acer <sip:[email protected]>;tag=4169360809 To: acer <sip:[email protected]> CSeq: 9794 REGISTER ...

Status-Line: SIP/2.0 200 OK Message Header Via: SIP/2.0/UDP 192.168.2.104:5060;branch=z9hG4bKba8118b73532d From: acer <sip:[email protected]>;tag=4169360809 To: acer <sip:[email protected]>;tag=1124705376834-227754029 CSeq: 9794 REGISTER




EExxaammppllee The Register transaction between these two peers is uniquely identified through the branch value “z9hG4bKba8118b73532d” which has been generated originally by the peer who sent the Request: REGISTER. Additionally, the header field “CSeq:” is needed for transaction numbering within a dialog.

Sequence Numbering (CSeq) ⇒ Whenever a peer sends a new SIP-request message, it will generate a CSeq-number and add it as header field to this SIP-request message. The

“CSeq:”-header field also includes the method type of this request. ⇒ All responses for that SIP-Request shall be marked with the same “CSeq:”-header field value as the original SIP-request message. ⇒ “CSeq:” shall consist of a 32 bit unsigned integer and shall be smaller than 231. As a consequence, “CSeq” will always contain a positive value. [RFC 3261 (8.1.1.5)]




RReellaattiioonnsshhiipp bbeettwweeeenn SSIIPP,, tthhee IIMMSS aanndd 33GGPPPP--NNeettwwoorrkkss




RReellaattiioonnsshhiipp bbeettwweeeenn SSIIPP,, tthhee IIMMSS aanndd 33GGPPPP--NNeettwwoorrkkss ⇒ The figure illustrates how the IMS is interconnected to the various entities and network clouds that a 3GPP-network consists of or that a 3GPP-

network is connected to. For more details about the different logical entities within the IMS please refer to chapter 2 and to the course book “IMS – Architecture Details & System Engineering”.

⇒ More importantly, the figure illustrates how the IMS communicates with these different entities and network clouds. Intentionally, we did not include any notion of user data transfers to keep the illustration simple. Hence, the focus is purely on signaling.

⇒ Note that between the PS-Core ( or more precisely the GGSN) and the IMS ( or more precisely the P-CSCF) there may be a dedicated PDF (Policy Decision Function) or the PDF may be integrated into the P-CSCF or it may be integrated into the GGSN. Depending on this configuration, either COPS or DBP is used between the GGSN and the IMS for QoS-Policing [3GTS 23.228 (4.6.1), 3GTS 23.207 (5.1), 3GTS 29.209 (4.2)].

[3GTS 23.228]

???? Question Section 8 ???? ⇒ In chapter 1 we stated explicitly that the IMS provides its services exclusively through the packet-switched domain. Why did we still need to insert the

dotted line between the IMS and the circuit-switched domain?




GGeenneerriicc SSIIPP--SSeerrvveerrss vvss.. IIMMSS--ssppeecciiffiicc SSIIPP--SSeerrvveerrss




GGeenneerriicc SSIIPP--SSeerrvveerrss vvss.. IIMMSS--ssppeecciiffiicc SSIIPP--SSeerrvveerrss Before we delve into more detail about IMS-specifics, we like to match generic SIP-server terminology to IMS-specific terms. As you can see in the graphics, all IMS-specific SIP-server terms find the match in the generic environment. For a presentation of the IMS-specific SIP-servers please refer to the course book “IMS – Architecture Details & Design Engineering”. [3GTS 23.228]

Abbreviations (please fill in): S-CSCF: ____________________________________________________________________ I-CSCF: _____________________________________________________________________ BGCF: _____________________________________________________________________ P-CSCF: ____________________________________________________________________ TrGw: ______________________________________________________________________

MGCF: _____________________________________________________________________ HSS: ______________________________________________________________________ AAA: ______________________________________________________________________ MRFC: _____________________________________________________________________ MRFP: _____________________________________________________________________




TThhee MMoobbiillee’’ss WWaayy ttoo SSIIPP RReeggiissttrraattiioonn aanndd SSIIPP--SSeessssiioonnss




TThhee MMoobbiillee’’ss WWaayy ttoo SSIIPP RReeggiissttrraattiioonn aanndd SSIIPP--SSeessssiioonnss In 3GPP-networks, the IMS is interconnected to the UE / MS exclusively through the packet-switched domain. Consequently, the user needs to perform the respective internal registration procedure towards that domain before SIP-procedures can be performed:

Step 1: GPRS-Attachment ⇒ The MS / UE shall attach to the GPRS using the regular GPRS-attachment procedure.

Step 2: Primary PDP-Context Activation Procedure / P-CSCF Discovery ⇒ The MS / UE shall establish a PDP-context with best-effort QoS to be able to register to the IMS. ⇒ Either embedded in the SM: ACT_PDP_CT_ACC-message or through DNS-query ( according to RFC 3263 as presented in chapter 4 / “Advanced

Use of SIP and SDP”) the UE / MS receives the FQDN or IP-address of the P-CSCF (Proxy Call Session Control Function) to destine its SIP-messages to.

⇒ To be more precise: The MS/UE makes use of the FQDN / IP-address of the P-CSCF to be able to fill the destination IP-address field of any IP-frame that carries its outgoing SIP-messages. The SIP-URI of the embedded SIP-frame is usually not the one of the P-CSCF.

Step 3: SIP-Registration ( REGISTER) ⇒ The next step will be the registration towards the IMS-domain within the H-PLMN (or to be more accurate to a SIP-registrar which is called S-CSCF in

3GPP-networks).

Step 4: SIP-Invitation ( INVITE) ⇒ Finally, SIP-transactions can be established using the packet-switched domain as bearer.

Note that SIP-sessions will usually require the activation of a secondary PDP-context to obtain the necessary QoS.

[3GTS 24.229 (9.2.1)]




IIMMSS--rreellaatteedd UUsseerr IIddeennttiittiieess • Private User Identity (IMPI) / Public User Identity (IMPU)




IIMMSS--rreellaatteedd UUsseerr IIddeennttiittiieess Overview / the ISIM ⇒ Obviously, the IMS and SIP require new and different means for subscriber identification as legacy mobile telecommunication services. One example

is the use of the SIP-URI in SIP-based networks for subscriber identification. Accordingly, SIP-URI’s need to be provided in IMS-based networks, too.

We are aware of the possibility to continue using legacy telephone numbers in the form of TEL-URI’s but more advanced and easier to use are SIP-URI’s.

⇒ 3GPP has defined a new SIM-type, which is called the ISIM (IMS-Subscriber Identity Module). The availability of the ISIM is not mandatory for an IMS-subscriber but it is recommended.

Note that the presence of ISIM or at least USIM is required for IMS-level authentication [3GTS 33.978 (6.1.3)].

⇒ Most importantly, 3GPP requires a subscriber to have two types of user identities, the private user identity and the public user identity. [3GTS 23.003 (13.3, 13.4), 3GTS 23.228 (4.3.3)]

Private User Identity (IMPI) The private user identity is stored in the HSS and on the ISIM (indirectly also on SIM and USIM). The private user identity unambiguously identifies a subscriber. The private user identity reuses the IMSI of a subscriber together with the MCC and MNC of the related mobile network operator to provide for a globally unique and routable identifier. More details follow on the next slide. [3GTS 23.228 (4.3.3.1), RFC 2486 Definition of NAI]

Public User Identity (IMPU) As the figure illustrates, a given subscriber may be using more than one public user identity. Public user identities are known to the subscriber and can be published on business cards. Public user identities take on the form of an URI and can be used for different applications like messaging ( im: …, mailto: …), presence ( pres: …) or SIP ( sip: …) to identify the subscriber. [3GTS 23.228 (4.3.3.2)]

???? Question Section 9 ???? ⇒ How is it possible that Miriam has been allocated a SIP-URI that does not relate to the operator’s host name (e.g. Vodafone.sip.co.uk) but to

inacon.de?




DDeettaaiillss ooff PPrriivvaattee UUsseerr IIddeennttiittiieess ((IIMMPPII)) • Private User Identities are based on the Network Access

Identifier (NAI) as defined in RFC 2486 In 3GPP-networks, the private user identity is formatted as: <IMSI>@ims.mnc<MNC>.mcc<MCC>.3gppnetwork.org

• The private user identity is either stored within the memory of the ISIM or needs to be generated by the IMS-enabled UE/MS from the IMSI Irrespective of whether there is an ISIM, the format of the private user identity will always be the same. On the network side, the HSS stores the private user identity (IMPI).

• User Authentication on IMS-level only works if at least a USIM is present at the UE ( therefore not applicable for 2G-only devices) This also applies to the IPsec-security associations between UE and IMS which are established during authentication. They will not be there if only a SIM is used!

• Private User Identities (IMPI) can be compared with the IMSI in legacy mobile networks Like the IMSI, the private user identity is never displayed to the subscriber. And like the IMSI, the IMPI cannot be altered by the subscriber.




DDeettaaiillss ooff PPrriivvaattee UUsseerr IIddeennttiittiieess ((IIMMPPII))





DDeettaaiillss ooff PPuubblliicc UUsseerr IIddeennttiittiieess ((IIMMPPUU)) • Public User Identities are based on SIP-URI’s or TEL-URI’s

As the figure on the previous slide illustrated, TEL-URI’s are best suited to migrate your legacy phone number to the IMS-environment while SIP-URI’s represent human readable “telephone numbers”.

• Public User Identities are particularly important for mobile terminating sessions Very simple: Everybody who wants to contact the IMS-enabled subscriber has to use a public user identity to specify the session destination.

• If there is no ISIM, the MS/UE has to generate a temporary public user identity This public user identity is used during subscriber registration towards the S-CSCF. More details will be provided on the next side.




DDeettaaiillss ooff PPuubblliicc UUsseerr IIddeennttiittiieess ((IIMMPPUU))





UUssee ooff PPrriivvaattee aanndd PPuubblliicc UUsseerr IIddeennttiittiieess iinn RREEGGIISSTTEERR--MMssggss..




UUssee ooff PPrriivvaattee aanndd PPuubblliicc UUsseerr IIddeennttiittiieess iinn RREEGGIISSTTEERR--MMssggss.. The figure illustrates how the MS/UE shall equip the REGISTER-message that it sends towards the P-CSCF (which will ultimately forward it in the direction of the location service ( registrar) within the H-PLMN of the subscriber.

Home Network Domain Name The home network domain is no user parameter. However, the MS/UE that intends to register to the IMS, needs to determine from the IMSI on the SIM/USIM/ISIM this home network domain name. Ultimately, the home network domain name builds the most important part when the Request-URI of the Request: REGISTER-message is populated. The remainder of the Request-URI is fixed coded [3GTS 24.229 (5.1.1.1.A)]. Please compare the home network domain name with UMA-identifiers like “punc.uma.mnc<MNC>.mcc<MCC>.3gppnetwork.org” which is resolved to the “provisioning UNC” through DNS-query.

Use of Private User Identity As the figure illustrates, the private user identity becomes part of the “Authorization:”-header field. To be more precise, the private user identity is used as “digest username”-parameter within this header field ( 3GTS24.229 (5.1.1.2 a)).

Use of Public User Identity The public user identity is used as SIP-URI in the “To:”- and “From:”-header fields of the Request: REGISTER-message. It clarifies which public user identity shall be registered ( 3GTS24.229 (5.1.1.2 b and c)).

Use of Temporary Public User Identity If there is no ISIM, the MS/UE has to generate a temporary public user identity from the private user identity, simply by appending the complete private user identity to the string “sip:” [3GTS 23.003 (13.4)]. In such a case the S-CSCF will, in its related Response: 200-OK message, include a specific private header field, the “P-Associated-URI:”-header field. This header field is used to convey to the registering mobile devices its “real” IMPU’s [RFC 3455 (4.1)].

As mentioned earlier: The “Authorization:”-header field is suppressed if only a SIM-card is used because in such case, only authentication triplets rather than quintuplets are available and no integrity protection can take place through IPsec.




RReeggiissttrraattiioonn ttoo tthhee IIMMSS iinn 33GGPPPP--NNeettwwoorrkkss ((OOvveerrvviieeww)) • Dependency between APN-Setting and P-CSCF-Selection




RReeggiissttrraattiioonn ttoo tthhee IIMMSS iinn 33GGPPPP--NNeettwwoorrkkss ((OOvveerrvviieeww)) Dependency between APN-Setting and P-CSCF-Selection ⇒ Although the provision of the APN by the mobile station towards the network during primary PDP-context activation is not mandatory it is at least

typical: We talk about the APN or Access Point Name that is an indication for the SGSN to which GGSN the PDP-context activation shall be directed. ⇒ Usually, operators make sure that roaming subscribers still register to GGSN’s in their H-PLMN by proper APN-configuration within the dial string that

is used by the terminal equipment when configuring the MS/UE to establish a primary PDP-context. This relates to the illustrated option 2 and it represents a frequently used setup.

⇒ Alternatively, no APN is configured by the MS/UE during PDP-context activation and the decision as to which GGSN is used for plain internet access is left to the SGSN. In this case, the SGSN will obviously select a GGSN within the V-PLMN which relates to our option 1.

⇒ With the advent of the IMS, the aforementioned considerations get a new dimension since it is the GGSN during primary PDP-context activation that also conveys the IP-address of the responsible P-CSCF to the MS/UE.

⇒ Consequentially, the MS/UE will use this very P-CSCF as entry point to IMS-services. And as the figure illustrates, this may become an issue when data need to be transferred in real-time between the different PLMN’s.

⇒ Still, option 2 may remain the default approach for two reasons: (1) Operators like to continue collecting charging data records in the home GGSN. (2) It may be easier to guarantee real-time QoS within an operator-owned inter-PLMN backbone than over an arbitrary IP-network.

???? Question Section 10 ???? ⇒ Since we are talking about APN’s: Can a secondary PDP-context use a different APN than the primary PDP-context? [3GTS 24.229, 3GTS 23.060]




SSuubbssccrriibbeerr rreeggiisstteerrss ttoo IIMMSS wwhhiillee llooccaatteedd iinn HH--PPLLMMNN




SSuubbssccrriibbeerr rreeggiisstteerrss ttoo IIMMSS wwhhiillee llooccaatteedd iinn HH--PPLLMMNN The figure illustrates how a roaming subscriber registers to an IMS. 3. The MS/UE sends a Request: REGISTER-message to the P-CSCF in the H-PLMN. The MS/UE shall set the expires-parameter = 600.000 s

( app. 167 hours) but obviously the re-registration interval can be adjusted by the S-CSCF. 4. We assume in the non-roaming case that the P-CSCF does not need a DNS-server to select the next hop towards an I-CSCF. In any case, the MS/UE

will not have identified a particular S-CSCF ( registrar) but only the location service domain (e.g. registrar.inacon.com). This domain may obviously contain many registrars.

5. The I-CSCF interrogates the SLF over the Dx-interface about the HSS of this subscriber. DIAMETER is used for that purpose. This step only occurs if there is more than one HSS in this PLMN

6. The I-CSCF interrogates the HSS over the Cx-interface whether there are any registration restrictions for this subscriber and whether there are already registrations for this subscriber from other devices.

5. If not, then the I-CSCF selects the S-CSCF to which the subscriber shall be registered. Of course, subsequent registrations of the same subscriber will be done to the same S-CSCF but this is assured through the previous HSS-interrogation. The selection of the S-CSCF )through the I-CSCF is based on different aspects like geographic considerations, load sharing, service specific, subscriber-specific (e.g. pre-paid / post-paid). The I-CSCF forwards the REGISTER-message to the selected S-CSCF and this

6. S-CSCF registers the subscriber towards the HSS 7. The S-CSCF responds with a Response: 200-OK. 8. The Response: 200-OK traverses from the I-CSCF to the P-CSCF and … 9. from the P-CSCF back to the MS/UE.

Note: Authentication will be invoked by the S-CSCF upon initial registration of an MS/UE. This will be illustrated later. Also, for simplicity the present scenario does not illustrate registration to the subscription event package. We will illustrate this also later.

[3GTS 24.228 (6), 3GTS 24.229 (5.1.1)]




SSuubbssccrriibbeerr iiss RRooaammiinngg




SSuubbssccrriibbeerr iiss RRooaammiinngg The figure illustrates how a roaming subscriber registers to an IMS.

Most importantly, the MS/UE will always register to his/her home IMS, irrespective of whether he/she is roaming or not.

1. The MS/UE sends a Request: REGISTER-message to the previously detected P-CSCF in the local IMS (V-PLMN). Note our considerations about the APN: If the APN is not set to default but to a GGSN in the H-PLMN then the subscriber would rather detect a P-CSCF in the H-PLMN.

2. The P-CSCF checks with a DNS-server to determine where to find the domain in which the subscriber wants to register (e.g. registrar.inacon.com). Note that this construct does not identify one particular registrar but only a domain which may contain many registrars.

3. In our case, the P-CSCF has got routing information and forwards the REGISTER to an I-CSCF (for topology hiding) in its own IMS. Alternatively, the P-CSCF could have sent the REGISTER directly to an I-CSCF in the H-PLMN of the subscriber. In our example, this step 4 is done by the I-CSCF in the V-PLMN.

5. The I-CSCF interrogates the SLF which HSS is responsible for this subscriber (only if there is more than one HSS in this PLMN). 6. The I-CSCF interrogates the HSS of the subscriber whether there are any registration restrictions for this subscriber. 7. If not, then the I-CSCF forwards the REGISTER-message to the selected S-CSCF. 8. The S-CSCF registers the subscriber towards the HSS and … 9. responds with a Response: 200-OK

Note that alternatively, the S-CSCF could have rejected the REGISTER-message with a Response: 401-Unauthorized which would contain an authentication challenge for the MS/UE. The S-CSCF obtains this authentication information from the HSS through the query illustrated as step 7. In this case, the MS/UE would calculate the respective authentication response and send it in another REGISTER-message to the S-CSCF. We will talk more about authentication in the next section. Also, for simplicity this scenario does not illustrate registration to the subscription event package. We will illustrate this also later.

10.+11.+12. In our case, the servers in the middle will relay the Response: 200-OK back to the MS. [3GTS 24.228 (6), 3GTS 24.229 (5.1.1)]




AAuutthheennttiiccaattiioonn aanndd SSeeccuurriittyy iinn 33GGPPPP--bbaasseedd IIMMSS

• Authentication in and through the IMS is based on IMS-AKA and reuses the authentication quintuplets known from the UMTS security architecture An authentication quintuplet consists of five different values: RAND (128 bit), XRES (32 .. 128 bit), CK (128 bit), IK (128 bit), AUTN. Transmission of the authentication parameters to the MS/UE happens base64-encoded through SIP-signaling messages.

• Authentication is performed during the initial registration of an MS/UE We will illustrate the extended registration scenario on the following slides.

• Note that the authentication process is also used to establish IPsec security associations between the P-CSCF and the MS/UE

• Still, these security associations are used for SIP-message integrity protection only but not for SIP-message encryption




AAuutthheennttiiccaattiioonn iinn 33GGPPPP--bbaasseedd IIMMSS





AAuutthheennttiiccaattiinngg tthhee NNeettwwoorrkk ttoowwaarrddss tthhee MMSS//UUEE




AAuutthheennttiiccaattiinngg tthhee NNeettwwoorrkk ttoowwaarrddss tthhee MMSS//UUEE ⇒ The MS/UE authenticates to the network through the correct calculation and provision of RES. The related challenge is based on RAND which the

network sends to the MS/UE. ⇒ The question remains how the network can authenticate to the MS/UE since there is no challenge sent in the reverse direction. ⇒ This network to MS/UE authentication is achieved in two different ways: First of all, the network needs to have access to the mobile subscriber’s

secret key ( Ki-value) to be able to calculate a valid AK. However, note that AK may be set to ‘0’ if no concealed transfer of SQN is desired. ⇒ The UE proves the validity of AK by XORing the first 48 bit of AUTN with its own result of AK. Only when the resulting SQN-value is higher than the

SQN-value from the most recent authentication process, the network is eligible to serve the MS/UE. ⇒ The second step of the network authentication is more challenging. The just calculated SQN by the is used by the MS/UE together with Ki and RAND

to calculate XMAC (64 bit). ⇒ The MS/UE needs to validate that XMAC matches MAC ( the last 64 bit of AUTN) to make sure that the network is authenticated. [3GTS 33.102 (6.3)]




TThhee ““bbaassee6644””--EEnnccooddiinngg PPrroocceessss




TThhee ““bbaassee6644””--EEnnccooddiinngg PPrroocceessss ⇒ As illustrated, the algorithm operates on chunks of 3 octets / 24 bit. ⇒ In a first step, these 24 bit are separated into 4 x 6 bit and each of these 6 bits is extended with two leading ‘0’-bits. Each of the resulting 4 octets will

be in the value range ‘0..63’(hex) and is translated into a base ASCII character, encoded according to the special base64-alphabet as lined out in RFC 2045.

⇒ The value range is indicated in the figure. It includes only the human readable ASCII-characters ‘A-Z’, ‘a-z’, ‘0-9’, ‘+’ and ‘/’. The character ‘=’ is used for padding purposes only.

Base64-encoding avoids that parsers mistakenly consider octets within the authentication information (or anywhere else) as control information. Consider in case of SIP the special meaning of a “-character as “end of nonce”-indication.

???? Question Section 11 ???? ⇒ When is padding required within the output octet string? ⇒ Which other very important application is using base64-encoding? [RFC 2045 (6.8)]




TThhee IIMMSS--AAKKAA AAuutthheennttiiccaattiioonn PPrroocceessss




TThhee IIMMSS--AAKKAA AAuutthheennttiiccaattiioonn PPrroocceessss ⇒ The figure illustrates the subscriber registration with authentication which is invoked by the S-CSCF. Most importantly, we use two additional colors to

emphasize the flow of IPsec- and authentication related information among the different network elements. ⇒ The MS/UE initiates the process by sending a Request: REGISTER-message to the P-CSCF. This message contains private and public user identities

(IMPI and IMPU) and it includes in the header field “Security-Client:” IP-sec related information like the SPI (Security Parameters Index / 32 bit) and the secure port number (e.g. port number 1357 but definitely not 5060) at which the MS/UE wishes to receive IPsec-protected SIP-messages.

If the UE is only equipped with a SIM-card, then no “Authorization:”- and “Security-Client:”-header fields shall be present. In such case, the IMS will not perform authentication of the UE and no IPsec-tunnels will be established between UE and P-CSCF [3GTS 33.978 (6.2.3.1)].

⇒ The P-CSCF forwards the registration attempt through possibly various other SIP-proxies towards an S-CSCF in the IMS within the H-PLMN of this subscriber. During initial registration, there will be at least an I-CSCF to select the very S-CSCF to take on the registration of that subscriber.

⇒ The S-CSCF uses DIAMETER and the subscriber’s IMPI to retrieve authentication quintuplets from the HSS of this subscriber. Accordingly, the HSS provides an arbitrary number (4 - 5) of authentication quintuplets to the S-CSCF.

⇒ The S-CSCF selects one quintuplet and base64-encodes the indicated parameters (most importantly RAND, AUTN and IK) into the Response: 401-Unauthorized message. This message finds its way back to the P-CSCF.

⇒ The P-CSCF adds a new header field “Security-Server:” and puts its own IP-sec related information inside. This information includes most importantly the port number at which the P-CSCF will now be ready to receive IPsec-protected information from this MS/UE.

Please note that the P-CSCF will only accept unprotected REGISTER-requests on SIP’s default port number 5060.

⇒ The MS/UE extracts the different parameters and performs the necessary calculations to obtain RES and IK and to authenticate the network. ⇒ Now that the MS/UE has IK available it can integrity protect its next registration attempt and send it towards the P-CSCF. Note that this Request:

REGISTER will contain the base64-encoded RES-parameter and it will be sent towards the IPsec-aware port number that the P-CSCF previously conveyed to the MS/UE.

⇒ When the Request: REGISTER is received by the S-CSCF, the S-CSCF will prove that RES matches XRES and if yes, authentication is successful at both peers. In this case, the S-CSCF will issue a Response: 200-OK that finally reaches the MS/UE on the IP-sec aware port number. This message contains a “Service Route:”-header field with the SIP-URI of the S-CSCF which is stored by the P-CSCF for future use.

Note that there are two security associations established during the aforementioned process: One for transactions which origin from the MS/UE (this one is shown) and another one for transactions that origin from the P-CSCF (not shown). Both are different but use the same IK.

[3GTS 33.203 (6), 3GTS 24.229 (5.1.1.5), (5.2.2), RFC 3310]




AApppplliiccaattiioonn ooff IIPPsseecc bbeettwweeeenn MMSS//UUEE aanndd PP--CCSSCCFF




AApppplliiccaattiioonn ooff IIPPsseecc bbeettwweeeenn MMSS//UUEE aanndd PP--CCSSCCFF ⇒ The use of IPsec security associations serves one purpose only: Integrity protection of SIP-messages between the P-CSCF and the MS/UE. Integrity

protection relates to the calculation of a secure hash value ( ICV) and the amendment of this hash value to the original SIP-message. ⇒ Any tampering with the SIP-message can therefore be detected at the receiver side.

Most importantly, although the ESP-variant of IPsec in transport mode is mandated by 3GPP and although ESP does support encryption, there shall be no encryption of SIP-messages between the P-CSCF and the MS/UE. Encryption is left to the access network layer.

⇒ The process of integrity protection of SIP-messages between P-CSCF and MS/UE considering the aforementioned constraints is illustrated in the figure:

⇒ Initially, there is a SIP-message which is embedded into a UDP-frame which in turn is embedded into an IP-frame. The UDP-frame with the embedded SIP-message is processed through one of two message digest algorithms: Either HMAC-SHA-1-96 (RFC 2403) or HMAC-MD-5-96 (RFC 2404). Each of these algorithms provides a 96 bit hash value / integrity protection value which is added at the end of the new created IPsec-frame.

⇒ Of course, TCP or another transport protocol could be used instead of UDP. ⇒ Note that both message digest algorithms will use IK (128 bit) as secret key but HMAC-SHA-1-96 requires a key length of 160 bit. If this algorithm

shall be used, then IK is extended by 32 bits (all ‘0’) to be 160 bit long [3GTS 33.203 (Annex I)]. ⇒ All the blue fields in the resulting IP-frame represent IPsec-related information. The SPI is an integer pointer towards the common security association

and the sequence number is a 32 bit message counter to exclude any risk of message replays. When the sequence number reaches it’s modulo then new keying material has to be provided.

⇒ Padding is an option of IPsec in ESP-mode but 3GPP does not use padding so the padding length will be ‘0’. The “next header” field is necessary to tell the receiver the original protocol field of the IP-frame (e.g. UDP, TCP) since the protocol field of the resulting IP-frame has been changed to ESP / 32(hex).

[3GTS 33.203 (6.3), RFC 2401, RFC 2406]




((11)) RReeggiissttrraattiioonn ttoo tthhee IIMMSS iinn 33GGPPPP ((DDeettaaiilleedd SScceennaarriioo))

Gm-Interface Mw-Interface Mw-Interface Cx-Interface SIP: REGISTER Authorization: IMPI, IMPU SIP: REGISTER Security-Client: IPsec-Info Authorization: IMPI, IMPU DIA: UAR [Command-Code: 300] Path: SIP-URI of P-CSCF IMPI, IMPU DIA: UAA [Command-Code: 300] OK SIP: REGISTER IMPI, IMPU Path: SIP-URI of P-CSCF DIA: MAR [CommCd:303] IMPI, IMPU SIP-URI of S-CSCF DIA: MAA [CommCd:303] N x (Auth-Quintuplet) SIP: 401-UNAUTH (REG) SIP: 401-UNAUTH (REG) Base64 (Auth-Quintuplet) SIP:401-UNAUTH (REG) Base64 (Auth-Quintuplet) Base64 (RAND / AUTN) P-CSCF IPsec-Info




((11)) RReeggiissttrraattiioonn ttoo tthhee IIMMSS iinn 33GGPPPP ((DDeettaaiilleedd SScceennaarriioo)) Initial Conditions The UE has been powered up and has just before activated its primary PDP-context and it has already discovered its P-CSCF.

Applicability of this Procedure The scenario is applicable to the initial registration of a UE with USIM or ISIM available and subsequent subscription of the UE and the P-CSCF to the registration event package of that UE. Only one HSS is used and therefore no SLF is required to obtain the HSS-address from the IMPI.

If the UE is only equipped with a SIM-card, then no “Authorization:”- and “Security-Client:”-header fields shall be present. In such case, the IMS will not perform authentication of the UE and no IPsec-tunnels will be established between UE and P-CSCF [3GTS 33.978 (6.2.3.1)].

Description ⇒ The UE sends the Request: REGISTER-message to the P-CSCF which relays it towards an I-CSCF in the home-PLMN of the subscriber. This does

obviously not preclude the P-CSCF and the I-CSCF to be in the same network. ⇒ The I-CSCF uses the IMPI and IMPU of the subscriber for an initial authorization information retrieval towards the HSS. That is, the I-CSCF sends a

DIAMETER: UAR-message (User Authorization Request) to the HSS to find out whether this subscriber may register in the first place. ⇒ Let us assume that everything is OK and the HSS will reply with a DIAMETER: UAA-message (User Authorization Answer). Since this is the initial

registration of the subscriber after power on, no “server-name” AVP will be included in this message. This “server-name” AVP is used to identify the S-CSCF of the subscriber.

⇒ Since no S-CSCF is serving the subscriber yet, the I-CSCF will select an S-CSCF based on different considerations like load sharing, geographic issue or customer type (pre-paid / contract).

⇒ In the next step, the I-CSCF will relay the Request: REGISTER-message to the selected S-CSCF. ⇒ The S-CSCF uses the DIAMETER: MAR-message (Multimedia Authorization Request) to request authentication information for that subscriber

( identified through IMPI and IMPU) and to preset the HSS with its own S-CSCF Id ( SIP-URI of the S-CSCF). ⇒ The HSS replies by sending back n authentication quintuplets ( RAND, SRES, CK, IK, AUTN) which will be used by the S-CSCF to authenticate the

subscriber. ⇒ The S-CSCF picks one entire quintuplet and relays it towards the I-CSCF. The relaying occurs through a Response: 401-Unauthorized message that

terminates the initial SIP: Register-transaction. ⇒ The I-CSCF relays this Response: 401-Unauthorized message towards the P-CSCF. ⇒ The P-CSCF extracts all keys (IK, CK) and the authentication response (RES) from the authentication information and it adds its own IPsec-related

information (SPI (32 bit) / new port number for SIP-signaling messages) to the Response: 401-Unauthorized message that it finally sends towards the UE.





Gm-Interface Mw-Interface Mw-Interface Cx-Interface ⇐ IPsec-tunnel ⇒ SIP: REGISTER IMPI, IMPU SIP: REGISTER Base64 (RAND,AUTN,RES) IMPI, IMPU,Path: SIP-URI P-CSCF DIA: UAR [Command-Code: 300] Base64 (RAND,AUTN,RES) IMPI, IMPU DIA: UAA [Command-Code: 300] OK, Server-Name = SIP-URI of S-CSCF SIP: REGISTER IMPI, IMPU Base64 (RAND,AUTN,RES) DIA: SAR [CommCd: 301] IMPI, IMPU SIP-URI of S-CSCF DIA: SAA [CommCd: 301] User-Profile (XML-encoded) e.g. other IMPU’s SIP: 200-OK (REG) SIP: 200-OK (REG) P-Associated-URI: n x IMPU SIP: 200-OK (REG) P-Associated-URI: n x IMPU Serv-Route: S-CSCF SIP-URI P-Associated-URI: n x IMPU Serv-Route: S-CSCF SIP-URI Serv-Route: S-CSCF SIP-URI




((22)) RReeggiissttrraattiioonn ttoo tthhee IIMMSS iinn 33GGPPPP ((DDeettaaiilleedd SScceennaarriioo)) Description ⇒ The UE authenticates the network based on AUTN and calculates its own values for RES, CK and IK based on Ki and RAND. The calculated RES

and the related RAND- and AUTN-values are embedded into a second Request: REGISTER-message which is then sent towards the P-CSCF. ⇒ As the figure illustrates, this Request: REGISTER-message is integrity protected through IK and either HMAC-SHA-1-96 (RFC 2403) or HMAC-MD-5-

96. The message is sent over the new IPsec-tunnel to the very port number that the P-CSCF previously conveyed to the UE. Because of lack of space we did not indicate that this REGISTER-message also includes a “Security-Verify:”-header field, verifying the IPsec-settings received from the P-CSCF.

⇒ The P-CSCF will only accept initial Request: REGISTER-messages on the unprotected port number ‘5060’. ⇒ The P-CSCF relays the Request: REGISTER-message towards an I-CSCF. Note that the P-CSCF will add a “Path:”-header field to make sure that the

S-CSCF routes all future UE-terminating SIP-transactions through this P-CSCF. ⇒ This I-CSCF has (again) to interrogate the HSS whether the subscriber is already registered to an S-CSCF and whether there are any registration

restrictions. The interrogation is done as before through a DIAMETER: UAR-message (User Authorization Request) which contains the IMPI and IMPU of that subscriber.

⇒ Different from the first UAR-message, the current answer message DIAMETER: UAA (User Authorization Answer) contains the SIP-URI of the S-CSCF that was previously selected by the I-CSCF to serve that customer (the HSS kept track since the MAR/MAA-messages while the I-CSCF keeps no registration states).

⇒ Therefore, the I-CSCF is enabled to relay the Request: REGISTER-message towards that S-CSCF. ⇒ The S-CSCF verifies that the RES and XRES-values match ( authentication successful) and then sends a DIAMETER: SAR-message (Server

Assignment Request) to the HSS to finally register that S-CSCF as serving S-CSCF and to initiate the download of the XML-encoded user profile [3GTS 29.228 (Annex D and E)]. This user profile consists of the user’s public user identities and other information. The HSS does so by sending a DIAMETER: SAA-message (Server Assignment Answer) to the S-CSCF.

⇒ The S-CSCF generates the Response: 200-OK-message and inserts the IMPU’s of the subscriber as received from the HSS. The S-CSCF also adds a “Service-Route:”-header field into the Response: 200-OK-message which includes its own SIP-URI (with port number) to be used from now on by the P-CSCF in the future for all SIP-transactions originated by the UE. That is, the “Service-Route:”-header field is used by the S-CSCF to indicate its own identity to the P-CSCF and to make sure that the P-CSCF will route all SIP-requests coming from that UE to that S-CSCF (if the P-CSCF is in another PLMN, then at least one I-CSCF will be between the P-CSCF and the S-CSCF during future transactions. If both are in the same PLMN then there will be no I-CSCF between them for all transactions except future registrations).

⇒ The I-CSCF relays the Response: 200-OK-message to the P-CSCF which applies integrity protection upon it and relays it towards the UE.





Gm-Interface Mw-Interface Mw-Interface Cx-Interface ⇐ IPsec-tunnel ⇒ SIP: SUBSCRIBE Event: reg SIP: 200-OK (SUB) SIP: NOTIFY Public User Identities (XML-encoded) SIP: 200-OK (NOT) SIP: SUBSCRIBE Event: reg SIP: SUBSCRIBE Event: reg SIP: 200-OK (SUB) SIP: 200-OK (SUB)




((33)) RReeggiissttrraattiioonn ttoo tthhee IIMMSS iinn 33GGPPPP ((DDeettaaiilleedd SScceennaarriioo)) Description ⇒ The plain registration is over once that the UE receives the Response: 200-OK-message. Still, to allow for network initiated de-registrations and to

keep the UE and the P-CSCF informed at all times whether or not the UE is registered (and with which public user identities), there is an immediate subscription of the UE and the P-CSCF to the registration event state package.

Note that this is an IMS-specific amendment to the genuine registration procedure as defined in RFC 3261.

⇒ For the registration event package, the S-CSCF takes on the role of the event server and the P-CSCF and the UE become the user agents that are notified once that a registration event state change occurs.

⇒ As illustrated, the P-CSCF and the UE will both and independently issue a Request: SUBSCRIBE-message to the S-CSCF which identifies the “event: reg” as subscription event.

⇒ The S-CSCF internally registers both subscriptions and sends a Request: NOTIFY-message to the P-CSCF to inform the P-CSCF about the current registration state of that subscriber.





Gm-Interface Mw-Interface Mw-Interface Cx-Interface ⇐ IPsec-tunnel ⇒ SIP: NOTIFY SIP: NOTIFY Public User Identities (XML-encoded) Public User Identities (XML-encoded) SIP: 200-OK (NOT) SIP: 200-OK (NOT)




((44)) RReeggiissttrraattiioonn ttoo tthhee IIMMSS iinn 33GGPPPP ((DDeettaaiilleedd SScceennaarriioo)) Description ⇒ Finally, the S-CSCF sends a Request: NOTIFY-message to the UE to inform that UE about the its current registration state.

In case of a network initiated de-registration, there will be another Request: NOTIFY-message telling the UE and the P-CSCF that the subscriber has been de-registered entirely or only one or more public user identities are de-registered.




((11)) TTrraannssaaccttiioonn IIddeennttiiffiiccaattiioonn ((ttwwoo UUAA’’ss // wwiitthh PPrrooxxiieess))




((11)) TTrraannssaaccttiioonn IIddeennttiiffiiccaattiioonn ((ttwwoo UUAA’’ss // wwiitthh PPrrooxxiieess)) The figure on this slide and on the next slide illustrates a single dialog.

Transaction Identification through “branch” is done Hop-by-Hop ⇒ Transaction identification only applies between two adjacent SIP-entities. ⇒ For SIP-Requests, the intermediate proxy server adds its own “Via:”-header field ( host-address (not shown) and unique branch-parameter) in front

of any already existing “Via:”-header field entries (see figure). ⇒ The addition of the host address of a SIP-proxy server to the “Via:”-header field of a SIP-Request ensures that all responses for this request will also

traverse through this SIP-proxy. ⇒ For the related SIP-Responses, the intermediate proxy server subtracts its “Via:”-header field entry before forwarding the SIP-Response to the next

UAC (see figure). The next hop’s address is obtained from the next-in-line “Via:”-header field or rather from the included host-address. ⇒ The branch-parameter is always generated by the UAC ( the party that sends or relays a SIP-request message). The branch-parameter remains

constant throughout the lifetime of a SIP-transaction between the two SIP-entities.

Note: • The aforementioned rules apply for stateful and stateless SIP-proxy servers. That is, stateless SIP-proxy servers also have to assure that a unique

branch-parameter is added to the “Via:”-header field before forwarding a received SIP-Request [RFC 3261 (p.116)]. • In the figure, also the ACK-transaction at the bottom uses its own branch-parameter. However, this is only true, if the final response for the Request:

INVITE-message was a Response: 200-OK. If the final response was a Response: 3XX-6XX, then the ACK-transaction had to use the same branch-parameter as the Request: INVITE-message was using and it should contain only a single “Via:”-header field..

• Similarly, the branch-parameter value of a Request: CANCEL-message shall be identical to the branch-parameter value of the Request: INVITE-message that it cancels.

[RFC 3261 (8.1.1.7) / p.39] On the following slide, we will emphasize on the behavior of the “CSeq:”-header field for the illustrated dialog.

???? Question Section 12 ???? ⇒ Do you think that a stateless SIP-proxy needs to allocate a unique branch parameter?




((22)) TTrraannssaaccttiioonn IIddeennttiiffiiccaattiioonn ((ttwwoo UUAA’’ss // wwiitthh PPrrooxxiieess))




((22)) TTrraannssaaccttiioonn IIddeennttiiffiiccaattiioonn ((ttwwoo UUAA’’ss // wwiitthh PPrrooxxiieess)) Transaction Numbering through “CSeq:” applies end-to-end ⇒ The “CSeq:”-number is arbitrarily allocated by the UA which initiates a transaction. Unlike the branch-parameter, the “CSeq:”-number applies end-to-

end and for the lifetime of a transaction. ⇒ For consecutive transactions within a dialog, the “CSeq:”-numbering shall be monotonically increasing. However, the “CSeq:”-numbering is done

independently by each peer. That is, each peer starts transaction numbering during a dialog independently at an arbitrary number. ⇒ In the example, the PDA on the left hand side originally chose CSeq = Integer1, while the PDA on the right hand side selects CSeq = Integer2 for the

first transaction initiated by this slide. Obviously, Integer1 and Integer2 are independent from each other. ⇒ Note that the new transaction (BYE) at the bottom of this slide uses the monotonically increased CSeq = (Integer 1 + 1).

Note: • The “CSeq:”-header field consists of an integer number and a method. Note on the previous slide that in case of ACK (and CANCEL as we will see

later) the “CSeq:”-number is reused from the INVITE which is acked or cancelled but the method type is ACK (or CANCEL).

[RFC 3261 (8.1.1.5) / p.38, (12.2.1.1) / (p.73, p.74)]

???? Question Section 13 ???? ⇒ Why is transaction numbering done in the first place? In other words: Why is there a “CSeq:”-number?





• The following SIP-message contains two syntax errors. Please find them:

Internet Protocol, Src Addr: 10.0.0.32 (10.0.0.32), Dst Addr: 10.0.0.33 (10.0.0.33) User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060) Session Initiation Protocol Request-Line: INFO sip:[email protected]:5064 SIP/2.0 Message Header Content-Type: application/media_control+xml Content-Length: 167 To: <sip:OS@ia-os:5064>;tag=DLc84e319482 From: "OS2" <sip:[email protected]>;tag=DLe3e87fa44d CSeq: DLfeec059c53-5603793@ia-os INFO Call-ID: OS@ia-os-12:54:16:989ms-Jan13-2005-109875197 Max-Forwards: 70 Via: SIP/2.0/UDP 10.0.0.32:5060;branch=z9hG4bK-9e9a139214-DL Contact: "OS2" <sip:[email protected]:5060> Message body <?xml version="1.0" encoding="utf-8" ?><media_control><vc_primitive><to_encoder><picture_fast_update></picture_fast_update></to_encoder></vc_primitive></media_control>




Notes:




TTrraannssaaccttiioonn--ssppeecciiffiicc MMeessssaaggiinngg • Option 1: Request = INVITE / Transaction = successful




TTrraannssaaccttiioonn--ssppeecciiffiicc MMeessssaaggiinngg Option 1: Request = INVITE / Transaction = successful ⇒ If a transaction is initiated by a Request: INVITE-message, then the final Response: 200 shall be acknowledged by the UAC through a Request: ACK-

message. ⇒ Since this Request: ACK-message is considered as a new transaction, it shall be equipped with a new branch-parameter value ( “z9hG4bK-

Alpha2”). Note that each proxy between the two UA’s will add its own “Via:”-header field to the traversing Request: ACK-message which is different to an unsuccessful INVITE-transaction.

⇒ Despite this fact, the Request: ACK-message shall use the same “CSeq:”-value as the original Request: INVITE-message. However, the “CSeq:”-method shall be ACK [RFC 3261 (p.82)].

[RFC 3261 (17.1.1), (17.2.1)]

???? Question Section 14 ???? ⇒ Why does SIP deploy a “3-Way Handshake” –procedure (1. INVITE / 2. 200-OK / 3. ACK) in the first place? ⇒ Why is ACK considered as a new transaction?




OOppttiioonn 22:: RReeqquueesstt == IINNVVIITTEE // TTrraannssaaccttiioonn == uunnssuucccceessssffuull




OOppttiioonn 22:: RReeqquueesstt == IINNVVIITTEE // TTrraannssaaccttiioonn == uunnssuucccceessssffuull ⇒ If a Request: INVITE-message receives a negative response (Response: 3XX – 6XX), then the still necessary Request: ACK-message is considered

as part of the transaction and therefore shall use the same branch-parameter value as the Request: INVITE-message. ⇒ Note that unlike any previous messages of this transaction, the Request: ACK-message shall carry only a single “Via:”-header field entry even if

proxies are traversed. That is, any intermediate proxies will remove the previous “Via:”-header field entry and only add their own “Via:”-header field entry [RFC 3261 (17.1.1.3 / p.129)].

⇒ The “CSeq:”-value shall be identical to the original INVITE-message but the “CSeq:”-method shall be ACK. This, however, is no different to the aforementioned option 1.

[RFC 3261 (17.1.1.3), (17.2.1)]




OOppttiioonn 33:: RReeqquueesstt == IINNVVIITTEE // TTrraannssaaccttiioonn == ccaanncceelllleedd




OOppttiioonn 33:: RReeqquueesstt == IINNVVIITTEE // TTrraannssaaccttiioonn == ccaanncceelllleedd Request: CANCEL should only be used to cancel INVITE-transactions and it must not be used before a provisional response has been received.

⇒ If a pending Request: INVITE is cancelled by a Request: CANCEL-message, then the procedure as illustrated in the figure applies. ⇒ The Request: CANCEL-message shall use the same branch-parameter value and the same CSeq-value = Integer1 as the cancelled INVITE-Request

but the CSeq-method shall be CANCEL [RFC 3261 (p.54)]. ⇒ Despite the fact that the same branch-parameter and the same CSeq-number are used, CANCEL is considered as a new transaction

[RFC 3261 (p.54)] which requires a final response. Thus, the Request: CANCEL shall be responded to with a final response message which is a positive Response: 200-OK-message if the transaction to be cancelled exists [RFC 3261 (p.55)]. Please note the related values for branch, CSeq-value and CSeq-method as illustrated in the figure.

If the transaction to be cancelled is unknown in the UAS that receives a Request: CANCEL, then a Response: 481-Call Leg / Transaction Does Not Exist shall be used instead to answer to that Request: CANCEL [RFC 3261 (p.55).

⇒ Note that up to now, the original Request: INVITE did not receive a final response. If a cancellation occurs as illustrated in the figure, then this final response message for the Request: INVITE shall be a Response: 487-Request Terminated. The included branch-parameter value and the entire “CSeq:”-header field shall refer to the original Request: INVITE.

⇒ As already illustrated under “option2” on the previous slide, the final response ‘487’ for a Request: INVITE requires a Request: ACK-message which is also shown.

[RFC 3261 (9)]




OOppttiioonn 44:: RReeqquueesstt == RREEGGIISSTTEERR




OOppttiioonn 44:: RReeqquueesstt == RREEGGIISSTTEERR Note: • The term “location service” that we use underneath may contain more than one registrar in which case an inbound SIP-proxy server needs to select to

which particular registrar a registration attempt is being sent. • In case of the 3GPP-IMS, the registrar is called S-CSCF and the inbound proxy server is the I-CSCF which invokes the HSS to select a suitable S-

CSCF (e.g. based on load sharing considerations).

⇒ Consecutive Registration Transactions ( periodical and regular) towards the same location service shall be tagged through a monotonically

increasing “CSeq:”-number. This is done to allow the location service to distinguish retransmissions of the same Request: REGISTER from new REGISTER-messages.

⇒ In a 3GPP-IMS environment, the registering UA shall ask for an expires-time of 600000 s ( 166.7 hours) [3GTS 24.229 (5.1.1.2)]. Of course, the registrar ( S-CSCF) may reduce that time within the Response: 200-OK as indicated in the graphics.

⇒ Likewise, the branch-value within the “Via:”-header field shall be different in consecutive Request: REGISTER-messages (does not apply for retransmissions).

⇒ Still, the value of the “Call-ID:”-header field should remain the same for registrations of one sip-device towards the same registrar [RFC 3261 (p.58)]. This is true even if different users register consecutively from the same SIP-device. However, since the IP-address may be different after a system power down/power up, this requirement cannot always be met.

[RFC 3261 (10.2)]

???? Question Section 15 ???? ⇒ Please compare the illustrated procedure and messages with standard attachment/location updating and periodic location updating in GSM-mobile

networks. Use a pencil and draw the related scenario adjacent to the illustrated scenario and compare the message names. ⇒ Consider that a subscriber can register the same user identity (e.g. sip: [email protected]) from different devices (e.g. landline phone at

home, mobile device and work phone) and keep all registrations active simultaneously. In the yellow box at the top we mentioned a possible load sharing mechanism to select the very registrar: Can this load sharing mechanism operate only on a "per subscriber" or on a "per registration" basis ( per device) or on both?

⇒ How does a user de-register a certain device from a registrar? ⇒ Will the registrar be able to do the same?




OOppttiioonn 55:: AAllll OOtthheerr RReeqquueessttss • There is no difference in the message flow, irrespective of whether the

transaction is successful or not In any case there is no Request: ACK-message.




OOppttiioonn 55:: AAllll OOtthheerr RReeqquueessttss ⇒ For all other Requests ( other than INVITE, ACK, CANCEL and REGISTER) the respective message flow is illustrated on this slide. ⇒ Most importantly, these requests do require a final response message (2XX – 6XX) but there is no Request: ACK as for the Request: INVITE. Still, all

rules lined out for branch and “CSeq:” are fully applicable. ⇒ Note that there should be no provisional response messages for Non-INVITE-Requests, still, some implementations use provisional responses also in

these cases. [RFC 3261 (17.1.2), (17.2.2)]




PPrraaccttiiccaall EExxeerrcciissee • Please fill in the missing information elements or parameters, solely based

on the information provided on this page and the previous pages.




Notes:




AAmmeennddmmeennttss iinn ccaassee ooff mmoorree tthhaann ttwwoo PPeeeerrss • Overview: Forking Proxies




AAmmeennddmmeennttss iinn ccaassee ooff mmoorree tthhaann ttwwoo PPeeeerrss Introducing Different Contact Addresses per User ⇒ A user may have registered different contact addresses to his/her registrar. In our example, the user sip: [email protected] registered to her registrar

from different SIP-devices of which each one conveyed a different SIP-URI in the “Contact:”-header field to the registrar (not shown). These “Contact:”-header SIP-URI’s are the ones that we indicate as device SIP-addresses. Note that each of these “Contact:”-header SIP-URI’s relates to a specific IP-address

⇒ As illustrated, there is also a ‘q’-parameter (q = qualifier = 0.000 – 1.000) used during the registration to provide for a different prioritization of the different “Contact:”-addresses. The smaller ‘q’, the higher the priority. The forking registrar does not care in this case and relays the Request: INVITE to all destinations simultaneously. Alternatively, a predefined q=1.0 could be used as identifier for the voicemail URI of a user.

Behavior of Forking Proxies ⇒ Forking proxies either receive their location information from registrars or they are registrars themselves (the case which is illustrated in our example). ⇒ Such a forking proxy will relay a received Request: INVITE-message not only to a single destination but to several different ones.

The Terms Call, Dialog, Session and Transaction in case of Forking The figure emphasizes what we already introduced earlier: ⇒ A dialog between two peers is established as soon as the Response: 200-OK is received from the called peer. Each dialog is uniquely identified by the

“Call-ID:” and the “To:”- and “From:”-header field tags. ⇒ In case of multiparty ( in our example let Mary herself answer at device 1 but somebody else answers at device 2) a call consists of all the different

dialogs. Obviously, a call equals a dialog if only two parties are involved. ⇒ Although the detailed message parameters will be illustrated on the following slides we like to say that between the calling party and the registrar, all

messages except the Request: ACK’s for the Responses: 200-OK represent only a single transaction despite the fact that the two Response: 200-OK messages belong to two different dialogs!

⇒ Obviously, the registrar establishes a separate transaction to each of the called parties. And obviously, the relayed Request: ACK-messages towards device 1 and 2 are again separate transactions.

⇒ A very important new behavior of SIP-proxies in general is illustrated between the registrar and device 3. For one or another reason, device 3 rejects the incoming Request: INVITE with a final Response: 488-“Not Supported Here”.

Note: • In the example, the SIP-proxy / registrar does not relay this unsuccessful response to the calling party but rather handles the respective

acknowledgement independently and by itself. Likewise, such a SIP-proxy / registrar could issue a Request: CANCEL-message.

[RFC 3261 (p.78)]




((11)) MMeessssaaggee aanndd PPaarraammeetteerr DDeettaaiillss




((11)) MMeessssaaggee aanndd PPaarraammeetteerr DDeettaaiillss ⇒ While the previous slide focused on the impact of forking on dialogs and calls, the current slide is emphasizing on transactions and parameter details.

Obviously, only interesting message parameters have been illustrated. And obviously, this slide represents the same scenario as the previous slide. ⇒ The different colors shall highlight the different transactions. Therefore, we colored the branch-parameter synchronous with the columns underneath

the different devices. ⇒ The following lines on this and the next slide indicate which alphanumeric value (Alpha1, Alpha2 …) is used for which purpose in our scenario:

• Alpha1 Alpha1 is the Call-ID, unique for the entire call but it is identical for both dialogs.

• Alpha2 Alpha2 is the branch-parameter for the INVITE-transaction between the calling party and the registrar.

• Alpha3 Alpha3 is the “From:”-tag as allocated by the calling party. It is unique for this call but it is identical for both dialogs.

• Alpha4 Alpha4 represents the “To:”-tag which is allocated by device 1 ( sip:[email protected]). The dialog between device 1 and the calling party is unambiguously identified by the Call-ID = Alpha1, the From-tag = Alpha3 and the To-Tag = Alpha4. That means that all future messages of this dialog can be related to this dialog.

• Alpha5 Alpha5 represents the “To:”-tag which is allocated by device 2 ( sip:[email protected]). The dialog between device 2 and the calling party is unambiguously identified by the Call-ID = Alpha1, the From-tag = Alpha3 and the To-Tag = Alpha5. That means that all future messages of this dialog can be related to this dialog.

• Alpha7 Alpha7 is the branch-parameter for the INVITE-transaction between the registrar and device 1 ( sip:[email protected]).






((22)) MMeessssaaggee aanndd PPaarraammeetteerr DDeettaaiillss




((22)) MMeessssaaggee aanndd PPaarraammeetteerr DDeettaaiillss Note: • According to RFC 3261 (16.7.10), a forking proxy shall generate Request: CANCEL for all pending INVITEs that it sent out, once that the first

successful response is received from a UAS. • Therefore, the registrar in the example should have sent a Request: CANCEL to device 2 and to device 3 before their final responses are received. • The reception of multiple Responses: 200-OK by the registrar and consequentially by the original UAC can according to RFC 3261 (p.78) still not be

entirely excluded. • Note that the Request: ACK-messages for the Response: 200-OK-messages contain several “Via:”-header field entries opposed to the Request: ACK

for the unsuccessful Response: 488-“Not supported here” which shall in any case only contain a single “Via:”-header field entry [RFC 3261 (p.129)].

• Alpha6 Alpha6 represents the “To:”-tag which is allocated by device 3 ( sip:[email protected]). However, device 3 rejects the invitation so no dialog gets established between device 3 and the calling party.

• Alpha10 Alpha10 is the branch-parameter for the ACK-transaction between the calling party and the registrar which relates to the first dialog ( To-tag = Alpha4). Note that the CSeq-method is not INVITE but ACK.

• Alpha11 Alpha11 is the branch-parameter for the ACK-transaction between the registrar and device 1 ( sip:[email protected]). Note that the CSeq-method is not INVITE but ACK.

• Alpha12 Alpha12 is the branch-parameter for the ACK-transaction between the calling party and the registrar which relates to the second dialog ( To-tag = Alpha5). Note that the CSeq-method is not INVITE but ACK.

• Alpha13 Alpha13 is the branch-parameter for the ACK-transaction between the registrar and device 2 ( sip:[email protected]). Note that the CSeq-method is not INVITE but ACK.




SSuummmmaarryy • Call and Dialog

A call equals a dialog unless there are more than two peers. Each dialog is uniquely identified by the “Call-ID:”-value plus the pair of “From:”-tag and “To:”-tag.

• Session A session is established through SIP but it does not consist of SIP-messages. The session between two peers consists of the exchange of data of any kind.

• Transaction Each SIP-transaction consists of a SIP-request message and the one ore more related response messages which are exchanged between adjacent peers. The branch-parameter within the “Via:”-header field is used to identify all messages that belong to a single transaction between these adjacent peers.

• Impact of Forking The term “Forking” describes the relaying of a single INVITE to multiple destinations simultaneously or sequentially. A forking proxy ( always stateful) shall cancel all open invitations once that the first positive response is received from one peer.

• Forking and Multiparty Calls allow for one call to consist of more than one dialog




SSuummmmaarryy • Call and Dialog

Please keep in mind that the originator of a dialog allocates the “From:”-tag value and the “Call-ID:”-value and the responding user agent allocates the “To:”-tag value. All these parameters are alphanumeric values.

• Session SIP itself does not describe a session. Usually, SIP-message embedded SDP-parameters describe a session between two peers. This includes the definition of receiver IP-address and port number and codec types and modes.

• Transaction Consecutive transactions within a dialog use the monotonically increasing “CSeq:”-number to distinguish the related response messages from each other. The numbering of “CSeq:” is done independently per side. Please recall the exceptional request messages ACK and CANCEL that deserve special attention.

???? Question Section 16 ???? ⇒ Why do ACK and CANCEL deserve special attention?

• Impact of Forking If multiple Responses: 200-OK are received by the UAC, then the UAC will have to release all dialogs through a Request: BYE to be able to communicate with a single endpoint.

• Forking and Multiparty Calls allow for one call to consist of more than one dialog Simultaneous relay of the INVITE is called parallel forking and sequential relay is called sequential forking.

???? Question Section 17 ???? ⇒ Which parameter is only there to provide for multiple dialogs per call?




SSIIPP--MMeessssaaggee FFoorrmmaatt

Note: With the exception of the first line the sequence of the various header fields is arbitrary [RFC 3261 (7.3.1)].




SSIIPP--MMeessssaaggee FFoorrmmaatt General Information SIP-messages are either requests or responses. Both requests and responses consist of a message header and an optional message body which contains for instance an SDP-description. Each SIP-message is embedded in exactly one TCP- or UDP-frame. Note that by default, SIP will use UDP as transport protocol. The default destination port number for SIP-messages in TCP, SCTP and UDP is ‘5060’dec. If a secure transport layer ( TLS) is used or if SIPS (secure SIP) is used then the default port number shall be ‘5061’dec.

Request Messages Request messages are sent by a UAC (User Agent Client) to a UAS (User Agent Server). Each request message has a request-line as the first header line. This first line contains the:

⇒ SIP-message type, called “method”. Examples for methods are INVITE, ACK or REGISTER. We will later get back to the different methods. ⇒ Request URI (sip-URI, sips-URI or tel-URI) which specifies the destination of that SIP-message. ⇒ SIP-Version. This version shall be “SIP/2.0” if RFC 3261 is used.

The request line shall terminate with a <CRLF>. Various additional header fields follow of which some are mandatory while others are optional. Each header field line shall terminate with <CRLF>. The end of the header is indicated through an empty line which only consists of <CRLF>.

Response Messages Response messages are sent by a UAS (User Agent Server) to a UAC (User Agent Client). Each response message has a status-line as the first header line. This first line contains the:

⇒ SIP-Version. This version shall be “SIP/2.0” if RFC 3261 is used. ⇒ Numeric status code (e.g. ‘200’dec). ⇒ Human readable interpretation of the status code which is called a reason-phrase.

Like the request line in request messages, the status line in response messages shall terminate with a <CRLF>. Various additional header fields follow of which some are mandatory while others are optional. Each header field line shall terminate with <CRLF>. The end of the header is indicated through an empty line which only consists of <CRLF>.

Note: The format of SIP-messages is inherited from HTTP.

[RFC 3261 (7)]




SSIIPP--MMeessssaaggee CCoonntteennttss • The Request Line (Request Messages only)




SSIIPP--MMeessssaaggee CCoonntteennttss The Request Line (Request Messages only)

• Method Each Request-Line contains the “method” which shall be invoked. Methods rather represent the type of a SIP-message. The different method types will be elaborated in more detail on the following pages.

• Request-URI The Request-URI identifies the UA that shall process this request. Usually, this will be the called party but in case of the REGISTER-method, the Request-URI identifies the registrar.

• SIP-Version For SIP-messages which are compliant to the current version of SIP as specified in RFC 3261 and accompanying specifications, the SIP-version shall be 2.0. [RFC 3261 (7.1)]




((11)) TThhee DDiiffffeerreenntt MMeetthhoodd--TTyyppeess Method Type RFC-Number REGISTER RFC 3261

INVITE RFC 3261 ACK RFC 3261

CANCEL RFC 3261 BYE RFC 3261

OPTIONS RFC 3261 INFO RFC 2976




((11)) TThhee DDiiffffeerreenntt MMeetthhoodd--TTyyppeess REGISTER Through the REGISTER-method a SIP-UAC associates his / her SIP(S)-URI to his / her current location ( IP-address). REGISTER-requests are always destined to a specific server in the home domain, called registrar. Registrations are time limited through the “expires”-parameter which is part of the “Contact:”-header field. The “expires”-parameter is measured in seconds. The same REGISTER-method is also used for client based deregistration.

INVITE The INVITE-method is used by a SIP-UAC to establish a dialog and a session towards one or more SIP-UAS’s. Either the originating user is aware of the IP-address or fully qualified domain name of the called party and can send the INVITE-request directly to the called party or the INVITE-request is sent to the IP-address of SIP-proxy which will evaluate the “To:”-header field and try to further process the INVITE-request. Note that the INVITE-request will typically include an SDP-description in its message body.

ACK The SIP-UAC shall send an ACK-request for every final response (2XX-6XX-responses / except if received after BYE-request and except another request message is being sent) which is received. Example: During session setup the UAC will eventually receive the final “200 (OK)”-message from the UAS which also contains the called party’s SDP-description. This response message needs to be responded to with an ACK-request message.

CANCEL The CANCEL-method is used by a UAC to cancel a pending request that was originated by the UAC. RFC 3261 recommends not to cancel any other requests than INVITE-requests.

BYE The BYE-method is used by a UAC to terminate an active dialog and the related session. A session is considered active after the final “200 (OK)”-message is responded to with an ACK-request.

OPTIONS The OPTIONS-method is used by a UAC to retrieve information about another UA’s or SIP-proxy’s capabilities with respect to supported coders, method-types, languages and compression methods.

INFO The INFO-method is used to piggyback in-call signaling information to a UAS. Examples for such information are DTMF-digits or XML-encoded user information.




((22)) TThhee DDiiffffeerreenntt MMeetthhoodd--TTyyppeess Method Type RFC-Number

MESSAGE RFC 3428 SUBSCRIBE RFC 3265

NOTIFY RFC 3265 PUBLISH RFC 3903 PRACK RFC 3262 REFER RFC 3515

UPDATE RFC 3311




((22)) TThhee DDiiffffeerreenntt MMeetthhoodd--TTyyppeess MESSAGE Through the MESSAGE-method, a SIP-UAC is able to send text messages to a SIP-UAS. Messages which are sent outside of an active session should be no longer than 1300 octets. If a session is active, longer text messages may be sent. When a SIP-UAS receives a MESSAGE-method message, it shall respond to it with a “200 (OK)”-response message.

SUBSCRIBE Through the SUBSCRIBE-method, a SIP-UAC subscribes to be notified in case of specific events to occur (e.g. another user registers again). The respective notification is sent to the party which sent the SUBSCRIBE-request through the NOTIFY-request. Similar to registrations, subscriptions to event notifications are always time limited and need to be refreshed if necessary.

NOTIFY See SUBSCRIBE-method.

PUBLISH The PUBLISH-method is related to the SUBSCRIBE- and NOTIFY-methods. It allows publishing certain events to an event server like configuration changes that in turn shall be notified to all subscribed devices.

PRACK PRACK stands for Provisional Response ACKnowledgement. When a SIP-session is being activated there are quite a number of so called provisional responses (e.g. (183) Session Progress) which are not acknowledged by the receiver and which therefore may be retransmitted, if there is no state change. The PRACK-method allows acknowledging these provisional responses and therefore prevents retransmissions and provide for a better synchronization between called and calling party.

REFER Through the REFER-method, a called party or the responsible registrar is able to refer the calling party (upon INVITE) to another destination (SIP-URI). Therefore, the REFER-method can be used for e.g. call forwarding to voice mail or call transfer services.

UPDATE The UPDATE-method is used similarly to INVITE but unlike INVITE it can be used before the Response: 200-OK is received for the initial INVITE. That is, the UPDATE-method can be used already during so called “early dialogs” which is the time between reception of a non-100 provisional response for the initial INVITE and reception of a final response. During this time, UPDATE can for example be used to adapt session description parameters or to convey resource reservation related information as per RFC 3312.




AAddddrreessss SSppeecciiffiiccaattiioonn // RReeqquueesstt--UURRII • The “tel”-URI




AAddddrreessss SSppeecciiffiiccaattiioonn // RReeqquueesstt--UURRII SIP allows for different means how to specify the destination of a SIP-message: 1. The “tel-URI” which is based on the ITU-T E.164 numbering scheme used in the PSTN; 2. The “SIPS-URI” which is used if the called party requires a secure transport connection (IPsec / TLS); 3. The “SIP-URI”.

The “tel”-URI The structure of the “tel-URI” is illustrated in the figure. It always starts with the string “tel:”. The telephone number itself needs to be provided in international format e.g. +49-721-9578290. Note that country code, national destination code and telephone number shall be separated through “-“ ( hyphen).

Note: We represent the Request-URI is an ASN.1 compliant way as folder tree with sequences and choices. Green colored files and folders indicate optional presence. This way of presentation is done for illustration only. The respective RFC’s do not use ASN.1

[RFC 2806]




TThhee SSIIPP((SS))--UURRII




TThhee SSIIPP((SS))--UURRII • SIP or SIPS

The SIP(s)-URI starts with the text string “SIP:” to indicate that the following identifiers relate to a SIP-URI or with the text string “SIPS:” to indicate that a SIPS-URI follows.

• Userinfo The presence of the element “userinfo” is optional but highly recommended to identify a user using his / her fully qualified domain name (e.g. [email protected]). The userinfo consists of either a username or a telephone number. Either element may be followed by an optional password which is separated from the userinfo through the character “:”. The use of a password in the Request-URI is not recommended by the specifications. In either case, the userinfo ends with the character “@”.

• Hostport The presence of the element “hostport” is mandatory. It consists of: ⇒ the element “host” which includes either an IP-address (in which case there would be no userinfo) or a host domain name (e.g. cakao.net). Note that

the use of IP-addresses as host-ID is not recommended. ⇒ optionally a port number where this request shall be sent to at the receiver side (the default port number for SIP is ‘5060’dec.

• uri-parameters The presence of uri-parameters is optional. If one or more uri-parameters are present, their listing is separated from the element “hostport” through the character “;” which is also used to separate different parameters from each other. Different parameters depend on each other. For instance, only when the maddr-parameter (server address of that user) identifies a multicast IP-address, then the “ttl”-parameter (time to live) shall be present. The “transport” parameter specifies the transport protocol to be used for SIP-messages relating to this request. The “lr”-parameter indicates that the sending UA uses loose source routing. [RFC 3261 (19.1)]




TThhee SSttaattuuss LLiinnee




TThhee SSttaattuuss LLiinnee • SIP-Version

For SIP-messages which are compliant to the current version of SIP as specified in RFC 3261 and accompanying specifications, the SIP-version shall be 2.0.

Status Code and Reason Phrase Each Response-Line contains a status code which is followed by a human readable “reason-phrase”. Responses are always relates to previous requests and indicate the status of a session or dialog. The following response code types have to be distinguished:

• Provisional Responses (1XX) Provisional responses are sent by a UAS to inform the UAC that a request is being processed but that no final response can be given yet. This happens when the server determines that at least another 200 ms will be required to provide a final response. Provisional responses are also called informational responses. In contrast to final responses (2XX, 3XX, 4XX, 5XX and 6XX) there is no ACK-request being sent in reaction to a provisional response. Optionally, a provisional response can be responded to by a PRACK-request.

• Success (2XX) There is only one 2XX-response code which is the 200-response code. It indicates “success” of a request.

• Redirection (3XX) The 3XX-response codes tell the requester that a request cannot be suited but in contrast to failure codes, the 3XX-response codes direct the requester to an alternative direction where the request may possibly be successful. Example: 301 User moved permanently to the address provided in the same message.

• Client Error (4XX) 4XX-responses are final failure responses which are due to a problem with the original request. The request must not be repeated before it has been modified. Examples for errors are timeouts, missing authentication, ….

• Server Error (5XX) The 5XX-responses are final failure responses which are due to server error. Examples are congestion, SIP-message was too long, ….

• Global Failure (6XX) The 6XX-responses are final responses which indicate some problem at the peer user. For instance, the peer user did not accept the call or the peer user does not exist anywhere. [RFC 3261 (7.2), (13.2.2.1 – 13.2.2.4), (21)]




TThhee ““FFrroomm::”” aanndd tthhee ““TToo::”” HHeeaaddeerr FFiieellddss




TThhee ““FFrroomm::”” aanndd tthhee ““TToo::”” HHeeaaddeerr FFiieellddss Note: This header field and some others use the so called compact form to shorten a SIP-message. Example: On the graphics page, “From:” and “To:” are the regular text strings while “f:” and “t:” are the compact form.

The “From:” and the “To:” header fields identify the logical names of the requester and the destination of a SIP-message. Especially the “From:”-field should identify e.g. the human being behind the request to allow for automatic call rejection.

Display-Name The “Text”-field is optional and may be used for what is called a display name (e.g. the caller’s first and last name). However, if the display-name is used, then the SIP(S)-URI shall be enclosed by the characters “<” and ”>”.

Tag The “tag”-element shall be present in each “From:”-header field. Together with the “Call-ID:”-header field and the “tag”-element in the related response messages in represents a unique identification of a SIP-dialog. Note that there shall be no “tag”-element in the “To:”-header field, if no dialog is established. The “tag”-field shall be generated randomly to provide uniqueness. [RFC 3261 (8.1.1.2), (8.1.1.3)]




TThhee ““CCaallll--IIDD::”” aanndd ““MMaaxx--FFoorrwwaarrddss::”” HHeeaaddeerr FFiieellddss




TThhee ““CCaallll--IIDD::”” aanndd ““MMaaxx--FFoorrwwaarrddss::”” HHeeaaddeerr FFiieellddss Call-ID The “Call-ID:”-header field is randomly selected and assigned when a UAC initiates a session. It shall be used by the UAC, the intermediate proxies and the UAS to group together a sequence of messages that belong to one dialog.

Max-Forwards The “Max-Forwards:”-header field indicates the number of hops before a SIP-message shall be discarded. The recommended value is ‘70’dec. [RFC 3261 (8.1.1.4), (8.1.1.6)]




TThhee ““CCSSeeqq::”” HHeeaaddeerr FFiieelldd




TThhee ““CCSSeeqq::”” HHeeaaddeerr FFiieelldd The “CSeq:”-header field represents a sequence number for request-messages within a dialog. Every new request message within a dialog shall have an incremented “CSeq:”-value compared to the previous request. The only exception to this rule are ACK-requests and CANCEL-requests which shall have the same “CSeq:”-value as the request which they acknowledge or cancel. The related response messages shall mirror the entire “CSeq:”-field (that is, value and method shall be identical as in the request message). [RFC 3261 (8.1.1.5)]




TThhee ““VViiaa::”” HHeeaaddeerr FFiieelldd




TThhee ““VViiaa::”” HHeeaaddeerr FFiieelldd The “Via:”-header field is used to determine the route back to the original sender. When a UAC issues a request it shall insert the first entry into the “Via:”-header field. Every SIP-proxy server on the way to the final destination (as identified by the “To:”-header field) shall add another entry in front of the entry of the previous node. Consequently, responses will travel the same way back to the original requester. In the figure, the variable “m” indicates that the “Via:”-header field may contain up to m entries. In fact, the variable “m” indicates the number of “SIP-hops” that a SIP-message already experienced from its origin to the current position. In addition to the identification of the “next hop” which is identified through its port number and host-element (see SIP(S)-URI) , the “Via:”-header field mandatorily contains the branch-parameter which is randomly selected and assigned by UAC, receiving UAS and each intermediate SIP-proxy server. This branch parameter shall be unique for each request sent by a UAC. Compliance with RFC 3261 instead of RFC 2543 is indicated by the branch-parameter starting with the string ‘z9hG4bK”. The parameters “received” and “rport” [RFC 3581] are particularly important in case of NAT/NAPT.

Note: The “Via:”-header field assures that responses are routed the same way as requests. This allows for instance that charging can properly be done.

[RFC 3261 (8.1.1.7)]

???? Question Section 18 ???? ⇒ The provision of the “port number” behind the host is optional and apparently not necessary if it is the default port number ‘5060’. The question is

when do I have to fill in this field even if the port number is ‘5060’?




TThhee ““CCoonnttaacctt::”” HHeeaaddeerr FFiieelldd




TThhee ““CCoonnttaacctt::”” HHeeaaddeerr FFiieelldd The “Contact:”-header field most importantly identifies the originator of that request to be used as identifier in subsequent requests. The “Contact:”-header field value may contain a display-name, a URI with URI parameters (see SIP(S)-URI) and additional header parameters. Only the provision of the SIP(S)-URI is mandatory. The enclosing “<” and “>” are mandatory, if a display-name is preceding. As the figure illustrates, “Contact:”-specific parameters shall be delimited from each other through a “;”-character. Context-specific parameters may be defined but the two indicated parameters “q” and “expires” must only be present in REGISTER-request messages. The parameter “q” allows to relatively prioritizing subsequent REGISTER-requests from different locations to be contacted in case of a terminating transaction. The parameter “expires” contains the registration timeout (the period after which re-registration is required) as desired by the user in REGISTER-request messages or the possibly downgraded timeout in the respective response message from the registrar. Note that the “contact-params” are provided per “Contact:”-parameter which means that different expiration times can be indicated per “Contact:”-address. As an alternative, the dedicated “Expires:”-header field can be used which then applies globally [RFC 3261 (10.2.1.1)]. [RFC 3261 (8.1.1.8), (20.10)]

Note that in 3GPP-networks, the UA shall re-register 600 seconds before the “expires”-timer expires (if the timer value is larger than 1200 s) or after half of the time indicated by the “expires”-timer has elapsed (if the timer value is 1200 s or smaller) [3GTS 24.229 (5.1.1.4)]




SSIIPP--TTiimmeerrss • Overview




SSIIPP--TTiimmeerrss Overview As the figure illustrates, one can distinguish different types of timers in SIP. There are:

• Transaction Surveillance Timers They exist differently for both the UAC and the UAS. These timers are typically set to 32 s (default) and upon expiry a transaction is deleted in that SIP-device.

• Request Retransmission Timers These timers are used on the UAC-side and they determine when a SIP-Request shall be retransmitted. Different timers have been defined for Request: INVITE vs. all other Requests (called Non-INVITE, except ACK-Request).

• Response Retransmission Timers SIP as defined in RFC 3261 observes at least the proper reception of final response messages. We will in an upcoming chapter also introduce acknowledgements for provisional responses which have been described in RFC 3262.

Note: • All timers in SIP are based on the round-trip-time (RTT) timer T1 which defaults to 500 ms. • Most timers presented are only applicable if UDP is used in the transport layer. • SIP-Proxies run additional transaction timeout timers ( timer C > 3 min).

[RFC 3261 (Annex A)]

???? Question Section 19 ???? ⇒ Does the final bullet in the yellow box relate to stateful and stateless SIP-proxies or only to stateful ones?




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- RReessppoonnssee:: 220000--OOKK))




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- RReessppoonnssee:: 220000--OOKK)) Overview When the UAC issues the Request: INVITE-message, it will start timer A and timer B within its transaction handling sublayer.

Reception of Provisional Response Upon reception of the first related provisional response message, timer A and timer B shall be stopped. Consequentially, any retransmissions of the Request: INVITE stop.

Also timer B shall be stopped when the first provisional response message is received. However, this may lead to everlasting transactions when the UAS does never send a final response message. To avoid this from happening, the initial Request: INVITE-message may be equipped with an “Expires:”-header field that indicates how long the INVITE will be valid. Implementation depending, the transaction user / UAC-core sublayer may operate another transaction timeout timer to be able to detect and delete dead INVITE-transactions.

Reception of Response: 200-OK Upon reception of the first Response: 200-OK, the UAC-core ( one layer above the UAC) shall start a timer of 64 x T1 duration which allows the UAC-core to collect further incoming Response: 200-OK-messages. Each one needs to be responded to with a Request: ACK-message. [RFC 3261 (17.1.1), (p.82-83), Annex A]

???? Question Section 20 ???? ⇒ When is a “To:”-tag included in the indicated Response: 100-Trying message?

Timer 1, Timer A and Timer B in case of 3GPP-Networks

Timer Value to be used between P-CSCF and UE Value to be used between SIP-nodes within the IMS

Timer 1 (T1) 2 s 0.5 s

Timer A Initially T1 Initially T1

Timer B 128 s 32 s

[3GTS 24.229 (7.7)]




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- RReessppoonnssee:: 33XXXX –– 66XXXX))




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- RReessppoonnssee:: 33XXXX –– 66XXXX)) Overview When the UAC issues the Request: INVITE-message, it will start timer A and timer B within its transaction handling sublayer.

Reception of Provisional Response Upon reception of the first related provisional response message, timer A and timer B are stopped. Consequentially, any retransmissions of the Request: INVITE stop.

Also timer B shall be stopped when the first provisional response message is received. However, this may lead to everlasting transactions when the UAS does never send a final response message. To avoid this from happening, the initial Request: INVITE-message may be equipped with an “Expires:”-header field that indicates how long the INVITE will be valid. Implementation depending, the transaction management sublayer may operate another transaction timeout timer to be able to detect and delete dead INVITE-transactions.

Reception of Response: 3XX – 6XX Upon reception of a failure response message ( Response: 3XX – 6XX), the UAC should start timer D within its transaction handling sublayer. Timer D is used in case of UDP-transport to allow the UAC to collect possibly incoming retransmissions of the failure response message. [RFC 3261 (17.1.1), Annex A]

???? Question Section 21 ???? ⇒ Will the UAC on the left side be able to initiate another session / send another Request: INVITE while timer D is still running? ⇒ Which entity selects the transport protocol (UDP, TCP) between two SIP-nodes?




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee –– nnoo RReessppoonnssee rreecceeiivveedd))




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- nnoo RReessppoonnssee rreecceeiivveedd)) Overview When the UAC issues the Request: INVITE-message, it will start timer A and timer B within its transaction handling sublayer.

Expiry of Timer A Upon each expiry of timer A, the UAC will retransmit the Request: INVITE-message. Note that the duration of timer A doubles with each expiry ( exponential back off).

Considering that timer B has duration of 32 s, the UAC will be able to retransmit the Request: INVITE-message 6 times.

Expiry of Timer B If no provisional response message is received even after altogether 7 transmissions of the Request: INVITE-message, then timer B expires and there is a transaction timeout.

???? Question Section 22 ???? ⇒ With respect to the retransmitted Request: INVITE-messages: Will the Call-ID-, CSeq- and branch-values be identical in all instances? [RFC 3261 (17.1.1), Annex A]




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAASS--SSiiddee sseenntt 33XXXX –– 66XXXX –– wwaaiitt ffoorr AACCKK))




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAASS--SSiiddee sseenntt 33XXXX –– 66XXXX –– wwaaiitt ffoorr AACCKK)) Overview When the UAS receives the Request: INVITE-message, it may issue a number of provisional response messages. In the illustrated case, the UAS then generates an unsuccessful final response message (3XX – 6XX) and starts timers G and H within its transaction management sublayer.

Expiry of Timer G Upon each expiry of timer G the UAS will retransmit the final response message. Note that the duration of timer G doubles with each expiry ( exponential back off) until a maximum retransmit interval of T2 = 4 s is reached. This interval is also kept for consecutive retransmissions.

Expiry of Timer H Upon expiry of timer H the UAS considers the transaction as timed out and stops retransmitting the final response message (3XX – 6XX). [RFC 3261 (17.2.1), Annex A]

Note that retransmissions of a successful Response: 200-OK are not handled by the transaction handling sublayer but within the transaction management / UAS-core sublayer [RFC 3261 (p.135)]. This case is illustrated on the following page.

Timer 1, Timer 2, Timer G and Timer H in case of 3GPP-Networks


Timer 1 (T1) 2 s 0.5 s

Timer 2 (T2) 16 s 4 s

Timer G Initially T1 Initially T1

Timer H 128 s 32 s

[3GTS 24.229 (7.7)]




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAASS--SSiiddee sseenntt 220000--OOKK –– wwaaiitt ffoorr AACCKK))




IINNVVIITTEE TTrraannssaaccttiioonn ((UUAASS--SSiiddee sseenntt 220000--OOKK –– wwaaiitt ffoorr AACCKK)) Overview When the UAS receives the Request: INVITE-message, it may issue a number of provisional response messages. In the illustrated case, the UAS then generates a successful final Response: 200-OK which terminates this transaction within the transaction management sublayer. Therefore, the UAS-core / transaction user sublayer need to track whether a Request: ACK is received or whether the Response: 200-OK (buffered now within the UAS-core / transaction user sublayer) need to be retransmitted. Accordingly, there are UAS-core timers involved in this case opposed to timers G and H in the aforementioned case.

Expiry of UAS-Core Timer (T1) Upon expiry of the related UAS-core timer, the UAS will retransmit the Response: 200-OK-message. Note that the duration of the UAS-core timer doubles with each expiry ( exponential back off) until a maximum retransmit interval of T2 = 4 s is reached. This interval is also kept for consecutive retransmissions.

Note that opposed to the aforementioned case (unsuccessful final responses) the retransmission of Response: 200-OK-messages also occurs in case of reliable transports [RFC 3261 (p.85)].

Expiry of 2.UAS-Core Timer (64 x T1) Upon expiry of the second UAS-core timer, the UAS considers the transaction as timed out and issues a Request: BYE-message to the originally inviting party. Note that the Request: BYE is only sent, if a Response: 200-OK was sent before [RFC 3261 (p.85+86), (Annex A]. Note that there is a contradiction with RFC 3261 (p.259) which prohibits the transmission of a Request: BYE before a Request: ACK is received.

???? Question Section 23 ???? ⇒ Why does the former UAS send the Request: BYE-message only in case a Response: 200-OK was sent?

Timer 1 and Timer 2 in case of 3GPP-Networks


Timer 1 (T1) 2 s 0.5 s

Timer 2 (T2) 16 s 4 s

[3GTS 24.229 (7.7)]




””NNoonnee““--IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- RReessppoonnssee:: 22XXXX –– 66XXXX))




““NNoonnee““--IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- RReessppoonnssee:: 22XXXX –– 66XXXX)) Overview When the UAC issues a “None”-INVITE-Request, it will start timer F and possibly timer E within its transaction management sublayer. This relates to all SIP-requests, except Request: ACK ( CANCEL, MESSAGE, OPTIONS, INFO…).

Timer E and Timer F ⇒ Timer E is there to control retransmissions of the Request: “None”-INVITE-message in case of unreliable transport protocols ( UDP). ⇒ Timer F is the transaction surveillance timer. ⇒ As illustrated in the figure, the UAC will retransmit the Request: “None”-INVITE-message upon expiry of timer E. Note that the reception of provisional

response messages for that Request has no impact on timer E. ⇒ Both, timer E and timer F will be stopped only upon reception of a final response message which relates to that transaction.

Timer K ⇒ When timers E and F are stopped, the UAC will start timer K in case of unreliable transport protocols ( UDP) to be able to collect additional final

responses which have been sent by the peer as responses for received Request-retransmissions.. ⇒ Upon expiry of timer K, the transaction ends. [RFC 3261 (17.1.2), Annex A]

Timer 1, Timer E, Timer F and Timer K in case of 3GPP-Networks


Timer 1 (T1) 2 s 0.5 s

Timer E Initially T1 Initially T1

Timer F 128 s 32 s

Timer K 17 s 5 s

[3GTS 24.229 (7.7)]




””NNoonnee““--IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- nnoo RReessppoonnssee))




””NNoonnee““--IINNVVIITTEE TTrraannssaaccttiioonn ((UUAACC--SSiiddee -- nnoo RReessppoonnssee)) Overview When the UAC issues a “None”-INVITE-Request, it will start timer F and possibly timer E within its transaction management sublayer. This relates to all SIP-requests, except Request: ACK ( CANCEL, MESSAGE, OPTIONS, INFO…).

Timer E ⇒ Timer E is there to control retransmissions of the Request: “None”-INVITE-message in case of unreliable transport protocols ( UDP). ⇒ Timer F is the transaction surveillance timer. ⇒ As illustrated in the figure, the UAC will retransmit the Request: “None“-INVITE-message upon every expiry of timer E. The duration of timer E doubles

with each expiry ( exponential back off) until a maximum retransmit interval of 4 s is reached. ⇒ Note that the reception of provisional response messages for that Request has no impact on timer E.

Expiry of Timer F ⇒ Upon expiry of timer F, the UAC considers a transaction timeout and deletes the transaction. [RFC 3261 (17.1.2), Annex A]

Timer 1, Timer 2, Timer E and Timer F in case of 3GPP-Networks


Timer 1 (T1) 2 s 0.5 s

Timer 2 (T2) 16 s 4 s

Timer E Initially T1 Initially T1

Timer F 128 s 32 s

[3GTS 24.229 (7.7)]




““NNoonnee““--IINNVVIITTEE TTrraannssaaccttiioonn ((UUAASS--SSiiddee -- ffiinnaall RReessppoonnssee sseenntt))




““NNoonnee““--IINNVVIITTEE TTrraannssaaccttiioonn ((UUAASS--SSiiddee -- ffiinnaall RReessppoonnssee sseenntt)) Overview When the UAS receives a ”None“-INVITE-Request, it will not start any timer until a final response is transmitted.

Timer J ⇒ Upon transmission of the final response message, the UAS will start timer J to be able to collect and react upon retransmissions of the same “None“-

INVITE-Request. ⇒ Upon expiry of timer J, the transaction ends. [RFC 3261 (17.2.2), Annex A]

Timer 1 and Timer J in case of 3GPP-Networks


Timer 1 (T1) 2 s 0.5 s

Timer J 128 s 32 s

[3GTS 24.229 (7.7)]




TThhee SSeessssiioonn DDeessccrriippttiioonn PPrroottooccooll ((SSDDPP)) • Structure of SDP-Parameters within a SIP-Message (Example)




TThhee SSeessssiioonn DDeessccrriippttiioonn PPrroottooccooll ((SSDDPP)) Structure of SDP-Parameters within a SIP-Message (Example) The session description protocol is, at least in context with SIP, a protocol without messages. It manifests itself only within the body of SIP-messages.

That is, SDP is nothing else but a set of information elements within the body of a SIP-message. However, only some messages contain SDP-content.

The sequence of SDP-parameters within a SIP-message is always the same:

• Part 1: Session Description Items This part contains several lines of ASCII-encoded information which contains overall, common session related information. This relates to global information about a session like the origin and the IP-address and IP-address type of the sender of this SDP.

• Part 2: Time Description Items This part contains start and end time of the session to be setup. However, this information usually redundant and only there for compliance reasons with the original SDP-specification. The time descriptors are there for historic purposes and stem from the time when SDP was introduced to invite participants in possibly different time zones for possibly time shifted telephone conference sessions.

• Part 3: Media Description Items The one or more media descriptors most importantly identify the one or more media types and the related codec types to be used. They also identify as to which port number a media stream shall be sent.

Note how easy the description of multiple media streams for a single session is.

[RFC 2327, RFC 4566, http://www.iana.org/assignments/sdp-parameters]




LLooggffiillee EExxaammppllee:: SSeessssiioonn aanndd MMeeddiiaa DDeessccrriippttoorrss tthhrroouugghh SSDDPP

Connection Information: IN = <network type>( Internet) IP4 = <address type> ( IPv4-address) 10.0.0.32 = <connection address>

Media Announcements (suggested): “audio” ⇒ Audio only “5006” ⇒ the UDP Port Number at which this peer expects the other peer to send audio data to. “RTP/AVP” ⇒ The Transport Protocol to be used (in this case RTP/UDP/IP) “3 0 8” ⇒ The suggested media formats (see RTP-Payload Type) in a prioritized list 3 GSM, 0 G.711 (µ-law) 8 G.711 (a-law) The transmitter of this message needs to be prepared to receive audio information encoded with any of the indicated codec types.

Time Information: 0 = <start time>( immediate) 0 = <end time>( no end time defined)




LLooggffiillee EExxaammppllee:: SSeessssiioonn aanndd MMeeddiiaa DDeessccrriippttoorrss tthhrroouugghh SSDDPP Additional Information

⇒ It is worth to mention that the statement in the yellow box “… encoded with any of the indicated codec types.” applies fully: The other peer may during the session at any time switch to another codec than what was used initially.

⇒ This obviously will cause an interruption until the new codec mode has resynchronized but it allows to switch to more error-resilient codecs, if there are means to determine that transmission quality dropped.

⇒ Note that the IETF recommends in the RFC 4504 (2.14 / Req. 72) that all SIP-devices support the iLBC-voice codec (Internet Low Bitrate Codec).The license-free iLBC-voice codec is a relatively new development (Dec 2004) with data rates of 13.33 kbit/s and 15.2 kbit/s. It has been published in RFC 3951 and its transfer through RTP has been described in RFC 3952.




SSeessssiioonn DDeessccrriippttiioonn IItteemmss • Overview




SSeessssiioonn DDeessccrriippttiioonn IItteemmss Overview The figure illustrates a more detailed view on the different session specific SDP-items that appear in an SDP. In that respect, the figure illustrates which parts of the session specific SDP-items have to be included mandatorily, conditionally or optionally.

The sequential order of the various lines (e.g. v=…, o=…, s=…, …) within an SDP-description is not arbitrary but it is predefined and must be obeyed. The table illustrates this sequential order with focus on the important lines [RFC 4566 (p.8)]

The “v=”-Line (Version) Although many amendments have been added to the genuine SDP as defined in RFC 2327, we still use SDP-version No 0. This line is therefore fixed encoded and identical in every session description. [RFC 2327 (p.9)]

Note that RFC 2327 and many amendments for it will soon be replaced and updated by a new RFC which is currently still a draft: draft-ietf-mmusic-sdp-new-<version>.txt.

The “s=”-Line (Session Name) The s-line shall be present [RFC 2327, RFC 4566] and it shall contain the name of the session. However, RFC 3264 (p.5) recommends using either a single space character or a hyphen (“-“) for the session name [RFC 2327 (p.10)]. [RFC 2327, RFC 4566 (5), http://www.iana.org/assignments/sdp-parameters]




TThhee ““oo==””--LLiinnee ((OOrriiggiinn))




TThhee ““oo==””--LLiinnee ((OOrriiggiinn)) The o-line contains global session related information and information about the originator of the session. To be more specific: Username This parameter shall identify the user or the device that sends this session description. Still, usually there is no such information available and a simple hyphen (“-“) is used instead [RFC 2327 (p.9)]. Session-ID The session-ID shall be a 64 bit integer value, preferably generated according to the NTP-timestamp value of the sender’s device. However, the use of NTP-timestamps is not mandated and therefore, any session-id which provides reasonable uniqueness is acceptable [RFC 2327 (p.9)]. Session-Description-Version Similarly to the session-id, the session-description-version shall be a 64 bit integer value. However, its initial value shall be less than 262-1 to avoid any overflows while a session is active. The reason is that either peer may during a session change session or media parameters and any new session description version shall be identified by the same session-id but an incremented session-description-version [RFC 2327 (p.9), RFC 3264 (p.5)] Network-type The only defined network type is “IN” for the internet [RFC 2327 (p.10)] and ATM for ATM-based networks [RFC3108]. Address-type Defined address types are IPv4- and IPv6-addresses for network type “IN” and therefore the setting of this parameter is usually either “IP4” or “IP6”. Note that RFC 2327 clearly recommends the use of FQDN’s (e.g. device10.inacon.com) rather than plain IP-addresses and if plain IP-addresses are used then in should be globally unique ( not private) IP-addresses [RFC 2327 (p.10)]. In real life, the used address is rarely an FQDN and the IP-addresses are frequently private ones. As illustrated, ATM-networks use E164-numbers, NSAP (Network Service Access Point) and GWID (Gateway ID) instead [RFC 3108]. Address This parameter includes the address of the originator of this session description. Note that this address is not necessarily identical to the connection address to which data shall be sent to (see next page). The address will be an FQDN (e.g. device10.inacon.com), IPv4- or IPv6-address in case of IP-based networks or an NSAP, an E.164-telephone number or a GWID in case of ATM-based networks. [RFC 4566 (5.2), RFC 3108]




TThhee ““cc==””--LLiinnee ((CCoonnnneeccttiioonn IInnffoo))




TThhee ““cc==””--LLiinnee ((CCoonnnneeccttiioonn IInnffoo)) ⇒ The c-line seems to replicate information which was already provided through the o-line but this impression is not correct. While the o-line provides

information about the session originator, the c-line tells the peer as to which network address media data shall be sent to. ⇒ This will usually be the same address which is used in the o-line but consider the frequently appearing need for interworking in some gateway

between the two peers. Such needs may be NAT or codec conversions. In such cases, the c-line will rather state the network address ( IP-address) of the gateway than of either peer.

⇒ [RFC 2327 (p.13)] explicitly encourages the use of FQDN’s rather than IP-addresses and discourages the use of private IP-addresses but as stated previously, private IP-addresses are frequently used.

⇒ Initially, IPv6-addresses could not be used within the c-line. This amendment was provided through RFC 3266 and has been incorporated into RFC 4566.

⇒ Note that the indicated c-line applies to unicast IP-addresses only. The address field may contain additional parameters in case of multicast addresses. Please refer to RFC 2327 (p.13).

⇒ In the figure we also included the ATM-network specific network and address identifiers NSAP, E164 and GWID which have been added through RFC 3108.

Note: • There must be one c-line at the session level in which case there don’t need to be c-lines at the media description level. • If there is no c-line at the session level, there must be one c-line per media description level. • If there is a c-line at session level and in addition c-lines for (some) media descriptions, then a c-line at the media level overrides the c-line at session

level [RFC 2327 (p.12)]

[RFC 4566 (5.7)]




TThhee MMeeaanniinngg ooff SSDDPP




TThhee MMeeaanniinngg ooff SSDDPP • Session Description Items

⇒ The username is “Natalie” and as presented, there is a session-ID and a session-description-version number allocated by this user. Besides, the session description contains the FQDN or IP-address of the user.

⇒ The c-line specifically indicates on which IP-address Natalie is prepared to receive data.

• Time Description Items ⇒ The call shall start immediately <start time = 0> and shall last infinitely <stop time> = 0. Obviously, the call will be terminated by other means when

desired by either user.

• Media Description Items Two different media descriptors follow. Each is indicated by an m-item. ⇒ The first media description refers to the audio portion of the call. Natalie’s host computer intends to use RTP/UDP/IP as transport protocol and the

UDP-port number on the called party’s computer where audio data will be sent is ‘3120’dec. Note that port number ‘3121’dec is reserved for the related RTCP-signaling.

⇒ Dynamic Payload type indication for RTP is selected. The RTP-Payload Type shall be ‘100’. Through the attribute line “a = rtpmap: 100 AMR”, this dynamic payload type is assigned to the AMR-coder which has also been selected by Natalie on the user interface.

⇒ The b = AS: 12.2 tells the receiver that 12.2 kbit/s are required for the transfer of the AMR-data. The term ‘AS’ means that this bandwidth only relates to this media stream.

⇒ The second media description is related to the video portion of the call. As for the audio part, RTP/UDP/IP shall serve as transport protocol. The

destination UDP-port number where the video data shall be sent is ‘3122’dec. ⇒ The dynamic RTP-Payload Type 101 is used. This Payload Type is assigned to MPV (MPEG-Video) in the line “a = rtpmap: 101 MPV.




TTiimmee DDeessccrriippttiioonn IItteemmss • Overview

• The “t=”-Line (Time)




TTiimmee DDeessccrriippttiioonn IItteemmss Overview The figure illustrates a more detailed view on the different time specific SDP-items that appear in an SDP. In that respect, the figure illustrates which parts of the time specific SDP-items have to be included mandatorily or optionally. Mandatory parts of the time description have to be included in every SDP-description. At the bottom, the figure illustrates the structure of the start and stop times.

The “t=”-Line (Time) ⇒ The t-line indicates at which time a session starts (start time) and at which time it shall end (stop time). These times are indicated using time

indications in seconds as defined by the NTP (Network Time Protocol). ⇒ NTP-time stamps are 64 bit long and they are provided in seconds since January 1, 1900. ⇒ If the stop time equals ‘0’, then the session may last forever from the perspective of this SDP-description but it may only start as the start time

indicates. ⇒ If the start time also equals ‘0’, then the session is considered as permanent. ⇒ This case of both the start and the stop time being set to ‘0’ (t = 0 0) is actually the default case. It leaves the actual start and end of a session to

another protocol, most likely to SIP. ⇒ The offer- / answer-model mandates that the SDP-offerer and answerer have to use identical start and stop times in the offer and answer

[RFC 3264 (p.9)]. [RFC 2327 (p.15), RFC 4566 (5.9), RFC 958 ( for NTP), http://www.iana.org/assignments/sdp-parameters]




MMeeddiiaa DDeessccrriippttiioonn IItteemmss • Overview




MMeeddiiaa DDeessccrriippttiioonn IItteemmss Overview ⇒ The figure illustrates a more detailed view on the different media specific SDP-items that appear in an SDP. In that respect, the figure illustrates which

parts of the media specific SDP-items have to be included mandatorily, conditionally and optionally. ⇒ Note that each media stream requires exactly one media description of which each starts with an m-line. The sequential order of the following lines

within each media description is predefined and must be obeyed.

Presence of Attributes ⇒ A c-line may be present if there is already a c-line at the session level. In such a case, the c-line at the media description level overrides the c-line at

the session level. However, a c-line has to be present within each media description (and will be formatted as illustrated previously) if there is no c-line at session description level.

⇒ The b-line may be present to indicate how much bandwidth is required for that media stream. The indicated bandwidth shall include any bandwidth required for lower layer protocols such as RTP/UDP/IP-headers [RFC 3550 (6.2)]. In case of 3GPP-environments, the b-line shall be provided for audio and video media-types and may be provided for other media types [3GPP 24.229 (A.3.2.2)].

⇒ The presence of the mapping attributes is conditional and depends on whether or not dynamic RTP-payload mapping is done (for RTP-payload types 97 – 127). In such a case each dynamic payload-type from the payload-type-list needs to be mapped to a predefined codec type.

⇒ Other attributes (a=…) may need to be there under certain circumstances. Example: 3GPP mandates the use of preconditions and resource management as defined in RFC 3312, hence there will be multiple lines which state the current state of resource allocation ( a=des:qos mandatory local sendrecv).

⇒ 3GPP 24.229 (A.3.2.2) lists very clearly as to which attributes can and shall be used within a 3GPP-environment. [RFC 2327 (p.19), RFC 4566 (5.14), http://www.iana.org/assignments/sdp-parameters]




TThhee ““mm””--LLiinnee ((MMeeddiiaa AAnnnnoouunncceemmeenntt))




TThhee ““mm””--LLiinnee ((MMeeddiiaa AAnnnnoouunncceemmeenntt)) The m-line provides the receiver of the SDP-description with the most important information about a given media stream. Note that each m-line is the start of the SDP-description of a separate media stream.

Media Type (MIME) The media type obviously identifies the type of the media to be defined and used on this media stream. This relates to most of the MIME-media types and their subtypes which are listed at http://www.iana.org/assignments/media-types/.As of today the media types “application”, “audio”, “image”, “message”, “model”, “multipart”, “text”, “video”, “data” and “control” have been defined. Media types “data” and “control” are rather exotic and have never been fully specified [ RFC 4566 (8.2.1)]. They are listed only for completeness and because they are still included in RFC 3840 (Indicating UA-Capabilities in SIP). More details follow on the next pages.

Port-Number The “port number” indicates at which port number the sender of the SDP-description wants to receive this media stream. Note that “port number” does indicate nothing about the sender’s port number. If RTP is used, then “port number” shall be an even port number. Implicitly, the sender of the SDP-description defines through the RTP-port number also its receiver port number for the RTCP-messages related to this media stream: it is (port number + 1). If a port number = 0 is indicated then the related media stream is rejected (most likely to be seen in a response for an offer) [RFC 3264 (p.6)].

Transport “Transport” indicates the protocol stack to be used for exchanging the media as defined in the “media-type” parameter. The following pages provide more details about the listed transport protocols.

Payload-Type-List If transport is related to RTP, then the “payload-type-list” indicates in decimal notation the codec types which may be used on that media stream from the perspective of the sender of this SDP-description. The codec types are provided in a prioritized list, that is, the most preferred codec for receive (and transmit) [RFC 3264 (p.7)] from the perspective of the sender of this SDP-description is listed first. The sender of the SDP-description must be prepared from the moment of issuing that SDP-description to receiving any of the listed codec types on the indicated receiver port number. Most importantly, this includes unsolicited changes of the codec type (amongst those listed) in the middle of the session [RFC 3264 (p.6)]. The RTP-codec types 0 – 96 are predefined and assigned to specific codecs (e.g. PCM µ-law = ‘0’) but codec types 97 – 127 can be dynamically assigned to audio or video codec types. [RFC 4566 (5.14)]




““mm””--lliinnee MMeeddiiaa TTyyppee AAttttrriibbuuttee ((MMIIMMEE)) // ssoommee EExxaammpplleess • Media Type = application / Subtype = pdf




““mm””--lliinnee MMeeddiiaa TTyyppee AAttttrriibbuuttee ((MMIIMMEE)) // ssoommee EExxaammpplleess Media Type = application / Subtype = pdf ⇒ The figure illustrates a few subtype examples for the media type = application. Many of these application subtypes represent content which can be

embedded into SIP-messages but obviously, we can also use them for the media type parameter within the m-line. ⇒ In the example you can see an SDP-description fragment which identifies PDF as application and the attribute line underneath identifies the very

filename that the UA on the left side likes to receive over a TCP-connection.

Note that the encoding and syntax of the different subtypes is not arbitrary. In other words: In the SDP we must for instance list “H263” rather than “H.263”.

⇒ File transfer may also be done through MSRP-containers during an IM-session (see next pages). [http://www.iana.org/assignments/media-types/]




MMeeddiiaa TTyyppee == mmeessssaaggee // SSuubbttyyppee == CCPPIIMM




MMeeddiiaa TTyyppee == mmeessssaaggee // SSuubbttyyppee == CCPPIIMM ⇒ The graphics illustrates the setup of an instant messaging session between two peers. Setup of a chatroom is different and described in draft-niemi-

simple-chat-03.txt. ⇒ Most important for our considerations is the new media type “message” and the use of the transport protocol “TCP/TLS/MSRP” which means, that

MSRP (Message Session Relay Protocol) shall be used on top of a TLS/TCP-protocol stack. ⇒ As can be seen from the following attribute line, the “acceptable MIME-types” ( accept-types) is set to “message/CPIM” which translates into the

specific message format which has been defined in RFC 3860 / RFC 3862 for CPIM (Common Presence and Instant Messaging). ⇒ The IM-session itself occurs independent from SIP and SDP. [http://www.iana.org/assignments/media-types/, draft-ietf-simple-message-sessions-14.txt]




((11)) ““mm””--lliinnee // DDeettaaiillss ooff tthhee TTrraannssppoorrtt PPrroottooccooll TTyyppeess




((11)) ““mm””--lliinnee // DDeettaaiillss ooff tthhee TTrraannssppoorrtt PPrroottooccooll TTyyppeess RTP/AVP The related protocol stack is most frequently used as it is well suited for real-time user applications like voice calls or video conferencing. Note that the protocol stack always contains two parts: one for RTP and the voice or video codec on top and another one for RTCP. RTP/AVP is also applicable in case of unidirectional VoD or AoD-sessions in which case a media stream only flows in one direction. The structure of the m-line is also indicated. The payload-type-list does contain one or more integer codec identifiers which are used within the payload type field of the related RTP-frames [RFC 3551]

RTP/AVPF The same applies which has been said about RTP/AVP. The only difference between RTP/AVP and RTP/AVPF is the use of advanced “Feedback” reports on RTCP-level. These advanced feedback reports provide information about lost RTP-frames and their numbers or encoder specific feedback information about lost graphics frames (which is important for high quality video conferencing and VoD). [draft-ietf-avt-rtcp-feedback-11.txt]

RTP/SAVP The related protocol stack indicates the additional value of RTP/SAVP over RTP/AVP: It uses SRTP and SRTCP to provide privacy in the user plane. In that respect, privacy relates to RTP- / RTCP-data frame integrity protection, replay protection and encryption. The provision of the related keying material is out of the scope of RTP/SAVP and SRTP. [RFC 3711]




((22)) ““mm””--lliinnee // DDeettaaiillss ooff tthhee TTrraannssppoorrtt PPrroottooccooll TTyyppeess TBCP (Talk Burst Control Protocol) The TBCP is a PoC-specific protocol for floor control purposes which stems from OMA. Floor control means that through TBCP a PoC-client reserves the right to speak during a session and likewise that the related PoC-server informs the other session participants that the floor is currently in use. TBCP operates on top of UDP but its setup needs to be included in the SDP-description as indicated in the m-line. The sender of the illustrated m-line tells the PoC-server that it is ready to receive TBCP-messages on port No 10000.

TCP (Transmission Control Protocol) There are applications that require a connection-oriented and reliable transport protocol like TCP. Usually, we will find those applications under the MIME-media type “applications” as also illustrated in the example m-line. In this example, the sender of the m-line suggests a T.120 session (application sharing). The sender of this m-line is prepared to receive T.120-information on the predefined T.120-port number 1503. Note that additional attribute lines (not shown) are necessary to further specify which T.120 functions are suggested. [draft-ott-mmusic-sdp-t120-00.txt]

TCP/BFCP (TCP / Binary Floor Control Protocol) BFCP serves a quite similar purpose as the aforementioned TBCP. It provides for floor control during conference sessions (we will illustrate an example a few pages later). However, the way the different standardization groups use SDP and the m-line to communicate the setup of floor control is slightly different. Although both use the MIME media type “application”, BFCP uses a new transport protocol type definition TCP/BFCP and an asterisk (‘*’) as payload type. Please compare this to TBCP. [draft-ietf-mmusic-sdp-bfcp-03.txt, draft-ietf-xcon-bfcp-05.txt]

???? Question Section 24 ???? ⇒ With respect to the transport protocol type “TCP/BFCP”: What would have been an alternative way to register BFCP?




((33)) ““mm””--lliinnee // DDeettaaiillss ooff tthhee TTrraannssppoorrtt PPrroottooccooll TTyyppeess TCP/MSRP (Message Session Relay Protocol) If an instant messaging session shall be setup, if files shall be transferred and in many other cases the transport protocol type can be set to TCP/MSRP. As illustrated, the MSRP sits on top of TCP and piggybacks the MIME-encoded information between the peers. The related m-line clearly states the TCP-port number on which the sender of this SDP-description is prepared to receive MSRP-frames. MSRP is well suited to transfer huge amounts of data between peers. Every MIME-type is supported and hence, MSRP-messages can take on segmented files of any type. In its simplest form, the MSRP-messages carry short plain text instant messages back and forth. [draft-ietf-simple-message-sessions-14]

TCP/RTP/AVPF There may be applications or the need to convey RTP-frames over a connection-oriented and reliable transport protocol. If this is desired, the transport protocol type TCP/RTP/AVP is selected. There will be additional attribute lines to define who of the peers has to setup the related TCP-connection but basically, this option is similar to the standard RTP/AVPF-transport protocol type [draft-ietf-avt-rtp-framing-contrans-06.txt, RFC 4145]

TCP/TLS/BFCP (Transport Layer Security / Binary Floor Control Protocol) In this case, conference floor control applies as in case of TCP/BFCP (please read there) but TLS is positioned in between these two protocols to provide for privacy and confidentiality. [draft-ietf-mmusic-sdp-bfcp-03.txt, draft-ietf-xcon-bfcp-05.txt]




((44)) ““mm””--lliinnee // DDeettaaiillss ooff tthhee TTrraannssppoorrtt PPrroottooccooll TTyyppeess TCP/TLS/MSRP (Transport Layer Security / Message Session Relay Protocol) This transport protocol type is used together with the media-type “message” to setting up instant messaging sessions just like the aforementioned TCP/MSRP does. However, TLS shall be used in addition to provide for confidentiality and privacy. [draft-ietf-simple-message-sessions-14]

UDP (User Datagram Protocol) The transport-protocol-type UDP provides the possibility to specify a media bearer for various different types of data transfers between peers. The new SDP-standard RFC 4566 (p.24) mandates that if UDP is used as transport-protocol type in the m-line that in this case the media type shall be one of the MIME-media types and that the “payload-type-list”-parameter shall in this case list the very subtype under this MIME-media type. Our example illustrates an SDP-description that tells the peer that this party that sends the SDP-description is ready to receive *.JPG-encoded images on UDP-port number 10000. [RFC 4566]

UDPTL (UDP Transport Layer) The transport protocol type “UDPTL” is nothing else but UDP but it goes together with the T.38-protocol for G3-fax transmission over IP-networks. That is, the special transport-protocol-type UDPTL specifies a media stream [ITU-T T.38, RFC 3362]




UUssee CCaassee EExxaammppllee:: FFlloooorr CCoonnttrrooll ((BBFFCCPP)) dduurriinngg PPuusshh--ttoo--TTaallkk • Configuration of the Participants and the Floor Control Server




UUssee CCaassee EExxaammppllee:: FFlloooorr CCoonnttrrooll dduurriinngg PPuusshh--ttoo--TTaallkk ((BBFFCCPP)) Configuration of the Participants and the Floor Control Server ⇒ The figure illustrates the configuration of an audio or multimedia conference session in the context of the IMS. In case of the IMS, the MRFC and

MRFP may be responsible for Push-to-Talk sessions. ⇒ Conference setup occurs through regular SIP-messages and likewise, audio streams are conveyed through RTP-frames. ⇒ The BFCP is used among the peers for floor control.




BBFFCCPP--OOppeerraattiioonn dduurriinngg aa CCoonnffeerreennccee SSeessssiioonn




BBFFCCPP--OOppeerraattiioonn dduurriinngg aa CCoonnffeerreennccee SSeessssiioonn ⇒ A more detailed view on BFCP-operation during a conference session is presented in this figure. The conference is setup among the different parties

through SIP-signaling. In that respect, the MRFC acts as UA and invites the other parties to the conference after receiving an invitation from either party.

⇒ When the session is setup and when floor control shall be applied, the party that likes to speak ( party A) will indicate this somehow (e.g. click on “speak” button on a softphone conference application).

⇒ This triggers the transfer of a BFCP: FloorRequest-message towards the MRFC. The MRFC may or may not grant the right to speak; in our case it does ( BFCP: FloorStatus) and likewise informs the other parties that the link is occupied to avoid any further floor reservation attempts.

⇒ Consequentially, there will be audio and/or video data flowing from party A to the MRFP which will distribute that data to the other peers. ⇒ In our example, party A eventually stops talking and uses BFCP: FloorRelease to indicate that party A no longer needs the floor. However, this

revocation of the right to speak may also origin from the MRFC. ⇒ The following message sequence illustrates the same procedure but in this case it is party B that speaks.




TThhee ““bb””--LLiinnee ((BBaannddwwiiddtthh IInnffoorrmmaattiioonn))




TThhee ““bb””--LLiinnee ((BBaannddwwiiddtthh IInnffoorrmmaattiioonn)) The provision of the b-line is optional. The b-line may be present in the session description part and/or in the media description part. If it is present in both parts then the ones in the media description part only apply to that media stream.

CT (Conference Total) This modifier is typically used within the session part of an SDP-description. CT provides a rough estimate of the bandwidth which is required for the entire session. The use of the CT-modifier is little helpful for resource reservation and QoS-related issues. [RFC 2327 (p.14), RFC 4566 (5.8)]

AS (Application Specific) This modifier is typically used within the media description part of an SDP-description. AS provides information how much bandwidth is required for that media stream. In case of RTP-based data transfers (as defined through the transport protocol type) the related AS-bandwidth value takes into account the entire overhead caused by lower layer protocols down towards IP (but it does not consider any layer 1 or layer 2 overheads nor does it consider any compression algorithms [RFC 3550 (6.2 / p.24)]. The necessary RTCP-bandwidth for sending and receiving RTCP-reports is also not included in the AS-bandwidth value and is estimated to be an additional 5% of the AS-bandwidth value. Since 5% may be wrong, the RR- and RS-modifiers were defined. The related AS-bandwidth value may be used by resource reservation protocols like RSVP in general and SM (Session Management) in case of 3GPP to understand how much bandwidth a media stream requires but the aforementioned constraints need to be taken into account. This is illustrated in the example. Note that the bit rate of 28.8 kbit/s is rounded upwards to the next integer value of 29 kbit/s. [RFC 2327 (p.14), RFC 3550 (6.2), RFC 4566 (5.8), 3GTS 26.236 (Annex B), 3GTS 29.208 (7.2.2)]

TIAS (Transport Independent Application Specific) This modifier provides the same information as the AS-modifier but without consideration of any lower layer protocols. Therefore, the indicated value covers exclusively the bandwidth which is needed by a particular codec type. Neither RTP-headers nor bandwidth for RTCP-messages are considered. A bandwidth modifier TIAS is accompanied by an attribute maxprate (maximum packet rate) which provides the maximum number of packet per seconds for that media stream [RFC3890].

RR (Rtcp bandwidth for data Receiver) and RS (Rtcp bandwidth for data Sender) Both are dealt with on the following pages [RFC3556].




DDeettaaiillss ooff tthhee BBaannddwwiiddtthh MMooddiiffiieerrss ““RRRR”” aanndd RRSS””




DDeettaaiillss ooff tthhee BBaannddwwiiddtthh MMooddiiffiieerrss ““RRRR”” aanndd RRSS”” ⇒ For each unidirectional RTP-session, the RTP-sender also generates SR’s (Sender Reports) and the RTP-receiver generates RR’s (Receiver

Reports).

Note that if the session is bidirectional, then each peer generates only Sender Reports [RFC 3551]

⇒ In case of multicast or conference sessions, a media stream sender will encounter situations in which the multiple media stream receivers each convey their own RTCP-receiver reports. Consequentially, there is an increased demand for RTCP-receiver bandwidth compared to the required RTCP-transmit bandwidth.

⇒ This is a well-known and well-addressed issue which is already covered by the standard bandwidth modifier “AS”. Possible resource allocation mechanisms just add 5% to the AS-bandwidth for considering RTCP. Note that in this case, 1.25% are for RTCP-sender reports and 3.75% are for RTCP-receiver reports. We illustrate this possibility as option 1.

⇒ However, this situation may not work well in all cases. There may for instance be very low bandwidth codecs on top in which case more bandwidth percentage than 5% is needed for RTCP or the opposite may be the case.

⇒ This illustrates the requirements behind introducing the new bandwidth modifiers “RR” (Rtcp bandwidth for data Receiver) and “RS” (Rtcp bandwidth for data Sender).

⇒ They allow for an explicit communication of the required RTCP-bandwidth values in each direction (note that the RS-bandwidth in such a case is actually added to the AS-bandwidth as it pertains to the same direction).

⇒ In our graphics, option 2 illustrates the use of the RR- and RS-modifiers as amendments for the AS- or TIAS-modifiers. The AS-bandwidth is still 29 kbit/s but since specific RR- and RS-modifiers have been included, the 5%-rule no longer applies but the provided values of 500 bit/s and 2000 bit/s are applied.

Note that the AS- and the CT-modifiers use kbit/s as unit while TIAS, RR and RS use bit/s.

[RFC 3556]

???? Question Section 25 ???? ⇒ Taking these constraints about using RR and RS into consideration: How will a UA most likely indicate not to use RTCP at all in either or in both

directions?




““aa””--LLiinneess ((AAttttrriibbuutteess)) • Example 1: Attribute “recvonly / sendonly”




““aa””--LLiinneess ((AAttttrriibbuutteess)) ⇒ The SDP-attributes are defined in RFC 4566 (6) and many (but unfortunately not all of them…) are listed at the website

http://www.iana.org/assignments/sdp-parameters. ⇒ There are attributes which are only applicable at session level while others are applicable at the media description level. Yet others can be present in

both parts. ⇒ It is impossible to provide an overview of all defined attributes; hence we only illustrate some meaningful examples with entirely different focus to

illustrate the importance of attribute lines within an SDP-description. Example 1: Attribute “recvonly / sendonly” By default, a media stream is “sendrecv” which means bidirectional. Alternatively, it can be offered as “recvonly” or “sendonly”, always from the perspective of the peer that sends this SDP-description. That is, when the other party accepts the unidirectional character as suggested it will indicate the opposite: if “a = recvonly” was sent, then “a = sendonly” shall be replied and vice versa [RFC 4566 (p. 27).

In 3GPP-environments, the tagging of a media stream as “recvonly” or “sendonly” automatically allocates a QoS-class “Streaming” to that media stream. Vice versa, if no directivity or “sendrecv” is indicated, then “Conversational” QoS-class is allocated [3GTS 29.208 (7.2), 3GTS 26.236 (Annex B)]

[RFC 4566 (6)]

???? Question Section 26 ???? ⇒ Please look at the image: Why does the peer that acts as “sendonly” still provide a receiver port number of 4444 to the other side?




EExxaammppllee 22:: AAMMRR--CCooddeecc DDeeffiinniittiioonn aanndd PPaarraammeetteerriizzaattiioonn




EExxaammppllee 22:: AAMMRR--CCooddeecc DDeeffiinniittiioonn aanndd PPaarraammeetteerriizzaattiioonn ⇒ The example illustrates how the rtpmap-attribute is used to map the dynamic payload number ‘99’ to the MIME-registered codec type AMR. Of course,

the rtpmap-parameter is not only limited to the AMR-codec. ⇒ RFC 3267 (p.44) mandates the clock rate for AMR to be ‘8000’ and we use it on one channel ( AMR/8000/1) which is the default and could have

been omitted. ⇒ In the next line, the fmtp-attribute defines all other AMR-specific attributes. In particular it limits the AMR-modes to 0, 2, 5 and 7. The table which AMR

user data rates are reflected by which “mode-set” setting. ⇒ The following parameter “mode-change-neighbor” indicates whether AMR-mode changes during the upcoming conversation are only allowed between

adjacent modes (e.g. from 3 only to 2 or to 4) in which case “mode-change-neighbor = 1” or whether any mode change is allowed (e.g. from 5 to 1 or to 7) “mode-change-neighbor = 0”.

⇒ The final parameter “mode-change-period” indicates the minimum number of AMR-frames during which no mode change is allowed. [RFC 4566 (6), RFC 3267, 3GTS 26.101, 3GTS 26.235]




EExxaammppllee 33:: TTCCPP--CCoonnnneeccttiioonn DDeeffiinniittiioonn




EExxaammppllee 33:: TTCCPP--CCoonnnneeccttiioonn DDeeffiinniittiioonn ⇒ This example illustrates yet another type of parameter. It is used if TCP-based transport protocols are used between the two peers to determine

whether an already existing TCP-connection shall be used or whether a new TCP-connection shall be established (“connection”-attribute). ⇒ If a TCP-connection has to be setup, one also has to define who shall initiate the connection establishment. In the example, the offerer suggests to

take the active part in the setup phase which means that the offerer will send a TCP-SYN-frame towards the peer to establish the TCP-connection. [RFC 4145]




TThhee OOffffeerr // AAnnsswweerr MMooddeell




TThhee OOffffeerr // AAnnsswweerr MMooddeell In conjunction with SIP, SDP applies what is known as offer/answer model: ⇒ One peer provides an SDP-offer to the other peer. Note that this offer can be embedded in either a SIP-Request or a SIP-Response. That is, the SIP-

message may act as a plain bearer for the embedded SDP-content. This offer message will contain the description of one or more media streams (audio, video…). This peer is now awaiting response from the other party.

⇒ The receiver of the SDP-offer will process this offer and will embed his/her response into another SIP-message which typically belongs to the same transaction but this is not required. Note that this SDP-answer needs to include exactly the same number of media stream descriptions that was included in the offer.

[RFC 3264]




SSeessssiioonn IIddeennttiiffiiccaattiioonn PPaarraammeetteerrss aatt bbootthh PPeeeerrss




SSeessssiioonn IIddeennttiiffiiccaattiioonn PPaarraammeetteerrss aatt bbootthh PPeeeerrss ⇒ The figure illustrates which parameters are used at each peer (UA) to identify a session uniquely. Note that session-ID’s are in general different at

both peers. ⇒ Intentionally, the connection IP-address of UA 1 is illustrated as being part of the session description items while the connection IP-address of UA 2 is

illustrated as being part of the media description items. Both options are legitimate. ⇒ The codec type should be the same in both directions.




QQuueessttiioonn 22:: WWhhaatt hhaappppeennss iiff PPrroovviissiioonnaall RReessppoonnsseess ggeett lloosstt?? • Provisional Response Messages are those with Status Code 100 – 199

They need to be distinguished from the final response messages with status code 200 – 699.

Note: Provisional responses may get lost because they are not directly confirmed and because they only are retransmitted under certain circumstances.




QQuueessttiioonn 22:: WWhhaatt hhaappppeennss iiff PPrroovviissiioonnaall RReessppoonnsseess ggeett lloosstt?? Provisional Response Messages are those with Status Code 100 – 199 ⇒ As the figure illustrates, provisional response messages may contain SDP-content. Since provisional responses are transmitted unreliably they may

get lost (unlike final response or request messages). ⇒ That means that the aforementioned SDP-content may also get lost.

Additional Information

⇒ The term “unreliably” in the previous sentence deserves some more explanation: ⇒ When the originator of a session transmits the Request: INVITE-message it waits for the first provisional response message to move into the next

state in its internal state machine. Until this first provisional response message is received, the originator shall retransmit the INVITE-message [RFC 3261 (17.2.1)] (timer A controlled, as described two chapters before).

⇒ The receiver of a retransmitted INVITE-message shall in this case retransmit only the latest provisional response message [RFC 3261 (17.2.1)]. All the previously transmitted provisional response messages are lost.

⇒ But let us assume that the originator did move into the next state after a provisional response message was received. One characteristics of this new state is the fact that there are no more retransmissions of the INVITE–message (or anything else) and that the peer may send several other provisional responses without any chance of getting their reception confirmed.

⇒ Note that according to RFC 3261 (8.2.6.1) there should be no provisional responses for „None“-INVITE request messages. However, in practice one can frequently recognize exactly this behavior.




SSoolluuttiioonn:: PPrroovviiddee ffoorr tthhee OOppttiioonn ttoo aacckknnoowwlleeddggee pprroovviissiioonnaall RReessppoonnsseess • Indicating Support or Requirement of acknowledged provisional Responses

INVITE SIP:[email protected]

SIP/2.0 Via: ... . . CSeq: 999 INVITE Require:..., 100rel, ... Sec-agree: ... Supported: ... . SIP/2.0 183 Session Progress

Via: ... Require: ..., 100rel, ... . CSeq: 999 INVITE RSeq: 3498 . .

Acknowledgement of provisional responses is required. If the feature is not mandated but only supported by the requester then the “Supported:”-header field would be used instead. Note that this feature only relates to provisional responses with response code ‘101’ – ‘199’ which explicitly excludes ‘100’-Trying.

Responder confirms and applies acknowledged provisional responses.

Response: The UAS shall in its provisional responses require that the provisional responses be acknowledged.




SSoolluuttiioonn:: PPrroovviiddee ffoorr tthhee OOppttiioonn ttoo aacckknnoowwlleeddggee pprroovviissiioonnaall RReessppoonnsseess

Indicating Support or Requirement of acknowledged provisional Responses ⇒ As the figure illustrates it is always the UAC ( the party that sends the Request: INVITE-message) that can indicate support for or even require

acknowledged provisional responses. ⇒ Support for this feature is indicated by the UAC adding an option tag ‘100rel’ to the list of supported features in the “Supported:”-header field. Most

importantly, in this case, support for acknowledged provisional is not mandated ( “should”-feature). ⇒ If support for this feature is required by the UAC, then the UAC will add the option tag ‘100rel’ not to the “Supported:”-header field but to the

“Require:”-header field. In this case, the UAS has to send provisional responses reliably (or drop the transaction).

Note that the UAS may only send provisional responses reliably if this feature has previously been indicated as supported or required by the UAC. In other words: The UAS may not initiate the reliable transfer of provisional responses (see also next pages).

⇒ If the UAS supports reliable provisional responses, then all provisional responses which are different from Response: 100-Trying will include a header field “RSeq:” which content will be described in detail on the following slide. In addition, all these provisional responses shall in include a “Require:”-header field that mandates the acknowledgement of provisional responses.

Note: • RFC 3262 explicitly limits the use of acknowledged provisional responses to the INVITE-transaction. • Only provisional responses with response code ‘101 – ‘199’ shall be sent reliably. This avoids the acknowledgement of Response: 100-Trying

messages that are only sent to avoid INVITE-retransmissions and which are sent by each hop and by each proxy. • Reliable transmission of provisional responses consequentially means that retransmissions of these provisional responses may occur.

[RFC 3262]




IInnddiiccaattiinngg LLaacckkiinngg SSuuppppoorrtt ffoorr aa RReeqquuiirreedd FFeeaattuurree




IInnddiiccaattiinngg LLaacckkiinngg SSuuppppoorrtt ffoorr aa RReeqquuiirreedd FFeeaattuurree If a UAC requires support for certain features by including its option tag into the “Require:”-header field but the receiving UAS is unable to support this feature then the UAS shall reply a Response: 420-Bad Extension with an “Unsupported:”-header field inside that lists the unsupported features. [RFC 3261 (8.1.1.9)]

Note that the UAS cannot require support of certain features through the “Require:”-header field. The required or supported features shall be listed by the UAC at the beginning of a transaction.




UUssiinngg PPRRAACCKK ttoo aacckknnoowwlleeddggee PPrroovviissiioonnaall RReessppoonnsseess




UUssiinngg PPRRAACCKK ttoo aacckknnoowwlleeddggee PPrroovviissiioonnaall RReessppoonnsseess • The figure illustrates the operation of acknowledged provisional responses

⇒ Whenever an INVITE-transaction has been initiated and provisional responses shall be sent reliably, then the first provisional response with a status code different from 100-Trying shall include the new header field “RSeq:”.

⇒ This header field “RSeq:” contains a 32 bit long arbitrary integer number (similar to the CSeq-number / read [RFC 3261 (7.1)]). In our example, the RSeq-number = Integer2.

⇒ As the figure illustrates, the sender of the provisional response message expects to receive a PRovisional ACKnowledement (PRACK) within 500 ms ( T1) to acknowledge the reception of the provisional response message. This new message is a SIP-request by itself that requires its own CSeq-number ( Integer1 + 1) which is obviously related to the sequence number of the INVITE as it belongs to the same dialog.

⇒ The PRACK contains a new defined header field “RAck:” which contains the concatenation of the “RSeq:”-number and the “CSeq:”-header field that this PRACK relates to.

⇒ Since PRACK constitutes its own transaction, it also requires a final response message from the peer. This response message will always be a Response: 200-OK. Please note in the figure that “CSeq: (Integer1+1) PRACK” binds the Request: PRACK and the Response: 200-OK together in the context of a dialog ( which means that the two messages are also related through all already introduced dialog identifiers.

[RFC 3262]

???? Question Section 27 ???? ⇒ Repetition: Which parameters do identify messages that belong to one dialog? ⇒ How can UAC and UAS distinguish subsequent reliable provisional response messages and their PRACK’s within an INVITE-transaction? ⇒ Can PRACK only be sent through the SIP-proxies or end-to-end directly (without proxies)? ⇒ Which timers are used to control the transaction timeout and retransmission scheduling of Request: PRACK?




TTrraannssaaccttiioonn AAbboorrtt iinn CCaassee ooff LLaacckkiinngg PPRRAACCKK




TTrraannssaaccttiioonn AAbboorrtt iinn CCaassee ooff LLaacckkiinngg PPRRAACCKK • Opposed to the previous slide, the present slide illustrates the error case and its consequences

⇒ The called party / the UAS that sends provisional responses reliably, expects to receive the acknowledging Request: PRACK-message within T1 = 500 ms.

⇒ As the figure illustrates, the UAS will retransmit the same provisional response upon expiry of T1 and double the retransmission wait time to 2 x T1. This procedure repeats a number of times until the retransmission timeout of 64 x T1 = 32 s kicks in and the UAS aborts the session.

⇒ That is, after seven unsuccessful unacknowledged transmissions of a provisional response message, the UAS will transmit a final Response: 5XX-message (e.g. 504-Server Timeout).

[RFC 3262 (3)]




SSuummmmaarryy • As an option, the UAC within an INVITE-transaction may require that all

provisional responses with a status code different from “100-Trying” are acknowledged RFC 3262 (3) explicitly restricts acknowledged provisional responses to the INVITE-method.

• The originator of a SIP-transaction indicates this requirement by including the parameter “100rel” in the “Require:” header field Alternatively, the originator of a SIP-session may only suggest the use of acknowledgments by including the “100rel”-parameter in the “Supported:” header field.

• Consequently, all provisional responses except ‘100’ are sent reliably by the UAS and require an acknowledgement through the new PRACK-method type

• To be able to relate a provisional response to its acknowledgement, the new header fields RSeq and RAck are introduced. RSeq is an arbitrary number within the provisional response message that links to RAck which is part of the PRACK-acknowledgment.




SSuummmmaarryy Additional Information

⇒ If neither peers indicates support or requirement for acknowledged provisional response, then provisional responses must not be sent reliably. ⇒ Only the peer who sends the SIP-Request message can indicate or require support for reliable provisional response ( “100rel”). ⇒ The “100-Trying”-response message is generated hop-by-hop rather than end-to-end and is therefore inherently reliable. Hop-by-hop means that each

stateful proxy server on the way between the two peers will autonomously generate a “100-Trying”-response message for a received INVITE-request message to avoid that the previous node retransmits the Request: INVITE-message when timer A expires.

[RFC 3262]




QQuueessttiioonn 33:: HHooww ttoo aassssuurree aapppprroopprriiaattee RReessoouurrccee AAllllooccaattiioonn iinn bbootthh WWaayyss bbeeffoorree aalleerrttiinngg tthhee CCaalllleedd PPaarrttyy?? • In the final scenario

in the first chapter no such provision was done… So called “Ghost Rings” are the consequence of not making sure that there are enough resources available. Another issue may be that one peer suggests codecs that the other peer does not support.




QQuueessttiioonn 33:: HHooww ttoo aassssuurree aapppprroopprriiaattee RReessoouurrccee AAllllooccaattiioonn iinn bbootthh WWaayyss bbeeffoorree aalleerrttiinngg tthhee CCaalllleedd PPaarrttyy?? • In the previous scenario no such provision was done!

It is therefore incidental whether the two users have full duplex media streams with media types that both peers support once they accept the call. In the figure we can identify three potential hazards: 1. There are no sufficient network resources available end-to-end to support the media stream(s) in the direction from the called party (B) to the calling

party (A). 2. There are no sufficient network resources available end-to-end to support the media stream(s) in the direction from the calling party (A) to the called

party (B). 3. The SDP-parameters that (B) conveys to (A) are unacceptable to (A), for instance because (A) does not support any of the suggested codec types.

Consequences of this Lack of Sophistication ⇒ If resources are lacking in either or in both directions, the users will experience very poor quality or even a dead link ( Ghost Ring)

Call Drop (No common Codec)

If the codec type(s) which is/are suggested by (B) for the direction (A) ⇒ (B) is/are not supported by (A) ( error No 3), then (A) will still send the ACK-Request to (B) but it will immediately afterwards send a BYE-Request to (B) to terminate the session [RFC 3261 (13.2.2.4)].

[RFC 3312, RFC 4032]




AAnnsswweerr:: WWee ddeeffiinnee aann aaddddiittiioonnaall HHaannddsshhaakkiinngg PPrroocceedduurree

• This handshaking procedure uses preconditions which describe to the peer which QoS needs to be fulfilled to justify session establishment

• Basically, this new procedure describes how to combine the new SIP-method UPDATE with new SDP-attributes The new SIP-method is the UPDATE-method and the new SDP-attributes allow both peers to measure the progress of the resource allocation and media codec selection in both directions.

• Note that it must still be possible to alert the called party before the media types of a session are selected This is necessary because it may be desirable to allow the human user to contribute to the selection of the media types or codecs.




AAnnsswweerr:: WWee ddeeffiinnee aann aaddddiittiioonnaall HHaannddsshhaakkiinngg PPrroocceedduurree Additional Information

⇒ Please do not expect too much from this handshaking procedure. There will be no means to convey a parameterized QoS-requirement between peers.

⇒ It will be possible to request “QoS” from the peer without defining what that means. This decision is in the courtesy of the peer.




OOvveerrvviieeww:: RReessoouurrccee MMaannaaggeemmeenntt uussiinngg SSIIPP aanndd SSDDPP • Positive Outcome – Resource Reservation successful




OOvveerrvviieeww:: RReessoouurrccee MMaannaaggeemmeenntt uussiinngg SSIIPP aanndd SSDDPP Positive Outcome – Resource Reservation successful ⇒ The Request: INVITE-message will contain in its message body a regular SDP-offer which also defines preconditions for QoS to be met, prior to

alerting the called party’s user. ⇒ As a consequence, the called party shall invoke network specific resource allocation procedures.

Example: In case of 3GPP-networks, the “network specific resource allocation procedure” relates to the activation of a secondary PDP-context.

⇒ In our scenario, the resource allocation has already succeeded when the called party sends a provisional response ( Response: 183-Session Progress) to the calling party.

⇒ Note that this message will not only contain the SDP-answer to the previously received SDP-offer, it will furthermore contain a progress report about the achieved resource allocation at the called party.

⇒ As illustrated, in our example the Response: 183 – Session Progress contains preconditions from the perspective of the called party which have to be met on the side of the calling party. Accordingly, network specific resource allocation procedures are invoked here.

⇒ Upon completion of these activities, the calling party uses a specifically defined method-type ( UPDATE / RFC 3311) as a bearer to inform the called party that resource allocation also succeeded on the side of the calling party.

⇒ Like most other SIP-Requests, the Request: UPDATE-message requires a final response message. ⇒ And finally, with all preconditions met, the called party alerts the user and sends a Response: 180-Ringing to the calling party. [RFC 3312]

???? Question Section 28 ???? ⇒ Why is the resource allocation of the inviting party only done after the provisional response is received and not already before the invitation is sent?




NNeeggaattiivvee OOuuttccoommee –– PPrreeccoonnddiittiioonnss ccaannnnoott bbee mmeett • Option 1: Related SDP was contained in a SIP-Request (INVITE / UPDATE)




NNeeggaattiivvee OOuuttccoommee –– PPrreeccoonnddiittiioonnss ccaannnnoott bbee mmeett Obviously, it may happen that preconditions cannot be met in which case a session establishment is unsuccessful. This slide and the following slides describe the related procedures.

Option 1: Related SDP was contained in a SIP-Request (INVITE / UPDATE) ⇒ If the precondition that cannot be met was included in a SIP-Request message ( INVITE or UPDATE), then the peer who encounters the problem

will use the specifically defined response code 580-“Precondition Failure” to inform its peer about the negative outcome.

Note that RFC 3312 doesn’t define this but if the Response: 580-Precondition Failure message is the final response to a Request: UPDATE-message, then the original Request: INVITE-message will most likely also be responded to with failure response message (e.g. 488-Not Acceptable Here) to finish the transaction. In our scenario, the precondition that cannot be met was received in the Request: INVITE and therefore the aforementioned problem does not exist.

⇒ Please note that the message Response: 580-“Precondition Failure” will contain an SDP-body, containing the same number of m-lines (media) as the related offer did.

⇒ This SDP-body shall also indicate which precondition caused the failure. In our scenario, the called party B was apparently unable to reserve resources in send direction ( from the perspective of the called party).

⇒ After the Request: ACK has been transmitted as response for the final Response: 580-Precondition Failure, Party A may obviously retry the session establishment. Depending on the implementation, this retry may require a previous prompting of the human user ( “Call unsuccessful: Retry (Y/N)”) or it may occur for a certain number of times automatically before the user is prompted.

⇒ The Retry may also be done without the precondition that caused the error. [RFC 3312 (8)]

???? Question Section 29 ???? ⇒ If party A sends another INVITE after the 580-Precondtion Failure was received: Will there be any relationship of the identifiers Call-ID, CSeq, branch,

“To:”-tag and “From:”-tag between the two INVITE-messages?




((11)) OOppttiioonn 22:: RReellaatteedd SSDDPP wwaass ccoonnttaaiinneedd iinn aa SSIIPP--RReessppoonnssee




((11)) OOppttiioonn 22:: RReellaatteedd SSDDPP wwaass ccoonnttaaiinneedd iinn aa SSIIPP--RReessppoonnssee ⇒ If the calling party A receives an offer with preconditions in a final or provisional response message and this offer cannot be met, then party A shall

use a Request: UPDATE-method to inform party B that the failure occurred / that the precondition cannot be met. ⇒ As illustrated in the figure, the SDP-body within the Request: UPDATE-message shall also indicate which precondition caused the failure. In our

scenario, calling party A was apparently unable to reserve resources in both directions. ⇒ Most importantly, the calling party shall immediately cancel the pending INVITE-transaction by sending a Request: CANCEL-message to the peer.

Party A must not use Request: BYE which is reserved to finish established dialogs ( after a Response: 200-OK has been received). [RFC 3312 (8)]




((22)) OOppttiioonn 22:: RReellaatteedd SSDDPP wwaass ccoonnttaaiinneedd iinn aa SSIIPP--RReessppoonnssee




((22)) OOppttiioonn 22:: RReellaatteedd SSDDPP wwaass ccoonnttaaiinneedd iinn aa SSIIPP--RReessppoonnssee ⇒ After the Request: CANCEL-message has been received by party B, party B will issue two different Response: 200-OK messages which finish the

UPDATE- and the CANCEL-transaction. ⇒ Party B shall also issue a final Response: 487-Request Terminated message which finishes the original INVITE-transaction. ⇒ And obviously, this failure final response message requires the transmission of a Request: ACK-message by party A. ⇒ After the Request: ACK has been transmitted, Party A may obviously retry the session establishment. Depending on the implementation, this retry

may require a previous prompting of the human user ( “Call unsuccessful: Retry (Y/N)”) or it may occur for a certain number of times automatically before the user is prompted.

⇒ The Retry may also be done without the precondition that caused the error. [RFC 3312 (8)]




OOnnee MMeeddiiaa SSttrreeaamm iiss rreejjeecctteedd aallttooggeetthheerr




OOnnee MMeeddiiaa SSttrreeaamm iiss rreejjeecctteedd aallttooggeetthheerr ⇒ Rejection of a media stream is always indicated by setting its port number to ‘0’ in the related SDP-answer. In the illustrated example, the called party

B accepts the suggested audio media stream by indicating its own receiver port number ‘6542’ which implicitly confirms that it will send audio data to party A’s receiver port number for audio ‘3466’. However, party B explicitly rejects the video media stream by indicating a receiver port number ‘0’.

⇒ This SDP-response needs to be embedded into a Response: 200-OK to allow the session to start in the first place. Reception of the Response: 200-OK is then confirmed through the final ACK.

[RFC 3312 (8.1)]

This case needs to be distinguished from in-call modifications of session which are handled later during this chapter.




HHaannddlliinngg tthhee PPrreeccoonnddiittiioonn AAttttrriibbuutteess ““aa == ccuurrrr::”” aanndd ““aa == ddeess::”” • Overview

The figure illustrates the exchange of session preconditions and the related progress reports between the two parties A and B. On the following pages we will examine the meaning of the different parts in detail.




HHaannddlliinngg tthhee PPrreeccoonnddiittiioonn AAttttrriibbuutteess ““aa == ccuurrrr::”” aanndd ““aa == ddeess::”” Overview ⇒ Please consider that the first message will most likely be an INVITE which is sent from A to B. This SIP-message contains SDP-content which

consists of the definition of an audio stream and the related QoS-preconditions. ⇒ Party B will eventually respond to party A, most likely through a provisional response message ( 1XX-response). We assume that no resource

allocation has been done by party B yet. ⇒ The next two messages indicate the resource allocation progress of party A and B. Only when the resource allocation has succeeded at both peers,

the called party B is alerted ( 180-RINGING). ⇒ The meaning of the illustrated SDP-content will be evaluated in detail on the following slides. [RFC 3312]




TThhee nneeww OOppttiioonn TTaagg ““pprreeccoonnddiittiioonn””




TThhee nneeww OOppttiioonn TTaagg ““pprreeccoonnddiittiioonn”” ⇒ The figure illustrates it: Preconditions within SDP-bodies cannot just be applied or used. The Request: INVITE and the related Response-messages

will mandate the use of preconditions by including the option tag “precondition” in the “Require:”-header field [RFC 3312 (11)]. ⇒ This header field shall be used, if preconditions are mandatory. Alternatively, the option tag “precondition” may be added to the “Supported:”-header

field, if the preconditions are not mandatory.

Note that the support of “preconditions” also requires the support of “100rel” (acknowledged reliable provisional responses as per RFC 3262). Accordingly, this option tag shall also be present [RFC 3312 (11)].




TThhee ““mm == ……”” LLiinnee // PPoorrtt NNuummbbeerr aanndd PPaayyllooaadd TTyyppee




IInntteerrpprreettaattiioonn ooff ““llooccaall”” aanndd ““rreemmoottee”” DDiirreeccttiioonn--TTaaggss




IInntteerrpprreettaattiioonn ooff tthhee ““ccuurrrreenntt--ssttaattuuss”” AAttttrriibbuuttee ((““aa == ccuurrrr::””))




TThhee ““ddeessiirreedd--ssttaattuuss”” aanndd ““ccoonnffiirrmm--ssttaattuuss”” AAttttrriibbuutteess




PPrreeccoonnddiittiioonnss ffuullffiilllleedd:: tthhee ffiinnaall SSttaattuuss




EExxaammppllee 11:: RReessoouurrccee RReesseerrvvaattiioonn iiff IIPP--CCAANN == GGEERRAANN//UUTTRRAANN




EExxaammppllee 11:: RReessoouurrccee RReesseerrvvaattiioonn iiff IIPP--CCAANN == GGEERRAANN//UUTTRRAANN ⇒ The figure illustrates the case when the IP-CAN of the invited party is based on GERAN or UTRAN. In this case, the Request: INVITE will contain a

media authorization token which is used by the UA / mobile station as “entry ticket” into real-time QoS. The media authorization token has previously been conveyed by the PEP (Policy Enforcement Point) to the PDF (policy decision function) upon request of the PDF. The PEP is usually part of the GGSN.

⇒ Upon reception of the Request: INVITE, the UA needs to interpret the received SDP-parameters and translate them into IP-CAN-specific QoS-parameters which in this case means 3GPP-specific QoS-parameters.

Selection of 3GPP-specific QoS-Parameters ⇒ Since the media type is audio or video rather than message, application or data the traffic class is selected with “Conversational Class”. Alternatively,

is the media stream would be marked as “sendonly” or “recvonly”, the traffic class would have been selected with “Streaming Class”. ⇒ The transfer delay is requested with 100 ms. ⇒ The SDP-parameter bandwidth “b=AS: 29” translates into “Guaranteed Bitrate” and “Maximum Bitrate” with app. 32 kbit/s (the additional bandwidth is

there to considering RTCP-reporting). ⇒ Of course there are many other QoS-parameters which are not illustrated here.

Activation of QoS-aware Media Tunnel ⇒ Completely independent from SIP, the UA / mobile station then activates a secondary PDP-context through SM-signaling messages (Session

Management). The UA / MS sends out an ACT_SEC_PDP_CT_REQ-message (Activate Secondary Packet Data Protocol Context Request) to the SGSN and upon successful PDP-context establishment it receives back an ACT_SEC_PDP_CT_RSP-message (Activate Secondary Packet Data Protocol Context Response).

⇒ As illustrated, the UA / mobile station needs to include the media authorization token into the ACT_SEC_PDP_CT_REQ-message. After reception by the GGSN, the PEP (Policy Enforcement Point) which is physically part of the GGSN will check with the PDF (Policy Decision Function) which is part of the P-CSCF whether the requested resources have really been authorized and are necessary.

⇒ For more details about PDP-context activation please refer to the INACON-book “GPRS – Signaling & Protocol Analysis (RAN & Mobile Station)”. [3GTS 23.060, 3GTS 24.008, 3GTS 29.208]




EExxaammppllee 22:: RReessoouurrccee RReesseerrvvaattiioonn iiff IIPP--CCAANN == WWIIMMAAXX




EExxaammppllee 22:: RReessoouurrccee RReesseerrvvaattiioonn iiff IIPP--CCAANN == WWIIMMAAXX ⇒ This figure depicts another case in which the IP-CAN of the invited party is based on WIMAX / 802.16. In this case, the Request: INVITE may at some

time in the future contain a media authorization token which can be used by the UA / subscriber station as “entry ticket” into real-time QoS.

Note that at least today, WIMAX has no means to convey a media authorization from the mobile station to the network.

⇒ Upon reception of the Request: INVITE, the UA needs to interpret the received SDP-parameters and translate them into IP-CAN-specific QoS-parameters which in this case means WIMAX / 802.16-specific QoS-parameters.

Selection of WIMAX / 802.16-specific QoS-Parameters ⇒ Since the media type is audio and the maximum latency is app. 50 ms, the service class can be selected with “Unsolicited Grant Service” which allows

for the smallest latency. ⇒ The SDP-parameter bandwidth “b=AS: 29” translates into “Minimum Reserved Traffic Rate” and “Maximum Sustained Traffic Rate” of 36 kbit/s. Note

that the additional bandwidth is there to considering RTCP-reporting and because WIMAX QoS-parameters follow certain granularities. ⇒ Of course there are many other QoS-parameters which are not illustrated here.

Activation of QoS-aware Media Tunnel ⇒ Completely independent from SIP, the UA / mobile station establishes new “Service Flows” through 802.16-specific MAC-messages. The UA / MS

sends out a DSA-REQ-message (Dynamic Service Addition) to the WIMAX base station which interprets and relays it towards a WIMAX ASN-Gateway (Access Service Network).

⇒ It is the ASN-GW that finally approves the new service flows.

At least today, there are no means for the WIMAX mobile station to include the media authorization token. Neither does the WIMAX-forum support QoS-policing.

⇒ For more details about DSA-procedure please refer to the INACON-book “WIMAX from A-Z”. [IEEE 802.16-2005]




EExxaammppllee 33:: RReessoouurrccee RReesseerrvvaattiioonn iiff IIPP--CCAANN == IInnttSSeerrvv--aawwaarree




EExxaammppllee 33:: RReessoouurrccee RReesseerrvvaattiioonn iiff IIPP--CCAANN == IInnttSSeerrvv--aawwaarree ⇒ The figure illustrates the case when the IP-CAN of the invited party is based on a DSL-access line or a Cable-TV network. Although several options

exist is this case, we depict a case in which the UA (a set top box) uses IntServ to request a QoS-aware path within its access network to receive a movie from the backbone network (represented by the P-CSCF).

⇒ As illustrated in case of IntServ-aware networks, the Request: INVITE will contain a media authorization token which is used by the UA / set top box as “entry ticket” into real-time QoS. The media authorization token has previously been conveyed by the PEP (Policy Enforcement Point) to the PDF (policy decision function) upon request of the PDF. The PEP is usually part of the edge router (see graphics). Unlike the IEEE and the WIMAX-forum, the IETF already integrated IntServ and Policy Control [RFC 2750, RFC 3521].

⇒ Upon reception of the Request: INVITE, the UA / set top box needs to interpret the received SDP-parameters and translate them into IP-CAN-specific QoS-parameters which in this case means IntServ-specific QoS-parameters.

Selection of IntServ-specific QoS-Parameters ⇒ In the IntServ-environment, the real-time QoS-requirement translates into the selection of ”Guaranteed QoS” rather than “Controlled QoS” to cope with

minimum delay requirements. ⇒ This transfer delay is termed “Slack Term” in the IntServ-environment and it is selected with 100 ms (implementation specific). ⇒ The SDP-parameter bandwidth “b=AS: 2000” translates into “Guaranteed Bitrate” and “Maximum Bitrate” with app. 2001 kbit/s (the additional 1 kbit/s

bandwidth is there for RTCP-reporting). ⇒ Of course there are many other QoS-parameters which are not illustrated here.

Activation of QoS-aware Media Tunnel ⇒ Completely independent from SIP, the UA / mobile station establishes a unidirectional new “QoS-Path” through IntServ-specific RSVP-messages. The

UA / MS sends out an RSVP: Path-message to its standard gateway which relays it internally towards other IntServ-aware routers Alternatively, there could be a DiffServ-environment which uses DSCP’s to indicate a certain QoS-requirement within each IP-frame

⇒ For more details about IntServ and Policing please refer to the respective IETF-specifications RFC 2749 and RFC 3521. [RFC 2749, RFC 2750, RFC 3084, RFC 3521, PacketCable PKT-SP-DQOS-I12-050812 “Dynamic Quality of Service Specification”]




EExxaammppllee 44:: UUnnssuucccceessssffuull OOuuttccoommee




EExxaammppllee 44:: UUnnssuucccceessssffuull OOuuttccoommee ⇒ The figure illustrates the case when the IP-CAN of the invited party is based on GERAN or UTRAN and the preconditions cannot be met. ⇒ Everything is performed as illustrated on the previous example but in this case, the GGSN is unable to provide the required service. Accordingly, it

rejects the secondary PDP-context activation with a failure indication within the GTP: CT_PDP_CT_RSP-message. ⇒ The SGSN translates this into an SM: ACT_SEC_PDP_CT_REJ-message. This is how the mobile station experiences that the preconditions cannot

be met. ⇒ Consequentially, the mobile station will send a Response: 580 – Preconditions cannot be met towards the P-CSCF. [3GTS 23.060, 3GTS 24.008, 3GTS 29.208, RFC 3312 (8)]




SSuummmmaarryy

• The inclusion of QoS-related SDP-preconditions into SIP-messages avoids the alerting of users without resources being available It therefore paves the way for more sophisticated services and for the control of the resource management through SIP.

• Technically, SDP uses the two attributes “current” and “desired” to communicate the current local resource allocation situation to the peer

• Preconditions are met if both states “current” and “desired” are equal

• If either side is unable to fulfill the necessary preconditions it shall inform the peer about the failure by tagging the respective precondition with a “failure” attribute This failure attribute shall replace the so called strength-tag ‘mandatory’ or ‘optional’




SSuummmmaarryy






• Please insert the missing messages and message parts into the following scenario:




???? Question Section 30 ???? ⇒ What happens if party B does not receive the Request: ACK-message?

Notes:




QQuueessttiioonn 44:: AArree tthheerree aannyy MMeeaannss ffoorr SSeeccoonnddaarryy CCaallll TTrreeaattmmeenntt?? What happens if the called party…

… is currently busy on another call? Distinction is necessary whether the called party has subscribed for secondary call treatment or not.

… has activated “Call Forwarding Unconditional”? Which effectively means that every incoming call (of certain type?) shall be rejected.

… does not respond for some time to an incoming call? Again, a distinction is necessary whether the called party has subscribed for secondary call treatment or not. Proxy server interaction is most likely necessary in this case.

… has invoked the “do not disturb” feature? This feature may be applicable to all incoming calls but can be restricted only to certain callers. Positive and negative lists of “callers to be rejected” are feasible.

… has activated the “Find Me” Feature? The “Find me” feature means that a user is initially called on his/her primary device, upon no response on the device with second priority and so on.




QQuueessttiioonn 44:: AArree tthheerree aannyy MMeeaannss ffoorr SSeeccoonnddaarryy CCaallll TTrreeaattmmeenntt Answer: Yes, there are means for User Busy It may also be possible that the user puts the existing call on hold and first responds to the new call. This however is another feature.

Call Forwarding Unconditional Most interestingly, the same scenario applies also to the case when the user is currently not registered at all. Most likely, the user has to configure the rules for secondary call treatment through a web interface.

User not Responding We state that proxy server interaction is *MOST LIKELY* necessary to support this feature. The term “most likely” means that theoretically, also the user agent ( the user device) could send a SIP-Response to the calling party, indicating the alternative address.

The “Do not Disturb” Feature The question arises what the detailed meaning of positive and negative lists is: A positive list of callers to be rejected really means a black list: Everybody who shall be “silently discarded” is added to this list. Vice versa, we could think of a negative list: Everybody who is not listed is silently discarded. This is more a “white list” than a black list. It may also be interesting to reject all calls from callers who hide their identity. [RFC 3261 (21.4.18)]

The “Find Me” Feature




((11)) UUsseerr BBuussyy aanndd ““DDoo nnoott DDiissttuurrbb”” FFeeaattuurree –– DDeettaaiilleedd MMeessssaaggee SSeeqquueennccee CChhaarrtt




((11)) ““CCaallll FFoorrwwaarrddiinngg UUnnccoonnddiittiioonnaall”” // ““UUsseerr nnoott RReeggiisstteerreedd”” –– DDeettaaiilleedd MMeessssaaggee SSeeqquueennccee CChhaarrtt




((11)) UUsseerr nnoott RReessppoonnddiinngg –– DDeettaaiilleedd MMeessssaaggee SSeeqquueennccee CChhaarrtt




((11)) FFiinndd mmee // FFoollllooww mmee –– DDeettaaiilleedd MMeessssaaggee SSeeqquueennccee CChhaarrtt




TTaacckklliinngg NNAATT--IIssssuueess wwiitthhiinn tthhee IIMMSS • Introducing NAT and NAPT




TTaacckklliinngg NNAATT--IIssssuueess wwiitthhiinn tthhee IIMMSS Introducing NAT and NAPT The figure illustrates the operation of a typical NAT/NAPT-system. ⇒ Internally in the private IP-network, all devices have been assigned private IP-addresses; in the example class A-addresses 10.0.0.0 have been used.

Note that behind a NAT/NAPT, any range of IP-addresses (not only dedicated private ones) can be used and assigned to booting devices.

⇒ In the example, the laptop with address 10.0.0.20 sends an IP-frame from source port number AAAA (TCP or UDP) to the server in the outside IP-network which has an IP-address 80.132.19.30. The destination port number on the server is CCCC (TCP or UDP).

⇒ As illustrated, the NAT/NAPT-router is also the edge router of the private IP-network. Every outgoing IP-frame needs to be routed through the NAT/NAPT-router.

⇒ Its specific operation becomes clear when looking at the left message box: The NAT/NAPT-router replaces the source IP-address 10.0.0.20 with its own IP-address 149.225.10.22 which is also valid on the outside IP-network. The NAT/NAPT-router also replaces the source port number AAAA with a randomly selected but very important port number, say BBBB. The NAT/NAPT-router also buffers the association between its own source port number BBBB and the internal IP-address 10.0.0.20 / port number AAAA. The NAT/NAPT-router does not tamper with the content of the IP-frame.

The buffering of this association is time limited and the actual buffering time is implementation dependent. Recommended values are 5 minutes for UDP-associations and 24 hours for TCP-associations [RFC 4008].

⇒ Therefore, the NAT/NAPT-router really pretends to be the origin of the IP-frame and its content when it sends the IP-frame towards the server 80.132.19.30.

For fully understanding the operation of NAT/NAPT it is very important to understand the following step: ⇒ When the server 80.132.19.30 sends its reply for the previously received IP-frame, it sends it to 149.225.10.22 / port number BBBB. Since the

NAT/NAPT-router has in the meantime probably sent many IP-frames to different destinations and possibly several ones also to 80.132.19.30, it is this port number BBBB that allows the NAT/NAPT-router to relate the incoming IP-frame to the previously stored association.

⇒ Therefore, the NAT/NAPT-router is enabled to replace the destination IP-address and port number with the internal values 10.0.0.20 and AAAA.

The whole meaning of NAT/NAPT lies in the sudden availability of a rather unlimited number of IP-addresses. This makes NAT so appealing. However, NAT also provides an inherent firewall function because no IP-frame may enter a private IP-network through a NAT/NAPT-router unless some process from the inside requested it.




LLiiaabbiilliittiieess ooff NNAATT // NNAAPPTT

• NAT/NAPT operates on the network and transport layer level and is unable to consider IP-address and port number instances within upper layer PDU’s This is particularly a problem for SIP and requires the introduction of ALG’s.

• There are different NAT/NAPT types which operate differently It is unknown in a given situation which NAT/NAPT-type is actually in use. This makes the addressing of potential NAT/NAPT-issues particularly difficult.

• If NAT is used then IPsec-connections cannot operate in transport mode The reason is the integrity protection of IPsec. Changing IP-addresses and port numbers on the way from source to destination is obviously regarded as security violation by the receiver.

• NAT/NAPT IP-address Port Associations are time limited That is, even if SIP could penetrate NAT-routers, it would be impossible for a registrar to contact a UA because the established association within the NAT/NAPT expires after some inactivity time.




LLiiaabbiilliittiieess ooff NNAATT // NNAAPPTT • NAT/NAPT operates on the network and transport layer level and is unable to consider IP-address and port number

instances within upper layer PDU’s ALG’s (Application Layer Gateways) may be integral part of NAT/NAPT-routers although they do not appear as SIP-hops. Still, they check whether an IP-frame which is processed within a NAT/NAPT-router contains critical protocol information like SIP/SDP. In such a case, the ALG alters also this protocol’s information accordingly to avoid problems. In the IMS-domain, such devices are called IMS-ALG.

• There are different NAT/NAPT types which operate differently • If NAT is used then IPsec-connections cannot operate in transport mode

It is important to note that IPsec in tunnel mode is not jeopardized since it adds a second IP-frame “shell” around the first one which may have been NAT-affected.

• NAT/NAPT IP-address Port Associations are time limited After registration there will most likely be no continuous activity of a user agent. From the perspective of the NAT/NAPT-router, this inactivity automatically results in the release of the related association. Consequentially, the registrar will be unable to reach the UA through the NAT/NAPT-router.




NNeettwwoorrkk CCoonnffiigguurraattiioonn ((UUAA bbeehhiinndd ttwwoo NNAATT’’ss))




NNeettwwoorrkk CCoonnffiigguurraattiioonn ((UUAA bbeehhiinndd ttwwoo NNAATT’’ss)) The figure illustrates the network configuration example that we use to outline how NAT-issues can be addressed within the IMS. Note that this solution has not been standardized yet ( Rel 7). ⇒ The UA shall be nested within a residential private IP-network, say a home WLAN. Of course, the private network uses private IP-addresses and when

booting, the UA was assigned a private IP-address (10.0.0.20). ⇒ The residential private IP-network lies behind a NAT-router. As example please consider that the residential private IP-network is granted internet

access by an ISP through PPPoE (Point-to-Point Protocol over Ethernet). ⇒ Behind the ISP’s IP-network we reach the public internet (blue) and behind it there is the home IMS of the UA on the left hand side. Note that the ISP

is also using NAT at his/her network edge. ⇒ In case of the NAT’s, the indicated IP-addresses represent the outside IP-addresses. That is, the right NAT-router is also using a second private IP-

address within the 192.X.Y.Z domain. ⇒ Since we use two NAT’s we can assume that any number of NAT’s is taken care of by our considerations.




SStteepp 11:: RReeggiissttrraattiioonn bbeehhiinndd ttwwoo NNAATT’’ss • SIP: REGISTER-Messages




SStteepp 11:: RReeggiissttrraattiioonn bbeehhiinndd ttwwoo NNAATT’’ss SIP: REGISTER-Messages The figure illustrates how the Request: REGISTER-message which is sent by the UA behind the two NAT’s reaches the P-CSCF, is processed by the P-CSCF and finally gets relayed to the S-CSCF.

• Bullet 1: The entire IP-frame is shown together with the included SIP-message. Please note that the UA uses the IP-address of the P-CSCF as destination IP-address. The P-CSCF’s address was prior obtained through DHCP-options or was preconfigured in the UA.

• Bullet 2: This bullet highlights the IP-frame with the embedded Request: REGISTER behind the first NAT. As expected, the NAT replaced source IP-address and port number through its own IP-address 192.0.0.10 and BBBB. Note that destination IP-address and port number are still the same.

• Bullet 3 and 4: When the P-CSCF receives the Request: REGISTER, it detects the NAT-interworking based on the difference between the source IP-address 212.10.10.20 (within the IP-frame header) and the IP-address indicated in the topmost “Via:”-header field.

• Bullet 5: Therefore, the P-CSCF acts as IMS-ALG and adds to the “Via:”-header field of the UA the “received “- and “rport”- attributes. Both will allow the P-CSCF to forward upcoming response message to the UA through the closest NAT ( received=212.10.10.20 / rport=CCCC).

• Bullet 6: Finally, the P-CSCF forwards the Request: REGISTER-message to the S-CSCF.




SSIIPP:: 220000--OOKK RReessppoonnssee MMeessssaaggee




SSIIPP:: 220000--OOKK RReessppoonnssee MMeessssaaggee The figure assumes that there is no authentication of the UA, hence no Response: 401-Unauthorized is replied to the UA upon receiving the Request: REGISTER.

• Bullet 1: The S-CSCF rather confirms the registration and returns a Response: 200-OK to the P-CSCF.

• Bullet 2: Upon removal of its own “Via:”-header field entry, the P-CSCF also reads the “received “- and “rport”- attribute values. They are removed from the “Via:”-header field entry of the UA but …

• Bullet 3: … the P-CSCF will not send the Response: 200-OK to the UA’s IP-address but rather to the IP-address 212.10.10.20 of the NAT, using the source port number CCCC of the NAT as destination port number.

• Bullet 4: This bullet highlights the IP-frame with the embedded Response: 200-OK-message behind the right hand NAT. As expected, the NAT replaced destination IP-address and port number through the other NAT’s IP-address 192.0.0.10 and port number BBBB. Note that source IP-address and port number are still the same on the return path through the NAT.

• Bullet 5: This bullet highlights the IP-frame with the embedded Response: 200-OK-message behind the left hand NAT. Like its predecessor, this NAT replaced destination IP-address and port number through the UA’s IP-address 10.0.0.20 and port number AAAA. Note that source IP-address and port number are still the same. For the UA the NAT-interaction remained transparent.

It is very important to note that the S-CSCF mandates a re-registration period of 180 seconds to avoid that the NAT-associations time out.




XX--CCSSCCFF-- aanndd NNAAPPTT--AAssssoocciiaattiioonnss aafftteerr RReeggiissttrraattiioonn




SStteepp 22:: UUAA OOrriiggiinnaattiinngg SSeessssiioonn EEssttaabblliisshhmmeenntt bbeehhiinndd 22 NNAATT’’ss • Problem Description




SStteepp 22:: UUAA OOrriiggiinnaattiinngg SSeessssiioonn EEssttaabblliisshhmmeenntt bbeehhiinndd 22 NNAATT’’ss Problem Description

SIP-messages can flow back and forth through the NAT’s, provided that symmetric port numbering is applied. Again, symmetric port numbering means that the SIP-proxy and the UA both send and receive SIP-message on/from the same port number, e.g. 5060.

The figure and the description underneath illustrate the reason why there is still a problem if media transfer shall occur, even when the aforementioned measures are taken during registration and even when the P-CSCF incorporates an IMS-ALG:

⇒ The UA conveys in its Request: INVITE-message its own connection address = 10.0.0.20 and a receiver port number XXXX for audio and YYYY for

video. ⇒ The called User B conveys his/her connection address 88.10.10.12 and receiver port number GGGG for audio and HHHH for video. With this

information available at the calling UA, the UA can send data to User B through the NAT’s. ⇒ However, User B is unable to send media data anywhere. The media path from User B to the calling UA remains silent.

SIP-proxies can only operate on SIP-signaling messages and therefore the IMS-ALG function is not suited to address this issue. The amendment of a media gateway called TrGw in 3GPP becomes necessary.




SSIIPP:: IINNVVIITTEE--MMeessssaaggee




SSIIPP:: IINNVVIITTEE--MMeessssaaggee The figure illustrates how the Request: INVITE-message which is sent by the UA behind the two NAT’s reaches the P-CSCF, is processed by the P-CSCF and finally gets relayed to the S-CSCF before it is forwarded to the next hop (and finally it will reach its destination). Note that we did not include the Response: 100-Trying message.

• Bullet 1: The entire IP-frame is shown together with the included SIP-message. Please note that the UA uses the IP-address of the P-CSCF as destination IP-address. And of course, the UA indicates its own IP-address 10.0.0.20 as connection address within the SDP-portion. The UA has reserved the two port numbers 10000 and 10002 to receive audio and video data from the called user “Paul Brause”.

• Bullet 2: When the P-CSCF receives the Request: INVITE, it detects the NAT-interworking based on the difference between the source IP-address (within the IP-frame header) and the IP-address indicated in the topmost “Via:”-header field. As done during registration, the P-CSCF acts as IMS-ALG and adds to the “Via:”-header field of the UA the “received “- and “rport”- attributes. Both will allow the P-CSCF to forward upcoming response message to the UA through the closest NAT ( received=212.10.10.20 / rport=CCCC).

• Bullet 3: However, most important for our current considerations is the fact that the P-CSCF also inspects the included SDP-portion. As illustrated, the P-CSCF will communicate with the TrGw (IP-address 69.12.12.11) and it will trigger the TrGw to open two port numbers to act as receiver port numbers for the upcoming audio and video streams from “Paul Brause”.

• Bullet 4: Finally, the P-CSCF receives indication from the TrGw that port numbers 6666 and 8888 have been opened. Accordingly, the P-CSCF will alter the SDP-portion of the Request: INVITE-message and replace the UA’s connection address and port numbers through the ones received from the TrGw. Then the P-CSCF forwards the Request: INVITE-message to the S-CSCF.

By replacing the UA’s connection address and port numbers through the IP-address and port numbers of the TrGw, the invited party gets a valid sink for their media data.




SSIIPP:: 118833--SSeessssiioonn PPrrooggrreessss RReessppoonnssee MMeessssaaggee




SSIIPP:: 118833--SSeessssiioonn PPrrooggrreessss RReessppoonnssee MMeessssaaggee The figure emphasizes and the reception and processing of the Response: 183-Session Progress through the P-CSCF. We picked this response message as it includes the SDP from the perspective of “Paul Brause”.

• Bullet 1: The entire IP-frame is shown together with the included SIP-message. Please note that we show the IP-frame / SIP-message between S-CSCF and P-CSCF which explains the source and destination IP-addresses. The SDP of the message indicates the connection address (A956:7D6A:3490::7A34:66A8:9007:1CB5) and port numbers (40000 and 40002) at which “Paul Brause” wants to receive the audio and video data.

• Bullet 2: Before the P-CSCF forwards the Response: 183-Session Progress through the NAT (212.10.10.20 / CCCC) to the UA, it asks the TrGw to open to more port numbers for the upcoming communication.

• Bullet 3: Then the P-CSCF replaces the respective parts of the SDP of the Response: 183-Session Progress with the address and port numbers as received from the TrGw (2222 and 4444). This altered message is sent through the NAT (212.10.10.20 / CCCC) to the UA. Note that we did not include any other SIP-message (like Response: 200-OK) as these messages are not essential for the current considerations. Of course, these messages are necessary to establish the SIP-dialog and the session.




AAuuddiioo DDaattaa FFllooww tthhrroouugghh tthhee NNAATT’’ss –– UUEE OOrriiggiinnaattiinngg




AAuuddiioo DDaattaa FFllooww tthhrroouugghh tthhee NNAATT’’ss –– UUEE OOrriiggiinnaattiinngg After the reception of the Response: 183-Session Progress message the UA is aware that it shall send audio data to IP-address 69.12.12.11 / port number 2222 and video data to IP-address 69.12.12.11 / port number 4444.

• Bullet 1: The UA issues RTP-frames with source IP-address / port number 10.0.0.20 / 10000 and destination IP-address / port number 69.12.12.11 / 2222.

• Bullet 2: These RTP-frames are intercepted by the first NAT. It replaces the UA’s source IP-address and port number by its own IP-address and port number before relaying the RTP-frames towards the next NAT. Of course, the first NAT is not necessarily aware that there is another NAT involved. Destination IP-address / port number within the RTP-frames remain unchanged. Note that the UDP-port number 21235 is odd and not even.

• Bullet 3: These IP-frames illustrate the perspective of the TrGw. The first of these IP-frames (with embedded RTP) fulfills a very important mission: It tells the TrGw to which port number of the NAT 212.10.10.20 the TrGw needs to send audio data to reach the UA behind that NAT. Of course, the TrGw will also relay the audio frames towards the connection address and port number of “Paul Brause” ( A956:7D6A:3490::7A34:66A8:9007:1CB5 / 40000).

Note that we only show the audio media stream but it works the same way for the video stream.




AAuuddiioo DDaattaa FFllooww tthhrroouugghh tthhee NNAATT’’ss–– UUEE TTeerrmmiinnaattiinngg




AAuuddiioo DDaattaa FFllooww tthhrroouugghh tthhee NNAATT’’ss–– UUEE TTeerrmmiinnaattiinngg • Bullet 1:

The TrGw receives IP-frames with included RTP-audio data on IP-address 69.12.12.11 / port number 6666.

• Bullet 2: From the reception of the UA’s audio frames from 212.10.10.20 / 8670 (illustrated on the previous slide) the TrGw knows, that it needs to send audio data for the UA to the same port number 8670 to reach the UA. Accordingly, the TrGw put the RTP-frames into a new IP-frame with its own IP-address as source IP-address / source port number 69.12.12.11 / 2222 and the NAT’s IP-address / port number 212.10.10.20 / 8670 as destination IP-address / destination port number.

• Bullet 3: The NAT 212.10.10.20 will check its NAPT-association table and detect that everything that is received on port number 8670 needs internally be mapped to destination IP-address / destination port number 192.0.0.10 / 21235. This explains the new destination IP-address and destination port number.

• Bullet 3: Finally, the NAT 192.0.0.10 will check its NAPT-association table and detect that everything that is received on port number 21235 needs internally be mapped to destination IP-address / destination port number 10.0.0.20 / 10000. Consequentially, the RTP-frames reach the UA.




PPrraaccttiiccaall EExxeerrcciissee • Considering the aforementioned: If NAT is also used IMS-internally, will the I-CSCF and the P-CSCF require two

separate TrGw’s or is a single TrGw with NAT-function sufficient?




IIMMSS aanndd IIPP--CCAANN uussee NNAATT // HHooww mmaannyy TTrrGGww’’ss aarree rreeqquuiirreedd?? ((PPrraaccttiiccaall EExxeerrcciissee)) • To resolve this practical exercise you are asked to fill in the missing parts in the various message boxes underneath.

Each message box (each SIP B31) relates to a specific section in the figure. Note that we suppressed most SIP-messages and only focus on those that are required for our considerations. The session shall be audio only and the audio codec shall be set to 3 ( GSM Full Rate).

• We start with Option B

SIP B11 ⇒ SIP B21 ⇒

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________

Destination Port: _________________________________________________

I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________

Destination Port: _________________________________________________________

S I P

INVITE

Via: ____________________________________________________________

Contact: ________________________________________________________

S I P

INVITE

Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________




SIP B31 ⇒ SIP B41 ⇒

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


S I P

INVITE

Via: ____________________________________________________________

Contact: ________________________________________________________

S I P

INVITE

Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________

SIP B51 ⇒ ⇐ SIP B52

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


S I P

INVITE

Via: ____________________________________________________________

Contact: ________________________________________________________

S I P

183-Session Progress

Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________

⇐ SIP B42 ⇐ SIP B32

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________




Source Port: _____________________________________________________


Source Port: ____________________________________________________________


S I P


Via: ____________________________________________________________

Contact: ________________________________________________________

S I P


Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________

⇐ SIP B22 ⇐ SIP B12

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


S I P


Via: ____________________________________________________________

Contact: ________________________________________________________

S I P


Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________

Media B11 ⇒ Media B21 ⇒

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


R T

Nothing to declare RT

Nothing to declare




P P

Media B31 ⇒ ⇐ Media B32

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


R T P

Nothing to declare R

T P

Nothing to declare




⇐ Media B22 ⇐ Media B11

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


R T P


T P

Nothing to declare




• We continue with Option A

SIP A11 ⇒ SIP A21 ⇒

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


S I P

INVITE

Via: ____________________________________________________________

Contact: ________________________________________________________

S I P

INVITE

Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________




SIP A31 ⇒ SIP A41 ⇒

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


S I P

INVITE

Via: ____________________________________________________________

Contact: ________________________________________________________

S I P

INVITE

Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________

SIP A51 ⇒ ⇐ SIP A52

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


S I P

INVITE

Via: ____________________________________________________________

Contact: ________________________________________________________

S I P


Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________

⇐ SIP A42 ⇐ SIP A32

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________




Source Port: _____________________________________________________


Source Port: ____________________________________________________________


S I P


Via: ____________________________________________________________

Contact: ________________________________________________________

S I P


Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________

⇐ SIP A22 ⇐ SIP A12

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


S I P


Via: ____________________________________________________________

Contact: ________________________________________________________

S I P


Via: ___________________________________________________________________

Contact: _______________________________________________________________

S D P

c = : ___________________________________________________________

m = : ___________________________________________________________

S DP

c = : ___________________________________________________________________

m = : __________________________________________________________________

Media A11 ⇒ Media A21 ⇒

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


R T

Nothing to declare RT

Nothing to declare




P P

Media A31 ⇒ Media A41 ⇒

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


R T P


T P

Nothing to declare




⇐ Media A42 ⇐ Media A32

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


R T P


T P

Nothing to declare

⇐ Media A22 ⇐ Media A12

I P

Source IP: ______________________________________________________

Destination IP: ___________________________________________________

Source Port: _____________________________________________________


I P

Source IP: ______________________________________________________________

Destination IP: __________________________________________________________

Source Port: ____________________________________________________________


R T P


T P

Nothing to declare




Responses to the Question Sections

• Answers for Question Section 1: Q: Why are there SIP-proxies to relay SIP-messages? Why is this task not taken care of by simple IP-routers? R: IP-routers operate on the IP-layer which is OSI-layer 3. These routers will not consider any embedded application layer information (like SIP) for their routing decisions. Therefore, special SIP-proxies are required to take care of the routing function on the SIP-layer level.

• Answers for Question Section 2: Q: If either SIP-proxy would autonomously redirect the INVITE to its new destination, would this be a stateful or a stateless proxy server or both? R: It would need to be a stateful SIP-proxy as it kept track of the transaction state. Otherwise the proxy would not be able to relay the INVITE to another destination.

• Answers for Question Section 3: Q: Taking into account the aforementioned statement about the magic cookie: Is the SIP-scenario which we show in chapter 1 using RFC 2543 compliant software or RFC 3261 compliant software? R: Since no branch-parameter starts with the magic cookie, it is obviously RFC 2543 compliant software. Q: Why is “branch” there in the first place? R: The “branch”-parameter is there to ease the lookup tasks of SIP-proxies: Branch allows the SIP-proxies to identify easily as to which transaction an incoming response message belongs to.

• Answers for Question Section 4: Q: Do you think that a stateless SIP-proxy needs to allocate a unique branch parameter? R: Yes, a stateless SIP-proxy server shall also allocate a unique branch parameter. And although the stateless SIP-proxy does not maintain transaction state, it shall still make sure that a possible message retransmission is tagged with the same branch-parameter value.

• Answers for Question Section 5: Q: Why is transaction numbering done in the first place? In other words: Why is there a “CSeq:”-number? R: CSeq allows for the monotonically increasing numbering of transactions within a dialog. The CSeq-number together with the CSeq-method type allows matching INVITE-transactions to their ACK’s.




• Answers for Question Section 6: Q: Why does SIP deploy a “3-Way Handshake” –procedure (1. INVITE / 2. 200-OK / 3. ACK) in the first place? R: The ACK at the end confirms session establishment to the peer that sent 200-OK. Since forking may apply, the peer who sent 200-OK really requires that ACK-frame to be sure that the session started. Q: Why is ACK considered as a new transaction? R: The ACK for a Response: 200-OK confirms session establishment and can therefore only be sent by the final peer and not by an intermediate stateful proxy that could well send an ACK for an unsuccessful 3XX-6XX response (see next section). On the other hand, the INVITE-transaction shall be terminated equally by proxy and end-user SIP-implementations as soon as a 200-OK is received. Hence, the only entity within the end user to send the ACK is the transaction user / Core layer and it will generate a new transaction for the ACK [RFC 3261 (p.129)]




• Answers for Question Section 7: Q: Please compare the illustrated procedure and messages with standard attachment/location updating and periodic location updating in GSM-mobile networks. Use a pencil and draw the related scenario adjacent to the illustrated scenario and compare the message names. R:




Q: Consider that a subscriber can register the same user identity (e.g. sip: [email protected]) from different devices (e.g. landline phone at home, mobile device and work phone) and keep all registrations active simultaneously. In the yellow box at the top we mentioned a possible load sharing mechanism to select the very registrar: Can this load sharing mechanism operate only on a "per subscriber" or on a "per registration" basis ( per device) or on both? R: All registrations of a single user identity (e.g. sip: [email protected]) shall be routed to the same registrar. Otherwise, the registrar would be unable to fork an incoming session setup request for that user to different devices. Q: How does a user de-register a certain device from a registrar? R: In general, de-registration is performed by sending a Request: REGISTER-message to the registrar which contains an “expires = 0” in the “Contact:”-header field or a specific “Expires:”-header field (= 0). The very device which is deregistered is identified through its FQDN (e.g. sip: [email protected] or sip: [email protected]). Alternatively, all current registrations may be removed by setting the “Contact:”-header field to “*” and including an “Expires:”-header field (= 0) [RFC 3261 (10.2.2)]. Q: Will the registrar be able to do the same? R: Not quite but obviously, registrars also should be able to perform de-registrations and to inform the UA’s accordingly. De-registration itself is done registrar internally and the very device which is removed from the contact list of this user identity receives a Request: NOTIFY-message which includes more detailed information about the de-registration (see example underneath): NOTIFY sip: [email protected]/2.0 .. ... From: sip: [email protected];tag=151170 To: sip: [email protected];tag=31415 Call-ID: Bumm-Bumm CSeq: 23 NOTIFY Subscription-State: terminated Event: reg Content-Type: application/reginfo+xml Contact: sip: registrar.sip-service.net.home1.net Content-Length: (...) May contain XML




• Answers for Question Section 8: Q: Why do ACK and CANCEL deserve special attention? R: ACK and CANCEL deserve special attention because both reuse the “CSeq:”-number of the INVITE that they relate to. In addition, ACK is special as it does not get a response. If sent for a successful 200-OK response, ACK is therefore a transaction which only consists of a request.

• Answers for Question Section 9: Q: Which parameter is only there to provide for multiple dialogs per call? R: The “To:”-tag

• Answers for Question Section 10: Q: Does the final bullet in the yellow box relate to stateful and stateless SIP-proxies or only to stateful ones? R: Since a transaction specific timer is started, this function can only relate to stateful SIP-proxies.

• Answers for Question Section 11: Q: When is a “To:”-tag included in the indicated Response: 100-Trying message? R: Never! The Response: 100-Trying is a single hop message that shall only avoid retransmissions of the original INVITE-message. The “never” even applies in case of the receiving UAS that generates the last 100-Trying message. Any other provisional response message or any final response message can include the “To:”-tag.

• Answers for Question Section 12: Q: Will the UAC on the left side be able to initiate another session / send another Request: INVITE while timer D is still running? R: Yes, of course. But the transaction management sublayer needs to keep the transaction alive while timer D is running for UDP-transport. Q: Which entity selects the transport protocol (UDP, TCP) between two SIP-nodes? R: The party that issues or forwards the SIP-Request. That is: The UAC selects the transport for the first SIP-hop towards “its” proxy but it is this proxy that selects the transport protocol towards the next proxy and so on.

• Answers for Question Section 13: Q: With respect to the retransmitted Request: INVITE-messages: Will the Call-ID-, CSeq- and branch-values be identical in all instances? R: Yes, each Request: INVITE will be exactly identical. This applies in any case, whether SCTP, TCP or UDP or used. Still, in case of TCP the TCP-layer would take care of the retransmissions.




• Answers for Question Section 14: Q: Why does the former UAS send the Request: BYE-message only in case a Response: 200-OK was sent? R: Because the Response: 200-OK established a dialog which is not true in case of unsuccessful responses (3XX – 6XX). If no Request: ACK is received the UAS needs to clear its state machine and terminate this dialog. This happens by issuing the Request: BYE-message towards the former UAC.

• Answers for Question Section 15: Q: The provision of the “port number” behind the host is optional and apparently not necessary if it is the default port number ‘5060’. The question is when do I have to fill in this field even if the port number is ‘5060’? R: The port number ‘5060’ must be provided if the default port number would be different which is true in case of SIPS-URI’s (secure transport TLS). Their default port number is ‘5061’.

• Answers for Question Section 16: Q: With respect to the transport protocol type “TCP/BFCP”: What would have been an alternative way to register BFCP? R: The alternative way would have been: m=application <port-number> TCP BFCP. This would be aligned with the registration of TBCP.

• Answers for Question Section 17: Q: Taking these constraints about using “RR” and “RS” into consideration: How will a UA most likely indicate not to use RTCP at all in either or in both directions? R: A user agent will indicate that it does not intend to send RTCP-messages by stating a b-line: b = RS: 0. Alternatively or at the same time, the user agent may indicate that it does not want to receive RTCP-messages from the peer user agent by stating a b-line: b = RR: 0. It is noteworthy that 3GPP suggests to not using RTCP-reports in case of plain two-party audio calls [3GTS 26.236 (7.4)]. If such a plain audio call shall be setup, the two user agents shall indicate b = RR: 0 and b = RS: 0.

• Answers for Question Section 18: Q: Please look at the image: Why does the peer that acts as “sendonly” still provide a receiver port number of 4444 to the other side? R: This is done to allow the receiving node to send RTCP-receiver reports to the port number 4444+1 which is port number 4445.

• Answers for Question Section 19: Q: Repetition: Which parameters do identify messages that belong to one dialog? R: “Call-ID:”, “To:”-tag and “From:”-tag. Q: How can UAC and UAS distinguish subsequent reliable provisional response messages and their PRACK’s within an INVITE-transaction?




R: Distinction is achieved through the “RSeq:” “RAck:”-relationship. Please note that the PRACK-message will include the “RAck:”-header field that includes in sequence the RSeq-number (of the provisional response that it relates to), the CSeq-number of the original INVITE-message and INVITE as method type. It is most importantly the RSeq-number that binds together provisional responses with their PRACK’s. Q: Can PRACK only be sent through the SIP-proxies or end-to-end directly (without proxies)? R: PRACK will be sent end-to-end if the sending peer is aware of the IP-address of the final recipient and if the proxies in between did not add themselves to a “Record-Route:”-header field. Q: Which timers are used to control the transaction timeout and retransmission scheduling of Request: PRACK? R: Timer E and Timer F.

• Answers for Question Section 20: Q: Why is the resource allocation of the inviting party only done after the provisional response is received and not already before the invitation is sent? R: An earlier resource allocation of the inviting party would unnecessarily block resources and require signaling effort before it is known whether there will be a session in the first place. Besides, the UAC will wait for the acceptance of all suggested media streams through the UAS before resource reservation is done.

• Answers for Question Section 21: Q: If party A sends another INVITE after the 580-Precondtion Failure was received: Will there be any relationship of the identifiers Call-ID, CSeq, branch, “To:”-tag and “From:”-tag between the two INVITE-messages? R: Yes, there will be… The “Call-ID:”-value will be the same and the “CSeq:”-number will be incremented from the previous one. The value of “branch” will be different. The value of the “From:”-tag will be identical but the invited party will allocate a new “To:”-tag.

• Answers for Question Section 22: Q: What happens if party B does not receive the Request: ACK-message at the end of the scenario? R: In this case, the timer H will expire and party B will send a Request: BYE-message to party A which ends the dialog.

• Answers for Question Section 23: Q: In chapter 1 we stated explicitly that the IMS provides its services exclusively through the packet-switched domain. Why did we still need to insert the dotted line between the IMS and the circuit-switched domain? R: Calls from the PSTN to an MS/UE will still enter the H-PLMN at a G-MSC or G-MSC-server. If decided by the HSS of the called MS/UE, this incoming call gets routed through the IMS which requires the interconnection between circuit-switched domain and IMS.




• Answers for Question Section 24: Q: How is it possible that Miriam has been allocated a SIP-URI that does not relate to the operator’s host name (e.g. Vodafone.sip.co.uk) but to inacon.de? R: This is a simple DNS-issue. If the SRV-records within a DNS-server guide a querying SIP-device to the registrar of the responsible network operator then everything is fine. Consider in our example that a query for _SIP.UDP.inacon.de would be responded to with the IP-address or FQDN of the Vodafone registration service. Obviously, this possibility opens the opportunity of virtual registrars.

• Answers for Question Section 25: Q: Since we are talking about APN’s: Can a secondary PDP-context use a different APN than the primary PDP-context? R: No, this is not possible since the same IP-address is used for both PDP-contexts. Incoming IP-frames will be sent to the same GGSN.

• Answers for Question Section 26: Q: When is padding required within the output octet string? R: Note that there are always 3 consecutive octets processed by the “base64”-encoder. If at the end of the input string there are only 1 or 2 octets left then padding is required. Q: Which other very important application is using base64-encoding? R: The transfer of e-mail attachments such as files could cause the same problems and therefore requires base64-encoding.




List of Acronyms v2.2 Term Explanation 16-QAM 16 symbols Quadrature Amplitude Modulation (3GTS

25.213) 1xEV-DO One Carrier (1.25 MHz) Evolution - Data Only

(cdma2000) 1xEV-DV One Carrier (1.25 MHz) Evolution - Data and Voice 2B1Q Two Binary One Quaternary (Line Coding used on the

ISDN U-Interface) 3G ... 3rd Generation ... 3GPP Third Generation Partnership Project (Collaboration

between different standardization organizations (e.g. ARIB, ETSI) to define advanced mobile communications standards, responsible for UMTS)

3GPP2 Third Generation Partnership Project 2 (similar to 3GPP, but consisting of ANSI, TIA and EIA-41, responsible for cdma2000, EvDO and EVDV)

3GTR 3rd Generation Technical Report 3GTS 3rd Generation Technical Specification 4G 4th Generation ... 64-QAM 64 symbols Quadrature Amplitude Modulation 8-PSK 8 Symbol Phase Shift Keying 8VSB 8-level Vestigial Sideband Modulation (ATSC) A&S Applications & Services domain or server A/V Audio / Video AA Anonymous Access AAA Authentication, Authorization and Accounting

AAA Authorize Authenticate Answer (DIAMETER message type)

AAL ATM-Adaption Layer AAL-2 ATM Adaptation Layer 2 (for real-time services) (ITU-T

I.363.2) AAL-5 ATM-Adaptation Layer 5 (non-real time) (ITU-T I.363.5) AAR Authorize Authenticate Request (DIAMETER message

type) AAS Adaptive Antenna Systems A-Bit Acknowledgement Request Bit (used in LLC-protocol

Logical Link Control) ABM Asynchronous Balanced Mode ABNF Augmented Backus Naur Form (RFC 2234) AC Alternate Current ACC Access Control Class (3GTS 22.011) ACCH Associated Control Channel (GSM / can be an SACCH

or an FACCH) ACK Acknowledgement (3GTS 25.214, 25.308, 25.309) ACM Address Complete Message (ISUP-message type) ACS Active Codec Set ADCH Associated Dedicated Channel (3GTS 45.902) ADM Asynchronous Disconnected Mode ADPCM Adaptive Differential Pulse Code Modulation ADSL2 Asynchronous Digital Subscriber Line 2 (ITU-T G.992.3) AES Advanced Encryption Standard / Cipher Key Lengths:

128 bit, 192 bit or 256 bit AESA ATM End System Address AF Assured Forwarding (DiffServ Term) AG Absolute Grant (3GTS 25.309)




AGCH Access Grant Channel (GSM) AGWN Additive Gaussian White Noise AH Authentication Header (RFC 4302) AI Acquisition Indicator AICH Acquisition Indicator Channel (UMTS Physical Channel) AIPN All IP Network AJAX Asynchronous Javascript and XML AK Authentication Key (IEEE 802.16) AK Anonymity Key (3GTS 33.102) AKA Authentication and key agreement (3GTS 33.102) ALC Asynchronous Layered Coding ALCAP Access Link Control Application Part (ITU-T Q.2630.1 /

Q.2630.2) ALG Application Layer Gateway AM Acknowledged Mode operation (e.g. in UMTS-RLC) AM Amplitude Modulation AMC Adaptive Modulation and Coding AMC Advanced Modulation and Coding AMD Acknowledged Mode Data (UMTS RLC PDU-type) AMF Authentication management field (3GTS 33.102) AMI Alternate Mark Inversion (Line Coding) AMPS Advanced Mobile Phone System AMR Adaptive Multirate Encoding (3GTS 26.090) AMR-WB Adaptive Multi-Rate - WideBand speech codec (3GTS

26.273, ITU-T G.722.2) AMR-WB+ Extended Adaptive Multi-Rate - WideBand speech

codec (3GTS 26.304, 26.410, ITU-T G.722.1) ANSI American National Standards Institute

AoD Audio on Demand AP Access Point (IEEE 802.11, 802.16) AP Access Preamble AP-AICH CPCH Access Preamble Acquisition Indicator Channel

(UMTS Physical Channel) API Access Preamble Acquisition Indicator APN Access Point Name (Reference to a GGSN) APP A Posteriori Probability (Turbo Decoding) AR Assured Rate PDB (DiffServ Term) ARFCN Absolute Radio Frequency Channel Number ARIB Association of Radio Industries and Businesses

(Japanese) ARP Address Resolution Protocol (RFC 826) ARPU Average Revenue Per User ARQ Automatic Repeat Request AS Application Server AS Access Stratum (UMTS) AS application specific (within SDP-bandwidth specification

/ b-line) ASC Access Service Class ASCA Adjacent Subcarrier Allocation ASCI Advanced Speech Call Items (GSM-R) ASCII American Standard Code for Information Interchange

(ANSI X3.4-1986) ASIC Application Specific Integrated Circuit AS-ILCM Application Server - Incoming Leg Control Model ASN Access Service Network ASN.1 Abstract Syntax Notation 1 (ITU-T X.680 / X.681) ASN-GW Access Service Network-Gateway




AS-OLCM Application Server - Outgoing Leg Control Model ASP Application Server Process AT_MAC Message Authentication Code ATCA Advanced Telecommunications Computing Architecture AT-Command Attention-Command ATM Asynchronous Transfer Mode (ITU-T I.361) ATSC Advanced Television System Committee AuC Authentication Center AUTN Authentication Token (3GTS 33.102) AV Authentication Vector (3GTS 33.102) AVC Advanced Video Coding B2BUA Back-to-Back User Agent (SIP term / RFC 3261, RFC

3725) B8ZS Bipolar with Eight-Zero Substitution (Line Code used at

the T1-Rate (1.544 Mbit/s)) BAS Basic rate access ISDN-user interface for single lines (2

B-channels plus one D-Channel with 16 kbit/s) BB Base Band module BC Broadcast BCC Broadcast Call Control (3GTS 44.069) BCC Base Station Color Code BCCH Broadcast Control Channel (UMTS Logical Cannel) BCCH Broadcast Control Channel (GSM Logical Channel) BCD Binary Coded Decimal BCH Broadcast Channel (UMTS Transport Channel) BCMCS Broadcast and Multicast Services (CDMA-2000 Rev. D) BCTP Bearer Control Tunneling Protocol (ITU-T Q.1990) BE Best Effort

BEC Backward Error Correction BEG BEGin Message (TCAP) BER Bit Error Rate BFCP Binary Floor Control Protocol (draft-ietf-xcon-bfcp-05) BFI Bad Frame Indication BG Border Gateway BGCF Breakout Gateway Control Function BIB Backward Indicator Bit BIC Blind Interference Cancellation BICC Bearer Independent Call Control (ITU-T Q.1902.1 -

Q.1902.6) BLER Block Error Rate BMC Broadcast / Multicast Control (3GTS 25.324) BM-IWF Broadcast Multicast Interworking Function BM-SC Broadcast Multicast Service Center (3GTS 23.346) BNF Backus Naur Form (RFC 2234) BPSK Binary or Bipolar Phase Shift Keying BQA Bluetooth Qualification Administer BQB Bluetooth Qualification Body BQRB Bluetooth Qualification Review Board BQTF Bluetooth Qualification Test Facility BR Bandwidth Request (WIMAX Term) BRAN Broadband Radio Access Network BS Base Station (IEEE 802.16) BS_CV_MAX Maximum Countdown Value to be used by the mobile

station (Countdown Procedure) BS_EIRP Base Station Effective Isotropic Radiated Power BSC Base Station Controller




BSIC Base Station Identity Code BSN Block Sequence Number (RLC) / Backward Sequence

Number (SS7) BSS Base Station Subsystem BSSAP Base Station Subsystem Application Part BSSAP-LE Base Station System Application Part - Location Based

Services Extension BSSGP Base Station System GPRS Protocol BSSMAP Base Station Subsystem Mobile Application Part (3GTS

48.008) BTAB Bluetooth Technical Advisory Board BTC Block Turbo Coding BTS Base Transceiver Station BVCI BSSGP Virtual Connection Identifier BW Bandwidth C/I Carrier-to-Interference Ratio (like SNR) C/R-Bit Command / Response Bit C/T-Field logical Channel / Transport channel identification Field CAI Channel Assignment Indicator CAMEL Customized Applications for Mobile network Enhanced

Logic CAN Connectivity Access Network CAP CAMEL Application Part (CCS7) CAPEX Capital Expenditure CATV Cable TV CBC Cipher Block Chaining (DES-Operation Mode) CBC Cell Broadcast Center CBC Committed Burst Size CBCH Cell Broadcast Channel (GSM)

CBMS Convergence of Broadcast and Mobile Services CC Call Control CC Convolutional Coding CCC CPCH Control Command CCCH Common Control Channel (UMTS Logical Channel) CCCH Common Control Channel (GSM Logical Channel) CCF Charging Collection Function CCH Control Channel CCITT Comitéonsultatif International Tégraphique et

Téphonique (International Telegraph and Telephone Consultative Committee)

CCM Common Channel Management (Protocol Part on the GSM Abis-Interface / 3GTS 48.058)

CCM-Mode Counter with CBC-MAC (RFC 3610) Combined Authentication and Encryption with AES-Algorithm

CCN Cell Change Notification (related to Network Assisted Cell Change / 3GTS 44.060)

CCPCH Common Control Physical Channel (see also P-CCPCH and S-CCPCH)

CCS7 Common Channel Signaling System No. 7 (ITU-T Q-series of specifications, in particular Q.700 - Q.703)

CCTrCH Coded Composite Transport Channel (UMTS) CCU Channel Codec Unit CD Compact Disc CD/CA-ICH Collision Detection / Channel Assignment Indicator

Channel (UMTS Physical Channel) CDCH Control-plane Dedicated Channel (3GTS 45.902) CDI Collision Detection Indicator CDMA Code Division Multiple Access




CDR Call Detail Record CELL_DCH RRC Dedicated State CEPT Conférence Européne des Postes et Técommunications CESoP Circuit Emulation Services over Packet CFN Connection Frame Number CG Charging Gateway CGF Charging Gateway Function CGI Cell Global Identification CHAP Challenge Handshake Authentication Protocol (RFC

1334) CIC Circuit Identity Code (ISUP) CIC Call Instance Code (BICC) CID Channel Identity (ATM) CID Connection Identifier (WIMAX) CIDR Classless Inter-Domain Routing (RFC 1519) CIF Common Intermediate Format (352 x 240 pixels / ITU-T

H261 / H263) CINR Carrier to Interference and Noise Ratio CIO Cell Individual Offset (3GTS 25.331) CIR Committed Information Rate CK Ciphering Key (3GTS 33.102) CKSN Ciphering Key Sequence Number CMC Codec Mode Command CMI Codec Mode Indication CMIP Client Mobile IP CMR Codec Mode Request CMTS Cable Modem Termination System CN Core Network

CNR Carrier to Noise Ratio COA Change Over Acknowledge message (CCS7) CoA Care of Address (MIP) COFDM Coded Orthogonal Frequency Division Multiplexing CON CONtinue Message (TCAP) COO Change Over Order message (CCS7) COPS Common Open Policy Service Protocol (RFC 2748) CPCH Common Packet Channel (UMTS Transport Channel)

FDD only CPCS Common Part Convergence Sublayer CPE Customer Premises Equipment CPICH Common Pilot Channel (UMTS Physical Channel / see

also P-CPICH and S-CPICH) CPICH_Ec/No Common Pilot Channel Energy per Chip to Noise Radio CPIM Common Presence and Instant Messaging (RFC 3862) CPS Coding and Puncturing Scheme CPS Common Part Sublayer CPU Central Processing Unit CQI Channel Quality Indicator (3GTS 25.214) CQICH Channel Quality Indicator Channel CRC Cyclic Redundancy Check CRNC Controlling RNC CRSC Contributing Source CS Coding Scheme CS Circuit Switched CS Class Selector (DiffServ Term / RFC 2474) CS Convergence Sublayer C-SAP Control Service Access Point




CSCF Call Session Control Function (SIP) CSD Circuit Switched Data CSICH CPCH Status Indicator Channel (UMTS Physical

Channel) CSMA-CA Carrier-Sense Multiple Access - Collision Avoidance CSN Connectivity Service Network CSPDN Circuit Switched Public Data Network CS-X Coding Scheme (1 - 4) CTC Convolutional Turbo Coding CTCH Common Traffic Channel (Logical) PTM CTFC Calculated Transport Format Combination (3GTS

25.331) CV Countdown Value CW Code Word cwnd Congestion window DAB Digital Audio Broadcasting DARP Downlink Advanced Receiver Performance (3GPP's

adaptation of SAIC / 3GTS 45.015, 3GTS 24.008) DASS Digital Access Signaling System DBC Dynamic Bearer Control dBm The unit dBm measures a power. The conversion of a

power value from Watt [W] to dBm is done in the following way:X [dBm] = 10 x log10(X [W] / 0.001 [W])

DBP Diameter Base Protocol (RFC 3588) DBPSCH Dedicated Basic Physical SubCHannel DC Direct Current DCCH Dedicated Control Channel (UMTS Logical Channel) DCD Downlink Channel Descriptor (WIMAX Message) DCF DRM Content Format

DCH Dedicated Channel (Transport) DCM Dedicated Channel Management (Protocol Part on the

GSM Abis-Interface / 3GTS 48.058) DCS Digital Communication System DDDS Dynamic Delegation Discovery System (RFC 3401 -

RFC 3404) DDI Data Description Indicator (3GTS 25.309, 25.331) DEC Decision (COPS message type) DEMUX De-Multiplexer DES Data Encryption Standard DF Do not Fragment (bit in IPv4 header) DF Default Forwarding (DiffServ Term / RFC 2474) DHCP Dynamic Host Configuration Protocol (RFC 2131) DIA Diameter Protocol (RFC 3588, RFC 3589) Digit 4 bit DIUC Downlink Interval Usage Code (WIMAX Term) DL Downlink DLCI Data Link Connection Identifier DLFP Downlink Frame Prefix DL-MAP Downlink-Medium Access Protocol (MAC-Message in

WIMAX / IEEE 802.16) DLR Destination Local Reference (SCCP term) DLS Downloadable Sounds DMB Digital Multimedia Broadcasting DNS Domain Name System DOCSIS Data Over Cable Service Interface Specification

(defined by CableLabs) DoS Denial of Service attack DPC Destination Point Code




DPCCH Dedicated Physical Control Channel (UMTS Physical Channel)

DPCH Dedicated Physical Channel (UMTS / Term to combine DPDCH and DPCCH)

DPDCH Dedicated Physical Data Channel (UMTS Physical Channel)

DPNSS Digital Private Network Signaling System DPSK Differential Phase Shift Keying DRM Digital Rights Management DRNC Drift Radio Network Controller DRX Discontinuous Reception DSCA Diversity / Distributed Subcarrier Allocation DS-CDMA Direct Sequence Code Division Multiple Access DSCH Downlink Shared Channel (UMTS Transport Channel) DSCP Differentiated Services Code Pointer DSL Digital Subscriber Line DSLAM Digital Subscriber Line Access Multiplexer DSM-CC Digital Storage Media Call Control DSN Digital Switching Network DSP Digital Signal Processor DSS1 Digital Subscriber Signaling System No.1 (also referred

to as LAPD-signaling / ITU-T Q.931) DSSS Direct Sequence Spread Spectrum DT1 Data Form 1 (SCCP message type) DTAP Direct Transfer Application Part DTCH Dedicated Traffic Channel (UMTS Logical Channel) DTM Dual Transfer Mode (3GTS 43.055) DTX Discontinuous Transmission DUA DPNSS 1 / DASS 2 User Adaptation Layer (RFC 4129)

DVB Digital Video Broadcasting DVB-C Digital Video Broadcasting - Cable TV DVB-H Digital Video Broadcasting - Handheld DVB-S Digital Video Broadcasting - Satellite DVB-T Digital Video Broadcasting - Terrestrial e2e End-to-End E-AGCH E-DCH Absolute Grant Channel (3GTS 25.211) EAP Extensible Authentication Protocol (RFC 3748) EAP-AKA Extensible Authentication Protocol method for 3rd

generation Authentication and Key Agreement (RFC 4187)

EAPOL EAP encapsulation Over Lan or wlan (IEEE 802.1X) EAP-SIM Extensible Authentication Protocol method for gsm

Subscriber Identity Module (RFC 4186) EAP-TLS Extensible Authentication Protocol - Transport Layer

Security (RFC 2716) EAP-TTLS Extensible Authentication Protocol - Transport Layer

Security (draft-funk-eap-ttls-v0-01.txt) Ec/No Received energy per chip / power density in the band ECN Explicit Congestion Notification ECSD Enhanced Circuit Switched Data (HSCSD + EDGE) E-DCH Enhanced Uplink Dedicated Transport Channel (3GTS

25.211, 25.309) E-DCH-FP E-DCH Frame Protocol (Enhanced Dedicated Channel) EDGE Enhanced Data Rates for Global Evolution E-DPCCH Enhanced Uplink Dedicated Physical Control Channel

(3GTS 25.211) E-DPDCH Enhanced Uplink Dedicated Physical Data Channel

(3GTS 25.211)




EDR Enhanced Data Rate (more speed with Bluetooth 2.0 (2.0 - 3.0 Mbit/s)

EF Expedite Forwarding (DiffServ Term) EFR Enhanced Full Rate speech codec EGPRS Enhanced General Packet Radio Service E-GSM Extended GSM (GSM 900 in the Extended Band) E-HICH E-DCH HARQ Acknowledgement Indicator Channel

(3GTS 25.211) EIA Electronic Industries Alliance (US-organization to

support US industry) EIR Equipment Identity Register EIRENE European Integrated Railway Radio Enhanced Network

(GSM-R) eMLPP enhanced Multi-Level Precedence and Pre-emption

(3GTS 23.067) EMSK Extended Master Session Key END END Message (TCAP) ENUM E.164-telephone number to URI (Uniform Resource

Identifier) translation (RFC 3761) E-OTD Enhanced Observed Time Difference E-RGCH E-DCH Relative Grant Channel (3GTS 25.211) E-RNTI E-DCH Radio Network Temporary Identifier (3GTS

25.401) ertPS Extended Real-Time Polling Service (IEEE 802.16

Traffic Class) ert-PS Extended Real-Time Polling Service (WIMAX Traffic

Class) ESG Electronic Service Guide ES-Id Encoding Symbol-Id ESN Electronic Serial Number (North American Market)

ESP Encapsulating Security Payload (RFC 4303) E-TFC E-DCH Transport Format Combination (3GTS 25.309) E-TFCI E-DCH Transport Format Combination Identifier

(Enhanced Dedicated Channel) Ethernet Layer 2 Protocol for IP (IEEE 802.3) ETSI European Telecommunications Standard Institute EUL Enhanced Uplink E-UTRA Evolved UMTS Terrestrial Radio Access EV-DO Evolution Data Only or Evolution Data Optimized

(cdma2000) EV-DV Evolution Data/Voice (cdma2000) EVM Error Vector Magnitude FA Foreign Agent (Mobile IP / RFC 3344) FACCH Fast Associated Control Channel (GSM) FACH Forward Access Channel (UMTS Transport Channel) FBI Feedback Information (UMTS) FBI Final Block Indicator FBSS Fast Base Station Switching FCC Federal Communications Commission FCCH Frequency Correction Channel (GSM) FCH Frame Control Header FCS Frame Check Sequence (CRC-Check) FDD Frequency Division Duplex FDDI Fiber Distributed Data Interconnect (optical Layer 2) FDM Frequency Division Multiplexing FDMA Frequency Division Multiple Access F-DPCH Fractional Dedicated Physical Channel (3GTS 25.211) FDT File Delivery Table




FEC Forward Error Correction FER Frame Error Rate FFH Fast Frequency Hopping FFRS Fractional Frequency Reuse Scheme FFT Fast Fourier Transformation FH-CDMA Frequency Hopping Code Division Multiple Access FIB Forward Indicator Bit FIPS Federal Information Processing Standard FISU Fill In Signal Unit FLO Flexible Layer 1 (3GTS 45.902) FLUTE File Delivery over Unidirectional Transport (RFC 3926) FM Frequency Modulation FMC Fixed Mobile Convergence FN Frame Number FP Frame Protocol FPB First Partial Bitmap FQDN Fully Qualified Domain Name. Fully qualified domain

names consist of a host and a domain name whereas the domain name needs to include a top-level domain (e.g. 'de' or 'org'). Examples: 'www.inacon.de' and 'PC10.inacon.com' are fully qualified domain names. 'www' and 'PC10' represent the host, 'inacon' is the second-level domain, 'de' and 'com' are the top level domain.

FR Fullrate or Frame Relay FRMR Frame Reject FRS Frequency Reuse Scheme FSN Forward Sequence Number FTP File Transfer Protocol (RFC 959)

FUSC Full Usage of Subchannels FWA Fixed Wireless Access GA Generic Access (3GTS 43.318) GAA Generic Authentication Architecture (3GTS 33.220) GA-CSR Generic Access - Circuit-Switched Resources (3GTS

43.318) GAN Generic Access Network GANC Generic Access Network Controller (3GTS 43.318) GA-PSR Generic Access - Packet-Switched Resources (3GTS

43.318) GA-RC Generic Access - Resource Control (3GTS 43.318) GBA Generic Bootstraping Architecture (3GTS 33.220) GBR Guaranteed Bit Rate Service GCC Generic Call Control GCF General Certification Forum GEA GPRS Encryption Algorithm GERAN GSM EDGE Radio Access Network GGSN Gateway GPRS Support Node GHz Giga Hertz (109 Hertz) GIF Graphics Interchange Format GK Gatekeeper GMLC Gateway Mobile Location Center GMM GPRS Mobility Management GMSC Gateway MSC G-MSC Gateway MSC GMSC-S Gateway MSC Server GMSK Gaussian Minimum Shift Keying GNU recursive acronym for GNU is Not Unix. Today a




synonym for free Sourcecode Software. GPCS Generic Packet Convergence Sublayer (IEEE 802.16) G-PDU T-PDU + GTP-Header GPRS General Packet Radio Service GPRS-CSI GPRS CAMEL Subscription Information GPRS-SSF GPRS Service Switching Function (CAMEL) GPS Global Positioning System GRA GERAN Registration Area GRE Generic Routing Encapsulation (RFC 2784) G-RNTI GERAN Radio Network Temporary Identifier GRX GPRS Roaming Exchange (GSM-Association IR.34) GSM Global System for Mobile Communication GSM-R GSM for Railways GSMS GPRS Short Message Service GSN GPRS Support Node GTP GPRS Tunneling Protocol (3GTS 29.060) GTP-C GTP Control Plane GTP-U GTP User Plane GTT Global Title Translation (ITU-T Q.714 (2.4)) GTTP GPRS Transparent Transport Protocol (3GTS 44.018) GUP Generic User Profile GW Gateway GZIP GNU ZIP (compression format) HA Home Agent (Mobile IP / RFC 3344) HARQ Hybrid ARQ HB Heartbeat HCS Hierarchical Cell Structure HDB3 High Density Bipolar Three (Line Coding used for E1

(PCM 30) HDLC High level Data Link Control HDTV High Definition Television HFC Hxbrid Fiber Cable (relates to the layer 1 of CableTV-

operators) HFC-Network Hybrid Fiber- / Coaxial-cable HIPERLAN/2 High Performance Radio Local Area Network type 2 HLR Home Location Register HMAC Keyed Hashing for Message Authentication (RFC 2104) HO Handover HoA Home Address H-PLMN Home PLMN HR Halfrate H-RNTI HS-DSCH Radio Network Transaction Identifier (3GTS

25.331, 25.433) HS High Speed HSCSD High Speed Circuit Switched Data HSDPA High Speed Downlink Packet Access (3GTS 25.301,

25.308, 25.401, 3GTR 25.848) HS-DPCCH High Speed Dedicated Physical Control Channel (3GTS

25.211) HS-DSCH High Speed Downlink Shared Transport Channel

(3GTS 25.211, 25.212, 25.308) HSPA High Speed Packet Access (operation of HSDPA and

HSUPA) HS-PDSCH High Speed Physical Downlink Shared Channel (3GTS

25.211) HSS Home Subscriber Server (3GTS 23.002). HSS replaces

the HLR with 3GPP Rel. 5




HS-SCCH High Speed Shared Control Channel (3GTS 25.211, 25.214)

HSUPA High Speed Uplink Packet Access (3GTS 25.301, 25.309, 25.401, 3GTR 25.896)

HTTP HyperText Transfer Protocol (RFC 2616) HTTPS Hypertext Transfer Protocol Secure HUMAN High-speed Unlicensed Metropolitan Area Network I+S Information + Supervisory IAM Initial Address Message (ISUP ISDN User Part) IANA Internet Assigned Numbers Authority IBS Integrated Base Station ICANN Internet Corporation for Assigned Names and Numbers ICH Indicator Channel (UMTS Physical Channel / see also

PICH, AICH, CD/CA-ICH) ICM Initial Codec Mode ICMP Internet Control Message Protocol (RFC 792) ICS Implementation Conformance Statement I-CSCF Interrogating Call Session Control Function (SIP) ID Identity IDNNS Intra-Domain NAS Node Selector IE Information Element IEC International Electrotechnical Commission IEEE Institute of Electrical and Electronics Engineers IETF Internet Engineering Task Force (www.ietf.org) IFFT Inverse Fast Fourier Transformation IGMP Internet Group Multicast Protocol (RFC 1112, RFC

2236) IHOSS Internet Hosted Octet Stream Service IK Integrity Key (3GTS 33.102)

IKE Internet Key Exchange (RFC 2409) IKEv2 Internet Key Exchange protocol / version 2 (RFC 4306) IKMP Internet Key Management Protocol iLBC Internet Low Bitrate Codec (RFC 3951 / RFC 3952) ILCM Incoming Leg Control Model IM Instant Messaging IMEI International Mobile Equipment Identity IMPI IP Multimedia Private Identity; the private user identity

of an IMS-subscriber, formatted as an NAI (3GTS 33.203)

IMPU IP Multimedia Public Identity; the public user identity of an IMS-subscriber, formatted as SIP-URI or TEL-URI (3GTS 33.203)

IMS Internet Protocol Multimedia Core Network Subsystem (Rel. 5 onwards)

IMS-AG IMS-Access Gateway IMSI International Mobile Subscriber Identity IMS-SSF IP Multimedia Subsystem - Service Switching Function IMT-2000 International Mobile Telecommunications for the year

2000 IN Intelligent Networking INAP Intelligent Network Application Part (CCS7) IOV-I / IOV-UI Input Offset Variable for I+S and UI-Frames (for

ciphering in GPRS) IP Internet Protocol (RFC 791) IPBCP IP Bearer Control Protocol (ITU-T Q.1970) IP-CAN Internet Protocol - Connectivity Access Network (e.g.

DSL, TV-Cable, WIMAX, UMTS) IPCP Internet Protocol Control Protocol (RFC 1332)




IP-CS IP-Convergence Sublayer IPDC IP Datacast IPDV IP-packet delay variation (ITU-T Y.1540) IPER IP-packet error ratio (ITU-T Y.1540) IPLR IP-packet loss ratio (ITU-T Y.1540) IPsec Internet Protocol / secure (RFC 4301) IPTD IP-packet transfer delay (ITU-T Y.1540) IPv4 Internet Protocol (version 4) IPv6 Internet Protocol (version 6) IR Incremental Redundancy (ARQ II) IS Interim Standard (ASNI Standard) ISAKMP Internet Security Association and Key Management

Protocol (RFC 2408) ISC IP multimedia subsystem Service Control-Interface ISCP Interference Signal Code Power (3GTS 25.215 / 3GTS

25.102) ISDB Integrated Services Digital Broadcasting ISDN Integrated Services Digital Network ISI Inter-Symbol Interference ISIM IMS capable Subscriber Identity Module ISM Industrial, Scientific and Medical (term for license-free

frequencies) ISO International Standardization Organization ISP Internet Service Provider ISPC International Signaling Point Code (ITU-T Q.708) ISUA ISDN User Adaptation Layer ISUP ISDN User Part (ITU-T Q.761 - Q.765) IT Information Technology

ITU International Telecommunication Union ITU-R International Telecommunication Union -

Radiocommunications ITU-T International Telecommunication Union -

Telecommunication Sector IUA ISDN Q.921 User Adaptation Layer (RFC 4233) Iub-FP Iub-Frame Protocol (3GTS 25.427 / 25.435) Iu-FP Iu-Frame Protocol (3GTS 25.415) Iur-FP Iur-Frame Protocol (3GTS 25.424, 3GTS 25.425,

25.426, 25.435) IUT Implementation under Test I-WLAN Interworking WLAN (Wireless Local Area Network)

(3GTS 23.234) JD Joint Detection JPEG Joint Picture Expert Group kbps kilo-bits per second KEK Key Encryption Key (IEEE 802.16) KHz Kilo Hertz (103 Hertz) L1 Layer 1 (physical layer) L2 Layer 2 (data link layer) L2TP Layer 2 Tunneling Protocol (RFC 2661) L3 Layer 3 (network layer) LA Location Area LAC Location Area Code LAI Location Area Identification (LAI = MCC + MNC + LAC) LAN Local Area Network LAPB Link Access Procedure Balanced LAPD Link Access Protocol for the ISDN D-Channel LAPV5 Link Access Protocol for V5-interface




LBS Location Based Service LCP Link Control Protocol (PPP) LCS LoCation Service LCT Layered Coding Transport LDAP Lightweight Directory Access Protocol (RFC 3928) LDPC Low Density Parity Check LE Lower Effort PDB (DiffServ Term) LER Label Edge Router (MPLS) LEX Local Exchange Carrier LI Length Indicator LLC Logical Link Control-Protocol LMDS Local Multipoint Distribution Services LMMSE Linear Minimum Mean Square Error receiver LMU Location Measurement Unit LOS Line Of Sight LPD Link Protocol Discriminator LR Location Register LSB Least Significant Bit LSP Label Switched Path (MPLS) LSR Label Switch Router (MPLS) LSSU Link Status Signal Unit LTE Long Term Evolution (of UMTS) M2PA MTP-2 user Peer-to-Peer Adaptation Layer (RFC 4165) M2UA MTP-2 User Adaptation Layer (RFC 3331) M3UA MTP-3 User Adaptation Layer (RFC 4666) MAC Message Authentication Code MAC Medium Access Control MAC-d Medium Access Control for the Dedicated Transport

Channel (3GTS 25.321) MAC-e MAC-E-DCH (3GTS 25.321) MAC-es MAC-E-DCH SRNC (3GTS 25.321) MAC-hs MAC-High Speed (3GTS 25.321) MAN Metropolitan Area Network MAP Mobile Application Part (3GTS 29.002) MAP-B Mobile Application Part - B-interface protocol between

MSC and VLR MAP-X Mobile Application Part - various interface protocols like

B-, C-, D-, E-, F- or G-interface MASF Minimum Available Spreading Factor Max [X, Y] The value shall be the maximum of X or Y, which ever

is bigger MBMS Multimedia Broadcast / Multicast Service (3GTS

23.246, 3GTS 43.846) MBS Multicast Broadcast Services MBSAT Mobile Broadcast Satellite MBWA Mobile Broadband Wireless Access (IEEE 802.20

Specification of physical and medium access control layers of an air interface for interoperable mobile broadband wireless access systems, operating in licensed bands below 3.5 GHz, optimized for IP-data transport, with peak data rates per user in excess of 1 Mbps. It supports various vehicular mobility classes up to 250 Km/h in a MAN environment and targets spectral efficiencies, sustained user data rates and numbers of active users that are all significantly higher than achieved by existing mobile systems)

MBZ Must Be Zero MCC Mobile Country Code MCCH MBMS point-to-multipoint Control Channel




Mcps Mega Chip Per Second MCS Modulation and Coding Scheme MCS-X Modulation and Coding Scheme (1 - 9) and for HSDPA

/ HSUPA MCU Multipoint Control Unit (H.323 equipment) MD Message Digest algorithm (e.g. MD-5) MDHO Macro-Diversity Handover MD-X Message Digest Algorithm (MD-2, 4, 5 are defined)

(MD-5 RFC 1321) ME Mobile Equipment (ME + SIM = MS) MEGACO Media Gateway Control Protocol (ITU-T H.248 incl.

Annex F - H and IETF RFC 3015) MExE Mobile Station Application Execution Environment MGC Media Gateway Controller MGCF Media Gateway Control Function MGCP Media Gateway Control Protocol (RFC 2705) MGW Media Gateway MHP Multimedia Home Platform MHz Mega Hertz (106 Hertz) MIB Management Information Base MICH MBMS Notification Indicator Channel MIDI Musical Instrument Digital Interface MIH Media Independent Handover (IEEE 802.21) MIKEY Multimedia Internet KEYing (RFC 3830) MIME Multipurpose Internet Mail Extensions MIMO Multiple In / Multiple Out (antenna system) MIN Mobile Identity Number (North American Market) Min [X, Y] The value shall be the minimum of X or Y, which ever is

smaller

MINA Mobile Internet Network Architecture MIP Mobile IP (RFC 2002, 3344, 3775) MISO Multiple In / Single Out (antenna system) MitM Man in the Middle (attack) MLD Multicast Listener Discovery (RFC 2710) MLP MAC Logical Channel Priority MLPP Multi-Level Precedence and Pre-emption (ITU-T Q.85 /

Clause 3) MM Mobility Management MMCC Multimedia Call Control MMD IP Multimedia Domain (name of the IMS in 3GPP2) MMDS Multipoint Microwave Distribution System or Multi-

channel Multi-point Distribution System MMS Multimedia Messaging Service (3GTS 22.140, 3GTS

23.140) MNC Mobile Network Code MNRG Mobile Not Reachable for GPRS flag MOBIKE IKEv2 Mobility and Multihoming Protocol (RFC 4555) MOC Mobile Originating Call MP3 MPEG-1 Audio Layer 3 MPCC Multiparty Call Control MPE Multi Protocol Encapsulation (DVB-H) MPEG Motion Picture Expert Group MPEG2-TS MPEG-2 Transport Stream (DVB) MPLS Multi Protocol Label Switching MPRACH MBMS Packet Random Access Channel ((E)GPRS) MRC Maximum Ratio Combining MRF Multimedia Resource Function




MRFC Multimedia Resource Function Controller MRFP Multimedia Resource Function Processor MRU Maximum Receive Unit (PPP) MRW Move Receiving Window MS Mobile Station MS Mobile Subscriber Station (IEEE 802.16e) MSB Most Significant Bit MSC Mobile Services Switching Center MSCH MBMS point-to-multipoint Scheduling Channel MSC-S MSC-Server MS-ISDN Mobile Subscriber - International Service Directory

Number MSK Master Session Key MSRD Mobile Station Receive Diversity MSRN Mobile Station Roaming Number MSRP Message Session Relay Protocol (draft-ietf-simple-

message-sessions-XX) MSS Maximum Segment Size (TCP) MSU Message Signal Unit MT Mobile Terminal or Mobile Terminating MTC Mobile Terminating Call MTCH MBMS point-to-multipoint Traffic Channel MTK MBMS Traffic Key MTP Message Transfer Part (ITU-T Q.701 - Q.709) MTP-3b Message Transfer Part level 3 / broadband (ITU-T

Q.2210) MTU Maximum Transmit Unit (IP) MUD Multi-User-Detection unit

MUX Multiplex MVNO Mobile Virtual Network Operator NACC Network Assisted Cell Change (3GTS 44.060) NACK Negative Acknowledgement NAF Network Application Function (part of the Generic

Authentication Architecture (GAA)) NAI Network Access Identifier (RFC 2486) NAP Network Access Provider NAPT Network Address Port Translation (RFC 3022) NAPTR Naming Authority Pointer (RFC 2915) NAS Non-Access-Stratum (UMTS) NASS Network Attachment SubSystem (part of the TISPAN

NGN-architecture) NAT Network Address Translation (RFC 1631) NBAP NodeB Application Part (3GTS 25.433) NBNS NetBios Name Service NC Neighbor Cell NCC Network Color Code NCP Network Control Protocol (PPP) NGN Next Generation Networks NI Network Indicator NIC Network Interface Card NLOS Non Line Of Sight NMT Nordic Mobile Telephone (analog cellular standard,

mainly used in Scandinavia) NNI Network-to-Network Interface NPB Next Partial Bitmap N-PDU Network-Protocol Data Unit (IP-Packet, X.25-Frame)




NRI Network Resource Identifier NS Network Service NSAP Network Service Access Point NSAPI Network Service Access Point Identifier N-SAW N-Channel Stop and Wait (3GTS 25.309, 3GTR 25.848) NSE Network Service Entity NSF NAS Node Selection function NSIS Next Steps in Signaling (RFC 4080) NSLP NSIS Signaling Layer Protocol (e.g. for resource

reservation) NSP Network Service Provider NSPC National Signaling Point Code NSS Network Switching Subsystem NS-VC Network Service - Virtual Connection NS-VCG Network Service - Virtual Connection Group NS-VL Network Service - Virtual Link NT Network Termination NTSC National Television System Committee (video standard

for North America) NWG Network Working Group (WIMAX Forum) O&M Operation and Maintenance Octet 8 bit OFDM Orthogonal Frequency Division Multiplexing OFDMA Orthogonal Frequency Division Multiple Access OFUSC Optional FUSC (Full Usage of Subchannels) OLCM Outgoing Leg Control Model OMA Open Mobile Alliance

(http://www.openmobilealliance.org/)

OMAC One-Key CBC-MAC (NIST standard: SP 800-38B and http://csrc.nist.gov/CryptoToolkit/modes/proposedmodes/)

OMAP Operation & Maintenance Application Part OMC Operation and Maintenance Center OoBTC Out of Band Transcoder Control (3GTS 23.153) OPC Originating Point Code OPEX Operational Expenditure OPUSC Optional PUSC (Partial Usage of Subchannels) OPWA One Pass With Advertising (Term in RSVP) OSA Open Service Access OSA-SCS Open Service Access - Service Capability Server OSCP Online Certificate Status Protocol (RFC 2560) OSI Open System Interconnection OSP Octet Stream Protocol OTDOA Observed Time Difference Of Arrival OVSF Orthogonal Variable Spreading Factor P/F-Bit Polling/Final - Bit P/S Parallel to Serial PA Presence Agent (RFC 3856) PABX Private Automatic Branch Exchange PACCH Packet Associated Control Channel ((E)GPRS) PACS Personal Access Communication System PAD Packet Assembly Disassembly PAGCH Packet Access Grant Channel ((E)GPRS) PAL Phase Alternating Line PAP Password Authentication Protocol (RFC 1334) PAPR Peak-to-Average Power Ratio




PAT Program Assocation Table (MPEG2-TS) PBCCH Packet Broadcast Control Channel ((E)GPRS) PBS Peak Burst Size PC Protocol Class (SCCP) PC Paging Controller PCCCH Packet Common Control Channel ((E)GPRS) PCCH Paging Control Channel (UMTS Logical Channel) P-CCPCH Primary Common Control Physical Channel (UMTS /

used as bearer for the BCH TrCH) PCH Paging Channel (UMTS / Transport Channel) PCH Paging Channel (GSM / Logical Channel) PCI Peripheral Component Interconnect (computer bus

standard to interconnect peripherals to the CPU) PCM Pulse Code Modulation PCN Personal Communication Network PCPCH Physical Common Packet Channel (UMTS Physical

Channel) P-CPICH Primary Common Pilot Channel (UMTS Physical

Channel) PCS Personal Communication System P-CSCF Proxy Call Session Control Function (SIP) PCU Packet Control Unit PD Protocol Discriminator PDA Personal Digital Assistant PDB Per Domain Behavior (DiffServ Term) PDBF Profile DataBase Function (TISPAN term / ETSI ES 282

004) PDC Personal Digital Communication (ARIB-Standard) PDCH Packet Data Channel ((E)GPRS)

PDCP Packet Data Convergence Protocol (3GTS 25.323) PDF Policy Decision Function (Part of the IP Multimedia

Subsystem) PDG Packet Data Gateway PDH Plesiochronous Digital Hierarchy PDN Packet Data Network PDP Packet Data Protocol PDS Packet Data Subsystem (3GPP2) PDSCH Physical Downlink Shared Channel (UMTS Physical

Channel) PDSN Packet Data Support Node (the SGSN in 3GPP2) PDTCH Packet Data Traffic Channel ((E)GPRS) PDU Protocol Data Unit or Packet Data Unit PEAP Protected Extensible Authentication Protocol PEP Policy Enforcement Point (3GTS 23.209) PER Packed Encoding Rules (ITU-T X.691) PES PSTN/ISDN Emulation Subsystem (part of the TISPAN

NGN-architecture) PES Packetised Elementary Stream (DVB) PFC Packet Flow Context PFI Packet Flow Identifier PHB Per Hop Behavior (DiffServ Term) PHS Payload Header Suppression (IEEE 802.16) PHS Personal Handy phone System PHY Physical Layer PHz Peta Hertz (1015 Hertz) PICH Page Indicator Channel (UMTS Physical Channel) PICMG PCI (Peripheral Component Interconnect) Industrial

Computer Manufacturers Group (http://www.picmg.org/)




PICS Protocol Implementation Conformance Statement PID Packet Identifier (MPEG2-TS) PIDF Presence Information Data Format (RFC 3863) PIR Peak Information Rate PIXIT Protocol Implementation Extra Information for Testing PKCS Public Key Cryptography Standard PKMv2 Privacy Key Management Version 2 PLC Power Line Communications PLMN Public Land Mobile Network PMIP Proxy Mobile IP PMM Packet Mobility Management PMT Program Map Table (MPEG2-TS) PMTU Path MTU PN Pseudo Noise PNCH Packet Notification Channel ((E)GPRS) PNG Portable Network Graphics PoC Push to talk over Cellular (3GTR 29.979 and various

OMA-specifications) PoE Power over Ethernet POP Post Office Protocol (RFC 1939) POTS Plain Old Telephone Service PPCH Packet Paging Channel ((E)GPRS) PPP Point-to-Point Protocol (RFC 1661) PRA PCPCH Resource Availability PRACH Physical Random Access Channel UMTS PRACH Packet Random Access Channel ((E)GPRS) PRACK Provisional Response Acknowledgement (SIP-method

type)

PRD Bluetooth Qualification Program Reference Document PRF Pseudo Random Function PRI Primary rate access ISDN-user interface for PABX's (23

or 30 B-channels plus one D-Channel) PS Physical Slot (IEEE 802.16) PS Puncturing Scheme PS Program Stream PS Packet Switched PSC Primary Synchronization Code or Primary Scrambling

Code (both used in UMTS) P-SCH Primary Synchronization Channel (physical) PSD Power Spectral Density (3GTS 25.215 / 3GTS 25.102) PSI Program Specific Information (MPEG2-TS) PSK Phase Shift Keying PSPDN Packet Switched Public Data Network PSTN Public Switched Telephone Network PT Protocol Type (GTP or GTP') PTCCH Packet Timing Advance Control Channel ((E)GPRS) PTCCH/D Packet Timing Advance Control Channel / Downlink

Direction ((E)GPRS) PTCCH/U Packet Timing Advance Control Channel / Uplink

Direction ((E)GPRS) PTM Point to Multipoint P-TMSI Packet TMSI PTP Point to Point PTT Post, Telephone & Telegraph (abbreviation for the

former government owned organizations that were responsible for all three services)

PUA Presence User Agent (RFC 3856)




PUSC Partial Usage of Subchannels PVC Permanent Virtual Circuit QAM Quadrature Amplitude Modulation QCIF Quarter Common Intermediate Format (176 x 144

pixels ITU-T H261 / H263) QE Quality Estimate QoS Quality of Service QPSK Quadrature Phase Shift Keying (3GTS 25.213) QSIG Q-interface signaling protocol RA Routing Area RAA RE-Auth-Answer command (Diameter BASE, RFC

3588) RAB Radio Access Bearer RAC Routing Area Code RACH Random Access Channel (UMTS Transport Channel) RACH Random Access Channel (GSM) RACS Resource and Admission Control Subsystem (part of

the TISPAN NGN-architecture) RADIUS Remote Authentication Dial In User Service (RFC 2865) RAI Routing Area Identification RAN Radio Access Network RANAP Radio Access Network Application Part (3GTS 25.413) RAND Random Number RAR RE-Auth-Request command (Diameter BASE, RFC

3588) RAT Radio Access Technology (e.g. GERAN, UTRAN, ...) RATSCCH Robust AMR Traffic Synchronized Control CHannel RB Receive Block Bitmap (EGPRS) RB Radio Bearer

RBB Receive Block Bitmap (GPRS) RBPSCH Shared Basic Physical SubCHannel RED Random Early Detection REJ Reject REQ Request (COPS message type) RES Response RF Radio Frequency RFC Request for Comments (Internet Standards) RFID Radio Frequency Identification RG Relative Grant (3GTS 25.309) R-GSM Railways-GSM RL Radio Link (3GTS 25.433) RLC Radio Link Control (UMTS 3GTS 25.322) RLC Radio Link Control ((E)GPRS / 3GTS 04.60 / 3GTS

44.060) RLM Radio Link Management (Protocol Part on the GSM

Abis-Interface / 3GTS 48.058) RLP Radio Link Protocol (3GTS 24.022) RLS Radio Link Set (3GTS 25.309, 25.433) RNC Radio Network Controller RNL Radio Network Layer RNR Receive Not Ready RNS Radio Network Subsystem RNSAP Radio Network Subsystem Application Part (3GTS

25.423) RNSN Radio Network Serving Node RNTI Radio Network Temporary Identifier RoT Rise over Thermal (interference rise relative to zero

load)




RPE/LTP Regular Pulse Excitation / Long Term Prediction (Speech Codec)

RPID Rich Presence Information Data RPLMN Registered PLMN RPR Resilient Packet Ring (IEEE 802.17) RR Radio Resource Management RR Receive Ready (LAPD/LLC/RLP-Frame Type) RRA Radio Resource Agent RRBP Relative Reserved Block Period RRC Radio Resource Control RRC-Filter Root Raised Cosine Filter RRLP Radio Resource LCS Protocol RRM Radio Resource Management RSA Ron Rivest, Adi Shamir and Leonard Adleman-

algorithm (Public Key Encryption / PKCS #1) RSADP RSA-Decryption Primitive (RFC 3447 (5.1.2) or PKCS

#1 (5.1.2); PKCS = Public Key Cryptography Standard) RSAEP RSA-Encryption Primitive (RFC 3447 (5.1.1) or PKCS

#1 (5.1.1); PKCS = Public Key Cryptography Standard) RSAES-OAEP RSA Encryption Scheme - Optimal Asymmetric

Encryption Padding (PKCS #1 / RFC 3447) RSC Recursive Systematic Convolutional Coder (Turbo

Coding, 25.212) RSCP Received Signal Code Power (3GTS 25.215) RSN Retransmission Sequence Number (3GTS 25.309,

25.212) RSSI Received Signal Strength Indicator RSVP Resource Reservation Protocol (RFC 2205) RTCP Real-time Transport Control Protocol

RTG Receive transmit Transition Gap (IEEE 802.16 (3.45)) the time between an uplink subframe and the subsequent downlink subframe in a TDD-system

RTO Retransmission Time Out RTP Real-time Transport Protocol (RFC 3550, RFC 3551) RTP/AVP Real-time Transport Protocol / Audio Video Profile (RFC

3551) (used in SDP-descriptions) RTP/AVPF Real-time Transport Protocol / extended Audio Video

Profile for rtcp Feedback (used in SDP-descriptions)(draft-ietf-avt-rtcp-feedback-11.txt)

RTP/SAVP Real-time Transport Protocol / Secure Audio Video Profile (RFC 3711) (used in SDP-descriptions)

RTSP Real Time Streaming Protocol (RFC 2326) RTT Round Trip Time RTTVAR Round Trip Time Variation RTWP Received Total Wideband Power RUIM Removable User Identity Module RV Redundancy and Constellation Version (3GTS 25.212) RX Receive S/P Serial to Parallel SA Service Area SA Security Association SAAL-NNI Signaling ATM Adaptation Layer - Network Node

Interface SAB Service Area Broadcast SABM(E) Set Asynchronous Balanced Mode (Extended for

Modulo 128 operation) (LAPD/LLC/RLP-Frame Type) SABP Service Area Broadcast Protocol (3GTS 25.419) SACCH Slow Associated Control Channel (GSM)




SACCH/MD SACCH Multislot Downlink (related control channel of TCH/FD/GSM)

SACK Selective Acknowledgement SAI Service Area Identifier SAIC Single Antenna Interference Cancellation SANC Signaling Area Network Code (ITU-T Q.708) SAP Service Access Point SAPI Service Access Point Identifier SAR Segmentation And Reassembly (ATM-sublayer) SAT Satellite SBC Session Border Controller (SIP term, usually a B2BUA

with NAT-function and media gateway) SBN Source Block Number SBPSCH Shared Basic Physical SubCHannel SC Serving Cell SC Subcarrier SCCP Signaling Connection Control Part (ITU-T Q.711 -

Q.714) S-CCPCH Secondary Common Control Physical Channel (used as

bearer for the FACH and PCH TrCH's / UMTS Physical Channel)

SCF Service Control Function (CAMEL) SCH Synchronization Channel (UMTS Physical Channel /

see also P-SCH and S-SCH) SCH Synchronization Channel (GSM) SCP Service Control Point (IN) S-CPICH Secondary Common Pilot Channel (UMTS Physical

Channel) SCR Source Controlled Rate

S-CSCF Serving Call Session Control Function (SIP) SCTP Stream Control Transmission Protocol (RFC 2960) SDCCH Stand Alone Dedicated Control Channel SDH Synchronous Digital Hierarchy SDMA Space Division Multiple Access SDP Session Description Protocol (RFC 2327, RFC 3266,

RFC 3264) SDU Service Data Unit (the payload of a PDU) SEG Security Gateway SEP Signaling End Point (CCS7) SF Spreading Factor SFH Slow Frequency Hopping SFID Service Flow Identity SFN System Frame Number SFN Single Frequency Network SG Security Gateway (IPsec / RFC 2401) SG Serving Grant respectively Power Grant (3GTS 25.213,

25.309, 25.321) SGSN Serving GPRS Support Node SGW Signaling Gateway SHA Secure Hash Algorithm SHCCH Shared Channel Control Channel (UMTS Logical

Channel / TDD only) SHO Soft Handover (UE is having more than one radio link at

the same time and combines them) SI Service Indicator SIB System Information Block SIB LSSU with status indication busy SID Silence Insertion Descriptor




SID Size InDex (3GPP 25.321) SIE LSSU with status indication emergency alignment SIF Signaling Information Field SIG Special Interest Group (e.g. Bluetooth) SIGTRAN Signaling Transport (RFC 2719) SIM Subscriber Identity Module SIMO Single In / Multiple Out (antenna system) SIN LSSU with status indication normal alignment SIO Service Information Octet SIO LSSU with status indication out of alignment SIOS LSSU with status indication out of service SIP Session Initiation Protocol (RFC 3261) SIP-AS SIP-Application Server SIP-B SIP for Businesses (abbreviation for a set of PABX-

specific SIP-extensions) SIP-I SIP with encapsulated ISUP (ITU-T Q.1912.5) SIPO LSSU with status indication processor outage SIP-T SIP for Telephones (RFC 3372, RFC 3398) SIQ Service Information Query SIR Signal to Interference Ratio SISO Single In / Single Out (antenna system) SLA Service Level Agreement SLC Signaling Link Code SLF Subscriber Locator Function SLR Source Local Reference SLS Signaling Link Selection SLTA Signaling Link Test Acknowledge SLTM Signaling Link Test Message

SM Session Management (3GTS 23.060, 3GTS 24.008) SME Small and Medium size Enterprises (Type of Business) SMIL Synchronized Multimedia Integration Language SMLC Gateway Mobile Location Center SMS Short Message Service (3GTS 24.011, 3GTS 23.040) SM-SC Short Message Service Center SMSCB Short Message Services Cell Broadcast SMS-G-MSC SMS Gateway MSC (for Short Messages destined to

Mobile Station) SMS-IW-MSC SMS Interworking MSC (for Short Messages coming

from Mobile Station) SMTP Simple Mail Transfer Protocol (RFC 2821) SN Sequence Number SND Sequence Number Downlink (GTP) SNDCP Subnetwork Dependent Convergence Protocol SNM Signaling Network Management Protocol (ITU-T Q.704

(3)) SNN SNDCP N-PDU Number Flag SN-PDU Segmented N-PDU (SN-PDU is the payload of SNDCP) SNR Signal to Noise Ratio SNTM Signaling Network Test & Maintenance (ITU-T Q.707) SNTP Simple Network Time Protocol (RFC 2030) SNU Sequence Number Uplink (GTP) SOAP Simple Object Access Protocol

(http://www.w3.org/TR/2000/NOTE-SOAP-20000508) SOHO Small Office Home Office (Type of Business) SP Signaling Point SPC Signaling Point Code SPI Security Parameter Index (RFC 2401)




SQCIF Semi Quarter Common Intermediate Format (128 x 96 pixels ITU-T H261 / H263)

SQN Sequence number (used in UMTS-security architecture / 3GTS 33.102)

SRB Signaling Radio Bearer SRES Signed Response SRF Service Resource Function (CAMEL) SRNC Serving Radio Network Controller SRNS Serving Radio Network Subsystem SRTP Secure RTP (RFC 3711) SRTT Smoothed RoundTrip Time SRV Service Location (DNS-related / RFC 2782) SS Subscriber Station (IEEE 802.16) SSC Secondary Synchronization Code SSCF Service Specific Co-ordination Function SSCF/NNI Service Specific Coordination Function - Network Node

Interface Protocol (ITU-T Q.2140) SSCF/UNI Service Specific Coordination Function - User Network

Interface Protocol (ITU-T Q.2130) S-SCH Secondary Synchronization Channel (physical) SSCOP Service Specific Connection Oriented Protocol (ITU-T

Q.2110) SSCOPMCE Service Specific Connection Oriented Protocol in a

Multi-link or Connectionless Environment (ITU-T Q.2111)

SSCS Service Specific Convergence Sublayer SSDT Site Selection Diversity Transmission SSF Service Switching Function (CAMEL) SSID Service Set Identifier (IEEE 802.11)

SSN Start Sequence Number (related to ARQ-Bitmap in GPRS / EGPRS)

SSN Send Sequence Number (GSM MM and CC-Protocols) SSP Service Switching Point (IN) SSRTG Subscriber Station Receive to transmit Turnaround Gap

(IEEE 802.16 (3.53)) Time that the SS needs to switch from receive to transmit.

SSSAR Service Specific Segmentation And Reassembly (ITU-T I.366.1)

ssthresh Slow start threshold (RFC 2001, RFC 2960) SSTTG Subscriber Station Transmit to receive Turnaround Gap

(IEEE 802.16 (3.54)) Time that the SS needs to switch from transmit to receive.

STBC Space Time Block Coding STC Signaling Transport Converter on MTP-3 and MTP-3b

(ITU-T Q.2150.1) / Signaling Transport Converter on SSCOP and SSCOPMCE (ITU-T Q.2150.2)

STC Space Time Coding STP Signaling Transfer Point STTD Space Time block coding based Transmission Diversity STUN Simple Traversal of UDP through Network Address

Translators (RFC 3489) SUA SCCP User Adaptation Layer (RFC 3868) SUERM Signal Unit Error Rate Monitor (ITU-T Q.703 (10)) SUFI Super Field (RLC-Protocol) SUN Originally stood for Stanford University Network SVC Switched Virtual Circuit SVG Scalable Vector Graphics SWAP Shared Wireless Access Protocol (Home RF) T.38 Fax Specification




TA Terminal Adapter (ISDN) TA Timing Advance TACS Total Access Communication System TAF Terminal Adopter Function (3GTS 27.001) TAI Timing Advance Index TB Transport Block TBCP Talk Burst Control Protocol TBF Temporary Block Flow TBS Transport Block Set TCAP Transaction Capabilities Application Part (Q.771 -

Q.773) TCB Transmission Control Block TCH Traffic Channel TCH/FD Traffic Channel / Fullrate Downlink TCH-AFS Traffic CHannel Adaptive Full rate Speech TCH-AHS Traffic Channel Adaptive Half rate Speech TCP Transmission Control Protocol TCP/BFCP Transmission Control Protocol / Binary Floor Control

Protocol (draft-ietf-xcon-bfcp-05.txt) TCP/RTP/AVP Real-time Transport Protocol / Audio Video Profile over

TCP (used in SDP-descriptions)(draft-ietf-avt-rtp-framing-contrans-06.txt)

TCP/TLS/BFCP Transmission Control Protocol / Transport Layer Security / Binary Floor Control Protocol (draft-ietf-xcon-bfcp-05.txt)

TCTF Target Channel Type Field TCTV Transport Channel Traffic Volume TDD Time Division Duplex TDM Time Division Multiplexing

TDMA Time Division Multiple Access TDOA Time Difference of Arrival TE Terminal Equipment TEBS Total E-DCH Buffer Status TEID Tunnel Endpoint Identifier (GTP / 3GTS 29.060) TEK Traffic Encryption Key (IEEE 802.16) Term Explanation TF Transport Format TFC Transport Format Combination TFCI Transport Format Combination Identifier TFCS Transport Format Combination Set TFI Transport Format Indication (UMTS) TFI Temporary Flow Identity ((E)GPRS) TFO Tandem Free Operation (3GTS 22.053) TFRC Transport Format and Resource Combination (3GTS

25.308) TFRI Transport Format and Resource Indicator (3GTS

25.308, 25.321) TFS Transport Format Set TFT Traffic Flow Template TFTP Trivial File Transfer Protocol (RFC 1350) TGD Transmission Gap start Distance (3GTS 25.215) TGL Transmission Gap Length (3GTS 25.215) TGPRC Transmission Gap Pattern Repetition Count (3GTS

25.215) TGSN Transmission Gap Starting Slot Number (3GTS 25.215) TH-CDMA Time Hopping Code Division Multiple Access THIG Topology Hiding Inter Network Gateway




THP Traffic Handling Priority (DiffServ Term) THz Tera Hertz (1012 Hertz) TI Transaction Identifier TIA Telecommunications Industry Association TID Tunnel Identifier TIPHON Telecommunications and Internet Protocol

Harmonization Over Networks (ETSI Project) TISPAN Telecoms & Internet converged Services & Protocols

for Advanced Networks (ETSI Working Group to define IMS for fixed broadband access networks)

TLLI Temporary Logical Link Identifier TLS Transport Layer Security (RFC 2246 / RFC 3546 /

formerly known as SSL or Secure Socket Layer) TLV Tag / Length / Value Notation TM Transparent Mode operation (UMTS-RLC) TM Transmission Modules TMD Transparent Mode Data (UMTS RLC PDU-type) TMGI Temporary Mobile Group Identity (3GTS 23.003 (15.2)) TMN Telecommunication Management Network TMSI Temporary Mobile Subscriber Identity TNL Transport Network Layer (3GTS 25.401) TOI Transport Object Identifier ToIP Text over IP TOS Type of Service TPC Transmit Power Command T-PDU Payload of a G-PDU which can be user data, i.e.

possibly segmented IP-frames, or GTP signaling information (GTP)

TPS Transmission Parameter Signalling (DVB-H)

TQI Temporary Queuing Identifier TRAU Transcoder and Rate Adaption Unit TrCH Transport Channel (UMTS) TrFO Transcoder Free Operation TrGw Transition Gateway (IPv4 IPv6) (3GTS 23.228 (5.18)) TRX Transmitter / Receiver TS Timeslot TS Transport Stream TSC Training Sequence Code TSN Transmission Sequence Number TSTD Time Switched Transmit Diversity TTA Telecommunications Technology Association (South

Korean standards organization) TTG Tunnel Termination Gateway TTG Transmit receive Transition Gap (IEEE 802.16 (3.63))

the time between a downlink subframe and the subsequent uplink subframe in a TDD-system

TTI Transmission Time Interval TTL Time To Live (IP-Header / RFC 791) TUA TCAP User Adaptation Layer TUP Telephone User Part TUSC Tile Use of Subchannels TV Television TX Transmit UA User Agent (SIP-Term / RFC 3261) UA Unnumbered Acknowledgement (LAPD/LLC/RLP-

Frame Type) UAC User Agent Client (SIP-Term / RFC 3261) UARFCN UMTS Absolute Radio Frequency Channel Number




UART Universal Asynchronous Receiver and Transmitter UAS User Agent Server (SIP-Term / RFC 3261) UCD Uplink Channel Descriptor (WIMAX Message) UCS Universal Character Set UDCH User-plane Dedicated Channel (3GTS 45.902) UDP User Datagram Protocol (RFC 768) UDPTL UDP Transport Layer (used in SDP-description for T.38

fax-applications) UE User Equipment UEA UMTS Encryption Algorithm (3GTS 33.102) UGS Unsolicited Grant Service (IEEE 802.16 Traffic Class) UHF Ultra High Frequency UI Unnumbered Information (LAPD) / Unconfirmed

Information (LLC) / Frame Type UIA UMTS Integrity Algorithm (3GTS 33.102) UICC Universal Integrated Circuit Card (3GTS 22.101 /

Bearer card of SIM / USIM) UIUC Uplink Interval Usage Code (WIMAX Term) UL Uplink UL-MAP Uplink-Medium Access Protocol (MAC-Message in

WIMAX / IEEE 802.16) UM Unacknowledged Mode operation (UMTS-RLC) UMA Unlicensed Mobile Access (3GTS 43.318) UMAN Unlicensed Mobile Access Network UMD Unacknowledged Mode Data (UMTS RLC PDU-type) UMS User Mobility Server (HSS = HLR + UMS) UMTS Universal Mobile Telecommunication System UNC UMA Network Controller UNC-SGW UMA Network Controller Security Gateway

UNI User-to-Network Interface URA UTRAN Registration Area URB User Radio Bearer URI Uniform Resource Identifier URL Uniform Resource Locator (RFC 1738) USA United States of America USAT USIM Application Toolkit USB Universal Serial Bus USCH Uplink Shared Channel (UMTS Transport Channel

TDD only) USD User Service Description USF Uplink State Flag USIM Universal Subscriber Identity Module UTF-8 Unicode Transformation Format-X (Is an X-bit) lossless

encoding of Unicode characters UTRA UMTS (Universal Mobile Telecommunication System)

Terrestrial Radio Access UTRAN UMTS (Universal Mobile Telecommunication System)

Terrestrial Radio Access Network UUI User to User Information UUS User-User-Signaling (3GTS 23.087) UV Ultra Violet UWB Ultra-Wide Band (IEEE 802.15.3) UWC Universal Wireless Convergence (Merge IS-136 with

GSM) V5UA V5.2-User Adaptation Layer (RFC 3807) VAD Voice Activity Detector VBS Voice Broadcast Service (GSM-R) VC Virtual Circuit




VCI Virtual Circuit Identifier (ATM) VDSL Very high data rate Digital Subscriber Line (ITU-T

G.993.1) VE Virtual Engine VGCS Voice Group Call Service (GSM-R) VHE Virtual Home Environment (3GTS 22.121, 3GTS

23.127) VHF Very High Frequency VLAN Virtual LAN VLR Visitor Location Register VoD Video on Demand VoIP Voice over IP VPI Virtual Path Identifier (ATM) V-PLMN Visited PLMN VPN Virtual Private Network VW Virtual Wire PDB (DiffServ Term) WAG WLAN (Wireless Local Area Network) Access Gateway W-AMR Wideband AMR-Codec (Adaptive Multirate) (3GTS

26.190) W-AMR+ Extended Wideband AMR-Codec (Adaptive Multirate)

(3GTS 26.290) WAN Wide Area Network WAP Wireless Application Protocol W-APN WLAN-APN (Wireless Local Area Network - Access

Point Name) (3GTS 23.234) WCDMA Wide-band Code Division Multiple Access WEP Wired Equivalent Privacy WiFi Wireless Fidelity (www.wi-fi.org) WIMAX Worldwide Interoperability for Microwave Access (IEEE

802.16) WINS Windows Internet Name Service WLAN Wireless Local Area Network (IEEE 802.11) WMAN Wireless Metropolitan Area Network WPA WiFi Protected Access WRED Weighted Random Early Detection WSN Window Size Number X-CSCF Call Session Control Function (any, there is I-CSCF, P-

CSCF and X-CSCF) XHTML Extensible Hypertext Markup Language XID Exchange Identification (LAPD/LLC-Frame Type) XMAC Expected Message Authentication Code XMF Extensible Music Format XOR Exclusive-Or Logical Combination XRES Expected Response (3GTS 33.102) XUA Any User Adaptation Layer (M2UA, M3UA, SUA)




hh

Index: 11

100rel..........................................................................................................240 100-Trying ( SIP-Response Code) .........................................................248 183-Session Progress ( SIP-Response Code).......................................254

33 302-Moved Temporarily ( SIP-Response Code) ................................80, 82 3pcc ....................................................................................................340, 356

44 401-Unauthorized ( SIP-Response Code)..............................................118 420-Bad Extension ( SIP-Response Code) ............................................242 422- Session Interval Too Small ( SIP-Response Code) .......................342 480-Temporarily Unavailable ( SIP-Response Code) ............................292 481-Call Leg / Transaction Does Not Exist ( SIP-Response Code) .......116 487- Request Terminated ( SIP-Response Code) ...................................84 487-Request Terminated / Transaction Does Not Exist ( SIP-Response

Code) ......................................................................................................116 488-Not Acceptable Here ( SIP-Response Code)..................................256

55 504-Server Timeout ( SIP-Response Code)...........................................246 580-Precondition Failure ( SIP-Response Code) ...................................256

66 606-Not Acceptable ( SIP-Response Code)...........................................334

AA Address ( SDP o-line) .............................................................................184 Address-type ( SDP o-line) .....................................................................184 ALG (Application Layer Gateway) ................................................................72 a-line ( SDP) ...........................................................................................214 AMR ( SDP-definition) ............................................................................216 Application Layer Gateway...........................................................................72 Application Server.........................................................................................72 AS ( SDP b-line / modifier)......................................................................210 AS (Application Server) ................................................................................72 attribute lines ( SDP)...............................................................................214 Authorization ( header field)....................................................384, 400, 404

BB B2BUA ..........................................................................................................70 back-to-back user agent ...............................................................................70 BFCP ..........................................................................................................206 b-line ( SDP) ...................................................................................190, 210 branch parameter .......................................................................................102

CC call ..............................................................................................................124




call ( definition in SIP) ...............................................................................96 call drop (no common codec) .....................................................................250 call forwarding unconditional ......................................................................298 Call-ID.........................................................................................................100 capacity of SIP-server ..................................................................................74 c-line ( SDP) ...........................................................................................186 codec type ..................................................................................................332 common presence and instant messaging.................................................196 confirmation (conf) ( SDP-attribute)........................................................274 connection ( SDP-attribute) ....................................................................218 Contact ( header field) ............................................................................124 Core ( SIP-sublayer) .................................................................................64 CPIM...........................................................................................................196 CSeq...........................................................................................................104 CT ( SDP b-line / modifier)......................................................................210 current (curr) ( SDP-attribute) .................................................................272

DD desired (des) ( SDP-attribute).................................................................274 DIA................................................................................................................16 dialog ..................................................................................................100, 124 dialog ( definition in SIP)...........................................................................96 DIAMETER ...................................................................................................16 do not disturb..............................................................................................292

EE early dialog ...........................................................................................96, 332 event server ..................................................................................................90 event: reg....................................................................................................408 expires-time ( 3GPP) ......................................................................118, 388

FF find me ........................................................................................................314 fmtp ( SDP-attribute)...............................................................................216 follow me.....................................................................................................314 forking .....................................................................................74, 76, 124, 130 forking (simultaneous ...................................................................................82 From-tag .....................................................................................................100

HH H.248 ............................................................................................................92 H.323 ............................................................................................................20 header field

Authorization......................................................................................................384 Authorization......................................................................................................400 Authorization......................................................................................................404 P-Associated-URI ...................................................................................... 384, 406 Path.....................................................................................................................406 Security-Client ........................................................................................... 400, 404 Security-Verify...................................................................................................406 Service-Route.....................................................................................................406

home network domain name ......................................................................384

II iLBC ............................................................................................................180 IMPI ............................................................................................................378 IMPU...........................................................................................................378 IMS ...............................................................................................................12 IP Multimedia Subsystem.............................................................................12 ISIM ............................................................................................................378




KK keep-alive mechanism................................................................................342

LL local ( SDP-attribute) ..............................................................................270 location based services ................................................................................90

MM magic cookie ( z9hG4bK ) .......................................................................102 media description ( SDP)................................................................178, 190 media gateway .............................................................................................92 media gateway controller..............................................................................92 Media Gateway Controller ............................................................................72 media stream adjustment ...........................................................................336 media type (MIME) ( SDP m-line)...........................................................192 media types (MIME) / examples)................................................................194 MEGACO......................................................................................................92 MGC .......................................................................................................72, 92 MGW.............................................................................................................92 Min-SE........................................................................................................342 m-line ( SDP) ..........................................................................................192 mode-change-neighbor ( SDP-attribute / AMR-specific) ........................216 mode-change-period ( SDP-attribute / AMR-specific) ............................216 mode-set ( SDP-attribute / AMR-specific) ..............................................216 modifying a media stream ..........................................................................336

NN NAPTR........................................................................................................236 network architecture ( SIP) .......................................................................66 Network-type ( SDP o-line) .....................................................................184

Next Generation Networks .........................................................................6, 8 NGN............................................................................................................6, 8 notification ( event) ...................................................................................90 NTP.............................................................................................................188

OO offer / answer model ...................................................................................220 o-line ( SDP) ...........................................................................................184

PP Packed Encoding Rules ...............................................................................20 P-Associated-URI ( header field) ....................................................384, 406 Path ( header field) .................................................................................406 payload-type-list ( SDP m-line) ...............................................................192 PDF.............................................................................................412, 414, 416 PER ..............................................................................................................20 policy decision function...............................................................412, 414, 416 port number ( RTCP) ................................................................................58 port number ( SIP) ............................................................................64, 150 port-number ( SDP m-line)......................................................................192 PRACK .......................................................................................................244 precondition ( SIP-option tag) .................................................................266 preconditions ( SDP)...............................................................................254 presence ( event) ......................................................................................90 private user identity.....................................................................................378 protocol stack ( SIP...................................................................................64 provisional response messages .................................................................238 provisional responses.................................................................................238 proxy ( stateful) ...................................................................................70, 76 proxy ( stateless) ................................................................................70, 74 proxy server discovery (SIP) ..............................................................230, 234 PSTN-replacement .......................................................................................36




public user identity......................................................................................378 publishing ( event) ....................................................................................90 push-to-talk .................................................................................................206

QQ q-parameter ................................................................................................124

RR RAck ...........................................................................................................244 Real-time Transport Protocol........................................................................16 received (via-parameter) ............................................................................170 recvonly ( SDP-attribute) ........................................................................214 redirect server.........................................................................................76, 80 refresher ( timer based session release) ................................................342 Registrar .......................................................................................................72 registration event package .........................................................................408 remote ( SDP-attribute)...........................................................................270 Response Types ( SIP).............................................................................40 Response: 100-Trying ................................................................................248 Response: 183-Session Progress..............................................................254 Response: 302-Moved Temporarily .......................................................80, 82 Response: 401-Unauthorized.....................................................................118 Response: 420-Bad Extension...................................................................242 Response: 422- Session Interval Too Small ..............................................342 Response: 481-Call Leg / Transaction Does Not Exist ..............................116 Response: 486-User Busy..........................................................................292 Response: 487- Request Terminated ..........................................................84 Response: 487-Request Terminated .................................................116, 260 Response: 488-Not Acceptable Here.........................................................256 Response: 504-Server Timeout..................................................................246 Response: 580-Precondition Failure ..........................................................256 Response: 606-Not Acceptable..................................................................334

rport (via-parameter)...................................................................................170 RR ( SDP b-line / modifier) .............................................................210, 212 RS ( SDP b-line / modifier) .............................................................210, 212 RSeq...................................................................................................240, 244 RTCP-port number) ......................................................................................58 RTP...............................................................................................................16 RTP/AVP ( SDP m-line / transport).........................................................198 RTP/AVPF ( SDP m-line / transport) ......................................................198 RTP/SAVP ( SDP m-line / transport) ......................................................198 rtpmap ( SDP-attribute)...........................................................................216

SS SBC ......................................................................................................70, 346 SBC initiated session release.....................................................................350 S-CSCF selection .......................................................................................388 SDP-media description...............................................................................178 SDP-session description ............................................................................178 SDP-time description..................................................................................178 Secure Real-time Transport Protocol ...........................................................16 Security-Client ( header field) .........................................................400, 404 Security-Verify ( header field) .................................................................406 selection (of S-CSCF )................................................................................388 sendonly ( SDP-attribute) .......................................................................214 Service-Route ( header field)..................................................................406 session..........................................................................................................98 session ( identification) ...........................................................................100 session border controller ..............................................................................70 session description ( SDP) .....................................................................178 session establishment with SIP ( simplified example) ..............................38 session release ( SBC-initiated) .............................................................350 session release ( timer based)................................................................342 session release ( ungraceful)..........................................................340, 348 session timer...............................................................................................342 Session-Description-Version ( SDP o-line).............................................184




session-description-version ( SDP-description)......................................332 Session-ID ( SDP o-line).........................................................................184 SigComp.....................................................................................................330 SIP (Response types)..............................................................................40 SIP ( protocol stack) .................................................................................64 SIP ( scope of) ..........................................................................................22 SIP trapezoid ..............................................................................................230 SIP Use within NGN .....................................................................................16 SIP-B ..........................................................................................................330 SIP-bridging................................................................................................358 SIP-I............................................................................................................330 SIPPING .....................................................................................................356 SIP-proxy server discovery.........................................................................234 SIP-server ( capacity of) ...........................................................................74 SIP-T...................................................................................................330, 358 SIP-transport protocol...................................................................................76 SKYPE..........................................................................................................34 s-line ( SDP) ...........................................................................................182 soft switch...............................................................................................66, 92 SRTP ............................................................................................................16 SRV ............................................................................................................236 start time ( SDP t-line) ............................................................................188 stateful proxy ..........................................................................................70, 76 stateless proxy........................................................................................70, 74 stop time ( SDP t-line).............................................................................188 sublayers of SIP ...........................................................................................64 subscription ( event) .................................................................................90

TT T1................................................................................................................132 tag ( From) ..............................................................................................100 tag ( To) ..................................................................................................100 TBCP ( SDP m-line / transport) ..............................................................200 TCP ( SDP m-line / transport).................................................................200

TCP/BFCP ( SDP m-line / transport) ......................................................200 TCP/MSRP ( SDP m-line / transport) .....................................................202 TCP/RTP/AVPF ( SDP m-line / transport) ..............................................202 TCP/TLS/BFCP ( SDP m-line / transport) ..............................................202 TCP/TLS/MSRP ( SDP m-line / transport)..............................................204 TIAS ( SDP b-line / modifier) ..................................................................210 time description ( SDP)...........................................................................178 timer 1.........................................................................................................132 timer A ........................................................................................................134 timer B ........................................................................................................134 timer C ..................................................................................................76, 132 timer D ........................................................................................................136 timer E ................................................................................................144, 146 timer F.................................................................................................144, 146 timer G ........................................................................................................140 timer H ........................................................................................................140 timer J .........................................................................................................148 timer K ........................................................................................................144 t-line ( SDP) ............................................................................................188 To-tag .........................................................................................................100 Transaction ( definition in SIP)..................................................................96 transaction ( identification)......................................................102, 106, 108 transaction / CANCEL ................................................................................116 transaction / INVITE / successful................................................................112 transaction / INVITE / unsuccessful............................................................114 transaction / REGISTER.............................................................................118 transaction handling ( SIP-sublayer) ........................................................64 transaction numbering ................................................................................104 transaction user ( SIP-sublayer) ...............................................................64 transport ( SDP m-line) ...........................................................................192 transport layer control ( SIP-sublayer)......................................................64 transport protocol ( SIP)............................................................................76 trapezoid (SIP)............................................................................................230 Triple-Play Services........................................................................................6 TU .................................................................................................................64




UU UAC ..............................................................................................................64 UAS ..............................................................................................................64 UDP ( SDP m-line / transport) ................................................................204 UDPTL ( SDP m-line / transport) ............................................................204 UMA............................................................................................................384 ungraceful session release.................................................................340, 348 UPDATE .............................................................................................254, 332 user busy ....................................................................................................292 user not registered......................................................................................298

user not responding....................................................................................304 Username ( SDP o-line)..........................................................................184

VV via ...............................................................................................................102 v-line ( SDP)............................................................................................182

ZZ z9hG4bK.....................................................................................................102

training ims sip

Engineering

employees of inacon

inacon publications

nokia siemens networks

message mandatory

srihari avula

different color codes

mandatory data blocks

training document