Sie sind auf Seite 1von 678

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

IMS_SIP_NSN0910
Special Training

INACON GmbH
Kriegsstrasse 154
76133 Karlsruhe
Germany
www.inacon.com
e-mail: inacon@inacon.de

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.

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

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)

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

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
(inacon@inacon.de), 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.

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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 MSCs 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


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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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-CNArchitecture ............................................................................................................................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


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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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-CANs .......................................................... 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


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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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
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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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
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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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
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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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
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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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 UAs ..........................................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 UAs / 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 Mobiles 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
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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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 UAs / 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


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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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
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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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
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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
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 NATs) ........................................................... 589
Step 1: Registration behind two NATs ....................................................................... 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 NATs ................................. 597


Problem Description............................................................................................................ 597
SIP: INVITE-Message ......................................................................................................... 599
SIP: 183-Session Progress Response Message................................................................ 601
Audio Data Flow through the NATs UE Originating ........................................................ 603
Audio Data Flow through the NATs UE Terminating ....................................................... 605
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

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

SIP, SDP and other NGN Protocols


Signaling & Protocol Analysis
IMS and IP-CAN use NAT / How many TrGws are required? (Practical Exercise).... 607

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

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

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

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

IMS_SIP_NSN0910 Special Course

Intentionally left blank

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-

IMS_SIP_NSN0910 Special Course

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

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

-1-

IMS_SIP_NSN0910 Special Course

Objectives
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
NGNs to address which requirements

Have seen a simple session setup and release through SIP

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

-2-

IMS_SIP_NSN0910 Special Course

Objectives

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 NGNs are implemented in the first place. Secondly, we will illustrate the network elements
within NGNs and their tasks. Finally, we will illustrate the IMS (IP Multimedia Subsystem) as an essential part of NGNs.

Know which protocols like SIP (Session Initiation Protocol) are used within NGNs to address which requirements
In this section, we will emphasize on the core protocols within NGNs 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.

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

-3-

IMS_SIP_NSN0910 Special Course

What are the driving Forces behind the NGN-Hype?

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, ISPs (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.

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

-4-

IMS_SIP_NSN0910 Special Course

What are the driving Forces behind the NGN-Hype?


NGN relates to Next Generation Networks

Easy Offering of Multimedia Services becomes possible


Please compare this to todays 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).

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

-5-

IMS_SIP_NSN0910 Special Course

Next Generation Networks and their Components

Typical Configuration and Interconnection of Next Generation Networks

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

-6-

IMS_SIP_NSN0910 Special Course

Next Generation Networks and their Components


Typical Configuration and Interconnection of Next Generation Networks
The figure illustrates the most likely configuration of NGNs 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 TelecomOperator 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. Thats 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 DSLcompetitor 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-CANs.

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

-7-

IMS_SIP_NSN0910 Special Course

Limitations of the Release 99 Network & Software Architecture

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

-8-

IMS_SIP_NSN0910 Special Course

Limitations of the Release 99 Network & Software Architecture


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 MSCs handle broadband service requests?


Nowadays, the circuit-switched core network is primarily based on the MSCs 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 doesnt 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.

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

-9-

IMS_SIP_NSN0910 Special Course

The New Circuit-Switched CN Architecture with Release 4

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

- 10 -

IMS_SIP_NSN0910 Special Course

The New Circuit-Switched CN Architecture with Release 4


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 users service requirements and the required QoS. One MGW may
therefore be the slave of one or more MSC-Ss. 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 MGWs 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 MGWs. 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-Ss 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-Ss is called BICC. It is very similar to ISUP but allows for the provision of binding IDs 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.

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

- 11 -

IMS_SIP_NSN0910 Special Course

Access and Core Network Architecture with Release 4

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

- 12 -

IMS_SIP_NSN0910 Special Course

Access and Core Network Architecture with Release 4


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 MSCs (< 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]

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

- 13 -

IMS_SIP_NSN0910 Special Course

Important Architectural Changes with Release 5

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

- 14 -

IMS_SIP_NSN0910 Special Course

Important Architectural Changes with Release 5


The figure illustrates the most important architectural changes with 3GPPs 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, NodeBs can be interconnected to their C-RNC using IP. The same applies to the interconnection between RNCs on one hand
and MSC-S and MGW on the other hand. Obviously, the Iur-interface can also be based on IP.

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

- 15 -

IMS_SIP_NSN0910 Special Course

New Features with Release 5

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

- 16 -

IMS_SIP_NSN0910 Special Course

New Features with Release 5


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.

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

- 17 -

IMS_SIP_NSN0910 Special Course

Fixed Mobile Convergence

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

- 18 -

IMS_SIP_NSN0910 Special Course

Fixed Mobile Convergence


The figure illustrates one possible future of mobile communications that will be possible with 3GPPs 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.

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

- 19 -

IMS_SIP_NSN0910 Special Course

OSA (Open Service Access)

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

- 20 -

IMS_SIP_NSN0910 Special Course

OSA (Open Service Access)


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/GMMprotocols 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 SCSs (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]

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

- 21 -

IMS_SIP_NSN0910 Special Course

Multimedia Call Control

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

- 22 -

IMS_SIP_NSN0910 Special Course

Multimedia Call Control


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]

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

- 23 -

IMS_SIP_NSN0910 Special Course

Why is an Architecture Evolution necessary?

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

- 24 -

IMS_SIP_NSN0910 Special Course

Why is an Architecture Evolution necessary?


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.

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

- 25 -

IMS_SIP_NSN0910 Special Course

Why is an Architecture Evolution necessary? (cont.)

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

- 26 -

IMS_SIP_NSN0910 Special Course

Why is an Architecture Evolution necessary? (cont.)


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.

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

- 27 -

IMS_SIP_NSN0910 Special Course

Why is an Architecture Evolution necessary? (cont.)

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

- 28 -

IMS_SIP_NSN0910 Special Course

Why is an Architecture Evolution necessary? (cont.)


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

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

- 29 -

IMS_SIP_NSN0910 Special Course

Release 8 / 9 Architecture Overview

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

- 30 -

IMS_SIP_NSN0910 Special Course

Release 8 / 9 Architecture Overview

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 3GPPrecommendations 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 EPCoperator'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.

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

- 31 -

IMS_SIP_NSN0910 Special Course

Zoom into the EPS

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

- 32 -

IMS_SIP_NSN0910 Special Course

Zoom into the EPS

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.

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

- 33 -

IMS_SIP_NSN0910 Special Course

The eNB

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

- 34 -

IMS_SIP_NSN0910 Special Course

The eNB

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.

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

- 35 -

IMS_SIP_NSN0910 Special Course

The eNB (contd)

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

- 36 -

IMS_SIP_NSN0910 Special Course

The eNB (contd)

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)]

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

- 37 -

IMS_SIP_NSN0910 Special Course

Mobility Management Entity (MME)

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

- 38 -

IMS_SIP_NSN0910 Special Course

Mobility Management Entity (MME)

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)]

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

- 39 -

IMS_SIP_NSN0910 Special Course

Mobility Management Entity Interfaces & Protocols

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

- 40 -

IMS_SIP_NSN0910 Special Course

Mobility Management Entity Interfaces & Protocols


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)]

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

- 41 -

IMS_SIP_NSN0910 Special Course

Mobility Management Entity Tasks & Functions

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

- 42 -

IMS_SIP_NSN0910 Special Course

Mobility Management Entity Tasks & Functions


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]

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

- 43 -

IMS_SIP_NSN0910 Special Course

S-GW and P-GW Selection

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

- 44 -

IMS_SIP_NSN0910 Special Course

S-GW and P-GW Selection


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.

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

- 45 -

IMS_SIP_NSN0910 Special Course

E-UTRAN Organization and Identifiers

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

- 46 -

IMS_SIP_NSN0910 Special Course

E-UTRAN Organization and Identifiers


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 MMEresources. 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)]

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

- 47 -

IMS_SIP_NSN0910 Special Course

UE Identifiers M-TMSI and S-TMSI

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

- 48 -

IMS_SIP_NSN0910 Special Course

UE Identifiers M-TMSI and S-TMSI


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.

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

- 49 -

IMS_SIP_NSN0910 Special Course

UE Identifiers GUTI

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

- 50 -

IMS_SIP_NSN0910 Special Course

UE Identifiers GUTI

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)]

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

- 51 -

IMS_SIP_NSN0910 Special Course

The Serving Gateway (S-GW)

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

- 52 -

IMS_SIP_NSN0910 Special Course

The Serving Gateway (S-GW)

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)]

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

- 53 -

IMS_SIP_NSN0910 Special Course

S-GW Interfaces & Protocols

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

- 54 -

IMS_SIP_NSN0910 Special Course

S-GW Interfaces & Protocols


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)]

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

- 55 -

IMS_SIP_NSN0910 Special Course

The PDN Gateway (P-GW)

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

- 56 -

IMS_SIP_NSN0910 Special Course

The PDN Gateway (P-GW)

Termination towards of PDNs


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

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

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

- 57 -

IMS_SIP_NSN0910 Special Course

P-GW Interfaces & Protocols

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

- 58 -

IMS_SIP_NSN0910 Special Course

P-GW Interfaces & Protocols


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)]

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

- 59 -

IMS_SIP_NSN0910 Special Course

Enhanced Packet Data Gateway (ePDG) Interfaces &


Protocols

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

- 60 -

IMS_SIP_NSN0910 Special Course

Enhanced Packet Data Gateway (ePDG) Interfaces &


Protocols
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)]

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

- 61 -

IMS_SIP_NSN0910 Special Course

Distinction Trusted vs. Non-Trusted Non-3GPP RAT's

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

- 62 -

IMS_SIP_NSN0910 Special Course

Distinction Trusted vs. Non-Trusted Non-3GPP RAT's


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)]

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

- 63 -

IMS_SIP_NSN0910 Special Course

Distinction Trusted vs. Non-Trusted Non-3GPP RAT's

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

- 64 -

IMS_SIP_NSN0910 Special Course

Distinction Trusted vs. Non-Trusted Non-3GPP RAT's


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)]

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

- 65 -

IMS_SIP_NSN0910 Special Course

e-UTRAN eHRPD Roaming Architecture

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

- 66 -

IMS_SIP_NSN0910 Special Course

e-UTRAN eHRPD Roaming Architecture


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.

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

- 67 -

IMS_SIP_NSN0910 Special Course

and the Protocol Stack with HRPD RAT

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

- 68 -

IMS_SIP_NSN0910 Special Course

and the Protocol Stack with HRPD RAT


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.

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

- 69 -

IMS_SIP_NSN0910 Special Course

Security Architecture Overview & Introduction

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

- 70 -

IMS_SIP_NSN0910 Special Course

Security Architecture Overview & Introduction


Please note that eNodeB also includes home eNodeB's.

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

- 71 -

IMS_SIP_NSN0910 Special Course

Security Architecture Overview & Introduction

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

- 72 -

IMS_SIP_NSN0910 Special Course

Security Architecture Overview & Introduction


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

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

- 73 -

IMS_SIP_NSN0910 Special Course

The Authentication Quintuplet of UMTS- and IMS-AKA

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

- 74 -

IMS_SIP_NSN0910 Special Course

The Authentication Quintuplet of UMTS- and IMS-AKA


Abbreviations:
AKA: ______________________________________________________________________

XRES (32 .. 128 bit): __________________________________________________________

RAND (128 bit): ______________________________________________________________

CK (128 bit): _________________________________________________________________

IK (128 bit): _________________________________________________________________

AK (48 bit): __________________________________________________________________

AMF (16 bit): ________________________________________________________________

SQN (48 bit): ________________________________________________________________

MAC (64 bit): ________________________________________________________________

AUTN: ______________________________________________________________________

AK

IK

AK is used to conceal SQN.

Used for integrity protection.

AMF

RAND

AMF is used as input parameter to generate the MAC

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

AUTN

XRES

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

Authentication Response which is calculated from RAND and Ki

CK

MAC

Used for encryption between RNC and UE in UMTS-networks

Used for Network Authorization towards the MS/UE.

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

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

- 75 -

IMS_SIP_NSN0910 Special Course

Key Derivation Function (KDF) for K(ASME) Rel.8

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

- 76 -

IMS_SIP_NSN0910 Special Course

Key Derivation Function (KDF) for K(ASME) Rel.8


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)]

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

- 77 -

IMS_SIP_NSN0910 Special Course

EPS-AKA during Initial Attach Procedure

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

- 78 -

IMS_SIP_NSN0910 Special Course

EPS-AKA during Initial Attach Procedure

Intentionally left blank

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

- 79 -

IMS_SIP_NSN0910 Special Course

EPS-AKA during Initial Attach Procedure (cont.)

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

- 80 -

IMS_SIP_NSN0910 Special Course

EPS-AKA during Initial Attach Procedure (cont.)

Intentionally left blank

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

- 81 -

IMS_SIP_NSN0910 Special Course

EPS-AKA during Initial Attach Procedure (cont.)

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

- 82 -

IMS_SIP_NSN0910 Special Course

EPS-AKA during Initial Attach Procedure (cont.)

Intentionally left blank

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

- 83 -

IMS_SIP_NSN0910 Special Course

The Use of EAP-AKA' Authenticaton for eHRPD

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

- 84 -

IMS_SIP_NSN0910 Special Course

The Use of EAP-AKA' Authenticaton for eHRPD

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]

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

- 85 -

IMS_SIP_NSN0910 Special Course

The Use of EAP-AKA' Authenticaton for eHRPD (cont.)

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

- 86 -

IMS_SIP_NSN0910 Special Course

The Use of EAP-AKA' Authenticaton for eHRPD (cont.)

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]

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

- 87 -

IMS_SIP_NSN0910 Special Course

IPv6 Protocol Elements Inherited from IPv4

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

- 88 -

IMS_SIP_NSN0910 Special Course

IPv6 Protocol Elements Inherited from IPv4


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]

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

- 89 -

IMS_SIP_NSN0910 Special Course

The IPv6 Protocol Format

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

- 90 -

IMS_SIP_NSN0910 Special Course

The IPv6 Protocol Format


With the increasing transmission and processing speed of todays 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 didnt 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 packets 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 packets 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]

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

- 91 -

IMS_SIP_NSN0910 Special Course

The IPv6 Address Types

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

- 92 -

IMS_SIP_NSN0910 Special Course

The IPv6 Address Types


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)]
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

- 93 -

IMS_SIP_NSN0910 Special Course

IPv6 Address Notation

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

- 94 -

IMS_SIP_NSN0910 Special Course

IPv6 Address Notation


care needs to be taken with shortcut forms as this colon separation is very similar to port notations.

[RFC 2373, RFC 4291]

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

- 95 -

IMS_SIP_NSN0910 Special Course

IPv6 Address Configuration Options

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

- 96 -

IMS_SIP_NSN0910 Special Course

IPv6 Address Configuration Options


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.

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

- 97 -

IMS_SIP_NSN0910 Special Course

High Level View at the IMS and its Environment

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

- 98 -

IMS_SIP_NSN0910 Special Course

High Level View at the IMS and its Environment


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

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 IMSs 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 PDAs, supporting various different IP-CANs. 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.

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

- 99 -

IMS_SIP_NSN0910 Special Course

What is the IMS?

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

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

- 100 -

IMS_SIP_NSN0910 Special Course

What is the IMS?

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 clients presence and location

The IMS has originally been developed by the 3GPP for use in mobile networks

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

- 101 -

IMS_SIP_NSN0910 Special Course

Involved Standards Organizations

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

- 102 -

IMS_SIP_NSN0910 Special Course

Involved Standards Organizations


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
NGNs 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 TVcables, 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 ISPs and fixed line telecom operators.

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

- 103 -

IMS_SIP_NSN0910 Special Course

The 3GPP-Version of the IMS

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-CANs which are supported by the 3GPPrecommendations
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.

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

- 104 -

IMS_SIP_NSN0910 Special Course

The 3GPP-Version of the IMS


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-CANs 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).

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

- 105 -

IMS_SIP_NSN0910 Special Course

Architectural Overview (Network Perspective)

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

- 106 -

IMS_SIP_NSN0910 Special Course

Architectural Overview (Network Perspective)


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 UEs 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]

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

- 107 -

IMS_SIP_NSN0910 Special Course

And what is inside the IMS?

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

- 108 -

IMS_SIP_NSN0910 Special Course

And what is inside the IMS?


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]

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

- 109 -

IMS_SIP_NSN0910 Special Course

The Perspective of the 3GPP-User Agent ( Mobile Station)

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

- 110 -

IMS_SIP_NSN0910 Special Course

The Perspective of the 3GPP-User Agent ( Mobile Station)

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

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

- 111 -

IMS_SIP_NSN0910 Special Course

Overview of the other IMS-Approaches

TISPAN

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

- 112 -

IMS_SIP_NSN0910 Special Course

Overview of the other IMS-Approaches


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.
Abbreviations:
DSLAM: ____________________________________________________________________

PES: _______________________________________________________________________

NASS: ______________________________________________________________________

RACS: _____________________________________________________________________

PDBF: ______________________________________________________________________

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 UEs
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]

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

- 113 -

IMS_SIP_NSN0910 Special Course

Some Remarks on the TISPAN NGN-Solution

TISPAN views the IMS only as an important portion of its overall NGNArchitecture
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, TISPANs 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-CANs
In that respect, TISPAN leaves all IMS-related specification changes to 3GPP. TISPAN only formulates
their requirements.

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

- 114 -

IMS_SIP_NSN0910 Special Course

Some Remarks on the TISPAN NGN-Solution

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-CANs
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 TISPANs initial focus on DSL as access network solution and not on IMS-based service provision for legacy telephones (POTS)?

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

- 115 -

IMS_SIP_NSN0910 Special Course

3GPP2

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

- 116 -

IMS_SIP_NSN0910 Special Course

3GPP2
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.
Abbreviations:
PDS: _______________________________________________________________________

PDSN: ______________________________________________________________________

[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]

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

- 117 -

IMS_SIP_NSN0910 Special Course

Some Remarks on the 3GPP2 IMS-Solution

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

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

- 118 -

IMS_SIP_NSN0910 Special Course

Some Remarks on the 3GPP2 IMS-Solution

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.

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

- 119 -

IMS_SIP_NSN0910 Special Course

Cable Labs

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

- 120 -

IMS_SIP_NSN0910 Special Course

Cable Labs

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]

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

- 121 -

IMS_SIP_NSN0910 Special Course

DSL Forum

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

- 122 -

IMS_SIP_NSN0910 Special Course

DSL-Forum
We illustrate the DSL-forums efforts mainly from the perspective of ISPs. Still, the DSL-forums 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 ISPs premises are usually behind the telecom operators DSLAM and IP-network.
Similarly to cable TV operators, some ISPs already compete against the telecom operators for POTS and therefore these ISPs 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]

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

- 123 -

IMS_SIP_NSN0910 Special Course

Performance Figures of the Different IP-CANs

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

- 124 -

IMS_SIP_NSN0910 Special Course

Performance Figures of the Different IP-CANs


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.

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

- 125 -

IMS_SIP_NSN0910 Special Course

(1) Summary & Conclusions

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.

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

- 126 -

IMS_SIP_NSN0910 Special Course

(1) Summary & Conclusions


Chances of the Different Players
Telecom Operator
Mobile Telecom Operator
CableTV Operator
ISP

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

- 127 -

IMS_SIP_NSN0910 Special Course

(2) Summary & Conclusions

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.

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

- 128 -

IMS_SIP_NSN0910 Special Course

(2) Summary & Conclusions


Wireless vs. Wireline Technologies
It is like the older rabbit / turtle race: Whenever the wireless standards have advanced to yesterdays 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/Irequirement 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 competitors access network (DSL).
How shall such an operator type be successful in the long run?

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

- 129 -

IMS_SIP_NSN0910 Special Course

The Service Perspective of the IMS

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

- 130 -

IMS_SIP_NSN0910 Special Course

The Service Perspective of the IMS


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

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

- 131 -

IMS_SIP_NSN0910 Special Course

Conversational Services

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

- 132 -

IMS_SIP_NSN0910 Special Course

Conversational Services
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 ISPs.

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

- 133 -

IMS_SIP_NSN0910 Special Course

Audiovisual Entertainment Services

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

- 134 -

IMS_SIP_NSN0910 Special Course

Audiovisual Entertainment Services


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 CDs and DVDs.

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

- 135 -

IMS_SIP_NSN0910 Special Course

Services Enablers

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

- 136 -

IMS_SIP_NSN0910 Special Course

Service Enablers
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!

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

- 137 -

IMS_SIP_NSN0910 Special Course

Triple Play and Quadruple Play

Initial Situation

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

- 138 -

IMS_SIP_NSN0910 Special Course

Triple Play and Quadruple Play


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: ISPs 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 ISPs 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, ISPs were the first ones to cannibalize part of the business of another type of operator.

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

- 139 -

IMS_SIP_NSN0910 Special Course

Triple Play

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

- 140 -

IMS_SIP_NSN0910 Special Course

Triple Play
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.

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

- 141 -

IMS_SIP_NSN0910 Special Course

Quadruple Play

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

- 142 -

IMS_SIP_NSN0910 Special Course

Quadruple Play
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.

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

- 143 -

IMS_SIP_NSN0910 Special Course

Conclusions

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-CANs offer an essentially different performance in


terms of throughput and QoS
Both Characteristics throughput and QoS are crucial for the success of an operators 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.

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

- 144 -

IMS_SIP_NSN0910 Special Course

Conclusions

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

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

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

- 145 -

IMS_SIP_NSN0910 Special Course

Practical Exercise:

Please fill in the missing node, network and domain names


