Beruflich Dokumente
Kultur Dokumente
IMS_SIP_NSN0910
Special Training
INACON GmbH
Kriegsstrasse 154
76133 Karlsruhe
Germany
www.inacon.com
e-mail: inacon@inacon.de
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:
Signaling Message
(mandatory)
Signaling Message
(optional)
Data
(mandatory)
Data
(optional)
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,
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
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
Conclusions.......................................................................................................145
sInter IP-CAN Roaming (Practical Exercise)............................................................... 146
Inter IP-CAN Roaming (Practical Exercise) ................................................................ 147
And where are SIP, SDP and all the other Protocols used? ..........................231
SIP Use within NGN.................................................................................................... 231
DIA (DIAMETER)) ............................................................................................................... 231
VPN with IPsec in Tunnel Mode and Transport Mode ................................................ 273
VPN with IPsec in Tunnel Mode ......................................................................................... 273
VPN with IPsec in Transport Mode ..................................................................................... 273
SIP-Servers................................................................................................................. 287
Stateless SIP-Proxy Server ................................................................................................ 287
Stateful SIP-Proxy Server ................................................................................................... 287
SBC (Session Border Controller), B2BUA (Back-to-Back User Agent) .............................. 287
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
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 (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
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
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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-
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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-
Objectives
After this Lecture the Student will:
Know which protocols like SIP (Session Initiation Protocol) are used within
NGNs to address which 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
-2-
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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-
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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-
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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-
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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-
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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-
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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-
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-
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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).
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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)]
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 -
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 -
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
- 35 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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)]
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
AUTN: ______________________________________________________________________
AK
IK
AMF
RAND
AUTN
XRES
CK
MAC
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
- 93 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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 -
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
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
PES: _______________________________________________________________________
NASS: ______________________________________________________________________
RACS: _____________________________________________________________________
PDBF: ______________________________________________________________________
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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).
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
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.
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
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 -
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 -
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.
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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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 -
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 -
Conclusions
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.
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 -
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 -
Practical Exercise:
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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:
???
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 -
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 -
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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
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).
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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).
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
- 194 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
Chatroom 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
- 219 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
If the MRFC is present then the interfaces towards the S-CSCF ( Mr-interface) and towards the MRFP ( Mp-interface) are mandatory.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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).
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
And where are SIP, SDP and all the other Protocols used?
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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]
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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].
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
MSRP
The MSRP is used within the IMS for embedding IM-messages which can be differently encoded [draft-ietf-simple-message-sessions-XX]
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
[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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
Example of an RTP-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
- 254 -
Example of an RTP-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
- 255 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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).
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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
- 268 -
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.
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
???
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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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)]
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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)]
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
Summary
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
Summary
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
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 -
Philosophy of SIP-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
- 316 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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)]
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
???
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 -
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
...
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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]
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
Step 1: GPRS-Attachment
The MS / UE shall attach to the GPRS using the regular GPRS-attachment procedure.
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.
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).
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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)]
???
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
Since we are talking about APNs: Can a secondary PDP-context use a different APN than the primary PDP-context?
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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.
Note that the authentication process is also used to establish IPsec security
associations between the P-CSCF and 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
- 358 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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).
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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)
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
Gm-Interface
IPsec-tunnel
Mw-Interface
Mw-Interface
Cx-Interface
SIP: SUBSCRIBE
Event: reg
SIP: NOTIFY
Public User Identities (XML-encoded)
SIP: SUBSCRIBE
Event: reg
SIP: SUBSCRIBE
Event: reg
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
Gm-Interface
IPsec-tunnel
SIP: NOTIFY
Public User Identities
(XML-encoded)
Mw-Interface
Mw-Interface
Cx-Interface
SIP: NOTIFY
Public User Identities (XML-encoded)
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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)]
???
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 -
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 -
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 -
Transaction-specific 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
- 382 -
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)].
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
Practical Exercise
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
- 395 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
Summary
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 -
Summary
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.
???
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.
???
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 -
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 -
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:
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 -
SIP-Message Contents
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
SIP-Timers
Overview
As the figure illustrates, one can distinguish different types of timers in SIP. There are:
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
???
2s
0.5 s
Timer A
Initially T1
Initially T1
Timer B
128 s
32 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
- 429 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
With respect to the retransmitted Request: INVITE-messages: Will the Call-ID-, CSeq- and branch-values be identical in all instances?
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 (T1)
Timer
2s
0.5 s
Timer 2 (T2)
16 s
4s
Timer G
Initially T1
Initially T1
Timer H
128 s
32 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
- 435 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
???
Why does the former UAS send the Request: BYE-message only in case a Response: 200-OK was sent?
Timer 1 (T1)
Timer
2s
0.5 s
Timer 2 (T2)
16 s
4s
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
2s
0.5 s
Timer E
Initially T1
Initially T1
Timer F
128 s
32 s
Timer K
17 s
5s
Timer 1 (T1)
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
2s
0.5 s
128 s
32 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
- 443 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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)
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
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 -
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
- 456 -
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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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]
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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)]
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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]
???
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 -
a-Lines (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
- 482 -
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.
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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 -
Response:
The UAS shall in its provisional
responses require that the
provisional responses be
acknowledged.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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]
???
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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).
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
Summary
Consequently, all provisional responses except 100 are sent reliably by the
UAS and require an acknowledgement through the new PRACK-method 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
- 502 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
If resources are lacking in either or in both directions, the users will experience very poor quality or even a dead link ( Ghost Ring)
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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]
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
???
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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).
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
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).
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
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.
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
Summary
Preconditions are met if both states current and desired are equal
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
Summary
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
???
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 -
- 544 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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.
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 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).
SIP B21
INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
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 -
SIP B41
INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
SIP B51
S
I
P
S
D
P
S
D
P
INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
SIP B42
I
P
INVITE
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________
SIP B52
Source IP: ______________________________________________________________
I
P
S
I
P
S
D
P
183-Session Progress
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________
SIP B32
I
P
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
S
I
P
S
D
P
183-Session Progress
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
SIP B22
S
I
P
S
D
P
S
D
P
183-Session Progress
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
Media B11
I
P
S
I
P
S
D
P
m = : __________________________________________________________________
183-Session Progress
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________
Media B21
c = : ___________________________________________________________________
Contact: _______________________________________________________________
Via: ___________________________________________________________________
SIP B12
183-Session Progress
Nothing to declare
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 -
Media B31
Media B32
Nothing to declare
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 -
Media B11
Nothing to declare
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 -
SIP A21
INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
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 -
SIP A41
INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
SIP A51
S
I
P
S
D
P
S
D
P
INVITE
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
SIP A42
I
P
INVITE
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________
SIP A52
Source IP: ______________________________________________________________
I
P
S
I
P
S
D
P
183-Session Progress
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________
SIP A32
I
P
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
S
I
P
S
D
P
183-Session Progress
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
SIP A22
S
I
P
S
D
P
S
D
P
183-Session Progress
Via: ____________________________________________________________
Contact: ________________________________________________________
c = : ___________________________________________________________
m = : ___________________________________________________________
Media A11
I
P
S
I
P
S
D
P
m = : __________________________________________________________________
183-Session Progress
Via: ___________________________________________________________________
Contact: _______________________________________________________________
c = : ___________________________________________________________________
m = : __________________________________________________________________
Media A21
c = : ___________________________________________________________________
Contact: _______________________________________________________________
Via: ___________________________________________________________________
SIP A12
183-Session Progress
Nothing to declare
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 -
Media A31
Media A41
Nothing to declare
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 -
Media A32
Nothing to declare
Media A22
R
T
P
Nothing to declare
Media A12
Nothing to declare
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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
CBMS
CC
CC
CCC
CCCH
CCCH
CCF
CCH
CCITT
CCM
CCM-Mode
CCN
CCPCH
CCS7
CCTrCH
CCU
CD
CD/CA-ICH
CDCH
CDI
CDMA
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
DBP
DBPSCH
DC
DCCH
DCD
DCF
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
FR
FRMR
FRS
FSN
FTP
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
MAC-e
MAC-es
MAC-hs
MAN
MAP
MAP-B
MAP-X
MASF
Max [X, Y]
MBMS
MBS
MBSAT
MBWA
MBZ
MCC
MCCH
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
SCF
SCH
SCH
SCP
S-CPICH
SCR
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
SSCS
SSDT
SSF
SSID
SSN
SSN
SSP
SSRTG
SSSAR
ssthresh
SSTTG
STBC
STC
STC
STP
STTD
STUN
SUA
SUERM
SUFI
SUN
SVC
SVG
SWAP
T.38
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
TCP/TLS/BFCP
TCTF
TCTV
TDD
TDM
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
TLLI
TLS
TLV
TM
TM
TMD
TMGI
TMN
TMSI
TNL
TOI
ToIP
TOS
TPC
T-PDU
TPS
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
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -
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 -
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
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 -
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 -
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
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 -
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 -
T
T1................................................................................................................132
tag ( From) ..............................................................................................100
tag ( To) ..................................................................................................100
TBCP ( SDP m-line / transport) ..............................................................200
TCP ( SDP m-line / transport).................................................................200
INACON GmbH 1999 - 2010. All rights reserved. Reproduction and/or 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 -
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 -