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

Day 1 • Course Introduction • VoLTE EPS attach and IMS bearer setup
• VoLTE Network Architecture (Review) • VoLTE Subscriber Registration

Day 2 • VoLTE Subscriber Registration • VoLTE Subscriber Registration

Lunch Break
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
 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)
Coffee!!!
• 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

5 (e.g. : early flight / train)
6 04/08/2023
 A bit of HISTORY…

7 04/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 04/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
Rel 9
Rel 8
4G LTE
Rel 7 4G LTE
Rel 6 E
3G NodeB
Rel 5 3G S/P GW
Rel 4 3G HSUPA IMS MME IMS
extensi HSS – extensi
99 3G HSDPA Networ
IU-CS k ons LTE ons:
Rel 3G Core
over IP Sharing CS FB MMTE
Rel 98 Multim
Networ
IUFLE IMS IBCF IMS L
k
97 Higher edia Modific X extensi PCRF extensi TAS,
Services CAME ons PCEF ons: SRVC
Rel Higher bit rates New ation L Ph 4 WLAN IP-SM- Precon C for
GSM 96 bit rates EDGE RAN IP at Voice GW ditions,
CAMEL User Emerg
Ph 2 GPRS Ph2 WCDM
Plane IMS over Emerg ency
GSM Higher CAMEL A
and IMS ency,S calls
BS = 9.6 bit rates RNC, IMS
Control RVCC,
Basic Kbit’/s 14.4 NodeB
Plane ALG Lawful
Service = SS=ISDN HSCSD CAME
Speech ASCI TrGW l Interc
L Ph3
Time
18
 Mobile Communication Evolution
Capabilities LTE IMS over LTE

IMS Ext Rel

Rel 9
IMS
Rel 8
4G LTE
Rel 7 4G LTE
Rel 6 E
3G NodeB
Rel 5 3G S/P GW
Rel 4 3G HSUPA IMS MME IMS
extensi HSS – extensi
99 3G HSDPA Networ
IU-CS k ons LTE ons:
Rel 3G Core
over IP Sharing CS FB MMTE
Rel 98 Multim
Networ
IUFLE IMS IBCF IMS L
k
97 Higher edia Modific X extensi PCRF extensi TAS,
Services CAME ons PCEF ons: SRVC
Rel Higher bit rates New ation L Ph 4 WLAN IP-SM- Precon C for
GSM 96 bit rates EDGE RAN IP at Voice GW ditions,
CAMEL User Emerg
Ph 2 GPRS Ph2 WCDM
Plane IMS over Emerg ency
GSM Higher CAMEL A
and IMS ency,S calls
BS = 9.6 bit rates RNC, IMS
Control RVCC,
Basic Kbit’/s 14.4 NodeB
Plane ALG Lawful
Service = SS=ISDN HSCSD CAME
Speech ASCI TrGW l Interc
L Ph3
Time
19
 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 Rel
Rel
11 12
Rel 10
Rel 9 4G LTE
4G LTE
4G LTE
Rel 8
4G LTE
Rel 7 4G LTE
Rel 6 E
IMS
3G NodeB IMS
Rel 5 3G S/P GW IMS extensi
extensi
Rel 4 3G HSUPA IMS MME IMS extensi
ons:
ons:
extensi ons:

Rel 3G
99 3G
Core
HSDPA
IU-CS
Networ
k
extensi
ons
HSS –
LTE ons: eSRVC ….
over IP Sharing CS FB MMTE C
Rel 98 Multim
Networ
IUFLE IMS IBCF IMS L
k
97 Higher edia Modific X extensi PCRF extensi TAS,
Services CAME ons PCEF ons: SRVC
Rel Higher bit rates New ation L Ph 4 WLAN IP-SM- Precon C for
GSM 96 bit rates EDGE RAN IP at Voice GW ditions,
CAMEL User Emerg
Ph 2 GPRS Ph2 WCDM
Plane IMS over Emerg ency
GSM Higher CAMEL A
and IMS ency,S calls
BS = 9.6 bit rates RNC, IMS
Control RVCC,
Basic Kbit’/s 14.4 NodeB
Plane ALG Lawful
Service = SS=ISDN HSCSD CAME
Speech ASCI TrGW l Interc
L Ph3
Time
22
23 04/08/2023
VoLTE Network Architecture