Consider the constraints listed on the text page to resolve the issue.

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

- 146 -

IMS_SIP_NSN0910 Special Course


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.

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

- 147 -

IMS_SIP_NSN0910 Special Course

Description of the IMS-Network Architecture

Overview

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

- 148 -

IMS_SIP_NSN0910 Special Course

Description of the IMS-Network Architecture


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-CSCFs 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: ____________________________________________________________________

HSS: _______________________________________________________________________

X-CSCF: ____________________________________________________________________

MGCF: _____________________________________________________________________

PDF: _______________________________________________________________________

MRFC: _____________________________________________________________________

ISC-Interface: ________________________________________________________________

MGW: ______________________________________________________________________

BGCF: ______________________________________________________________________

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

- 149 -

IMS_SIP_NSN0910 Special Course

Detailed View

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

- 150 -

IMS_SIP_NSN0910 Special Course

Detailed View
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.

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

- 151 -

IMS_SIP_NSN0910 Special Course

P-CSCF (Proxy Call Session Control Function)


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

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

- 152 -

IMS_SIP_NSN0910 Special Course

P-CSCF (Proxy Call Session Control Function)


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 CSCFs 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 UEs. [3GTS 24.229 (5.1.1.5),
33.203 (6), RFC 3310]

[3GTS 23.228 (4.6.1)]

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

- 153 -

IMS_SIP_NSN0910 Special Course

Tasks & Functions (continued)

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

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

- 154 -

IMS_SIP_NSN0910 Special Course

Tasks & Functions (continued)

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)]

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

- 155 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases

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

- 156 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases


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)]

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

- 157 -

IMS_SIP_NSN0910 Special Course

P-CSCF Involvement during Registration

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

- 158 -

IMS_SIP_NSN0910 Special Course

P-CSCF Involvement during Registration

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 subscribers 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: 401Unauthorized 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 SIPs 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]

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

- 159 -

IMS_SIP_NSN0910 Special Course

P-CSCF Involvement for Session Setup and Policing

Step 1: Session Start

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

- 160 -

IMS_SIP_NSN0910 Special Course

P-CSCF Involvement for Session Setup and Policing


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)]

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

- 161 -

IMS_SIP_NSN0910 Special Course

Step 2: Media Tunnel Establishment

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

- 162 -

IMS_SIP_NSN0910 Special Course

Step 2: Media Tunnel Establishment


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 IPCAN-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) PDPcontext [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 UAs authorization to activate a realtime 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-CANs, the GGSN also includes the PEP [3GTS 29.209 (4)].

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

- 163 -

IMS_SIP_NSN0910 Special Course

Step 3: Media Tunnel Established

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

- 164 -

IMS_SIP_NSN0910 Special Course

Step 3: Media Tunnel Established


The figure emphasizes the tunnel character of the real-time bearer through the IP-CAN. The figure also illustrates the independence of the X-CSCFs from
the media streams.

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

- 165 -

IMS_SIP_NSN0910 Special Course

Step 4: Preconditions fulfilled / Confirmation on SIP-Layer

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

- 166 -

IMS_SIP_NSN0910 Special Course

Step 4: Preconditions fulfilled / Confirmation on SIP-Layer


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.

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

- 167 -

IMS_SIP_NSN0910 Special Course

Example: Resource Reservation if IP-CAN = GERAN/UTRAN

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

- 168 -

IMS_SIP_NSN0910 Special Course

Example: Resource Reservation if IP-CAN = GERAN/UTRAN

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 QoSparameters 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]

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

- 169 -

IMS_SIP_NSN0910 Special Course

and the change with LTE / SAE

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

- 170 -

IMS_SIP_NSN0910 Special Course

and the change with LTE / SAE


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)]

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

- 171 -

IMS_SIP_NSN0910 Special Course

and the change with LTE / SAE (cont.)

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

- 172 -

IMS_SIP_NSN0910 Special Course

and the change with LTE / SAE (cont.)


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: ERAB_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)]

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

- 173 -

IMS_SIP_NSN0910 Special Course

P-CSCF Involvement during Ungraceful Session Release

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

- 174 -

IMS_SIP_NSN0910 Special Course

P-CSCF Involvement during Ungraceful Session Release

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 wont 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]

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

- 175 -

IMS_SIP_NSN0910 Special Course

P-CSCF Interworking with the TrGw

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

- 176 -

IMS_SIP_NSN0910 Special Course

P-CSCF Interworking with the TrGw


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.

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

- 177 -

IMS_SIP_NSN0910 Special Course

Facts Sheet

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

- 178 -

IMS_SIP_NSN0910 Special Course

Facts Sheet
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
CSCFs; 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: P-CSCF_No1@operator.com).
[3GTS 23.228 (4.6.1)]

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

- 179 -

IMS_SIP_NSN0910 Special Course

I-CSCF (Interrogating Call Session Control Function)


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.

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

- 180 -

IMS_SIP_NSN0910 Special Course

I-CSCF (Interrogating Call Session Control Function)


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 DIAMETERprotocol 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-CSCFs will be in the communication chain.

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

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

- 181 -

IMS_SIP_NSN0910 Special Course

Tasks & Functions (continued)

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

May need to act as IMS-ALG


This becomes necessary if IP-version or NAT-Interworking are required in the SIP-signaling plane.

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

- 182 -

IMS_SIP_NSN0910 Special Course

Tasks & Functions (continued)

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 NATinterworking 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 operators domain.

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

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

- 183 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases

I-CSCF Involvement during UA Registration ( Initial UE-Authorization and


S-CSCF Assignment)

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

- 184 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases


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?

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

- 185 -

IMS_SIP_NSN0910 Special Course

I-CSCF Involvement during IMS-Incoming Transactions

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

- 186 -

IMS_SIP_NSN0910 Special Course

I-CSCF Involvement during IMS-Incoming Transactions


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 / SCSCF) 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:user-A@telcom.nz 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 operators 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)]

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

- 187 -

IMS_SIP_NSN0910 Special Course

Topology Hiding through the I-CSCF

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

- 188 -

IMS_SIP_NSN0910 Special Course

Topology Hiding through the I-CSCF


Tokenization
The figure illustrates the impact and meaning of topology hiding within SIP-messages that leave an IMS towards external networks or IP-CANs. 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 Viaentries 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)]

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

- 189 -

IMS_SIP_NSN0910 Special Course

TrGw-Interworking and Operation as IMS-ALG (with NAT)

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

- 190 -

IMS_SIP_NSN0910 Special Course

TrGw-Interworking and Operation as IMS-ALG (with NAT)

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 IPaddress 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 IMSinternal 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.

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

- 191 -

IMS_SIP_NSN0910 Special Course

Facts Sheet

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

- 192 -

IMS_SIP_NSN0910 Special Course

Facts Sheet
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 IMSs, 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 CSCFs. 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: I-CSCF_No1@operator.com).
[3GTS 23.228 (4.6.2)]

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

- 193 -

IMS_SIP_NSN0910 Special Course

S-CSCF (Serving Call Session Control Function)


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

- 194 -

IMS_SIP_NSN0910 Special Course

S-CSCF (Serving Call Session Control Function)


Tasks & Functions

Represents the Registrar within the IMS


There may be multiple S-CSCFs 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)]

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

- 195 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases of the S-CSCF

Involvement during IMS-Originating Transactions

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

- 196 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases of the S-CSCF


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 IPCAN 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 IPCAN 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 circuitswitched 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.

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

- 197 -

IMS_SIP_NSN0910 Special Course

Involvement during IMS-Terminating Session

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

- 198 -

IMS_SIP_NSN0910 Special Course

Involvement during IMS-Terminating Session


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 UAs which are registered in that S-CSCF. Note that such voice calls first enter in the circuitswitched 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-CANs and different P-CSCFs 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.

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

- 199 -

IMS_SIP_NSN0910 Special Course

Facts Sheet

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

- 200 -

IMS_SIP_NSN0910 Special Course

Facts Sheet
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 CSCFs.
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: S-CSCF_No1@operator.com).
[3GTS 23.228 (4.6.3)]

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

- 201 -

IMS_SIP_NSN0910 Special Course

BGCF (Breakout Gateway Control Function)


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.

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

- 202 -

IMS_SIP_NSN0910 Special Course

BGCF (Breakout Gateway Control Function)


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)]

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

- 203 -

IMS_SIP_NSN0910 Special Course

Use Case of the BGCF

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

- 204 -

IMS_SIP_NSN0910 Special Course

Use Case of the BGCF


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

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

- 205 -

IMS_SIP_NSN0910 Special Course

Facts Sheet

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

- 206 -

IMS_SIP_NSN0910 Special Course

Facts Sheet
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: BGCF_No1@operator.com).
[3GTS 23.228 (4.6.4)]

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

- 207 -

IMS_SIP_NSN0910 Special Course

MGCF (Media Gateway Control Function) / MGW (IMS-MGW)


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.

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

- 208 -

IMS_SIP_NSN0910 Special Course

MGCF (Media Gateway Control Function) / MGW (IMS-MGW)


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 IMSs, 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)]

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

- 209 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases of the MGCF and the IMS-MGW

Involvement during IMS-MOC towards PSTN or CS-Domain

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

- 210 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases of the MGCF and the IMS-MGW


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

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

- 211 -

IMS_SIP_NSN0910 Special Course

Involvement during IMS-MTC from PSTN or CS-Domain

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

- 212 -

IMS_SIP_NSN0910 Special Course

Involvement during IMS-MTC from PSTN or CS-Domain


The figure illustrates how the MGCF and the IMS-MGW handle IMS-MTCs (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 IMSMGW 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-CSCFs 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.

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

- 213 -

IMS_SIP_NSN0910 Special Course

Facts Sheet MGCF

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

- 214 -

IMS_SIP_NSN0910 Special Course

Facts Sheet MGCF


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 ( Mninterface) 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: MGCF_No1@operator.com) for communication with SIP-UAs but it also requires
CCS7-identifiers like MSCs do. Those are E.164-based.

[3GTS 23.002 (4a.7.2)]

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

- 215 -

IMS_SIP_NSN0910 Special Course

Facts Sheet IMS-MGW (IMS-Media Gateway)

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

- 216 -

IMS_SIP_NSN0910 Special Course

Facts Sheet IMS-MGW (IMS-Media Gateway)


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)]

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

- 217 -

IMS_SIP_NSN0910 Special Course

MRF (Multimedia Resource Function)


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 UAs within and outside the IMS.

Chatroom Server
The MRF may be equipped with SIP-URIs 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).

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

- 218 -

IMS_SIP_NSN0910 Special Course

MRF (Multimedia Resource Function)


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)]

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

- 219 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases of the MRF (MRFC and MRFP)

Involvement during chat-room based instant messaging

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

- 220 -

IMS_SIP_NSN0910 Special Course

Typical Use Cases of the MRF (MRFC and MRFP)


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-CSCFs. As illustrated, all users come from different IP-CANs and therefore they use different P-CSCFs. However, the
users at bullet 1b and 1c at least share the same S-CSCF. The SDP in the INVITEs 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
UAs. What is not shown is the remaining session setup through SIP in which the MRFC informs the UAs 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 UAs 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?

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

- 221 -

IMS_SIP_NSN0910 Special Course

Announcement Playing

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

- 222 -

IMS_SIP_NSN0910 Special Course

Announcement Playing
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.

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

- 223 -

IMS_SIP_NSN0910 Special Course

Facts Sheet MRFC (Multimedia Resource Function Controller)

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

- 224 -

IMS_SIP_NSN0910 Special Course

Facts Sheet MRFC (Multimedia Resource Function Controller)


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: MRFC_No1@operator.com). The MRFC may also incorporate various public
service identities to identify different chatrooms which are also SIP-URIs.

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

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

- 225 -

IMS_SIP_NSN0910 Special Course

Facts Sheet MRFP (Multimedia Resource Function Processor)

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

- 226 -

IMS_SIP_NSN0910 Special Course

Facts Sheet MRFP (Multimedia Resource Function Processor)


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-CANs and PDNs (Packet Data Networks) ( Mbinterface) 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: MRFC_No1@operator.com). The MRFC may also incorporate various public
service identities to identify different chatrooms which are also SIP-URIs.
[3GTS 23.002 (4A.7.4a), 3GTS 23.218 (8), 23.228 (4.7)]

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

- 227 -

IMS_SIP_NSN0910 Special Course


Bootcamp Intorduction

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

- 228 -

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

- 229 -

IMS_SIP_NSN0910 Special Course

And where are SIP, SDP and all the other Protocols used?

The figure illustrates which components within 3GPP-based NGNs 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.

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

- 230 -

IMS_SIP_NSN0910 Special Course

And where are SIP, SDP and all the other Protocols used?
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 3GPPs 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- Dxand 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-CSCFs. The
reason is that all these IMS-specific servers are nothing else but SIP-proxy servers with special functions.

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

- 231 -

IMS_SIP_NSN0910 Special Course

Protocols within the IMS-Control Plane

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

- 232 -

IMS_SIP_NSN0910 Special Course

Protocols within the IMS-Control Plane


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 3GPPs 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 PoCservice [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.

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

- 233 -

IMS_SIP_NSN0910 Special Course

Protocols within the IMS-User Plane

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

- 234 -

IMS_SIP_NSN0910 Special Course

Protocols within the IMS-User Plane


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 3GPPUTRAN / GERAN this would be session management.

QoS-Control Protocols
Different IP-transport networks may support different QoS-control protocols like IntServ, DiffServ or MPLS.

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

- 235 -

IMS_SIP_NSN0910 Special Course

Some details of the DIAMETER Protocol

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

- 236 -

IMS_SIP_NSN0910 Special Course

Some details of the DIAMETER Protocol


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 3GPPs
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

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

- 237 -

IMS_SIP_NSN0910 Special Course

DIAMETER Overview

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

- 238 -

IMS_SIP_NSN0910 Special Course

DIAMETER Overview
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.

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

- 239 -

IMS_SIP_NSN0910 Special Course

IMS-specific Amendments to DIAMETER Protocol

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

- 240 -

IMS_SIP_NSN0910 Special Course

IMS-specific Amendments to DIAMETER Protocol


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]

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

- 241 -

IMS_SIP_NSN0910 Special Course

Selected Diameter Commands used by IMS

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

- 242 -

IMS_SIP_NSN0910 Special Course

Selected Diameter Commands used by IMS


some Diameter commands which are important to IMS.
3GTS 29.229, 3GTS 29.329

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

- 243 -

IMS_SIP_NSN0910 Special Course

RTP / RTCP

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

- 244 -

IMS_SIP_NSN0910 Special Course

RTP / RTCP
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-IDs, 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.

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

- 245 -

IMS_SIP_NSN0910 Special Course

The Real Time Transport Protocol (RTP and RTCP)

Operation of RTP and RTCP

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

- 246 -

IMS_SIP_NSN0910 Special Course

The Real Time Transport Protocol (RTP and RTCP)


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

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

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

- 247 -

IMS_SIP_NSN0910 Special Course

(1) Format of the RTP-Header

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

- 248 -

IMS_SIP_NSN0910 Special Course

(1) Format of the RTP-Header


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 CSRCs are included in the header. Between 0 and 15 CSRCs are possible.
Note that in UMTS on the Nb- and Iu-cs-interface, no CSRCs 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]

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

- 249 -

IMS_SIP_NSN0910 Special Course

(2) Format of the RTP-Header

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

- 250 -

IMS_SIP_NSN0910 Special Course

(2) Format of the RTP-Header


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 SDPelements 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]

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

- 251 -

IMS_SIP_NSN0910 Special Course

(3) Format of the RTP-Header

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

- 252 -

IMS_SIP_NSN0910 Special Course

(3) Format of the RTP-Header


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 CSRCs of which each is 32 bit long. CSRCs 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]

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

- 253 -

IMS_SIP_NSN0910 Special Course

Example of an RTP-Frame

Even destination port number for RTP


RTP-Port Number = 2 * x
related RTCP-port number = 2 * x + 1
No CRSCs:
Content
stems from only
one source.

Length of the entire UDP-frame (incl. header / 8 octets).


Considering the RTP-header length of 12 octets, the RTPframe contains 160 data octets.

A-law encoded PCM (as


selected by the user)

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

- 254 -

IMS_SIP_NSN0910 Special Course

Example of an RTP-Frame

Intentionally left blank

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

- 255 -

IMS_SIP_NSN0910 Special Course

Tasks and Functions of RTCP

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

- 256 -

IMS_SIP_NSN0910 Special Course

Tasks and Functions of RTCP


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. Peter.Smith@inacon.de) or an IP-address.

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

- 257 -

IMS_SIP_NSN0910 Special Course

Example of an RTCP-Frame (Sender Report)

Who sent this


Sender Report
The 1.SSRC of
the Destination
of this Sender
Report (in this
case, only one
SSRC exists)

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

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

- 258 -

IMS_SIP_NSN0910 Special Course

Example of an RTCP-Frame (Sender Report)

Intentionally left blank

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

- 259 -

IMS_SIP_NSN0910 Special Course

The H.248- / MEGACO-Protocol

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

- 260 -

IMS_SIP_NSN0910 Special Course

The H.248- / MEGACO-Protocol


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 MSCs are replaced by MSC-Servers for the call control and MGWs 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 MGWs 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]

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

- 261 -

IMS_SIP_NSN0910 Special Course

Contexts and Terminations

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

- 262 -

IMS_SIP_NSN0910 Special Course

Contexts and Terminations


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)]

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

- 263 -

IMS_SIP_NSN0910 Special Course

The H.248 Command Set

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

- 264 -

IMS_SIP_NSN0910 Special Course

The H.248 Command Set

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)]

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

- 265 -

IMS_SIP_NSN0910 Special Course

Example of Media Gateway Operation through H.248

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

- 266 -

IMS_SIP_NSN0910 Special Course

Example of Media Gateway Operation through H.248


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.

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

- 267 -

IMS_SIP_NSN0910 Special Course

IPsec

IPsec in Transport Mode

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

- 268 -

IMS_SIP_NSN0910 Special Course

IPsec
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]

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

- 269 -

IMS_SIP_NSN0910 Special Course

IPsec in Tunnel Mode

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

- 270 -

IMS_SIP_NSN0910 Special Course

IPsec in Tunnel Mode


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 IPsecaware routers / firewalls.

[RFC 2401 / RFC 2402 / RFC 2406]

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

- 271 -

IMS_SIP_NSN0910 Special Course

VPN with IPsec in Tunnel Mode and Transport Mode

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

- 272 -

IMS_SIP_NSN0910 Special Course

VPN with IPsec in Tunnel Mode and Transport Mode


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]

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

- 273 -

IMS_SIP_NSN0910 Special Course

The IPsec Authentication Header (AH)

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

- 274 -

IMS_SIP_NSN0910 Special Course

The IPsec Authentication Header (AH)


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]

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

- 275 -

IMS_SIP_NSN0910 Special Course

The IPsec Encapsulating Security Payload (ESP)

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

- 276 -

IMS_SIP_NSN0910 Special Course

The IPsec Encapsulating Security Payload (ESP)


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]

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

- 277 -

IMS_SIP_NSN0910 Special Course

The Security Association (SA)

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

- 278 -

IMS_SIP_NSN0910 Special Course

The Security Association (SA)


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]

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

- 279 -

IMS_SIP_NSN0910 Special Course

SIP Protocol Structure

Sublayers within SIP

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

- 280 -

IMS_SIP_NSN0910 Special Course

SIP Protocol Structure


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)]

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

- 281 -

IMS_SIP_NSN0910 Special Course

SIP-Network Architecture

Overview

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

- 282 -

IMS_SIP_NSN0910 Special Course

SIP-Network Architecture
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. Thats why we hid these routers
behind shades.
Sessions towards the PSTN require by default the interaction of soft switches ( MGC + MGW).
Sessions towards external PDNs 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?

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

- 283 -

IMS_SIP_NSN0910 Special Course

User Agents

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

- 284 -

IMS_SIP_NSN0910 Special Course

User Agents
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 SIPuser device. Although below the surface these dedicated VoIP-phones are nothing more but regular computers with a simple operating system and a SIPsoftphone, 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 tomorrows 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 addon 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 UAs with RFC 3261 (18).

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

- 285 -

IMS_SIP_NSN0910 Special Course

SIP-Servers

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

- 286 -

IMS_SIP_NSN0910 Special Course

SIP-Servers
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 B2BUAs.
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, SBCs represent the combination of B2BUAs (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, B2BUAs represent SIP-proxy servers that act like user agents. That is, B2BUAs 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 B2BUAs are also used for media transversal then they become SBCs.

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

- 287 -

IMS_SIP_NSN0910 Special Course

Special SIP-Servers

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

- 288 -

IMS_SIP_NSN0910 Special Course

Special SIP-Servers
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). MGCs 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)


ALGs are no network elements by themselves nor do they represent actual SIP-servers. They are rather integral part of other network elements like NATrouters 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)]

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

- 289 -

IMS_SIP_NSN0910 Special Course

Operation of Stateless SIP-Proxy Servers

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

- 290 -

IMS_SIP_NSN0910 Special Course

Operation of Stateless SIP-Proxy Servers


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 UASs. 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 SIPRequest 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.

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

- 291 -

IMS_SIP_NSN0910 Special Course

Operation of Stateful SIP-Proxy Servers

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

- 292 -

IMS_SIP_NSN0910 Special Course

Operation of Stateful SIP-Proxy Servers


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-URIs 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)]

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

- 293 -

IMS_SIP_NSN0910 Special Course

Operation of Registrars

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

- 294 -

IMS_SIP_NSN0910 Special Course

