Introduction To SIP VoIP and IMS

VoIP與IMS
SIP VoIP與介紹
IMS介紹
陳懷恩博士
助理教授兼電算中心網路組組長
國立宜蘭大學資訊工程研究所
Email: wechen@niu.edu.tw
Tel: 03-9357400#340
Outline
y Introduction to VoIP and IMS
y SIP/SDP and SIP Extensions
y IMS Architecture
A hit t
y IMS Concepts
y IMS Registration Examples
y IMS Session Examples
y Conclusions
2
Outline
y IMS Architecture
A hit t
y IMS Concepts
y Conclusions
3
Introduction to VoIP
y Transport voice traffic using the Internet Protocol (IP)
y One of the greatest challenges to VoIP is voice quality.
y One of the keys to acceptable voice quality is
bandwidth.
y Internet:
te et: best-effort
best e o t transfer
ta se
y VoIP != Internet telephony
y Carrier grade
g
y Extremely high availability
y 99.999% reliability (high reliability)
y Why VoIP:
y lower equipment cost
y low operating expense
4 y integration of voice and data applications
VoIP Protocol Stacks
5
Payload Types for Audio Encoding
Table 1. Example of payload types of audio encoding
Payload Type Name Media Type Clock Rate (Hz) Channel

0 PCMU Audio 8000 1
2 G726-32 Audio 8000 1
3 GSM Audio 8000 1
4 G723 Audio 8000 1
8 PCMA Audio 8000 1
18 G729 Audio 8000 1
6
Payload Types for Video Encoding
Table 2. Example of payload types of video encoding
Payload Type Name Media Type Clock Rate (Hz)

25 CelB Video 90000
26 JPEG Video 90000
31 H261 Audio 90000
32 MPV Audio 90000
33 MP2T Video/Audio 90000
34 H263 Video 90000
Dyn H263-1998 Video 90000
7
Speech Codecs and MOS Values
y In general,
general coding techniques are such that speech quality
degrades as bandwidth reduces.
y The relationship
p is non-linear.
8
Introduction to IMS
y Third Generation (3G) Networks aim to merge two of
the most successful paradigms in communications :
cellular networks and Internet
y IMS provide a unified service platform to achieve the
convergence of fixed and mobile networks
y Session Initiation Protocol (SIP) is adopted by 3G IP
Multimedia Subsystem (IMS) as the signaling
protocol.
protocol
y To solve the IP address shortage problem, IP version 6
(IPv6) is adopted to provide large addressing space.
space
y This talk will overview the SIP-related protocols,
introduce
t oduce IMS S co
concept
cept aand
d reference
e e e ce aarchitecture,
c tectu e, and
a d
9
utilize examples to show IMS procedures.
Outline
y IMS Architecture
A hit t
y IMS Concepts
y Conclusions
10
SIP Methods for IMS
RFC Method IMS required
RFC 2976 INFO √
RFC 3261 ACK √
(Fundamental)
(F d l) BYE √
CANCEL √
INVITE √
OPTIONS √
REGISTER √
RFC 3262 PRACK √
RFC 3265 NOTIFY √
SUBSCRIBE √
RFC 3311 UPDATE √
RFC 3428 MESSAGE √
RFC 3515 REFER √
RFC 3903 PUBLISH √
Network Entities [1/5]
y SIP User Agent (UA)
y User Agent Client (UAC)
y Application that sends requests
y The calling party
y User Agent Server (UAS)
y Application that receives requests and sends responses
y The called party
12
y Location Server (Registrar)
y A database that maintains users’ location
i f
information
i
y Receive REGISTER requests
y Record who is at where now
y Support user mobility
y Generally
ll combined
bi d with
i h a proxy or redirect
di
server
13
y Proxy Server
y Receive requests
y Forward requests or send responses back to
originator or both
y ex. 100 Trying
y Used for call forwarding, time-of-day routing or
follow-me services
14
y Redirect Server
y Receive requests
y Send responses
y Map the destination address to zero or more new
addresses
y 302 Moved Temporarily
y 404 Not Found
15
Registration Flow
16
Call Flow [1/3]
y UA to UA
INVITE Transaction
BYE Transaction
17
NotHere.org
Call Flow [2/3]
y Through Proxy Server
Location Server
bHost
(3) Bob@Bob
(2) Bob
UA Proxy Server UA
Alice@Here.org Bob@BobHost
(1) INVITE Bob@NotHere.org

(4) INVITE Bob@BobHost
(5) 200 OK
(6) 200 OK
(7) ACK
(8) ACK
18 (9) RTP Media Stream

NotHere.org
Call Flow [3/3]
y Through Redirect Server Location Server
UA
Proxy Server UA
Alice@Here.org
Bob@BobHost
(1) INVITE Bob@NotHere.org
(4) 302 Moved temprarily

Contact: Bob@BobHost
(5) ACK
(6) INVITE Bob@BobHost

(7) 200 OK
(8) ACK
19 (9) RTP Media Stream
Message Syntax
y Text-based
y Similar to HTTP
y More bandwidth consumption
y Two type
y Request
q message
g
y Response message
20
SIP Addressing
y URI: Uniform Resource Identifiers
y Format: user@host
y ex.
ex sip:0944021021@sip3
sip:0944021021@sip3.ipv6.club.tw
ipv6 club tw
y ex. sip:bean@course.ccca.nctu.edu.tw
y ex.
ex sip:0944021021@140
sip:0944021021@140.113.11.35:5060
113 11 35:5060
y ex. sip:0944021021@[3ffe:3600:2::1]:3600
21
Request Messages [1/2]
y Method SP Request
Request-URI
URI SP SIP
SIP-version
version CRLF
y Methods
y REGISTER, INVITE, ACK, BYE, CANCEL, OPTIONS
y REGISTER
y Create a mapping of public address and current address
y Can register
g to multiple
p servers
y Can register several current addresses with one public address in one
server
y INVITE
NV
y Initiate a session
y Contains information of the calling and called parties inside Headers
y Contains the type of media to be used inside Message body
y ACK only when receiving the final response
22
Request Messages [2/2]
y ACK
y Ensure receiving the final response of INVITE request
y BYE
y Terminate a session
y Can be issued by either the calling or called party
y CANCEL
y Terminate
T i t a pending
di requestt
y OPTIONS
y Query one’s capabilities
y Request-URI
y URI of the destination (UAS)
y SIP
SIP-version
i
y Generally “SIP/2.0”
23
Response Messages
y SIP-version
SIP version SP Status
Status-code
code SP Reason
Reason-phrase
phrase CRLF
y Status-code
y Three-digit number (i.e., 100 Trying or 200 OK)
y 1xx,
1xx Informational
y 2xx, Success
y 3xx, Redirection
y 4xx,
4 Request
R t Failure
F il
y 5xx, Server Failure
y 6xx, Global Failure
y 1xx
1 iis considered
id d provisional
i i l responses where
h others
h are considered
id d
final responses
y Reason-phrase
y A textual description of the outcome
24
Headers
y Provide additional information
y ex. “From” header indicates the UAC
y Four type
y General Headers
y Request Headers
y Response Headers
y Entity Headers
25
General Headers [1/2]
y Apply to both request and response messages
y Provide basic information
y ex. “To”
y URI of called party if there exists called party
y INVITE, OPTIONS
y ex. “From”
y URI of UAC
y ex. “Call-ID”
y Uniquely identifier of the session
y ex. “Contact”
y URI for future communication
26
General Headers [2/2]
y ex. “Via”
Via
y Address and port information of UA or proxies in sequence in the
routing path
y Prevent request
q looping
p g
y Ensure that responses will route via the same path as requests
y Add when send requests
y Remove when send responses
p
y ex. “CSeq”
y Command sequence
y CSeq = “CSeq:”
CSeq: DIGIT SP Method
y Consecutive requests within a session use the same Call-ID but
increasing sequence number (DIGIT)
y Requests
q and responses
p within a transaction use the same CSeqq
y ex. INVITEÆ200 OKÆACK
y ex. BYEÆ200 OK
27
Request Headers
y Apply only to request messages
y Provide additional information about the request
y ex. “Subject”
Subject
y Summary or the nature of the call
y ex. “Max-Forwards”
y Number of proxies or gateways that can forward the request
downstream
y ex. “Priority”
y
y Urgency of the request
28
Response Headers
y Apply only to response messages
y Provide further information about the response that
cannot be included in the status line
y ex. “Retry-After”
y Time in seconds that services or the calling party might being
available
y ex. “Unsupported”
y Features that are not supported by the UAS if it is asked to
support those
29
Entity Headers
y Define information about the message body
y ex. “Content-Length”
y Length of the message body
y ex. “Content-Type”
y Media type
yp of the message
g bodyy
y ex. “application/sdp”
y ex. “Context-Encoding”
y Information about encoding and decoding the message body
y ex. “Context-Language”
30
SDP Introduction
y Session Description Protocol