24 04/08/2023
 MGW- IMS Mn (Megaco)
TDM MGCF Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
)
PSTN (ISUP
2G
CS-IP Billing
HPLMN (CAP)
C)
BB SCP

M
XCAP Ut (xcap)
IC

TD
BTS BSC IM-SSF
I/B (CAP)

)
UP
-
Voice P Mr’ (SIP MSML)
MS MGW-CS
( SI P) IN IP-SM-GW MRF

(IS
SIM Mc c (CA ) (MAP) Mp’(h248)
N (MAP SMS P) SCC-AS MRFC
IMSI (h248) (MA Traffica
MSISDN UP D (MAP) HLR ) )
MMTEL
MSS AP er
-
P et Open TAS (DNS
(SO
CS

–C VLR ) DNS
S am Ma
-

C P) LDAP i eNUM
IU

(d ISC (SIP)
IU- ANA AP) I2 (SIP)
3G
(SIP)
(R Gr(M Sh Mi )
One LDAP HSS Cx (diameter) S-CSCF BGCF DNS
NB RNC SGSN GGSN PDN Mx (

Multimedia
NDS IMS C
Mx
x( Mw
UE d ia Mw
SGs(SGSAP) CSFB me Mx
USIM
Hd (propr
LDAP ter I-CSCF IBCF ICi
SV(GTP V2) SRVCC ) (SI
IMSI
diameter) Mw P)
Mx
MSISDN S6a ( diameter) r) IMS ATC Other IMS
P ) MME HSS
( d iamete P-CSCF ALG F Networks
4G LTE
A ) LTE R x
( S1 V2 CFX5000

)
E PCRF )