Operation of Registrars
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 users 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)]

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

- 295 -

IMS_SIP_NSN0910 Special Course

Operation of Redirect Servers

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

- 296 -

IMS_SIP_NSN0910 Special Course

Operation of Redirect Servers


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 devices addresses that shall be contacted instead or
directly by the originating party.

Procedure Description
As illustrated in the figure, UserA sends an INVITE / sip: UserB@nebelhorn.de 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: UserB@desktop500.nebelhorn.de, 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: UserB@desktop500.nebelhorn.de 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?
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

- 297 -

IMS_SIP_NSN0910 Special Course

(1) Operation of Forking SIP-Proxy Servers (always stateful)

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

- 298 -

IMS_SIP_NSN0910 Special Course

(1) Operation of Forking SIP-Proxy Servers (always stateful)

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: Mary@inacon.com.
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: Mary@phone10.inacon.com, 2. sip: Mary@178.20.19.10 and
3. sip: Mary@pda2.inacon.com. Note that Marys 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 Marys device 2.
The session is active between User A and Marys device 2 and media data are exchanged. However, since forking occurred, the still open INVITEtransactions towards device 1 and device 3 need to be handled. Please refer to the next page.
[RFC 3261 (16.7.10)]

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

- 299 -

IMS_SIP_NSN0910 Special Course

(2) Operation of Forking SIP-Proxy Servers (always stateful)

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

- 300 -

IMS_SIP_NSN0910 Special Course

(2) Operation of Forking SIP-Proxy Servers (always stateful)

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.

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

- 301 -

IMS_SIP_NSN0910 Special Course

Operation of B2BUA and SBC

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

- 302 -

IMS_SIP_NSN0910 Special Course

Operation of B2BUA and SBC


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 B2BUAs.
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).

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

- 303 -

IMS_SIP_NSN0910 Special Course

Example: VoD-for a Mobile Client with limited Access Rates

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

- 304 -

IMS_SIP_NSN0910 Special Course

Example: VoD-for a Mobile Client with limited Access Rates


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

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

- 305 -

IMS_SIP_NSN0910 Special Course

Operation of Event Servers

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

- 306 -

IMS_SIP_NSN0910 Special Course

Operation of Event Servers


Introduction
Event servers most importantly are a specific type of SIP-ASs (Application Servers). They can be used by user agents and by other SIP-ASs (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]

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

- 307 -

IMS_SIP_NSN0910 Special Course

Soft Switches and their Controllers

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

- 308 -

IMS_SIP_NSN0910 Special Course

Soft Switches and their Controllers

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

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

- 309 -

IMS_SIP_NSN0910 Special Course

Summary

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.

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

- 310 -

IMS_SIP_NSN0910 Special Course

Summary

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.

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

- 311 -

IMS_SIP_NSN0910 Special Course

Why SIP is used and not H.323 or other Alternatives

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 RFCs and it is therefore an output of the IETF (and not of the
ITU-T or ETSI).

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

- 312 -

IMS_SIP_NSN0910 Special Course

Why SIP is used and not H.323 or other Alternatives?


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.

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

- 313 -

IMS_SIP_NSN0910 Special Course

Scope of SIP

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

- 314 -

IMS_SIP_NSN0910 Special Course

Scope of SIP
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.

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

- 315 -

IMS_SIP_NSN0910 Special Course

Philosophy of SIP-Operation

Session Establishment Phase

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

- 316 -

IMS_SIP_NSN0910 Special Course

Philosophy of SIP-Operation
Session Establishment Phase

The figure illustrates it: During the session establishment phase, the two UAs may require a number of SIP-proxy servers to route and handle session
establishment requests. At this time, we dont 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.

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

- 317 -

IMS_SIP_NSN0910 Special Course

Session Completion Phase

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

- 318 -

IMS_SIP_NSN0910 Special Course

Session Completion Phase

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.

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

- 319 -

IMS_SIP_NSN0910 Special Course

Session Active Phase

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

- 320 -

IMS_SIP_NSN0910 Special Course

Session Active Phase

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 UAs.
Note that there is no SIP-proxy in between.

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

- 321 -

IMS_SIP_NSN0910 Special Course

Comparison between SIP and HTTP

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

- 322 -

IMS_SIP_NSN0910 Special Course

Comparison between SIP and HTTP

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.

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

- 323 -

IMS_SIP_NSN0910 Special Course

Simple Example of a SIP-Scenario: VoIP Call Setup with SIP

Overview

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

- 324 -

IMS_SIP_NSN0910 Special Course

Simple Example of a SIP-Scenario: VoIP Call Setup with SIP


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

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

- 325 -

IMS_SIP_NSN0910 Special Course

Summary: Some SIP-Terminology

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

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

- 326 -

IMS_SIP_NSN0910 Special Course

Summary: Some SIP-Terminology


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

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

- 327 -

IMS_SIP_NSN0910 Special Course

Important SIP-Terminology / Step 1: Two UAs

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

- 328 -

IMS_SIP_NSN0910 Special Course

Important SIP-Terminology / Step 1: Two UAs


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 UAs 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 UAs / 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.

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

- 329 -

IMS_SIP_NSN0910 Special Course

Session (Definition)

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

- 330 -

IMS_SIP_NSN0910 Special Course

Session (Definition)
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-IDs 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.

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

- 331 -

IMS_SIP_NSN0910 Special Course

Dialog Identification (two Users / with or w/o Proxies)

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

- 332 -

IMS_SIP_NSN0910 Special Course

Dialog Identification (two Users / with or w/o Proxies)

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: 100Trying-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 UAs 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.

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

- 333 -

IMS_SIP_NSN0910 Special Course

Transaction Identification (two UAs / no Proxies)

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

- 334 -

IMS_SIP_NSN0910 Special Course

Transaction Identification (two UAs / no Proxies)


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?

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

- 335 -

IMS_SIP_NSN0910 Special Course

Example
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:acer@192.168.2.106>;tag=4169360809
To: acer <sip:acer@192.168.2.106>
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:acer@192.168.2.106>;tag=4169360809
To: acer <sip:acer@192.168.2.106>;tag=1124705376834-227754029
CSeq: 9794 REGISTER

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

- 336 -

IMS_SIP_NSN0910 Special Course

Example
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)]

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

- 337 -

IMS_SIP_NSN0910 Special Course

Relationship between SIP, the IMS and 3GPP-Networks

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

- 338 -

IMS_SIP_NSN0910 Special Course

Relationship between SIP, the IMS and 3GPP-Networks

The figure illustrates how the IMS is interconnected to the various entities and network clouds that a 3GPP-network consists of or that a 3GPPnetwork 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?

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

- 339 -

IMS_SIP_NSN0910 Special Course

Generic SIP-Servers vs. IMS-specific SIP-Servers

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

- 340 -

IMS_SIP_NSN0910 Special Course

Generic SIP-Servers vs. IMS-specific SIP-Servers


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

MGCF: _____________________________________________________________________

I-CSCF: _____________________________________________________________________

HSS: ______________________________________________________________________

BGCF: _____________________________________________________________________

AAA: ______________________________________________________________________

P-CSCF: ____________________________________________________________________

MRFC: _____________________________________________________________________

TrGw: ______________________________________________________________________

MRFP: _____________________________________________________________________

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

- 341 -

IMS_SIP_NSN0910 Special Course

The Mobiles Way to SIP Registration and SIP-Sessions

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

- 342 -

IMS_SIP_NSN0910 Special Course

The Mobiles Way to SIP Registration and SIP-Sessions


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 SIPmessages 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)]

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

- 343 -

IMS_SIP_NSN0910 Special Course

IMS-related User Identities

Private User Identity (IMPI) / Public User Identity (IMPU)

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

- 344 -

IMS_SIP_NSN0910 Special Course

IMS-related User Identities


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-URIs 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-URIs but more advanced and easier to use are SIP-URIs.

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 IMSsubscriber 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 operators host name (e.g. Vodafone.sip.co.uk) but to
inacon.de?

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

- 345 -

IMS_SIP_NSN0910 Special Course

Details of Private User Identities (IMPI)

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

- 346 -

IMS_SIP_NSN0910 Special Course

Details of Private User Identities (IMPI)

Intentionally left blank

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

- 347 -

IMS_SIP_NSN0910 Special Course

Details of Public User Identities (IMPU)

Public User Identities are based on SIP-URIs or TEL-URIs


As the figure on the previous slide illustrated, TEL-URIs are best suited to migrate your legacy phone
number to the IMS-environment while SIP-URIs 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.

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

- 348 -

IMS_SIP_NSN0910 Special Course

Details of Public User Identities (IMPU)

Intentionally left blank

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

- 349 -

IMS_SIP_NSN0910 Special Course

Use of Private and Public User Identities in REGISTER-Msgs.

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

- 350 -

IMS_SIP_NSN0910 Special Course

Use of Private and Public User Identities in REGISTER-Msgs.


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 IMPUs [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.

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

- 351 -

IMS_SIP_NSN0910 Special Course

Registration to the IMS in 3GPP-Networks (Overview)

Dependency between APN-Setting and P-CSCF-Selection

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

- 352 -

IMS_SIP_NSN0910 Special Course

Registration to the IMS in 3GPP-Networks (Overview)


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 GGSNs 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 PLMNs.
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 APNs: Can a secondary PDP-context use a different APN than the primary PDP-context?

[3GTS 24.229, 3GTS 23.060]

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

- 353 -

IMS_SIP_NSN0910 Special Course

Subscriber registers to IMS while located in H-PLMN

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

- 354 -

IMS_SIP_NSN0910 Special Course

Subscriber registers to IMS while located in H-PLMN


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)]

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

- 355 -

IMS_SIP_NSN0910 Special Course

Subscriber is Roaming

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

- 356 -

IMS_SIP_NSN0910 Special Course

Subscriber is Roaming
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)]

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

- 357 -

IMS_SIP_NSN0910 Special Course

Authentication and Security in 3GPP-based IMS

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

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

- 358 -

IMS_SIP_NSN0910 Special Course

Authentication in 3GPP-based IMS

Intentionally left blank

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

- 359 -

IMS_SIP_NSN0910 Special Course

Authenticating the Network towards the MS/UE

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

- 360 -

IMS_SIP_NSN0910 Special Course

Authenticating the Network towards the MS/UE

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 subscribers
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)]

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

- 361 -

IMS_SIP_NSN0910 Special Course

The base64-Encoding Process

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

- 362 -

IMS_SIP_NSN0910 Special Course

The base64-Encoding Process

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)]

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

- 363 -

IMS_SIP_NSN0910 Special Course

The IMS-AKA Authentication Process

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

- 364 -

IMS_SIP_NSN0910 Special Course

The IMS-AKA Authentication Process

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 subscribers 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: 401Unauthorized 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 SIPs 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]

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

- 365 -

IMS_SIP_NSN0910 Special Course

Application of IPsec between MS/UE and P-CSCF

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

- 366 -

IMS_SIP_NSN0910 Special Course

Application of IPsec between MS/UE and P-CSCF

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 its 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]

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

- 367 -

IMS_SIP_NSN0910 Special Course

(1) Registration to the IMS in 3GPP (Detailed Scenario)

Gm-Interface
SIP: REGISTER
Authorization: IMPI, IMPU
Security-Client: IPsec-Info

Mw-Interface

SIP: REGISTER
Authorization: IMPI, IMPU
Path: SIP-URI of P-CSCF

Mw-Interface

Cx-Interface

DIA: UAR [Command-Code: 300]


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)
Base64 (RAND / AUTN)
P-CSCF IPsec-Info

SIP: 401-UNAUTH (REG)


Base64 (Auth-Quintuplet)

SIP: 401-UNAUTH (REG)


Base64 (Auth-Quintuplet)

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

- 368 -

IMS_SIP_NSN0910 Special Course

(1) Registration to the IMS in 3GPP (Detailed Scenario)


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

- 369 -

IMS_SIP_NSN0910 Special Course

(2) Registration to the IMS in 3GPP (Detailed Scenario)

Gm-Interface

Mw-Interface

Mw-Interface

Cx-Interface

IPsec-tunnel
SIP: REGISTER
IMPI, IMPU
Base64 (RAND,AUTN,RES)

SIP: REGISTER
IMPI, IMPU,Path: SIP-URI P-CSCF

Base64 (RAND,AUTN,RES)

DIA: UAR [Command-Code: 300]


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 IMPUs

SIP: 200-OK (REG)


P-Associated-URI: n x IMPU
Serv-Route: S-CSCF SIP-URI

SIP: 200-OK (REG)


P-Associated-URI: n x IMPU
Serv-Route: S-CSCF SIP-URI

SIP: 200-OK (REG)


P-Associated-URI: n x IMPU
Serv-Route: S-CSCF SIP-URI

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

- 370 -

IMS_SIP_NSN0910 Special Course

(2) Registration to the IMS in 3GPP (Detailed Scenario)


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-596. 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 PCSCF.
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 SCSCF 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 users 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 IMPUs 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.

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

- 371 -

IMS_SIP_NSN0910 Special Course

(3) Registration to the IMS in 3GPP (Detailed Scenario)

Gm-Interface
IPsec-tunnel

Mw-Interface

Mw-Interface

Cx-Interface

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)

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

- 372 -

IMS_SIP_NSN0910 Special Course

(3) Registration to the IMS in 3GPP (Detailed Scenario)


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.

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

- 373 -

IMS_SIP_NSN0910 Special Course

(4) Registration to the IMS in 3GPP (Detailed Scenario)

Gm-Interface
IPsec-tunnel
SIP: NOTIFY
Public User Identities
(XML-encoded)

Mw-Interface

Mw-Interface

Cx-Interface

SIP: NOTIFY
Public User Identities (XML-encoded)

SIP: 200-OK (NOT)


SIP: 200-OK (NOT)

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

- 374 -

IMS_SIP_NSN0910 Special Course

(4) Registration to the IMS in 3GPP (Detailed Scenario)


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.

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

- 375 -

IMS_SIP_NSN0910 Special Course

(1) Transaction Identification (two UAs / with Proxies)

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

- 376 -

IMS_SIP_NSN0910 Special Course

(1) Transaction Identification (two UAs / with Proxies)


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 hops 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 branchparameter 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: INVITEmessage 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?

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

- 377 -

IMS_SIP_NSN0910 Special Course

(2) Transaction Identification (two UAs / with Proxies)

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

- 378 -

IMS_SIP_NSN0910 Special Course

(2) Transaction Identification (two UAs / with Proxies)


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-toend 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?

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

- 379 -

IMS_SIP_NSN0910 Special Course

Practical Exercise:

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:OS@10.0.0.33: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:OS2@10.0.0.32>;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:OS2@10.0.0.32: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>
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

- 380 -

IMS_SIP_NSN0910 Special Course

Notes:

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

- 381 -

IMS_SIP_NSN0910 Special Course

Transaction-specific Messaging

Option 1: Request = INVITE / Transaction = successful

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

- 382 -

IMS_SIP_NSN0910 Special Course

Transaction-specific Messaging
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: ACKmessage.
Since this Request: ACK-message is considered as a new transaction, it shall be equipped with a new branch-parameter value ( z9hG4bKAlpha2). Note that each proxy between the two UAs 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?

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

- 383 -

IMS_SIP_NSN0910 Special Course

Option 2: Request = INVITE / Transaction = unsuccessful

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

- 384 -

IMS_SIP_NSN0910 Special Course

Option 2: Request = INVITE / Transaction = unsuccessful

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)]

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

- 385 -

IMS_SIP_NSN0910 Special Course

Option 3: Request = INVITE / Transaction = cancelled

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

- 386 -

IMS_SIP_NSN0910 Special Course

Option 3: Request = INVITE / Transaction = cancelled


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, CSeqvalue 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)]

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

- 387 -

IMS_SIP_NSN0910 Special Course

Option 4: Request = REGISTER

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

- 388 -

IMS_SIP_NSN0910 Special Course

Option 4: Request = REGISTER


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 SCSCF (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: user1@operator.sip-service.net) 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?

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

- 389 -

IMS_SIP_NSN0910 Special Course

Option 5: All Other Requests

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.

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

- 390 -

IMS_SIP_NSN0910 Special Course

Option 5: All Other Requests

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)]

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

- 391 -

IMS_SIP_NSN0910 Special Course

Practical Exercise

Please fill in the missing information elements or parameters, solely based


on the information provided on this page and the previous pages.

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

- 392 -

IMS_SIP_NSN0910 Special Course

Notes:

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

- 393 -

IMS_SIP_NSN0910 Special Course

Amendments in case of more than two Peers

Overview: Forking Proxies

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

- 394 -

IMS_SIP_NSN0910 Special Course

Amendments in case of more than two Peers


Introducing Different Contact Addresses per User

A user may have registered different contact addresses to his/her registrar. In our example, the user sip: Mary@inacon.com 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-URIs are the ones that we indicate as device SIP-addresses. Note that each of these Contact:-header SIP-URIs 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: ACKs 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)]
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

- 395 -

IMS_SIP_NSN0910 Special Course

(1) Message and Parameter Details

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

- 396 -

IMS_SIP_NSN0910 Special Course

(1) Message and Parameter Details

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:Mary@phone10.inacon.com). 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:Mary@178.20.19.10). 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:Mary@phone10.inacon.com).

Alpha8
Alpha8 is the branch-parameter for the INVITE-transaction between the registrar and device 2 ( sip:Mary@178.20.19.10).

Alpha9
Alpha9 is the branch-parameter for the INVITE-transaction between the registrar and device 3 ( sip:Mary@pda2.inacon.com).

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

- 397 -

IMS_SIP_NSN0910 Special Course

(2) Message and Parameter Details

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

- 398 -

IMS_SIP_NSN0910 Special Course

(2) Message and Parameter Details


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:Mary@pda2.inacon.com). 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:Mary@phone10.inacon.com). Note that the CSeqmethod 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 ( Totag = 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:Mary@178.20.19.10). Note that the CSeq-method is
not INVITE but ACK.

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

- 399 -

IMS_SIP_NSN0910 Special Course

Summary

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

- 400 -

IMS_SIP_NSN0910 Special Course

Summary

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?

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

- 401 -

IMS_SIP_NSN0910 Special Course

SIP-Message Format

Note:

With the exception of the first line the sequence of the various header fields is arbitrary
[RFC 3261 (7.3.1)].

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

- 402 -

IMS_SIP_NSN0910 Special Course

SIP-Message Format
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 5060dec. If a secure transport layer ( TLS) is used or if SIPS (secure SIP) is used then the
default port number shall be 5061dec.

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. 200dec).
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)]

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

- 403 -

IMS_SIP_NSN0910 Special Course

SIP-Message Contents

The Request Line (Request Messages only)

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

- 404 -

IMS_SIP_NSN0910 Special Course

SIP-Message Contents
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 RequestURI 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)]

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

- 405 -

IMS_SIP_NSN0910 Special Course

(1) The Different Method-Types


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

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

- 406 -

IMS_SIP_NSN0910 Special Course

(1) The Different Method-Types


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-UASs. 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 partys 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 UAs or SIP-proxys capabilities with respect to supported coders, methodtypes, 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.

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

- 407 -

IMS_SIP_NSN0910 Special Course

(2) The Different Method-Types


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

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

- 408 -

IMS_SIP_NSN0910 Special Course

(2) The Different Method-Types


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.

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

- 409 -

IMS_SIP_NSN0910 Special Course

Address Specification / Request-URI

The tel-URI

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

- 410 -

IMS_SIP_NSN0910 Special Course

Address Specification / Request-URI


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 RFCs do not use ASN.1
[RFC 2806]

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

- 411 -

IMS_SIP_NSN0910 Special Course

The SIP(S)-URI

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

- 412 -

IMS_SIP_NSN0910 Special Course

The SIP(S)-URI

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.
baulbrause@cakao.net). 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 5060dec.

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)]

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

- 413 -

IMS_SIP_NSN0910 Special Course

The Status Line

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

- 414 -

IMS_SIP_NSN0910 Special Course

The Status Line

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)]

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

- 415 -

IMS_SIP_NSN0910 Special Course

The From: and the To: Header Fields

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

- 416 -

IMS_SIP_NSN0910 Special Course

The From: and the To: Header Fields


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 callers 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)]

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

- 417 -

IMS_SIP_NSN0910 Special Course

The Call-ID: and Max-Forwards: Header Fields

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

- 418 -

IMS_SIP_NSN0910 Special Course

The Call-ID: and Max-Forwards: Header Fields


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 70dec.
[RFC 3261 (8.1.1.4), (8.1.1.6)]

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

- 419 -

IMS_SIP_NSN0910 Special Course

The CSeq: Header Field

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

- 420 -

IMS_SIP_NSN0910 Special Course

The CSeq: Header Field


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)]

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

- 421 -

IMS_SIP_NSN0910 Special Course

The Via: Header Field

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

- 422 -

IMS_SIP_NSN0910 Special Course

The Via: Header Field


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?

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

- 423 -

IMS_SIP_NSN0910 Special Course

The Contact: Header Field

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

- 424 -

IMS_SIP_NSN0910 Special Course

The Contact: Header Field


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)]

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

- 425 -

IMS_SIP_NSN0910 Special Course

SIP-Timers

Overview

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

- 426 -

IMS_SIP_NSN0910 Special Course

SIP-Timers
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 SIPdevice.

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?

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

- 427 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAC-Side - Response: 200-OK)

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

- 428 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAC-Side - Response: 200-OK)


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 UACcore 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
Timer 1 (T1)

Value to be used between P-CSCF and UE

Value to be used between SIP-nodes within the IMS

2s

0.5 s

Timer A

Initially T1

Initially T1

Timer B

128 s

32 s

