SIP Signaling Anlysis
SIP Signaling Anlysis
• VoLTE Architecture
• Registration
• xxNETWORK registration example with signaling messages
• VoLTE session setup signaling
• xxNETWORK VoLTE session setup example with signaling messages
• End the call
S-CSCF
MME P-CSCF
LTE
eNode-B Serving PDN
GW GW I-CSCF
LTE Control plane
SAE Gateway
VoLTE Voice Bearer
SIP Signaling Bearer QCI5
Internet
For internal use
7 11/25/2021 ©2013 Nokia Solutions and Networks. All rights reserved.
Registration
The initial registration procedure consists of the UE sending an unprotected REGISTER request and, if challenged
depending on the security mechanism supported for this UE, sending the integrity-protected REGISTER request or other
appropriate response to the challenge. The UE can register a public user identity with any of its contact addresses at any
time after it has acquired an IP address, discovered a P-CSCF, and established an IP-CAN bearer that can be used for
SIP signalling. However, the UE shall only initiate a new registration procedure when it has received a final response from
the registrar for the ongoing registration, or the previous REGISTER request has timed out.
Authentication is performed during initial registration. A UE can be re-authenticated during subsequent reregistrations,
deregistrations or registrations of additional public user identities. When the network requires authentication or re-
authentication of the UE, the UE will receive a 401 (Unauthorized) response to the REGISTER request.
2. Terminal sets the IMEI and IMS communication identifier Activate EPS Bearer Accept (QCI5) and DRB
4. S-CSCF performs registration procedures with HSS and Allocate client and
server ports
acquires user authentication information
5. S-CSCF sends UE a challenge in 401 Unauthorized REGISTER
Registration procedures
message with HSS
200 OK,
REGISTER
401 Unauthorized
Verify AUTN &
calculate RES
REGISTER
401 Unauthorized
UE sends Registration Request to S-CSCF (via P- Activate EPS Bearer Accept (QCI5) and DRB
REGISTER
REGISTER
Registration procedures
with HSS
401 Unauthorized:
Store P-CSCF IP
Address
REGISTER
Registration procedures
with HSS
401 Unauthorized:
REGISTER
Store P-CSCF IP
Address
S-CSCF notifies the terminal about completed
Extract user public
registration identity from ISIM
REGISTER
Registration procedures
with HSS
401 Unauthorized:
REGISTER
200 OK,
• Upon generating an initial INVITE request, the UE shall include the Accept header field with "application/sdp", the MIME type
associated with the 3GPP IM CN subsystem XML body (see subclause 7.6.1) and any other MIME type the UE is willing and
capable to accept.
• The "integration of resource management and SIP" extension is hereafter in this subclause referred to as "the precondition
mechanism" and is defined in RFC 3312 [30] as updated by RFC 4032 [64].
• The preconditions mechanism should be supported by the originating UE.
• The UE may initiate a session without the precondition mechanism if the originating UE does not require local resource
reservation.
• NOTE 1: The originating UE can decide if local resource reservation is required based on e.g. application requirements,
current access network capabilities, local configuration, etc.
• In order to allow the peer entity to reserve its required resources, an originating UE supporting the precondition mechanism
should make use of the precondition mechanism, even if it does not require local resource reservation.
• Upon generating an initial INVITE request using the precondition mechanism, the UE shall:
• - indicate the support for reliable provisional responses and specify it using the Supported header field mechanism;and
• - indicate the support for the preconditions mechanism and specify it using the Supported header field mechanism.
• Upon generating an initial INVITE request using the precondition mechanism, the UE should not indicate the requirement for the
precondition mechanism by using the Require header field mechanism.
• NOTE 2: If an UE chooses to require the precondition mechanism, i.e. if it indicates the "precondition" option-tag within the
Require header field, the interworking with a remote UE, that does not support the precondition mechanism, is not described in
this specification.
• NOTE 3: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26]. The UE can accept or
reject any of the forked responses, for example, if the UE is capable of supporting a limited number of simultaneous transactions
or early dialogs.
• Upon successful reservation of local resources the UE shall confirm the successful resource reservation (see subclause 6.1.2)
within the next SIP request.
• NOTE 4: In case of the precondition mechanism being used on both sides, this confirmation will be sent in either a PRACK
request or an UPDATE request. In case of the precondition mechanism not being supported on one or both sides, alternatively a
reINVITE request can be used for this confirmation after a 200 (OK) response has been received for the initial INVITE request, in
case the terminating UE does not support the PRACK request (as described in RFC 3262 [27]) and does not support the
UPDATE request (as described in RFC 3311 [29]).
• NOTE 5: If the UE supports the P-Early-Media header field, upon receiving a 18x provisional response with a P-Early-Media
header field indicating authorized early media, as described in RFC 5009 [109], if the preconditions are met, the UE should,
based on local configuration, present received early media to the user.
• NOTE 6: If the UE supports the P-Early-Media header field, upon receiving a 180 (Ringing) provisional response with a P-
Early-Media header field indicating authorized early media, as described in RFC 5009 [109], if the preconditions are met, and the
UE presents the received early media to the user based on local configuration, the UE will not provide an indication that the
invited user is being alerted.
• NOTE 7: If the UE supports the P-Early-Media header field and if the most recently received P-Early-Media header field
within the dialog includes a parameter applicable to media stream with value "inactive", then based on local configuration, the UE
will provide an indication that the invited user is being alerted and stop presenting received early media to the user if requested
by any previous receipt of P-Early-Media header field within the dialog.
For internal use
23 11/25/2021 ©2013 Nokia Solutions and Networks. All rights reserved.
Call initiation - UE-originating case
• If the UE wishes to receive early media authorization indications, as described in RFC 5009 [109], the UE shall add the P-Early-
Media header field with the "supported" parameter to the INVITE request.
• When a final answer is received for one of the early dialogues, the UE proceeds to set up the SIP session. The UE shall not
progress any remaining early dialogues to established dialogs. Therefore, upon the reception of a subsequent final 200 (OK)
response for an INVITE request (e.g., due to forking), the UE shall:
• 1) acknowledge the response with an ACK request; and
• 2) send a BYE request to this dialog in order to terminate it.
• Upon receiving a 488 (Not Acceptable Here) response to an initial INVITE request, the originating UE should send a new INVITE
request containing SDP according to the procedures defined in subclause 6.1.
• NOTE 8: An example of where a new request would not be sent is where knowledge exists within the UE, or interaction
occurs with the user, such that it is known that the resulting SDP would describe a session that did not meet the user
requirements.
• Upon receiving a 421 (Extension Required) response to an initial INVITE request in which the precondition mechanism was not
used, including the "precondition" option-tag in the Require header field, the originating UE shall:
• - send a new INVITE request using the precondition mechanism, if the originating UE supports the precondition
mechanism; and
• - send an UPDATE request as soon as the necessary resources are available and a 200 (OK) response for the first
PRACK request has been received.
• Upon receiving a 503 (Service Unavailable) response to an initial INVITE request containing a Retry-After header field, then the
originating UE shall not automatically reattempt the request until after the period indicated by the Retry-After header field
contents. related to that early dialog
For internal use
24 11/25/2021 ©2013 Nokia Solutions and Networks. All rights reserved.
Call initiation - UE-originating case
• The UE may include a "cic" tel-URI parameter in a tel-URI, or in the userinfo part of a SIP URI with user=phone, in the Request-
URI of an initial INVITE request if the UE wants to identify a user-dialed carrier, as described in RFC 4694 [112].
• NOTE 9: The method whereby the UE determines when to include a "cic" tel-URI parameter and what value it should
contain is outside the scope of this document (e.g. the UE could use a locally configured digit map to look for special prefix digits
that indicate the user has dialled a carrier).
• NOTE 10: The value of the "cic" tel-URI parameter reported by the UE is not dependent on UE location (e.g. the reported
value is not affected by roaming scenarios).
• In the event the UE receives a 380 (Alternative Service) response to an INVITE request the response containing a P-Asserted-
Identity header field with a value equal to the value of the last entry on the Path header field value received during registration
and the the response containing a 3GPP IM CN subsystem XML body that includes an <ims-3gpp> element, including a version
attribute, with an <alternative-service> child element with the <type> child element set to "emergency" (see table 7.7AA), the UE
shall attempt an emergency call as described in subclause 5.1.6.
• NOTE 11: The last entry on the Path header field value received during registration is the value of the SIP URI of the P-
CSCF.
• Upon receiving a 199 (Early Dialog Terminated) provisional response to an established early dialog the UE shall release
resources specifically related to that early dialog
f local resource reservation is not required by the terminating UE and the terminating UE supports the precondition mechanism and:
- the received INVITE request includes the "precondition" option-tag in the Supported header field and:
• the required resources at the originating UE are not reserved, the terminating UE shall use the precondition mechanism;
or
• the required local resources at the originating UE and the terminating UE are available, the terminating UE may use the
precondition mechanism;
- the received INVITE request does not include the "precondition" option-tag in the Supported header field or Require header
field, the terminating UE shall not make use of the precondition mechanism; or
- the received INVITE request includes the "precondition" option-tag in the Require header field, the terminating UE shall use
the precondition mechanism.
NOTE 2: Table A.4 specifies that UE support of forking is required in accordance with RFC 3261 [26].
NOTE 3: If the terminating UE does not support the precondition mechanism it will apply regular SIP session initiation procedures.
If the terminating UE requires a reliable alerting indication at the originating side, the UE shall send the 180 (Ringing) response
reliably. If the received INVITE request indicated support for reliable provisionable responses, but did not require their use, the
terminating UE shall send provisional responses reliably only if the provisional response carries SDP or for other application
related purposes that requires its reliable transport.
NOTE 4: Certain applications, services and operator policies might mandate the terminating UE to send a 199 (Early Dialog
Terminated) provisional response (see RFC 6228 [142]) prior to sending a non-2xx final response to the INVITE request.
100 Trying
UPDATE UPDATE
1. USER 1 generates an INVITE request, which is sent to 200 OK 200 OK
the proxy at USER_2 The INVITE message contains: Ringing
to use and the protocol for transporting the media. 200 OK (prack) 200 OK (prack)
Answer
2. The P-CSCF acknowledges the INVITE to the UE with
"100 Trying” message indicating that the call setup is in 200 OK (invite) 200 OK (invite)
3. IMS commands PCRF (with PGW, SGW etc.) to set up Voice or Video Session
100 Trying
INVITE
5. Originating UE notifies the terminating UE using PRACK EPS Bearer Activation for QCI1 and Audio Video Path Setup
the selected codec. OK 200 is received from terminating
UE 183 Session Progress
200 OK 200 OK
UE start ringing. 6
7. Once originating UE receives 200 OK, it ACKs it and the UPDATE UPDATE
PRACK PRACK
ACK ACK
8 BYE BYE
ACK ACK
100 Trying
with "100 Trying” message indicating that the call setup EPS Bearer Activation for QCI1 and Audio Video Path
Setup
is in progress. 183 Session Progress
PRACK
3. The SIP method OPTIONS allows a IMS to query EPS Bearer Activation for QCI1 and Audio Video Path
another UA or a proxy server as to its capabilities. This Setup
200 OK 200 OK
Description Protocol (SDP) parameters: declaration for 180 Ringing 180 Ringing
the selected codec. OK 200 is received from terminating 183 Session Progress
UPDATE 7 UPDATE
8. Both terminals confirm the setup of bearer with QoS 200 OK 200 OK
according to UPDATE & 200 OK message, terminating 8 Ringing
9. Once both UEs receive 200 OK, they ACK it and the SIP 200 OK 200 OK
call INVITE
- Options INVITE
100 Trying
100 Trying
to IMS 200 OK
100 Trying
AMR-WB/16000
maxptime:240
ptime:20
- Trying INVITE
Please note that the SIP client of LG G2 did not send ‘100
Trying’ message although both UEs have the same Qualcomm
chipset (MSM8974).
call INVITE
with its own and determines the codec to be used. 100 Trying
Bandwidth Value: 0
Media Attribute (a):
rtpmap:104 AMR-WB/16000
Media Attribute Fieldname: rtpmap
Media Format: 104
MIME Type: AMR-WB
Sample Rate: 16000
100 Trying
OPTIONS
EPS Bearer Activation for QCI1 and Audio Video Path Setu
PRACK
200 OK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
100 Trying
OPTIONS
100 Trying
EPS Bearer Activation for QCI1 and Audio Video Path Setu
PRACK
200 OK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
PRACK
200 OK
100 Trying
OPTIONS
PRACK
200 OK
UPDATE UPDATE
100 Trying
OPTIONS
100 Trying
PRACK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
PRACK
200 OK
200 OK
UPDATE UPDATE
200 OK 200 OK
100 Trying
OPTIONS
100 Trying
PRACK
200 OK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
PRACK
200 OK
UPDATE UPDATE
200 OK 200 OK
Ringing
100 Trying
OPTIONS
200OK
INVITE
100 Trying
EPS Bearer Activation for QCI1 and Audio Video Path Set
PRACK
200 OK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
PRACK
200 OK
UPDATE UPDATE
200 OK 200 OK
Ringing
200 OK 200 OK
100 Trying
OPTIONS
Once MO has answered it sends 200 OK.
200OK
Once originating UE receives 200 OK, it sends EPS Bearer Activation for QCI1 and Audio Video Path Setu
200 OK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
200 OK
UPDATE UPDATE
200 OK 200 OK
Ringing
200 OK 200 OK
ACK ACK
For internal use
66 11/25/2021 ©2013 Nokia Solutions and Networks. All rightsor reserved.
Voice Video Session
NSN Smart Lab UE to UE VoLTE call – ACK
Session Initiation Protocol (ACK) CSeq: 1066529694 ACK
Request-Line: ACK sip:psslcsf1-gm.testlab.samsung.com;transport=TCP Sequence Number: 1066529694
SIP/2.0 Method: ACK
Method: ACK Max-Forwards: 70
Request-URI: sip:psslcsf1-gm.testlab.samsung.com;transport=TCP [truncated] Route:
Request-URI Host Part: psslcsf1-gm.testlab.samsung.com <sip:10.40.136.182:5067;routing_id=pcscf_a_side;lskpmc=PYK;lr>,<sip:ssslcsf1.
[Resent Packet: False] testlab.samsung.com:5090;reg-
Message Header id=H61386209885981647;routing_id=f6bdedbdf2a447065382ce9b0aa206fe;lskpmc=SH6;
l: 0 lr;interface=isc>,<sip:AAQACARhwAABZA
f: <sip:[email protected]>;tag=3214013382 Route URI:
SIP from address: sip:[email protected] sip:10.40.136.182:5067;routing_id=pcscf_a_side;lskpmc=PYK;lr
SIP from address User Part: +821090000053 Route Host Part: 10.40.136.182
SIP from address Host Part: testlab.samsung.com Route Host Port: 5067
SIP from tag: 3214013382 Route URI parameter: routing_id=pcscf_a_side
t: <sip: Route URI parameter: lskpmc=PYK
[email protected];user=phone>;tag=daUW.4ZA2VWd03i7 Route URI parameter: lr
SIP to address: sip:[email protected];user=phone Route URI: sip:ssslcsf1.testlab.samsung.com:5090;reg-
SIP to address User Part: +821090000038 id=H61386209885981647;routing_id=f6bdedbdf2a447065382ce9b0aa206fe;lskpmc=SH6;
SIP to address Host Part: testlab.samsung.com lr;interface=isc
SIP To URI parameter: user=phone Route Host Part: ssslcsf1.testlab.samsung.com
SIP to tag: daUW.4ZA2VWd03i7 Route Host Port: 5090
v: SIP/2.0/TCP 10.80.132.65:8907;branch=z9hG4bK263235027 Route URI parameter: reg-id=H61386209885981647
Transport: TCP Route URI parameter:
Sent-by Address: 10.80.132.65 routing_id=f6bdedbdf2a447065382ce9b0aa206fe
Sent-by port: 8907 Route URI parameter: lskpmc=SH6
Branch: z9hG4bK263235027 Route URI parameter: lr
i: [email protected] Route URI parameter: interface=isc
Route URI:
sip:[email protected]:5060;transport=TCP;lr
Route Userinfo: AAQACARhwAABZAAAA8gAAfUkK
Route Host Part: 10.40.140.33
Route Host Port: 5060
Route URI parameter: transport=TCP
Route URI parameter: lr
100 Trying
OPTIONS
MT or MO can release the voice communication
by sending BYE message 200OK
INVITE
• SIP from address User Part: +821090000053 EPS Bearer Activation for QCI1 and Audio Video Path Setu
• SIP from address Host Part: testlab.samsung.com
183 Session Progress
PRACK
200 OK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
PRACK
200 OK
UPDATE UPDATE
200 OK 200 OK
Ringing
200 OK 200 OK
ACK ACK
For internal use Voice or Video Session
68 11/25/2021 ©2013 Nokia Solutions and Networks. All rights reserved.
BYE BYE
NSN Smart Lab UE to UE VoLTE call – BYE
100 Trying
OPTIONS
100 Trying
EPS Bearer Activation for QCI1 and Audio Video Path Setu
PRACK
200 OK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
PRACK
200 OK 200 OK
UPDATE UPDATE
200 OK 200 OK
Ringing
200 OK 200 OK
ACK ACK
Voice or Video Session
For internal use
70 11/25/2021 ©2013 Nokia Solutions andBYE
Networks. All rights reserved. BYE
200 OK 200 OK
NSN Smart Lab UE to UE VoLTE call – 200OK (to BYE)
100 Trying
127 ms
57 ms OPTIONS
49 ms 200 OK
INVITE
530 ms 46 ms
183 Session Progress 116 ms EPS Bearer Activation for QCI1 and Audio Video Path Setup
PRACK
37 ms
PRACK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
66 ms
48 ms
ACK
200 OK 108 ms
UPDATE 40 ms
UPDATE
41 ms 200 OK
Ringing
200 OK 106 ms
180 Ringing
3489 ms
Answer
200 OK
72 ms
200 OK
59 ms
ACK
37 ms
MO MT
5000 5000
4500 4500
4000 4000
3500
3500 3000
3000 2500
2500 2000
2000 1500
MO 1000 MT
1500 500
1000 0
500 MO Trying INVITE - 100 Trying 183 180 Total
0 - MT 100 Trying - 183 Session Ringing -
INVITE - 100 100 Trying - 183 Session 180 Ringing - Total INVITE Session Progress - ACK
Trying 183 Session Progress - ACK Progress 180
Progress 180 Ringing Ringing
INVITE INVITE
EPS Bearer Activation for QCI1 and Audio Video Path Setup EPS Bearer Activation for QCI1 and Audio Video Path Setup
100 Trying
INVITE
When no preconditions are required the setup procedure EPS Bearer Activation for QCI1 and Audio Video Path Setup
B starts ringing once received INVITE in case no 180 Ringing 180 Ringing
ACK ACK
BYE BYE
ACK ACK
INVITE
100 Trying
The VoLTE call setup flow from xxNETWORK network is
illustrated on the right with the following remarks: 183 Session Progress
INVITE
200 OK
100 Trying
1. After ‘183 Session Progress’ message IMS signalling
(QCI 5) bearer can carry RTP audio packets, e.g. 1 180 Ringing
Ringing
3. EPS bearer for QCI1 is activated at A-party once a Voice or Video Session
originating UE has sent ACK and SIP session is then
established. BYE
200 OK
BYE
200 OK
-TRYING INVITE
100 Trying
100 Trying
The ‘183 Session Progress’ response is used to convey
information about the progress of the call that is not 183 Session Progress
100 Trying
The P-CSCF updates the Via and Route-Record headers and
183 Session Progress
forwards the request to the Called UE. INVITE
100 Trying
When the P-CSCF receives an initial INVITE request
destined for the UE, it will have a list of Record-Route header 183 Session Progress
INVITE
fields. Prior to forwarding the initial INVITE request, the P-
100 Trying
CSCF shall respond to all INVITE requests with a ‘100 Trying’
provisional response.
Please note that the SIP client of LG G2 did not send ‘100
Trying’ message although both UEs have the same
Qualcomm chipset (MSM8974).
100 Trying
100 Trying
Please note that 180 Ringing’ message is NOT forwarded Ringing
by IMS to the originating UE in this example. However, 180 Ringing
100 Trying
has received ACK from IMS and thus, this completes the 100 Trying
INVITE/200 OK/ACK three-way handshake used to Ringing
establish SIP sessions at B-party. 180 Ringing
Answer
200 OK
ACK
100 Trying
Ringing
180 Ringing
Answer
200 OK
ACK
200 OK
ACK
INVITE
xxNETWORK - Wireshark 1.8.4
Real-Time Transport Protocol 100 Trying
[Stream setup by SDP (frame 55)]
[Setup frame: 55] Ringing
[Setup Method: SDP] 180 Ringing
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False Answer
...0 .... = Extension: False 200 OK
.... 0000 = Contributing source identifiers count: 0
1... .... = Marker: True ACK
Payload type: AMR-WB (100)
Sequence number: 245 EPS Bearer Activation for QCI1 and Audio Video Path
[Extended sequence number: 65781] Setup
Timestamp: 14068
Synchronization Source identifier: 0x0000f500 (62720) 200 OK
Adaptive Multi-Rate
Payload decoded as RFC 3267 ACK
1111 .... = CMR: No mode request (15)
.... 0000 = Reserved: 0 EPS Bearer Activation for QCI1 and Audio Video Path
Setup
Payload Table of Contents
0... .... = F bit: Last frame in this payload
.100 0... = FT bits: AMR-WB 23.85 kbit/s (8) Voice or Video Session
.... .1.. = Q bit: Ok
Upon receipt of an indication that the radio/bearer resources are no longer available or the signalling bearer is lost to the UE for a
session (e.g. abort session request from PCRF) or upon detecting that the SDP offer conveyed in a SIP response contained
parameters which are not allowed according to the local policy (as specified in the subclause 6.2), the P-CSCF shall release the
respective dialog by applying the following steps:
• if the P-CSCF serves the calling user of the session, then the P-CSCF shall generate a BYE request destined for the called user
based on the information saved for the related dialog, including:
- a Request-URI, set to the stored Contact header field provided by the called user;
- a To header field, set to the To header field value as received in the 200 (OK) response for the initial INVITE request;
- a From header field, set to the From header field value as received in the initial INVITE request;
- a Call-ID header field, set to the Call-Id header field value as received in the initial INVITE request;
- a CSeq header field, set to the current CSeq value stored for the direction from the calling to the called user, incremented by
one;
- a Route header field, set to the routeing information towards the called user as stored for the dialog;
- a Reason header field that contains:
- a 503 (Service Unavailable) response code, if radio/bearer interface resources are no longer available; or
- a 503 (Service Unavailable) response code, if the signalling bearer is lost to the UE; or
- a 488 (Not Acceptable Here) response code, if a SDP offer conveyed in a SIP response contained parameters which are not
allowed according to the local policy;
- further header fields, based on local policy; and
- - send the generated BYE requests towards the called user;
• When the P-CSCF receives a 2xx response for a BYE request matching an existing dialog, then the
P-CSCF shall delete all the stored information related to the dialog.
entity INVITE
100 Trying
INVITE
The call release reason is indicated in ‘BYE’ message as specified EPS Bearer Activation for QCI1 and Audio Video Path Setup
in RFC3326, e.g.
183 Session Progress
200 OK 200 OK
Ringing
PRACK PRACK
ACK ACK
BYE BYE
200 OK 200 OK
- BYE INVITE
At the end of the call, the terminating UE generates BYE 100 Trying
message. This BYE is routed to the originating UE
through IMS. No ACK is sent - an ACK is only sent in 183 Session Progress
100 Trying
When the P-CSCF receives a 2xx response for a BYE Ringing
request matching an existing dialog, then the P-CSCF 180 Ringing
shall delete all the stored information related to the dialog. Answer
200 OK
ACK
200 OK
ACK
BYE
BYE
200 OK
200 OK
- BYE INVITE
The originating UE confirms receipt of the BYE with a 200 100 Trying
(OK) response, which terminates the session and the
BYE transaction. 183 Session Progress
INVITE
100 Trying
Ringing
180 Ringing
Answer
200 OK
ACK
200 OK
ACK
BYE
BYE
200 OK
200 OK
• The VoLTE call is successfully setup from SIP session establishment point of view once three-way handshake is
completed, i.e. the sequence of INVITE, 200 OK and ACK messages are transmitted at mobile originating UE.
• Alternatively, call setup time end point could be the ‘180 Ringing’ message at originating UE to exclude the SIP
application/user delay in answering the call. However, ‘180 Ringing’ message is not always forwarded by IMS to the
originating UE due to fact that ‘ringing tone’ is transmitted as RTP audio already after ‘183 Session progress’ message
is received by a calling party.
• The delay contribution from radio procedures such as RRC connection establishment, paging and dedicated EPS
bearer activations is negligible in total call setup time.
• Mobile originating call setup delay is highly depending on IMS delay (processing and forwarding INVITE)
• The following values are average values of 100 VoLTE calls in drive test done in live LTE network
100 Trying
606 ms
73 ms INVITE
100 Trying
60 ms
Ringing
3060 ms 180 Ringing
1275 ms (* call script delay)
Answer
152 ms 200 OK (invite)
ACK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
200 OK (invite) 65 ms
ACK
EPS Bearer Activation for QCI1 and Audio Video Path Setup
Please note that the call script of drive test tool is causing delay of almost 1300ms (180 Ringing – 200 OK)
in total call setup time and therefore, it should be ignored.
MO MT
5000 5000
4500 4500
4000 4000
3500 3500
3000 3000
2500 2500
2000 2000
MO MT
1500 1500
1000 1000
500 500
0 0
INVITE-100 100 Trying- 183 Session 200 OK Total setup INVITE-100 100 Trying- 180 Ringing- 200 OK Total setup
Trying 183 Session Progress-200 (Invite)-ACK time Trying 180 Ringing 200 OK (Invite)-ACK time
Progress OK (Invite) (Invite)
The first digit of the Status-Code defines the class of response. The last two digits do not
have any categorization role. For this reason, any response with a status code between
100 and 199 is referred to as a "1xx response", any response with a status code
between 200 and 299 as a "2xx response", and so on.