Welcome to the training CN61120
VoLTE System Siganaling
Dalton Quinalha
Cordoba, March 18th to 22nd, 2019 - 09h00~~16h00
1
Contents:
0. VoLTE Network Architecture (VoLTE Network Architecture Review)
1. VoLTE Subscriber EPS Attach and IMS bearer setup
2. VoLTE Subscriber Registration
3. Dedicated bearer setup and QoS mapping Procedures
4. VoLTE Call Setup Procedures
5. MMTel Service Handling
6. VoLTE session transfer
7. VoLTE Emergency Call
2
Course Programme
Afternoon
Day 1
•
•
Course Introduction
VoLTE Network Architecture
(Review)
•
•
VoLTE EPS attach and IMS bearer setup
VoLTE Subscriber Registration
Day 2
•
VoLTE Subscriber Registration
•
VoLTE Subscriber Registration
Day 3
•
Dedicated Bearer setup and QoS
•
VoLTE Call Setup procedures
Day 4
•
VoLTE Call Setup procedures
•
•
VoLTE Call Setup procedures
MMTEL Service Handling
Day 5
•
VoLTE Session Transfer
•
•
VoLTE Emergency Calls
Course Review and Conclusions
3
Lunch Break
Morning
Please could you possibly introduce yourself ?
•
•Name
• Working Area
• Experience
• Expectation
4
•
General Course Info (Classroom Session)
Course day duration
(e.g. : 09h00  16h00…max. 16h30)
•
Lunch break schedule
(e.g. : 12h30)
•
Number of additional breaks during the day
(e.g. : 1 in the morning and 1 in the afternoon
shift)
•
Special needs for the last day
(e.g. : early flight / train)
5
Coffee!!!
6
06/08/2023
A bit of HISTORY…
7
06/08/2023
In Telecommunications History, voice service has always been the main Focus !
8
History
voice
9
In Mobile Telecommunications History, voice service has always been the main Focus !
10
voice
11
06/08/2023
“This changes with the introduction of LTE,
Where Data is the main Focus.
Voice is regarded as just Another Application,
But with specific requirements : Qos, GBR and
Interoperability to Legacy 2/3G networks…”
DATA
12
“Voice Over LTE or VoLTE…
…Uses IMS (IP Multimedia System) as Call Control Layer.
IMS uses SIP as main Call Control Protocol and SDP for media.
13
Today’s Voice Services are offered by 2/3 G Circuit Switching Core
Where the main Network Element executing voice services is the MSS,
using for that, a set of different Signaling protocols…
14
One day in the future, the VoLTE architecture will replace
the current 2/3G CS core…
…at this scenario, TAS will be the main NE executing voice services and
SIP will be the main signaling protocol.
But as this replacement will not happen from night to day for most of
Operators, Interoperability between 2/3G and VoLTE is necessary.
From another point of view, the 2/3G network has undergone a huge
evolutionary path and IMS appeared somewhere in this track…
15
A bit of History: the mobile communication evolutionary path:
16
Capabilities
Mobile Communication Evolution
Time
17
Capabilities
Mobile Communication Evolution
Rel
6
Rel
7
Rel
8
4G LTE
E
Rel
3G
NodeB
Rel 5
S/P
3G
GW
IMS
Rel 4
HSUPA
3G
MME
extens
Networ
HSDPA
99 3G
k
ions HSS –
IU-CS
Core
Rel 3G
LTE
Sharin
over IP
Networ
Rel 98
g
Multim
IBCF CS FB
IUFLEX
k
97 Higher edia Modific CAMEL IMS PCRF IMS
Service
extens PCEF extens
Ph 4
ation
Rel Higher bit
s New
ions IP-SM- ions:
rates
IP at
GSM 96 bit
RAN
Preco
IMS
WLAN GW
EDGE
User
WCDM
rates
Ph 2
nditio
Voice
CAMEL
Plane
Higher GPRS
A
GSM
over
ns,Em
Ph2
and
RNC,
BS = 9.6 bit
CAMEL
IMS
ergen
Control
Kbit’/s rates
Basic
NodeB
IMS
cy,SR
Plane
Service SS=ISD 14.4
CAMEL
ALG
ASCI
VCC,L
N
=
HSCSD
Ph3
Speech
18
TrGW
awfull
Interc
Rel
9
4G LTE
IMS
extens
ions:
MMTE
L
TAS,
SRVC
C for
Emerg
ency
calls
Time
Mobile Communication Evolution
Capabilities
LTE IMS over LTE
IMS Ext
IMS
Rel
6
Rel
7
Rel
8
4G LTE
E
Rel
3G
NodeB
Rel 5
S/P
3G
GW
IMS
Rel 4
HSUPA
3G
MME
extens
Networ
HSDPA
99 3G
k
ions HSS –
IU-CS
Core
Rel 3G
LTE
Sharin
over IP
Networ
Rel 98
g
Multim
IBCF CS FB
IUFLEX
k
97 Higher edia Modific CAMEL IMS PCRF IMS
Service
extens PCEF extens
Ph 4
ation
Rel Higher bit
s New
ions IP-SM- ions:
rates
IP at
GSM 96 bit
RAN
Preco
IMS
WLAN GW
EDGE
User
WCDM
rates
Ph 2
nditio
Voice
CAMEL
Plane
Higher GPRS
A
GSM
over
ns,Em
Ph2
and
RNC,
BS = 9.6 bit
CAMEL
IMS
ergen
Control
Kbit’/s rates
Basic
NodeB
IMS
cy,SR
Plane
Service SS=ISD 14.4
CAMEL
ALG
ASCI
VCC,L
N
=
HSCSD
Ph3
Speech
19
TrGW
awfull
Interc
Rel
9
4G LTE
IMS
extens
ions:
MMTE
L
TAS,
SRVC
C for
Emerg
ency
calls
Time
2009 GSM-A
IR 92 – IP Multimedia Subsystem profile for Voice and SMS
IR 94 – Conversational Video Service
IR 64 – Service Centralization and Continuity Guidelines
IR 65 – IMS Roaming and Interworking Guidelines
IR 88 – LTE Roaming Guidelines
IR 51 – IMS Over Wi Fi
20
2009 GSM-A
IR 92 – IP Multimedia Subsystem profile for Voice and SMS
IR 94 – Conversational Video Service
IR 64 – Service Centralization and Continuity Guidelines
IR 65 – IMS Roaming and Interworking Guidelines
IR 88 – LTE Roaming Guidelines
IR 51 – IMS Over Wi Fi
21
Capabilities
Mobile Communication Evolution
Rel
6
Rel
7
Rel
8
4G LTE
E
Rel
3G
NodeB
Rel 5
S/P
3G
GW
IMS
Rel 4
HSUPA
3G
MME
extens
Networ
HSDPA
99 3G
k
ions HSS –
IU-CS
Core
Rel 3G
LTE
Sharin
over IP
Networ
Rel 98
g
Multim
IBCF CS FB
IUFLEX
k
97 Higher edia Modific CAMEL IMS PCRF IMS
Service
extens PCEF extens
Ph 4
ation
Rel Higher bit
s New
ions IP-SM- ions:
rates
IP at
GSM 96 bit
RAN
Preco
IMS
WLAN GW
EDGE
User
WCDM
rates
Ph 2
nditio
Voice
CAMEL
Plane
Higher GPRS
A
GSM
over
ns,Em
Ph2
and
RNC,
BS = 9.6 bit
CAMEL
IMS
ergen
Control
Kbit’/s rates
Basic
NodeB
IMS
cy,SR
Plane
Service SS=ISD 14.4
CAMEL
ALG
ASCI
VCC,L
N
=
HSCSD
Ph3
Speech
22
TrGW
awfull
Interc
Rel
9
Rel
10
4G LTE
Rel
11
4G LTE
Rel
12
4G LTE
4G LTE
IMS
IMS
IMS
extens
extens
extens
ions:
IMS
ions:
extens ions:
ions: eSRV
MMTE CC
L
TAS,
SRVC
C for
Emerg
ency
calls
….
Time
23
06/08/2023
VoLTE Network Architecture
24
06/08/2023
MGW- IMS
MGCF
CS-IP
BB
BTS
SCP
IM-SSF
BSC
MS
SIM
IMSI
MSISDN
MGW-CS
Mc
(h248)
HLR
LDAP
UE
USIM
IMSI
MSISDN
SGs(SGSAP) CSFB
SV(GTP V2) SRVCC
Hd (propr
diameter)
One
NDS
HSS
IMS
(GTP V1)
BGCF
Mw
IBCF
PCRF
IMS ATC
ALG F
CFX5000
Ix (megaco)
Iq (megaco)
PGW
PDN
Gi (IP)
IMS
AGW
ATGW
Open Border GW
SWu
(IKEv2/Ipsec)
ePDG
xDSL
SWm
( diameter )
AAA
GW
DNS
eNUM
Mw
P-CSCF
WiFi
25
S-CSCF
Mw
S5/S8 ( GTP V2)
SGW
Open TAS
Ma
ISC (SIP)
(SIP)
Mi
I-CSCF
LDAP
HSS
LTE
MME
eN B
UE
USIM
IMSI
MSISDN
PDN
GGSN
SGSN
Mr’ (SIP MSML)
Mp’(h248)
Traffica
MMTEL
MSS
VLR
RNC
MRF
MRFC
SCC-AS
SMS
Billing
Ut (xcap)
XCAP
IP-SM-GW
IN
I2 (SIP)
NB
Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
PSTN
HPLMN
TrG
W
Other IMS
Networks
MGW- IMS
MGCF
CS-IP
BB
BTS
SCP
IM-SSF
BSC
MS
SIM
IMSI
MSISDN
MGW-CS
Mc
(h248)
HLR
LDAP
UE
USIM
IMSI
MSISDN
SGs(SGSAP) CSFB
SV(GTP V2) SRVCC
Hd (propr
diameter)
One
NDS
HSS
IMS
(GTP V1)
BGCF
Mw
IBCF
PCRF
IMS ATC
ALG F
CFX5000/SBC
Ix (megaco)
Iq (megaco)
PGW
PDN
Gi (IP)
IMS
AGW
ATGW
TrG
W
Open Border GW / SBC
SWu
(IKEv2/Ipsec)
ePDG
xDSL
SWm
( diameter )
AAA
GW
DNS
eNUM
Mw
P-CSCF
WiFi
26
S-CSCF
Mw
S5/S8 ( GTP V2)
SGW
Nokia TAS
Ma
ISC (SIP)
(SIP)
Mi
I-CSCF
LDAP
HSS
LTE
MME
eN B
UE
USIM
IMSI
MSISDN
PDN
GGSN
SGSN
Mr’ (SIP MSML)
Mp’(h248)
Traffica
MMTEL
MSS
VLR
RNC
MRF
MRFC
SCC-AS
SMS
Billing
Ut (xcap)
XCAP
IP-SM-GW
IN
I2 (SIP)
NB
Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
PSTN
HPLMN
Other IMS
Networks
MGW- IMS
MGCF
CS-IP
BB
BTS
SCP
IM-SSF
BSC
MS
SIM
IMSI
MSISDN
MGW-CS
Mc
(h248)
HLR
LDAP
UE
USIM
IMSI
MSISDN
SGs(SGSAP) CSFB
SV(GTP V2) SRVCC
WiFi
Hd (propr
diameter)
MME
VoLTE
VoWiFi
27
One
NDS
HSS
IMS
LDAP
HSS
LTE
SGW
SWu
(IKEv2/Ipsec)
(GTP V1)
ePDG
xDSL
PGW
SWm
( diameter )
Nokia TAS
Ma
ISC (SIP)
(SIP)
Mi
S-CSCF
BGCF
Mw
IBCF
Mw
P-CSCF
PCRF
IMS ATC
ALG F
CFX5000/SBC
Ix (megaco)
Iq (megaco)
PDN
Gi (IP)
IMS
AGW
ATGW
TrG
W
Open Border GW / SBC
AAA
GW
DNS
eNUM
Mw
I-CSCF
S5/S8 ( GTP V2)
eN B
UE
USIM
IMSI
MSISDN
PDN
GGSN
SGSN
Mr’ (SIP MSML)
Mp’(h248)
Traffica
MMTEL
I2 (SIP)
RNC
MRF
MRFC
SCC-AS
SMS
Billing
Ut (xcap)
XCAP
IP-SM-GW
IN
MSS
VLR
NB
Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
PSTN
HPLMN
Other IMS
Networks
MGW- IMS
MGCF
CS-IP
BB
BTS
Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
PSTN
HPLMN
SCP
IM-SSF
BSC
MS
SIM
IMSI
MSISDN
MGW-CS
Mc
(h248)
HLR
UE
USIM
IMSI
MSISDN
PDN
GGSN
SGSN
SGs(SGSAP) CSFB
SV(GTP V2) SRVCC
Hd (propr
diameter)
LDAP
One
NDS
HSS
IMS
Nokia TAS
Ma
ISC (SIP)
(SIP)
Mi
S-CSCF
PCRF
S5/S8 ( GTP V2)
(GTP V1)
PGW
PDN
Gi (IP)
WiFi - WAP
28
Mw
CFX5000
IMS ATC
ALG F
Iq (megaco)
IMS
AGW
SWu
(IKEv2/Ipsec)
BGCF
Mw
P-CSCF
SGW
IBCF
Ix (megaco)
ATGW
TrG
W
Open Border GW / SBC
ePDG
xDSL
SWm
( diameter )
AAA
GW
DNS
eNUM
Mw
I-CSCF
LDAP
HSS
LTE
MME
eN B
UE
USIM
IMSI
MSISDN
Traffica
MMTEL
I2 (SIP)
RNC
Mr’ (SIP MSML)
Mp’(h248)
MRF
MRFC
SCC-AS
SMS
MSS
VLR
NB
XCAP
IP-SM-GW
IN
Billing
Ut (xcap)
Other IMS
Networks
MGW- IMS
MGCF
CS-IP
BB
BTS
Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
PSTN
HPLMN
SCP
IM-SSF
BSC
MS
SIM
IMSI
MSISDN
MGW-CS
Mc
(h248)
HLR
UE
USIM
IMSI
MSISDN
PDN
GGSN
SGSN
SGs(SGSAP) CSFB
SV(GTP V2) SRVCC
Hd (propr
diameter)
LDAP
One
NDS
HSS
IMS
Nokia TAS
Ma
ISC (SIP)
(SIP)
Mi
S-CSCF
(GTP V1)
PGW
PCRF
PDN
Gi (IP)
CFX5000
IMS ATC
ALG F
SWu
(IKEv2/Ipsec)
IBCF
Ix I-SBC
(megaco)
Iq (megaco)
A-SBC
IMS
AGW
WiFi - WAP
29
Mw
Other IMS
Networks
P-CSCF
SGW
BGCF
Mw
S5/S8 ( GTP V2)
ATGW
TrG
W
Open Border GW / SBC
ePDG
xDSL
SWm
( diameter )
AAA
GW
DNS
eNUM
Mw
I-CSCF
LDAP
HSS
LTE
MME
eN B
UE
USIM
IMSI
MSISDN
Traffica
MMTEL
I2 (SIP)
RNC
Mr’ (SIP MSML)
Mp’(h248)
MRF
MRFC
SCC-AS
SMS
MSS
VLR
NB
XCAP
IP-SM-GW
IN
Billing
Ut (xcap)
SCP
IM-SSF
Billing
Ut (xcap)
XCAP
IP-SM-GW
MRF
MRFC
SCC-AS
Traffica
MMTEL
One
NDS
HSS
IMS
HSS
LTE
MME
UE
USIM
IMSI
MSISDN
SGW
(GTP V1)
BGCF
Mw
IBCF
PCRF
IMS ATC
ALG F
CFX5000/SBC
Ix (megaco)
Iq (megaco)
PGW
PDN
Gi (IP)
IMS
AGW
ATGW
TrG
W
Open Border GW / SBC
SWu
(IKEv2/Ipsec)
ePDG
xDSL
SWm
( diameter )
AAA
GW
DNS
eNUM
Mw
P-CSCF
WiFi
30
S-CSCF
Mw
S5/S8 ( GTP V2)
eN B
Nokia TAS
Ma
ISC (SIP)
(SIP)
Mi
I-CSCF
LDAP
Mr’ (SIP MSML)
Mp’(h248)
Other IMS
Networks
Billing
Ut (xcap)
Mr’ (SIP MSML)
Mp’(h248)
Traffica
Nokia TAS
Ma
ISC (SIP)
(SIP)
One
NDS
DNS
eNUM
HSS
IMS
LDAP
HSS
LTE
MME
UE
USIM
IMSI
MSISDN
Iq (megaco)
S5/S8 ( GTP V2)
eN B
SGW
(GTP V1)
PGW
Ix (megaco)
PDN
Gi (IP)
WiFi
31
CFX5000/SBC
PCRF
Open Border GW / SBC
SWu
(IKEv2/Ipsec)
ePDG
xDSL
SWm
( diameter )
AAA
GW
Other IMS
Networks
Billing
Ut (xcap)
Mr’ (SIP MSML)
Mp’(h248)
Traffica
Nokia TAS
Ma
ISC (SIP)
(SIP)
One
NDS
DNS
eNUM
HSS
IMS
LDAP
HSS
LTE
MME
UE
USIM
IMSI
MSISDN
Iq (megaco)
S5/S8 ( GTP V2)
eN B
SGW
(GTP V1)
CFX5000/SBC
PCRF
PGW
Ix (megaco)
PDN
Gi (IP)
Open Border GW / SBC
32
Other IMS
Networks
SIP
33
SIP Session Initiation Protocol
•
Text based application layer protocol primarily for media stream signalling
-
It’s purpose is the establishment, modification, and termination of multimedia
sessions e.g. phone calls, videoconferences, online game sessions, etc.
-
Extensions allow instant messaging, presence status and event publication
•
IETF defined standard: RFC 3261
•
3GPP has adopted SIP as the main Control Protocol for IMS – TS 23.228 and 24.229
•
Text Protocol – http like. The headers are flexible. ‘’write what ever you want’’
•
- Binary protocols (like SS7) are predefined, prearranged and requires signaling links
and routing data bases. Text protocols are flexible and have all definitions at own
body.
•
Sip over TCP/UPD/SCTP dest. Port 5060
•
Request/Response client/server protocol
•
-clients send Requests (methods) to Servers. Servers sends Responses (Status
Codes).
34
•
Nodes acts as both: clients and servers
SIP Network Components (summary)
•
UA – User agent:
-
SIP enabled terminal (end device), which is one of the endpoints of a session
•
It may send AND receive session initiation requests
•
Acts on behalf of it’s user, hence user agent
-
35
Two parts:
•
UAC – User Agent Client: initiates requests
•
UAS – User Agent Server: generates responses
•
Registrar server:
-
Accepts REGISTER requests
-
Usually performs authentication of users and downloads user profile
-
Builds a temporary binding between the AOR (IMPU) present in the REGISTER’s „To” header
and the device URI present in the „Contact” header
•
Proxy Server:
-
36
Helps Routing a Request from a Client to a Server. The Proxy itself is a combination of Client
and a server just routing messages, not modifying them. It has no media capabilities.
-
Statefull proxy: maintains dialog state. Keep on ‘the loop’’.
-
Stateless proxy: only forwards the messages
•
37
Back to Back User Agent:
-
SIP Device that works as 2 coupled User Agents in opposite directions. It receives requests (A
side requests and may reformulate them (creating new ‘B’ side requests) thus potentially
creating new dialogs
-
It answers these requests (A responses)
-
It also handles the responses for B requests)
-
Mantains dialog states
Addressing
•
Address of Record (AOR):
-
URI which Identifies a participant in the session
-
E.g. sip:user@domain.com, tel:+123456789
-
Usually requires database lookups
-
Appears in „From” and „To” headers and in the start-line
•
38
Device URI:
-
URI which Identifies a (logical) network element
-
E.g. sip:user@unit1.NE2.subdomain.domain.com
-
Usually does not require database lookups
-
Appears in „Contact” header
SIP message structure
•
Start line contains the SIP version and…
-
…the method and target address in requests (Request URI R-URI)
-
…the status in responses
•
Headers contain the information related to the session in text lines
•
e.g. the initiator, and the recipient of the request, call identifier etc.
Message body (payload) can carry any text based information
-
e.g. SDP packet, instant message etc.
-
Starts with CRLF
Start-Line
Header1: value1
Header1: value2
Header3: value3
Header4: value4
Message body
39
•
Request:
-
SIP message which is sent by a client towards a server requesting the invocation of
a SIP service method
-
e.g. INVITE message
•
•
40
Method:
-
A SIP functionality which is performed at the server invoked by a request message
-
e.g. invitation of a peer to a call (invoked by the INVITE request)
Almost interchangeable terms
SIP Requests
REGISTER
SUBSCRIBE
INVITE
PUBLISH
ACK
NOTIFY
MESSAGE
BYE
CANCEL
PRACK
UPDATE
OPTIONS
41
REFER
INFO
•
REGISTER:
Registers a user’s AOR and device URI to the SIP system with a given
expiration time
•
„From” header: AOR of the UA performing the registration
•
„To” header: AOR of the UA to be registered
•
•
42
3rd party registration: if „From” and „To” URI don’t equal (e.g. IMS)
„Expires” header
•
Indicates the duration of the registration requested
•
If zero, de-registration is requested, the user will be removed from the sytsem
•
The AOR will be bound to the device URI for the duration of the registration,
thus if changing the „Contact” URI (due to e.g. WLAN handover) the user has to
be re-registered by sending another REGISTER message
•
If there’s no „Contact” header present
•
Return all current registrations in response
•
43
INVITE:
•
Invites a participant into a media session
•
Body usually carries an SDP message describing the media session
•
A media session is considered established when the INVITE, 200 OK, and ACK messages
have been exchanged between the participants
•
RURI and „To” URI is the called party’s AOR, „From” URI is the caller’s AOR, „Contact” address
is the device URI of the caller
•
ACK:
-
Acknowledges final responses for INVITE requests
-
It can also carry media description, but only if the initial INVITE did not
•
44
It must not modify an already established session (re-INVITE has to be used for that)
-
The „CSeq” value in an ACK is never incremented, but the method is changed to
ACK so that the UA can match the particular ACK with the corresponding INVITE
(see CSeq header and examples!)
-
ACK for 2xx responses is end-to-end, for all other responses it is hop-by-hop (i.e.
new ACK transaction for each hop)
•
45
BYE:
-
Terminates active sessions
-
Only UAs participating in a session may send it, proxies must not (thus end-to-end)
-
Pending INVITEs should be terminated with CANCEL, not with BYE
•
CANCEL:
-
Cancels pending requests before a final response arrives for a request (otherwise
BYE is used)
-
Forking proxies are using CANCEL to end parallel branch dialogs
-
CSeq is NOT incremented like in case of ACK (see CSeq header and examples!)
-
Hop-by-hop request
• It is responded to with 200 OK
• The INVITE is replied to with 487 Request Terminated
46
•
OPTIONS:
-
Used for querying UAs’ or servers’ capabilities (e.g. supported extensions,
language, etc.) and momentary availability
-
It is responded to with 200 OK in successful case with the capabilities of the „B”
side listed
• Supported header may list the supported SIP extensions
• Allow header may list the allowed methods
• Accept header may list the accepted payload types
• SDP payload may describe the broadest set of supported media types
• It can be used for reachability checking i.e. ping
-
47
Proxies must not generate OPTIONS request
•
48
OPTIONS and CANCEL basics:
•
PRACK:
-
Used for acknowledging reliably transported provisional responses (1xx)
• Reliably transported: received with a proper „RSeq” header
• Any informational response except for „100 Trying”
• Other responses are using ACK for acknowledgment
49
-
Specified in RFC 3262
-
Requires support for extension „100rel”
-
RAck header: used for echoing CSeq and RSeq of the acknowledged response
(see RAck headers and examples!)
-
Matches the offer/answer model of SDP
•
UPDATE:
-
Allows a client to update parameters of a session before the completion of an initial
INVITE method
• Set of media streams and their codecs
• After the session is established, re-INVITE should be used for the same purpose
-
50
Used for e.g. codec negotiation, QoS parameter updates
PRACK, UPDATE basics:
51
•
SUBSCRIBE:
-
Used by a UA to initiate a subscription to another UA’s presence and activity (or
„arbitrary”) status
-
Creates a dialog
• Can be terminated using a final NOTIFY (see NOTIFY method)
-
„Expires” header defines the duration of the subscription
• A subscription can be refreshed by another SUBSCRIBE
• „Expires: 0” means the termination of a subscription
52
-
„Event” header describes which actions the UA wants to subscribe to
-
„Allow-Events” header may show the allowed events
•
PUBLISH:
-
53
Used by a UA to publish an event towards an ESC which then distributes it to the interested
parties
•
NOTIFY:
-
Used by a UA to notify it’s target about the occurence of a particular event
• Usually within a subscription dialog, but also in case of call transfer (see REFER method)
-
„Event” and „Subscription-State” headers highlight the basics of the occured event
-
Has a specific XML based payload describing the actual change and the event of a
subscription
• sipfrag in case of call reference
54
-
Solicited ~: sent within a dialog (i.e.: subscription)
-
Unsolicited ~: sent outside a dialog (i.e.: MWI)
•
MESSAGE:
-
Allows a client to send a direct message to a recipient
-
One shot request: does not create a dialog
-
May be sent within a dialog (in-dialog messaging)
-
Payload (message body) can be a large number of MIME types
• E.g. „text/plain” or „application/vnd.3gpp.sms”
-
Success scenarios:
• 200 OK is received
• 202 Accepted is received meaning that the NE recieved the message but is not yet able to
deliver it to it’s target
55
•
REFER:
-
Used by a UA to instruct another UA participating in the session to contact a third
(or Xth) URI or URL
• E.g. Call transfer or even PBX functionality
• Arbitrary URL/URI scheme can be used as a target e.g. HTTP resources can also be used
56
-
„Refer-To” header indicates the target of the reference
-
The optional „Referred-By” header shows information about the referrer
-
Requires immediate response
-
Implicit subscription: equals with a subscription for „Refer” event (see SUBSCRIBE
method)
•
INFO:
-
Method for in-dialog general information transmission
• E.g. In case of ISUP tunnelling, those messages that don’t fit the SIP initiatives (e.g. CHG,
MPM, CNF, etc.) or DTMF relay
-
57
End-to-end transmission
•
Response:
-
SIP message which is sent by a server towards a client responding to a previously received
request
-
e.g. 200 message
•
•
58
Status code:
-
A number which represents the state of the method that the response is sent about
-
e.g. 200 OK for an INVITE: the called party picks up the call
Strongly coupled terms
•
59
Provisional response:
-
Response which does not complete/terminate the transaction
-
Practically a synonym for Information class (1xx) responses
-
E.g.: 183 Session Progress
-
They can be acknowledged using the PRACK method if they are reliably
transmitted (if the „100rel” extension is supported by the peers participating in the
dialog)
RESPONSES
•
Status codes:
-
Informational:
•
-
2xx
200,202
Redirection:3xx
•
-
300, 301, 302
Client error: 4xx
•
-
400,401,403,404,405,407,408,480,484,486,487
Server error:
•
-
5xx
500,503,501,513
Global error:
•
60
100,180,181,183
Success:
•
1xx
600,606
6xx
•
100 Trying:
-
Sent in case the processing of an INVITE request lasts too long in order to avoid
retransmission of the INVITE
• Never sent reliably  never PRACK’d
• Hop-by-hop response
• Must not contain a message body
• Typically does not contain a „To”-tag (see „To” header)
•
61
180 Ringing:
-
Indicates that the INVITE has reached it’s target and it is alerting
-
May contain media description e.g. for special RBT
•
181 Call Is Being Forwarded:
-
•
Indicates that the call is being handed off to another end-point
183 Session/Call Progress:
-
Used for transmitting information regarding the progress of the session
-
If „100rel” extension is supported it perfectly fits the offer/answer model of SDP
• Can be used for codec negotiation
-
Can be used generally for media stream establishment prior the session
establishment
• E.g. announcements
62
•
200 OK:
-
Used for indicating the successful completion of a request
• For INVITE, OPTIONS, REGISTER it may contain a message body
• For other requests it must not contain a message body
•
202 Accepted:
-
Indicates that the request was received and accepted (e.g. it is both syntactically
and semantically reasonable), however it does not indicate any information about
it’s processing
• Typically for SUBSCRIBE, MESSAGE and REFER
63
•
300 Multiple Choices:
-
Indicates that the location service returned multiple possible locations of the sip(s)
URI in the RURI
• Contains several „Contact” headers in significant order
•
301 Moved Permanently:
-
•
~, „Contact” header contains the new permanent URI of the called party
302 Moved Temporarily:
-
~, „Contact” header contains the momentarily valid URI of the called party
• „Expires” header may provide the duration of the validity of the URI
64
•
400 Bad Request:
-
Indicates that the server does not understand the request
• E.g. missing mandatory headers or multiple INVITEs with same Call-ID
•
401 Unauthorized:
-
Indicates that authentication is required before accessing the requested method
• Generally UAs or registrar servers (proxy servers use 407)
• The authenticated request should have the same Call-ID as the initial
65
•
403 Forbidden:
-
Indicates that the requested service is not available for the UA
• E.g. call attempt when unregistered
•
404 Not Found:
-
•
Indicates that the user in the RURI can not be located by the server
405 Method Not Allowed:
-
Indicates that the requested method is not allowed at the UA
• E.g. REGISTER to a UA
• „Allow” header must be present containing the allowed methods
66
•
407 Proxy Authentication Required:
-
Indicates that the UA (and NOT a server) sending the request to a proxy server has
to be authenticated
• „Proxy-Authenticate” header contains the required authentication type
• Request then has to be resubmitted with „Proxy-Authorization” header containing the
authentication credentials
•
408 Request Timeout:
-
67
Indicates that an INVITE containing an „Expires” header has timed out
•
480 Temporarily Unavailable:
-
Indicates that the target UA can not be accessed momentarily
• E.g.: The called party is found, but is not logged in
• „Retry-After” header should contain when the request might be served
•
484 Address Incomplete:
-
Indicates that the address in the RURI is not complete
• Typically in case of overlap dialing at PSTN gateways
•
486 Busy Here:
-
Indicates that the call can not be accepted at the target location
• Equivalent to the busy signal
68
•
487 Request Terminated:
-
Sent by a (B2B)UA which received a CANCEL message to a pending INVITE
• The CANCEL is acknowledged with a 200 OK, and the pending INVITE is responded with
487
69
•
500 Server Internal Error:
-
General server error response which indicates that the request can not be served
(usually only momentarily) due to some unexpected condition
• E.g. a server unit melts down during processing the request
• „Retry-After” header may indicate the interval of the outage
•
503 Service Unavailable:
-
General server error response which indicates that the request can not be served
(usually only momentarily) due to some NE level error
• Typically in case of overload or maintenance (which causes overload) of a NE
• „Retry-After” header may indicate the interval of the outage
70
•
501 Not Implemented:
-
Indicates that the requested method is unknown to the server and will never be
able to serve it
• E.g. Presence functionality in case of a strict VoIP network
•
513 Message Too Large:
-
71
The length of the message exceeds the server capabilities
•
600 Busy Everywhere:
-
Indicates that the request is not going to be served at any possible resource bound
to the RURI
• Global version of 486, only servers with overall knowledge of the network should be
sending it
•
606 Not Acceptable:
-
Indicates that the target was reached, but no end point will be able to accept the
session due to some aspect of the media description
• E.g. attempt to join a voice conference with video conference media requirement
• Primitive/basic media negotiation method
• „Warning” header may be used to clarify the reason
72
HEADERS
•
header = "header-name" HCOLON header-value *(COMMA headervalue)
-
Field names are always case-insensitive
•
E.g. the following ones are equivalent
Contact: <sip:alice@atlanta.com>;expires=3600
CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600
-
73
In most cases field values, parameter names, and parameter values are
case-insensitive too
Many headers have a compact form of one character
•
From:
•
Shows the originator of the session establishment attempt
•
Must contain a URI and a „tag” field
•
74
-
The URI is enclosed in < > brackets
-
The URI may contain a display name which is exluded from the < > brackets
In a response it is echoed, i.e. even though the response is generated by the
server, the header’s value will be the CALLER’s URI
•
To:
Shows the target of the session establishment attempt
•
Must contain a URI
-
75
The URI must be composed like in „From” header
•
From the first response to a request (even in case of provisionals except for 100
Trying) it must contain a tag field, which indicates that the dialog is established
•
In a response it is echoed, i.e. even though the response’s target is the client, the
header’s value will be the CALLEE’s URI
•
The URI in the To header is NOT used for routing, the RURI is used instead
•
Via:
•
Used for routing and matching SIP messages to the transaction it belongs to
•
Mandatory header that must contain
-
the protocol version (always SIP/2.0)
-
the transport that was used for transmitting the message (/UDP)
-
an address (10.85.18.113:5060)
-
a „branch” field beginning always with the so-called magic cookie „z9hG4bK”
(branch=z9hG4bK5B1gdA.WdC85)
•
76
A SIP message may contain many Via headers
-
Their order is utterly important for routing purposes
-
They record the path of a request and ensure that responses are routed the same way as the
request was that they belong to
•
77
Via: In requests
•
Via:
•
In responses
-
78
A NE element receiving a response checks whether the address in the topmost Via header
matches it’s own’s
•
If it does not, the NE discards the message
•
If it does (i.e. the message has reached the proper NE), the NE removes the topmost Via
header and forwards the response towards the address in the new topmost Via header
•
This allows that responses are routed the same way the corresponding request was
Via: In responses
79
•
Call-ID:
Is a unique ID generated by the UA generating a request identifying the call
throughout the entire session
•
It is echoed in responses
•
Each call should have a unique Call-ID
•
However in case of registrations, all registrations from a particular user should
contain the same Call-ID
•
Usually made up of a local-id, the @ symbol, and a host name or IP address
-
80
Local-id should be a cryptographically random string
•
CSeq:
Stands for Command Sequence
•
A counter that increases for each request and contains the method of the request that triggered
the last incrementation
•
It is generated for each request
•
It is echoed in the respons(es) belonging to the request
•
81
-
This way, within a dialog it can identify all messages belonging to the transaction initiated by
a particular request
-
Cseq „space” is generated and maintained by each UA independently
CANCEL and ACK DO NOT increment the CSeq number, they contain a CSeq with the number
of the INVITE they refer to, but the method name is changed
CSeq:
82
•
Contact:
•
Contains the URI of the resource generating the SIP message
•
Usually it resolves directly to the address of the UA
-
83
E.g. networks with firewalls may hide the actual address of the UA
•
In case of registrations, it is the address bound to the URI publicly available for
addressing SIP messages
•
In case of registration the wildcard „Contact: *” may be used together with „Expires:
0” header meaning that all registrations should be cleared
•
Allow:
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, INFO, MESSAGE, SUBSCRIBE,
NOTIFY, REFER, UPDATE
•
•
Shows which methods are allowed at the UA
Supported:
Supported:100rel,precondition,timer
•
•
Shows which extensions of SIP are supported by the UA
Require:
Require:100rel
•
84
Shows which extensions of SIP the UA requires the other party to support
•
85
Reason:
•
In case of CANCEL and BYE it describes the reason of closing the session
•
In case of error responses it describes the reason for the situation represented by
the response’s status code
•
May containg a SIP-specific, partly textual description and/or a Q.850 SS7-specific
cause value
•
Reason header in a „484 Address Incomplete” response:
Reason:X.int ;reasoncode=0x0B17;add-info=01CA.FFFE.0000
Reason:Q.850 ;cause=28
SIP Reason
Part
Value
Meaning
Clear code 0B17 Insufficient digits or selection information have been received (address_incomplete)
01CA si7prb
PRB
c0B17_mapped_from_ext_cause
Situation
FFFE
Add info
0
86
cd_t type constant definition info
The clear code is mapped from an external cause
code
•
WWW-Authenticate:
•
Carries public authentication credentials  it „challenges” the client to authenticate
itself
•
Typically in a „401 Unauthorized” response
In a reformulated request after the 401, „Authorization” header carries the authentication
credentials generated by the client using
-
87
•
the authentication algorithm described in the algorithm field’s value
•
nonce, which is the public key of the authentication algorithm
•
the client’s private key
•
88
Authorization:
•
Carries authentication credentials in requests
•
Typically in a reformulated request generated after the arrival of a „401
Unauthorized” response
•
Record-Route:
Record-Route: <sip:private.in.nephthys.tas.com:5060;lr>
•
89
used to force routing through a proxy for all subsequent requests in a session
between two user agents
-
Normally a present „Contact” header allows the direct transmission of SIP messages
between two UAs, a present Record-Route however overrides this and forces the message
to go through the proxy present in the header
-
All subsequent requests must have a „Route” header containing the address present in the
„Record-Route” header (see examples)
•
Route:
Route: <sip:private.in.nephthys.tas.com:5060;lr>, <sip:private.in.apollon.tas.com:5060;lr>,
<sip:private.in.hercules.tas.com:5060;lr>
•
90
In case a message with Record-Route header(s) was received all subsequent
requests must contain a Route header matching the Record-Route value(s)
• Content-Type:
Content-Type: application/sdp
•
Indicates the type of the payload carried in the
message body
• Content-Length:
Content-Length: 0
91
•
Expires:
Expires: 60
•
Indicates the time interval in which the request or message contents are valid
•
Interval is defined in seconds or in absolute time (SIP date type)
-
•
92
E.g.: Expires: Mon, 8 Nov 2010 16:00:00 GMT+1
Typically in case of REGISTER, SUBSCRIBE and INVITE requests
•
Session-Expires:
Session-Expires: 3600
•
It can define a duration for a session
-
93
It can be extended using an UPDATE or a re-INVITE method
•
94
Transaction:
-
All messages from the first request (sent from the client to the server) up to the final (non-1xx)
response for the request (sent from the server to the client)
-
Also includes ACK for a response if it was a non-2xx response
-
ACK for a 2xx response is a separate transaction
-
„Via” header’s „branch” field’s value in SIP messages identifies the transaction it belongs to in
an unequivocal way (see Via header)
-
“Transaction is a Request-Response(s) sequence of messages for one single Request between
2 directly connected SIP entities’’.
Session:
‘’A Session is a Realtime multimedia exchange between 2 or more users’’
95
•
Dialog:
-
Peer-to-peer SIP relationship between a client and a server that
persists for some time
Established by SIP messages, such as a 2xx or 1xx response to
an INVITE request
Consists of transactions
Each dialog is uniquely identified by it’s initial request’s
-
96
•
„Call-ID” header value AND
•
„tag” field’s value in the „From” header (From-tag) AND
•
„tag” field’s vaule in the „To” header (To-tag) (appears in the first non-100 response!)
Each transaction within a dialog is uniquely identified by it’s
request’s „CSeq” header’s value
Dialog:
97
Routing - Strict Routing
Route is created from Record-Routes
If there is a Route header field present
- Pull the topmost Route header and replace the Request-URI with it
- Route the request according to the new content of the R-URI
- DO NOT modify the new content of the R-URI
98
Routing – Loose Routing
A loose router proxy routes according the topmost Route and does not modify the R-URI (if Route
present)
A loose router proxy can insert additional hops to the Route list: Route-pre-loading entity
Pre-loaded Route headers
Route headers inserted to a request, which are not copied/derived from Record-Route header fields
of an earlier request
99
. Routing – Example (Pre-config’d route)
Alice’s UA is pre-configured with the outbound proxy outbound.nokia.com
So, UA inserts a Route-header with the outbound proxy address
10
0
Routing – Example (Proxy R-R-ing)
A Proxy examines route-header and finds out itself, so it removes the route-header
Outbound.nokia.com decides it wants to stay on the path of subsequent requests for this dialog, so it
includes a Record-Route header in the request
Inserts a Via header on top
10
1
Routing – Example (DNS)
Resolver at the outbound proxy
Resolver queries DNS with NAPRT records for vodafone.com
- Answer might look like:
• ;
order pref flags service
regexp replacement
• IN NAPTR 50 50
"s" "SIPS+D2T" ""
_sips._tcp.vodafone.com.
• IN NAPTR 90 50
"s" "SIP+D2T"
""
_sip._tcp.vodafone.com
• IN NAPTR 100 50
"s" "SIP+D2U"
""
_sip._udp.vodafone.com
10
2
A Name Authority Pointer (NAPTR) is a type of resource record used in the DNS.
„s" flag indicates that resulting domain name points to a SRV pointer.
Routing – Example (DNS)
Choosing TCP, an SRV query for _sip._tcp. vodafone.com is performed
- Answer might look like:
• ;;
Priority Weight Port Target
• IN SRV 0
1
5060 server1.vodafone.com
• IN SRV 0
2
5060 server2.vodafone.com
10
3
Routing – Example (DNS)
So, now we have TCP. We still need an IP address and port
DNS A/AAAA record query is performed. IP address and port is returned
Each one of the SRV records is tried starting from the top until one is successful
10
4
Examples – Registration
10
5
. Basic call
Client
Server
10
6
Server
Client
Examples – Basic Call with 100rel
10
7
User Plane Setup
10
8
10
9
11
0