IP
MM P IP
S1- GT ter
) (S Ix (megaco)

i(
( x e m Iq (megaco)

IZ
1 S5/S8 ( GTP V2) G iam G
Data
eN B S1
(d PDN )
UE SGW PGW RTP
USIM (GTP V1) Gi (IP) Mb (
S1U ( GTP-U )
SWx )
IMSI IMS ATGW TrG
eter
(d S
MSISDN b 2) ia 6b AGW W
m
S2 v1/v et ( diam
e
WiFi TP r)
Open Border GW
(G
SWu SWm
25
(IKEv2/Ipsec)
ePDG ( diameter ) AAA

xDSL GW
 MGW- IMS Mn (Megaco)
TDM MGCF Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
)
PSTN (ISUP
2G
CS-IP Billing
HPLMN (CAP)
C)
BB SCP

M
XCAP Ut (xcap)
IC

TD
BTS BSC IM-SSF
I/B (CAP)

)
UP
-
Voice P Mr’ (SIP MSML)
MS MGW-CS
( SI P) IN IP-SM-GW MRF

(IS
SIM Mc c (CA ) (MAP) Mp’(h248)
N (MAP SMS P) SCC-AS MRFC
IMSI (h248) (MA Traffica
MSISDN UP D (MAP) HLR ) )
MMTEL
MSS AP er
-
P et Nokia TAS (DN
(SO
CS

–C VLR S) DNS
S am Ma
-

C P) LDAP i eNUM
IU

(d ISC (SIP)
IU- ANA AP) I2 (SIP)
3G
(SIP)
(R Gr(M Sh Mi )
One LDAP HSS Cx (diameter) S-CSCF BGCF DNS
NB RNC SGSN GGSN PDN Mx (

Multimedia
NDS IMS C
Mx
x( Mw
UE d ia Mw
SGs(SGSAP) CSFB me Mx
USIM
Hd (propr
LDAP ter I-CSCF IBCF ICi
SV(GTP V2) SRVCC ) (SI
IMSI
diameter) Mw P)
Mx
MSISDN S6a ( diameter) r) IMS ATC Other IMS
P ) MME HSS
( d iamete P-CSCF ALG F Networks
4G LTE
A ) LTE R x
( S1 V2 CFX5000/SBC

)
E PCRF )

IP
MM P IP
S1- GT ter
) (S Ix (megaco)

i(
( x e m Iq (megaco)

IZ
1 S5/S8 ( GTP V2) G iam G
Data
eN B S1
(d PDN )
UE SGW PGW RTP
USIM (GTP V1) Gi (IP) Mb (
S1U ( GTP-U )
SWx )
IMSI IMS ATGW TrG
eter
(d S
MSISDN b 2) ia 6b AGW W
m
S2 v1/v et ( diam
e
WiFi TP r)
Open Border GW / SBC
(G
SWu SWm
26
(IKEv2/Ipsec)
ePDG ( diameter ) AAA

xDSL GW
 MGW- IMS Mn (Megaco)
TDM MGCF Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
)
PSTN (ISUP
2G
CS-IP Billing
HPLMN (CAP)
C)
BB SCP

M
XCAP Ut (xcap)
IC

TD
BTS BSC IM-SSF
I/B (CAP)

)
UP
-
Voice P Mr’ (SIP MSML)
MS MGW-CS
( SI P) IN IP-SM-GW MRF

(IS
SIM Mc c (CA ) (MAP) Mp’(h248)
N (MAP SMS P) SCC-AS MRFC
IMSI (h248) (MA Traffica
MSISDN UP D (MAP) HLR ) )
MMTEL
MSS AP er
-
P et Nokia TAS (DN
(SO
CS

–C VLR S) DNS
S am Ma
-

C P) LDAP i eNUM
IU

(d ISC (SIP)
IU- ANA AP) I2 (SIP)
3G
(SIP)
(R Gr(M Sh Mi )
One LDAP HSS Cx (diameter) S-CSCF BGCF DNS
NB RNC SGSN GGSN PDN Mx (

Multimedia
NDS IMS C
Mx
x( Mw
UE d ia Mw
SGs(SGSAP) CSFB me Mx
USIM
Hd (propr
LDAP ter I-CSCF IBCF ICi
SV(GTP V2) SRVCC ) (SI
IMSI
diameter) Mw P)
Mx
MSISDN S6a ( diameter) r) IMS ATC Other IMS
P ) MME HSS
( d iamete P-CSCF ALG F Networks
4G LTE
A ) LTE R x

VoLTE
( S1 V2 CFX5000/SBC

)
E PCRF )

IP
MM P IP
S1- GT ter
) (S Ix (megaco)

i(
( x e m Iq (megaco)

IZ
1 S5/S8 ( GTP V2) G iam G
Data
eN B S1
(d PDN )
UE SGW PGW RTP
USIM (GTP V1) Gi (IP) Mb (
S1U ( GTP-U )
SWx )
IMS ATGW TrG

VoWiFi
IMSI
eter
(d S
MSISDN b 2) ia 6b AGW W
m
S2 v1/v et ( diam
e
WiFi TP r)
Open Border GW / SBC
(G
SWu SWm
27
(IKEv2/Ipsec)
ePDG ( diameter ) AAA

xDSL GW
 MGW- IMS Mn (Megaco)
TDM MGCF Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
)
CS-IP
PSTN (ISUP Billing
HPLMN (CAP)
C)
BB SCP

M
XCAP Ut (xcap)
IC

TD
BTS BSC IM-SSF
I/B (CAP)

)
UP
P- Mr’ (SIP MSML)
MS MGW-CS
( SI P) IN IP-SM-GW MRF

(IS
SIM Mc c (CA ) (MAP) Mp’(h248)
N (MAP SMS P) SCC-AS MRFC
IMSI (h248) (MA A P) Traffica
MSISDN UP D (M A P ) ) (LD )
r
MMTEL
MSS HLR AP
-
e Nokia TAS (DN
CP VLR (SO et
CS

– m S) DNS
S a Ma
-

C ) LDAP i eNUM
IU

P (d ISC (SIP)
IU- ANA (SIP)
(R r (M AP) I2 (SIP) S h
G Mi )
One LDAP HSS Cx (diameter) S-CSCF BGCF DNS
NB RNC SGSN GGSN PDN Mx (
NDS IMS C
Mx
x( Mw
UE d ia Mw
SGs(SGSAP) CSFB me Mx
USIM
Hd (propr
LDAP ter I-CSCF
SV(GTP V2) SRVCC )
IMSI
diameter) Mw CFX5000
MSISDN S6a ( diameter) r) P) Other IMS
P ) MME
)
HSS
x ( d iamete ICi (SI Networks
A LTE R
( S1 V2 IBCF

)
E PCRF )

IP
MM P IP IMS ATC
S1- GT ter
) (S P-CSCF

i(
( x e m ALG F Mx

IZ
11 S5/S8 ( GTP V2) G iam G
eN B S (d PDN )
UE SGW PGW Iq (megaco) Ix (megaco) RTP
USIM (GTP V1) Gi (IP) Mb (
S1U ( GTP-U )
SWx )
IMSI IMS ATGW TrG
eter
(d S
MSISDN b 2) ia 6b AGW W
m
S2 v1/v et ( diam
e
WiFi - WAP TP r)
Open Border GW / SBC
(G
SWu SWm
28
(IKEv2/Ipsec)
ePDG ( diameter ) AAA

xDSL GW
 MGW- IMS Mn (Megaco)
TDM MGCF Mg [BGCF-MGCF] Mj [MGCF-I-CSCF (SIP)
)
CS-IP
PSTN (ISUP Billing
HPLMN (CAP)
C)
BB SCP

M
XCAP Ut (xcap)
IC

TD
BTS BSC IM-SSF
I/B (CAP)

)
UP
P- Mr’ (SIP MSML)
MS MGW-CS
( SI P) IN IP-SM-GW MRF

(IS
SIM Mc c (CA ) (MAP) Mp’(h248)
N (MAP SMS P) SCC-AS MRFC
IMSI (h248) (MA A P) Traffica
MSISDN UP D (M A P ) ) (LD )
r
MMTEL
MSS HLR AP
-
e Nokia TAS (DN
CP VLR (SO et
CS

– m S) DNS
S a Ma
-

C ) LDAP i eNUM
IU

P (d ISC (SIP)
IU- ANA (SIP)
(R r (M AP) I2 (SIP) S h
G Mi )
One LDAP HSS Cx (diameter) S-CSCF BGCF DNS
NB RNC SGSN GGSN PDN Mx (
NDS IMS C
Mx
x( Mw
UE d ia Mw
SGs(SGSAP) CSFB me Mx
USIM
Hd (propr
LDAP ter I-CSCF
SV(GTP V2) SRVCC )
IMSI
diameter) Mw CFX5000
MSISDN S6a ( diameter) r) P) Other IMS
P ) MME
)
HSS
x ( d iamete ICi (SI Networks
A LTE R
( S1 V2

)
E PCRF ) IBCF

IP
MM P IP IMS ATC
S1- GT ter
) (S P-CSCF

i(
( x e m ALG F Mx

IZ
11 S5/S8 ( GTP V2) G iam G
eN B S (d
UE SGW PGW PDN Iq (megaco) A-SBC Ix I-SBC
(megaco) RTP
)
USIM (GTP V1) Gi (IP) Mb (
S1U ( GTP-U )
SWx )
IMSI IMS ATGW TrG
eter
(d S
MSISDN b 2) ia 6b AGW W
m
S2 v1/v et ( diam
e
WiFi - WAP TP r)
Open Border GW / SBC
(G
SWu SWm
29
(IKEv2/Ipsec)
ePDG ( diameter ) AAA

xDSL GW
 Billing
SCP
XCAP Ut (xcap)
IM-SSF
IP-SM-GW MRF Mr’ (SIP MSML)
MRFC Mp’(h248)
SCC-AS
MMTEL Traffica
) )
AP er Nokia TAS (DN
(SO et S) DNS
i am Ma
ISC (SIP) eNUM
(d (SIP)
Sh
Cx (diameter) S-CSCF
Mi S)
One LDAP HSS BGCF
( DN
NDS IMS C Mx
x( Mw Mx
dia Mw
me Mx
LDAP ter I-CSCF IBCF ICi
) (SI
Mw P)
Mx
S6a ( diameter) ) IMS ATC Other IMS
MME HSS meter P-CSCF
1 AP) 2) LTE R x ( dia ALG F CFX5000/SBC
Networks
(S

)
E V PCRF )

IP
MM T P I P
S1- (G r) (S Ix (megaco)

i(
x mete m Iq (megaco)

IZ
11 S5/S8 ( GTP V2) G a G
eN B S i
(d PDN
UE SGW PGW
USIM (GTP V1) Gi (IP)
S1U ( GTP-U )
SWx )
IMSI IMS ATGW TrG
eter
(d S
MSISDN b 2) ia 6b AGW W
m
S2 v1/v et ( diam
e
WiFi TP r)
Open Border GW / SBC
(G
SWu SWm
30
(IKEv2/Ipsec)
ePDG ( diameter ) AAA

xDSL GW
 Billing
Ut (xcap)
Mr’ (SIP MSML)
Mp’(h248)
Traffica
) )
AP er Nokia TAS
(SO et (DNS
) DNS
i am Ma
ISC (SIP) eNUM
(d (SIP)
Sh )
One LDAP HSS Cx (diameter) NS
(D
NDS IMS Cx
( dia
me
LDAP t er ICi
) (SI
P)
S6a ( diameter) r) Other IMS
P)
MME HSS iamete
S1A
) LTE Rx ( d CFX5000/SBC
Networks
V2

)
E( PCRF )

IP
MM TP IP
S1- G r) S Ix (megaco)

i(
t e (
1( Gx iame Gm Iq (megaco)

IZ
eN B S1 S5/S8 ( GTP V2) d
( PDN
UE SGW PGW
USIM (GTP V1) Gi (IP)
S1U ( GTP-U )
SWx )
IMSI
eter
(d S
MSISDN b v2) ia 6b
2 / m
S v1 et
er ( diam
WiFi T P )
(G Open Border GW / SBC
SWu SWm
31
(IKEv2/Ipsec)
ePDG ( diameter ) AAA

xDSL GW
 Billing
Ut (xcap)
Mr’ (SIP MSML)
Mp’(h248)
Traffica
) )
AP er Nokia TAS
(SO et (DNS
) DNS
i am Ma
ISC (SIP) eNUM
(d (SIP)
Sh )
One LDAP HSS Cx (diameter) NS
(D
NDS IMS Cx
( dia
me
LDAP t er ICi
) (SI
P)
S6a ( diameter) r) Other IMS
P)
MME HSS iamete
S1A
) LTE Rx ( d CFX5000/SBC
Networks
V2

)
E( PCRF )

IP
MM TP IP
S1- G r) S Ix (megaco)

i(
t e (
1( Gx iame Gm Iq (megaco)

IZ
eN B S1 S5/S8 ( GTP V2) d
( PDN
UE SGW PGW
USIM (GTP V1) Gi (IP)
IMSI S1U ( GTP-U )
MSISDN

Open Border GW / SBC

32
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).
• Nodes acts as both: clients and servers
34
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
- Two parts:
• UAC – User Agent Client: initiates requests
• UAS – User Agent Server: generates responses

35
• 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:
- 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

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

37
Addressing
• Address of Record (AOR):
- URI which Identifies a participant in the session
- E.g. sip:[email protected], tel:+123456789
- Usually requires database lookups
- Appears in „From” and „To” headers and in the start-line
• Device URI:
- URI which Identifies a (logical) network element
- E.g. sip:[email protected]
- Usually does not require database lookups
- Appears in „Contact” header

38
SIP message structure
• Start line contains the SIP version and…
- …the method and target address in requests (Request URI R-URI)
Start-Line
- …the status in responses
• Headers contain the information related to the session in text lines Header1: value1
- e.g. the initiator, and the recipient of the request, call identifier etc. Header1: value2
• Message body (payload) can carry any text based information Header3: value3
- e.g. SDP packet, instant message etc.
Header4: value4
- Starts with CRLF

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

40
SIP Requests

REGISTER SUBSCRIBE MESSAGE

INVITE PUBLISH
ACK NOTIFY
BYE
CANCEL
PRACK
UPDATE
REFER
OPTIONS
INFO

41
• 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
• 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
42
• Return all current registrations in response
• 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

43
• ACK:
- Acknowledges final responses for INVITE requests
- It can also carry media description, but only if the initial INVITE did not
• 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)

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

45
• 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
- Proxies must not generate OPTIONS request

47
• OPTIONS and CANCEL basics:

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

49
• 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
- Used for e.g. codec negotiation, QoS parameter updates

50
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
- „Event” header describes which actions the UA wants to subscribe to
- „Allow-Events” header may show the allowed events

52
• PUBLISH:
- Used by a UA to publish an event towards an ESC which then distributes it to the interested
parties

53
• 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
- Solicited ~: sent within a dialog (i.e.: subscription)
- Unsolicited ~: sent outside a dialog (i.e.: MWI)

54
• 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
- „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)

56
• 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
- End-to-end transmission

57
• Response:
- SIP message which is sent by a server towards a client responding to a previously received
request
- e.g. 200 message
• 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

58
• 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)

59
RESPONSES
• Status codes:
- Informational: 1xx
• 100,180,181,183
- Success: 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: 6xx
• 600,606
60
• 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)
• 180 Ringing:
- Indicates that the INVITE has reached it’s target and it is alerting
- May contain media description e.g. for special RBT