[3GTS 24.229 (7.7)]

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

- 429 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAC-Side - Response: 3XX 6XX)

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

- 430 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAC-Side - Response: 3XX 6XX)


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?

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

- 431 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAC-Side no Response received)

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

- 432 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAC-Side - no Response received)


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]

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

- 433 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAS-Side sent 3XX 6XX wait for ACK)

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

- 434 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAS-Side sent 3XX 6XX wait for ACK)


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


Value to be used between P-CSCF and UE

Value to be used between SIP-nodes within the IMS

Timer 1 (T1)

Timer

2s

0.5 s

Timer 2 (T2)

16 s

4s

Timer G

Initially T1

Initially T1

Timer H

128 s

32 s

[3GTS 24.229 (7.7)]

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

- 435 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAS-Side sent 200-OK wait for ACK)

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

- 436 -

IMS_SIP_NSN0910 Special Course

INVITE Transaction (UAS-Side sent 200-OK wait for ACK)


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


Value to be used between P-CSCF and UE

Value to be used between SIP-nodes within the IMS

Timer 1 (T1)

Timer

2s

0.5 s

Timer 2 (T2)

16 s

4s

[3GTS 24.229 (7.7)]

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

- 437 -

IMS_SIP_NSN0910 Special Course

None-INVITE Transaction (UAC-Side - Response: 2XX 6XX)

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

- 438 -

IMS_SIP_NSN0910 Special Course

None-INVITE Transaction (UAC-Side - Response: 2XX 6XX)


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

Value to be used between P-CSCF and UE

Value to be used between SIP-nodes within the IMS

2s

0.5 s

Timer E

Initially T1

Initially T1

Timer F

128 s

32 s

Timer K

17 s

5s

Timer 1 (T1)

[3GTS 24.229 (7.7)]

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

- 439 -

IMS_SIP_NSN0910 Special Course

None-INVITE Transaction (UAC-Side - no Response)

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

- 440 -

IMS_SIP_NSN0910 Special Course

None-INVITE Transaction (UAC-Side - no Response)


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

Value to be used between P-CSCF and UE

Value to be used between SIP-nodes within the IMS

Timer 1 (T1)

2s

0.5 s

Timer 2 (T2)

16 s

4s

Timer E

Initially T1

Initially T1

Timer F

128 s

32 s

[3GTS 24.229 (7.7)]

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

- 441 -

IMS_SIP_NSN0910 Special Course

None-INVITE Transaction (UAS-Side - final Response sent)

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

- 442 -

IMS_SIP_NSN0910 Special Course

None-INVITE Transaction (UAS-Side - final Response sent)


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 NoneINVITE-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
Timer 1 (T1)
Timer J

Value to be used between P-CSCF and UE

Value to be used between SIP-nodes within the IMS

2s

0.5 s

128 s

32 s

[3GTS 24.229 (7.7)]

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

- 443 -

IMS_SIP_NSN0910 Special Course

The Session Description Protocol (SDP)

Structure of SDP-Parameters within a SIP-Message (Example)

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

- 444 -

IMS_SIP_NSN0910 Special Course

The Session Description Protocol (SDP)


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]

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

- 445 -

IMS_SIP_NSN0910 Special Course

Logfile Example: Session and Media Descriptors through SDP

Connection Information:
IN = <network type>( Internet)
IP4 = <address type> ( IPv4-address)
10.0.0.32 = <connection address>

Time Information:
0 = <start time>( immediate)
0 = <end time>( no end time defined)

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.

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

- 446 -

IMS_SIP_NSN0910 Special Course

Logfile Example: Session and Media Descriptors through SDP


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.

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

- 447 -

IMS_SIP_NSN0910 Special Course

Session Description Items

Overview

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

- 448 -

IMS_SIP_NSN0910 Special Course

Session Description Items


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-sdpnew-<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]

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

- 449 -

IMS_SIP_NSN0910 Special Course

The o=-Line (Origin)

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

- 450 -

IMS_SIP_NSN0910 Special Course

The o=-Line (Origin)


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 senders 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 FQDNs (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]

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

- 451 -

IMS_SIP_NSN0910 Special Course

The c=-Line (Connection Info)

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

- 452 -

IMS_SIP_NSN0910 Special Course

The c=-Line (Connection Info)

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 FQDNs 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 dont 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)]

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

- 453 -

IMS_SIP_NSN0910 Special Course

The Meaning of SDP

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

- 454 -

IMS_SIP_NSN0910 Special Course

The Meaning of SDP

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. Natalies host computer intends to use RTP/UDP/IP as transport protocol and the
UDP-port number on the called partys computer where audio data will be sent is 3120dec. Note that port number 3121dec 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 3122dec.
The dynamic RTP-Payload Type 101 is used. This Payload Type is assigned to MPV (MPEG-Video) in the line a = rtpmap: 101 MPV.

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

- 455 -

IMS_SIP_NSN0910 Special Course

Time Description Items

Overview

The t=-Line (Time)

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

- 456 -

IMS_SIP_NSN0910 Special Course

Time Description Items


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 SDPdescription.
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]

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

- 457 -

IMS_SIP_NSN0910 Special Course

Media Description Items

Overview

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

- 458 -

IMS_SIP_NSN0910 Special Course

Media Description Items


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]

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

- 459 -

IMS_SIP_NSN0910 Special Course

The m-Line (Media Announcement)

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

- 460 -

IMS_SIP_NSN0910 Special Course

The m-Line (Media Announcement)


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 senders port number. If RTP is used, then port number shall be an even port number. Implicitly, the sender of the SDPdescription 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)]

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

- 461 -

IMS_SIP_NSN0910 Special Course

m-line Media Type Attribute (MIME) / some Examples

Media Type = application / Subtype = pdf

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

- 462 -

IMS_SIP_NSN0910 Special Course

m-line Media Type Attribute (MIME) / some Examples


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/]

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

- 463 -

IMS_SIP_NSN0910 Special Course

Media Type = message / Subtype = CPIM

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

- 464 -

IMS_SIP_NSN0910 Special Course

Media Type = message / Subtype = CPIM

The graphics illustrates the setup of an instant messaging session between two peers. Setup of a chatroom is different and described in draft-niemisimple-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]

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

- 465 -

IMS_SIP_NSN0910 Special Course

(1) m-line / Details of the Transport Protocol Types

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

- 466 -

IMS_SIP_NSN0910 Special Course

(1) m-line / Details of the Transport Protocol Types


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 mline 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]

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

- 467 -

IMS_SIP_NSN0910 Special Course

(2) m-line / Details of the Transport Protocol Types

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

- 468 -

IMS_SIP_NSN0910 Special Course

(2) m-line / Details of the Transport Protocol Types


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 MIMEmedia 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?

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

- 469 -

IMS_SIP_NSN0910 Special Course

(3) m-line / Details of the Transport Protocol Types

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

- 470 -

IMS_SIP_NSN0910 Special Course

(3) m-line / Details of the Transport Protocol Types


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]

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

- 471 -

IMS_SIP_NSN0910 Special Course

(4) m-line / Details of the Transport Protocol Types

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

- 472 -

IMS_SIP_NSN0910 Special Course

(4) m-line / Details of the Transport Protocol Types


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]

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

- 473 -

IMS_SIP_NSN0910 Special Course

Use Case Example: Floor Control (BFCP) during Push-to-Talk

Configuration of the Participants and the Floor Control Server

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

- 474 -

IMS_SIP_NSN0910 Special Course

Use Case Example: Floor Control during Push-to-Talk (BFCP)


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.

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

- 475 -

IMS_SIP_NSN0910 Special Course

BFCP-Operation during a Conference Session

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

- 476 -

IMS_SIP_NSN0910 Special Course

BFCP-Operation during a Conference Session

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.

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

- 477 -

IMS_SIP_NSN0910 Special Course

The b-Line (Bandwidth Information)

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

- 478 -

IMS_SIP_NSN0910 Special Course

The b-Line (Bandwidth Information)


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 ASbandwidth 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].

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

- 479 -

IMS_SIP_NSN0910 Special Course

Details of the Bandwidth Modifiers RR and RS

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

- 480 -

IMS_SIP_NSN0910 Special Course

Details of the Bandwidth Modifiers RR and RS

For each unidirectional RTP-session, the RTP-sender also generates SRs (Sender Reports) and the RTP-receiver generates RRs (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?

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

- 481 -

IMS_SIP_NSN0910 Special Course

a-Lines (Attributes)

Example 1: Attribute recvonly / sendonly

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

- 482 -

IMS_SIP_NSN0910 Special Course

a-Lines (Attributes)

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?

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

- 483 -

IMS_SIP_NSN0910 Special Course

Example 2: AMR-Codec Definition and Parameterization

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

- 484 -

IMS_SIP_NSN0910 Special Course

Example 2: AMR-Codec Definition and Parameterization

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]

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

- 485 -

IMS_SIP_NSN0910 Special Course

Example 3: TCP-Connection Definition

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

- 486 -

IMS_SIP_NSN0910 Special Course

Example 3: TCP-Connection Definition

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]

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

- 487 -

IMS_SIP_NSN0910 Special Course

The Offer / Answer Model

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

- 488 -

IMS_SIP_NSN0910 Special Course

The Offer / Answer Model


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 SIPmessage 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]

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

- 489 -

IMS_SIP_NSN0910 Special Course

Session Identification Parameters at both Peers

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

- 490 -

IMS_SIP_NSN0910 Special Course

Session Identification Parameters at both Peers

The figure illustrates which parameters are used at each peer (UA) to identify a session uniquely. Note that session-IDs 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.

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

- 491 -

IMS_SIP_NSN0910 Special Course

Question 2: What happens if Provisional Responses get lost?

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

- 492 -

IMS_SIP_NSN0910 Special Course

Question 2: What happens if Provisional Responses get lost?


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 INVITEmessage (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.

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

- 493 -

IMS_SIP_NSN0910 Special Course

Solution: Provide for the Option to acknowledge provisional


Responses

Indicating Support or Requirement of acknowledged provisional Responses


INVITE SIP:P.Brause@inacon.com
SIP/2.0
Via: ...
.
.
CSeq: 999 INVITE
Require:..., 100rel, ...
Sec-agree: ...
Supported: ...
.
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.

Response:
The UAS shall in its provisional
responses require that the
provisional responses be
acknowledged.

SIP/2.0 183 Session Progress


Via: ...
Require: ..., 100rel, ...
.
CSeq: 999 INVITE
RSeq: 3498
.
.
Responder confirms and
applies acknowledged
provisional responses.

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

- 494 -

IMS_SIP_NSN0910 Special Course

Solution: Provide for the Option to acknowledge provisional


Responses
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]

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

- 495 -

IMS_SIP_NSN0910 Special Course

Indicating Lacking Support for a Required Feature

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

- 496 -

IMS_SIP_NSN0910 Special Course

Indicating Lacking Support for a Required Feature


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.

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

- 497 -

IMS_SIP_NSN0910 Special Course

Using PRACK to acknowledge Provisional Responses

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

- 498 -

IMS_SIP_NSN0910 Special Course

Using PRACK to acknowledge Provisional Responses

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 CSeqnumber ( 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 PRACKs 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?

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

- 499 -

IMS_SIP_NSN0910 Special Course

Transaction Abort in Case of Lacking PRACK

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

- 500 -

IMS_SIP_NSN0910 Special Course

Transaction Abort in Case of Lacking PRACK

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: 5XXmessage (e.g. 504-Server Timeout).

[RFC 3262 (3)]

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

- 501 -

IMS_SIP_NSN0910 Special Course

Summary

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.

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

- 502 -

IMS_SIP_NSN0910 Special Course

Summary
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]

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

- 503 -

IMS_SIP_NSN0910 Special Course

Question 3: How to assure appropriate Resource Allocation in


both Ways before alerting the Called Party?

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.

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

- 504 -

IMS_SIP_NSN0910 Special Course

Question 3: How to assure appropriate Resource Allocation in


both Ways before alerting the Called Party?

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 ACKRequest 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]

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

- 505 -

IMS_SIP_NSN0910 Special Course

Answer: We define an additional Handshaking Procedure

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

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

- 506 -

IMS_SIP_NSN0910 Special Course

Answer: We define an additional Handshaking Procedure


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.

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

- 507 -

IMS_SIP_NSN0910 Special Course

Overview: Resource Management using SIP and SDP

Positive Outcome Resource Reservation successful

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

- 508 -

IMS_SIP_NSN0910 Special Course

Overview: Resource Management using SIP and SDP


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 partys 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?

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

- 509 -

IMS_SIP_NSN0910 Special Course

Negative Outcome Preconditions cannot be met

Option 1: Related SDP was contained in a SIP-Request (INVITE / UPDATE)

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

- 510 -

IMS_SIP_NSN0910 Special Course

Negative Outcome Preconditions cannot be met


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 doesnt 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?

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

- 511 -

IMS_SIP_NSN0910 Special Course

(1) Option 2: Related SDP was contained in a SIP-Response

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

- 512 -

IMS_SIP_NSN0910 Special Course

(1) Option 2: Related SDP was contained in a SIP-Response

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)]

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

- 513 -

IMS_SIP_NSN0910 Special Course

(2) Option 2: Related SDP was contained in a SIP-Response

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

- 514 -

IMS_SIP_NSN0910 Special Course

(2) Option 2: Related SDP was contained in a SIP-Response

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)]

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

- 515 -

IMS_SIP_NSN0910 Special Course

One Media Stream is rejected altogether

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

- 516 -

IMS_SIP_NSN0910 Special Course

One Media Stream is rejected altogether

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 As 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: 200OK 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.

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

- 517 -

IMS_SIP_NSN0910 Special Course

Handling the Precondition Attributes a = curr: and a = des:

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.

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

- 518 -

IMS_SIP_NSN0910 Special Course

Handling the Precondition Attributes a = curr: and a = des:


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]

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

- 519 -

IMS_SIP_NSN0910 Special Course

The new Option Tag precondition

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

- 520 -

IMS_SIP_NSN0910 Special Course

The new Option Tag precondition

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)].

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

- 521 -

IMS_SIP_NSN0910 Special Course

The m = Line / Port Number and Payload Type

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

- 522 -

IMS_SIP_NSN0910 Special Course

The m = Line / Port Number and Payload Type

Intentionally left blank

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

- 523 -

IMS_SIP_NSN0910 Special Course

Interpretation of local and remote Direction-Tags

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

- 524 -

IMS_SIP_NSN0910 Special Course

Interpretation of local and remote Direction-Tags

Intentionally left blank

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

- 525 -

IMS_SIP_NSN0910 Special Course

Interpretation of the current-status Attribute (a = curr:)

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

- 526 -

IMS_SIP_NSN0910 Special Course

Interpretation of the current-status Attribute (a = curr:)

Intentionally left blank

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

- 527 -

IMS_SIP_NSN0910 Special Course

The desired-status and confirm-status Attributes

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

- 528 -

IMS_SIP_NSN0910 Special Course

The desired-status and confirm-status Attributes

Intentionally left blank

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

- 529 -

IMS_SIP_NSN0910 Special Course

Preconditions fulfilled: the final Status

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

- 530 -

IMS_SIP_NSN0910 Special Course

Preconditions fulfilled: the final Status

Intentionally left blank

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

- 531 -

IMS_SIP_NSN0910 Special Course

Example 1: Resource Reservation if IP-CAN = GERAN/UTRAN

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

- 532 -

IMS_SIP_NSN0910 Special Course

Example 1: Resource Reservation if IP-CAN = GERAN/UTRAN

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 QoSparameters 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]

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

- 533 -

IMS_SIP_NSN0910 Special Course

Example 2: Resource Reservation if IP-CAN = WIMAX

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

- 534 -

IMS_SIP_NSN0910 Special Course

Example 2: Resource Reservation if IP-CAN = WIMAX

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 QoSparameters 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 ASNGateway (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 QoSpolicing.

For more details about DSA-procedure please refer to the INACON-book WIMAX from A-Z.

[IEEE 802.16-2005]

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

- 535 -

IMS_SIP_NSN0910 Special Course

Example 3: Resource Reservation if IP-CAN = IntServ-aware

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

- 536 -

IMS_SIP_NSN0910 Special Course

Example 3: Resource Reservation if IP-CAN = IntServ-aware

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 DSCPs 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]

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

- 537 -

IMS_SIP_NSN0910 Special Course

Example 4: Unsuccessful Outcome

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

- 538 -

IMS_SIP_NSN0910 Special Course

Example 4: Unsuccessful Outcome

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)]

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

- 539 -

IMS_SIP_NSN0910 Special Course

Summary

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

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

- 540 -

IMS_SIP_NSN0910 Special Course

Summary

Intentionally left blank

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

- 541 -

IMS_SIP_NSN0910 Special Course

Practical Exercise:

Please insert the missing messages and message parts into the following
scenario:

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

- 542 -

IMS_SIP_NSN0910 Special Course


? Question Section 30 ????

???

What happens if party B does not receive the Request: ACK-message?

Notes:

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

- 543 -

IMS_SIP_NSN0910 Special Course

Question 4: Are there any Means for Secondary Call


Treatment?
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.
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

- 544 -

IMS_SIP_NSN0910 Special Course

Question 4: Are there any Means for Secondary Call Treatment


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

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

- 545 -

IMS_SIP_NSN0910 Special Course

(1) User Busy and Do not Disturb Feature Detailed


Message Sequence Chart

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

- 546 -

IMS_SIP_NSN0910 Special Course

(1) User Busy and Do not Disturb Feature Detailed


Message Sequence Chart

Intentionally left blank

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

- 547 -

IMS_SIP_NSN0910 Special Course

(2) User Busy and Do not Disturb Feature Detailed


Message Sequence Chart

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

- 548 -

IMS_SIP_NSN0910 Special Course

(2) User Busy and Do not Disturb Feature Detailed


Message Sequence Chart

Intentionally left blank

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

- 549 -

IMS_SIP_NSN0910 Special Course

(3) User Busy and Do not Disturb Feature Detailed


Message Sequence Chart

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

- 550 -

IMS_SIP_NSN0910 Special Course

(3) User Busy and Do not Disturb Feature Detailed


Message Sequence Chart

Intentionally left blank

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

- 551 -

IMS_SIP_NSN0910 Special Course

(1) Call Forwarding Unconditional / User not Registered


Detailed Message Sequence Chart

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

- 552 -

IMS_SIP_NSN0910 Special Course

(1) Call Forwarding Unconditional / User not Registered


Detailed Message Sequence Chart

Intentionally left blank

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

- 553 -

IMS_SIP_NSN0910 Special Course

(2) Call Forwarding Unconditional / User not Registered


Detailed Message Sequence Chart

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

- 554 -

IMS_SIP_NSN0910 Special Course

(2) Call Forwarding Unconditional / User not Registered


Detailed Message Sequence Chart

Intentionally left blank

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

- 555 -

IMS_SIP_NSN0910 Special Course

(3) Call Forwarding Unconditional / User not Registered


Detailed Message Sequence Chart

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

- 556 -

IMS_SIP_NSN0910 Special Course

(3) Call Forwarding Unconditional / User not Registered


Detailed Message Sequence Chart

Intentionally left blank

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

- 557 -

IMS_SIP_NSN0910 Special Course

(1) User not Responding Detailed Message Sequence Chart

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

- 558 -

IMS_SIP_NSN0910 Special Course

(1) User not Responding Detailed Message Sequence Chart

Intentionally left blank

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

- 559 -

IMS_SIP_NSN0910 Special Course

(2) User not Responding Detailed Message Sequence Chart

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

- 560 -

IMS_SIP_NSN0910 Special Course

(2) User not Responding Detailed Message Sequence Chart

Intentionally left blank

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

- 561 -

IMS_SIP_NSN0910 Special Course

(3) User not Responding Detailed Message Sequence Chart

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

- 562 -

IMS_SIP_NSN0910 Special Course

(3) User not Responding Detailed Message Sequence Chart

Intentionally left blank

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

- 563 -

IMS_SIP_NSN0910 Special Course

(4) User not Responding Detailed Message Sequence Chart

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

- 564 -

IMS_SIP_NSN0910 Special Course

(4) User not Responding Detailed Message Sequence Chart

Intentionally left blank

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

- 565 -

IMS_SIP_NSN0910 Special Course

(5) User not Responding Detailed Message Sequence Chart

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

- 566 -

IMS_SIP_NSN0910 Special Course

(5) User not Responding Detailed Message Sequence Chart

Intentionally left blank

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

- 567 -

IMS_SIP_NSN0910 Special Course

(1) Find me / Follow me Detailed Message Sequence Chart

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

- 568 -

IMS_SIP_NSN0910 Special Course

(1) Find me / Follow me Detailed Message Sequence Chart

Intentionally left blank

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

- 569 -

IMS_SIP_NSN0910 Special Course

(2) Find me / Follow me Detailed Message Sequence Chart

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

- 570 -

IMS_SIP_NSN0910 Special Course

(2) Find me / Follow me Detailed Message Sequence Chart

Intentionally left blank

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

- 571 -

IMS_SIP_NSN0910 Special Course

(3) Find me / Follow me Detailed Message Sequence Chart

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

- 572 -

IMS_SIP_NSN0910 Special Course

(3) Find me / Follow me Detailed Message Sequence Chart

Intentionally left blank

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

- 573 -

IMS_SIP_NSN0910 Special Course

(4) Find me / Follow me Detailed Message Sequence Chart

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

- 574 -

IMS_SIP_NSN0910 Special Course

(4) Find me / Follow me Detailed Message Sequence Chart

Intentionally left blank

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

- 575 -

IMS_SIP_NSN0910 Special Course