(SDP)
y RFC 2327
y Text-based
T b d
y Describing the media to be
exchanged
g between the pparties
y The structure of SDP
y Session level info.
y Media level info.
31
SDP Syntax
y Contains a number of lines of text
y Each line is “field=value”
y “field” is exactly one character (case-sensitive)
y “value”
“ l ” may be b one or more components
y Two main blocks
y Session level fields
y Media level fields
y Begin with media description field (m=)
y Some field can be applied at both session and media
levels.
y The value applied at the media level overrides that at the
session level.
32
SDP Fields [1/3]
y v
v=(protocol
(protocol version)
y ex. v=0
y o
o=(session
(session owner or creator)
y username, session ID, version, network type, address
type, address
y ex. o=R100-Lin 0 0 IN IP4 140.113.66.92
y s=(session name)
y ex. s=session
i
y c=(connection information)
y network
t k type,
t address
dd type,
t connection
ti address
dd
y ex. c=IN IP4 140.113.66.92
33
SDP Fields [2/3]
y b=(bandwidth information)
y In kilobits per second
y ex. b=CT:1000
y t=(time of the session)
y For pre-arranged multi-party conference
y start time, stop time
y ex. t=0 0
y m=(media
( di description)
d i i )
y media type, port, transport, media payload format list
y ex. m=audio 27644 RTP/AVP 97 111 112 6 0 8 4 5 3 101
y a=(attribute)
( ib )
y Several formats
y Session level: information about the whole session
y Media
M di level:
l l information
i f ti about
b t the
th media
di stream
t
y Take rtpmap attribute as example:
“rtpmap”, payload type, encoding name, clock rate
y ex. aa=rtpmap:97
rtpmap:97 red/8000
34
Using SDP in SIP [1/3]
y SIP uses SDP in an offer/answer mode.

y An agreement between the two parties as to the types of
media they are willing to share
y INVITE <-> 200 OK
UAC UAS
((1)) INVITE
NV
I can use both XXX and YYY as
media type
( ) 200 OK
(2)
No problem. Use XXX
35
y A mismatch happens if can
can’tt support all
codec from the other part.
y 488 Not Acceptable Here
y 606 Not Acceptable
y Caller issues a new INVITE request
36
y 200 OK <-> ACK
Special Case!!
y Unsupported should also be returned with a port number of

zero.
y ex. m=audio
di 0 RTP/AVP 2
37
Registration Message Flow [1/2]
[M1] Register
b @140 113 66 47
bean@140.113.66.47 140.113.27.54
38
Registration Message Flow [2/2]
[M1] Register
[M2] 200 OK
b @140 113 66 47
bean@140.113.66.47 140.113.27.54
39
Call Message Flow [1/15]
[M01] INVITE
bean@140.113.66.47
lin@140.113.66.92
140.113.27.54
40
[M01] INVITE
[M02] INVITE
bean@140.113.66.47
lin@140.113.66.92
140.113.27.54
41
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47
lin@140.113.66.92
140.113.27.54
42
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
140.113.27.54
[M04]
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 140.113.27.54;branch=z9hG4bK944c.70b18621.0
Via: SIP/2.0/UDP 140.113.66.47:12264
From: "bean@140.113.27.54" <sip:bean@140.113.27.54>;tag=4465847a8df4466ab7bf4cd21f4ef1f5;epid=04de356250
To: <sip:lin@140.113.27.54>;tag=adb6b6c3-bed2-4113-8cc0-2495ee252a5a
Call-ID: 383b5cdc4c784113b07e223f2f3a23c8@140.113.66.47
CSeq: 1 INVITE
User-Agent: Windows RTC/1.0
Content-Length:
Content Length: 0
43
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
140.113.27.54
44
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
140.113.27.54
[M06]
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 140.113.66.47:12264
CSeq: 1 INVITE
Record-Route: <sip:lin@140.113.27.54;ftag=4465847a8df4466ab7bf4cd21f4ef1f5;lr=on>
User-Agent: Windows RTC/1.0
Content-Length:
Content Length: 0
45
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
140.113.27.54
[M07-1]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 140.113.27.54;branch=z9hG4bK944c.70b18621.0
Via: SIP/2.0/UDP 140.113.66.47:12264
From: "bean@140.113.27.54"
" " <sip:bean@140.113.27.54>;tag=4465847a8df4466ab7bf4cd21f4ef1f5;epid=04de356250
< >
CSeq: 1 INVITE
Contact: <sip:140.113.66.92:15450>
p
User-Agent: Windows RTC/1.0 [M07-2]
Content-Type: application/sdp v=0
Content-Length: 455 o=R100-Lin 0 0 IN IP4 140.113.66.92
s=session
c=IN IP4 140.113.66.92
b=CT:1000
t=0 0
m=audio 27644 RTP/AVP 97 111 112 6 0 8 4 5 3 101
46 a=rtpmap:97 red/8000
...
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
[M08] 200 OK
140.113.27.54
47
[M01] INVITE
[M02] INVITE
[M03]
03 100 Trying
i
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
[M08] 200 OK
[M09] ACK
140.113.27.54
48
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
[M08] 200 OK
[M09] ACK
140.113.27.54 [M10] ACK
[M10]
ACK sip:140.113.66.92:15450
i 140 113 66 92 15450 SIP/2.0
SIP/2 0
Via: SIP/2.0/UDP 140.113.27.54;branch=0
Via: SIP/2.0/UDP 140.113.66.47:12264
Max-Forwards: 69
From: "bean@140.113.27.54"<sip:bean@140.113.27.54>;tag=4465847a8df4466ab7bf4cd21f4ef1f5;epid=04de356250
CSeq: 1 ACK
User-Agent:
User Agent: RTC/1.2
RTC/1 2
Content-Length: 0
49
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
[M08] 200 OK
[M09] ACK
140.113.27.54 [M10] ACK
[M11] RTP Media
50
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
[M08] 200 OK
[M09] ACK
140.113.27.54 [M10] ACK
[M11] RTP Media
[M12] BYE
51
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
[M08] 200 OK
[M09] ACK
140.113.27.54 [M10] ACK
[M11] RTP Media
[M12] BYE
[M13] BYE
[M13]
BYE sip:140.113.66.92:15450 SIP/2.0
Via: SIP/2.0/UDP 140.113.27.54;branch=z9hG4bK644c.887cba62.0
Via: SIP/2.0/UDP 140.113.66.47:12264
Max-Forwards: 69
CSeq:
q 2 BYE
User-Agent: RTC/1.2
Content-Length: 0
52
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
[M08] 200 OK
[M09] ACK
140.113.27.54 [M10] ACK
[M11] RTP Media
[M12] BYE
[M13] BYE
[M14] 200 OK
[M14]
SIP/2.0 200 OK
Via: SIP/2.0/UDP 140.113.27.54;branch=z9hG4bK644c.887cba62.0
Via: SIP/2.0/UDP
SIP/2 0/UDP 140.113.66.47:12264
140 113 66 47:12264
CSeq: 2 BYE
U
User-Agent:
A t Windows
Wi d RTC/1
RTC/1.0
0
Content-Length: 0
53
[M01] INVITE
[M02] INVITE
[M03] 100 Trying
bean@140.113.66.47 [M04] 100 Trying
lin@140.113.66.92
[M05] 180 Ringing
[M06] 180 Ringing
[M07] 200 OK
[M08] 200 OK
[M09] ACK
140.113.27.54 [M10] ACK
[M11] RTP Media
[M12] BYE
[M13] BYE
[M14] 200 OK
[M15] 200 OK
[M15]
SIP/2.0 200 OK
Via: SIP/2.0/UDP
SIP/2 0/UDP 140.113.66.47:12264
140 113 66 47:12264
CSeq: 2 BYE
U
User-Agent:
A Wi d
Windows RTC/1
RTC/1.0
0
Content-Length: 0
54
SIP Extensions
y Because of great simplicity, flexibility and other
features, SIP has attracted enormous interest.
y Traditional telecommunications companies
y Cable
C bl TV providers
id
y ISPs
y A large number of extensions to SIP have been

proposed.
y For presence and instant message
y For communication with SS7 PSTN network
y For phone transfer
55
INFO Method
y RFC 2976
y “INFO” method is defined for transferring
i f
information
ti during
d i an ongoing
i session.
i
y DTMF digits
yA
Account bbalance
l information
i f i
y Pre-paid service
56
REFER Method
y RFC 3515
y The sender of the request can
instruct the receiver to
contact a third party.
party
y Call transfer
y REFER
y The URI of the third party is in
“Refer-to” header.
y The dialog between Alice and
Bob remains established.
y Bob must inform Alice about the
status of the referece
referece.
y In message body
y Content-type: message/sipfrag
57
UPDATE Method
y RFC 3311
y “UPDATE” allows a client to update parameters of a
session but has no impact on the state of a dialog.
y Change the codec
58
PRACK Method
y Lost of p
provisional response
p ((1xx)) may
y cause pproblems when
interoperating with other network.
y 180, 183ÆQ.931 alerting or ISUP ACM
y To drive a state machine
y RFC 3262 defines PRACK Method and some Headers to support
reliability of provisional response messages.
y Supported: 100rel
y “RSeq”
“RS ” header
h d
y Response sequence
y +1 when retransmit
y “RAck”
RAck header
y Response ACK
y In PRACK
y RSeq+CSeq
y “PRACK” Method
y This mechanism should not apply to “100 Trying” and the default timer
value is 0.5 second.
59
PRACK Example
p
Alice Bob
(1) INVITE
Supported: 100rel
CSeq: 1 INVITE
(2) 180 Ringing

Require: 100rel
RSeq: 567890
Cseq: 1 INVITE
Bomb!!
( ) 180 Ringing
(3) g g
Require: 100rel
RSeq: 567891
Cseq: 1 INVITE
(4) PRACK
RAck: 567891 1 INVITE
CSeq: 2 PRACK
(2) 200 OK
CSeq: 2 PRACK
60
SUBSCRIBE & NOTIFY Method
y RFC 3265
y Some SIP-based application may
need to know the information of
a certain
t i eventt off other
th users.
y presence
y SUBSCRIBE
y Subscribe the information of a
certain event of one user
y Subscribed event in “Event” header
y NOTIFY
y Send current or updated information
of a certain event to who subscribed
me
61
MESSAGE Method
y RFC 3428
y SIMPLE (SIP for Instant
Messaging and Presence
Leveraging Extensions) is a
separate IETF working group.
y MESSAGE
y Context of message is in the message
body.
y A MESSAGE request does not
establish a SIP dialog.
62
Related SIP Header Fields for IMS
RFC header IMS required RFC header IMS required
RFC3262 RAck √ RFC3455 P-Access-Network-Info √
RFC3265 Event √
P-Associated-URI √
Subscription-sate √
RFC3313 P-Media-Authentication √ P-Called-Party-Id √
RFC3323 Privacy √
P-Charging-Function- √
Addresses
RFC3325 P-Preferred-Identity √
P-Asserted-Identity
P Asserted Identity √
P-Charging-Vector √
RFC3327 Path √
RFC3329 Security-Client √ P-Visited-Network-ID √
Security-Server √ RFC3515 Refer-To √

Security-Verify √
RFC3608 Service-Route √
RFC 3608/3515
y Service-Route
Service Route Header Field
y Used by the UA to learn the service route.
y Registrar uses Service-Route
Service Route header in a 2xx response to
a REGISTER request to inform a UA of a service route
set.
y Refer-To Header Field
y It p
provides a URL to reference.
RFC 3455
y P
P-Access-Network-Info
Access Network Info Header Field
y Transport information about the network technology and user’s location
(GPRS Cell-ID).
y P-Associated-URI
P Associated URI Header Field
y P-Called-Party-Id Header Field
y P-Charging-Function-Addresses
g g Header Field
y P-Charging-Vector Header Field
y P-Visited-Network-ID Header Field
y Transports
T t the
th identification
id tifi ti string
t i off the
th visited
i it d network
t k to
t the
th home
h
network of the user during registration, thus allow the home network to
discover details about the roaming agreements between the two
networks.
networks
Outline
y IMS A
Architecture
hit t
y IMS Concepts
y Conclusions
66
Architectural Requirements(1/5)
y IP connectivity
y IMS supports IPv6 to avoid IP address shortage problem.
y In the early deployment,
deployment IMS may use IPv4.
IPv4
y An UE may be assigned an IP address by Dynamic Host
Configuration Protocol (DHCP) server or Gateway
GPRS Support Node (GGSN).
67
IPv6 Auto-configuration
Auto configuration Example
68
IMS Connectivity Options
Type I Type II
69
Architectural Requirements (2/5)
y Ensuring quality of service
y The underlying access and transport networks together
with the IMS provide end-to-end QoSQoS.
y UEs negotiates their capabilities via the IMS.
y The UE is able to negotiate such parameters as
y Media type, bit rate, packet size,
y packet transport frequency
y Bandwidth adaptation
y Usage of RTP payload for media types
y When
Wh end-to-end
dt d QoS
Q S iis set,
t the
th UEs
UE encode
d andd packetize
k ti
the media with an appropriate protocol (e.g., RTP) and send
these media ppackets byy usingg a transport
p layer
y protocol
p (e.g.,
( g
TCP or UDP) over IP.
70
y IP policy control for ensuring correct usage of
media resources
y IP po
policy
cy control
co t o means
ea s tthee capability
capab ty to authorize
aut o e and
a d
control the usage of bearer traffic intended for IMS
media, based on the signaling parameters at the IMS
session.
session
y The means of setting up interaction can be divided into
g
three different categories:
y The policy control element is able to verify that values negotiated
in SIP signaling are used when activating bearers for media traffic.
y The policy control element is able to enforce when media traffic
between the end points of a SIP session start or stop.
y The policy control element is able to receive notifications when
the IP connectivity access network service has either modified
modified,
suspended or released the bearer(s) of a user associated with a
71
session.
y Secure communication
y Security is a fundamental requirement in every
telecommunication system
y and the IMS.
y The IMS has its own authentication and authorization
mechanisms between the UE and the IMS network in
addition to access network procedures (e.g.,
(e g GPRS
network).
y Moreover,, the integrity
g y and optional
p confidentialityy of the
SIP messages is provided between the UE and the IMS
network and between IMS network entities regardless of
the underlying core network.
network
y Therefore. the IMS provides at least a similar level of
securityy as the
corresponding GPRS and circuit-switched networks
72
y Charging arrangements
y From an operator or service provider perspective the
ability to charge users is a must in any network
y The IMS architecture supports both online and offline
charging
g g capabilities.
p
y The IMS adds the possibility to charge for user IP traffic
in a more granular manner than before.
y Session/Event-based Charge (for IMS sessions/events)
y Service specific Charge (for IMS Applications)
y Support of roaming (between IMS and CS CN)

y Interworking with other networks (PSTN, ISDN)
73
IMS Layered
y Architecture
74
Source: WiKi 3GPP / TISPAN IMS Architectural Overview
IMS Reference Architecture
(IMS--related Functions and Reference Points)
(IMS
IP Multimedia
M lti di Networks
N t k Legacy mobile
CS Network Mk Mm signalling
Networks
Mb Mb CS BGCF
I-CSCF AS
Mk Mm
CS
Mg ISC Dh
BGCF Sh
Mw Cx
Mj C, D,
Mi Gc, Gr
Cx
IM - MGCF HSS
MGW Mn Mg
S-CSCF
Dx
Mr Mw
SLF
Mb
MRFP MRFC P-CSCF

UE
Mp Gm Ut
Mb Mb Mb
IMS Subsystem
75
Source: 3GPP TS24.228
P-CSCF (Proxy-
(Proxy-Call Session Control
Function)
y P CSCF is the first contact point for users within IMS
P-CSCF
y Forward SIP messages between the UE and the S-CSCF or I-CSCF
y Detect emergency session establishment requests
y Send accounting-related information to the CCF (Charging Collection
Function)
y Provide integrity protection of SIP signaling and maintain a security
association between the UE and the P-CSCF
y Supports decompress and compress SIP messages from the UE
y To interact with the Policy Decision Function (PDF)
y Maintain session timers
76
I-CSCF ((Interrogating
Interrogating--Call Session
Control Function)
y I-CSCF is a contact point within an operator
operator'ss network for all
connections destined to a subscriber of that network operator
y Contact the HSS to obtain the name of the S-CSCF that is serving
g a user
y Assign an S-CSCF based on received capabilities from the HSS
y Forward SIP requests or responses to the S-CSCF
y Send
S d accounting-related
i l d information
i f i to the
h CCF
y Provide a topology hiding functionality
77
S-CSCF (Serving
(Serving--Call Session Control
Function)
y S CSCF performs session control and registration services for
S-CSCF
UEs
y Handle registration requests by acting as a registrar
y Authenticate
A h i users bby means off the
h IMS
SAAuthentication
h i i and d Key A
Agreement
(AKA) schema
y Download user information and service-related data from the HSS
y Route mobile-terminating traffic to the P-CSCF and route mobile-originated
traffic to the I-CSCF, the BGCF or the AS
y Select an emergency
g y centre for IMS emergency
g y sessions
y Send accounting-related information to the CCF
78
PDF ((Policy
Policy Decision Function)
Function)
y PDF is responsible for making policy decisions based on
session and media-related information obtained from the P-
CSCF
y Store and update session and media-related information (IP
addresses, port numbers, bandwidths, etc)
y Generate
G t an authorization
th i ti token
t k tot identify
id tif ththe PDF andd the
th session
i
y The capability to enable the usage of an authorized bearer (e.g.,
Packet Data Protocol, or PDP, context)
y To pass an IMS-charging identifier to the GGSN and to pass a
GPRS-charging identifier to the P-CSCF.
79
HSS ((Home
Home Subscriber Server
Server))
y Home Subscriber Server (HSS) is the main data storage
for all subscriber and service-related data of the IMS
y User identities, registration
g information, access pparameters and
service-triggering information
y HLR functionality is required to provide support to PS and CS
domain entities(PS:SGSN
entities(PS:SGSN,GGSN
GGSN CS:MSC)
y The AUC stores a secret key for each mobile subscriber
y SLF ((Subscription
p Locator Function))
y Enables the I-CSCF, the S-CSCF and the AS to find the address of
the HSS
HLR/AUC for IP Multimedia
CS Functionality
HSS Structure
HLR/AUC for
80 PS HSS
IMS--Related Functionalities
IMS
IP Multimedia
M lti di Networks
N t k Legacy mobile
CS Network Mk Mm signalling
Networks
Mb Mb CS BGCF
I-CSCF AS
Mk Mm
CS
Mg ISC Dh
BGCF Sh
Mw Cx
Mj C, D,
Mi Gc, Gr
Cx
IM - MGCF HSS
MGW Mn Mg
S-CSCF
Dx
Mr Mw
SLF
Mb
MRFP MRFC P-CSCF

UE
Mp Gm Ut
Mb Mb Mb
IMS Subsystem
81
IMS Service Functions
y MRFC (Multimedia Resource Function Controller)
y The MRFC interprets SIP signaling received via S-CSCF and uses
Media Gateway Control Protocol (MEGACO) instructions to control
the Multimedia Resource Function Processor (MRFP)
y The MRFC may send accounting information to the CCF and OCS
y MRFP (Multimedia Resource Function Processor)
y Provide user-plane resources requested and instructed by the MRFC
y Mixing of incoming media streams,
streams Media stream source
(multimedia announcement), Media stream processing (audio
transcoding)
y AS main functions include
y Process and impact an incoming SIP session received from the IMS
y Originate
O i i t SIP requestst
82 y Send accounting information to the CCF and the OCS
BGCF ((Breakout
Breakout Gateway Control
Function))
Function
y BGCF Chooses where a breakout to the CS domain occurs
y If the breakout happens in the same network, then the
BGCF selects a MGCF to handle a session further
y If the breakout takes place in another network, then the
BGCF forwards a session to another BGCF in a selected
network
y In addition, the BGCF is able to report account information
to the CCF and collect statistical information
83
MGCF (Media Gateway Control
Function))
Function
y MGCF is a gateway that enables communication between
IMS and CS users
y All incoming call control signaling from CS users is
destined to the MGCF that performs protocol conversion
between the ISDN User Part (ISUP) and SIP protocols, and
forwards the session to IMS
y In addition, MGCF is able to report account information to
the CCF
84
Interworking Functions
y SGW (Signaling Gateway)
y Used to interconnect different signaling networks, such as SCTP/IP-
based signaling networks and SS7 signaling networks
y IMS-MGW (IP Multimedia Subsystem-Media Gateway
Function)
y Provides the user-plane link between CS networks (PSTN, GSM)
and the IMS
y SEG (Security gateway)
y Protects control-plane traffic between security domains, traffic will
pass through a SEG before entering or leaving the security domain
85
Gm Reference Point
y The Gm reference point connects the UE to the IMS
y In the registration procedure the UE uses the Gm reference point to
send a registration request with an indication of supported security
mechanisms
h i to the
h P-CSCF
P CSCF
y Session control procedure
y Forward requests from the UE to the P
P-CSCF
CSCF
y Forward request from the P-CSCF to the UE
y Transaction procedure
y Send stand-alone requests (e.g., MESSAGE) and to receive all responses
(e.g., 200 OK) to that request via the Gm reference point
y Dialog is not created
86
Mw Reference Point
y SIP
SIP-based
based reference point between different CSCFs (P<
(P<->I、S
>I S S<->P、I)
S< >P I)
y Registration procedure
y Forward a registration request from the UE to the I-CSCF
y The I-CSCF then uses the Mw reference point to pass the request to the S-
CSCF
y S
Session control p
procedure
y Forward requests both from the P-CSCF to the S-CSCF and from the S-
CSCF to the I-CSCF
y Charging-related
Charging related information is conveyed via the Mw
y Transaction procedures
y Used to pass a stand-alone request (e.g., MESSAGE) and to receive all
responses (e.g., 200 OK) to that request via the Mw
y Dialog is not created
87
IMS Service Control (ISC) Reference Point
y ISC reference point for sending and receiving SIP
messages between the CSCF and an AS
y When the S-CSCF or I-CSCF receives an initial SIP request

it will analyze it. Based on the analysis the S-CSCF may
decide to route the request to an AS for further processing
y An AS may initiate a request
88
Cx Reference Point (1/3)
y Subscriber and service data are permanently stored in the
HSS
y Selected protocol is DIAMETER
y Location management procedure
y Registration and de-registration procedures between I-CSCF and
HSS
y After receiving the UAR command the HSS sends a User-Authorization-
User Authorization
Answer (UAA) command
y Registration and de-registration procedures between S-CSCF and
HSS
y After receiving the SAR command the HSS will respond with a Server-
Assignment- Answer (SAA) command
y It is the HSS that starts network-initiated de-registration by using a
command called Registration-Termination-Request
Registration Termination Request (RTR) The RTR
command is acknowledged by a Registration-Termination-Answer (RTA)
command
89
Cx Reference Point(2/3)
y Location retrieval procedure
y Find the S-CSCF when a SIP method is different than REGISTER, The
required procedure is to make use of a Location-Info-Request (LIR)
command
y The HSS responds with a Location-Info-Answer (LIA) command
y User data-handling procedure

y During the registration process, user and service-related data will be
downloaded from the HSS to the S-CSCF
S CSCF via the Cx reference point
using SAR and SAA commands
y To update the data in the S-CSCF the HSS initiates a Push-Profile-
Request (PPR) command, and S-CSCF acknowledged by a Push-
Profile-Answer (PPA) command
90
Cx Reference Point(3/3)
y Authentication procedure
y Shared secrets and sequence numbers are stored in the IP Multimedia
Services Identity Module (ISIM) in the UE and in the HSS in the
network
y When the S-CSCF needs to authenticate a user it sends a
Multimedia-Auth- Request
q (MAR)
( ) command to the HSS,SS, The HSS
SS
responds with a Multimedia-Auth-Answer (MAA) command
91
Dx Reference Point
y When multiple and separately addressable HSSs have been
deployed in a network, the I-CSCF nor the S-CSCF know
which HSS theyy need to contact , However, theyy need to
contact the SLF first
y The protocol used in this reference point is based on
DIAMETER
92
Source: The IMS:IP Multimedia Concepts and Services , John Wiley & Sons ,Ltd
Sh Reference Point (1/2)
y An AS may need user data or need to know which S-CSCF
to send a SIP request This type of information is stored in
the HSS
y Data handling
y Data handling procedures contain the possibility to retrieve user data
from the HSS
y EX: service-related data registration information, identities, initial filter
criteria, S-CSCF name servingg the user, addresses of the charging
g g
functions and even location information
y The AS uses the User-Data-Request (UDR) command to request data,
The HSS responds
p with the User-Data-Answer ((UDA))
y The AS can update transparent data in the HSS using the Profile-Update-
Request (PUR) command, acknowledged by a Profile-Update-Answer
((PUA)) command
93
Sh Reference Point (2/2)
y Subscription/Notification
y Allow the AS to get a notification when particular data for a specific user is
updated in the HSS
y The AS sends a Subscribe- Notifications-Request (SNR) command
to receive a notification of when a user's data indicated in the SNR
command are changed in the HSS, AS Acknowledged by a Push-
Notification-Answer (PNA) command
94
Dh、Mm
M 、Mg
M Reference
R f P
Points
i
y Dh Reference Point
y When multiple and separately addressable HSSs have been deployed
in the network, the AS cannot know which HSS it needs to contact
y Mm
M Reference
R f P
Point
i t
y For communicating with other multimedia IP networks, a reference
point between the IMS and other multimedia IP networks is needed
y Mg Reference Point
y The Mg reference point links the CS edge function, MGCF, to IMS
y MGCF converts ISUP signaling to SIP signaling and forwards SIP signaling
to I-CSCF
95
Mi、Mj、Mk、Ut Reference Points
y Mi Reference Point
y When the S-CSCF discovers that a session needs to be routed to the CS
domain it uses the Mi reference point to forward the session to BGCF
y Mj Reference Point
y When BGCF receives a session signaling via the Mi reference point it
selects the CS domain in which breakout is to occur
y Mk Reference Point
y When BGCF receives a session signaling via the Mk reference point it
selects the CS domain in which breakout is to occur
y Ut Reference Point
y Between
B t the
th UE andd the
th AS.
AS It enables
bl users tot securely
l manage andd
configure their network services-related information hosted on an AS
96
、Mp
Mr、
Mr 、Go
Mp、、Gq Reference Points
Go、
y Mr Reference Point
y When the S-CSCF needs to activate bearer-related services it passes SIP
signaling to the MRFC via the Mr reference point
y H.248
y Mp Reference Point
y When the MRFC needs to control media streams it uses the Mp reference
point
y H.248
H 248
y Go Reference Point
y This reference point allows operators to control QoS in a user plane and
exchange charging correlation information between IMS and GPRS network
y Gq Reference Point
y This reference point is used to exchange policy decisions-related
information between P
P-CSCF
CSCF and PDF
97
Summary of Reference Points (1/3)
Name IMS entities Description
p Protocol
Used by MRFC to fetch documents (scripts and other HTTP over dedicated
Cr MRFC, AS
resources) from an AS TCP/SCTP channels
Used to communicate between I-CSCF/S-CSCF and
Cx I-CSCF,, S-CSCF,, HSS Diameter
HSS
SIP AS, OSA, SCF, Used by AS to find a correct HSS in a multi-HSS
Dh Diameter
IM-SSF, HSS environment
Used by I-CSCF/S-CSCF to find a correct HSS in a
Dx I CSCF S
I-CSCF, S-CSCF,
CSCF SLF Diameter
multi-HSS environment
Gm UE, P-CSCF Used to exchange messages between UE and CSCFs SIP
Allows operators to control QoS in a user plane and

COPS (Rel5),
(Rel5) Diameter
Go PDF, GGSN exchange charging correlation information between
(Rel6+)
IMS and GPRS network
Used to exchange policy decisions-related information
Gq P-CSCF, PDF Diameter
between P-CSCF and PDF
ISC S-CSCF, I-CSCF, AS Used to exchange messages between CSCF and AS SIP
Used to directly forward SIP requests which are

Ma I-CSCF -> AS destinated to a Public Service Identity hosted by the SIP
AS
MGCF converts ISUP signalling to SIP signalling and
Mg MGCF -> I-CSCF SIP
98 forwards SIP signalling to I-CSCF
Name IMS entities Description
p Protocol
Used to exchange messages between S-CSCF and

Mi S-CSCF -> BGCF SIP
BGCF
Used to exchange messages between BGCF and
Mjj BGCF -> MGCF SIP
MGCF ini the
th same IMS network
t k
Used to exchange messages between BGCFs in
Mk BGCF -> BGCF SIP
different IMS networks
I-CSCF, S-CSCF, Used for exchanging messages between IMS and
Mm Not specified
external IP network external IP networks
Mn MGCF, IM-MGW Allows control of user-plane resources H.248
Used to exchange messages between MRFC and

Mp MRFC MRFP
MRFC, H 248
H.248
MRFP
Used to exchange messages between S-CSCF and
Mr S-CSCF, MRFC SIP
MRFC
P-CSCF,, I-CSCF,, S-
M
Mw U d tto exchange
Used h messages between
b t CSCFs
CSCF SIP
CSCF
P-CSCF, I-CSCF, S-
Used to exchange offline charging information with
Rf CSCF, BGCF, MRFC, Diameter
CCF
MGCF, AS
Used to exchange online charging information with
Ro AS, MRFC Diameter
ECF
99
Name IMS entities Description Protocol
SIP AS, OSA SCS, Used to exchange information between SIP AS/OSA
Sh Diameter
HSS SCS and HSS
Used to exchange information between IM-SSF and
Si IM-SSF, HSS MAP
HSS
Used by MRFC to fetch documents (scripts and other
Sr MRFC, AS HTTP
resources) from an AS
UE, AS (SIP AS, OSA Enables UE to manage information related to his
Ut HTTP(s)
SCS, IM-SSF) services
100
Outline
y IMS Architecture
A hit t
y IMS Concepts
y Conclusions
101
Registration Procedure
102
Source: ITRI
Call Setup Procedure
103
Source: ITRI
P-CSCF Discovery Procedure (1/2)
P-CSCF Discovery Procedure (2/2)
User Identities for Normal 3GPP
Network
y International Mobile Subscriber Identity (IMSI)
y A unique phone identity that is stored in the SIM
y Temporary Mobile Subscriber Identity (TMSI)
y TMSI is a temporary number generated per geographical
location
y International Mobile Equipment Identity (IMEI)
y A unique device identity
y Mobile Subscriber ISDN Number (MSISDN)
y The telephone number of a user
y IMS also requires IP Multimedia Private Identity
(IMPI) and IP Multimedia Public Identity (IMPU).
(IMPU)
106
IMS Identification (1/3)
y Identity of IMS User
y Private user identities
y Assigned by the home network operator
y Stored on ISIM (IMS Subscriber Identity Module)
y Stored within the HSS (use for registration)
y Contained in all registration requests passed from UE to home
network (for authentication)
y Not used for routing of SIP messages
y Used like IMSI (International Mobile Subscriber Identity)
107
y Private user identities
y The format of Private user identities is NAI format
y U @d
User@domain
i
y For 3GPP system
y The user part of the private user identity is the whole string of
digits from IMSI
y The domain part of the private user identity is composed of the
MCC (Mobile Country Code) and MNC (Mobile Network Code)
values of IMSI and has a predefined domain name,
IMSI 3
IMSI.3gppnetwork.org
t k
y e.g. IMSI in use: 234150123456789
MCC: 234
MNC: 15
MSIN: 0123456789
Private User Identity:
234150123456789@234.15.IMSI.3gppnetwork.org
@ gpp g
108
y Public user identities
y Every IM subscriber shall have one or more public user identities.
y The public user identity shall take the form of SIP URI or tel URL
syntax.
y SIP URI
URI: sip:
i wechen@niu.edu.tw
h @ i d
y tel URL: tel:+88639357400
y Used like MSISDN.
109
IP Multimedia Services Identity
Module (ISIM)
y ISIM is an application residing on the
Universal Integrated Circuit Card (UICC).
y The ISIM itself stores IMS
IMS-specific
specific subscriber data
mainly provisioned by an IMS operator.
y The stored data can be divided into four groups.
groups
y Security keys.
y Private user identity.
identity
y Public user identity.
y Home network domain name.
110
Relationship Between Public and
Private User Identities
111
Sharing a Single User Identity
between Multiple Devices
y In Release 6,
6 IMS allows users to register the same
public user identity from a number of
items of UE.
UE
y Preference-based
y Sequential forking.
forking
y Parallel forking.
112
Discovery P-
P-CSCF by GGSN
113
Discovery P-
P-CSCF by DHCP
114
S-CSCF Assignment
y The S-CSCF is assigned in the following cases:
y when a user registers with the network
y when an unregistered user receives a SIP request
y when a previously assigned S-CSCF is not responding
y The S-CSCF is de-assigned when a user de-registers from
the network or the network decides to de-register the user.
Then the S-CSCF to clear the stored S-CSCF name from
the HSS
HSS.
y While de-registration, an operator may keep the same S-
CSCF assigned.
assigned In this case,
case the S-CSCF informs the HSS
that the user has been deregistered and it is willing to
maintain the user profile. This optimizes the load of the Cx
reference point.
115
Service-based Local Policy (SBLP)
Service-
Entities
116
Service-
Entities
y IP Bearer Service (BS) Manager– manages the IP BS
using a standard IP mechanism. It resides in the GGSN and
optionally
p y in the UE.
y Translation/Mapping Function– provides the
interworking between the mechanism and parameters used
within the UMTS BS and those used within the IP BS. It
resides in the GGSN and optionally in the UE.
y UMTS BS Manager– handles resource reservation
requests from the UE. It resides in the GGSN and in the
UE.
UE
y Policy Enforcement Point– is a logical entity that enforces
policy decisions made by the PDF.
PDF It resides in the IP BS
117
manager of the GGSN.
Service-
Entities
y Policy Decision Function– is a logical policy decision
element that uses standard IP mechanisms to implement
SBLP in the IP media layer.
y
y In Release 5 it resides in the P-CSCF.
y In Release 6 it is a standalone entity.
y The PDF is effectively a policy decision
point according to
[RFC2753] that defines a framework for policy-based
admission
d i i control.
t l
118
SBLP Functions
y Bearer Authorization
y Approval of QoS Commit
y Removal
R l off QoS
Q S Commit
C it
y Indication of Bearer Release
y Indication of Bearer Loss/Recovery
y Revoke Authorization
y Exchange of Charging Identifiers
119
Bearer Authorization
y The P-CSCF
P CSCF will send the relevant SDP information to
the PDF together with an indication of the originator.
y The PDF authorizes the IP flows by mapping from
SDP parameters to authorized IP QoS parameters to
the GGSN via the Go interface
interface.
y While activating a PDP context for media, UE has to
perform its own mapping from SDP parameters and
application demands to some UMTS QoS parameters.
y PDP context activation will also contain the received
authorization token and flow identifiers as the binding
information.
120
Authorize QoS Resources
y During session setup,
setup the PDF collects IP QoS
authorization data.
y These data consist of :
y Flow Identifier– used to identify the IP flows that are
described within a media component associated with a
SIP session
y Data Rate– this information is derived from SDP
bandwidth parameters.
y QoS Class– the QoS class information represents the
highest class that can be used for the media component.
121
Resource Reservation
y When a PDF receives a COPS request,
request the PDF
validates that:
y The authorization token is valid
y The corresponding SIP session exists
y The binding information contains valid flow identifier(s)
y The authorization token has not changed in an
authorization modification request
q
y The UE follows the grouping indication
y If validation is successful,, then the PDF will determine
the authorized IP QoS, packet classifiers and the gate
status to be applied to the GGSN.
122
Approval/Removal of the QoS Commit
Functions
y During the resource reservation procedure a PDF sends
packet classifiers to a GGSN.
y Based on the packet classifiers
classifiers, the GGSN formulates
a gate to policy-control incoming and outgoing traffic.
y It is the PDF
PDF’ss decision when to open the gate
gate.
y When the gate is open, the GGSN allows traffic to pass
through the GGSN.
GGSN
y The removal function closes a gate in the GGSN when
a PDF does not allow traffic to traverse through the
GGSN. This function is used, for example, when a
media component of a session is put on hold due to
123 media re-negotiation.
Indication of Bearer Release/
Loss/Recovery Functions
y When the GGSN receives a delete PDP context
request, the GGSN informs the PDF of the bearer
release by sending a COPS delete request
request-state
state
message.
y Upon receipt of the COPS message,
message the PDF removes
the authorization for the corresponding media and
requests
q the P-CSCF to release the session(s).
()
y When the MBR (Max. Bit Rate) value equals 0 kbps
or is modified from 0 kbps,
p , the GGSN needs to send a
COPS report message to notify the PDF.
124
Revoke Function
y The revoke function is used to force the release of
previously authorized bearer resources in a GPRS
network.
network
y With this mechanism, the PDF is able to ensure
y the UE releases a PDP context when a SIP session is
ended
y the
e UE
U modifies
od es thee PDP context
co e when
w e a media
ed
component bound to a PDP context is removed from the
session.
125
Charging Identifiers Exchange
Function
y The Go reference point is the link between the IMS
and the GPRS networks.
y The IMS layer needs to know the corresponding GPRS
layer charging identifier and vice versa.
y These charging identifiers are exchanged during the
bearer authorization phase.
y An IMS charging identifier is delivered to the GGSN
within the authorization_decision message, while a
GPRS charging identifier is delivered to the PDF as
part of the authorization report.
126
Charging
y IMS provide two charging models
y Offline Charging
y Charging Triggering Function (CTF)
y Charging Data Function (CDF)
y Charging Gateway Function (CGF)
y Billing
g System
y
y Online Charging
y The purpose of online charging is to perform credit control before
usage of IMS services/resources
services/resources.
y Two different models exist:
y direct debiting
y unit
it reservation.
ti
y Both will communicate with OCS (Online Charging System)
y Charging Triggering Function (CTF)
127
IMS Charging Architecture
128
Security Services in the IMS
y The IMS security architecture consists of three
building blocks:
y Network Domain Security (NDS)
y IMS access security
y Authentication and Key Agreement (AKA)
y Secret (K) will share between ISIM and home network’s Authentication
Centre (AUC).
y Secret (K) and AKA will store in ISIM
129
Network Domain Security (NDS)
y Network Domain Security (NDS) accomplishes this by
providing confidentiality, data integrity, authentication and
anti-replay protection for the traffic, using a combination of
cryptographic security mechanisms and protocol security
mechanisms applied in IP security (IPsec).
y Security domains
y Security
S it domains
d i are central
t l to
t the
th conceptt off NDS
NDS.
y In the NDS/IP the interfaces between different security domains are
denoted as Za, while interfaces between elements inside a security
domain are denoted as Zb
Zb.
y Security gateways
y Traffic entering and leaving a security domain passes through a
Security Gateway (SEG)
(SEG).
130
Network Domain Security (NDS)
131
IMS Access Security
y IMS access security for SIP-based
SIP based services
y SIP is at the core of the IMS, as it is used for creating,
managing and terminating various types of multimedia
sessions.
y In the IMS core network security y is accomplished
p usingg
the NDS/IP. But UE to P-CSCF don’t support.
y Authentication and security agreement.
y AKA.
y Confidentiality and integrity protection.
y The protocol used to provide them is IPsec.
132
IMS Applications
y Voice Call
y Video Call
y Presence
P S
Service
i ((or IMPS)
y Download / Browsing (with Digital Right
Management))
M
y Push to Talk over Cellular (PoC)
y Interactive Games and Applications
133
134
Source: ITRI
Outline
y IMS Architecture
A hit t
y IMS Concepts
y Conclusions
135
User Identities(1/2)
y The identities that go into the first REGISTER request are read from
the ISIM, one of the applications contained on the UICC (Universal
Integrated Circuit Card) within the UE.
y Data
D read d ffrom the
h ISIM iinclude：
l d
y The private user identity of the user, which is only used for authentication;
y The p
public user identityy of the user, which is used for registration;
g
y The address of the SIP registrar of the user.
y IMS services can also be provided to users who own UICC cards on
which no ISIM application.
application Therefore,
Therefore the UE needs to create a
temporary public user identity from the data available from the USIM
application and use this temporary identity for registration.
y As the temporary public user identity is constructed from security-
related data on the USIM, it must not be exposed to any entity outside
the IMS.
136
User Identities(2/2)
y The IMS allows implicit and explicit registration of further public user
identities.
y Whenever a user has successfully been authenticated and registered, the
S-CSCF
S CSCF sendsd in
i the
h 200 OK response forf theh REGISTER request theh
P-Associated-URI header, which lists all the SIP URIs and tel URLs,
which are associated but not necessarily registered for the user.
y Only the first URI listed in this header is always a valid, registered
public user identity and can be used by the UE and the P-CSCF for
further actions
actions.
SIP/2.0 200 OK
P-Associated-URI:<sip:tobias@home1.fr>,<sip:tobi@home1.fr>,
<sip:gameMaster@home1.fr>,
<sip:+44-123-456-789@home1.fr;user=phone>,
<sip:+44-123-456-111@home1.fr;user=phone>
137
Visited/Home Network Home Network
P-CSCF I-CSCF HSS S-CSCF

1. Register (IMPI)
2 Register (IMPI)
2.
3. Cx-Query
Can user register in the
4. Cx-Query Resp. P-CSCF network ?
5. Cx-Select-Pull
Cx Select Pull
Request info about the
6. Cx-Select-Pull Resp. required S-CSCF cap.
7. Register (IMPI)
8 Cx
8. Cx-Put
Put
S-CSCF Send IMPI to
HSS for Auth. Vector 9. Cx-Put-Resp.
13. 401 Unauthorized

Registration Procedure (cont.)
Visited/Home Network Home Network
P-CSCF I-CSCF HSS S-CSCF

16. Register(IMPI,RES)
17 Register(IMPI
RES)
18. Cx-Select-Pull
Request Selected S-CSCF
19. Cx-Select-Pull Resp.
21 Cx-Put
21.
S-CSCF inform HSS the
register State 22. Cx-Put-Resp.
Download user profile to
access service. Service Control
Store P-CSCF address
If I-CSCF is THIG, Send Register info to
Encrypt S-CSCF Service Platform
23. 200 OK
24 200 OK
24.
25. 200 OK
(UE-->P
(UE >P--CSCF)
REGISTER sip:registrar.home1.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCE11
From: <sip:user1_public1@home1.net>;tag=4fa3
To: <sip:user1_public1@home1.net>
Contact: <sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000
Call-ID: apb03a0s09dkjdfglkj49111
Authorization: Digest username="user1_private@home1.net",
realm="registrar.home1.net", nonce="",
uri="sip:registrar.home1.net", response=""
Security-Client: ipsec-3gpp;
alg=hmac-sha-1-96;
g ;
spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357
Require: sec-agree
Proxy-Require: sec-agree
CSeq: 1 REGISTER
Supported: path
Content-Length: 0
(P--CSCF
(P CSCF-->I-
>I-CSCF)
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 69
P-Access-Network-Info:
Path: <sip:term@pcscf1.visited1.net;lr>
Require: path
P-Visited-Network-ID: "Visited Network Number 1"
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
From:
To:
Contact:
Call-ID:
realm="registrar.home1.net", nonce="",
uri="sip:registrar.home1.net",
response="", integrity
response integrity-protected="no"
protected no
…
{ The P-CSCF needs to be in the path for all mobile terminated requests for
this user. To ensure this, the P-CSCF adds itself to the Path header value
for future requests.
requests
{ The P-CSCF adds also the P-Visited-Network-ID header with the contents
of the identifier of the P-CSCF network.
(I--CSCF Æ S-CSCF)
(I
REGISTER sip:scscf1.home1.net SIP/2.0
Via: SIP/2.0/UDP icscf1_p.home1.net;branch=z9hG4bK351g45.1,
SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1,
Max-Forwards: 68
Path:
Require:
P-Visited-Network-ID:
P-Charging-Vector:
From:
To:
Contact:
{ Upon receiving this request the S-CSCF S CSCF may set its
Call-ID:
Authorization: SIP registration timer for this UE to the Expires time
CSeq: in this request or
Supported:
{ the th S S-CSCF
CSCF may assign i another th registration
i t ti timer
ti
Content-Length:
for this registration
(S--CSCF
(S CSCF-->I
>I--CSCF)
SIP/2.0 401 Unauthorized
To: <sip:user1_public1@home1.net>; tag=5ef4
WWW-Authenticate: Digest realm="registrar.home1.net",
nonce=base64(RAND + AUTN + server specific data),
algorithm=AKAv1 MD5
algorithm=AKAv1-MD5,
ik="00112233445566778899aabbccddeeff",
ck="ffeeddccbbaa11223344556677889900"
CSeq:
q 1 REGISTER
Content-Length: 0
(UE-->P
(UE >P--CSCF)
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;
comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
To: <sip:user1_public1@home1.net>
Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp>;expires=600000
Authorization: Digest username="user1_private@home1.net", realm="registrar.home1.net",
algorithm=AKAv1-MD5, uri="sip:registrar.home1.net",
response="6629fae49393a05397450978507c4ef1"
p f f RES
alg=hmac-sha-1-96;
Security-Verify:
Security Verify: ipsec
ipsec-3gpp;
3gpp; qq=00.1;
1;
alg=hmac-sha-1-96;
Require: sec-agree
Proxy Require: sec-agree
Proxy-Require: sec agree
CSeq: 2 REGISTER
Supported: path
Content-Length: 0
(P--CSCF -> I-
(P I-CSCF)
Via: SIP/2.0/UDP pcscf1.visited1.net;branch=z9hG4bK240f34.1,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 69
Require: path
P-Visited-Network-ID: "Visited Network Number 1"
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024"
From:
To:
Contact:
Call-ID:
realm="registrar.home1.net",
algorithm=AKAv1-MD5
algorithm AKAv1 MD5, uriuri="sip:registrar
sip:registrar.home1.net
home1 net",
response="6629fae49393a05397450978507c4ef1",
integrity-protected="yes"
CSeq:
Supported:
Content-Length:
(S--CSCF -> I-
(S I-CSCF)
SIP/2.0 200 OK
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Service-Route: <sip:orig@scscf1.home1.net;lr>
From:
To:
Call-ID:
CSeq:
Date: Wed, 11 July 2001 08:49:37 GMT
P-Associated-URI: <sip:user1
p _ppublic2@home1.net>,
@ ,
<sip:user1_public3@home1.net>,
<sip:+1-212-555-1111@home1.net;user=phone>
Content-Length:
Re--registration Procedure
Re
y Before the registration expires, the UE re-registers by sending a new
REGISTER request. This request is sent to the same P-CSCF with
which the UE initially registered.
Re--registration Procedure
Re
Vi SIP/2.0/UDP
Via: SIP/2 0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
[5555 bbb ddd] 1357 i b h 9hG4bK hd 7
Max-Forwards: 70
T <sip:user1_public1@home1.net>
To: <i 1 bli 1@h 1 t>
realm="registrar home1 net"
realm="registrar.home1.net",
algorithm=AKAv1-MD5, uri="sip:registrar.home1.net",
integrity protected="yes"
integrity-protected= yes
alg=hmac-sha-1-96; spi-c=23456789; spi-s=12345678; port-c=2468; port-s=1357
Security-Verify: ipsec-3gpp; q=0.1;
alg=hmac-sha-1-96;
alg hmac-sha-1-96; spi-c=98765432;
spi-c 98765432; spi-s=87654321;
spi-s 87654321; port-c=8642;
port-c 8642; port-s=7531
port-s 7531
Require: sec-agree
{ Upon receiving this request the P-CSCF will detect
CSeq: 3 REGISTER
Supported: path that it alreadyy has a registration
g record for this UE
Content-Length: 0 and will reset it's SIP registration timer for this UE to
the Expires time in this request.
UE
UE’ss Subscription to Registration
Registration--state
Information
Visited fi (Finland)
Visited.fi Home1 fr (France)
Home1.fr
Tobias’s
Tobias s UE P CSCF
P-CSCF S CSCF
S-CSCF
(1) SUBSCRIBE (2) SUBSCRIBE
To: tobias@home1.fr To: tobias@home1.fr
From: tobias@home1.fr
tobias@home1 fr F
t bi @h 1f
Event: reg Event: reg
Route: pcscf:ps1,scscf Route: scscf
200 OK
200 OK
NOTIFY
NOTIFY
tobias@home1 fr
From: tobias@home1.fr To: tobias@home1.fr
To: tobias@home1.fr Route: pcscf
XML body: registration state XML body: registration state information
information
200 OK
149 200 OK
UE
UE’ss Subscription to Registration
Registration--state
Information
(1)
SUBSCRIBE sip:tobias@home1.fr SIP/2.0
Via: SIP/2.0/UDP [5555::1:2:3:4]:1357; comp=sigcomp; branch=4uetb
Route: <sip:[5555::a:b:c:d]:7531;lr>
Route: <sip:orig@scscf1.home1.fr;lr>
From: "Tobias" <sip:tobias@home1.fr>; tag=sipuli
To: "Tobias" <sip:tobias@home1.fr>
P-Preferred-Identity: "Tobias" <sip:tobias@home1.fr>
Event: reg
g
Expires: 600000
Accept: application/reginfo+xml
Contact: <sip:[5555::1:2:3:4]:1357>
p[ ]
Content-Length: 0
( )
(2)
150 P-Asserted-Identity: "Tobias" <sip:tobias@home1.fr>
P-CSCF’s
CSCF s Subscription to Registration
Registration--
state Information
Visited.fi (Finland) Home1.fr (France)
P-CSCF I-CSCF S-CSCF
(1) SUBSCRIBE SUBSCRIBE

To: tobias@home1.fr To: tobias@home1.fr
tobias@home1 fr
From: pcscf From: pcscf
Event: reg Event: reg
Contact: pcscf Contact: pcscf 200 OK
200 OK
(2)NOTIFY
To: pcscf
XML body: registration state information
200 OK
151
P-CSCF’s Subscription
p to
Registration--state Information
Registration
(1)
Via: SIP/2
SIP/2.0/UDP
0/UDP pcscf1.visited1.fi
pcscf1 visited1 fi
From: <sip:pcscf1.visited1.fi>; tag=retiisi
To: "Tobias" <sip:tobias@home1.fr>
PA
P-Asserted-Identity:
d Id i <sip:pcscf1.visited1.fi>
i f1 i i d1 fi
Event: reg
Expires: 600000
Accept: application/reginfo+xml
Contact: <sip:pcscf1.visited1.fi>
Content-Length:
Content Length: 0
152
The NOTIFY Request
q as received by
y
Tobias’s UE
(2)
NOTIFY sip:[5555::1:2:3:4]:1357; comp=sigcomp SIP/2.0
Via: SIP/2.0/UDP
SIP/2 0/UDP scscf1.home1.fr;
scscf1 home1 fr; branch=nosctb
branch nosctb
Via: SIP/2.0/UDP pcscf1.visited1.fi:7531; branch=nopctb
From: "Tobias" <sip:tobias@home1.fr>; tag=peruna
T "Tobias"
To: "T bi " <sip:tobias@home1.fr>;
i t bi @h 1 f tag=sipuli
t i li
Subscription-State: active; expires=599999
Event: reg
Content-Type: application/reginfo+xml
Contact: <sip:scscf1.home1.fr>
Content-Length:
Content Length: (...)
153
Registration--state Information of NOTIFY
Registration
Request
1) reginfo
y xmins, version, state
2) registration
y aor (Address Of Record): The URI for the public user identity
y id: Uniquely identifies the registration sub-element
y state:
y active: (i.e., registered)
y terminated: (i.e., de-registered)
y init: (i
(i.e.,
e in the process of being registered)
3) contact
y id: Uniquely identifies the contact sub-element
y state
t t
y active: (i.e., the URI is registered with this contact information)
y terminated: (i.e., the binding between the URI and this contact information has just been
removed))
y event: registered, created, refreshed, shortened, deactivated, probation, unregistered,
154 rejected, expire, retry-after
Example
p Registration-
Registration
g -state
Information (1/2)
y Tobias’s registration-state information is included in the body of the NOTIFY requests
that the S-CSCF sends out to the UE and the P-CSCF.
<?xml version="1.0"?>
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="0" state="full">
<registration aor=
aor="sip:tobias@home1
sip:tobias@home1.fr
fr" id=
id="a1"
a1 state=
state="active">
active >
<contact id="15" state="active" event="registered">
sip:[5555::1:2:3:4]
</contact>
</registration>
<registration aor="tel:+44-123-456-789" id="a2" state="active">

<contact id="16" state="active" event="created">
sip:[5555::1:2:3:4]
</contact>
155
</registration>
Example
p Registration-
Registration
g -state
Information (2/2)
<registration aor="sip:tobi@home1.fr" id="b1" state="terminated">
</registration>
<registration aor
aor="tel:+44-123-456-111"
tel:+44 123 456 111 id
id="b2"
b2 state
state="terminated">
terminated >
</registration>
<registration
i i aor="sip:gameMaster@home1.fr"
"i M @h 1 f " id="c1"
id " 1" state="active">
" i "
sip:[5555::101:102:103:104]
</contact>
contact id="19"
<contact id 19 state
state="active"
active event
event="created">
created
sip:[5555::1:2:3:4]
</contact>
</registration>
/ i t ti
156 </reginfo>
Re--registration and Re-
Re Re-authentication
y User-initiated re-registration
y Tobias’s UE can at any time perform re-registration by sending a new REGISTER
request to the network.
y Network-initiated re-authentication
y The IMS UE registers its contact information for a time of 600000 seconds, which
means that the bindingg of the registered
g public
p user identities and the physical
p y IP
address is kept for around 7 days in the S-CSCF.
y The S-CSCF can reduce the expiry time of the user’s registration. Assume the home
operator wants to perform a random re-authentication. The S-CSCF will reduce the
expiry time of Tobias’s registration to 600 seconds.
y The S-CSCF makes use of the UE’s subscription to the registration-state event
package. The S-CSCF generates a NOTIFY request for the registration-state event
package in which it indicates that it shortened the registration time and sends this
package,
NOTIFY request to Tobias’s UE.
y On receiving this request the UE will immediately update the registration expiry time
information.
157
Network--initiated Re-
Network Re-authentication
Notification
<reginfo xmlns="urn:ietf:params:xml:ns:reginfo" version="2" state="partial">
<registration aor
aor="sip:tobias@home1
sip:tobias@home1.fr
fr" id
id="a1"
a1 state
state="active">
active >
<contact id="15" state="active" event="shortened" expires="600">
sip:[5555::1:2:3:4] </contact> </registration>
<registration
i i aor="tel:+44-123-456-789"
" l 44 123 456 789" id="a2"
id " 2" state="active">
" i "
<registration aor="sip:gameMaster@home1.fr" id="c1" state="active">
sip:[5555::101:102:103:104] </contact>
/contact
sip:[5555::1:2:3:4] </contact>
</registration>
/ i t ti
158 </reginfo>
De--registration
De
y User-initiated de-registration
y Tobias might want to be undisturbed after he called his sister and switches
off his mobile phone.
phone When doing so, so his phone sends another REGISTER
request to the S-CSCF, including all the information we have already seen,
but indicating that this time it is for de-registration.
y The S-CSCF will then clear all the information it has stored for Tobias,
Tobias
update the data in the HSS and send a 200 OK response to Tobias’s UE.
y Network-initiated de-registration
y Sometimes the network need to de-register the user: maybe the S-CSCF
needs to be shut down or maybe Tobias is using a pre-paid card and has ran
out of money.
y In these cases the S-CSCF would simply send another NOTIFY message
with registration-state information to Tobias’s UE, this time indicating that
he has been de-registered.
159
User--initiated De-
User De-registration(1/4)
Tobias’s UE P-CSCF I-CSCF S-CSCF
(1) REGISTER
REGISTER
Contact: ue
ue-address:ps1;
address:ps1; REGISTER
expires=0
200 OK
200 OK
200 OK
(2)NOTIFY
NOTIFY (Tobias’s registration state information –
“unregistered” event)
200 OK
200 OK
NOTIFY
(Tobias’s registration state information –
“unregistered”
unregistered event)
200 OK
160
User--initiated De-
(1)
REGISTER sip:home1.fr SIP/2.0
Via: SIP/2
SIP/2.0/UDP
0/UDP [5555::1:2:3:4]:1357;comp
[5555::1:2:3:4]:1357;comp=sigcomp;branch=99uetb
sigcomp;branch 99uetb
Route: sip:[5555::a:b:c:d]:7531;comp=sigcomp;lr
Max-Forwards: 70
F
From: <sip:tobias@home1.fr>;tag=ulkomaa
i bi @h 1f lk
To: <sip:tobias@home1.fr>;tag=kotimaa
Authorization: Digest username="user1_private@home1.fr",
realm="home1.fr",
nonce=A34Cm+Fva37UYWpGNB34JP, algorithm=AKAv1-MD5,
uri sip:home1.fr ,
uri="sip:home1.fr",
integrity-protected="yes"
161
User--initiated De-
Require: sec-agree
Security-Verify:
Security Verify: tls ;q=0
;q 0.2,
2 IPsec-3gpp;
IPsec 3gpp; qq=0
0.1;
1; alg
alg=hmac-sha-1-96;
hmac sha 1 96;
Security-Client: digest, IPsec-3gpp; alg=hmac-sha-1-96;
spi-c=23456790;
i 23456790 spi-s=12345679;
i 12345679 port-c=2472;
2472 port-s=1357
1357
Contact: <sip:[5555::1:2:3:4]:1357; comp=sigcomp>; expires=0
CSeq: 49 REGISTER
Content-Length: 0
162
User--initiated De-
NOTIFY sip:[5555::1:2:3:4]:1357;comp=sigcomp SIP/2.0
Subscription-State: terminated
<registration aor="sip:tobias@home1.fr" id="a1" state=“terminated">
<contact id="15" state="terminated" event="unregistered">
<registration aor="tel:+44-123-456-789" id="a2" state="terminated">
<registration aor="sip:gameMaster@home1.fr" id="c1" state="active">
<contact id="45" state="active" event="refreshed">
sip:[5555::101:102:103:104] </contact>
sip:[5555::1:2:3:4]
p[ ] </contact> </registration>
g
</reginfo>
163
Network--initiated De-
Network De-registration(1/2)
Tobias’s UE P-CSCF S-CSCF

(3)NOTIFY
NOTIFY (Tobias’s registration state information –
“d
“deactivated”
ti t d” event)t)
200 OK
200 OK
NOTIFY
((Tobias’s registration
g state information –
“deactivated” event)
200 OK
164
Network--initiated de-
Network de-registration(2/2)
(3)
<registration aor="sip:tobias@home1.fr" id="a1" state="terminated">
<contact id="15" state="terminated" event="deactivated">
sip:[5555::1:2:3:4] </contact>
</registration>
<registration aor="tel:+44-123-456-789" id="a2" state="terminated">
sip:[5555::1:2:3:4] </contact>
</registration>
<registration
g aor="sip:gameMaster@home1.fr"
pg @ id="c1" state="terminated">
sip:[5555::101:102:103:104] </contact>
165 </reginfo>
Outline
y IMS Architecture
A hit t
y IMS Concepts
y Conclusions
166
Session Setup Procedure
Procedure-- 1
Procedure-- 2
Procedure-- 3
RTP Streams
Identification of the Calling User(1/3)
[UE->P-CSCF]
INVITE sip:theresa@home2. hu SIP/2 . 0
From: "Your Brother"
<sip:tobi@brother.com>;tag=veli
To: "My beloved Sister" <sip:Theresa@sister. com>
P-Preferred-Identity: <sip:tobias@home1.fr>
Privacy: None
[P-CSCF->S-CSCF]
INVITE sip:theresa@home2.hu SIP/2.0
From: "Your Brother"
<sip:tobi@brother.com>;tag=veli
To: "My beloved Sister" <sip:Theresa@sister.com>
P-Asserted-Identity: <sip:tobias@home1.fr>
Privacy: None
y Originating P-CSCF includes the P-Asserted-Identity header field

170
y Originating S
S-CSCF
CSCF and P Asserted Identity header
P-Asserted-Identity
INVITE sip: theresa@home2.hu SIP/2.0

From: "Your Brother" <sip:tobi@brother.com>;tag=veli
P-Asserted-Identity: <sip:tobias@home1.fr>,<tel:+44123456789>
Privacy: None
171
P Asserted Identity header field at the
y P-Asserted-Identity
terminating side
y The P-CSCF
P CSCF of Theresa has to check the value of the
Privacy header of the request
y As it is not set to the value "id“
id , it can send the P
P-
Asserted-Identity header field to Theresa's UE
172
Identification of the Called User
y Its first line, the request URI
y INVITE sip: theresa@home2 .hu SIP/2 . 0
y If Theresa is currently not registered with this public user identity, the S-
CSCF will return,
return say,
say a 404 (Not Found) response to the INVITE request
y This P-Called-Party-ID header includes the public user identity that
was received in the request URI
y INVITE sip: [5555: :5:6:7:8] :1006 SIP/2.0
P-Called-Party-ID: sip:theresa@home2.hu
SIP/2.0 183 Session in Progress SIP/2.0 183 Session in Progress

From: "Your Brother" <sip:tobi@brother.com>;tag=veli From: "Your Brother" <sip:tobi@brother.com>;tag=veli
To: "My beloved Sister" To: "My beloved Sister" <sip:Theresa@sister.com>;
<sip:Theresa@sister.com>;tag=schwester tag=schwester
P Preferred Identit <sip
P-Preferred-Identity: <sip:theresa@home2.hu>
theresa@home2 h > P Asserted Identit <sip
P-Asserted-Identity: <sip:theresa@home2.hu>
theresa@home2 h >
Privacy: None Privacy: None
173
Routing of the INVITE Request and
Response(1/2)
I-CSCF P-CSCF
Tobias P-CSCF S-CSCF S-CSCF Theresa
INVITE
INVITE
INVITE sip : theresa@home2.hu SIP/2 . INVITE sip:theresa@home2.hu SIP/2.0
0 Vi SIP/2.0/UDP
Via: SIP/2 0/UDP pcscf1.visited1.fi;branch=9pctb
f1 i it d1 fi b h 9 tb
INVITE
Via: SIP/2.0/UDP [5555::1:2:3:4] :
1357;branch=8uetb
Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb
Record-Route: <sip:pcscf1.visitedl.fi;1r>
INVITE
Route: <sip: [5555: :a:b:c:d] :7531;1r> Route: <sip:orig@scscf1.home1.fr;1r>
Via: SIP/2.0/UDP scscf1.home1.fr;branch=asctb
INVITE
Route: <sip:orig@scscf1.home1.fr; 1r> Contact: <sip: [5555: :1:2:3:4] :1357>
INVITE sip:theresa@home2.hu SIP/2.0
Contact: <sip: [5555: :1:2:3:4] :1357> Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb INVITE
100 Trying Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth
Via: SIP/2.0/UDP scscf1.home1.fr ;branch=asctb INVITE sip: [5555::5:6:7:8] : 1006 SIP/2.0
Record-Route: <sip:scscf1.home1.fr;1r>
Record-Route: <sip:pcscf1.visitedl.fi;1r> Via: SIP/2.0/UDP pcscf1.visitedl.fi;branch=9pctb Via: SIP/2 . 0/UDP scscf2.home2.hu;branch=cscth
100 Trying Contact: <sip: [5555::1:2:3:4]:1357> Via: SIP/2.0/UDP Via: SIP/2. 0/UDP icscf1.home2 .hu;branch=bicth
Via: SIP/2. 0/UDP scscf1.home1.fr ;branch=asctb
INVITE sip: [5555::5:6:7:8] :1006 SIP/2.0
Via: SIP/2.0/UDP pcscf2.home2.hu:
[5555::1:2:3:4] :1357;branch=8uetb
Route: <sip:scscf2.home2.hu;1r>
p ; Via: SIP/2 .0/UDP pcscf1.visited1.fi;branch=9pctb 1511 ;branch=dpcth
Record-Route: <sip:scscf1.homel.fr;1r> Via: SIP/2.0/UDP Via: SIP/2.0/UDP scscf2.home2.hu;branch=cscth
Record-Route: <sip:pcscf1.visitedl.fi;1r> [5555::1:2:3:4] :1357;branch=8uetb Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth
Contact: <sip: [5555::1:2:3:4] :1357> Route: <sip:pcscf2.home2.hu;1r> Via: SIP/2.0/UDP scscf1.home1.fr ;branch=asctb
Record-Route: <sip:scscf2.home2.hu;1r> Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb
Record-Route: <sip:scscf1.homel.fr;1r> Via: SIP/2.0/UDP
100 Trying Record-Route: <sip:pcscf1.visitedl.fi;1r> [5555::1:2:3:4] :1357;branch=8uetb
Contact: <sip: [5555::1:2:3:4] :1357> Record-Route: <sip:pcscf2.home2.hu:1511;1r>
Record-Route: <sip:scscf2.home2.hu;1r>
100 Trying 100 Trying Record-Route:<sip:scscf1.homel.fr;lr>
Record-Route: <sip:pcscf1.visitedl.fi;lr>
Contact: <sip: [5555::1:2:3:4] :1357>
100 Trying
183 Session in Progress

183 Session in Progress SIP/2.0 183 Session in Progress
183 Session in Progress INVITE sip:theresa@home2.hu SIP/2.0
SIP/2.0 183 Session in Progress
Via: SIP/2 . 0/UDP scscf2.home2.hu;branch=cscth
Via: SIP/2. 0/UDP pcscf2.home2.hu :
1511 ;branch=dpcth
INVITE sip:theresa@home2.hu SIP/2.0 Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth Via: SIP/2 . 0/UDP
INVITE sip:theresa@home2.hu
i th @h 2 h SIP/2.0
SIP/2 0 Vi SIP/2
Via: SIP/2.0/UDP
0/UDP scscf1.home1.fr
f1 h 1 f ;branch=asctb
b h tb Via: SIP/2.0/UDP
/ / scscf1.home1.fr
f h f ;branch=asctb
b h b Via: SIP/2. 0/UDP scscf1.home1.fr;branch=asctb scscf2.home2.hu;branch=cscth
SIP/2.0 183 Session in Progress Via: SIP/2.0/UDP pcscf1.visitedl.fi;branch=9pctb Via: SIP/2.0/UDP pcscf1.visitedl.fi;branch=9pctb Via: SIP/2.0/UDP pcscf1.visitedl.fi;branch=9pctb Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb Via: SIP/2 . 0/UDP icscf1.home2.hu;branch=bicth
Via: SIP/2.0/UDP [5555::1:2:3:4] :1357;branch=8uetb
Via: SIP/2.0/UDP Via: SIP/2.0/UDP Via: SIP/2.0/UDP Via: SIP/2.0/UDP Via: SIP/2.0/UDP scscf1.home1.fr;branch=asctb
Record-Route: <sip:pcscf2.home2.hu;1r> [5555::1:2:3:4] :1357;branch=8uetb [5555::1:2:3:4] :1357;branch=8uetb [5555::1:2:3:4] :1357;branch=8uetb [5555::1:2:3:4]:1357;branch=8uetb Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb
Record-Route: <sip:scscf2.home2.hu;1r> Record-Route: <sip:pcscf2.home2.hu;1r> Record-Route: <sip:pcscf2.home2.hu;1r> Record-Route: <sip:pcscf2.home2.hu;1r> Record-Route: <sip:pcscf2.home2.hu;1r> Via:
Record-Route: <sip:scscf1.home1.fr;1r> Record-Route: <sip:scscf2.home2.hu;1r> Record-Route: <sip:scscf2.home2.hu;1r> Record-Route: <sip:scscf2.home2.hu;1r> Record-Route: <sip:scscf2.home2.hu;1r> SIP/2.0/UD5555::1:2:3:4]:1357;branch=8uetb
Record-Route: <sip:pcscf1.visited1.fi:7531;1r> Record-Route:<sip:scscf1.homel.fr;1r> Record-Route:<sip:scscf1.homel.fr;1r> Record-Route:<sip:scscf1.homel.fr;1r> Record-Route:<sip:scscf1.homel.fr;1r> Record-Route: <sip:pcscf2.home2.hu:1511;1r>
Contact: <sip: [5555 : : 5 : 6 : 7 : 8 ] :1006> Record-Route: <sip:pcscf1.visitedl.fi;1r> Record-Route: <sip:pcscf1.visitedl.fi;1r> Record-Route: <sip:pcscf1.visitedl.fi;1r> Record-Route: <sip:pcscf1.visitedl.fi;1r> Record-Route: <sip:scscf2.home2.hu;1r>
Contact: <sip:[5555::5:6:7:8]:1006> Contact: <sip:[5555::5:6:7:8]:1006> Contact: <sip:[5555::5:6:7:8]:1006> Contact: <sip:[5555::5:6:7:8]:1006> Record-Route: <sip:scscf1.homel.fr;1r>
Contact: <sip: [5555: : 5 : 6 : 7 : 8 ] :1006>
174
Routing of the INVITE Request and
Response(2/2)
I-CSCF P-CSCF
P-CSCF S-CSCF S-CSCF UE
UE
PRACK
PRACK
PRACK sip: [5555: :5:6:7:8] :1006 SIP/2.0
Vi SIP/2
Via: SIP/2.0/UDP
0/UDP PRACK sip:
i [5555:
[5555 :5:6:7:8]
5 6 7 8] :1006
1006 SIP/2.0
SIP/2 0
PRACK
[5555::1:2:3:4]:1357;branch=82uetb Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb
Route: <sip:pcscf1.visited1.fi:7531;1r> Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=82uetb
PRACK sip: [5555: :5:6:7:8] :1006 SIP/2.0
Route: <sip:scscf1.homel.fr;1r> Route: <sip:scscf1.homel.fr;1r>
PRACK
Route: <sip:scscf2.home2.hu;1r> Route: <sip:scscf2.home2.hu;1r>
Route: <sip:pcscf2.home2.hu;1r> Route: <sip:pcscf2.home2.hu;1r> Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb
Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=82uetb
PRACK
Route: <sip:scscf2.home2.hu;1r> PRACK sip: [5555: :5:6:7:8] :1006 SIP/2.0
Route: <sip:pcscf2.home2.hu;1r> Via: SIP/2 . 0/UDP scscf2.home2.hu;branch=cscth
Via: SIP/2.0/UDP scscf1.home1.fr;branch=asctb PRACK sip: [5555: :5:6:7:8] :1006 SIP/2.0
Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb Via: SIP/2.0/UDP pcscf2.home2.hu:
Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=82uetb 1511 ;branch=dpcth
Route: <sip:pcscf2.home2.hu;1r> Via: SIP/2 . 0/UDP
scscf2.home2.hu;branch=cscth
Via: SIP/2.0/UDP pcscf1.visited1.fi;branch=9pctb
Via: SIP/2.0/UDP
[5555::1:2:3:4]:1357;branch=82uetb
200 OK
200 OK
SIP/2.0
SIP/2 0 200 OK
200 OK SIP/2.0 200 OK
Via: SIP/2.0/UDP pcscf2.home2.hu:
1511 ;branch=dpcth
200 OK Via: SIP/2 . 0/UDP scscf2.home2.hu;branch=c2scth
Via: SIP/2. 0/UDP scscf1.home1.fr;branch=a2sctb
Via: SIP/2 . 0/UDP scscf2.home2.hu;branch=c2scth
SIP/2.0 200 OK Via: SIP/2 . 0/UDP pcscf1.visited1.fi;branch=92pctb Via: SIP/2 . 0/UDP pcscf1.visited1.fi;branch=92pctb
200 OK SIP/2.0 200 OK
Via: SIP/2 . 0/UDP pcscf1.visited1.fi;branch=92pctb
Via: SIP/2.0/UDP [5555::1:2:3:4] Via: SIP/2.0/UDP
[5555::1:2:3:4] :1357;branch=82uetb
Via: SIP/2 . 0/UDP pcscf1.visited1.fi;branch=92pctb Via: SIP/2.0/UDP [5555::1:2:3:4]
Via: SIP/2.0/UDP [5555::1:2:3:4]
SIP/2.0 200 OK
Via: SIP/2.0/UDP [5555::1:2:3:4]
175
Routing to and from ASs
AS I-CSCF
S-CSCF
INVITE

Via: SIP/2.0/UDP scscf1.homel.fr;branch=asctb Filter criteria evaluation
Via: SIP/2.0/UDP pcscf1.visitedl.fi;branch=9pctb
Via: SIP/2.0/UDP [5555::1:2:3:4] :1357;branch=8uetb INVITE
Route: <sip:orig@scscf1
<sip:orig@scscf1.home1.fr;1r>
home1 fr;1r>
From: "Your Brother" <sip:tobi@brother.com>;tag=veli
Via: SIP/2.0/UDP sip:scscf1.home1.fr;branch=9sc2as2tb
P-Asserted-Identity: <sip:tobias@home1.fr> Via: SIP/2. 0/UDP pcscf1.visited1.fi;branch=9pctb
Privacy: None Via: SIP/2.0/UDP [5555::1:2:3:4]:1357;branch=8uetb
Route: <sip:as2.homel.fr;1r>
p ;
Route: <sip:scscf1.homel.fr;1r>;dia-id=6574839201
Record-Route: <sip:scscf1.home1.fr;1r>
Record-Route: <sip:pcscf1.visited1.fi;1r>
INVITE
INVITE sip:theresa@home2
sip:theresa@home2.hu hu SIP/2
SIP/2.00
Via: SIP/2.0/UDP sip:as2.home1.fr;branch=vas2tb
Via: SIP/2. 0/UDP sip: scscf1.home1.fr ;branch=9sc2as2tb
Via: SIP/2 . 0/UDP pcscf1.visited1.fi;branch=9pctb
Via: SIP/2.0/UDP [5555::1:2:3:4] :1357;branch=8uetb
Route: <sip:scscf1.home1.fr;1r>;dia-id=6574839201
Record-Route: <sip:as2.homel.fr;lr>
p ;
Record-Route: <sip:scscf1.homel.fr;1r>
Record-Route: <sip:pcscf1.visitedl.fi;1r> INVITE
176
Routing to and from ASs
Filter criteria Example

p in Tobias’s S-CSCF
Compression Negotiation
P-CSCF
Theresa
INVITE
INVITE
INVITE sip: [5555::5:6:7:8] :1006;comp=SigComp SIP/2.0

Via: SIP/2.0/UDPpcscf2.home2.hu:1511;comp=SigComp;1r;branch=dpcth
Via: SIP/2.0/UDP scscf2.home2.hu;branch=cscth
Via: SIP/2.0/UDP icscf1.home2.hu;branch=bicth
Via: SIP/2.
/ 0/UDP
/ scscf1.homel.fr;branch=asctb
;
Via: SIP/2. 0/UDP pcscf1.visited1.fi;branch=9pctb
Via: SIP/2.0/UDP[5555::1:2:3:4]:1357;branch=8uetb
Record-Route: <sip:pcscf2.home2.hu:1511;comp=SigComp;1r>
Record-Route: <sip:pcscf1.visitedl.fi; 1r>
Contact: <sip:
p [5555::1:2:3:4]
[ ] :1357;comp=SigComp>
; p g p
183 Session Progress


Via: SIP/2 .0/UDP pcscf2.home2.hu: 1511; comp=SigComp; 1r
Via: SIP/2.0/UDP scscf2.home2.hu
Via: SIP/2.0/UDP scscf2.home2.hu
Via: SIP/2.0/UDP
SIP/2 0/UDP icscfl
icscfl.home2.hu
home2 hu
Via: SIP/2.0/UDP icscf1.home2.hu
Via: SIP/2.0/UDP scscf1.homel.fr,
Via: SIP/2. 0/UDP scscf1.home1.fr,
Via: SIP/2. 0/UDP pcscf1.visited1.fi
Via : SIP/2.0/UDP pcscf1.visited1.fi
Via: SIP/2.0/UDP [5555::1:2:3:4] :1357
Via: SIP/2.0/UDP [5555::1:2:3:4] :1357
Record-Route: <sip:pcscf2.home2.hu;1r>
Record-Route: <sip:pcscf2.home2.hu:1511;comp=SigComp;1r>
Record-Route: <sip:scscf1.homel.fr;lr>
<sip:pcscf1 visitedl fi;1r>
Record-Route: <sip:pcscf1.visited1.fi;1r>
Contact: <sip:
Contact: <sip:[5555::5:6:7:8]:1006;comp=SigComp>
[5555: :5:6:7:8] :1006;comp=SigComp>
Media Negotiation(1/2)
P-CSCF S-CSCF I-CSCF S-CSCF P-CSCF Theresa
Tobias
INVITE
INVITE INVITE
v=0 INVITE
o=1357924 1357924IN IP6 IN IP6 5555::1:2 : 3 : 4 INVITE INVITE
s=-
c = IN IP6 5555: :1:2:3:4 v=0
t=907165275 0 o=- 1357924 1357924IN IP6 IN IP6 5555::1:2 : 3 : 4
m=audio 3458 RTP/AVP 0 96 97 98 s=-
a=rtpmap:0 PCMU c = IN IP6 5555: :1:2:3:4
a=rtpmap:96 G726-32/8000 t=907165275 0
a=rtpmap:97 AMR-WB m=audio 3458 RTP/AVP 0 96 97 98
a=rtpmap:98 telephone-event a=rtpmap:0 PCMU
m=video 3400 RTP/AVP 98 99 a=rtpmap:96 G726-32/8000
a=rtpmap:98 MPV a=rtpmap:97 AMR-WB
a=rtpmap:99 H.261 a=rtpmap:98 telephone-event
m=video 3400 RTP/AVP 98 99
a=rtpmap:98 MPV
a=rtpmap:99 H.261

183 Session Progress 183 Session Progress
v=0
o=- 1357924 1357924 IN IP6 5555::5:6:7:8 v=0
s=- o=- 1357924 1357924 IN IP6 5555::5:6:7:8
c=IN IP6 5555::5:6:7:8 s=-
t=907165275 0 c=IN IP6 5555::5:6:7:8
m=audio 4011 RTP/AVP 96 97 98 t=907165275 0
a=rtpmap:96 G726-32/8000 m=audio 4011 RTP/AVP 96 97 98
a=rtpmap:97 AMR-WB a=rtpmap:96 G726-32/8000
a=rtpmap:98 telephone-event a=rtpmap:97 AMR-WB
m=video 4012 RTP/AVP 99 a=rtpmap:98 telephone-event
a=rtpmap:99 H.261 m=video 4012 RTP/AVP 99
179 a=rtpmap:99 H.261
Media Negotiation(2/2)
P-CSCF S-CSCF I-CSCF S-CSCF P-CSCF Theresa
Tobias
PRACK
PRACK
PRACK
PRACK
v=0 PRACK PRACK
o=- 1357924 1357925 IN IP6 5555::1:2:3:4
s=- v=0
c=IN IP6 5555: :1:2:3:4 o=- 1357924 1357925 IN IP6 5555::1:2:3:4
t=907165275 0 s=-
m=audio 3458 RTP/AVP 97 98 cc=IN
IN IP6 5555: :1:2:3:4
a=rtpmap:97 AMR-WB t=907165275 0
a=rtpmap:98 telephone-event m=audio 3458 RTP/AVP 97 98
m=video 3400 RTP/AVP 99 a=rtpmap:97 AMR-WB
a=rtpmap:99 H.261 a=rtpmap:98 telephone-event
m=video 3400 RTP/AVP 99
a=rtpmap:99 H.261
200 OK 200 OK
200 OK
v=0
200 OK o=- 1357924 1357925 IN IP6 5555::1:2:3:4
s=-
v=0 c=IN IP6 5555::1:2:3:4
o=- 1357924 1357925 IN IP6 5555::1:2:3:4
o t 907165275 0
t=907165275
s=- m=audio 4011 RTP/AVP 97 98
c=IN IP6 5555::1:2:3:4 a=rtpmap: 97 AMR-WB
t=907165275 0 a=rtpmap:98 telephone-event
m=audio 4011 RTP/AVP 97 98 m=video 4012 RTP/AVP 99
a=rtpmap: 97 AMR-WB a=rtpmap:99 H.261
a=rtpmap:98 telephone-event
m video 4012 RTP/AVP 99
m=video
a=rtpmap:99 H.261
180
Resource Reservation(1/3)
181
Tobias Theresa
INVITE
Require: see-agree,
precondition
Are preconditions mandatorily
supported?
420 Bad Extension
SIP/2.0 420 Bad

Extension
Unsupported:
preconditions
182
Theresa
Tobias
bi
UPDATE
INVITE
PRACK
m=audio 3458 RTP/AVP 0 96 97 98 m=audio 3458 RTP/AVP 97 98
a=rtpmap:0 PCMU m=audio 3458 RTP/AVP 97 98 a=rtpmap:97 AMR-WB
a=rtpmap:96 G726-32/8000 a=rtpmap:97 AMR-WB a=rtpmap:98 telephone-event
a=rtpmap:97 AMR-WB a=rtpmap:98 telephone-event a=curr:qos local sendrecv
a=rtpmap:98 telephone-event a=curr:qos local none a=curr:qos remote none
a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv
a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv
a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv
a=des:qos none remote sendrecv
--> 200 Ok
--> 200 Ok
m=audio
d 4011 RTP/AVP/ 97 98
183 Session Progress m=audio 4011 RTP/AVP 97 98 a=rtpmap:97 AMR-WB
a=rtpmap:97 AMR-WB a=rtpmap:98 telephone-event
a=rtpmap:98 telephone-event a=curr:qos local sendrecv
m=audio 4011 RTP/AVP 96 97 98
a=curr:qos local none a=curr:qos remote sendrecv
a=rtpmap:96 G726-32/8000
a=curr:qos remote none a=des:qos mandatory local sendrecv
a=rtpmap: 97 AMR-WB
a=des:qos mandatory local sendrecv a=des:qos mandatory remote sendrecv
a=rtpmap:98
a rtpmap:98 telephone-event
telephone event
a=curr:qos local none a=des:qos mandatory remote sendrecv
a=curr:qos remote none
a=des:qos mandatory local sendrecv Let us assume that Theresa's resource
a=des:qos mandatory remote sendrecv reservation takes longer than Tobias's
a=conf:qos remote sendrecv
m=audio 4011 RTP/AVP 97 98

a=rtpmap:97 AMR-WB
a=curr:qos local none
183 a=curr:qos remote sendrecv
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
Controlling the Media(1/2)
P-CSCF P-CSCF Theresa
Tobias
INVITE
……..
INVITE sip: [5555::5:6:7:8] :1006 SIP/2.0 INVITE

INVITE sip: [5555::5:6:7:8]
[ ] :1006 SIP/2.0
/
INVITE sip: [5555::5:6:7:8] :1006 SIP/2.0

P-Media-Authorization: example-auth-token2
Establishing the media

PDP context
…….. SIP/2.0 183 Session in Progress


P-Media-Authorization: example-auth-tokenl
184
Controlling the Media(2/2)
P-CSCF
P-CSCF
P CSCF
h
Theresa
Tobias
PRACK
……..
PRACK
v 0
v=0
o=- 1357924 1357924 IN IP6 5555::1:2:3:4
s=-
c = IN IP6 5555: :1:2:3:4
t=907165275 0
a=group:SRF 1 This means that the P-
m=audio 3458 RTP/AVP 97 98 CSCF instructs
a=mid:
a mid: 1 Theresa'ss
Theresa
a=rtpmap:97 AMR-WB UE to group the two
a=rtpmap:98 telephone-event media streams together
m=video 3400 RTP/AVP 99 into one PDP context
a=mid: 1
a=rtpmap:99 H.261
200 OK
200 OK ……..
v=0
Tobias's UE will o=- 1357924 1357925 IN IP6 5555::5:6:7:8
have to reserve s=-
separate media PDP c=IN IP6 5555: :5:6:7:8
contexts for each of t=907165275 0
th two
the t a=group:SRF 1
media streams a=group:SRF 2
m=audio 4011 RTP/AVP 97 98
a=mid: 1
a=rtpmap: 97 AMR-WB
a=mid: 2
a=rtpmap:99 H.261
185
Charging--Related Information for Sessions
Charging
Tobias
bi P-CSCF S-CSCF I-CSCF S-CSCF P-CSCF
Theresa
INVITE
INVITE
INVITE
INVITE
INVITE INVITE
P-Charging-Vector: icid-value=
INVITE sip:theresa@home2.hu SIP/2.0 INVITE sip:theresa@home2.hu SIP/2.0
"AyretyU0dm+6O2lrT5tAFrbHLso=0235510 INVITE sip:theresa@home2.hu SIP/2.0
25" P-Charging-Vector: icid-value=
"AyretyU0dm+602lrT5tAFrbHLso=023551025"
;orig-ioi=home1.fr "AyretyU0dm+602lrT5tAFrbHLso=023551025
"

183 Session
i Progress
183 Session Progress 183 Session Progress SIP/2.0183 Session in Progress
SIP/2.0183 Session in Progress
SIP/2.0 183 Session in Progress P-Charging-Vector: icid-value=
P-Charging-Vector: icid-value= "AyretyU0dm+602lrT5tAFrbHLso=023551025"
SIP/2.0183 Session in Progress SIP/2.0183 Session in Progress
"AyretyU0dm+602lrT5tAFrbHLso=023551025
"
"AyretyU0dm+602lrT5tAFrbHLso=023551025"
UPDATE ;;term-ioi=home2.hu
UPDATE
UPDATE
UPDATE
UPDATE sip: [5555: :5:6:7:8]:1006 SIP/2.0 UPDATE sip: [5555::5:6:7:8]:1006
UPDATE UPDATE
P-Charging-Vector: icid-value= SIP/2.0
UPDATE sip: [5555::5:6:7:8]:1006
"AyretyU0dm+602lrT5tAFrbHLso=023551024" P-Charging-Vector: icid-
SIP/2.0
;ggsn=[5555::4b4:3c3:2d2:1e1]; value=""AAyretyU0dm+6O2lrT5tAFrbH
P-Charging-Vector: icid-
;pdp-sig=no; gcid=723084371 Lso=023551024"
value=""AAyretyU0dm+6O2lrT5tAFrbH 200 OK
;auth-token=example-auth-token1 ;orig-ioi=home1.fr
Lso=023551024"
;flow-id=l ;term-ioi=home2 hu
;term-ioi=home2.hu
;ggsn=[5555::4b4:3c3:2d2:lei]
200 OK
200 OK
;pdp-sig=no; gcid=723084372 200 OK
;auth-token=example-auth-token1 SIP/2.0 200 OK
;flow-id=2 SIP/2.0 200 OK P-Charging-Vector: icid-value=
P-Charging-Vector: icid-value= "AyretyU0dm+602IrT5tAFrbHLso=02355
200 OK "AyretyU0dm+602IrT5tAFrbHLso=0235510 1024"
200 OK 24"; ;ggsn=[5555::802:53:58:6]
;orig-ioi=home1.fr ;pdp-sig=no
SIP/2.0 200 OK ;term-ioi=home2.hu
;term ioi home2.hu ;gcid=306908949
;auth-token=example-auth-token2
"AyretyU0dm+602IrT5tAFrbHLso=0235510
;flow-id=2
24";
186
User--Initiated Session Release
User
187
Network--initiated Session
Network
y For example
example, Theresa’s
Theresa s P-CSCF
P CSCF would need to release
an ongoing session when it realizes that Theresa’s UE
has lost radio coverage and is no longer connected to
the access network.
y There may
ma be occasions when
hen Tobias’s S-CSCF
S CSCF needs
to be shut down or Tobias may be using a pre-paid card
and runs out of money.
money
188
3GPP Specifications (1/2)
y 3GPP All IP Network
y TS 23.002 “Network architecture”
y TS 23.221 “Architectural requirements”
y 3GPP IP Multimedia Subsystem
y TS 23.228 V7.0.0 (2005-06)
y IP Multimedia Subsystem ((IMS)
IMS) Stage 2
(Release 7)
y TS 23.228
23 228 “IP multimedia
lti di subsystem
b t (IMS)”
y TS 23.218 “IP multimedia (IM) call model”
y TS 24.228 “Signaling
Signaling flows based on SIP & SDP
SDP”
y TS 24.229 “Call control based on SIP and SDP”
3GPP Specifications (2/2)
y QoS related specs (P (P--CSCF)
y TS 23.107 “QoS concept and architecture”
y TS 23.207 “End-to-End QoS concept & architecture”
y TS 29.208 “End-to-End QoS signaling flows”
y Security related specs (P (P--CSCF)
y TS 33.102
33 102 “Security
Security architecture
architecture”
y TS 33.203 “Access security for IP-based services”
y TS 33.210 “IP network layery security”y
y Cx Interface specs (S- (S-CSCF, I- I-CSCF)
y TS 29.228 “IP Multimedia (IM) Subsystem Cx Interface;
Si li flows
Signaling fl andd message contents”
t t”
y TS 29.229 “Cx Interface based on the Diameter protocol;
Protocol details”
C
Conclusions
l i
y This talk brief presents IMS signaling protocols
including SIP, SDP and related SIP extensions.
y Then an IMS reference architecture is introduced.
Then, introduced In
the architecture, IMS functions and reference points
are discussed.
discussed
y Before going through IMS signaling, the IMS concept
is presented.
presented
y Finally, we utilize several examples to discuss IMS
registration and session setup procedures.
procedures
y IMS security and charging issues can be elaborated in
more detail for further study.
study
191
Q&A
Q
Th k ffor your attention.
Thanks tt ti

Introduction To SIP VoIP and IMS

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Introduction To SIP VoIP and IMS

Încărcat de

Drepturi de autor:

Formate disponibile

VoIP與IMS

Table 1. Example of payload types of audio encoding

Payload Type Name Media Type Clock Rate (Hz) Channel

Table 2. Example of payload types of video encoding

Payload Type Name Media Type Clock Rate (Hz)

y Through Proxy Server

(1) INVITE Bob@NotHere.org

18 (9) RTP Media Stream

y Through Redirect Server Location Server

(4) 302 Moved temprarily

(6) INVITE Bob@BobHost

y Session Description Protocol

y SIP uses SDP in an offer/answer mode.

y 200 OK <-> ACK

y Unsupported should also be returned with a port number of

y A large number of extensions to SIP have been

(2) 180 Ringing

RFC3313 P-Media-Authentication √ P-Called-Party-Id √

RFC3329 Security-Client √ P-Visited-Network-ID √

Security-Server √ RFC3515 Refer-To √

y Support of roaming (between IMS and CS CN)

MRFP MRFC P-CSCF

MRFP MRFC P-CSCF

y When the S-CSCF or I-CSCF receives an initial SIP request

y An AS may initiate a request

y User data-handling procedure

Gm UE, P-CSCF Used to exchange messages between UE and CSCFs SIP

Allows operators to control QoS in a user plane and

Used to directly forward SIP requests which are

Used to exchange messages between S-CSCF and

Mn MGCF, IM-MGW Allows control of user-plane resources H.248

Used to exchange messages between MRFC and

Name IMS entities Description Protocol

P-CSCF I-CSCF HSS S-CSCF

13. 401 Unauthorized

P-CSCF I-CSCF HSS S-CSCF

P-CSCF I-CSCF S-CSCF

(1) SUBSCRIBE SUBSCRIBE

<registration aor="tel:+44-123-456-789" id="a2" state="active">

Tobias’s UE P-CSCF I-CSCF S-CSCF

Tobias’s UE P-CSCF S-CSCF

y Originating P-CSCF includes the P-Asserted-Identity header field

INVITE sip: theresa@home2.hu SIP/2.0

SIP/2.0 183 Session in Progress SIP/2.0 183 Session in Progress

183 Session in Progress

INVITE sip: theresa@home2.hu SIP/2.0

Filter criteria Example

INVITE sip: [5555::5:6:7:8] :1006;comp=SigComp SIP/2.0

183 Session Progress

SIP/2.0 183 Session in Progress

183 Session Progress

420 Bad Extension

SIP/2.0 420 Bad

m=audio 4011 RTP/AVP 97 98

INVITE sip: [5555::5:6:7:8] :1006 SIP/2.0 INVITE

INVITE sip: [5555::5:6:7:8] :1006 SIP/2.0

Establishing the media

183 Session Progress

…….. SIP/2.0 183 Session in Progress

SIP/2.0 183 Session in Progress

183 Session Progress

S-ar putea să vă placă și