61
• 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:

- Indicates that an INVITE containing an „Expires” header has timed out

67
• 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:

- The length of the message exceeds the server capabilities

71
• 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 header-
value)
- Field names are always case-insensitive
• E.g. the following ones are equivalent
Contact: <sip:[email protected]>;expires=3600
CONTACT: <sip:[email protected]>;ExPiReS=3600
- In most cases field values, parameter names, and parameter values are
case-insensitive too
- Many headers have a compact form of one character

73
• From:

• Shows the originator of the session establishment attempt

• Must contain a URI and a „tag” field
- 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

74
• To:

Shows the target of the session establishment attempt

• Must contain a URI
- 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

75
• 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)
• 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

76
• Via: In requests

77
• Via:

• In responses
- 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

78
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
- Local-id should be a cryptographically random string

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

81
CSeq:

82
• Contact:

• Contains the URI of the resource generating the SIP message

• Usually it resolves directly to the address of the UA
- 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

83
• 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
• Shows which extensions of SIP the UA requires the other party to support

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

85
 • 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)
PRB 01CA si7prb
c0B17_mapped_from_ext_cause
Situation FFFE
cd_t type constant definition info The clear code is mapped from an external cause
code
Add info 0  
86
• 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
• 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

87
• Authorization:

• Carries authentication credentials in requests

• Typically in a reformulated request generated after the arrival of a „401
Unauthorized” response

88
• Record-Route:

Record-Route: <sip:private.in.nephthys.tas.com:5060;lr>

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

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

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

90
• Content-Type:
Content-Type: application/sdp

• Indicates the type of the payload carried in the message body

• Content-Length:
Content-Length: 0

91
• Indicates the length of the payload carried in the message
• 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)
- E.g.: Expires: Mon, 8 Nov 2010 16:00:00 GMT+1
• Typically in case of REGISTER, SUBSCRIBE and INVITE requests

92
• Session-Expires:

Session-Expires: 3600

• It can define a duration for a session

- It can be extended using an UPDATE or a re-INVITE method

93
• 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’’.

94
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
• „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
96
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.
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

Client
Server

10
6
Examples – Basic Call with 100rel

10
7
User Plane Setup

10
8
10
9
11
0