(5) Find me / Follow me Detailed Message Sequence Chart

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

- 576 -

IMS_SIP_NSN0910 Special Course

(5) Find me / Follow me Detailed Message Sequence Chart

Intentionally left blank

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

- 577 -

IMS_SIP_NSN0910 Special Course

(6) Find me / Follow me Detailed Message Sequence Chart

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

- 578 -

IMS_SIP_NSN0910 Special Course

(6) Find me / Follow me Detailed Message Sequence Chart

Intentionally left blank

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

- 579 -

IMS_SIP_NSN0910 Special Course

(7) Find me / Follow me Detailed Message Sequence Chart

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

- 580 -

IMS_SIP_NSN0910 Special Course

(7) Find me / Follow me Detailed Message Sequence Chart

Intentionally left blank

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

- 581 -

IMS_SIP_NSN0910 Special Course

(8) Find me / Follow me Detailed Message Sequence Chart

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

- 582 -

IMS_SIP_NSN0910 Special Course

(8) Find me / Follow me Detailed Message Sequence Chart

Intentionally left blank

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

- 583 -

IMS_SIP_NSN0910 Special Course

Tackling NAT-Issues within the IMS

Introducing NAT and NAPT

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

- 584 -

IMS_SIP_NSN0910 Special Course

Tackling NAT-Issues within the IMS


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 IPnetwork 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 UDPassociations 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.

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

- 585 -

IMS_SIP_NSN0910 Special Course

Liabilities of NAT / NAPT

NAT/NAPT operates on the network and transport layer level and is unable
to consider IP-address and port number instances within upper layer PDUs
This is particularly a problem for SIP and requires the introduction of ALGs.

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.

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

- 586 -

IMS_SIP_NSN0910 Special Course

Liabilities of NAT / NAPT

NAT/NAPT operates on the network and transport layer level and is unable to consider IP-address and port number
instances within upper layer PDUs
ALGs (Application Layer Gateways) may be integral part of NAT/NAPT-routers although they do not appear as SIP-hops. Still, they check whether an IPframe which is processed within a NAT/NAPT-router contains critical protocol information like SIP/SDP. In such a case, the ALG alters also this protocols
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 NATaffected.

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.

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

- 587 -

IMS_SIP_NSN0910 Special Course

Network Configuration (UA behind two NATs)

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

- 588 -

IMS_SIP_NSN0910 Special Course

Network Configuration (UA behind two NATs)


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 ISPs 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 NATs, the indicated IP-addresses represent the outside IP-addresses. That is, the right NAT-router is also using a second private IPaddress within the 192.X.Y.Z domain.
Since we use two NATs we can assume that any number of NATs is taken care of by our considerations.

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

- 589 -

IMS_SIP_NSN0910 Special Course

Step 1: Registration behind two NATs

SIP: REGISTER-Messages

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

- 590 -

IMS_SIP_NSN0910 Special Course

Step 1: Registration behind two NATs


SIP: REGISTER-Messages
The figure illustrates how the Request: REGISTER-message which is sent by the UA behind the two NATs reaches the P-CSCF, is processed by the PCSCF 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 IPaddress. The P-CSCFs 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.

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

- 591 -

IMS_SIP_NSN0910 Special Course

SIP: 200-OK Response Message

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

- 592 -

IMS_SIP_NSN0910 Special Course

SIP: 200-OK Response Message


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 UAs 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 NATs 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 UAs 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.

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

- 593 -

IMS_SIP_NSN0910 Special Course

X-CSCF- and NAPT-Associations after Registration

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

- 594 -

IMS_SIP_NSN0910 Special Course

X-CSCF- and NAPT-Associations after Registration

Intentionally left blank

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

- 595 -

IMS_SIP_NSN0910 Special Course

Step 2: UA Originating Session Establishment behind 2 NATs

Problem Description

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

- 596 -

IMS_SIP_NSN0910 Special Course

Step 2: UA Originating Session Establishment behind 2 NATs


Problem Description
SIP-messages can flow back and forth through the NATs, 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 NATs.
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.

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

- 597 -

IMS_SIP_NSN0910 Special Course

SIP: INVITE-Message

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

- 598 -

IMS_SIP_NSN0910 Special Course

SIP: INVITE-Message
The figure illustrates how the Request: INVITE-message which is sent by the UA behind the two NATs 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 IPaddress. 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 IPframe 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 SDPportion of the Request: INVITE-message and replace the UAs 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 UAs 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.

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

- 599 -

IMS_SIP_NSN0910 Special Course

SIP: 183-Session Progress Response Message

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

- 600 -

IMS_SIP_NSN0910 Special Course

SIP: 183-Session Progress Response Message


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

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

- 601 -

IMS_SIP_NSN0910 Special Course

Audio Data Flow through the NATs UE Originating

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

- 602 -

IMS_SIP_NSN0910 Special Course

Audio Data Flow through the NATs UE Originating


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 UAs 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 IPaddress / 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.

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

- 603 -

IMS_SIP_NSN0910 Special Course

Audio Data Flow through the NATs UE Terminating

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

- 604 -

IMS_SIP_NSN0910 Special Course

Audio Data Flow through the NATs UE Terminating

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 UAs 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 NATs 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.

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

- 605 -

IMS_SIP_NSN0910 Special Course

Practical Exercise

Considering the aforementioned: If NAT is also used IMS-internally, will the I-CSCF and the P-CSCF require two
separate TrGws or is a single TrGw with NAT-function sufficient?

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

- 606 -

IMS_SIP_NSN0910 Special Course

IMS and IP-CAN use NAT / How many TrGws are required?
(Practical Exercise)

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

Source IP: ______________________________________________________


I
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


S
I
P
S
D
P

INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

S
I
P
S
D
P

INVITE
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________

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

- 607 -

IMS_SIP_NSN0910 Special Course


SIP B31

SIP B41

Source IP: ______________________________________________________


I
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


S
I
P
S
D
P

INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

SIP B51

S
I
P
S
D
P

S
D
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

SIP B42
I
P

INVITE
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________

SIP B52
Source IP: ______________________________________________________________
I
P

Destination Port: _________________________________________________


S
I
P

Source Port: ____________________________________________________________


Destination Port: _________________________________________________________

Source IP: ______________________________________________________


I
P

Destination IP: __________________________________________________________

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

S
I
P
S
D
P

183-Session Progress
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________

SIP B32

Source IP: ______________________________________________________


Destination IP: ___________________________________________________

I
P

Source IP: ______________________________________________________________


Destination IP: __________________________________________________________

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

- 608 -

IMS_SIP_NSN0910 Special Course

S
I
P
S
D
P

Source Port: _____________________________________________________

Source Port: ____________________________________________________________

Destination Port: _________________________________________________

Destination Port: _________________________________________________________

183-Session Progress
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

SIP B22

S
I
P
S
D
P

S
D
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

183-Session Progress
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

Media B11

I
P

S
I
P
S
D
P

m = : __________________________________________________________________

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________

183-Session Progress
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________

Media B21

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


R
T

c = : ___________________________________________________________________

Destination Port: _________________________________________________________

Source IP: ______________________________________________________


I
P

Contact: _______________________________________________________________

Source IP: ______________________________________________________________

Destination Port: _________________________________________________


S
I
P

Via: ___________________________________________________________________

SIP B12

Source IP: ______________________________________________________


I
P

183-Session Progress

Nothing to declare

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

R
T

Nothing to declare

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

- 609 -

IMS_SIP_NSN0910 Special Course


P

Media B31

Media B32

Source IP: ______________________________________________________


I
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


R
T
P

Nothing to declare

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

R
T
P

Nothing to declare

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

- 610 -

IMS_SIP_NSN0910 Special Course


Media B22

Media B11

Source IP: ______________________________________________________


I
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


R
T
P

Nothing to declare

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

R
T
P

Nothing to declare

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

- 611 -

IMS_SIP_NSN0910 Special Course

We continue with Option A


SIP A11

SIP A21

Source IP: ______________________________________________________


I
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


S
I
P
S
D
P

INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

S
I
P
S
D
P

INVITE
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________

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

- 612 -

IMS_SIP_NSN0910 Special Course


SIP A31

SIP A41

Source IP: ______________________________________________________


I
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


S
I
P
S
D
P

INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

SIP A51

S
I
P
S
D
P

S
D
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

SIP A42
I
P

INVITE
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________

SIP A52
Source IP: ______________________________________________________________
I
P

Destination Port: _________________________________________________


S
I
P

Source Port: ____________________________________________________________


Destination Port: _________________________________________________________

Source IP: ______________________________________________________


I
P

Destination IP: __________________________________________________________

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

S
I
P
S
D
P

183-Session Progress
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________

SIP A32

Source IP: ______________________________________________________


Destination IP: ___________________________________________________

I
P

Source IP: ______________________________________________________________


Destination IP: __________________________________________________________

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

- 613 -

IMS_SIP_NSN0910 Special Course

S
I
P
S
D
P

Source Port: _____________________________________________________

Source Port: ____________________________________________________________

Destination Port: _________________________________________________

Destination Port: _________________________________________________________

183-Session Progress
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

SIP A22

S
I
P
S
D
P

S
D
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

183-Session Progress
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________

Media A11

I
P

S
I
P
S
D
P

m = : __________________________________________________________________

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________

183-Session Progress
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________

Media A21

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


R
T

c = : ___________________________________________________________________

Destination Port: _________________________________________________________

Source IP: ______________________________________________________


I
P

Contact: _______________________________________________________________

Source IP: ______________________________________________________________

Destination Port: _________________________________________________


S
I
P

Via: ___________________________________________________________________

SIP A12

Source IP: ______________________________________________________


I
P

183-Session Progress

Nothing to declare

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

R
T

Nothing to declare

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

- 614 -

IMS_SIP_NSN0910 Special Course


P

Media A31

Media A41

Source IP: ______________________________________________________


I
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


R
T
P

Nothing to declare

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

R
T
P

Nothing to declare

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

- 615 -

IMS_SIP_NSN0910 Special Course


Media A42

Media A32

Source IP: ______________________________________________________


I
P

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


R
T
P

Nothing to declare

Media A22

R
T
P

Nothing to declare

Media A12

Destination IP: ___________________________________________________


Source Port: _____________________________________________________

Source IP: ______________________________________________________________


I
P

Destination Port: _________________________________________________


R
T
P

Source Port: ____________________________________________________________


Destination Port: _________________________________________________________

Source IP: ______________________________________________________


I
P

Destination IP: __________________________________________________________

Nothing to declare

Destination IP: __________________________________________________________


Source Port: ____________________________________________________________
Destination Port: _________________________________________________________

R
T
P

Nothing to declare

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

- 616 -

IMS_SIP_NSN0910 Special Course

Intentionally left blank

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

- 617 -

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

- 618 -

IMS_SIP_NSN0910 Special Course

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

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

- 619 -

IMS_SIP_NSN0910 Special Course

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)]

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

- 620 -

IMS_SIP_NSN0910 Special Course

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:

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

- 621 -

IMS_SIP_NSN0910 Special Course


Q: Consider that a subscriber can register the same user identity (e.g. sip: user1@operator.sip-service.net) 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: user1@operator.sip-service.net) 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:
user1@pda1000.operator.sip-service.net or sip: user1@123.321.987.987). 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 UAs 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: user1@123.321.987.987SIP/2.0
..
...
From: sip: user1@operator.sip-service.net;tag=151170
To: sip: user1@operator.sip-service.net;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

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

- 622 -

IMS_SIP_NSN0910 Special Course

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.

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

- 623 -

IMS_SIP_NSN0910 Special Course

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-URIs (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 PRACKs within an INVITE-transaction?

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

- 624 -

IMS_SIP_NSN0910 Special Course


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

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

- 625 -

IMS_SIP_NSN0910 Special Course

Answers for Question Section 24:


Q: How is it possible that Miriam has been allocated a SIP-URI that does not relate to the operators 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 APNs: 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.

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

- 626 -

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

- 627 -

IMS_SIP_NSN0910 Special Course


AAA

List of Acronyms v2.2


Term
16-QAM
1xEV-DO
1xEV-DV
2B1Q
3G ...
3GPP

3GPP2

3GTR
3GTS
4G
64-QAM
8-PSK
8VSB
A&S
A/V
AA
AAA

Explanation
16 symbols Quadrature Amplitude Modulation (3GTS
25.213)
One Carrier (1.25 MHz) Evolution - Data Only
(cdma2000)
One Carrier (1.25 MHz) Evolution - Data and Voice
Two Binary One Quaternary (Line Coding used on the
ISDN U-Interface)
3rd Generation ...
Third Generation Partnership Project (Collaboration
between different standardization organizations (e.g.
ARIB, ETSI) to define advanced mobile
communications standards, responsible for UMTS)
Third Generation Partnership Project 2 (similar to
3GPP, but consisting of ANSI, TIA and EIA-41,
responsible for cdma2000, EvDO and EVDV)
3rd Generation Technical Report
3rd Generation Technical Specification
4th Generation ...
64 symbols Quadrature Amplitude Modulation
8 Symbol Phase Shift Keying
8-level Vestigial Sideband Modulation (ATSC)
Applications & Services domain or server
Audio / Video
Anonymous Access
Authentication, Authorization and Accounting

AAL
AAL-2
AAL-5
AAR
AAS
A-Bit
ABM
ABNF
AC
ACC
ACCH
ACK
ACM
ACS
ADCH
ADM
ADPCM
ADSL2
AES
AESA
AF
AG

Authorize Authenticate Answer (DIAMETER message


type)
ATM-Adaption Layer
ATM Adaptation Layer 2 (for real-time services) (ITU-T
I.363.2)
ATM-Adaptation Layer 5 (non-real time) (ITU-T I.363.5)
Authorize Authenticate Request (DIAMETER message
type)
Adaptive Antenna Systems
Acknowledgement Request Bit (used in LLC-protocol
Logical Link Control)
Asynchronous Balanced Mode
Augmented Backus Naur Form (RFC 2234)
Alternate Current
Access Control Class (3GTS 22.011)
Associated Control Channel (GSM / can be an SACCH
or an FACCH)
Acknowledgement (3GTS 25.214, 25.308, 25.309)
Address Complete Message (ISUP-message type)
Active Codec Set
Associated Dedicated Channel (3GTS 45.902)
Asynchronous Disconnected Mode
Adaptive Differential Pulse Code Modulation
Asynchronous Digital Subscriber Line 2 (ITU-T G.992.3)
Advanced Encryption Standard / Cipher Key Lengths:
128 bit, 192 bit or 256 bit
ATM End System Address
Assured Forwarding (DiffServ Term)
Absolute Grant (3GTS 25.309)

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

- 628 -

IMS_SIP_NSN0910 Special Course


AGCH
AGWN
AH
AI
AICH
AIPN
AJAX
AK
AK
AKA
ALC
ALCAP
ALG
AM
AM
AMC
AMC
AMD
AMF
AMI
AMPS
AMR
AMR-WB
AMR-WB+
ANSI

Access Grant Channel (GSM)


Additive Gaussian White Noise
Authentication Header (RFC 4302)
Acquisition Indicator
Acquisition Indicator Channel (UMTS Physical Channel)
All IP Network
Asynchronous Javascript and XML
Authentication Key (IEEE 802.16)
Anonymity Key (3GTS 33.102)
Authentication and key agreement (3GTS 33.102)
Asynchronous Layered Coding
Access Link Control Application Part (ITU-T Q.2630.1 /
Q.2630.2)
Application Layer Gateway
Acknowledged Mode operation (e.g. in UMTS-RLC)
Amplitude Modulation
Adaptive Modulation and Coding
Advanced Modulation and Coding
Acknowledged Mode Data (UMTS RLC PDU-type)
Authentication management field (3GTS 33.102)
Alternate Mark Inversion (Line Coding)
Advanced Mobile Phone System
Adaptive Multirate Encoding (3GTS 26.090)
Adaptive Multi-Rate - WideBand speech codec (3GTS
26.273, ITU-T G.722.2)
Extended Adaptive Multi-Rate - WideBand speech
codec (3GTS 26.304, 26.410, ITU-T G.722.1)
American National Standards Institute

AoD
AP
AP
AP-AICH
API
APN
APP
AR
ARFCN
ARIB
ARP
ARPU
ARQ
AS
AS
AS
ASC
ASCA
ASCI
ASCII
ASIC
AS-ILCM
ASN
ASN.1
ASN-GW

Audio on Demand
Access Point (IEEE 802.11, 802.16)
Access Preamble
CPCH Access Preamble Acquisition Indicator Channel
(UMTS Physical Channel)
Access Preamble Acquisition Indicator
Access Point Name (Reference to a GGSN)
A Posteriori Probability (Turbo Decoding)
Assured Rate PDB (DiffServ Term)
Absolute Radio Frequency Channel Number
Association of Radio Industries and Businesses
(Japanese)
Address Resolution Protocol (RFC 826)
Average Revenue Per User
Automatic Repeat Request
Application Server
Access Stratum (UMTS)
application specific (within SDP-bandwidth specification
/ b-line)
Access Service Class
Adjacent Subcarrier Allocation
Advanced Speech Call Items (GSM-R)
American Standard Code for Information Interchange
(ANSI X3.4-1986)
Application Specific Integrated Circuit
Application Server - Incoming Leg Control Model
Access Service Network
Abstract Syntax Notation 1 (ITU-T X.680 / X.681)
Access Service Network-Gateway

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

- 629 -

IMS_SIP_NSN0910 Special Course


AS-OLCM
ASP
AT_MAC
ATCA
AT-Command
ATM
ATSC
AuC
AUTN
AV
AVC
B2BUA
B8ZS
BAS
BB
BC
BCC
BCC
BCCH
BCCH
BCD
BCH
BCMCS
BCTP
BE

Application Server - Outgoing Leg Control Model


Application Server Process
Message Authentication Code
Advanced Telecommunications Computing Architecture
Attention-Command
Asynchronous Transfer Mode (ITU-T I.361)
Advanced Television System Committee
Authentication Center
Authentication Token (3GTS 33.102)
Authentication Vector (3GTS 33.102)
Advanced Video Coding
Back-to-Back User Agent (SIP term / RFC 3261, RFC
3725)
Bipolar with Eight-Zero Substitution (Line Code used at
the T1-Rate (1.544 Mbit/s))
Basic rate access ISDN-user interface for single lines (2
B-channels plus one D-Channel with 16 kbit/s)
Base Band module
Broadcast
Broadcast Call Control (3GTS 44.069)
Base Station Color Code
Broadcast Control Channel (UMTS Logical Cannel)
Broadcast Control Channel (GSM Logical Channel)
Binary Coded Decimal
Broadcast Channel (UMTS Transport Channel)
Broadcast and Multicast Services (CDMA-2000 Rev. D)
Bearer Control Tunneling Protocol (ITU-T Q.1990)
Best Effort

BEC
BEG
BER
BFCP
BFI
BG
BGCF
BIB
BIC
BICC
BLER
BMC
BM-IWF
BM-SC
BNF
BPSK
BQA
BQB
BQRB
BQTF
BR
BRAN
BS
BS_CV_MAX
BS_EIRP
BSC

Backward Error Correction


BEGin Message (TCAP)
Bit Error Rate
Binary Floor Control Protocol (draft-ietf-xcon-bfcp-05)
Bad Frame Indication
Border Gateway
Breakout Gateway Control Function
Backward Indicator Bit
Blind Interference Cancellation
Bearer Independent Call Control (ITU-T Q.1902.1 Q.1902.6)
Block Error Rate
Broadcast / Multicast Control (3GTS 25.324)
Broadcast Multicast Interworking Function
Broadcast Multicast Service Center (3GTS 23.346)
Backus Naur Form (RFC 2234)
Binary or Bipolar Phase Shift Keying
Bluetooth Qualification Administer
Bluetooth Qualification Body
Bluetooth Qualification Review Board
Bluetooth Qualification Test Facility
Bandwidth Request (WIMAX Term)
Broadband Radio Access Network
Base Station (IEEE 802.16)
Maximum Countdown Value to be used by the mobile
station (Countdown Procedure)
Base Station Effective Isotropic Radiated Power
Base Station Controller

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

- 630 -

IMS_SIP_NSN0910 Special Course


BSIC
BSN
BSS
BSSAP
BSSAP-LE
BSSGP
BSSMAP
BTAB
BTC
BTS
BVCI
BW
C/I
C/R-Bit
C/T-Field
CAI
CAMEL
CAN
CAP
CAPEX
CATV
CBC
CBC
CBC
CBCH

Base Station Identity Code


Block Sequence Number (RLC) / Backward Sequence
Number (SS7)
Base Station Subsystem
Base Station Subsystem Application Part
Base Station System Application Part - Location Based
Services Extension
Base Station System GPRS Protocol
Base Station Subsystem Mobile Application Part (3GTS
48.008)
Bluetooth Technical Advisory Board
Block Turbo Coding
Base Transceiver Station
BSSGP Virtual Connection Identifier
Bandwidth
Carrier-to-Interference Ratio (like SNR)
Command / Response Bit
logical Channel / Transport channel identification Field
Channel Assignment Indicator
Customized Applications for Mobile network Enhanced
Logic
Connectivity Access Network
CAMEL Application Part (CCS7)
Capital Expenditure
Cable TV
Cipher Block Chaining (DES-Operation Mode)
Cell Broadcast Center
Committed Burst Size
Cell Broadcast Channel (GSM)

CBMS
CC
CC
CCC
CCCH
CCCH
CCF
CCH
CCITT

CCM
CCM-Mode
CCN
CCPCH
CCS7
CCTrCH
CCU
CD
CD/CA-ICH
CDCH
CDI
CDMA

Convergence of Broadcast and Mobile Services


Call Control
Convolutional Coding
CPCH Control Command
Common Control Channel (UMTS Logical Channel)
Common Control Channel (GSM Logical Channel)
Charging Collection Function
Control Channel
Comitonsultatif International Tgraphique et
Tphonique (International Telegraph and Telephone
Consultative Committee)
Common Channel Management (Protocol Part on the
GSM Abis-Interface / 3GTS 48.058)
Counter with CBC-MAC (RFC 3610) Combined
Authentication and Encryption with AES-Algorithm
Cell Change Notification (related to Network Assisted
Cell Change / 3GTS 44.060)
Common Control Physical Channel (see also P-CCPCH
and S-CCPCH)
Common Channel Signaling System No. 7 (ITU-T Qseries of specifications, in particular Q.700 - Q.703)
Coded Composite Transport Channel (UMTS)
Channel Codec Unit
Compact Disc
Collision Detection / Channel Assignment Indicator
Channel (UMTS Physical Channel)
Control-plane Dedicated Channel (3GTS 45.902)
Collision Detection Indicator
Code Division Multiple Access

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

- 631 -

IMS_SIP_NSN0910 Special Course


CDR
CELL_DCH
CEPT
CESoP
CFN
CG
CGF
CGI
CHAP
CIC
CIC
CID
CID
CIDR
CIF
CINR
CIO
CIR
CK
CKSN
CMC
CMI
CMIP
CMR
CMTS
CN

Call Detail Record


RRC Dedicated State
Confrence Europne des Postes et Tcommunications
Circuit Emulation Services over Packet
Connection Frame Number
Charging Gateway
Charging Gateway Function
Cell Global Identification
Challenge Handshake Authentication Protocol (RFC
1334)
Circuit Identity Code (ISUP)
Call Instance Code (BICC)
Channel Identity (ATM)
Connection Identifier (WIMAX)
Classless Inter-Domain Routing (RFC 1519)
Common Intermediate Format (352 x 240 pixels / ITU-T
H261 / H263)
Carrier to Interference and Noise Ratio
Cell Individual Offset (3GTS 25.331)
Committed Information Rate
Ciphering Key (3GTS 33.102)
Ciphering Key Sequence Number
Codec Mode Command
Codec Mode Indication
Client Mobile IP
Codec Mode Request
Cable Modem Termination System
Core Network

CNR
COA
CoA
COFDM
CON
COO
COPS
CPCH
CPCS
CPE
CPICH
CPICH_Ec/No
CPIM
CPS
CPS
CPU
CQI
CQICH
CRC
CRNC
CRSC
CS
CS
CS
CS
C-SAP

Carrier to Noise Ratio


Change Over Acknowledge message (CCS7)
Care of Address (MIP)
Coded Orthogonal Frequency Division Multiplexing
CONtinue Message (TCAP)
Change Over Order message (CCS7)
Common Open Policy Service Protocol (RFC 2748)
Common Packet Channel (UMTS Transport Channel)
FDD only
Common Part Convergence Sublayer
Customer Premises Equipment
Common Pilot Channel (UMTS Physical Channel / see
also P-CPICH and S-CPICH)
Common Pilot Channel Energy per Chip to Noise Radio
Common Presence and Instant Messaging (RFC 3862)
Coding and Puncturing Scheme
Common Part Sublayer
Central Processing Unit
Channel Quality Indicator (3GTS 25.214)
Channel Quality Indicator Channel
Cyclic Redundancy Check
Controlling RNC
Contributing Source
Coding Scheme
Circuit Switched
Class Selector (DiffServ Term / RFC 2474)
Convergence Sublayer
Control Service Access Point

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

- 632 -

IMS_SIP_NSN0910 Special Course


CSCF
CSD
CSICH
CSMA-CA
CSN
CSPDN
CS-X
CTC
CTCH
CTFC
CV
CW
cwnd
DAB
DARP
DASS
DBC
dBm

DBP
DBPSCH
DC
DCCH
DCD
DCF

Call Session Control Function (SIP)


Circuit Switched Data
CPCH Status Indicator Channel (UMTS Physical
Channel)
Carrier-Sense Multiple Access - Collision Avoidance
Connectivity Service Network
Circuit Switched Public Data Network
Coding Scheme (1 - 4)
Convolutional Turbo Coding
Common Traffic Channel (Logical) PTM
Calculated Transport Format Combination (3GTS
25.331)
Countdown Value
Code Word
Congestion window
Digital Audio Broadcasting
Downlink Advanced Receiver Performance (3GPP's
adaptation of SAIC / 3GTS 45.015, 3GTS 24.008)
Digital Access Signaling System
Dynamic Bearer Control
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])
Diameter Base Protocol (RFC 3588)
Dedicated Basic Physical SubCHannel
Direct Current
Dedicated Control Channel (UMTS Logical Channel)
Downlink Channel Descriptor (WIMAX Message)
DRM Content Format

DCH
DCM
DCS
DDDS
DDI
DEC
DEMUX
DES
DF
DF
DHCP
DIA
Digit
DIUC
DL
DLCI
DLFP
DL-MAP
DLR
DLS
DMB
DNS
DOCSIS
DoS
DPC

Dedicated Channel (Transport)


Dedicated Channel Management (Protocol Part on the
GSM Abis-Interface / 3GTS 48.058)
Digital Communication System
Dynamic Delegation Discovery System (RFC 3401 RFC 3404)
Data Description Indicator (3GTS 25.309, 25.331)
Decision (COPS message type)
De-Multiplexer
Data Encryption Standard
Do not Fragment (bit in IPv4 header)
Default Forwarding (DiffServ Term / RFC 2474)
Dynamic Host Configuration Protocol (RFC 2131)
Diameter Protocol (RFC 3588, RFC 3589)
4 bit
Downlink Interval Usage Code (WIMAX Term)
Downlink
Data Link Connection Identifier
Downlink Frame Prefix
Downlink-Medium Access Protocol (MAC-Message in
WIMAX / IEEE 802.16)
Destination Local Reference (SCCP term)
Downloadable Sounds
Digital Multimedia Broadcasting
Domain Name System
Data Over Cable Service Interface Specification
(defined by CableLabs)
Denial of Service attack
Destination Point Code

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

- 633 -

IMS_SIP_NSN0910 Special Course


DPCCH
DPCH
DPDCH
DPNSS
DPSK
DRM
DRNC
DRX
DSCA
DS-CDMA
DSCH
DSCP
DSL
DSLAM
DSM-CC
DSN
DSP
DSS1
DSSS
DT1
DTAP
DTCH
DTM
DTX
DUA

Dedicated Physical Control Channel (UMTS Physical


Channel)
Dedicated Physical Channel (UMTS / Term to combine
DPDCH and DPCCH)
Dedicated Physical Data Channel (UMTS Physical
Channel)
Digital Private Network Signaling System
Differential Phase Shift Keying
Digital Rights Management
Drift Radio Network Controller
Discontinuous Reception
Diversity / Distributed Subcarrier Allocation
Direct Sequence Code Division Multiple Access
Downlink Shared Channel (UMTS Transport Channel)
Differentiated Services Code Pointer
Digital Subscriber Line
Digital Subscriber Line Access Multiplexer
Digital Storage Media Call Control
Digital Switching Network
Digital Signal Processor
Digital Subscriber Signaling System No.1 (also referred
to as LAPD-signaling / ITU-T Q.931)
Direct Sequence Spread Spectrum
Data Form 1 (SCCP message type)
Direct Transfer Application Part
Dedicated Traffic Channel (UMTS Logical Channel)
Dual Transfer Mode (3GTS 43.055)
Discontinuous Transmission
DPNSS 1 / DASS 2 User Adaptation Layer (RFC 4129)

DVB
DVB-C
DVB-H
DVB-S
DVB-T
e2e
E-AGCH
EAP
EAP-AKA

EAPOL
EAP-SIM
EAP-TLS
EAP-TTLS
Ec/No
ECN
ECSD
E-DCH
E-DCH-FP
EDGE
E-DPCCH
E-DPDCH

Digital Video Broadcasting


Digital Video Broadcasting - Cable TV
Digital Video Broadcasting - Handheld
Digital Video Broadcasting - Satellite
Digital Video Broadcasting - Terrestrial
End-to-End
E-DCH Absolute Grant Channel (3GTS 25.211)
Extensible Authentication Protocol (RFC 3748)
Extensible Authentication Protocol method for 3rd
generation Authentication and Key Agreement (RFC
4187)
EAP encapsulation Over Lan or wlan (IEEE 802.1X)
Extensible Authentication Protocol method for gsm
Subscriber Identity Module (RFC 4186)
Extensible Authentication Protocol - Transport Layer
Security (RFC 2716)
Extensible Authentication Protocol - Transport Layer
Security (draft-funk-eap-ttls-v0-01.txt)
Received energy per chip / power density in the band
Explicit Congestion Notification
Enhanced Circuit Switched Data (HSCSD + EDGE)
Enhanced Uplink Dedicated Transport Channel (3GTS
25.211, 25.309)
E-DCH Frame Protocol (Enhanced Dedicated Channel)
Enhanced Data Rates for Global Evolution
Enhanced Uplink Dedicated Physical Control Channel
(3GTS 25.211)
Enhanced Uplink Dedicated Physical Data Channel
(3GTS 25.211)

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

- 634 -

IMS_SIP_NSN0910 Special Course


EDR
EF
EFR
EGPRS
E-GSM
E-HICH
EIA
EIR
EIRENE
eMLPP
EMSK
END
ENUM
E-OTD
E-RGCH
E-RNTI
ertPS
ert-PS
ESG
ES-Id
ESN

Enhanced Data Rate (more speed with Bluetooth 2.0


(2.0 - 3.0 Mbit/s)
Expedite Forwarding (DiffServ Term)
Enhanced Full Rate speech codec
Enhanced General Packet Radio Service
Extended GSM (GSM 900 in the Extended Band)
E-DCH HARQ Acknowledgement Indicator Channel
(3GTS 25.211)
Electronic Industries Alliance (US-organization to
support US industry)
Equipment Identity Register
European Integrated Railway Radio Enhanced Network
(GSM-R)
enhanced Multi-Level Precedence and Pre-emption
(3GTS 23.067)
Extended Master Session Key
END Message (TCAP)
E.164-telephone number to URI (Uniform Resource
Identifier) translation (RFC 3761)
Enhanced Observed Time Difference
E-DCH Relative Grant Channel (3GTS 25.211)
E-DCH Radio Network Temporary Identifier (3GTS
25.401)
Extended Real-Time Polling Service (IEEE 802.16
Traffic Class)
Extended Real-Time Polling Service (WIMAX Traffic
Class)
Electronic Service Guide
Encoding Symbol-Id
Electronic Serial Number (North American Market)

ESP
E-TFC
E-TFCI
Ethernet
ETSI
EUL
E-UTRA
EV-DO
EV-DV
EVM
FA
FACCH
FACH
FBI
FBI
FBSS
FCC
FCCH
FCH
FCS
FDD
FDDI
FDM
FDMA
F-DPCH
FDT

Encapsulating Security Payload (RFC 4303)


E-DCH Transport Format Combination (3GTS 25.309)
E-DCH Transport Format Combination Identifier
(Enhanced Dedicated Channel)
Layer 2 Protocol for IP (IEEE 802.3)
European Telecommunications Standard Institute
Enhanced Uplink
Evolved UMTS Terrestrial Radio Access
Evolution Data Only or Evolution Data Optimized
(cdma2000)
Evolution Data/Voice (cdma2000)
Error Vector Magnitude
Foreign Agent (Mobile IP / RFC 3344)
Fast Associated Control Channel (GSM)
Forward Access Channel (UMTS Transport Channel)
Feedback Information (UMTS)
Final Block Indicator
Fast Base Station Switching
Federal Communications Commission
Frequency Correction Channel (GSM)
Frame Control Header
Frame Check Sequence (CRC-Check)
Frequency Division Duplex
Fiber Distributed Data Interconnect (optical Layer 2)
Frequency Division Multiplexing
Frequency Division Multiple Access
Fractional Dedicated Physical Channel (3GTS 25.211)
File Delivery Table

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

- 635 -

IMS_SIP_NSN0910 Special Course


FEC
FER
FFH
FFRS
FFT
FH-CDMA
FIB
FIPS
FISU
FLO
FLUTE
FM
FMC
FN
FP
FPB
FQDN

FR
FRMR
FRS
FSN
FTP

Forward Error Correction


Frame Error Rate
Fast Frequency Hopping
Fractional Frequency Reuse Scheme
Fast Fourier Transformation
Frequency Hopping Code Division Multiple Access
Forward Indicator Bit
Federal Information Processing Standard
Fill In Signal Unit
Flexible Layer 1 (3GTS 45.902)
File Delivery over Unidirectional Transport (RFC 3926)
Frequency Modulation
Fixed Mobile Convergence
Frame Number
Frame Protocol
First Partial Bitmap
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.
Fullrate or Frame Relay
Frame Reject
Frequency Reuse Scheme
Forward Sequence Number
File Transfer Protocol (RFC 959)

FUSC
FWA
GA
GAA
GA-CSR
GAN
GANC
GA-PSR
GA-RC
GBA
GBR
GCC
GCF
GEA
GERAN
GGSN
GHz
GIF
GK
GMLC
GMM
GMSC
G-MSC
GMSC-S
GMSK
GNU

Full Usage of Subchannels


Fixed Wireless Access
Generic Access (3GTS 43.318)
Generic Authentication Architecture (3GTS 33.220)
Generic Access - Circuit-Switched Resources (3GTS
43.318)
Generic Access Network
Generic Access Network Controller (3GTS 43.318)
Generic Access - Packet-Switched Resources (3GTS
43.318)
Generic Access - Resource Control (3GTS 43.318)
Generic Bootstraping Architecture (3GTS 33.220)
Guaranteed Bit Rate Service
Generic Call Control
General Certification Forum
GPRS Encryption Algorithm
GSM EDGE Radio Access Network
Gateway GPRS Support Node
Giga Hertz (109 Hertz)
Graphics Interchange Format
Gatekeeper
Gateway Mobile Location Center
GPRS Mobility Management
Gateway MSC
Gateway MSC
Gateway MSC Server
Gaussian Minimum Shift Keying
recursive acronym for GNU is Not Unix. Today a

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

- 636 -

IMS_SIP_NSN0910 Special Course

GPCS
G-PDU
GPRS
GPRS-CSI
GPRS-SSF
GPS
GRA
GRE
G-RNTI
GRX
GSM
GSM-R
GSMS
GSN
GTP
GTP-C
GTP-U
GTT
GTTP
GUP
GW
GZIP
HA
HARQ
HB
HCS
HDB3

synonym for free Sourcecode Software.


Generic Packet Convergence Sublayer (IEEE 802.16)
T-PDU + GTP-Header
General Packet Radio Service
GPRS CAMEL Subscription Information
GPRS Service Switching Function (CAMEL)
Global Positioning System
GERAN Registration Area
Generic Routing Encapsulation (RFC 2784)
GERAN Radio Network Temporary Identifier
GPRS Roaming Exchange (GSM-Association IR.34)
Global System for Mobile Communication
GSM for Railways
GPRS Short Message Service
GPRS Support Node
GPRS Tunneling Protocol (3GTS 29.060)
GTP Control Plane
GTP User Plane
Global Title Translation (ITU-T Q.714 (2.4))
GPRS Transparent Transport Protocol (3GTS 44.018)
Generic User Profile
Gateway
GNU ZIP (compression format)
Home Agent (Mobile IP / RFC 3344)
Hybrid ARQ
Heartbeat
Hierarchical Cell Structure
High Density Bipolar Three (Line Coding used for E1

HDLC
HDTV
HFC
HFC-Network
HIPERLAN/2
HLR
HMAC
HO
HoA
H-PLMN
HR
H-RNTI
HS
HSCSD
HSDPA
HS-DPCCH
HS-DSCH
HSPA
HS-PDSCH
HSS

(PCM 30)
High level Data Link Control
High Definition Television
Hxbrid Fiber Cable (relates to the layer 1 of CableTVoperators)
Hybrid Fiber- / Coaxial-cable
High Performance Radio Local Area Network type 2
Home Location Register
Keyed Hashing for Message Authentication (RFC 2104)
Handover
Home Address
Home PLMN
Halfrate
HS-DSCH Radio Network Transaction Identifier (3GTS
25.331, 25.433)
High Speed
High Speed Circuit Switched Data
High Speed Downlink Packet Access (3GTS 25.301,
25.308, 25.401, 3GTR 25.848)
High Speed Dedicated Physical Control Channel (3GTS
25.211)
High Speed Downlink Shared Transport Channel
(3GTS 25.211, 25.212, 25.308)
High Speed Packet Access (operation of HSDPA and
HSUPA)
High Speed Physical Downlink Shared Channel (3GTS
25.211)
Home Subscriber Server (3GTS 23.002). HSS replaces
the HLR with 3GPP Rel. 5

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

- 637 -

IMS_SIP_NSN0910 Special Course


HS-SCCH
HSUPA
HTTP
HTTPS
HUMAN
I+S
IAM
IANA
IBS
ICANN
ICH
ICM
ICMP
ICS
I-CSCF
ID
IDNNS
IE
IEC
IEEE
IETF
IFFT
IGMP
IHOSS
IK

High Speed Shared Control Channel (3GTS 25.211,


25.214)
High Speed Uplink Packet Access (3GTS 25.301,
25.309, 25.401, 3GTR 25.896)
HyperText Transfer Protocol (RFC 2616)
Hypertext Transfer Protocol Secure
High-speed Unlicensed Metropolitan Area Network
Information + Supervisory
Initial Address Message (ISUP ISDN User Part)
Internet Assigned Numbers Authority
Integrated Base Station
Internet Corporation for Assigned Names and Numbers
Indicator Channel (UMTS Physical Channel / see also
PICH, AICH, CD/CA-ICH)
Initial Codec Mode
Internet Control Message Protocol (RFC 792)
Implementation Conformance Statement
Interrogating Call Session Control Function (SIP)
Identity
Intra-Domain NAS Node Selector
Information Element
International Electrotechnical Commission
Institute of Electrical and Electronics Engineers
Internet Engineering Task Force (www.ietf.org)
Inverse Fast Fourier Transformation
Internet Group Multicast Protocol (RFC 1112, RFC
2236)
Internet Hosted Octet Stream Service
Integrity Key (3GTS 33.102)

IKE
IKEv2
IKMP
iLBC
ILCM
IM
IMEI
IMPI

IMPU

IMS
IMS-AG
IMSI
IMS-SSF
IMT-2000
IN
INAP
IOV-I / IOV-UI
IP
IPBCP
IP-CAN
IPCP

Internet Key Exchange (RFC 2409)


Internet Key Exchange protocol / version 2 (RFC 4306)
Internet Key Management Protocol
Internet Low Bitrate Codec (RFC 3951 / RFC 3952)
Incoming Leg Control Model
Instant Messaging
International Mobile Equipment Identity
IP Multimedia Private Identity; the private user identity
of an IMS-subscriber, formatted as an NAI (3GTS
33.203)
IP Multimedia Public Identity; the public user identity of
an IMS-subscriber, formatted as SIP-URI or TEL-URI
(3GTS 33.203)
Internet Protocol Multimedia Core Network Subsystem
(Rel. 5 onwards)
IMS-Access Gateway
International Mobile Subscriber Identity
IP Multimedia Subsystem - Service Switching Function
International Mobile Telecommunications for the year
2000
Intelligent Networking
Intelligent Network Application Part (CCS7)
Input Offset Variable for I+S and UI-Frames (for
ciphering in GPRS)
Internet Protocol (RFC 791)
IP Bearer Control Protocol (ITU-T Q.1970)
Internet Protocol - Connectivity Access Network (e.g.
DSL, TV-Cable, WIMAX, UMTS)
Internet Protocol Control Protocol (RFC 1332)

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

- 638 -

IMS_SIP_NSN0910 Special Course


IP-CS
IPDC
IPDV
IPER
IPLR
IPsec
IPTD
IPv4
IPv6
IR
IS
ISAKMP
ISC
ISCP
ISDB
ISDN
ISI
ISIM
ISM
ISO
ISP
ISPC
ISUA
ISUP
IT

IP-Convergence Sublayer
IP Datacast
IP-packet delay variation (ITU-T Y.1540)
IP-packet error ratio (ITU-T Y.1540)
IP-packet loss ratio (ITU-T Y.1540)
Internet Protocol / secure (RFC 4301)
IP-packet transfer delay (ITU-T Y.1540)
Internet Protocol (version 4)
Internet Protocol (version 6)
Incremental Redundancy (ARQ II)
Interim Standard (ASNI Standard)
Internet Security Association and Key Management
Protocol (RFC 2408)
IP multimedia subsystem Service Control-Interface
Interference Signal Code Power (3GTS 25.215 / 3GTS
25.102)
Integrated Services Digital Broadcasting
Integrated Services Digital Network
Inter-Symbol Interference
IMS capable Subscriber Identity Module
Industrial, Scientific and Medical (term for license-free
frequencies)
International Standardization Organization
Internet Service Provider
International Signaling Point Code (ITU-T Q.708)
ISDN User Adaptation Layer
ISDN User Part (ITU-T Q.761 - Q.765)
Information Technology

ITU
ITU-R
ITU-T
IUA
Iub-FP
Iu-FP
Iur-FP
IUT
I-WLAN
JD
JPEG
kbps
KEK
KHz
L1
L2
L2TP
L3
LA
LAC
LAI
LAN
LAPB
LAPD
LAPV5

International Telecommunication Union


International Telecommunication Union Radiocommunications
International Telecommunication Union Telecommunication Sector
ISDN Q.921 User Adaptation Layer (RFC 4233)
Iub-Frame Protocol (3GTS 25.427 / 25.435)
Iu-Frame Protocol (3GTS 25.415)
Iur-Frame Protocol (3GTS 25.424, 3GTS 25.425,
25.426, 25.435)
Implementation under Test
Interworking WLAN (Wireless Local Area Network)
(3GTS 23.234)
Joint Detection
Joint Picture Expert Group
kilo-bits per second
Key Encryption Key (IEEE 802.16)
Kilo Hertz (103 Hertz)
Layer 1 (physical layer)
Layer 2 (data link layer)
Layer 2 Tunneling Protocol (RFC 2661)
Layer 3 (network layer)
Location Area
Location Area Code
Location Area Identification (LAI = MCC + MNC + LAC)
Local Area Network
Link Access Procedure Balanced
Link Access Protocol for the ISDN D-Channel
Link Access Protocol for V5-interface

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

- 639 -

IMS_SIP_NSN0910 Special Course


LBS
LCP
LCS
LCT
LDAP
LDPC
LE
LER
LEX
LI
LLC
LMDS
LMMSE
LMU
LOS
LPD
LR
LSB
LSP
LSR
LSSU
LTE
M2PA
M2UA
M3UA
MAC
MAC
MAC-d

Location Based Service


Link Control Protocol (PPP)
LoCation Service
Layered Coding Transport
Lightweight Directory Access Protocol (RFC 3928)
Low Density Parity Check
Lower Effort PDB (DiffServ Term)
Label Edge Router (MPLS)
Local Exchange Carrier
Length Indicator
Logical Link Control-Protocol
Local Multipoint Distribution Services
Linear Minimum Mean Square Error receiver
Location Measurement Unit
Line Of Sight
Link Protocol Discriminator
Location Register
Least Significant Bit
Label Switched Path (MPLS)
Label Switch Router (MPLS)
Link Status Signal Unit
Long Term Evolution (of UMTS)
MTP-2 user Peer-to-Peer Adaptation Layer (RFC 4165)
MTP-2 User Adaptation Layer (RFC 3331)
MTP-3 User Adaptation Layer (RFC 4666)
Message Authentication Code
Medium Access Control
Medium Access Control for the Dedicated Transport

MAC-e
MAC-es
MAC-hs
MAN
MAP
MAP-B
MAP-X
MASF
Max [X, Y]
MBMS
MBS
MBSAT
MBWA

MBZ
MCC
MCCH

Channel (3GTS 25.321)


MAC-E-DCH (3GTS 25.321)
MAC-E-DCH SRNC (3GTS 25.321)
MAC-High Speed (3GTS 25.321)
Metropolitan Area Network
Mobile Application Part (3GTS 29.002)
Mobile Application Part - B-interface protocol between
MSC and VLR
Mobile Application Part - various interface protocols like
B-, C-, D-, E-, F- or G-interface
Minimum Available Spreading Factor
The value shall be the maximum of X or Y, which ever
is bigger
Multimedia Broadcast / Multicast Service (3GTS
23.246, 3GTS 43.846)
Multicast Broadcast Services
Mobile Broadcast Satellite
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)
Must Be Zero
Mobile Country Code
MBMS point-to-multipoint Control Channel

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

- 640 -

IMS_SIP_NSN0910 Special Course


Mcps
MCS
MCS-X
MCU
MD
MDHO
MD-X
ME
MEGACO
MExE
MGC
MGCF
MGCP
MGW
MHP
MHz
MIB
MICH
MIDI
MIH
MIKEY
MIME
MIMO
MIN
Min [X, Y]

Mega Chip Per Second


Modulation and Coding Scheme
Modulation and Coding Scheme (1 - 9) and for HSDPA
/ HSUPA
Multipoint Control Unit (H.323 equipment)
Message Digest algorithm (e.g. MD-5)
Macro-Diversity Handover
Message Digest Algorithm (MD-2, 4, 5 are defined)
(MD-5 RFC 1321)
Mobile Equipment (ME + SIM = MS)
Media Gateway Control Protocol (ITU-T H.248 incl.
Annex F - H and IETF RFC 3015)
Mobile Station Application Execution Environment
Media Gateway Controller
Media Gateway Control Function
Media Gateway Control Protocol (RFC 2705)
Media Gateway
Multimedia Home Platform
Mega Hertz (106 Hertz)
Management Information Base
MBMS Notification Indicator Channel
Musical Instrument Digital Interface
Media Independent Handover (IEEE 802.21)
Multimedia Internet KEYing (RFC 3830)
Multipurpose Internet Mail Extensions
Multiple In / Multiple Out (antenna system)
Mobile Identity Number (North American Market)
The value shall be the minimum of X or Y, which ever is
smaller

MINA
MIP
MISO
MitM
MLD
MLP
MLPP
MM
MMCC
MMD
MMDS
MMS
MNC
MNRG
MOBIKE
MOC
MP3
MPCC
MPE
MPEG
MPEG2-TS
MPLS
MPRACH
MRC
MRF

Mobile Internet Network Architecture


Mobile IP (RFC 2002, 3344, 3775)
Multiple In / Single Out (antenna system)
Man in the Middle (attack)
Multicast Listener Discovery (RFC 2710)
MAC Logical Channel Priority
Multi-Level Precedence and Pre-emption (ITU-T Q.85 /
Clause 3)
Mobility Management
Multimedia Call Control
IP Multimedia Domain (name of the IMS in 3GPP2)
Multipoint Microwave Distribution System or Multichannel Multi-point Distribution System
Multimedia Messaging Service (3GTS 22.140, 3GTS
23.140)
Mobile Network Code
Mobile Not Reachable for GPRS flag
IKEv2 Mobility and Multihoming Protocol (RFC 4555)
Mobile Originating Call
MPEG-1 Audio Layer 3
Multiparty Call Control
Multi Protocol Encapsulation (DVB-H)
Motion Picture Expert Group
MPEG-2 Transport Stream (DVB)
Multi Protocol Label Switching
MBMS Packet Random Access Channel ((E)GPRS)
Maximum Ratio Combining
Multimedia Resource Function

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

- 641 -

IMS_SIP_NSN0910 Special Course


MRFC
MRFP
MRU
MRW
MS
MS
MSB
MSC
MSCH
MSC-S
MS-ISDN
MSK
MSRD
MSRN
MSRP
MSS
MSU
MT
MTC
MTCH
MTK
MTP
MTP-3b
MTU
MUD

Multimedia Resource Function Controller


Multimedia Resource Function Processor
Maximum Receive Unit (PPP)
Move Receiving Window
Mobile Station
Mobile Subscriber Station (IEEE 802.16e)
Most Significant Bit
Mobile Services Switching Center
MBMS point-to-multipoint Scheduling Channel
MSC-Server
Mobile Subscriber - International Service Directory
Number
Master Session Key
Mobile Station Receive Diversity
Mobile Station Roaming Number
Message Session Relay Protocol (draft-ietf-simplemessage-sessions-XX)
Maximum Segment Size (TCP)
Message Signal Unit
Mobile Terminal or Mobile Terminating
Mobile Terminating Call
MBMS point-to-multipoint Traffic Channel
MBMS Traffic Key
Message Transfer Part (ITU-T Q.701 - Q.709)
Message Transfer Part level 3 / broadband (ITU-T
Q.2210)
Maximum Transmit Unit (IP)
Multi-User-Detection unit

MUX
MVNO
NACC
NACK
NAF
NAI
NAP
NAPT
NAPTR
NAS
NASS
NAT
NBAP
NBNS
NC
NCC
NCP
NGN
NI
NIC
NLOS
NMT
NNI
NPB
N-PDU

Multiplex
Mobile Virtual Network Operator
Network Assisted Cell Change (3GTS 44.060)
Negative Acknowledgement
Network Application Function (part of the Generic
Authentication Architecture (GAA))
Network Access Identifier (RFC 2486)
Network Access Provider
Network Address Port Translation (RFC 3022)
Naming Authority Pointer (RFC 2915)
Non-Access-Stratum (UMTS)
Network Attachment SubSystem (part of the TISPAN
NGN-architecture)
Network Address Translation (RFC 1631)
NodeB Application Part (3GTS 25.433)
NetBios Name Service
Neighbor Cell
Network Color Code
Network Control Protocol (PPP)
Next Generation Networks
Network Indicator
Network Interface Card
Non Line Of Sight
Nordic Mobile Telephone (analog cellular standard,
mainly used in Scandinavia)
Network-to-Network Interface
Next Partial Bitmap
Network-Protocol Data Unit (IP-Packet, X.25-Frame)

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

- 642 -

IMS_SIP_NSN0910 Special Course


NRI
NS
NSAP
NSAPI
N-SAW
NSE
NSF
NSIS
NSLP
NSP
NSPC
NSS
NS-VC
NS-VCG
NS-VL
NT
NTSC
NWG
O&M
Octet
OFDM
OFDMA
OFUSC
OLCM
OMA

Network Resource Identifier


Network Service
Network Service Access Point
Network Service Access Point Identifier
N-Channel Stop and Wait (3GTS 25.309, 3GTR 25.848)
Network Service Entity
NAS Node Selection function
Next Steps in Signaling (RFC 4080)
NSIS Signaling Layer Protocol (e.g. for resource
reservation)
Network Service Provider
National Signaling Point Code
Network Switching Subsystem
Network Service - Virtual Connection
Network Service - Virtual Connection Group
Network Service - Virtual Link
Network Termination
National Television System Committee (video standard
for North America)
Network Working Group (WIMAX Forum)
Operation and Maintenance
8 bit
Orthogonal Frequency Division Multiplexing
Orthogonal Frequency Division Multiple Access
Optional FUSC (Full Usage of Subchannels)
Outgoing Leg Control Model
Open Mobile Alliance
(http://www.openmobilealliance.org/)

OMAC

OMAP
OMC
OoBTC
OPC
OPEX
OPUSC
OPWA
OSA
OSA-SCS
OSCP
OSI
OSP
OTDOA
OVSF
P/F-Bit
P/S
PA
PABX
PACCH
PACS
PAD
PAGCH
PAL
PAP
PAPR

One-Key CBC-MAC (NIST standard: SP 800-38B and


http://csrc.nist.gov/CryptoToolkit/modes/proposedmode
s/)
Operation & Maintenance Application Part
Operation and Maintenance Center
Out of Band Transcoder Control (3GTS 23.153)
Originating Point Code
Operational Expenditure
Optional PUSC (Partial Usage of Subchannels)
One Pass With Advertising (Term in RSVP)
Open Service Access
Open Service Access - Service Capability Server
Online Certificate Status Protocol (RFC 2560)
Open System Interconnection
Octet Stream Protocol
Observed Time Difference Of Arrival
Orthogonal Variable Spreading Factor
Polling/Final - Bit
Parallel to Serial
Presence Agent (RFC 3856)
Private Automatic Branch Exchange
Packet Associated Control Channel ((E)GPRS)
Personal Access Communication System
Packet Assembly Disassembly
Packet Access Grant Channel ((E)GPRS)
Phase Alternating Line
Password Authentication Protocol (RFC 1334)
Peak-to-Average Power Ratio

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

- 643 -

IMS_SIP_NSN0910 Special Course


PAT
PBCCH
PBS
PC
PC
PCCCH
PCCH
P-CCPCH
PCH
PCH
PCI
PCM
PCN
PCPCH
P-CPICH
PCS
P-CSCF
PCU
PD
PDA
PDB
PDBF
PDC
PDCH

Program Assocation Table (MPEG2-TS)


Packet Broadcast Control Channel ((E)GPRS)
Peak Burst Size
Protocol Class (SCCP)
Paging Controller
Packet Common Control Channel ((E)GPRS)
Paging Control Channel (UMTS Logical Channel)
Primary Common Control Physical Channel (UMTS /
used as bearer for the BCH TrCH)
Paging Channel (UMTS / Transport Channel)
Paging Channel (GSM / Logical Channel)
Peripheral Component Interconnect (computer bus
standard to interconnect peripherals to the CPU)
Pulse Code Modulation
Personal Communication Network
Physical Common Packet Channel (UMTS Physical
Channel)
Primary Common Pilot Channel (UMTS Physical
Channel)
Personal Communication System
Proxy Call Session Control Function (SIP)
Packet Control Unit
Protocol Discriminator
Personal Digital Assistant
Per Domain Behavior (DiffServ Term)
Profile DataBase Function (TISPAN term / ETSI ES 282
004)
Personal Digital Communication (ARIB-Standard)
Packet Data Channel ((E)GPRS)

PDCP
PDF
PDG
PDH
PDN
PDP
PDS
PDSCH
PDSN
PDTCH
PDU
PEAP
PEP
PER
PES
PES
PFC
PFI
PHB
PHS
PHS
PHY
PHz
PICH
PICMG

Packet Data Convergence Protocol (3GTS 25.323)


Policy Decision Function (Part of the IP Multimedia
Subsystem)
Packet Data Gateway
Plesiochronous Digital Hierarchy
Packet Data Network
Packet Data Protocol
Packet Data Subsystem (3GPP2)
Physical Downlink Shared Channel (UMTS Physical
Channel)
Packet Data Support Node (the SGSN in 3GPP2)
Packet Data Traffic Channel ((E)GPRS)
Protocol Data Unit or Packet Data Unit
Protected Extensible Authentication Protocol
Policy Enforcement Point (3GTS 23.209)
Packed Encoding Rules (ITU-T X.691)
PSTN/ISDN Emulation Subsystem (part of the TISPAN
NGN-architecture)
Packetised Elementary Stream (DVB)
Packet Flow Context
Packet Flow Identifier
Per Hop Behavior (DiffServ Term)
Payload Header Suppression (IEEE 802.16)
Personal Handy phone System
Physical Layer
Peta Hertz (1015 Hertz)
Page Indicator Channel (UMTS Physical Channel)
PCI (Peripheral Component Interconnect) Industrial
Computer Manufacturers Group (http://www.picmg.org/)

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

- 644 -

IMS_SIP_NSN0910 Special Course


PICS
PID
PIDF
PIR
PIXIT
PKCS
PKMv2
PLC
PLMN
PMIP
PMM
PMT
PMTU
PN
PNCH
PNG
PoC
PoE
POP
POTS
PPCH
PPP
PRA
PRACH
PRACH
PRACK

Protocol Implementation Conformance Statement


Packet Identifier (MPEG2-TS)
Presence Information Data Format (RFC 3863)
Peak Information Rate
Protocol Implementation Extra Information for Testing
Public Key Cryptography Standard
Privacy Key Management Version 2
Power Line Communications
Public Land Mobile Network
Proxy Mobile IP
Packet Mobility Management
Program Map Table (MPEG2-TS)
Path MTU
Pseudo Noise
Packet Notification Channel ((E)GPRS)
Portable Network Graphics
Push to talk over Cellular (3GTR 29.979 and various
OMA-specifications)
Power over Ethernet
Post Office Protocol (RFC 1939)
Plain Old Telephone Service
Packet Paging Channel ((E)GPRS)
Point-to-Point Protocol (RFC 1661)
PCPCH Resource Availability
Physical Random Access Channel UMTS
Packet Random Access Channel ((E)GPRS)
Provisional Response Acknowledgement (SIP-method
type)

PRD
PRF
PRI
PS
PS
PS
PS
PSC
P-SCH
PSD
PSI
PSK
PSPDN
PSTN
PT
PTCCH
PTCCH/D
PTCCH/U
PTM
P-TMSI
PTP
PTT

PUA

Bluetooth Qualification Program Reference Document


Pseudo Random Function
Primary rate access ISDN-user interface for PABX's (23
or 30 B-channels plus one D-Channel)
Physical Slot (IEEE 802.16)
Puncturing Scheme
Program Stream
Packet Switched
Primary Synchronization Code or Primary Scrambling
Code (both used in UMTS)
Primary Synchronization Channel (physical)
Power Spectral Density (3GTS 25.215 / 3GTS 25.102)
Program Specific Information (MPEG2-TS)
Phase Shift Keying
Packet Switched Public Data Network
Public Switched Telephone Network
Protocol Type (GTP or GTP')
Packet Timing Advance Control Channel ((E)GPRS)
Packet Timing Advance Control Channel / Downlink
Direction ((E)GPRS)
Packet Timing Advance Control Channel / Uplink
Direction ((E)GPRS)
Point to Multipoint
Packet TMSI
Point to Point
Post, Telephone & Telegraph (abbreviation for the
former government owned organizations that were
responsible for all three services)
Presence User Agent (RFC 3856)

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

- 645 -

IMS_SIP_NSN0910 Special Course


PUSC
PVC
QAM
QCIF
QE
QoS
QPSK
QSIG
RA
RAA
RAB
RAC
RACH
RACH
RACS
RADIUS
RAI
RAN
RANAP
RAND
RAR
RAT
RATSCCH
RB
RB

Partial Usage of Subchannels


Permanent Virtual Circuit
Quadrature Amplitude Modulation
Quarter Common Intermediate Format (176 x 144
pixels ITU-T H261 / H263)
Quality Estimate
Quality of Service
Quadrature Phase Shift Keying (3GTS 25.213)
Q-interface signaling protocol
Routing Area
RE-Auth-Answer command (Diameter BASE, RFC
3588)
Radio Access Bearer
Routing Area Code
Random Access Channel (UMTS Transport Channel)
Random Access Channel (GSM)
Resource and Admission Control Subsystem (part of
the TISPAN NGN-architecture)
Remote Authentication Dial In User Service (RFC 2865)
Routing Area Identification
Radio Access Network
Radio Access Network Application Part (3GTS 25.413)
Random Number
RE-Auth-Request command (Diameter BASE, RFC
3588)
Radio Access Technology (e.g. GERAN, UTRAN, ...)
Robust AMR Traffic Synchronized Control CHannel
Receive Block Bitmap (EGPRS)
Radio Bearer

RBB
RBPSCH
RED
REJ
REQ
RES
RF
RFC
RFID
RG
R-GSM
RL
RLC
RLC
RLM
RLP
RLS
RNC
RNL
RNR
RNS
RNSAP
RNSN
RNTI
RoT

Receive Block Bitmap (GPRS)


Shared Basic Physical SubCHannel
Random Early Detection
Reject
Request (COPS message type)
Response
Radio Frequency
Request for Comments (Internet Standards)
Radio Frequency Identification
Relative Grant (3GTS 25.309)
Railways-GSM
Radio Link (3GTS 25.433)
Radio Link Control (UMTS 3GTS 25.322)
Radio Link Control ((E)GPRS / 3GTS 04.60 / 3GTS
44.060)
Radio Link Management (Protocol Part on the GSM
Abis-Interface / 3GTS 48.058)
Radio Link Protocol (3GTS 24.022)
Radio Link Set (3GTS 25.309, 25.433)
Radio Network Controller
Radio Network Layer
Receive Not Ready
Radio Network Subsystem
Radio Network Subsystem Application Part (3GTS
25.423)
Radio Network Serving Node
Radio Network Temporary Identifier
Rise over Thermal (interference rise relative to zero
load)

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

- 646 -

IMS_SIP_NSN0910 Special Course


RPE/LTP
RPID
RPLMN
RPR
RR
RR
RRA
RRBP
RRC
RRC-Filter
RRLP
RRM
RSA
RSADP
RSAEP
RSAES-OAEP
RSC
RSCP
RSN
RSSI
RSVP
RTCP

Regular Pulse Excitation / Long Term Prediction


(Speech Codec)
Rich Presence Information Data
Registered PLMN
Resilient Packet Ring (IEEE 802.17)
Radio Resource Management
Receive Ready (LAPD/LLC/RLP-Frame Type)
Radio Resource Agent
Relative Reserved Block Period
Radio Resource Control
Root Raised Cosine Filter
Radio Resource LCS Protocol
Radio Resource Management
Ron Rivest, Adi Shamir and Leonard Adlemanalgorithm (Public Key Encryption / PKCS #1)
RSA-Decryption Primitive (RFC 3447 (5.1.2) or PKCS
#1 (5.1.2); PKCS = Public Key Cryptography Standard)
RSA-Encryption Primitive (RFC 3447 (5.1.1) or PKCS
#1 (5.1.1); PKCS = Public Key Cryptography Standard)
RSA Encryption Scheme - Optimal Asymmetric
Encryption Padding (PKCS #1 / RFC 3447)
Recursive Systematic Convolutional Coder (Turbo
Coding, 25.212)
Received Signal Code Power (3GTS 25.215)
Retransmission Sequence Number (3GTS 25.309,
25.212)
Received Signal Strength Indicator
Resource Reservation Protocol (RFC 2205)
Real-time Transport Control Protocol

RTG

RTO
RTP
RTP/AVP
RTP/AVPF

RTP/SAVP
RTSP
RTT
RTTVAR
RTWP
RUIM
RV
RX
S/P
SA
SA
SAAL-NNI
SAB
SABM(E)
SABP
SACCH

Receive transmit Transition Gap (IEEE 802.16 (3.45))


the time between an uplink subframe and the
subsequent downlink subframe in a TDD-system
Retransmission Time Out
Real-time Transport Protocol (RFC 3550, RFC 3551)
Real-time Transport Protocol / Audio Video Profile (RFC
3551) (used in SDP-descriptions)
Real-time Transport Protocol / extended Audio Video
Profile for rtcp Feedback (used in SDPdescriptions)(draft-ietf-avt-rtcp-feedback-11.txt)
Real-time Transport Protocol / Secure Audio Video
Profile (RFC 3711) (used in SDP-descriptions)
Real Time Streaming Protocol (RFC 2326)
Round Trip Time
Round Trip Time Variation
Received Total Wideband Power
Removable User Identity Module
Redundancy and Constellation Version (3GTS 25.212)
Receive
Serial to Parallel
Service Area
Security Association
Signaling ATM Adaptation Layer - Network Node
Interface
Service Area Broadcast
Set Asynchronous Balanced Mode (Extended for
Modulo 128 operation) (LAPD/LLC/RLP-Frame Type)
Service Area Broadcast Protocol (3GTS 25.419)
Slow Associated Control Channel (GSM)

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

- 647 -

IMS_SIP_NSN0910 Special Course


SACCH/MD
SACK
SAI
SAIC
SANC
SAP
SAPI
SAR
SAT
SBC
SBN
SBPSCH
SC
SC
SCCP
S-CCPCH

SCF
SCH
SCH
SCP
S-CPICH
SCR

SACCH Multislot Downlink (related control channel of


TCH/FD/GSM)
Selective Acknowledgement
Service Area Identifier
Single Antenna Interference Cancellation
Signaling Area Network Code (ITU-T Q.708)
Service Access Point
Service Access Point Identifier
Segmentation And Reassembly (ATM-sublayer)
Satellite
Session Border Controller (SIP term, usually a B2BUA
with NAT-function and media gateway)
Source Block Number
Shared Basic Physical SubCHannel
Serving Cell
Subcarrier
Signaling Connection Control Part (ITU-T Q.711 Q.714)
Secondary Common Control Physical Channel (used as
bearer for the FACH and PCH TrCH's / UMTS Physical
Channel)
Service Control Function (CAMEL)
Synchronization Channel (UMTS Physical Channel /
see also P-SCH and S-SCH)
Synchronization Channel (GSM)
Service Control Point (IN)
Secondary Common Pilot Channel (UMTS Physical
Channel)
Source Controlled Rate

S-CSCF
SCTP
SDCCH
SDH
SDMA
SDP
SDU
SEG
SEP
SF
SFH
SFID
SFN
SFN
SG
SG
SGSN
SGW
SHA
SHCCH
SHO
SI
SIB
SIB
SID

Serving Call Session Control Function (SIP)


Stream Control Transmission Protocol (RFC 2960)
Stand Alone Dedicated Control Channel
Synchronous Digital Hierarchy
Space Division Multiple Access
Session Description Protocol (RFC 2327, RFC 3266,
RFC 3264)
Service Data Unit (the payload of a PDU)
Security Gateway
Signaling End Point (CCS7)
Spreading Factor
Slow Frequency Hopping
Service Flow Identity
System Frame Number
Single Frequency Network
Security Gateway (IPsec / RFC 2401)
Serving Grant respectively Power Grant (3GTS 25.213,
25.309, 25.321)
Serving GPRS Support Node
Signaling Gateway
Secure Hash Algorithm
Shared Channel Control Channel (UMTS Logical
Channel / TDD only)
Soft Handover (UE is having more than one radio link at
the same time and combines them)
Service Indicator
System Information Block
LSSU with status indication busy
Silence Insertion Descriptor

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

- 648 -

IMS_SIP_NSN0910 Special Course


SID
SIE
SIF
SIG
SIGTRAN
SIM
SIMO
SIN
SIO
SIO
SIOS
SIP
SIP-AS
SIP-B
SIP-I
SIPO
SIP-T
SIQ
SIR
SISO
SLA
SLC
SLF
SLR
SLS
SLTA
SLTM

Size InDex (3GPP 25.321)


LSSU with status indication emergency alignment
Signaling Information Field
Special Interest Group (e.g. Bluetooth)
Signaling Transport (RFC 2719)
Subscriber Identity Module
Single In / Multiple Out (antenna system)
LSSU with status indication normal alignment
Service Information Octet
LSSU with status indication out of alignment
LSSU with status indication out of service
Session Initiation Protocol (RFC 3261)
SIP-Application Server
SIP for Businesses (abbreviation for a set of PABXspecific SIP-extensions)
SIP with encapsulated ISUP (ITU-T Q.1912.5)
LSSU with status indication processor outage
SIP for Telephones (RFC 3372, RFC 3398)
Service Information Query
Signal to Interference Ratio
Single In / Single Out (antenna system)
Service Level Agreement
Signaling Link Code
Subscriber Locator Function
Source Local Reference
Signaling Link Selection
Signaling Link Test Acknowledge
Signaling Link Test Message

SM
SME
SMIL
SMLC
SMS
SM-SC
SMSCB
SMS-G-MSC
SMS-IW-MSC
SMTP
SN
SND
SNDCP
SNM
SNN
SN-PDU
SNR
SNTM
SNTP
SNU
SOAP
SOHO
SP
SPC
SPI

Session Management (3GTS 23.060, 3GTS 24.008)


Small and Medium size Enterprises (Type of Business)
Synchronized Multimedia Integration Language
Gateway Mobile Location Center
Short Message Service (3GTS 24.011, 3GTS 23.040)
Short Message Service Center
Short Message Services Cell Broadcast
SMS Gateway MSC (for Short Messages destined to
Mobile Station)
SMS Interworking MSC (for Short Messages coming
from Mobile Station)
Simple Mail Transfer Protocol (RFC 2821)
Sequence Number
Sequence Number Downlink (GTP)
Subnetwork Dependent Convergence Protocol
Signaling Network Management Protocol (ITU-T Q.704
(3))
SNDCP N-PDU Number Flag
Segmented N-PDU (SN-PDU is the payload of SNDCP)
Signal to Noise Ratio
Signaling Network Test & Maintenance (ITU-T Q.707)
Simple Network Time Protocol (RFC 2030)
Sequence Number Uplink (GTP)
Simple Object Access Protocol
(http://www.w3.org/TR/2000/NOTE-SOAP-20000508)
Small Office Home Office (Type of Business)
Signaling Point
Signaling Point Code
Security Parameter Index (RFC 2401)

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

- 649 -

IMS_SIP_NSN0910 Special Course


SQCIF
SQN
SRB
SRES
SRF
SRNC
SRNS
SRTP
SRTT
SRV
SS
SSC
SSCF
SSCF/NNI
SSCF/UNI
S-SCH
SSCOP
SSCOPMCE

SSCS
SSDT
SSF
SSID

Semi Quarter Common Intermediate Format (128 x 96


pixels ITU-T H261 / H263)
Sequence number (used in UMTS-security architecture
/ 3GTS 33.102)
Signaling Radio Bearer
Signed Response
Service Resource Function (CAMEL)
Serving Radio Network Controller
Serving Radio Network Subsystem
Secure RTP (RFC 3711)
Smoothed RoundTrip Time
Service Location (DNS-related / RFC 2782)
Subscriber Station (IEEE 802.16)
Secondary Synchronization Code
Service Specific Co-ordination Function
Service Specific Coordination Function - Network Node
Interface Protocol (ITU-T Q.2140)
Service Specific Coordination Function - User Network
Interface Protocol (ITU-T Q.2130)
Secondary Synchronization Channel (physical)
Service Specific Connection Oriented Protocol (ITU-T
Q.2110)
Service Specific Connection Oriented Protocol in a
Multi-link or Connectionless Environment (ITU-T
Q.2111)
Service Specific Convergence Sublayer
Site Selection Diversity Transmission
Service Switching Function (CAMEL)
Service Set Identifier (IEEE 802.11)

SSN
SSN
SSP
SSRTG

SSSAR
ssthresh
SSTTG

STBC
STC

STC
STP
STTD
STUN
SUA
SUERM
SUFI
SUN
SVC
SVG
SWAP
T.38

Start Sequence Number (related to ARQ-Bitmap in


GPRS / EGPRS)
Send Sequence Number (GSM MM and CC-Protocols)
Service Switching Point (IN)
Subscriber Station Receive to transmit Turnaround Gap
(IEEE 802.16 (3.53)) Time that the SS needs to switch
from receive to transmit.
Service Specific Segmentation And Reassembly (ITU-T
I.366.1)
Slow start threshold (RFC 2001, RFC 2960)
Subscriber Station Transmit to receive Turnaround Gap
(IEEE 802.16 (3.54)) Time that the SS needs to switch
from transmit to receive.
Space Time Block Coding
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)
Space Time Coding
Signaling Transfer Point
Space Time block coding based Transmission Diversity
Simple Traversal of UDP through Network Address
Translators (RFC 3489)
SCCP User Adaptation Layer (RFC 3868)
Signal Unit Error Rate Monitor (ITU-T Q.703 (10))
Super Field (RLC-Protocol)
Originally stood for Stanford University Network
Switched Virtual Circuit
Scalable Vector Graphics
Shared Wireless Access Protocol (Home RF)
Fax Specification

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

- 650 -

IMS_SIP_NSN0910 Special Course


TA
TA
TACS
TAF
TAI
TB
TBCP
TBF
TBS
TCAP
TCB
TCH
TCH/FD
TCH-AFS
TCH-AHS
TCP
TCP/BFCP
TCP/RTP/AVP

TCP/TLS/BFCP

TCTF
TCTV
TDD
TDM

Terminal Adapter (ISDN)


Timing Advance
Total Access Communication System
Terminal Adopter Function (3GTS 27.001)
Timing Advance Index
Transport Block
Talk Burst Control Protocol
Temporary Block Flow
Transport Block Set
Transaction Capabilities Application Part (Q.771 Q.773)
Transmission Control Block
Traffic Channel
Traffic Channel / Fullrate Downlink
Traffic CHannel Adaptive Full rate Speech
Traffic Channel Adaptive Half rate Speech
Transmission Control Protocol
Transmission Control Protocol / Binary Floor Control
Protocol (draft-ietf-xcon-bfcp-05.txt)
Real-time Transport Protocol / Audio Video Profile over
TCP (used in SDP-descriptions)(draft-ietf-avt-rtpframing-contrans-06.txt)
Transmission Control Protocol / Transport Layer
Security / Binary Floor Control Protocol (draft-ietf-xconbfcp-05.txt)
Target Channel Type Field
Transport Channel Traffic Volume
Time Division Duplex
Time Division Multiplexing

TDMA
TDOA
TE
TEBS
TEID
TEK
Term
TF
TFC
TFCI
TFCS
TFI
TFI
TFO
TFRC
TFRI
TFS
TFT
TFTP
TGD
TGL
TGPRC
TGSN
TH-CDMA
THIG

Time Division Multiple Access


Time Difference of Arrival
Terminal Equipment
Total E-DCH Buffer Status
Tunnel Endpoint Identifier (GTP / 3GTS 29.060)
Traffic Encryption Key (IEEE 802.16)
Explanation
Transport Format
Transport Format Combination
Transport Format Combination Identifier
Transport Format Combination Set
Transport Format Indication (UMTS)
Temporary Flow Identity ((E)GPRS)
Tandem Free Operation (3GTS 22.053)
Transport Format and Resource Combination (3GTS
25.308)
Transport Format and Resource Indicator (3GTS
25.308, 25.321)
Transport Format Set
Traffic Flow Template
Trivial File Transfer Protocol (RFC 1350)
Transmission Gap start Distance (3GTS 25.215)
Transmission Gap Length (3GTS 25.215)
Transmission Gap Pattern Repetition Count (3GTS
25.215)
Transmission Gap Starting Slot Number (3GTS 25.215)
Time Hopping Code Division Multiple Access
Topology Hiding Inter Network Gateway

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

- 651 -

IMS_SIP_NSN0910 Special Course


THP
THz
TI
TIA
TID
TIPHON
TISPAN

TLLI
TLS
TLV
TM
TM
TMD
TMGI
TMN
TMSI
TNL
TOI
ToIP
TOS
TPC
T-PDU

TPS

Traffic Handling Priority (DiffServ Term)


Tera Hertz (1012 Hertz)
Transaction Identifier
Telecommunications Industry Association
Tunnel Identifier
Telecommunications and Internet Protocol
Harmonization Over Networks (ETSI Project)
Telecoms & Internet converged Services & Protocols
for Advanced Networks (ETSI Working Group to define
IMS for fixed broadband access networks)
Temporary Logical Link Identifier
Transport Layer Security (RFC 2246 / RFC 3546 /
formerly known as SSL or Secure Socket Layer)
Tag / Length / Value Notation
Transparent Mode operation (UMTS-RLC)
Transmission Modules
Transparent Mode Data (UMTS RLC PDU-type)
Temporary Mobile Group Identity (3GTS 23.003 (15.2))
Telecommunication Management Network
Temporary Mobile Subscriber Identity
Transport Network Layer (3GTS 25.401)
Transport Object Identifier
Text over IP
Type of Service
Transmit Power Command
Payload of a G-PDU which can be user data, i.e.
possibly segmented IP-frames, or GTP signaling
information (GTP)
Transmission Parameter Signalling (DVB-H)

TQI
TRAU
TrCH
TrFO
TrGw
TRX
TS
TS
TSC
TSN
TSTD
TTA
TTG
TTG

TTI
TTL
TUA
TUP
TUSC
TV
TX
UA
UA
UAC
UARFCN

Temporary Queuing Identifier


Transcoder and Rate Adaption Unit
Transport Channel (UMTS)
Transcoder Free Operation
Transition Gateway (IPv4 IPv6) (3GTS 23.228 (5.18))
Transmitter / Receiver
Timeslot
Transport Stream
Training Sequence Code
Transmission Sequence Number
Time Switched Transmit Diversity
Telecommunications Technology Association (South
Korean standards organization)
Tunnel Termination Gateway
Transmit receive Transition Gap (IEEE 802.16 (3.63))
the time between a downlink subframe and the
subsequent uplink subframe in a TDD-system
Transmission Time Interval
Time To Live (IP-Header / RFC 791)
TCAP User Adaptation Layer
Telephone User Part
Tile Use of Subchannels
Television
Transmit
User Agent (SIP-Term / RFC 3261)
Unnumbered Acknowledgement (LAPD/LLC/RLPFrame Type)
User Agent Client (SIP-Term / RFC 3261)
UMTS Absolute Radio Frequency Channel Number

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

- 652 -

IMS_SIP_NSN0910 Special Course


UART
UAS
UCD
UCS
UDCH
UDP
UDPTL
UE
UEA
UGS
UHF
UI
UIA
UICC
UIUC
UL
UL-MAP
UM
UMA
UMAN
UMD
UMS
UMTS
UNC
UNC-SGW

Universal Asynchronous Receiver and Transmitter


User Agent Server (SIP-Term / RFC 3261)
Uplink Channel Descriptor (WIMAX Message)
Universal Character Set
User-plane Dedicated Channel (3GTS 45.902)
User Datagram Protocol (RFC 768)
UDP Transport Layer (used in SDP-description for T.38
fax-applications)
User Equipment
UMTS Encryption Algorithm (3GTS 33.102)
Unsolicited Grant Service (IEEE 802.16 Traffic Class)
Ultra High Frequency
Unnumbered Information (LAPD) / Unconfirmed
Information (LLC) / Frame Type
UMTS Integrity Algorithm (3GTS 33.102)
Universal Integrated Circuit Card (3GTS 22.101 /
Bearer card of SIM / USIM)
Uplink Interval Usage Code (WIMAX Term)
Uplink
Uplink-Medium Access Protocol (MAC-Message in
WIMAX / IEEE 802.16)
Unacknowledged Mode operation (UMTS-RLC)
Unlicensed Mobile Access (3GTS 43.318)
Unlicensed Mobile Access Network
Unacknowledged Mode Data (UMTS RLC PDU-type)
User Mobility Server (HSS = HLR + UMS)
Universal Mobile Telecommunication System
UMA Network Controller
UMA Network Controller Security Gateway

UNI
URA
URB
URI
URL
USA
USAT
USB
USCH
USD
USF
USIM
UTF-8
UTRA
UTRAN
UUI
UUS
UV
UWB
UWC
V5UA
VAD
VBS
VC

User-to-Network Interface
UTRAN Registration Area
User Radio Bearer
Uniform Resource Identifier
Uniform Resource Locator (RFC 1738)
United States of America
USIM Application Toolkit
Universal Serial Bus
Uplink Shared Channel (UMTS Transport Channel
TDD only)
User Service Description
Uplink State Flag
Universal Subscriber Identity Module
Unicode Transformation Format-X (Is an X-bit) lossless
encoding of Unicode characters
UMTS (Universal Mobile Telecommunication System)
Terrestrial Radio Access
UMTS (Universal Mobile Telecommunication System)
Terrestrial Radio Access Network
User to User Information
User-User-Signaling (3GTS 23.087)
Ultra Violet
Ultra-Wide Band (IEEE 802.15.3)
Universal Wireless Convergence (Merge IS-136 with
GSM)
V5.2-User Adaptation Layer (RFC 3807)
Voice Activity Detector
Voice Broadcast Service (GSM-R)
Virtual Circuit

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

- 653 -

IMS_SIP_NSN0910 Special Course


VCI
VDSL
VE
VGCS
VHE
VHF
VLAN
VLR
VoD
VoIP
VPI
V-PLMN
VPN
VW
WAG
W-AMR
W-AMR+
WAN
WAP
W-APN
WCDMA
WEP
WiFi
WIMAX

Virtual Circuit Identifier (ATM)


Very high data rate Digital Subscriber Line (ITU-T
G.993.1)
Virtual Engine
Voice Group Call Service (GSM-R)
Virtual Home Environment (3GTS 22.121, 3GTS
23.127)
Very High Frequency
Virtual LAN
Visitor Location Register
Video on Demand
Voice over IP
Virtual Path Identifier (ATM)
Visited PLMN
Virtual Private Network
Virtual Wire PDB (DiffServ Term)
WLAN (Wireless Local Area Network) Access Gateway
Wideband AMR-Codec (Adaptive Multirate) (3GTS
26.190)
Extended Wideband AMR-Codec (Adaptive Multirate)
(3GTS 26.290)
Wide Area Network
Wireless Application Protocol
WLAN-APN (Wireless Local Area Network - Access
Point Name) (3GTS 23.234)
Wide-band Code Division Multiple Access
Wired Equivalent Privacy
Wireless Fidelity (www.wi-fi.org)
Worldwide Interoperability for Microwave Access (IEEE

WINS
WLAN
WMAN
WPA
WRED
WSN
X-CSCF
XHTML
XID
XMAC
XMF
XOR
XRES
XUA

802.16)
Windows Internet Name Service
Wireless Local Area Network (IEEE 802.11)
Wireless Metropolitan Area Network
WiFi Protected Access
Weighted Random Early Detection
Window Size Number
Call Session Control Function (any, there is I-CSCF, PCSCF and X-CSCF)
Extensible Hypertext Markup Language
Exchange Identification (LAPD/LLC-Frame Type)
Expected Message Authentication Code
Extensible Music Format
Exclusive-Or Logical Combination
Expected Response (3GTS 33.102)
Any User Adaptation Layer (M2UA, M3UA, SUA)

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

- 654 -

IMS_SIP_NSN0910 Special Course


hh

Index:
1

100rel..........................................................................................................240
100-Trying ( SIP-Response Code) .........................................................248
183-Session Progress ( SIP-Response Code) .......................................254

3
302-Moved Temporarily ( SIP-Response Code) ................................80, 82
3pcc ....................................................................................................340, 356

4
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

5
504-Server Timeout ( SIP-Response Code)...........................................246
580-Precondition Failure ( SIP-Response Code) ...................................256

606-Not Acceptable ( SIP-Response Code)...........................................334

A
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

B
B2BUA ..........................................................................................................70
back-to-back user agent ...............................................................................70
BFCP ..........................................................................................................206
b-line ( SDP) ...................................................................................190, 210
branch parameter .......................................................................................102

C
call ..............................................................................................................124

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

- 655 -

IMS_SIP_NSN0910 Special Course


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

D
desired (des) ( SDP-attribute).................................................................274
DIA................................................................................................................16
dialog ..................................................................................................100, 124
dialog ( definition in SIP)...........................................................................96
DIAMETER ...................................................................................................16
do not disturb ..............................................................................................292

E
early dialog ...........................................................................................96, 332
event server ..................................................................................................90
event: reg....................................................................................................408
expires-time ( 3GPP) ......................................................................118, 388

F
find me ........................................................................................................314
fmtp ( SDP-attribute)...............................................................................216
follow me.....................................................................................................314
forking .....................................................................................74, 76, 124, 130
forking (simultaneous ...................................................................................82
From-tag .....................................................................................................100

H
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

I
iLBC ............................................................................................................180
IMPI ............................................................................................................378
IMPU...........................................................................................................378
IMS ...............................................................................................................12
IP Multimedia Subsystem .............................................................................12
ISIM ............................................................................................................378

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

- 656 -

IMS_SIP_NSN0910 Special Course


K
keep-alive mechanism................................................................................342

L
local ( SDP-attribute) ..............................................................................270
location based services ................................................................................90

M
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

N
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

O
offer / answer model ...................................................................................220
o-line ( SDP) ...........................................................................................184

P
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

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

- 657 -

IMS_SIP_NSN0910 Special Course


public user identity......................................................................................378
publishing ( event) ....................................................................................90
push-to-talk .................................................................................................206

Q
q-parameter ................................................................................................124

R
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

S
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

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

- 658 -

IMS_SIP_NSN0910 Special Course


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

T
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

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

- 659 -

IMS_SIP_NSN0910 Special Course


user not responding ....................................................................................304
Username ( SDP o-line)..........................................................................184

U
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

V
via ...............................................................................................................102
v-line ( SDP)............................................................................................182

Z
z9hG4bK.....................................................................................................102

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

- 660 -

Das könnte Ihnen auch gefallen