IMS Design and Log Analysis

Reference Manual
80-PP068-3 Rev. A

October 30, 2019

Confidential and Proprietary - Qualcomm Technologies, Inc.

NO PUBLIC DISCLOSURE PERMITTED: Please report postings of this document on public servers or websites to
[email protected].

Restricted Distribution: Not to be distributed to anyone who is not an employee of either Qualcomm Technologies, Inc. or its affiliated
companies without the express approval of Qualcomm Configuration Management.

Not to be used, copied, reproduced, or modified in whole or in part, nor its contents revealed in any manner to others without the express
written permission of Qualcomm Technologies, Inc.

All Qualcomm products mentioned herein are products of Qualcomm Technologies, Inc. and/or its subsidiaries.

Qualcomm is a trademark of Qualcomm Incorporated, registered in the United States and other countries. Other product and brand names
may be trademarks or registered trademarks of their respective owners.

This technical data may be subject to U.S. and international export, re-export, or transfer ("export") laws. Diversion contrary to U.S. and
international law is strictly prohibited.

Qualcomm Technologies, Inc.

5775 Morehouse Drive
San Diego, CA 92121
U.S.A.

© 2019 Qualcomm Technologies, Inc. and/or its subsidiaries. All rights reserved.
Revision history

Revision Date Description

A October 2019 Initial release

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 2

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
Contents

Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1 Introduction to IMS design and log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Technical assistance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 L+L IMS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1 Call restrictions in L+L IMS networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Call concurrencies in L+L IMS networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.1 Voice concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Data concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Emergency call support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Override configuration changes per SUB in L+L IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1 Impact of IMS registration on a SUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5 Call flows for L+L IMS architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 Log analysis for L+L IMS call scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.1 Log messages during IMS registration on both SUBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.6.2 Log messages during UT call flow on SUB1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.3 Log messages during LTE to IWLAN handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3 RCS presence service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 Presence service software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 Presence publication responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Presence retrieval or capability polling responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 Presence enabler call flows and log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.1 IMS registration and presence publication call flow and log messages . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2 Capability polling call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.3 Sequential capability polling call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4.4 Availability fetch and originate VoLTE or VT call call flows and log messages . . . . . . . . . . . . . . . . . 39
3.4.5 IMS reregistration and republication call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.6 Toggle VoLTE ON/OFF call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 3

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Contents

3.4.7 Toggle VT ON or OFF call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.4.8 Mobile data network on/off call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4.9 L2e and e2L iRAT transitions call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4.10 Airplane mode on call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.4.11 UE power-off call flows and log messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.5 Enable RCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 IMS VoLTE architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Network architecture for VoLTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 EPS architecture for VoLTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.2 IMS architecture for VoLTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.2 UE architecture for IMS VoLTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.3 High-level VoLTE call flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.4 IMS registration to VoLTE call flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 High-level end-to-end VoLTE call establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6 Call setup scenarios and corresponding logs in IMS VoLTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.6.1 Mobile-originated call setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6.2 Mobile-originated call setup (with precondition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.6.3 Mobile-originated call setup failure (with precondition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6.4 Mobile-terminated call setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.6.5 Mobile-terminated call setup (with precondition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.6.6 Mobile-terminated call setup failure (with precondition) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.6.7 Call termination (near side-initiated) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.6.8 Call termination (far side-initiated) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.7 Call hold call flow and log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
4.8 Call resume call flow and log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.9 Call add call flow and log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.10 Call waiting call flow and log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.11 Call conferencing call flow and log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.11.1 Call conference subscribe event package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.12 DTMF call flow and logs analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.13 Audio codec profile configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5 IMS UT interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.1 UT call flows and log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.1.1 UT PDN bringup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.1.2 Activate call waiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.1.3 Interrogate current call waiting setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.1.4 Deactivate call waiting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 4

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Contents

5.1.5 Activate call forwarding unconditional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

5.1.6 Interrogate CFU setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.1.7 Deactivate CFU service and retain configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
5.1.8 Deactivate CFU service and erase target number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.1.9 Reactivate CFU using existing configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.2 Enable or disable UT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.3 XCAP error messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
6 IMS Wi-Fi handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.1 Handover between IWLAN and LTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.1.1 Handover between LTE and IWLAN while UE is in idle state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.1.2 Handover between LTE and IWLAN while UE is in connected state . . . . . . . . . . . . . . . . . . . . . . . . 122
6.2 Decode ESP packets on the ePDG tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
7 E911 call scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.1 E911 call establishment in CS and IMS domains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7.2 E911 call flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7.3 E911 log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.3.1 Log messages during an E911 call originated with initial attach . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
7.3.2 Log messages during an E911 call originated with emergency attach . . . . . . . . . . . . . . . . . . . . . . 136
7.4 E911 call establishment/termination flows on UE with UICC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
7.4.1 Scenario 1: Emergency call over IMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
7.4.2 Scenario 2: E911 IMS registration is rejected . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.4.3 Scenario 3: Emergency call without a SIM card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
7.5 E911 call with IMS-enabled SIM card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.6 E911 call without a SIM card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
7.7 E911 service category . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
7.8 Alternate service handling for E911 service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.8.1 Log messages during non-compliant network behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.8.2 Log messages during non-compliant network behavior with UE workaround . . . . . . . . . . . . . . . 155
7.8.3 Log messages during the switchover between IMS domain and CS domain . . . . . . . . . . . . . . . . . 156
7.8.4 Log messages during emergency access barring is found in SIB2 . . . . . . . . . . . . . . . . . . . . . . . . . . 156
7.9 E911 over Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
7.10 P-Emergency call mode preference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
7.10.1 Expiry of the ECBM timer from the CM module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.11 E911 call setup timer expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
7.12 Transition of UE states based on NAS timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7.13 E911 conformance testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
A Keywords for log analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 5

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Contents

B Carrier configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

C Decode TLS packets in Wireshark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
C.1 Requirements to decode TLS packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
C.2 Procedure to decode TLS packet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
C.2.1 Sample Wireshark window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
C.2.2 Multiple TLS sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
D References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
D.1 Related documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
D.2 Acronyms and terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 6

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
Tables

Table 2-1: Call restrictions on SUB1, for active CS/VoLTE/VoWiFi call on SUB2....................................................... 12
Table 2-2: IMS voice call concurrency handling scenarios....................................................................................... 13
Table 2-3: Data call concurrency.............................................................................................................................. 14
Table 3-1: Mapping between feature tags and service IDs...................................................................................... 50
Table 4-1: AMR narrowband and wideband bit rate................................................................................................64
Table 7-1: E911 service category............................................................................................................................153
Table 7-2: Transition of states on timer expiry.......................................................................................................163
Table B-1: UE behavior for dual-SIM L+L mode......................................................................................................168

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 7

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
Figures

Figure 2-1: Single SIM boot-up call flow.................................................................................................................. 16

Figure 2-2: Dual SIM dual standby boot-up call flow............................................................................................... 17
Figure 2-3: Transition to No-SIM call flow................................................................................................................ 18
Figure 2-4: SIM hot swap call flow........................................................................................................................... 19
Figure 2-5: Power down call flow.............................................................................................................................19
Figure 2-6: Wi-Fi off when UE in connected mode call flow.................................................................................... 20
Figure 2-7: Wi-Fi off when UE in Idle mode............................................................................................................. 21
Figure 2-8: Call flow when UE is in SRVCC call in one SUB and HO criteria met on other SUB................................ 22
Figure 3-1: Presence software architecture............................................................................................................. 30
Figure 3-2: Presence high-level call flow..................................................................................................................33
Figure 3-3: IMS registration and presence publication call flow.............................................................................. 34
Figure 3-4: Capability polling call flow..................................................................................................................... 36
Figure 3-5: Sequential capability polling call flow....................................................................................................38
Figure 3-6: Call flow for availability fetch and originate VoLTE or VT call.................................................................39
Figure 3-7: IMS reregistration and republication call flow....................................................................................... 41
Figure 3-8: Toggle VoLTE ON call flow...................................................................................................................... 42
Figure 3-9: Toggle VoLTE off call flow....................................................................................................................... 43
Figure 3-10: Toggle VT ON/OFF call flow..................................................................................................................44
Figure 3-11: Mobile data network on/off call flow.................................................................................................. 45
Figure 3-12: L2e and e2L iRAT transitions call flow.................................................................................................. 46
Figure 3-13: Airplane mode on call flow.................................................................................................................. 47
Figure 3-14: UE power off call flow.......................................................................................................................... 49
Figure 4-1: EPS network architecture...................................................................................................................... 51
Figure 4-2: IMS architecture.................................................................................................................................... 52

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 8

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Contents

Figure 4-3: High Level Media/Signaling block Diagram............................................................................................54

Figure 4-4: Data/Signalling Path...............................................................................................................................54
Figure 4-5: Handset architecture for VoLTE............................................................................................................. 55
Figure 4-6: High-level VoLTE call flow...................................................................................................................... 56
Figure 4-7: IMS registration call flow....................................................................................................................... 58
Figure 4-8: High-Level end-to-end VoLTE call – network-initiated QoS....................................................................60
Figure 4-9: Mobile-originated call setup call flow....................................................................................................63
Figure 4-10: Mobile-originated call setup (with precondition) call flow..................................................................67
Figure 4-11: Mobile-terminated call setup call flow................................................................................................ 71
Figure 4-12: Mobile-terminated call setup (with precondition) call flow................................................................ 75
Figure 4-13: Call termination (near side-initiated) call flow.................................................................................... 79
Figure 4-14: Call termination (far side-initiated) call flow....................................................................................... 80
Figure 4-15: Call hold call flow................................................................................................................................. 82
Figure 4-16: Call resume call flow............................................................................................................................ 84
Figure 4-17: Call add call flow.................................................................................................................................. 87
Figure 4-18: Call waiting call flow............................................................................................................................ 90
Figure 4-19: Call conferencing call flow................................................................................................................... 92
Figure 4-20: Call conference subscribe event package call flow.............................................................................. 97
Figure 4-21: DTMF call flow..................................................................................................................................... 98
Figure 4-22: Codec Configuration parameter........................................................................................................ 101
Figure 5-1: Network Architecture for UT interface................................................................................................ 104
Figure 5-2: UT PDN bring up call flow.................................................................................................................... 105
Figure 5-3: Activate call waiting call flow............................................................................................................... 106
Figure 5-4: Deactivate call waiting call flow........................................................................................................... 108
Figure 5-5: Activate call forwarding unconditional call flow.................................................................................. 110
Figure 5-6: Interrogate CFU setting call flow..........................................................................................................112
Figure 5-7: Deactivate CFU service and retain configuration.................................................................................113
Figure 5-8: Deactivate CFU service and erase target number................................................................................114
Figure 5-9: Reactivate CFU using existing configuration........................................................................................ 116
Figure 6-1: IWLAN to LTE handover during idle state call flow.............................................................................. 119
Figure 6-2: Call flow for handover during active call..............................................................................................122

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 9

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Contents

Figure 6-3: Filter ESP packet in WireShark............................................................................................................. 127

Figure 6-4: Decoding of ESP packet....................................................................................................................... 127
Figure 6-5: Wireshark packet content after decoding of ESP packet..................................................................... 129
Figure 7-1: E911 basic call flow.............................................................................................................................. 133
Figure 7-2: E911 over Wi-Fi call flow..................................................................................................................... 157

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 10

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
1 Introduction to IMS design and log analysis

1.1 Purpose
This document explains the call flows, design diagrams, and log snippets of LTE+LTE (L+L) IMS, and
VoLTE call scenarios, presence service, unstructured query (UT) interface and E911 service. The log
and call flows can be used to debug all modems other than 5G.

1.2 Conventions
Function declarations, function names, type declarations, attributes, and code samples appear in a
different font, for example, cp armcc armcpp.
Code variables appear in angle brackets, for example, <number>.
Commands to be entered appear in a different font, for example, copy a:*.* b:.

1.3 Technical assistance

For assistance or clarification on information in this document, submit a case to Qualcomm
Technologies, Inc. (QTI) at https://createpoint.qti.qualcomm.com/.
If you do not have access to the CDMATech Support website, register for access or send email to
[email protected].

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 11

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
2 L+L IMS architecture

The L+L architecture supports dual IMS stack. IMS stack per subscription (SUB) is identified with an
IMS instance ID, which is mapped to a SUB ID. Instance-ID-based design is present only within IMS
framework. External communication still occurs with SUB ID, for example, modem to application
processor.

L + L IMS supports the following device configurations:

■ Single SIM
■ 7+5
■ 7 + 7 (dual IMS stack)
Following are some of the advantages of L+L IMS:
■ IMS instances on each SUB can be independently created and destroyed based on various
conditions without impacting the state of IMS services on other SUBs.
■ Two MBNs can be loaded on the device to perform operations specific to each SUB/operator.
■ NVs are configurable per SUB.

2.1 Call restrictions in L+L IMS networks

The following list describes the call restriction scenarios in IMS L+L:
■ IMS is always ON/supported on both SUBs
■ When a call is active on one SUB, MO or MT calls get rejected on other SUB
■ CM waits for IMS call-end indication on one SUB before accepting a call on other SUB
■ IMS call end indication is sent only after MediaCodec (audio + video) is fully released
The following table lists the call restrictions on one SUB, when a CS/VoLTE/VoWiFi call is active on
other SUB.
Table 2-1 Call restrictions on SUB1, for active CS/VoLTE/VoWiFi call on SUB2

SUB1 SUB2

VoWi-Fi call active ■ HLOS blocks any MO voice call, including VoLTE, VoWi-Fi, circuit-switched (CS) call
■ IMS or CM rejects MT VoLTE calls
■ IMS or CM rejects MT VoWi-Fi calls
■ If WCDMA or 1X is active, MMCP ignores CS voice page, but handles CS SMS
pages normally.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 12

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Table 2-1 Call restrictions on SUB1, for active CS/VoLTE/VoWiFi call on SUB2 (cont.)

SUB1 SUB2
■ If GSM is active, all CS pages are ignored
■ If LTE is active, MMCP ignores CS pages, but handles PS pages normally.
■ If DO is active, PS pages are handled normally
CS/VoLTE call ■ HLOS blocks any MO voice call, including VoLTE/VoWiFi/CS call
active ■ IMS or CM rejects MT VoWi-Fi calls
■ MT pages on WCDMA/GSGM/1X/DO/LTE on SUB2 cannot be decoded (no lower
layer resource)

2.2 Call concurrencies in L+L IMS networks

Call concurrencies are situations when one SUB has an active operation and the other SUB also
receives an operation request. The following are the two types of concurrencies:
■ Voice concurrency
■ Data concurrency

2.2.1 Voice concurrency

The following table shows how the UE handles voice concurrency scenarios:
Table 2-2 IMS voice call concurrency handling scenarios

SUB1 status SUB2 event SUB2 action

Active call on Wi-Fi (VoWi-Fi) Receives IMS call (SIP INVITE) over Rejects call with 486 – busy here
Wi-Fi
Active call on Wi-Fi (VoWi-Fi) Receives IMS call (SIP INVITE) over Rejects call with 486 – busy here
LTE
Active call on Wi-Fi (VoWi-Fi) Receives SMS/MMS on either SUB1 SMS/MMS is accepted/received on
or SUB2 corresponding SUB
Active call on Wi-Fi (VoWi-Fi) Receives CSFB call over LTE on Drops CS page/call in LTE
either SUB1 or SUB2
Active call on Wi-Fi (VoWi-Fi) Receives CS call on GSM/WCDMA Drops CS page in GSM/WCDMA
on either SUB1 or SUB2
Active call on LTE (VoLTE) Receives IMS call (SIP INVITE) over Rejects call with 486 – busy here
Wi-Fi

2.2.2 Data concurrency

Packet switched (PS) data concurrency is supported for L+L. The following table shows how the UE
handles data call concurrency scenarios:
■ “Yes” indicates that the event is supported
■ “No” indicates that the event is not supported

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 13

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Table 2-3 Data call concurrency

SUB2 event
SUB1 event SMS over USSD over
SMS over IMS USSD over IMS UT (over IMS)
NAS NAS

SMS over NAS No No1 No Yes Yes

SMS over IMS No1 No1 No Yes Yes
USSD over NAS No No Yes Yes Yes
USSD over IMS Yes Yes Yes Yes Yes
UT (over IMS) Yes Yes Yes Yes Yes
1Retries
done by HLOS (MO case) and network (MT case) may help send (MO) or receive (MT) SMS on the
SUB that could not support concurrent SMS during initial attempt. Same behavior as Single-SIM devices.

2.3 Emergency call support

Emergency calls, also known as E911 calls, are supported on L+L IMS.
For a SUB that acquires limited service, IMS handles SIMless E911 calls. For this scenario, default
IR-92 MBN configuration is used for making an E911 call, if the SIM card is previously not inserted in
the slot.
Number of IMS instances in a No-SIM case depends on MMODE or PM giving indication to IMS about
how many stacks need to be brought up.

2.4 Override configuration changes per SUB in L+L IMS

The purpose of override configuration is to allow OEMs to test or try different values and eventually
raise a case so that QTI fixes the issue. It is not intended for commercial deployment on an end-user
device.
Override hard-coded configuration values per SUB using the following process:

1. IMS stacks read override configuration files when UIM starts or restarts (MCFG refresh case).
Override files are read per SUB, for example, overrideconfig (for SUB0) and overrideconfig_01 (for
SUB1).
□ IMS stack associated with sub0 always reads override values from/efsprofiles/
overideconfig.
□ IMS stack associated with sub1 always reads override values from/efsprofiles/
overideconfig_Subscription01.
If OEMs want to use MBN instead of EFS override (recommended method), OEMs must generate
SUB-specific MBNs that accommodate the respective override configuration.
2. EFS override file is read by each instance of IMS when that instance is created.
3. For an L+L set-up, each stack can move up or go down independently of the other IMS stack.
4. OEMs must provide the override file with its correct name, preferred values, and appropriate
timing.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 14

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

General notes regarding hard coded values on MBN

■ Hard coded configuration values are part of QTI source code.
■ If QTI software uses incorrect hard coded values in its software, OEMs should report bugs or raise
a case with QTI at https://createpoint.qti.qualcomm.com/.

2.4.1 Impact of IMS registration on a SUB

The functional impact of IMS registration on each SUB is as follows:
■ IMS can be initialized for SUBs that have LTE capability.
■ Maintenance of IMS packet data network (PDN) context and registration on both SUBs is possible
with L+L. PDN throttling and registration retry procedures are also maintained on both SUBs.
Using the IMS PDN context, P-CSCF discovery and P-CSCF list management are maintained per
SUB.
■ The SUB that is on voice call always has highest priority for the lower layer resources like RF, and
access stratum procedures. If one SUB is on call, the registration procedure on the other SUB is
stalled.
■ Registration retry procedure occurs on the same P-CSCF when the lower layer resources are
available.
■ Once the registration procedure starts on the SUB, it keeps the lower layer resources for a specific
time till critical session initiation protocol (SIP) signaling is completed.
■ IP type profile impact for dual SUB L+L scenario is as follows:
□ IPv4 and IPv6 profiles must be created for each individual SUB.
□ IP type manager to cater IP fallback requirements on both the SUBs.
□ In total, four profiles can be created and deleted after a successful case.

2.5 Call flows for L+L IMS architecture

The following call flows describe various processes that the UE performs in the L+L architecture:
■ Single SIM boot-up
■ Dual SIM dual standby boot-up
■ Transition to no-SIM (DSDS to DSSS to No-SIM)
■ SIM hot swap
■ Power down
■ Wi-Fi gets turned off when the UE is in Connected mode
■ Wi-Fi gets turned off when the UE is in Idle mode
■ UE is in SRVCC call on one SUB and HO criteria is met on other SUB

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 15

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Single SIM boot-up

Figure 2-1 Single SIM boot-up call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 16

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Dual SIM dual standby boot-up

Figure 2-2 Dual SIM dual standby boot-up call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 17

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Transition to no-SIM (DSDS to DSSS to No-SIM)

Figure 2-3 Transition to No-SIM call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 18

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

SIM hot swap

Figure 2-4 SIM hot swap call flow

Power down

Figure 2-5 Power down call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 19

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Wi-Fi gets turned off when the UE is in Connected mode

Figure 2-6 Wi-Fi off when UE in connected mode call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 20

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Wi-Fi gets turned off when the UE is in Idle mode

Figure 2-7 Wi-Fi off when UE in Idle mode

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 21

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

UE is in SRVCC call on one SUB and HO criteria is met on other SUB

Figure 2-8 Call flow when UE is in SRVCC call in one SUB and HO criteria met on other SUB

2.6 Log analysis for L+L IMS call scenarios

The following log analysis can be used to debug various L+L call scenarios after boot-up.

2.6.1 Log messages during IMS registration on both SUBs

Following are the log messages generated during the process of IMS registration on both SUBs:

1. IMS registration occurs on SUB2 first

a. SUB1 (Instance-1) and SUB2 (Instance-2) are initialized upon boot-up. Note the SUB IDs in
the following log messages below.
01:14:10.006 ims_agent.cpp 01237 InstanceACK: Init State --> 1 |
InstanceID --> 1 Sub-ID:1
01:14:10.011 ims_agent.cpp 01237 InstanceACK: Init State --> 1 |
InstanceID --> 2 Sub-ID:2
b. DS indicates LTE RAT available on SUB2
01:14:15.012 qpDcm.c 9245 H qpDcmGetServingSystem: DS Sys Info
pref_tech=0, so_mask=1000, pref_rat_value=3 Sub-ID:2
c. LTE attach procedure occurs on SUB2 first
01:14:15.254 [35] 0xB0EC LTE NAS EMM Plain OTA Incoming Message --
Attach accept Msg

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 22

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Subscription ID = 2
IMSVoPS = 1 (0x1) (IMS Vo PS Session in S1 Mode supported)
01:14:15.281 [75] 0xB0ED LTE NAS EMM Plain OTA Outgoing Message --
Attach complete Msg
Subscription ID = 2
:
01:14:16.020 PDPManager.cpp 1223 H EventChangeRat -
ServiceOnRatMask = 0x0080640e, new RAT mask = 0x00000400: Sub-ID:2
01:14:16.020 PDPManager.cpp 1224 H EventChangeRat - New RAT is
10 and is valid: 1 Sub-ID:2
d. PDP session is established
01:14:16.761 qpDcm.c 4259 H qpDcmSendMsgrEv:
eDCM_MSGR_RESP_VOLTE_STATE_INFO_CMD | Volte State --> 1 Sub-ID:2
01:14:16.024 qpDcm.c 8871 M
IMS_APP#>>#DPL_M#0#qpDcmEstablishPDPConnection Sub-ID:2
01:14:16.030 qpDcm.c 9008 H DPL_M#$
$#0#qpDcmEstablishPDPConnection - DS_EWOULDBLOCK on dsnet_start Sub-
ID:2
:
01:14:16.034 [9D] 0xB0E3 LTE NAS ESM Plain OTA Outgoing Message --
PDN connectivity request Msg
Subscription ID = 2
01:14:16.086 [28] 0xB0E2 LTE NAS ESM Plain OTA Incoming Message --
Activate default EPS bearer context request Msg
Subscription ID = 2
01:14:16.091 [FB] 0xB0E3 LTE NAS ESM Plain OTA Outgoing Message --
Activate default EPS bearer context accept Msg
Subscription ID = 2
e. IMS registration is triggered over LTE on SUB2 with IPSec established

NOTE SIP packet does not log sub ID

01:14:17.713 [35] 0x156E IMS SIP Message -- IMS_SIP_REGISTER/

INFORMAL_RESPONSE
Direction = UE_TO_NETWORK
Message ID = IMS_SIP_REGISTER
Response Code = INFORMAL_RESPONSE (0)
:
01:14:17.801 [2F] 0x156E IMS SIP Message -- IMS_SIP_REGISTER/
UNAUTHORIZED
Direction = NETWORK_TO_UE
Message ID = IMS_SIP_REGISTER
Response Code = UNAUTHORIZED (401)
:
01:14:17.964 [85] 0x156E IMS SIP Message -- IMS_SIP_REGISTER/
INFORMAL_RESPONSE
Direction = UE_TO_NETWORK
Message ID = IMS_SIP_REGISTER

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 23

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

Response Code = INFORMAL_RESPONSE (0)

P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-
id-3gpp=310000001013F801
:
01:14:18.028 [C4] 0x156E IMS SIP Message -- IMS_SIP_REGISTER/OK
Direction = NETWORK_TO_UE
Message ID = IMS_SIP_REGISTER
Response Code = OK (200)
:
01:14:17.713 sipConnection.cpp 3993 H EVENT_SIP_REQUEST_SEND:
REGISTER sip:qti-wlan-iotv4v6.com SIP/2.0From: <sip:8989515836@qti-wlan-
iotv Sub-ID:2
01:14:17.800 qimfsiplib.cpp 4916 H EVENT_SIP_MESSAGE_RECV:SIP/
2.0 401 UnauthorizedVia: SIP/2.0/TCP
[2002:c023:9c17:5758:1:3:cd5e:14 Sub-ID:2
01:14:17.916 secipsiface.c 1632 H IPSEC SA ESTABLISHED
:
01:14:17.964 sipConnection.cpp 3993 H EVENT_SIP_REQUEST_SEND:
REGISTER sip:qti-wlan-iotv4v6.com SIP/2.0From: <sip:8989515836@qti-wlan-
iotv Sub-ID:2
01:14:18.026 qimfsiplib.cpp 4916 H EVENT_SIP_MESSAGE_RECV:SIP/2.0
200 OKVia: SIP/2.0/TCP [2002:c023:9c17:5758:1:3:cd5e:146d]:41933;
Sub-ID:2

2. IMS registration now starts on SUB1

a. DS indicates LTE radio access technology (RAT) available on SUB1
01:14:29.112 qpDcm.c 9245 H qpDcmGetServingSystem: DS Sys Info
pref_tech=0, so_mask=1000, pref_rat_value=3 Sub-ID:1
b. LTE attach procedure occurs on SUB1.
01:14:29.046 [5C] 0xB0EC LTE NAS EMM Plain OTA Incoming Message --
Attach accept Msg
Subscription ID = 1
IMSVoPS = 1 (0x1) (IMS Vo PS Session in S1 mode supported)
01:14:29.071 [B2] 0xB0ED LTE NAS EMM Plain OTA Outgoing Message --
Attach complete Msg
Subscription ID = 1
01:14:31.117 PDPManager.cpp 1223 H EventChangeRat -
ServiceOnRatMask = 0x0080640e, new RAT mask = 0x00000400: Sub-
ID:1
01:14:31.117 PDPManager.cpp 1224 H EventChangeRat - New RAT is 10
and is valid: 1 Sub-ID:1
01:14:31.846 qipcall.c 1850 H qipcall_load_instance: loaded
Instance 1 Sub-ID:1
c. PDP session is established on SUB1
01:14:31.849 qpDcm.c 4259 H qpDcmSendMsgrEv:
eDCM_MSGR_RESP_VOLTE_STATE_INFO_CMD | Volte State --> 1 Sub-ID:1

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 24

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

01:14:31.122 qpDcm.c 8871 M

IMS_APP#>>#DPL_M#0#qpDcmEstablishPDPConnection Sub-ID:1
01:14:31.129 qpDcm.c 9008 H DPL_M#$$#0#qpDcmEstablishPDPConnection
- DS_EWOULDBLOCK on dsnet_start Sub-ID:1
:
01:14:31.133 [70] 0xB0E3 LTE NAS ESM Plain OTA Outgoing Message --
PDN connectivity request Msg
Subscription ID = 1
01:14:31.202 [DD] 0xB0E2 LTE NAS ESM Plain OTA Incoming Message --
Activate default EPS bearer context request Msg
Subscription ID = 1
01:14:31.208 [7C] 0xB0E3 LTE NAS ESM Plain OTA Outgoing Message --
Activate default EPS bearer context accept Msg
Subscription ID = 1
d. IMS registration is triggered over LTE on SUB1 with IPSec established (Note: SIP packet does
not log Sub ID)
01:14:32.805 [FB] 0x156E IMS SIP Message -- IMS_SIP_REGISTER/
INFORMAL_RESPONSE
Direction = UE_TO_NETWORK
Message ID = IMS_SIP_REGISTER
Response Code = INFORMAL_RESPONSE (0)
:
01:14:32.914 [35] 0x156E IMS SIP Message -- IMS_SIP_REGISTER/
UNAUTHORIZED
Direction = NETWORK_TO_UE
Message ID = IMS_SIP_REGISTER
Response Code = UNAUTHORIZED (401)
:
01:14:33.088 [6C] 0x156E IMS SIP Message -- IMS_SIP_REGISTER/
INFORMAL_RESPONSE
Direction = UE_TO_NETWORK
Message ID = IMS_SIP_REGISTER
Response Code = INFORMAL_RESPONSE (0)
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-
id-3gpp=310000001013F801
:
01:14:33.138 [31] 0x156E IMS SIP Message -- IMS_SIP_REGISTER/OK
Direction = NETWORK_TO_UE
Message ID = IMS_SIP_REGISTER
Response Code = OK (200)
:
01:14:32.805 sipConnection.cpp 3993 H EVENT_SIP_REQUEST_SEND:
REGISTER sip:ims1.qualcomm.com SIP/2.0From: <sip:
[email protected]. Sub-ID:1
01:14:32.913 qimfsiplib.cpp 4916 H EVENT_SIP_MESSAGE_RECV:SIP/2.0
401 UnauthorizedVia: SIP/2.0/TCP [2002:c023:9c17:5708:1:1:cd5e:4f
Sub-ID:1

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 25

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

01:14:33.023 secipsiface.c 1632 H IPSEC SA ESTABLISHED

01:14:33.088 sipConnection.cpp 3993 H EVENT_SIP_REQUEST_SEND:
REGISTER sip:ims1.qualcomm.com SIP/2.0From: <sip:
[email protected]. Sub-ID:1
01:14:33.135 qimfsiplib.cpp 4916 H EVENT_SIP_MESSAGE_RECV:SIP/2.0
200 OKVia: SIP/2.0/TCP [2002:c023:9c17:5708:1:1:cd5e:4f7a]:44395;
Sub-ID:1

2.6.2 Log messages during UT call flow on SUB1

Following are the log messages generated during the UT call flow on SUB1:
1. IMS handles the supplementary request from the multimode layer
23:09:56.561,IMSSupplementaryService.cpp,1386,H,StoreCMParams ss_code 17
ss_Ref 1 Operation_Type 2,Sub-ID:0,
23:09:56.561,IMSSupplementaryService.cpp,6326,H,IMSSupplementaryService::Ge
tPAURI,Sub-ID:0,
23:09:56.562,IMSSupplementaryService.cpp,1401,H,ProcessSSRequest req type
2 bs code- 0 codetype - 0,Sub-ID:0,

2. XML is initialized for triggering the supplementary service request

23:09:56.562,IMSSupplementaryService.cpp,2342,M,HandleBootUpXMLInitializati
on | Entered,Sub-ID:0,

3. Before triggering the HTTP request, the lower layer resources are acquired by the TRM
23:09:56.575,qpDplTRM.c,58,H,GetMappingSysProcType - 57:,Sub-ID:0,
23:09:56.575,qpDplTRM.c,281,H,IMS acquires TRM priority[57],Sub-ID:0,

4. All the subsequent HTTP connection and GBA procedure are triggered as follows:
23:09:56.575,imsserviceconfigGBA.cpp,1130,M,IMSServiceConfigGBA::Send
HTTP,Sub-ID:0,
23:09:56.575,QimfHttp.cpp,258,M,HttpConnection::HttpConnection | this:
40deb2a0,Sub-ID:0,
23:09:56.648,QimfHttp.cpp,280,M,HttpConnection::~HttpConnection | this:
40deb2a0 m_bTCPConnected:1 m_bTLSConnected:0,Sub-
ID:0,23:09:56.679,QimfHttp.cpp,1121,H,HttpConnection::HttpsSendData| HTTP
message :PUT /simservs.ngn.etsi.org/users/sip:[email protected],Sub-ID:0

5. Server responds with 200 OK message

23:09:56.733,QimfHttp.cpp,2087,H,HttpConnection::ProcessMessage|
Response:HTTP/1.1 200 OKConnection: Keep-AliveContent-Length: 0E,Sub-ID:0,

6. IMS releases the lower layer resources

23:09:56.735,qpDplTRM.c,339,M,qpDplReleaseTRMPriority - application
removed,Sub-ID:0,
23:09:56.735,qpDplTRM.c,351,M,qpDplReleaseTRMPriority - current IMS
priority is QPE_SYS_PROC_TYPE_NONE,Sub-ID:0,

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 26

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

7. Supplementary service indication is sent to multimode layer

23:09:56.735,IMSSupplementaryService.cpp,3845,H,SendIndicationToCM,Sub-
ID:0, :23:09:56.736,IMSSupplementaryServi
ce.cpp,3877,H,SendIndicationToCM sending sups indication type 0,Sub-
ID:0,

2.6.3 Log messages during LTE to IWLAN handover

Following are the log messages generated during the process of LTE to IWLAN handover:
1. Registration is triggered over LTE. RAT =10 corresponds to LTE on SUB1.
23:53:35.602,PDPManager.cpp,1212,H,EventChangeRat -Current RAT 0 New Rat
10 ProceedIfRatsSame 1,Sub-ID:1,
23:53:35.602,PDPManager.cpp,1238,H,EventChangeRat - New RAT is 10 and is
valid: 1,Sub-ID:1,
23:53:35.605,RegisterManager.cpp,5161,M,CheckRegistrationNeeded:
RegType[0],Sub-ID:1,

2. Registration module handles PDN throttling time per SUB.

23:53:35.605,PDPRATHandlerVoLTE.cpp,4997,H,UpdatePDNThrottlingTimers -
Entry,,Sub-ID:1,

3. IP type manager module manages the IP type to be used for this SUB.
23:53:35.606,QpPDNIPTypeManager.cpp,339,H,qpPDNIPTypeEstablishPDPConnection
| This Instance Value[3], PrimaryInUse[0], SecondaryInUse[0],Sub-ID:1,
23:53:35.606,qpDcm.c,9200,H,qpDcmEstablishPDPConnection - 3GPP
ProfileNumber --> 2 | 3GPP2 ProfileNumber --> -1 | IPType --> 1,Sub-ID:1,

4. PDP gets activated based on the PDP activation request.

:23:53:36.701,PDPRATHandlerVoLTE.cpp,1304,H,EventPdpActivated raise
QPE_RM_PDP_ACTIVATED_EV RegType[0],Sub-ID:1,

5. PDP activation is successful and indicated to application processor and other clients for knowing
the current activation status.
:23:53:36.701,PDPRATHandlerVoLTE.cpp,1176,H,GetClientIndication Current
Rat 10,Sub-ID:1,
:23:53:36.701,PDPRATHandlerVoLTE,1253,H,GetClientIndication Gen. Reg
Handle#PDP_SUCCESS_STATUS#10#1#1#0#8# ,Sub-ID:1,

6. SIP registration procedure over LTE is initiated.

23:53:37.418,EVENT_SIP_REG_REQ_SENT_EVENT,RAT Type = DCM_RAT_LTE,
Registration Type = IMS_REG_TYPE_NA, Response Status Code = Request,,

7. SIP registration is successful and IMS is registered.

23:53:37.537,qpSipUtils.cpp,3322,H,EVENT_SIP_RESPONSE_SEND: SIP/2.0 200
OK,Sub-ID:1,
23:53:43.528,qpSipRegisterService.cpp,1786,H,EVENT_SIP_REGISTER_END:Respons
e RAT: 10,Sub-ID:1,

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 27

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual L+L IMS architecture

8. ICS module that determines whether handover to Wi-Fi is possible based on the quality
measurement.
23:54:53.759,ICSCore.cpp,6857,H,ICSCore::is_handover_possible_based_on_qual
ity: LTE -> WIFI | HO possible 1,Sub-ID:1,
23:54:53.759,ICSCore.cpp,4087,M,ICSCore::is_wwan_iwlan_handover_required:
current system = 1, HO possible = 1, pref system 2 ,Sub-ID:1,

9. Handover criteria is entered and indicated to UI for the successful handover event.
23:54:57.509,ICSCore.cpp,5524,H,ICSCore::log_handover_criteria:
iHandOverCriteria Entered,Sub-ID:1,
23:54:57.509,ICSCore.cpp,8095,H,ICSCore::process_handover_success_event :
Indicate to UI, SRAT 2, TRAT 1 ,Sub-ID:1,

10. ICS module querying policy manager for all the preferred IMS RAT, voice call preference mode,
and WFC status.
23:54:57.511,ICSCore.cpp,1399,H,ICSCore::get_preferred_rat_for_ims_pdn: PM
returned Pref RAT 6, ims pref RAT 20 ,Sub-ID:1,
23:54:57.511,ICSCore.cpp,1658,H,ICSCore::get_preferred_rat_for_ims_pdn:
pref_rat 20, Voice pref 1 , WFC status 1,Sub-ID:1,

11. Based on the handover measurements, IMS registration over Wi-Fi is triggered. RAT = 6 indicates
WLAN RAT.
:23:54:57.512,PDPManager.cpp,1212,H,EventChangeRat -Current RAT 10 New Rat
6 ProceedIfRatsSame 0,Sub-ID:1,
:23:54:57.512,PDPManager.cpp,1237,H,EventChangeRat - ServiceOnRatMask =
0x00000440, new RAT mask = 0x00000040: ,Sub-ID:1,
:23:54:57.512,PDPManager.cpp,1238,H,EventChangeRat - New RAT is 6 and is
valid: 1,Sub-ID:1,

12. PDP activation completed.

23:54:57.513,qpDcm.c,3189,M,qpDcmCreateProfile - FOUND at i[1] j[2]
iPDPID[8],Sub-ID:1,
23:54:57.513,qpDcm.c,3209,M,DPL_M#$$#0#qpDcmCreateProfile - DS Handle[27]
PDP_ID[8] REF_CNT[3] exist,Sub-ID:1,

13. SIP registration is successful.

23:54:57.519,sipConnection.cpp,3199,H,EVENT_SIP_REG_REQ_SENT: 43 Code = 0
RAT = 6,Sub-ID:1,
23:54:57.571,qpSipUtils.cpp,3322,H,EVENT_SIP_RESPONSE_SEND: SIP/2.0 200
OK,Sub-ID:1,
23:55:03.564,qpSipRegisterService.cpp,1786,H,EVENT_SIP_REGISTER_END:Respons
e RAT: 6,Sub-ID:1,

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 28

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
3 RCS presence service

Presence service is a network service which accepts, stores and distributes information about the
online availability of the user. The presence service is accessed before a call is placed. Following are
the functions of the presence service:
■ Presence publication: Near-end user shares its presence with far-end peers through the IMS core
network (CN)
■ Presence retrieval or capability polling: Near-end user retrieves far-end peers’ presence from the
IMS CN

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 29

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.1 Presence service software architecture

Following is the presence architecture on the software side:

Figure 3-1 Presence software architecture

Following are the names of the libraries that handle the presence architecture:
■ Enhanced address book (EAB)
□ PresenceApp.apk – sample EAB application for reference. See EAB Reference Application
(80-NK072-1) for more information.
■ Java/ Android interface definition language (AIDL)
□ RCSBootstraputil.apk – AIDL service for Rich communication services (RCS) (starts at power-
on)
□ RcsImsBootstraputil.apk – AIDL service for RCS IMS settings (starts at power-on)

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 30

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

□ rcsservice.jar – RCS Java classes

□ rcsimssettings.jar – RCS IMS settings Java classes

■ Java native interface (JNI)

□ lib-rcsjni.so – interface between Java space and C space for RCS
□ lib-rcsimssjni.so – interface between Java space and C space for RCS IMS settings

■ C
□ lib-imsrcs.so – native RCS
□ lib-imss.so – native RCS IMS setting service

3.2 Presence publication responsibilities

QTI is responsible for the following:
■ Providing PUBLISH APIs through RCS AIDL API as per operator policies.
■ Trigger the Un-PUBLISH message when the value of the expires field is 0. This message is sent
by the IMS presence enabler for the following during IMS deregistration with the network:
□ Device shutdown
□ Airplane mode on

■ IMS presence enabler performs a periodic republish based on expires configured in NV 67314,
iPublishTimer
□ Network may change the expires value in 200 OK (PUBLISH)
■ IMS presence enabler performs a PUBLISH retry upon failure as per operator policies.
OEM is responsible for the following:
■ Using the IQPresListener_PublishTriggering() method for listening to the PUBLISH trigger
indication and performing an initial PUBLISH after successful IMS registration with the network
■ Checking if VT or mobile data is enabled or disabled per user action; then, the OEM should
perform an initial PUBLISH
■ Presence parameters, such as the SourceThrottlePublish PST parameter, can be written using
RCS IMS settings APIs, which write to NV 67314.
■ Initiating a PUBLISH request using the QPresService_PublishMyCap() method of RCS AIDL API:
The QTI IMS stack generates a PUBLISH request and sends it OTA; the network response is
provided by an asynchronous indication.
■ Listening to the network response using the IQPresListener_SipResponseReceived() method of
RCS AIDL API. See RCS 5.1 User Capability Exchange AIDL API Interface Specification (80-
NE170-2) for more information about QTI APIs.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 31

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.3 Presence retrieval or capability polling responsibilities

QTI is responsible for the following:
■ Providing SUBSCRIBE APIs from the RCS AIDL API specification.
□ QPresService_GetContactListCap() for capability polling
□ QPresService_GetContactCap() for availability fetch
■ Providing an indication of an incoming NOTIFY using the IQPresListener_ListCapInfoReceived()
method of the RCS AIDL API specification.
OEM is responsible for the following:
■ Periodic capability discovery and capability polling, and availability fetch caching
■ Capability polling triggered by NAB sync and contact address book updates made by the end user
■ Capability poll interval for performing periodic capability polling through NV 67314,
iCapabilityPollInterval, iCapabilityPollListSubscriptionExpiryTimer, and
iMaxNumberofEntriesInRequest; these parameters can be retrieved using the RCS IMS Settings
API.
■ Capability polling retry, since the IMS presence enabler will not know if it is a “scheduled” polling or
a “contact changed” trigger; the OEM must retry the SUBSCRIBE as per operator policies.
■ Reading NV 67314, iAvailabilityCacheExpiration, using RCS IMS setting APIs.
■ Initiating the SUBSCRIBE request using SUBSCRIBE APIs provided by the RCS AIDL API spec:
The QTI IMS stack generates a SUBCRIBE request and sends it OTA; the network response is
provided by an asynchronous indication
□ QPresService_GetContactListCap() for capability polling
□ QPresService_GetContactCap() for availability fetch
■ Listening to the network response using the IQPresListener_SipResponseReceived() method of
the RCS AIDL API. See RCS 5.1 User Capability Exchange AIDL API Interface Specification (80-
NE170-2) for more information about the API.
■ Sending capability polling requests sequentially, rather than in parallel
■ Start a timer after receiving NOTIFY message with Active state and send the next capability
polling request after receiving a terminated subscription state or upon timer expiration

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 32

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.4 Presence enabler call flows and log analysis

Following is the high-level call flow for presence services:

Figure 3-2 Presence high-level call flow

The steps of the call flow are described as follows:
1. IMS registration with the network is performed. QTI IMS performs the IMS PDN establishment and
IMS registration procedure. OEM must listen for a publish trigger indication, which is sent after
IMS registration with the network is successful.
2. OEM must perform the presence publication after receiving the publish trigger indication.
3. OEM must perform periodic capability polling and update the EAB accordingly.
4. OEM must perform availability fetch when a contact that is capable of VoLTE and/or VT is selected
in the EAB. If the far-end peer is available, VoLTE or VT calls can be originated to them. For QTI
APIs, see RCS 5.1 User Capability Exchange AIDL API Interface Specification (80-NE170-2).

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 33

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.4.1 IMS registration and presence publication call flow and log messages
The IMS registration and presence publication call flow and log messages are as follows:

Figure 3-3 IMS registration and presence publication call flow

1. IMS registration with the network is completed
IMS PRESENCE/High 00:29:23.057 [IMS_AP] IMSPresenceEnabler.cpp 03671 |
3671 | 2093 | Notify PRES Listener SvcAvail[0x5d9709e0]

2. Publish trigger indication is sent

IMS PRESENCE/High 00:29:23.060 [IMS_AP] IMSPresenceEnabler.cpp 03782 |
3782 | 2093 |Notify PRES Listener PublishTriggerInd[0x5d9709e0]

3. The OEM UI checks if VT is enabled

09-17 17:29:22.952 D/PRESENCE_UI( 3034): isVt_calling_enabled_valid true
IMS UNKNOWN/High 00:29:23.086 [IMS_AP] QPresService.cpp 00187 | 187 |
2062 |<RCS SVC CTX> QPresService_PublishMyCap [0x5678]
IMS UNKNOWN/High 00:29:23.086 [IMS_AP] QPresService.cpp 00199 | 199 |

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 34

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

2062 |<RCS SVC CTX> RCS capability bIPVoiceSupported: 1

IMS UNKNOWN/High 00:29:23.086 [IMS_AP] QPresService.cpp 00200 | 200 |
2062 |<RCS SVC CTX> RCS capability bIPVideoSupported: 1
IMS SIP/High 00:29:23.183 [IMS_AP] sipConnection.cpp 03376 | 3376 |
2093 |Sent SIP Message:PUBLISH sip:[email protected] SIP/2.0
IMS PRESENCE/High 00:29:23.187 [IMS_AP] IMSPresenceEnabler.cpp 03719 |
3719 | 2093 |NotifyListener_CmdStatus: Cmd ID = [0]
IMS PRESENCE/High 00:29:23.187 [IMS_AP] IMSPresenceEnabler.cpp 03725 |
3725 | 2093 | Notify PRES Listener CmdStatus[0x5d9709e0]
IMS SIP/Error 00:29:23.426 [IMS_AP] qimfsiplib.cpp 01451 | 1451 | 2093
|QimfSipActiveObj::ProcessMessage | Received Message is SIP/2.0 200 OK
IMS SIP/High 00:29:23.433 [IMS_AP] sipConnection.cpp 04551 | 4551 |
2093 |SipConnection::qpSipAddHdrValueinListHead | Added the value
779661273 PUBLISH
IMS PRESENCE/High00:29:23.437 [IMS_AP] IMSPresenceEnabler.cpp 01302 |
1302 | 2093 |imspSipResponseHandler | sipResponseCode [0] statusCode [200]

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 35

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.4.2 Capability polling call flows and log messages

The capability polling call flows and log messages are as follows:

Figure 3-4 Capability polling call flow

1. Send SUBSCRIBE to retrieve the capabilities of far-end peers.
IMS UNKNOWN/High00:32:34.440 [IMS_AP] QPresService.cpp 00284 | 284 |
3235 |<RCS SVC CTX> QPresService_GetContactListCap [0x5678]
IMS UNKNOWN/High00:32:34.440 [IMS_AP] QPresService.cpp 00295 | 295 |
3235 |QPresService::QPresService_GetContactListCap: Subscription list
size: [1]
IMS UNKNOWN/High00:32:34.443 [IMS_AP] QPresService.cpp 00303 | 303 |
3235 |QPresService::QPresService_GetContactListCap User: [tel:4253333333]
IMS SIP/High 00:32:34.587 [IMS_AP] sipConnection.cpp 03376 | 3376 |
2093 |Sent SIP Message:SUBSCRIBE sip:[email protected];pres-
IMS PRESENCE/High00:32:34.595 [IMS_AP] IMSPresenceEnabler.cpp 03719 |
3719 | 2093 |NotifyListener_CmdStatus: Cmd ID = [2]
IMS PRESENCE/High00:32:34.595 [IMS_AP] IMSPresenceEnabler.cpp 03725 |

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 36

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3725 | 2093 | Notify PRES Listener CmdStatus[0x5d9709e0]

IMS SIP/Error 00:32:34.652 [IMS_AP] qimfsiplib.cpp 01451 | 1451 | 2093 |
QimfSipActiveObj::ProcessMessage | Received Message is SIP/2.0 200 OK
IMS SIP/High 00:32:34.653 [IMS_AP] sipConnection.cpp 04267 | 4267 |
2093 |SipConnection::qpSipAddHdrValueinListTail | Added the value
779852530 SUBSCRIBE
IMS PRESENCE/High00:32:34.660 [IMS_AP] IMSPresenceEnabler.cpp 01302 |
1302 | 2093 |imspSipResponseHandler | sipResponseCode [6] statusCode [200]

2. Receive a NOTIFY message with the capabilities of far-end peers.

IMS SIP/Error 00:32:34.673 [IMS_AP] qimfsiplib.cpp 01451 | 1451 | 2093 |
QimfSipActiveObj::ProcessMessage | Received Message is NOTIFY
IMS PRESENCE/High00:32:34.705 [IMS_AP] IMSPresenceEnabler.cpp 03870 |
3870 | 2093 |IMSPresenceEnabler::NotifyListener_ContactListCapInfoReceived
PRES Listener ContactListCapInfoReceivedFn[0x5d64901d]
IMS SIP/High 00:32:34.703 [IMS_AP] sipConnection.cpp 03376 | 3376 |
2093 |Sent SIP Message:SIP/2.0 200 OK

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 37

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.4.3 Sequential capability polling call flows and log messages

The sequential capability polling call flows and log messages are as follows:

Figure 3-5 Sequential capability polling call flow

Multiple capability polling requests are sent for a list of contacts that is greater than the maximum
number of contacts supported in a single capability polling request. Each capability polling request
must be sent sequentially.
1. The OEM must listen for the NOTIFY message with the active state and start a timer equal to the
notify expiration plus SIP timer T1.
2. The OEM must listen for the NOTIFY message with the Terminated state.
The next capability polling request may be sent only after the timer from step 1 in Figure 3-4 expires or
step 2 in Figure 3-5, notify with terminated state, is received.
TheSIP timer T1 value can be retrieved from the modem by using the QMI IMSS API; see the relevant
QMI spec document based on the modemfor more information. For example, the QMI spec document
for Hercules is QMI IMSS 1.59 for MPSS.HE.1.0, QMI IMS Settings Svc Spec (80-NV701-32).

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 38

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.4.4 Availability fetch and originate VoLTE or VT call call flows and log messages
The availability fetch and originate VoLTE or VT call flows and log messages are as follows:

Figure 3-6 Call flow for availability fetch and originate VoLTE or VT call
1. Send SUBSCRIBE message to retrieve the availability of far-end peer.
IMS SIP/High 00:35:36.998 [IMS_AP] sipConnection.cpp 03376 | 3376 |
2093 |Sent SIP Message:SUBSCRIBE sip:[email protected]
IMS PRESENCE/High00:35:37.000 [IMS_AP] IMSPresenceEnabler.cpp 03719 |
3719 | 2093 |NotifyListener_CmdStatus: Cmd ID = [1]
IMS PRESENCE/High00:35:37.000 [IMS_AP] IMSPresenceEnabler.cpp 03725 |
3725 | 2093 | Notify PRES Listener CmdStatus[0x5d9709e0]
IMS SIP/Error 00:35:37.068 [IMS_AP] qimfsiplib.cpp 01451 | 1451 |
2093 |QimfSipActiveObj::ProcessMessage | Received Message is SIP/2.0 200 OK
IMS PRESENCE/High00:35:37.107 [IMS_AP] IMSPresenceEnabler.cpp 01302 |
1302 | 2093 |imspSipResponseHandler | sipResponseCode [6] statusCode [200]

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 39

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

2. Receive NOTIFY message with the availability of far-end peer.

IMS SIP/Error 00:35:37.131 [IMS_AP] qimfsiplib.cpp 01451 | 1451 |
2093 |QimfSipActiveObj::ProcessMessage | Received Message is NOTIFY
IMS PRESENCE/High00:35:37.175 [IMS_AP] IMSPresenceXmlParser.cpp 00263 |
263 | 2093 |IMSPresenceXmlParser::parseTuple: Service ID =
org.3gpp.urn:urn-7:3gpp-service.ims.icsi.mmtel
IMS PRESENCE/High00:35:37.175 [IMS_AP] IMSPresenceXmlParser.cpp 00264 |
264 | 2093 |IMSPresenceXmlParser::parseTuple: Description = VoLTE Voice
and Video Service
IMS PRESENCE/High00:35:37.175 [IMS_AP] IMSPresenceXmlParser.cpp 00277 |
277 | 2093 |IMSPresenceXmlParser::parseTuple: Audio is enabled
IMS PRESENCE/High00:35:37.175 [IMS_AP] IMSPresenceXmlParser.cpp 00282 |
282 | 2093 |IMSPresenceXmlParser::parseTuple: Video is enabled
IMS PRESENCE/High00:35:37.175 [IMS_AP] IMSPresenceXmlParser.cpp 00324 |
324 | 2093 |IMSPresenceXmlParser::parseTuple: Contact URI =
sip:[email protected]
IMS SIP/High 00:35:37.188 [IMS_AP] sipConnection.cpp 03376 | 3376 |
2093 |Sent SIP Message:SIP/2.0 200 OK
IMS PRESENCE/High00:35:37.190 [IMS_AP] IMSPresenceEnabler.cpp 02938 |
2938 | 2093 |Send ContactCapInfoReceived() with 5 tuple info
IMS PRESENCE/High00:35:37.190 [IMS_AP] IMSPresenceEnabler.cpp 03823 |
3823 | 2093 | Notify PRES Listener ContactCapInfoReceived[0x5d9709e0]

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 40

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.4.5 IMS reregistration and republication call flows and log messages
The modem periodically performs IMS reregistration and IMS republication with IMS CN. There is no
OEM responsibility.

Figure 3-7 IMS reregistration and republication call flow

NOTE Capability polling and Availability Fetch were removed from this call flow for simplicity.
IMS registration and publication expiry are handled by separate and distinct timers

1. The periodic re-REGISTER timer fires.

IMS/High 16:29:12.560 qpRegisterService.cpp 04113
RegisterService::qpProcessTimerExpireMsg | Timer fired to ReReg

2. The periodic re-PUBLISH timer fires.

09-20 10:38:21.895 D/Diag_Lib( 2019): [IMS_DEBUG]| 1195 | 2066
SipPublishService::TimerEventCallback | triggering republish

3.4.6 Toggle VoLTE ON/OFF call flows and log messages

The Android UI on the UE allows the end user to toggle VoLTE ON or OFF. If the VoLTE setting is
changed, OEM must use the RCS IMS Settings API to inform the modem. For QTI APIs, see RCS 5.1
User Capability Exchange AIDL API Interface Specification (80-NE170-2).

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 41

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

Modem performs the IMS reregistration. There is no OEM responsibility. OEM must invoke Perform
Presence Publication after receiving the trigger indication

Figure 3-8 Toggle VoLTE ON call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 42

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

■ The UI allows the end user to toggle VoLTE OFF. If the VoLTE setting is changed, OEM must use
the RCS IMS Settings API to inform the modem.
■ Modem performs the IMS reregistration. There is no OEM responsibility.
■ OEM must invoke Perform Presence Publication after receiving the trigger indication.

Figure 3-9 Toggle VoLTE off call flow

3.4.7 Toggle VT ON or OFF call flows and log messages

The Android UI on the UE allows the end user to toggle VT ON or OFF. If the VT setting is changed,
OEM must use the RCS IMS Settings API to inform the modem. For QTI APIs, see RCS 5.1 User
Capability Exchange AIDL API Interface Specification (80-NE170-2).

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 43

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

Modem performs the IMS reregistration. There is no OEM responsibility. OEM must invoke Perform
Presence Publication after receiving the trigger indication.

Figure 3-10 Toggle VT ON/OFF call flow

1. VT is turned on.
09-17 18:06:19.076 2825 2825 D PRESENCE_UI: Before updateVideoSetting
09-17 18:06:19.076 2825 2825 D PRESENCE_UI: Data is enabled ... video
was unchecked, video = false
09-17 18:06:24.611 2825 2825 D PRESENCE_UI: User selected Video
09-17 18:06:24.631 2825 2825 D PRESENCE_UI: if
QrcsImsSettings_SetQipcallConfig success
09-17 18:06:24.721 2825 3249 D PRESENCE_UI: Video is supported 1 and
DATA is ON from NV
09-17 18:06:24.721 2825 3249 D PRESENCE_UI: PublishTask :
sendPublishRequest : AppGlobalState.getPresenceSerrviceHandle() 22136

2. IMS reregistration and Presence Publication take place.

IMS SIP/High 01:04:31.872 [IMS_AP] sipConnection.cpp 03414 | 3414
| 2087 |EVENT_SIP_REQUEST_SEND: PUBLISH sip:[email protected] SIP/2.0
|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK
IMS/High 01:04:32.726 qipcall.c 00450

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 44

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

[qipcall_process_capability_change] [services: 11] [mobile_data: 1]

[video_calls: 1]
IMS/High 01:04:32.726 qipcall.c 00462
[qipcall_process_capability_change] [changing video service]
IMS SIP/High 01:04:32.763 /local/mnt/workspa 03489 3489|
EVENT_SIP_REQUEST_SEND: REGISTER sip:ims.vz.net SIP/2.0
IMS SIP/High 01:04:32.858 /local/mnt/workspa 02581 2581|
EVENT_SIP_REG_RESP_RCVD : 44 Code = 200

3.4.8 Mobile data network on/off call flows and log messages
When the user turns off mobile data from the UI, the process described in the following occurs:

Figure 3-11 Mobile data network on/off call flow

NOTE Capability polling and Availability Fetch were removed from this call flow for simplicity.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 45

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

1. Mobile data network is off.

IMS/High 18:35:17.009 qipcall.c 00450
[qipcall_process_capability_change] [services: 15] [mobile_data: 0]
[video_calls: 1]

2. Republish (without VT feature tag)

IMS SIP/High 18:35:17.127 [IMS_AP] sipConnection.cpp 03414 | 3414 | 2087
|EVENT_SIP_REQUEST_SEND: PUBLISH
IMS SIP/High 18:35:17.210 [IMS_AP] qimfsiplib.cpp 04463 | 4463 |
2087 |EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK

3.4.9 L2e and e2L iRAT transitions call flows and log messages
eHRPD is a software solution that is used to pass LTE packets through existing CDMA towers, when
pure LTE towers are not available. The following figure and procedure describe the transitions from
LTE to evolved high rate packet data (eHRPD) and vice versa:

Figure 3-12 L2e and e2L iRAT transitions call flow

NOTE Capability polling and Availability Fetch were removed from this call flow for simplicity

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 46

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

1. The UE moves from LTE to eHRPD.

2. IMS reregistration is performed and the OEM receives a presence trigger indication.
3. The OEM is responsible for listening to this indication and performing Presence Publication using
RCS AIDL APIs.
4. The UE moves from eHRPD to LTE.
5. IMS reregistration is performed and the OEM receives a Presence Trigger indication.
6. The OEM is responsible for listening to this indication and performing a Presence Publication
using RCS AIDL APIs. For QTI APIs, see RCS 5.1 User Capability Exchange AIDL API Interface
Specification (80-NE170-2).

3.4.10 Airplane mode on call flows and log messages

When the user turns on airplane mode from the UI, the following steps occur in the UE:
1. Airplane mode is turned on.
2. QTI IMS performs Presence depublication and IMS deregistration. There is no OEM responsibility.
3. The modem moves to low power mode (LPM)

Figure 3-13 Airplane mode on call flow

NOTE Capability polling and Availability Fetch were removed from this call flow for simplicity.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 47

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

1. Airplane mode is on
IMS UNKNOWN/High 01:09:03.035 [IMS_AP] IMSDevice.cpp 00662 | 662 |
2087 |<RCS STATUS> IMSDevice AirPlane - QPE_OPRT_MODE (6)
IMS UNKNOWN/High 01:09:03.035 [IMS_AP] IMSDevice.cpp 00672 | 672 |
2087 |<RCS STATUS> IMSDevice::imspOperMode - Old OperMode = 5 New OperMode
= 6
IMS PRESENCE/High 01:09:03.090 [IMS_AP] IMSPresenceEnabler.cpp 02351
| 2351 | 2087 |IMSPresenceEnabler Treating LPM as Air ON

2. Unpublish and deregister the device

IMS SIP/High 01:09:03.127 [IMS_AP] sipConnection.cpp 03414 |
3414 | 2087 |EVENT_SIP_REQUEST_SEND: PUBLISH
IMS SIP/High 01:09:03.210 [IMS_AP] qimfsiplib.cpp 04463 | 4463 |
2087 |EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK
IMS IMS CORE/High 01:09:03.345 /local/mnt/workspa 01555 1555|
EVENT_SIP_DEREGISTER_START:REGISTER sip:ims.vz.net SIP/2.0
IMS SIP/High 01:09:03.382 /local/mnt/workspa 04514 4514|
EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 48

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

3.4.11 UE power-off call flows and log messages

When the user turns off the UE, the following steps occur:
1. The user switches the power off in the UE.
2. Modem performs presence depublication and IMS deregistration. There is no OEM responsibility.
3. The modem moves to Offline mode.

Figure 3-14 UE power off call flow

NOTE Capability polling and Availability Fetch were removed from this call flow for simplicity.

1. Power off
IMS UNKNOWN/High 01:09:03.035 [IMS_AP] IMSDevice.cpp 00662 | 662 |
2087 |<RCS STATUS> IMSDevice AirPlane - QPE_OPRT_MODE (0)
IMS UNKNOWN/High 01:09:03.035 [IMS_AP] IMSDevice.cpp 00672 | 672 |
2087 |<RCS STATUS> IMSDevice::imspOperMode - Old OperMode = 5 New OperMode
= 0

2. Unpublish and deregister the device

IMS SIP/High 01:09:03.127 [IMS_AP] sipConnection.cpp 03414 |
3414 | 2087 |EVENT_SIP_REQUEST_SEND: PUBLISH
IMS SIP/High 01:09:03.210 [IMS_AP] qimfsiplib.cpp 04463 | 4463 |
2087 |EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK
IMS IMS CORE/High 01:09:03.345 /local/mnt/workspa 01555 1555|

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 49

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual RCS presence service

EVENT_SIP_DEREGISTER_START:REGISTER sip:ims.vz.net SIP/2.0

IMS SIP/High 01:09:03.382 /local/mnt/workspa 04514 4514|
EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK

3.5 Enable RCS

The following Android debug bridge (ADB) commands must be executed once to enable RCS. This
setting is stored in NV, which is persistent through power cycles.
adb root
adb remount
adb shell setprop persist.rcs.supported 1
adb shell sync
adb reboot

Table 3-1 Mapping between feature tags and service IDs

Capability Tag Tuple attribute

Capability discovery +g.3gpp.iari-ref=“urn Service-id: org.3gpp.urn:urn-7:3gpp-

via presence %3Aurn-7%3A3gpp- application.ims.iari.rcse.dp
application.ims.iari.rcse.dp”
Version 1.0
IP voice call +g.3gpp.icsi-ref=“urn Service-id: org.3gpp.urn:urn-7:3gpp-
%3Aurn-7%3A3gpp- service.ims.icsi.mmtel
(IR.92/IR.58)
service.ims.icsi.mmtel”
Version 1.0
Media capabilities: audio, duplex
IP video call (IR.94) +g.3gpp.icsi-ref=“urn Service-id: org.3gpp.urn:urn-7:3gpp-
%3Aurn-7%3A3gpp- service.ims.icsi.mmtel
service.ims.icsi.mmtel”;video
Version 1.0
Media capabilities: audio, video, duplex

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 50

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
4 IMS VoLTE architecture

4.1 Network architecture for VoLTE

To provide a telephone service, the EPS network only produces voice and signaling transport, which
are considered to be data. Signaling and voice processing is carried out by the IMS network, outside of
the mobile network.

4.1.1 EPS architecture for VoLTE

Figure 4-1 EPS network architecture

NOTE Interfacing IMS components for SIP signaling are highlighted in yellow

Evolved node B (eNB) provides the following evolved universal terrestrial radio access (E-UTRAN)
protocol terminations toward the UE:
■ User planes (PDCP/RLC/MAC/PHY)
■ Control plane (RRC)
Serving gateway (SGW) and PDN gateway (PGW) are the user plane. Mobility management entity
(MME) is the control plane

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 51

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.1.2 IMS architecture for VoLTE

Figure 4-2 IMS architecture

The parts of the architecture are described as follows:
■ Home subscriber server (HSS)
□ Master user database for subscription-related information (subscriber profiles)
□ Authenticates and authorizes the user

■ Application server
□ Host and execute IMS-specific services, for example, VoLTE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 52

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

■ Signaling
□ Call session control function (CSCF)

– Proxy call session control function (P-CSCF)

• First point of contact with the IMS terminal
• Sits on the path for all signaling to ensure that the IMS terminal behaves appropriately
• Encryption of signaling compression (SigComp) or IPSec

– Interrogating call session control function (I-CSCF)

• Queries the HSS to retrieve the address of the S-CSCF (load balanced) and assigns it
to a user performing SIP registration
• Forwards SIP request/response to the S-CSCF

– Serving call session control function (S-CSCF)

• SIP registration; binds the user location, for example, IP address of the device, and
the SIP address (IMPU)
• Decides which application server the SIP message is forwarded to, to provide
services

□ Policy and charging rules function (PCRF)

– On-call network-initiated quality of service (QoS) resource reservation

■ Media
□ Breakout gateway control function (BGCF)
– S-CSCF inserts BGCF into the signaling path, which in turn sends requests to media
gateway control function (MGCF)
□ Media gateway (MGW)/MGCF
– Calls delivered to another IP domain
– Calls delivered to PSTN
– Transcoding between two codecs (if there is a codec mismatch)

□ Media resource function controller (MRFC)

– Signaling plane node that interprets information coming from an AS and S-CSCF to
control the media resource function processor (MRFP)
□ MRFP
– Customized ringback tone (CRBT), also known as personalized ringback tone (PRBT)
– Network announcements, for example, “cannot establish call”, “call forwarded to voice
mail”.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 53

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

Signaling and media planes

VoLTE signaling and media are sent on different evolved packet system (EPS) bearers
■ Dedicated bearer is used for media (guaranteed bit rate (GBR), QoS class identifier (QCI) = 1)
■ Default bearer is used for signaling (non-GBR, QCI = 5)

Figure 4-3 High Level Media/Signaling block Diagram

Figure 4-4 Data/Signalling Path

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 54

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

■ Signaling
□ UE↔P-CSCF

– SIP
• IMS registration/deregistration
• VoLTE call origination/termination

■ Media
□ UE1 ↔ E-UTRAN ↔ UE2
□ Audio packets over real time transport protocol (RTP)

4.2 UE architecture for IMS VoLTE

The following figure shows the internal subsystem of the handset modem for the VoLTE architecture:

Figure 4-5 Handset architecture for VoLTE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 55

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.3 High-level VoLTE call flow

Figure 4-6 High-level VoLTE call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 56

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

VoLTE feature initialization procedures are required before a VoLTE session can be established. The
procedures are as follows:

1. UE attaches to LTE network

□ Domain selection (all call flows assume voice over IMS)

2. IMS PDN connection and SIP QoS flow take place

□ QCI = 5 is used for SIP signaling on IMS default bearer

3. IMS registration and subscription with IMS CN takes place

□ Feature tags for services are available
– MMTel IMS communication services identifier (ICSI) checks voice capability

VoLTE session procedures to establish a VoLTE session with a remote party is as follows:

1. IMS session establishment

□ SIP signaling
□ Session description protocol (SDP) for codec negotiation

2. Establish VoLTE QoS flow

□ Network-initiated QoS procedures

3. Robust header compression (RoHC) negotiation takes place

4. Full duplex VoLTE data between UE and E-UTRAN takes place

□ This data is routed from the E-UTRAN via the packet data core network to the remote party
involved in the call.
□ Each voice frame is generated by the vocoder and carried as the payload in the RTP.
□ RTP packets are encapsulated in user datagram protocol (UDP) packets and carried over IP.

5. IMS session termination

□ SIP signaling
□ Call release and cleanup

6. Release VoLTE QoS flow

□ Network-dependent QoS procedures
□ Feature termination procedures

When IMS services are no longer required, IMS deregistration with the network is performed.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 57

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.4 IMS registration to VoLTE call flow

The call flow for IMS registration to the VoLTE network is as follows:

Figure 4-7 IMS registration call flow

See IMS Registration Call Flows/Log Analysis (80-PC414-1) for log analysis and more details on IMS
registration.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 58

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.5 High-level end-to-end VoLTE call establishment

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 59

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

Figure 4-8 High-Level end-to-end VoLTE call – network-initiated QoS

Following is the end-to-end process of call transmission from MO to MT:

1. User makes a call. CM notifies IMS. IMS creates and sends Invite message.
□ Reliable provisional responses (100 Rel)
□ SDP for audio codec support

2. When the LTE stack receives this message, it initiates a service request procedure. The RRC
layer performs the random access channel (RACH) procedure to get into RRC connected state
and transmits the message.

3. LTE stack transmits the INVITE message.

a. The Invite message reaches P-CSCF1. It is routed to S-CSCF serving the UE through I-CSCF.
The S-CSCF determines that the destination is reachable through IMS (and not a CS/landline
customer) and forwards the request to the corresponding I-CSCF. The message is eventually
delivered to the PGW serving the UE2 through its P-CSCF (P-CSCF2).
b. The UE2 is paged over the E-UTRAN and performs the RACH procedure to respond to the
LTE page.
c. The INVITE message is sent to UE2 and is routed to the IMS client2.
4. P-CSCF1 sends a 100: Trying message to the IMS client1 to indicate that the Invite message has
been forwarded to the destination.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 60

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

5. If the IMS client in UE2 supports at least one of the codecs proposed by IMS client1, it responds to
the Invite message with 180 Ringing response, since it is configured as a QoS-unaware client.
□ 180 Ringing message contains only one codec choice in the SDP.
□ 180 Ringing message reaches IMS client1 through the reverse path of the one followed by the
Invite message.

6. When the P-CSCF1 and P-CSCF2 receive the 180 Ringing message, they trigger the network-
initiated push of the dedicated bearers. The P-CSCF triggers the network-initiated dedicated EPS
bearer creation by creating a diameter session with the PCRF. The EPS bearer is created by
sending an AA-Request message that contains:
□ The IP address assigned to the UE by the IMS PDN.
□ Media component description, which specifies the codec and traffic flow template (TFT) from
the SDP in the 180 Ringing message.

7. In response to the AA-Request message in step 6, the PCRF identifies the IP connectivity access
network (IP-CAN) session using the IP address obtained from the P-CSCF. It uses the QoS policy
information downloaded from the HSS/subscriber profile repository (SPR) during IP-CAN session
establishment and the media-description message received from P-CSCF to determine the QoS
and filter information for the dedicated EPS bearer that carries the voice traffic. It performs an IP-
CAN session modification by sending the (diameter) RAR command with the QoS-Information and
flow-description fields.
□ QoS-Information specifies QCI, address resolution protocol (ARP), GBR/MBR parameters.
□ For GPRS tunneling protocol (GTP), this command reaches PGW.

8. For GTP, the PGW creates S5 EPS bearers by installing the packet filters based on the flow-
description field of the received RAR command. It sends a Create Bearer request messageto the
SGW. This message contains the EPS bearer QoS, S5/S8-Tunnel-ID, TFT, and LBI (EPS bearer-
ID of default bearer to which the dedicated bearer is linked).
9. The SGW sends a Create Bearer Request message to the MME that contains the EPS bearer
QoS, S1-Tunnel-ID, TFT, and LBI.

10. The MME selects an EPS bearer ID for the dedicated bearer. It creates a NAS message and an
Activate Dedicated EPS Bearer Context request message, and sends it to eNB in an MME
message called Bearer Setup request. The following are the important fields:
□ The Bearer Set up request, which contains the EPS bearer-ID, EPS QoS, S1-Tunnel-ID, and
the NAS message
□ The Activate Dedicated EPS Bearer Context Request message, a NAS message that
specifies the EPS bearer-ID, TFT, QoS parameters, and LBI.
11. eNB maps EPS bearer QoS to radio bearer QoS. It sends an RRC-Connection Reconfiguration
message, which contains a data radio bearer (DRB) linked to the EPS bearer-ID that can
guarantee the QoS at the radio level. The RRC-Connection Reconfiguration message also
contains the NAS message from the MME.

12. When the UE acknowledges the radio bearer activation using RRC Connection Reconfiguration
Complete message, eNB sends a Bearer Setup Response to the MME indicating that the EPS
bearer QoS could be allocated. This message contains the EPS bearer-ID and S1-Tunnel-ID.
□ If eNB does not have resources, it responds with a failure.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 61

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

13. The NAS layer in the UE responds with a NAS message Activate Dedicated EPS Bearer Context
Accept in a UL Info Transfer message. Also, when the network-initiated dedicated bearer is
created, the LTE stack:
□ Uses the contents of the NAS message/RRC message to create a mapping between traffic
flows to the radio bearer.
□ The installed UL TFT should have a destination IP address/port in the SDP answer and DL
TFT with source IP/port advertised in the SDP offer.
14. eNB forwards the NAS message to the MME in a UL NAS transport.
15. The MME sends a Create Bearer Response message to the SGW.
16. The SGW sends a Create Bearer Response message to the PGW.
17. The PGW sends an RAR response message to the PCRF.
18. Upon receiving the RAR response message, the PCRF sends an AA-Answer command to the P-
CSCF indicating that dedicated bearer establishment has succeeded.
19. The IMS client in UE1 sends a provisional response acknowledgment (PRACK) SIP message.
This PRACK message reaches the IMS client on UE2 through the same set of nodes as in step 3.

20. The IMS client in UE2 responds with a 200 (OK) message upon receiving the PRACK. This
response acknowledges the PRACK and accepts the SDP-Offer.
□ The IMS client in UE2 alerts the user after receiving the PRACK that acknowledges the 180
Ringing message.
21. When the destination user answers the call, IMS client2 sends a 200 (OK) message to the source
IMS client1. This message serves as 200 (OK) to the initial Invite message.
22. IMS client1 acknowledges the 200 (OK) message with an ACK and the media streams are ready
to be established.

4.6 Call setup scenarios and corresponding logs in IMS VoLTE

The following call flows and log analysis help in debugging various call setup scenarios in VoLTE.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 62

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.6.1 Mobile-originated call setup

The following call flow and log analysis describe the mobile-originated call setup:

Figure 4-9 Mobile-originated call setup call flow

1. QMI receives a request to originate a VoLTE call.
01:26:22.306 [60] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Request
voice_dial_call {
call_type = CALL_TYPE_VOICE
01:26:22.309 [06] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Response
voice_dial_call {
result = QMI_RESULT_SUCCESS
error = QMI_ERR_NONE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 63

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

01:26:22.309 [06] 0x1544 QMI_MCS_QCSI_PKT

MsgType = Indication
voice_all_call_status {
call_state = CALL_STATE_ORIGINATING
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MO
mode = CALL_MODE_LTE

2. IMS receives a request to originate a VoLTE call.

IMS/High 01:26:22.311 cmipapp.c 5238 =CM= CM->IMS: CMIPAPP: Sending IP
orig, sys_mode 512, app_id 1 pi 0 orig call_id 2, call_type 1, as_id 0 Sub-
ID:1
IMS/High 01:26:22.311 qipcallh.c 36119 qipcallh_process_call_request:
eCallCbType = 0 Sub-ID:1

3. RTP component is initialized within IMS.

IMS/High 01:26:22.312 qipcallh.c 12106 Call id 2 moving to WAIT FOR RTP
OPEN Sub-ID:1
RTP initialization is successful
IMS/High 01:26:22.322 qipcall.c 1815 qipcall_process_rtp_msg:
QIPCALL_RTP_OPEN_DONE Sub-ID:1

4. IMS creates an SDP offer based on the UE configuration and sends it to IMS CN in a SIP INVITE
request containing supported codec rates.
IMS/High 01:26:22.322 qipcallsdp.c 3221 Creating Offer | call_id: 2 Sub-
ID:1
IMS/High 01:26:22.322 qipcallsdp.c 3248 [is_offer: 1] Sub-ID:1
:
IMS/High 01:26:22.322 qipcall_sdp_audio.c 6945
qipcallsdp_initialize_m_line_AS_bandwidth: AMR WB modeset NV: 0, AMR
modeset NV:0 amr_wb_enabled 1 Sub-ID:1
IMS/High 01:26:22.322 qipcall_sdp_audio.c 470
qipcallsdp_add_payld_fmt:WB-Amr mode is 0 Octet align 0 Sub-ID:1
IMS/High 01:26:22.322 qipcall_sdp_audio.c 488
qipcallsdp_add_payld_fmt:Amr mode is 0 Octet align 0 Sub-ID:1
AMR bandwidth (that is, wideband or narrowband), payload type, mode (bandwidth efficient or
octet aligned), and mode-set can be configured through audio codec profiles (AudioProfile) under
[QIPCALL:ImsMediaProfileConfig] in OEM override configuration files. See Audio codec profile
configuration for more details. Mode set is configured by NV 73846 (amrModeSet) for AMR-NB
and NV 73846 (amrWbModeSet) for AMR-WB. It is a bitmask (1 << n) representation of the
preceding values. For example: 149 = 1001 0101 = 23.05 kbps, 15.85 kbps, 12.65 kbps, 6.60 kbps
Table 4-1 AMR narrowband and wideband bit rate

AMR-NB (NV 73846 - amrModeSet) AMR-WB (NV 73846 - amrWbModeSet)

0 = AMR 4.75 kpbs 0 = AMR-WB 6.60 kbps

1 = AMR 5.15 kpbs 1 = AMR-WB 8.85 kbps
2 = AMR 5.90 kpbs 2 = AMR-WB 12.65 kbps
3 = AMR 6.70 kpbs 3 = AMR-WB 14.25 kbps

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 64

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

Table 4-1 AMR narrowband and wideband bit rate (cont.)

AMR-NB (NV 73846 - amrModeSet) AMR-WB (NV 73846 - amrWbModeSet)

4 = AMR 7.40 kpbs 4 = AMR-WB 15.85 kbps
5 = AMR 7.95 kpbs 5 = AMR-WB 18.25 kbps
6 = AMR 10.20 kpbs 6 = AMR-WB 19.85 kbps
7 = AMR 12.10 kpbs 7 = AMR-WB 23.05 kbps
8 = AMR-WB 23.85 kbps

Invite request with SDP payload is sent to IMS CN. This is routed to the far-end peer to begin
VoLTE session establishment.
IMS/High 01:26:22.333 qpSipUtils.cpp 3393 EVENT_SIP_REQUEST_SEND: INVITE
sip:[email protected];user=phone SIP/2.0 Sub-ID:1

5. 100 Trying message is received, which indicates that the Invite request was received by the IMS
CN.
IMS/High 01:26:22.684 qpSipUtils.cpp 3393 EVENT_SIP_RESPONSE_RECV: SIP/2.0
100 Trying Sub-ID:1
a. 180 Ringing message is received from far-end UE.
IMS/High 01:26:22.775 qpSipUtils.cpp 3393 EVENT_SIP_RESPONSE_RECV:
SIP/2.0 180 Ringing Sub-ID:1
b. IMS waits for 200 OK response to the Invite request. This indicates that the far-end UE
answered the VoLTE call.
c. IMS starts the ringback timer once 180 Ringing message is received, and stops after receiving
200 OK message. The timer value is configurable through NV 73842 – ringBackTimer (in
milliseconds). It is the amount of time that the UE waits for a final (non-1xx provisional) SIP
response before sending Cancel message to end the MO VoLTE session establishment
attempt.
IMS/High 01:26:22.782 qipcallh.c 4176 Start QIPCALL Ringback timer
180000 call id 2 Sub-ID:1
d. IMS sends indication to CM, which is propagated to UI through QMI Voice. Ringback tone is
played to the user. A normal ringback indication is propagated to upper layers unless SIP
header alert-info is set (alert-info indicates call waiting)
IMS/Medium 01:26:22.782 qpDplCallCtrl.c 6869 qpDplCallCtrlReportInd:
eIndication = 4 Sub-ID:1
01:26:22.783 [A4] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Indication
voice_all_call_status {
call_state = CALL_STATE_ALERTING
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MO
mode = CALL_MODE_LTE

6. IMS receives 200 OK (INVITE) response from IMS CN and sends ACK to IMS CN.
IMS/High 01:26:23.300 qpSipUtils.cpp 3393
EVENT_SIP_RESPONSE_RECV: SIP/2.0 200 OK Sub-

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 65

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

ID:1
IMS/High 01:26:23.305 qpSipSessionService.cpp 3776
EVENT_SIP_SESSION_ESTABLISHED:Response Code: 200 Sub-ID:1
:
IMS/High 01:26:23.306 qimfif_cbs.cpp 2942 qimfif_cbs_update: Received
event = 4 Sub-ID:1
IMS/High 01:26:23.310 qimfif_cbs.cpp 3092 qimfif_cbs_update: Outgoing
Established. 200 ok rcved for dialog_id 12 Sub-ID:1
:
IMS/High 01:26:23.316 qpSipUtils.cpp 3393 EVENT_SIP_REQUEST_SEND: ACK
sip:+12345678901@[fc01:abab:cdcd:6fee::1] SIP/2.0 Sub-ID:1

7. IMS activates the media part of the VoLTE call via the RTP component that was initiated based on
offer answer.
IMS/Medium 01:26:23.319 qpaudio.c 4436 qpAudioInitialize Start VSID
11C05000 MVM 11C05000
IMS/High 01:26:23.322 qipcallrtp.c 1909 [qipcallrtp_resume_rtp_stream]
[qvp_rtp_resume_stream success] Sub-ID:1

8. IMS informs upper layers that the call is connected.

IMS informs CM that call is connected
IMS/Medium 01:26:23.321 qpDplCallCtrl.c 6869
qpDplCallCtrlReportInd: eIndication = 2 Sub-ID:1

CM updates the state and passes on the information to the QMI layer
Call Manager/High 01:26:23.321 cmipapp.c 3997 =CM= RPT name
604
Call Manager/High 01:26:23.321 cmipcall.c 2882 =CM= DS: SUB
1 IP RXD: CONNECTED, id=2, as_id=0 Sub-ID:1
The QMI layer passes the call status to the AP side.
01:26:23.321 [EC] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Indication
voice_all_call_status {
call_state = CALL_STATE_CONVERSATION
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MO
mode = CALL_MODE_LTE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 66

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.6.2 Mobile-originated call setup (with precondition)

The following call flow and log analysis describe the mobile-originated call setup with precondition:

Figure 4-10 Mobile-originated call setup (with precondition) call flow

The qosPreconditionsEnabled item is used to enable(1) or disable(0) the precondition. This item can
be found under the following location:
[QIPCALL:ImsVoiceQoSConfig] in “datamodem\ims\Configuration\ConfigFramework
\OEM_OVERRIDE_FILES\sdm845.gen.testQ\overideconfig_xxx” file of respective operator/IR92
1. SIP Invite is sent for an MO VoLTE call with a precondition.
00:06:36.500 qpSipSessionServic 1456 H EVENT_SIP_SESSION_START: INVITE sip:
[email protected];user=phone SIP/2.0f: <tel:+11234567890> Sub-
ID:1
SIP Invite snippet from PCAP logs
INVITE sip:[email protected];user=phone SIP/2.0
k: 100rel,replaces,precondition,tdialog
o=- 2 1000 IN IP6 fc01:bbbb:cdcd:efe0:66fb:b688:d703:a94a
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 67

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

2. Network responds with SIP 183 session in progress message.

00:06:37.223 qpSipUtils.cpp 3393 H EVENT_SIP_RESPONSE_RECV: SIP/2.0 183
Session in Progress Sub-ID:1 Allow: UPDATE,INFO Call-ID:
396490_4119997676@fc01:bbbb:cdcd:efe0:66fb:b688:d703:a94a
SIP 183 response from NW supporting remote precondition
SIP/2.0 183 Session in Progress
Require: 100rel,precondition
Supported: precondition // Precondition supported by NW
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv // supports remote QoS precondition

3. After receiving SIP 183, QIPCALL registers for a QoS event with the data layer.
IMS/High 00:06:37.232 qipcalldialog.c 1262
qipcalldialog_process_incoming_session_progress_event: Call state = 12,
precondition enabled by remote = 1 Sub-ID:1
IMS/High 00:06:37.232 qipcallqos.c 564 qipcallqos_register_qos: QoS reg
status = 0, handle id = 0x1 Sub-ID:1
IMS/High 00:06:37.232 qipcallqos.c 597 qipcallqos_register_qos: Register
successfully for N/W init QoS event, Started QoS timer for VoLT Sub-ID:1

4. Network sets up the dedicated bearer for a media packet for VoLTE call.
00:06:37.412 [84] 0xB0E2 LTE NAS ESM Plain OTA Incoming Message --
Activate dedicated EPS bearer context request Msg
eps_bearer_id_or_skip_id = 6 (0x6)
msg_type = 197 (0xc5) (Activate dedicated EPS bearer context request)
00:06:37.415 [55] 0xB0E3 LTE NAS ESM Plain OTA Outgoing Message --
Activate dedicated EPS bearer context accept Msg
eps_bearer_id_or_skip_id = 6 (0x6)

5. After the dedicated bearer setup is accepted, the data layer informs IMS about QoS availability.
QIPCALL checks the bandwidth allocation details and sends SIP Update.
IMS/Error 00:06:37.415 qpDplQoS.c 894 qpDplProcessQoSEvent:
DPL_QOS_MSG_NW_INIT_AVAIL | Added Qos Instance Handle | QoS Instance
handle --> 0x43001c01 | Qos Handle --> 0x43001c01
IMS/High 00:06:37.415 qipcallqos.c 2411
qipcallqos_process_qos_available_event: Received QoS Handle = 0x1,
Instance Handle = 0x43001c01 Sub-ID:1
IMS/High 00:06:37.416 qipcalldialog.c 4879
qipcalldialog_update_qos_status Status = 0,processing Qos event Sub-
ID:1
IMS/High 00:06:37.416 qipcallqos.c 2158
[qipcallqos_is_mbr_met]QIPCALLQOS_QOS_AVAILABLE Handle = 1, media_index =
0 Sub-ID:1
IMS/High 00:06:37.416 qipcall_sdp_precondition.c 1566 H
qipcallsdp_update_local_precondition_state_to_met, media_index is 0 Sub-
ID:1

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 68

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

IMS/High 00:06:37.417 qipcall_sdp_audio.c 4765

qipcallsdp_get_AS_value_based_on_mode: bandwidth=38 for mode=2 Sub-ID:1
IMS/High 00:06:37.417 qipcallsdp.c 2447
qipcallsdp_set_RTCP_RR_RS_values:Final RR bandwidth 600 RS bandwidth 2000
Sub-ID:1
IMS/High 00:06:37.417 qipcalldialog.c 3408
qipcalldialog_update_precondition_status: Updated local precondition met
for call id = 2, precondition supported = 1, stream id = 0 Sub-ID:1
IMS/High 00:06:37.417 qipcall_sdp_precondition.c 2508
qipcallsdp_is_local_pre_condition_met: [local precondition status] audio =
1 video = 0, for call id
= 2 Sub-ID:1
IMS/Error 00:06:37.417 qipcalldialog.c 2408
qipcalldialog_process_wait_for_200ok_of_update Sub-ID:1
IMS/High 00:06:37.417 qipcallsdp.c 3221 Creating Offer | call_id: 2 Sub-
ID:1
IMS SIP/High 00:06:37.431 qpSipUtils.cpp 3393 EVENT_SIP_REQUEST_SEND:
UPDATE
sip:+12345678901@[fc01:abab:cdcd:6fee::1] SIP/2.0 Sub-ID:1
Call-ID: 396490_4119997676@fc01:bbbb:cdcd:efe0:66fb:b688:d703:a94a
SIP Update snippet from PCAP log
UPDATE sip:+12345678901@[fc01:abab:cdcd:6fee::1] SIP/2.0
m=audio 50024 RTP/AVP 104 96
b=AS:38 //Bandwidth allocated based on codec
b=RS:600
b=RR:2000
a=curr:qos local sendrecv // local QoS reserved
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

6. Network responds to SIP Update with SIP 200 OK with SDP answer.
IMS SIP/High 00:06:37.659 qpSipUtils.cpp 3393 EVENT_SIP_RESPONSE_RECV:
SIP/2.0 200 OK Sub-ID:1
Call-ID: 396490_4119997676@fc01:bbbb:cdcd:efe0:66fb:b688:d703:a94a
SIP/2.0 200 OK snippet from pcap log
m=audio 10000 RTP/AVP 104 96
b=AS:38
b=RS:600
b=RR:2000
a=curr:qos local sendrecv
a=curr:qos remote sendrecv // remote QoS reserved
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 69

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

7. Network sends SIP 180 ringing.

IMS SIP/High 00:06:37.716 qpSipUtils.cpp 3393 EVENT_SIP_RESPONSE_RECV:
SIP/2.0 180 Ringing Sub-ID:1
Call-ID: 396490_4119997676@fc01:bbbb:cdcd:efe0:66fb:b688:d703:a94a

8. Network sends SIP 200 OK final response for Invite. The call is established.
IMS SIP/High 00:06:38.595 qpSipUtils.cpp 3393 EVENT_SIP_RESPONSE_RECV: SIP/
2.0 200 OK Sub-ID:1
Call-ID: 396490_4119997676@fc01:bbbb:cdcd:efe0:66fb:b688:d703:a94a

9. UE sends SIP ACK to SIP 200 OK.

IMS SIP/High 00:06:38.605 qpSipUtils.cpp 3393 EVENT_SIP_REQUEST_SEND: ACK
sip:[email protected];user=phone SIP/2.0 Sub-ID:1
Call-ID: 396490_4119997676@fc01:bbbb:cdcd:efe0:66fb:b688:d703:a94a

4.6.3 Mobile-originated call setup failure (with precondition)

If a precondition is not met, that is, a dedicated QoS bearer for media is not available or is incorrect, or
it is not set by the network, then the QoS timer expires. Upon timer expiration, IMS releases the MO
call and sends SIP Cancel message.
The qosReservationTimer = 8000 HC item must be configured based on the operation requirement
that defines QoS timer (in ms). This item can be found in the following location: datamodem\ims
\Configuration\ConfigFramework\OEM_OVERRIDE_FILES\sdm845.gen.testQ\overideconfig_xxx file
of respective operator/IR92.
1. After receiving SIP 183, the QIPCALL registers for a QoS event with the data layer and starts the
QoS timer.
IMS/Medium 06:35:01.482 qpDplQoS.c 1085 qpDplQoSEventReg: First time
execution Sub-ID:1
IMS/High 06:35:01.482 qipcallqos.c 600 qipcallqos_register_qos: Register
successfully for N/W init QoS event, Started QoS timer for VoLTESub-ID:1
IMS/Medium 06:35:01.482 qipcalltimer.cpp 318 QipcallTimer::StartTimer -
iDelay:8000 TimerID 0 Sub-ID:1

2. As the network did not set up a necessary dedicated bearer for QoS in 8000 millisecond, the QoS
timer expires. Then, QIPCALL releases the MO call and sends SIP Cancel to the network.
IMS/Medium 06:35:09.398 qipcalltimer.cpp 218 QipcallTimer: Timer fired
0 Sub-ID:1
IMS/High 06:35:09.398 qipcallh.c 14194 qipcallh_handle_qos_timer_expiry
for call id = 2 Sub-ID:1
IMS/High 06:35:09.398 qipcall_sdp_precondition.c 2294
qipcallsdp_is_local_pre_condition_met: local precondition not met for
index = 0 Sub-ID:1
IMS/High 06:35:09.398 qipcallh.c 14457
qipcallh_wait_for_qos_reservation_timer_handler local precondition not
met, ending the call Sub-ID:1
IMS/High 06:35:09.398 qipcallh.c 8297 qipcallh_chg_state_to_null]
[call_id: 2] [state: 12] Sub-ID:1
IMS/Medium 06:35:09.406 qipcall_indication.c 470 qipcall_call_end_rpt_ind:

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 70

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

call_id=2, state=1, cause=0

IMS SIP/High 06:35:09.402 qpSipUtils.cpp 3407 EVENT_SIP_REQUEST_SEND:
CANCEL sip:[email protected];user=phone SIP/2.0 Sub-ID:1

4.6.4 Mobile-terminated call setup

The following call flow and log analysis describes the mobile-terminated call setup:

Figure 4-11 Mobile-terminated call setup call flow

1. IMS receives INVITE request, responds with 100 trying, and processes internally the incoming
VoLTE call request.
IMS/High 01:10:36.440 qpSipUtils.cpp 3393 EVENT_SIP_REQUEST_RECV:
INVITE sip:280671d5-db66-4d6b-a3ae-
553be9838631@[fc01:bbbb:cdcd:efe0:3d9b:681a Sub-ID:1
IMS/High 01:10:36.450 qpSipUtils.cpp 3393
EVENT_SIP_RESPONSE_SEND: SIP/2.0 100 Trying Sub-ID:1
IMS ensures it is able to accept the incoming VoLTE call if the following conditions are met:
□ Current RAT is LTE.
□ CM domain selection has chosen IMS for Voice.
□ There is no active 1X voice call.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 71

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

□ MO VoLTE call setup is not in progress.

□ There is no or only one current active VoLTE call. The following configuration items can keep
more than two call active at a time.
– MPSS.AT (Atlas) onwards: presentThirdCalltoUser
– On older product lines: NV#67348 qipcall_third_call_support_reqd

2. IMS stores and processes the dialog information (SIP headers and SDP).
IMS/High 01:10:36.452 qimfif_cbs.cpp 3097 qimfif_cbs_update: Rxed SIP
INCOMING Sub-ID:1
IMS/High 01:10:36.452 qipcalldialog.c 6169
[qipcalldialog_process_incoming_msg] [event: 4066] [status_code: 100]
[sdpBody_ptr: 0xbe11f5e0] Sub-ID:1
IMS/High 01:10:36.456 qipcalldialog.c 7022
qipcalldialog_update_precondition_enabled_flag :dialog_ptr-
>precondition_enabled = 0 Sub-ID:1
IMS parses SDP offer from far-end and reads the near-end NV configuration to formulate an SDP
answer with commonly supported media / attributes.
IMS/High 01:10:36.454 qipcalldialog.c 5812
[qipcalldialog_update_sdp_received] Sub-ID:1
IMS/High 01:10:36.456 qipcallsdp.c 3643
[qipcallsdp_extract_info_from_peer_container] Sub-ID:1

3. IMS opens an RTP stream to ensure that RTP resources are reserved for the incoming call. IMS
waits for RTP to be opened before proceeding to notify upper layers about the incoming call
request. The process to open RTP is as follows:
a. Allocate memory for audio stream
b. Allocate RTP timer (RTP/RTCP inactivity timers, RTP clock)
c. Configure or associate the audio stream with IMS internal call ID
IMS/High 01:10:36.457 qipcallh.c 12106 Call id 2 moving to WAIT FOR RTP
OPEN Sub-ID:1
IMS/High 01:10:36.458 qvp_rtp_api.c 684 API qvp_rtp_open2 entered with
appid 0 Sub-ID:1
IMS/High 01:10:36.467 qipcall.c 1815 qipcall_process_rtp_msg:
QIPCALL_RTP_OPEN_DONE Sub-ID:1

4. IMS notifies CM about the incoming VoLTE call. The user is not alerted for this notification. This
notification to upper layers is only performed to check if an incoming VoLTE call is allowed.
IMS/Medium 01:10:36.457 qipcall_indication.c 2053
qipcall_call_incoming_rpt_ind: call_id=2, type=1, eAudioAttrib=3,
eVideoAttrib=0, display_len=0, peer_PI=0 Sub-ID:1
:
IMS/Medium 01:10:36.457 qpDplCallCtrl.c 6869 qpDplCallCtrlReportInd:
eIndication = 0 Sub-ID:1
:
IMS/Medium 01:10:36.457 qpDplCallCtrl.c 6965 qpDplCallCtrlReportInd:
CallType = 1 Sub-ID:1

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 72

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

Call Manager/High 01:10:36.457 cmipcall.c 2202 =CM= IP RXD: MT_INVITE

sys_mode=512, as_id=0, is_ims_cap_on_sub=1 rtt_mode=%
Call Manager/High 01:10:36.457 cmipcall.c 2269 =CM= is_volte is TRUE
for MT

NOTE qpDplCallCtrlReportInd returns TRUE when upper layers are successfully notified
about the incoming VoLTE call

IMS/Medium 01:10:36.937 qpDplCallCtrl.c 6869 qpDplCallCtrlReportInd:

eIndication = 1 Sub-ID:1

5. CM informs IMS and confirms the incoming VoLTE call is allowed

Call Manager/High 01:10:36.457 cmipapp.c 5387 =CM= CM->IMS: CMIPAPP:
Sending Invite response to app 1, for call_id 2, as_id 0, accept 1

6. CM informs IMS that the VoLTE call is allowed. A 180 Ringing response is sent to inform the MO
UE that the MT UE is being notified about the incoming VoLTE call.
Invite cb
IMS/High 01:10:36.457 qipcallh.c 36119
qipcallh_process_call_request: eCallCbType = 2 Sub-ID:1
IMS checks if there are any active voice calls to set SIP header “Alert-Info” appropriately for
normal ringback tone or call waiting tone. An active voice call is a call with call type
CM_CALL_TYPE_VOICE in the Conversation state. If DPL can successfully query CM for the
current call list, the value TRUE is returned.
IMS/High 01:10:36.930 qipcallh.c 22865 qipcallh_set_alert_info:
qipcall_get_CM_call_list returned = 1, NumOfCalls =22 Sub-ID:1

NOTE is_alert_info_set is a flag used to indicate if there are any other active voice calls in
progress. The value 0 denotes false, while the value 1 denotes true.

IMS/High 01:10:36.930 qipcallh.c 22898 Hqipcallh_set_alert_info: Alert

info set to = 0 Sub-ID:1
IMS sends 180 Ringing response
IMS/High 01:10:36.930 qipcall.c 4304 [qipcall_send_response]
[response: 180] Sub-ID:1
IMS/High 01:10:36.936 qpSipUtils.cpp 3393
EVENT_SIP_RESPONSE_SEND: SIP/2.0 180 Ringing Sub-ID:1

7. IMS informs upper layers about the incoming VoLTE call to notify the MT UE user via the UI.
a. IMS starts the ringing timer. The ringing timer value is configurable through NV 73842 -
ringingTimer (in milliseconds). This value is the amount of time the MT UE waits for the user to
answer or reject the call before ending the VoLTE session establishment with 486 “Busy Here”
response to the MO UE.
IMS/High 01:10:36.937 qipcallh.c 4151 HStart QIPCALL Ringing timer
45000 call id 2 Sub-ID:1
b. Ringing event notification is propagated to upper layers
IMS/Medium 01:10:36.937 qipcall_indication.c 2144
qipcall_call_ring_cnf_ind: call id = 2, Encryption call enabled = 0 Sub-

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 73

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

ID:1
IMS/High 01:10:36.937 qpDplCallCtrl.c 7609 qpDplCallCtrlReportInd:
calling cmipapp_rpt_ind Sub-ID:1
c. Ringing
IMS/Medium 01:10:36.937 qpDplCallCtrl.c 6869 qpDplCallCtrlReportInd:
eIndication = 1 Sub-ID:1
d. Incoming call
Call Manager/High 01:10:36.937 cmdbg.c 3907 =CM= <<CM1 callevt=5
<2> Sub-ID:1
01:10:36.940 [83] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Indication
voice_all_call_status {
call_state = CALL_STATE_INCOMING
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MT
e. If CM is successfully notified about this event, then TRUE value is returned in the DPL call
control report indication
IMS/High 01:10:36.937 qipcall_indication.c 206 qipcall_rpt_ind ret
from qfDplCallCtrlReportInd = 1 Sub-ID:1
IMS/High 01:10:36.937 qipcallh.c 8202 Call Id 2 state from 11 to
WAIT_FOR_ANSWER Sub-ID:1

8. The user answers the incoming VoLTE call. IMS creates an SDP answer and sends a 200 OK
(INVITE) response.
01:10:47.958 [BA] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Request
voice_answer_call {
voice_answer_call_reqTlvs[0]
Call Manager/High 01:10:47.958 cmdbg.c 3639 >>CM callcmd 1,
tsk=qmi_mmode, client_type=17
Wait for answer (1 accept or 0 reject)
IMS/High 01:10:47.959 qipcallh.c 22457 Answer Cmd State 13 call id = 2,
bAccept = 1 Sub-ID:1

9. Received answer sent

IMS/High 01:10:47.959 qipcall.c 4304 [qipcall_send_response] [response:
200] Sub-ID:1
IMS/High 01:10:47.963 qpSipUtils.cpp 3393 EVENT_SIP_RESPONSE_SEND: SIP/
2.0 200 OK Sub-ID:1

10. IMS activates the VoLTE (same as MO Call Setup steps 7 to 10)
IMS/Medium 01:10:47.963 qipcallh.c 7982 [ activating call id: 2 ] Sub-
ID:1

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 74

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.6.5 Mobile-terminated call setup (with precondition)

The following call flow and log analysis describes the mobile-terminated call setup when it is with
precondition:

Figure 4-12 Mobile-terminated call setup (with precondition) call flow

The NV 65957 = qipcall_precondition_enable is used to enable/disable the precondition.
1. SIP Invite is received for an MT VoLTE call with a precondition.
IMS SIP/High 17:32:15.888 [ qpSipUtils.cpp 3393]
EVENT_SIP_REQUEST_RECV: INVITE sip:da6d5fd1-45ca-4ef9-adbc-
eaa16e8beaff@[fc01:bbbb:cdcd:efe0:acb0:ad76
SIP Invite snippet from PCAP logs
Sip Message = INVITE sip:da6d5fd1-45ca-4ef9-adbc-
eaa16e8beaff@[fc01:bbbb:cdcd:efe0:acb0:ad76:fece:b054]:43513 SIP/2.0
Supported: 100rel,precondition
m=audio 10000 RTP/AVP 97 98 99 100 101
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos optional remote sendrecv

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 75

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

2. UE responds with SIP 183 session in progress.

IMS SIP/High 17:32:15.927 [ qpSipUtils.cpp 3393]
EVENT_SIP_RESPONSE_SEND: SIP/2.0 183 Session Progress
SIP 183 response from UE supporting precondition
Sip Message = SIP/2.0 183 Session Progress
Require: 100rel,precondition
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

3. After sending SIP 183, QIPCALL registers for a QoS event with the data layer.
IMS/Medium 17:32:15.928 [ qipcallh.c 14656]
qipcallh_register_qos_for_call entering
IMS/High 17:32:15.928 [ qipcallqos.c 432]
qipcallqos_register_qos: Media Type = 0, port = 50048

4. Network sets up the dedicated bearer for a media packet for VoLTE call.
LTE NAS ESM Plain OTA Incoming Message 17:32:16.474 Activate dedicated EPS
bearer context request Msg
eps_bearer_id_or_skip_id = 6 (0x6)
LTE NAS ESM Plain OTA Outgoing Message 17:32:16.478 Activate dedicated EPS
bearer context accept Msg
eps_bearer_id_or_skip_id = 6 (0x6)

5. After the dedicated bearer setup is accepted, the data layer informs IMS about QoS availability.
QIPCALL checks the bandwidth allocation details and updates the precondition status.
IMS/High 17:32:16.478 [qipcallqos_wrapper.c 639]
qipcallqos_wrapper_update_qos_status filters: 0 1
IMS/High 17:32:16.478 [qipcallqos_wrapper.c 685]
qipcallqos_wrapper_update_qos_status TX count: 1 bIsMatch: 1 dialog:
0x6bd23d90
IMS/High 17:32:16.478 [ qipcallqos.c 2158]
[qipcallqos_is_mbr_met]QIPCALLQOS_QOS_AVAILABLE Handle = 1, media_index =
0
IMS/High 17:32:16.479 [qipcall_sdp_precondition.c 1566]
qipcallsdp_update_local_precondition_state_to_met, media_index is 0
IMS/High 17:32:16.479 [qipcall_sdp_precondition.c 2508]
qipcallsdp_is_local_pre_condition_met: [local precondition status] audio =
1 video = 0, for call id = 2
IMS/High 17:32:16.479 [qipcall_sdp_precondition.c 2569]
qipcallsdp_is_remote_pre_condition_met: Remote precondition audio not met

6. MT UE sends SIP UPDATE indicating its precondition status.

IMS SIP/High 17:32:16.719 [ qpSipUtils.cpp 3393]
EVENT_SIP_REQUEST_RECV: UPDATE sip:da6d5fd1-45ca-4ef9-adbc-
eaa16e8beaff@[fc01:bbbb:cdcd:efe0:acb0:ad76

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 76

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

SIP Update snippet from PCAP log

Sip Message = UPDATE sip:da6d5fd1-45ca-4ef9-adbc-
eaa16e8beaff@[fc01:bbbb:cdcd:efe0:acb0:ad76:fece:b054]:43513 SIP/2.0
m=audio 10000 RTP/AVP 97 100
b=AS:38
b=RS:0
b=RR:0
a=curr:qos local sendrecv //MO UE QoS bandwidth reserved
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv
IMS/High 17:32:16.729 [qipcall_sdp_precondition.c 2508]
qipcallsdp_is_local_pre_condition_met: [local precondition status] audio =
1 video = 0, for call id = 2
IMS/High 17:32:16.729 [qipcall_sdp_precondition.c 2564]
qipcallsdp_is_remote_pre_condition_met: Remote precondition audio met
Both local (MT UE) and remote (MO UE) precondition is met.
7. UE responds to SIP Update with SIP 200 OK with SDP answer and a local precondition status.
IMS SIP/High 17:32:16.734 [ qpSipUtils.cpp 3393]
EVENT_SIP_RESPONSE_SEND: SIP/2.0 200 OK
SIP/2.0 200 OK snippet from PCAP log
m=audio 50048 RTP/AVP 97 100
b=AS:37
b=RS:0
b=RR:0
a=curr:qos local sendrecv
a=curr:qos remote sendrecv // MT UE QoS reserved
a=des:qos mandatory local sendrecv
a=des:qos mandatory remote sendrecv

8. UE sends SIP 180 Ringing and indicates to the UI layer of the incoming call.
IMS SIP/High 17:32:16.738 [ qpSipUtils.cpp 3393]
EVENT_SIP_RESPONSE_SEND: SIP/2.0 180 Ringing

9. After the user accepts the incoming call, UE sends SIP 200 OK final response for INVITE. The call
is established.
IMS SIP/High 17:32:25.377 [ qpSipUtils.cpp 3393]
EVENT_SIP_RESPONSE_SEND: SIP/2.0 200 OK

10. UE receives SIP ACK for SIP 200 OK from the network.
IMS SIP/High 17:32:25.834 [ qpSipUtils.cpp 3393]
EVENT_SIP_REQUEST_RECV: ACK sip:da6d5fd1-45ca-4ef9-adbc-
eaa16e8beaff@[fc01:bbbb:cdcd:efe0:acb0:ad76:fe

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 77

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.6.6 Mobile-terminated call setup failure (with precondition)

If a precondition is not met, that is, a dedicated QoS bearer for media is not available or is incorrect, or
it is not set by the network, then the QoS timer expires. Upon timer expiration, IMS releases the MT
call and sends SIP 580 Precondition Failure.
The following parameter must be configured based on the operation requirement that defines QoS
timer (in ms).
This parameter can be found in the following location: datamodem\ims\Configuration
\ConfigFramework\OEM_OVERRIDE_FILES\sdm845.gen.testQ\overideconfig_xxx file of respective
operator/IR92
■ qosReservationTimer = 8000

1. After sending SIP 183, the QIPCALL registers for a QoS event with the data layer and starts the
QoS timer.
IMS/Medium 03:02:00.413 [ qipcallh.c 14613]
qipcallh_register_qos_for_call entering
IMS/High 03:02:00.413 [qipcallqos_wrapper.c 1039]
qipcallqos_wrapper_register_qos: Media Type = 0, port = 50028
IMS/Medium 03:02:00.413 [ qipcalltimer.cpp 251]
QipcallTimer::StartTimer - :d8b20614
IMS/Medium 03:02:00.413 [ qipcalltimer.cpp 265]
QipcallTimer::StartTimer - iDelay:8000 TimerID 0
IMS/High 03:02:00.413 [ qipcallqos.c 597]
qipcallqos_register_qos: Register successfully for N/W init QoS event,
Started QoS timer for VoLTE

2. As the network did not set up a necessary dedicated bearer for QoS in 2000 millisecond, the QoS
timer is expired. After that, QIPCALL releases the MT call and sends SIP 580 to the network.
IMS/High 03:02:08.414 [ qipcalltimer.cpp 286]
QipcallTimer::StopTimer 0 d8b20614
IMS/High 03:02:08.414 [ qipcallh.c 15031]
qipcallh_handle_qos_timer_expiry for call id = 2
IMS/High 03:02:08.414 [qipcall_sdp_precondition.c 2296]
qipcallsdp_is_local_pre_condition_met: local precondition not met for
index = 0
IMS/High 03:02:08.414 [ qipcallh.c 15277]
qipcallh_wait_for_qos_reservation_timer_handler local precondition not
met, ending the call
IMS/High 03:02:08.414 [ qipcallh.c 15290]
qipcallh_handle_local_precondition_not_met: sends SIP 580
IMS/High 03:02:08.415 [ qipcallh.c 8921]
qipcallh_chg_state_to_null: end_reason = 0, end_request_type = 1
IMS/High 03:02:08.415 [ qipcallh.c 8996]
qipcallh_chg_state_to_null: stopping media
MSG [00051/03] IMS/Error 00:22:17.885 /
local/mnt/workspa 03341 3341|EVENT_SIP_RESPONSE_SEND: SIP/2.0 580
Precondition Failure Call-ID: [email protected] Content

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 78

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.6.7 Call termination (near side-initiated)

The following call flow and log analysis describe the call termination process when it is near-side
initiated:

Figure 4-13 Call termination (near side-initiated) call flow

1. Call is established and audio flow is in progress
2. CM receives call end command from QMI
a)1:26:49.480 [FE] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Request
voice_end_call {
call_id = 1
voice_end_call_reqTlvs[1] {
end_cause = VOICE_REJECT_CAUSE_USER_REJECT
b) Data Services/Medium 01:26:49.481 ds_qmi_if.c 2057 Call_event 2
received in qmi_if_call_event_cb
Call Manager/High 01:26:49.480 cmcall.c 13098 =CM= End cmd for call
2 info_type = 4
IMS/High 01:26:49.481 cmipapp.c 5456 =CM= CM->IMS: Sending IP END
EXT, call_id 2, app_id 1, as_id 0 end_cause 0
c) 01:26:49.481 [BA] 0x1544 QMI_MCS_QCSI_PKT

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 79

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

MsgType = Response
result = QMI_RESULT_SUCCESS
error = QMI_ERR_NONE

3. CM requests IMS to end the VoLTE call

4. IMS internally cleans up the VoLTE call and sends BYE request
5. IMS receives 200 OK (BYE)
6. Call end indication is propagated up to QMI VOICE
01:26:49.493 [D1] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Indication
voice_all_call_status {
voice_all_call_status_indTlvs[0] {
call_id = 1
call_state = CALL_STATE_END
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MO

4.6.8 Call termination (far side-initiated)

The following call flow and log analysis describe the call termination process when it is far-side
initiated:

Figure 4-14 Call termination (far side-initiated) call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 80

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

1. IMS receives BYE message and sends 200 OK.

IMS/High 08:19:17.989 qpSipDispatcher.cp 2380 Sub-ID:2
QpSipDispatcher::setPriorityInfo| Req Rcvd = BYE
IMS/High 08:19:17.989 qpSipUtils.cpp 3393 Sub-ID:2
EVENT_SIP_REQUEST_RECV: BYE sip:d66d92ba-39d6-408a-a24f-
2305f1814853@[2001::1:acb3:2f22:a77c:a6a9]:448

2. SIP stack sends 200 OK.

IMS/High 08:19:17.999 qpSipUtils.cpp 3393 Sub-ID:2
EVENT_SIP_RESPONSE_SEND: SIP/2.0 200 OK

3. IMS performs VoLTE call cleanup and “end call” indication is propagated to QMI VOICE.
IMS/High 08:19:18.015 cmlog.c 2285 Sub-ID:2 =CM=
EVENT_CM_CALL_EVENT_END_2 - asubid 1
Data Services/Medium 08:19:18.016 ds_qmi_if.c 1653
Processing Call Event 0x3 from CM
08:19:18.016 [AC] 0x1544 QMI_MCS_QCSI_PKT
MsgType = Indication
voice_all_call_status {
voice_all_call_status_indTlvs[0] {
call_state = CALL_STATE_END
call_type = CALL_TYPE_VOICE_IP

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 81

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.7 Call hold call flow and log analysis

The following call flow and log analysis describe the call hold process in the UE:

Figure 4-15 Call hold call flow

1. UI sends Hold Call request to QMI.
19:55:38.085 Length: 0036
voice_manage_ip_calls {
sups_type {
sups_type = VOIP_SUPS_TYPE_CALL_HOLD
}

2. QMI sends Hold Call request to the CM, CM sends the CM_CALL_SUPS_TYPE_HOLD_CALL
command to IMS to put call on hold.
Data Services/Medium 19:55:38.085 [ ds_qmi_if.c 2057] Call_event
4 received in qmi_if_call_event_cb
19:55:38.085 Call Manager/High [ cm.c 7071] =CM=
CM_CALL_CMD_SUPS client 17, sups_type 16, as_id 0
19:55:38.085 Call Manager/High [ cmdbg.c 3639] >>CM callcmd
3, tsk=qmi_mmode, client_type=17

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 82

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

19:55:38.085 Call Manager/High [ cmipcall.c 4480] =CM= IPCALL

cmd check 0
19:55:38.085 Call Manager/High [ cmipcall.c 4849] =CM= IP
CALLCMD: cmd=3, as_id=0, is_ims_cap_on_sub=1
19:55:38.085 Call Manager/Medium [ cmipapp.c 5634] =CM= CM-
>IMS: CMIPAPP: Send Hold for call 2, as_id 0

3. Hold request callback posted to IMS from CM and IMS responds to CM with
CM_CALL_EVENT_SUPS.
19:55:38.085 IMS/High [ qipcallh.c 36119]
qipcallh_process_call_request: eCallCbType = 6

4. IMS sends invite with send-only attribute set to SIP. SIP forwards this invite to SIP server also
known as P-CSCF.
19:55:38.097 [0x156E] IMS SIP Message
a=sendonly

5. SIP server sends 200 OK to SIP stack.

19:55:38.483 [0x156E] IMS SIP Message
Response Code = OK (200)

6. SIP stack sends QPE_SIP_REINVITE_ESTABLISHED_EV message to IMS.

19:55:38.486 IMS/High [ qimfif_cbs.cpp 3366] qimfif_cbs_update:
Reinvite Established

7. IMS also sends acknowledgment of re-invite to SIP stack.

19:55:38.492 IMS SIP/High [ qpSipUtils.cpp 3393]
EVENT_SIP_REQUEST_SEND: ACK sip:8765432101@[fcb1:efef::1] SIP/2.0

8. IMS sends CM a CM_IP_CALL_IND_CALL_HOLD indication.

Call Manager/High 19:55:38.496 [ cmipapp.c 3997] =CM= RPT name
606
Call Manager/High 19:55:38.496 [ cmtask.c 10546] =CM= CM<< IP
cmd:606
Call Manager/High 19:55:38.496 [ cmipcall.c 3544] =CM= IP RXD:
CALL_HOLD, id=2, as_id=0

9. CM sends QMI a CM_CALL_EVENT_CALL_ON_HOLD event.

19:55:38.498 [0x1544] MCS QCSI Payload Packet
voice_modified {
voice_modified_indTlvs[2] {
audio_attrib {
audio_attrib = VOICE_CALL_ATTRIB_TX
}

10. IMS sends CM a CM_IP_CALL_IND_SUPS_CONF indication.

Call Manager/High 19:55:38.497 [ cmipcall.c 1986] =CM= CM->CM:
CM_IP_CALL_IND_SUPS_CONF, call_success 1, sups_type 0, as_id 0
Call Manager/High 19:55:38.497 [ cmipapp.c 3997] =CM= RPT name
609

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 83

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

11. CM sends QMI a CM_IP_CALL_IND_MODIFY_COMPLETE event.

Call Manager/High 19:55:38.497 [ cmtask.c 10546] =CM= CM<< IP
cmd:615
Call Manager/High 19:55:38.497 [ cmipcall.c 4067] =CM= IP RXD:
MODIFY_COMPLETE, id=2, as_id=0 call_type=1

12. QMI provides a status of call to UI.

19:55:38.498 [0x1544] MCS QCSI Payload Packet
voice_all_call_status {
call_state = CALL_STATE_HOLD

4.8 Call resume call flow and log analysis

The following call flow and log analysis describe the call resume process in the UE:

Figure 4-16 Call resume call flow

1. UI sends call resume request to QMI.
19:56:01.221 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_manage_ip_calls {
sups_type {

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 84

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

sups_type = VOIP_SUPS_TYPE_CALL_RESUME
}

2. QMI sends call resume request to CM.

Call Manager/High 19:56:01.221 [ cmipcall.c 4849] =CM= IP
CALLCMD: cmd=3, as_id=0, is_ims_cap_on_sub=1
Call Manager/High 19:56:01.221 [ cmipapp.c 5781] =CM= CM->IMS:
CMIPAPP: Send resume for call_id 4, as_id 0

3. CM posts call back to IMS through qpDplCallCtrlActiveCallCB.

IMS/High 19:56:01.221 [ qipcallh.c 36119]
qipcallh_process_call_request: eCallCbType = 7

4. IMS sends INVITE to P-CSCF server also known as SIP SERVER.

19:56:01.240 [0x156E] IMS SIP Message
Message ID = IMS_SIP_INVITE
a=sendrecv
19:56:01.852 [0x156E] IMS SIP Message
Response Code = OK (200)

5. IMS informs CM about CM_CALL_EVENT_SUPS.

Call Manager/High 19:56:01.864 [ cmipapp.c 3997] =CM= RPT name
617
Call Manager/High 19:56:01.864 [ cmtask.c 10546] =CM= CM<< IP
cmd:617

6. IMS receives 200 OK from SIP server also known as P-CSCF.

MSG [00051/03] IMS/Error 04:37:50.661 Z:/M8960AAAAATAAM4 01424 1424|
QimfSipActiveObj::ProcessMessage | Received Message is SIP/2.0 200 OK

7. IMS sends ACK to SIP server.

MSG [00051/03] IMS/Error 04:37:50.710 Z:/M8960AAAAATAAM4 03213 3213|
EVENT_SIP_REQUEST_SEND: ACK
sip:1212@[2002:c023:9c17:589:785d:1e43:4a2d:a510]:5060 SIP/2.0 f: <s

8. IMS posts indication to CM about CALL Retrieve event.

/* 607 = CM_IP_CALL_IND_CALL_RETRIEVE */
MSG [00005/02] Call Manager/High 04:37:50.733 cmipapp.c 02690 =CM= RPT
name 607
MSG [00005/02] Call Manager/High 04:37:50.733 cmipcall.c 02055 =CM= RXD:
CALL_RETRIEVE

9. CM posts indication to QMI about call_event_retrieved.

Call Manager/High 19:56:01.865 [ cmipapp.c 3997] =CM= RPT name
607
Call Manager/High 19:56:01.865 [ cmtask.c 10546] =CM= CM<< IP
cmd:607
Call Manager/High 19:56:01.865 [ cmipcall.c 3751] =CM= IP RXD:
CALL_RETRIEVE, id=4, as_id=0

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 85

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

10. IMS posts confirmation event to CM that call has been successfully retrieved
Call Manager/High 19:56:01.865 [ cmtask.c 10546] =CM= CM<< IP
cmd:609
Call Manager/High 19:56:01.865 [ cmipcall.c 3904] =CM= IP RXD:
SUPS_CONF, sups_type=17, num_part=0, participant=0x0 id=4, rpt asubs_id=0,
is_ims_cap_on_sub=1

11. QMI sends response to UI.

19:56:01.866 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_all_call_status {
call_state = CALL_STATE_CONVERSATION

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 86

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.9 Call add call flow and log analysis

The following call flow and log analysis describe the call add process in the UE:

Figure 4-17 Call add call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 87

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

1. VoLTE call has been established.

2. UI holds the call via QMI.
00:03:19.060 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_manage_ip_calls {
sups_type = VOIP_SUPS_TYPE_CALL_HOLD

3. CM holds the call.

Call Manager/High 00:03:19.060 [ cm.c 7071] =CM=
CM_CALL_CMD_SUPS client 17, sups_type 16, as_id 0
Call Manager/Medium 00:03:19.060 [ cmipapp.c 5634] =CM= CM-
>IMS: CMIPAPP: Send Hold for call 2, as_id 0

4. Call is put on Hold. See Figure 4-15 for more details

5. CM informs QMI about call on hold event received.
Call Manager/High 00:03:19.258 [ cmipapp.c 3997] =CM= RPT name
606
Call Manager/High 00:03:19.258 [ cmtask.c 10546] =CM= CM<< IP
cmd:606
Call Manager/High 00:03:19.258 [ cmipcall.c 3544] =CM= IP RXD:
CALL_HOLD, id=2, as_id=0

6. The call status is relayed back up to QMI.

00:03:19.260 [0x1544] MCS QCSI Payload Packet Service_VOICE {
voice_all_call_status {
call_info {
call_id = 1
call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MO

7. MO call establishment; see Mobile-originated call setup for more details

00:03:19.407 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_dial_call {
calling_number {
calling_number = +12345678902
}
call_type {
call_type = CALL_TYPE_VOICE
}

8. QMI informs UI about call status from CM and IMS.

IMS/High 00:03:19.845 [ qpDplCallCtrl.c 7599]
qpDplCallCtrlReportInd: eRptNameType = 604
IMS/High 00:03:19.845 [ qpDplCallCtrl.c 7609]
qpDplCallCtrlReportInd: calling cmipapp_rpt_ind
Call Manager/High 00:03:19.845 [ cmtask.c 10546] =CM= CM<< IP

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 88

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

cmd:604
Call Manager/High 00:03:19.845 [ cmipcall.c 2882] =CM= DS: SUB
1 IP RXD: CONNECTED, id=4, as_id=0
Call Manager/High 00:03:19.845 [ cmlog.c 2279] =CM=
EVENT_CM_CALL_EVENT_CONNECT_2 - asubid 0

00:03:19.845 [0x1544] MCS QCSI Payload Packet

Service_VOICE {
voice_all_call_status {
call_info {
call_id = 2
call_state = CALL_STATE_CONVERSATION
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MO
call_id = 1
call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MO

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 89

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.10 Call waiting call flow and log analysis

The following call flow and log analysis describe the call waiting process in the UE:

Figure 4-18 Call waiting call flow

1. After the VoLTE call is established, a third UE, UE3 initiates a call with UE1 via the Invite message
(INVITE/180/PRACK/200 OK(PRACK)).
19:55:28.086 [0x156E] IMS SIP Message
Direction = NETWORK_TO_UE
Message ID = IMS_SIP_INVITE

2. IMS processes the call sending out a 180 Ringing message and indicates to CM that a call has
been received.
IMS/High 19:55:28.096 [ qipcallh.c 20271]
qipcallh_process_incoming_call : RAT type 10

IMS/High 19:55:28.101 [ qpDplCallCtrl.c 7599]

qpDplCallCtrlReportInd: eRptNameType = 601
IMS/High 19:55:28.101 [ qpDplCallCtrl.c 7609]
qpDplCallCtrlReportInd: calling cmipapp_rpt_ind

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 90

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

IMS SIP/High 19:55:28.116 [ qpSipUtils.cpp 3393]

EVENT_SIP_RESPONSE_SEND: SIP/2.0 180 Ringing

3. CM receives an indication that a call has been received

Call Manager/High 19:55:28.101 [ cmipapp.c 3997] =CM= RPT name
601
Call Manager/High 19:55:28.101 [ cmipapp.c 3641] =CM=
cmippap_add_ref :Added ref for caller_info, info_text
Call Manager/High 19:55:28.101 [ cmtask.c 10546] =CM= CM<< IP
cmd:601

4. QMI indicates to UI that there is a call waiting.

19:55:28.285 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
ServiceVOICEV2 {
voice_all_call_status {
call_state = CALL_STATE_WAITING

5. UI holds the existing call first. See Call hold call flow and log analysis for details.
6. UI answers the waiting call. See Figure 4-11 for details.
7. The final state is one call, where the waiting call is active, while the original call is in held state.
19:55:38.676 [0x1544] MCS QCSI Payload Packet
QmiLength = 191
Service_VOICE {
voice_all_call_status {
num_of_instances = 2
call_id = 2
call_state = CALL_STATE_CONVERSATION
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MT
call_id = 1
call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP
direction = CALL_DIRECTION_MO

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 91

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.11 Call conferencing call flow and log analysis

The following call flow and log analysis describe the call conferencing process in the UE:

Figure 4-19 Call conferencing call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 92

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

■ Precondition – UE1 has UE2 on hold and is in an active call with UE3.
a. When UE1 receives the request to start a conference, it puts the active call with UE3 on hold.
b. UE1 creates the conference via an INVITE message sent to the conference uniform resource
identifier (URI).
c. UE1 sends a REFER message to the conference server with the URI of the UE that is to be
added to the conference. In this case, it is UE2.
d. UE2 receives an INVITE message from the conference server and UE1 receives NOTIFY
indications for the 100 Trying and the 200 OK messages received on the conference server
from UE2.
e. UE1 ends the call with UE2 after receiving the Notify message that UE2 has accepted the call
with the conference server.
f. Repeat steps 3a through 5b of Figure 4-19 for adding UE3 into the conference call.

NOTE At the end of this setup process, each UE is in an independent point-to-point call with the
conference server that does the multiplexing of the media.

Precondition – VoIP call between UE1 and UE2 is on HOLD and there is an initiated VoIP call between
UE1 and UE3 in conversation.
00:03:19.845 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_all_call_status {
call_info {
call_id = 2
call_state = CALL_STATE_CONVERSATION
call_type = CALL_TYPE_VOICE_IP
call_id = 1
call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP

1. UI requests a call conference through QMI.

00:03:30.774 [0x1544] MCS QCSI Payload Packet
voice_manage_ip_calls {
sups_type {
sups_type = VOIP_SUPS_TYPE_MAKE_CONFERENCE_CALL

2. CM receives the request through QMI. CM informs IMS to put the call between UE1 and UE3 on
hold.
00:03:30.774 Call Manager/High [ cmipcall.c 4849] =CM= IP
CALLCMD: cmd=3, as_id=0, is_ims_cap_on_sub=1
00:03:30.774 Call Manager/High [ cmipapp.c 6247] =CM= CM->IMS:
CMIPAPP: Send cmd MPTY to app 1, as_id 0
00:03:30.774 IMS/High [ qipcallh.c 36118]
qipcallh_process_call_request: eCallCbType = 13
Once the SIP re-INVITE to put call with UE3 on hold succeeds, the
indication is sent to CM.
00:03:30.955 IMS/High [ qpDplCallCtrl.c 7599]
qpDplCallCtrlReportInd: eRptNameType = 606
00:03:30.955 Call Manager/High [ cmtask.c 10546] =CM= CM<< IP

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 93

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

cmd:606
00:03:30.955 Call Manager/High [ cmipcall.c 3544] =CM= IP RXD:
CALL_HOLD, id=4, as_id=0

3. QMI indicates to the UI that both calls are on hold.

00:03:30.956 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_all_call_status {
call_info {
call_id = 2
call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP
call_id = 1
call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP

4. IMS receives the request for a multiparty call.

00:03:30.960 Call Manager/High [ cmipapp.c 5238] =CM= CM->IMS:
CMIPAPP: Sending IP orig, sys_mode 512, app_id 1 pi 0 orig call_id 5,
call_type 1, as_id 0
00:03:30.960 IMS/High [ qipcallh.c 36118]
qipcallh_process_call_request: eCallCbType = 0

5. IMS via the framework sends out the Invite message to connect to the conference server.
00:03:30.991 [0x156E] IMS SIP Message
Direction = UE_TO_NETWORK
Message ID = IMS_SIP_INVITE
00:03:31.499 [0x156E] IMS SIP Message
Direction = NETWORK_TO_UE
Response Code = OK (200)

6. The status of the conference call is indicated by CM to QMI to be sent to the UI.
00:03:31.503 IMS/High [ qipcall.c 1403]
qipcall_process_messages_from_qimfif: Rxed Connected - Incoming
Established
00:03:31.513 IMS/High [ qpDplCallCtrl.c 7609]
qpDplCallCtrlReportInd: calling cmipapp_rpt_ind
00:03:31.513 Call Manager/High [ cmipapp.c 3997] =CM= RPT name
617

7. QMI sends the indication to the UI.

00:03:31.516 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_all_call_status {
call_info {
call_id = 3
call_state = CALL_STATE_CONVERSATION
call_type = CALL_TYPE_VOICE_IP
call_id = 2

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 94

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP
call_id = 1
call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP

8. Once the call with conference server is established, the UE sends a Refer message to add UE2 to
the conference call.
00:03:31.684 [0x156E] IMS SIP Message
Message ID = IMS_SIP_REFER
r: <sip:[email protected];user=phone;method=INVITE?
Replaces=177060_2146267772%40fc01:bbbb:cdcd:efe0:6233:fd0:e986:1791%3Bto-
tag%3Dabc-InviteToTag1%3Bfrom-tag%3D177065>
Once UE1 terminates the call to UE2 via a BYE, a message sent via the SIP
stack.
00:03:33.044 [0x156E] IMS SIP Message
Message ID = IMS_SIP_BYE
t: <sip:[email protected];user=phone>;tag=abc-InviteToTag1

9. Call end status of UE1 to UE2 is indicated to QMI to be notified to the UI.
00:03:33.032 IMS/High [ qipcallh.c 8921]
qipcallh_chg_state_to_null: end_reason = 0, end_request_type = 2

00:03:33.064 Call Manager/High [ cmipapp.c 3997] =CM= RPT name

605
00:03:33.064 Call Manager/High [ cmipcall.c 3135] =CM= AS_ID 0,
IP RXD: CALL_END, end_cause=0, client_end_cause=-1, call_id=2,
call_state=3, is_lte_hard_failure=0

10. The status of the UE1 to UE2 call is indicated to the UI via QMI.
00:03:33.066 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_all_call_status {
call_info {
call_id = 3
call_state = CALL_STATE_CONVERSATION
call_type = CALL_TYPE_VOICE_IP
call_id = 2
call_state = CALL_STATE_HOLD
call_type = CALL_TYPE_VOICE_IP
call_id = 1
call_state = CALL_STATE_END
call_type = CALL_TYPE_VOICE_IP

11. UE sends a refer message to add UE3 to the conference call.

00:03:33.061 [0x156E] IMS SIP Message
Message ID = IMS_SIP_REFER
r: <sip:[email protected];user=phone;method=INVITE?

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 95

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

Replaces=199422_2146420908%40fc01:bbbb:cdcd:efe0:6233:fd0:e986:1791%3Bto-
tag%3Dabc-InviteToTag2%3Bfrom-tag%3D199434>

12. After UE3 is added to the conference, IMS sends a SIP BYE message to end the call with UE3.
00:03:34.170 [0x156E] IMS SIP Message
Message ID = IMS_SIP_BYE
t: <sip:[email protected];user=phone>;tag=abc-InviteToTag2

13. Call End status of UE1 to UE3 is indicated to QMI to be notified to the UI.
00:03:34.177 IMS/Medium [qipcall_indication.c 455]
qipcall_call_end_rpt_ind: call_id=4, state=1, cause=0, error code=-1, sip
error code=0
00:03:34.177 Call Manager/High [ cmipcall.c 3135] =CM= AS_ID 0,
IP RXD: CALL_END, end_cause=0, client_end_cause=-1, call_id=4,
call_state=3, is_lte_hard_failure=0

14. The status of the UE1 to UE3 call is indicated to the UI via QMI.
00:03:34.180 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_all_call_status {
call_info {
call_id = 3
call_state = CALL_STATE_CONVERSATION
call_type = CALL_TYPE_VOICE_IP
call_id = 2
call_state = CALL_STATE_END
call_type = CALL_TYPE_VOICE_IP

15. IMS sends an indication of the conference call status to CM.

00:03:34.177 IMS/High [qipcall_conf_and_transfer_call.c 4868]
QIPCALLE_TRANSFER_STATE_CONFERENCE status = 1, participants added = 2

16. CM receives an indication of the conference call and sends to QMI to inform the UI.
00:03:34.179 Call Manager/High [ cmipcall.c 3904] =CM= IP RXD:
SUPS_CONF, sups_type=5, num_part=2, participant=0x7fedc9a0 id=5, rpt
asubs_id=0, is_ims_cap_on_sub=1

17. QMI indicates the result of the Manage Call to the UI.
00:03:34.180 [0x1544] MCS QCSI Payload Packet
voice_manage_ip_calls{
result = QMI_RESULT_SUCCESS

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 96

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.11.1 Call conference subscribe event package

Figure 4-20 Call conference subscribe event package call flow

Precondition – UE1, UE2, and UE3 have each established a call with the conference server and are
logically in the same conference.
1. UE1 subscribes to the conference event package and receives the full state of the conference.
2. The UE2 and UE3 subscribe to the events of the server.
3. UE3 leaves the conference by sending a BYE. The other subscribed members of the conference
get a Notify informing them of this BYE.
The first Notify message that comes after the subscribe gives the full state of the conference call. All
subsequent Notify updates are partial states with changes of that initial conference state.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 97

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

4.12 DTMF call flow and logs analysis

Dual-tone multifrequency (DTMF) tones acts as interactive voice response. The following call flow and
log analysis help in debugging DTMF call scenarios:

Figure 4-21 DTMF call flow

Precondition – VoIP call between UE1 and UE2 on VoIP call-in conversation.
1. Digit is pressed. CM receives the DTMF start request.
02:36:00.332 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
ServiceVOICEV2 {
voice_start_cont_dtmf {
cont_dtmf_info {
call_id = 255
digit = 48
Call Manager/Medium 02:36:00.332 [ cmipapp.c 5520] =CM= CM-
>IMS: CMIPAPP: Send start inband DTMF for call 6, as_id 0
02:36:00.333 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_start_cont_dtmf {

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 98

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

resp {
result = QMI_RESULT_SUCCESS
error = QMI_ERR_NONE
}

2. DTMF is sent over RTP after IMS receives it from CM.

IMS/High 02:36:00.333 [ qipcalldtmf.c 369]
qipcall_start_dtmf_rpt_conf: Block call rpt ind = 0,Call Id=6, State=14,
status = 1
IMS/Medium 02:36:00.353 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 40, end_bit = 0
IMS/Medium 02:36:00.373 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 60, end_bit = 0
IMS/Medium 02:36:00.394 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 80, end_bit = 0
IMS/Medium 02:36:00.414 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 100, end_bit = 0
IMS/Medium 02:36:00.434 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 120, end_bit = 0
IMS/Medium 02:36:00.454 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 140, end_bit = 0
IMS/Medium 02:36:00.474 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 160, end_bit = 0
IMS/Medium 02:36:00.495 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 180, end_bit = 0
IMS/Medium 02:36:00.514 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 200, end_bit = 0
DS Real Time Transport Protocol/High 02:36:00.353 [ qvp_rtp_app_cmd.c
2679] sending DTMF \n
DS Real Time Transport Protocol/High 02:36:00.353 [ qvp_rtp_app_cmd.c
2779] Sending DTMF Len = 4, timestamp = 83200,
marker = 0

3. Digit is released.
02:36:00.517 [0x1544] MCS QCSI Payload Packet
MsgType = Request
Service_VOICE {
voice_stop_cont_dtmf {
IMS/High 02:36:00.517 [ qipcalldtmf.c 612] Stop DTMF event: 0x30,
duration = 200, call id = 6
IMS/High 02:36:00.517 [ qipcalldtmf.c 414]
qipcall_stop_dtmf_rpt_conf: Block call rpt ind 0. Call Id=6, State=14,
status =1
IMS/Medium 02:36:00.535 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 220, end_bit = 1
IMS/Medium 02:36:00.555 [ qipcalldtmf.c 886] -----> Sending dtmf
for digit = 48, duration = 220, end_bit = 1
IMS/Medium 02:36:00.575 [ qipcalldtmf.c 886] -----> Sending dtmf

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 99

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

for digit = 48, duration = 220, end_bit = 1

02:36:00.517 [0x1544] MCS QCSI Payload Packet
Service_VOICE {
voice_stop_cont_dtmf {

4.13 Audio codec profile configuration

Default audio codec profile configuration per operator or for IR92 can be found in OEM override files in
the following location:
modem_proc\datamodem\ims\Configuration\ConfigFramework\OEM_OVERRIDE_FILES
\sdm845.gen.testQ
If any changes are needed in this default configuration, modify respective parameters by adding ‘*’ at
the beginning as shown in Figure 4-22. See IMS NV Reduction (80-P8761-1) for more details.
This audio codec profile configuration has the following:
■ AMR_0_106: AMR-WB octet aligned with PT=106
■ AMR_1_107: AMR-WB bandwidth efficient with PT=107

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 100

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

■ AMR_2_104: AMR-NB octet aligned with PT=104

■ AMR_3_105: AMR-NB bandwidth efficient with PT=105

NOTE PT= PayloadType

Figure 4-22 Codec Configuration parameter

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 101

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS VoLTE architecture

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 102

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
5 IMS UT interface

The UT interface in IMS is used for supplementary services like the following:
■ Storing call routing information on a network database (DB)
■ Call waiting
■ Originating identity presentation (OIP)
■ Originating identification restriction (OIR)
■ Terminating identity presentation (TIP)
■ Terminating identity restriction (TIR)
■ Incoming call barring (ICB)
■ Outgoing call barring (OCB)
■ Call forwarding unconditional (CFU)

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 103

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

Provisioning back-end (PBE) is the interface between the UT server and the DB.

Figure 5-1 Network Architecture for UT interface

5.1 UT call flows and log analysis

The following call flows and log analysis can be used to debug various UT call scenarios.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 104

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

5.1.1 UT PDN bringup

The call flow and log messages for the UT PDN bringup are as follows:

Figure 5-2 UT PDN bring up call flow

1. DS informs UT that the RAT has changed.
2. UT checks if the RAT is valid, based on the RAT mask configured. If the RAT is valid, then the
PDN is established using the APN configured for UT.
MSG IMS/Medium 14:27:10.312 PDPHandler.cpp 00457
CPDPHandler::EventChangeRat - New RAT = 10
MSG IMS/Medium 14:27:10.312 PDPHandler.cpp 00467
CPDPHandler::EventChangeRat - New RAT is valid: 1
MSG IMS/High 15:08:55.613 PDPHandler.cpp 00192 CPDPHandler =====

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 105

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

PdpActivate state 1
MSG IMS DPL/High 15:08:55.613 /local/mnt/workspa 03837 3837|
qpDcmEstablishPDPConnection - APNName -->nxtgenphone
MSG IMS/High 15:08:55.623 PDPHandler.cpp 00195 CPDPHandler =====
PdpActivate PDPConnection established

NOTE The UE may not request UT PDN bring up if a PDN connection already exists with
the APN configured for UT.

5.1.2 Activate call waiting

The call flow and log messages for activating call waiting are as follows:

Figure 5-3 Activate call waiting call flow

1. User dials *43# to activate call waiting.
2013 Mar 14 15:30:32.320 [00] 0x138E QMI Link 1 RX PDU
SduCtlFlags = REQ
MsgType = QMI_VOICE_SET_SUPS_SERVICE
Supplementary Service Info {
Service = Activate
Reason = CallWaiting
}
}
2013 Mar 14 15:30:32.325 [00] 0x138F QMI Link 1 TX PDU
MsgType = QMI_VOICE_SUPS_IND

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 106

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

MSG IMS/Error 15:30:32.503 /local/mnt/workspa 00549 549|

HttpConnection::Send| HTTP message :PUT /simservs.ngn.etsi.org/users/tel:
+15124210030/simservs.xm
MSG IMS/Error 15:30:32.503 /local/mnt/workspa 00549
ut.gtm.itn.att.net:80 User-Agent: XDM-Client/OMA1.0
<communication-waiting active="true"/>

2. Server responds with 200 OK indicating success.

MSG IMS/Error 15:30:32.936 /local/mnt/workspa 00864 864|
HttpConnection::ProcessMessage|Response:HTTP/1.1 200 OK X-Powered-By:
Servlet/3.0 Content-Langu
MSG IMS/High 15:30:32.936 QimfHttp.cpp 01064
HttpConnection::Process2xxMessage|Received 200 response.
2013 Mar 14 15:30:32.939 [00] 0x138F QMI Link 1 TX PDU
SduCtlFlags = RSP
MsgType = QMI_VOICE_SET_SUPS_SERVICE
QmiResult = QMI_RESULT_SUCCESS
QmiError = QMI_ERROR_NONE

5.1.3 Interrogate current call waiting setting

The call flow and log messages for interrogating the current call waiting setting are as follows:

1. User dials *#43# to interrogate current call waiting setting.

2013 Mar 14 15:33:47.340 [00] 0x138E QMI Link 1 RX PDU
SduCtlFlags = REQ

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 107

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

MsgType = QMI_VOICE_GET_CALL_WAITING
2013 Mar 14 15:33:47.345 [00] 0x138F QMI Link 1 TX PDU
MsgType = QMI_VOICE_SUPS_IND
MSG IMS/Error 15:33:47.515 /local/mnt/workspa 00549 549|
HttpConnection::Send| HTTP message :GET /simservs.ngn.etsi.org/users/tel:
+15124210030/simservs.xm

2. Server responds with 200 OK indicating success.

MSG IMS/Error 15:33:47.810 /local/mnt/workspa 00864 864|
HttpConnection::ProcessMessage|Response:HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 Content-Langu
MSG IMS/High 15:33:47.810 QimfHttp.cpp 01064
HttpConnection::Process2xxMessage|Received 200 response.
MSG IMS/Error 15:33:47.811 /local/mnt/workspa 00427 427|<XML Module>:
CommunicationWaitingUnMarshaller::UnMarshall: pstring is <ss:communication-
waiting a
2013 Mar 14 15:33:47.814 [00] 0x138F QMI Link 1 TX PDU
SduCtlFlags = RSP
MsgType = QMI_VOICE_GET_CALL_WAITING
QmiResult = QMI_RESULT_SUCCESS
QmiError = QMI_ERROR_NONE

5.1.4 Deactivate call waiting

The call flow and log messages for deactivating call waiting are as follows:

Figure 5-4 Deactivate call waiting call flow

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 108

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

1. User dials #43# to deactivate call waiting.

2013 Mar 14 15:38:15.315 [00] 0x138E QMI Link 1 RX PDU
SduCtlFlags = REQ
MsgType = QMI_VOICE_SET_SUPS_SERVICE
Supplementary Service Info {
Service = Deactivate
Reason = CallWaiting
}
}
2013 Mar 14 15:38:15.320 [00] 0x138F QMI Link 1 TX PDU
MsgType = QMI_VOICE_SUPS_IND
MSG IMS/Error 15:38:15.506 /local/mnt/workspa 00549 549|
HttpConnection::Send| HTTP message :PUT /simservs.ngn.etsi.org/users/tel:
+15124210030/simservs.xm
MSG IMS/Error 15:38:15.506 /local/mnt/workspa 00549
ut.gtm.itn.att.net:80
User-Agent: XDM-Client/OMA1.0 <communication-waiting active="false"/>

2. Server responds with 200 OK indicating success.

MSG IMS/Error 15:38:15.956 /local/mnt/workspa 00864 864|
HttpConnection::ProcessMessage|Response:HTTP/1.1 200 OK X-Powered-By:
Servlet/3.0 Content-Langu
MSG IMS/High 15:38:15.956 QimfHttp.cpp 01064
HttpConnection::Process2xxMessage|Received 200 response.
2013 Mar 14 15:38:15.960 [00] 0x138F QMI Link 1 TX PDU
SduCtlFlags = RSP
MsgType = QMI_VOICE_SET_SUPS_SERVICE
QmiResult = QMI_RESULT_SUCCESS
QmiError = QMI_ERROR_NONE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 109

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

5.1.5 Activate call forwarding unconditional

The call flow and log messages for activating call forwarding unconditional are as follows:

Figure 5-5 Activate call forwarding unconditional call flow

1. User dials *21*7147024404# in order to activate CFU.
1 2013 Mar 14 15:59:47.020 [00] 0x138E QMI Link 1 RX PDU
SduCtlFlags = REQ
MsgType = QMI_VOICE_SET_SUPS_SERVICE
Supplementary Service Info {
Service = Register
Reason = Fwd Conditional
}
}
Tlvs[1] {
Type = 18
Length = 10
UnknownTlv {
Hex dump = {
55, 49, 52, 55, 48, 50, 52, 52,
48, 52
}
}
}

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 110

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

2 2013 Mar 14 15:59:47.026 [00] 0x138F QMI Link 1 TX PDU

MsgType = QMI_VOICE_SUPS_IND
MSG IMS/Error 15:59:47.203 /local/mnt/workspa 00549 549|
HttpConnection::Send| HTTP message :PUT /simservs.ngn.etsi.org/users/tel:
+15124210030/simservs.xm
MSG IMS/Error 15:59:47.203 /local/mnt/workspa 00549 ons><forward-
to><target>tel:7147024404</target></forward-to></cp:actions></cp:rule>

2. Server responds with 200 OK indicating success.

MSG IMS/Error 15:59:47.775 /local/mnt/workspa 00864 864|
HttpConnection::ProcessMessage|Response:HTTP/1.1 200 OK X-Powered-By:
Servlet/3.0 Content-Langu
MSG IMS/High 15:59:47.775 QimfHttp.cpp 01064
HttpConnection::Process2xxMessage|Received 200 response.
.
2013 Mar 14 15:59:47.778 [00] 0x138F QMI Link 1 TX PDU
SduCtlFlags = RSP
MsgType = QMI_VOICE_SET_SUPS_SERVICE
QmiResult = QMI_RESULT_SUCCESS
QmiError = QMI_ERROR_NONE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 111

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

5.1.6 Interrogate CFU setting

The call flow and log messages for interrogating CFU setting are as follows:

Figure 5-6 Interrogate CFU setting call flow

1. User dials *#21# to interrogate CFU setting.
2013 Mar 14 16:02:15.531 [00] 0x138E QMI Link 1 RX PDU
SduCtlFlags = REQ
MsgType = QMI_VOICE_GET_CALL_FORWARDING
Reason = FWDREASON_UNCONDITIONAL
}
}
2013 Mar 14 16:02:15.536 [00] 0x138F QMI Link 1 TX PDU
MsgType = QMI_VOICE_SUPS_IND
MSG IMS/Error 16:02:15.708 /local/mnt/workspa 00549 549|
HttpConnection::Send| HTTP message :GET /simservs.ngn.etsi.org/users/tel:
+15124210030/simservs.xm

2. Server responds with 200 OK indicating success.

MSG IMS/Error 16:02:16.110 /local/mnt/workspa 00864 864|
HttpConnection::ProcessMessage|Response:HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 112

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

Content-Langu
MSG IMS/High 16:02:16.110 QimfHttp.cpp 01064
HttpConnection::Process2xxMessage|Received 200 response.
.
2013 Mar 14 16:02:16.128 [00] 0x138F QMI Link 1 TX PDU
MsgType = QMI_VOICE_GET_CALL_FORWARDING
QmiResult = QMI_RESULT_SUCCESS
QmiError = QMI_ERROR_NONE

5.1.7 Deactivate CFU service and retain configuration

The call flow and log messages for deactivating CFU serving and retaining configuration are as
follows:

Figure 5-7 Deactivate CFU service and retain configuration

1. User dials #21# to deactivate CFU service and retain configuration
2013 Mar 14 16:11:02.195 [00] 0x138E QMI Link 1 RX PDU
SduCtlFlags = REQ
MsgType = QMI_VOICE_SET_SUPS_SERVICE
Supplementary Service Info {
Service = Deactivate
Reason = Fwd Conditional
}
}
2013 Mar 14 16:11:02.201 [00] 0x138F QMI Link 1 TX PDU

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 113

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

MsgType = QMI_VOICE_SUPS_IND
MSG IMS/Error 16:02:15.708 /local/mnt/workspa 00549 549|
HttpConnection::Send| HTTP message :GET /simservs.ngn.etsi.org/users/tel:
+15124210030/simservs.xm

2. Server responds with 200 OK indicating success.

MSG IMS/Error 16:11:02.895 /local/mnt/workspa 00864 864|
HttpConnection::ProcessMessage|Response:HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 Content-Langu
MSG IMS/High 16:11:02.895 QimfHttp.cpp 01064
HttpConnection::Process2xxMessage|Received 200 response.
.
2013 Mar 14 16:11:02.898 [00] 0x138F QMI Link 1 TX PDU
SduCtlFlags = RSP
MsgType = QMI_VOICE_SET_SUPS_SERVICE
QmiResult = QMI_RESULT_SUCCESS
QmiError = QMI_ERROR_NONE

5.1.8 Deactivate CFU service and erase target number

The call flow and log messages for deactivating CFU serving and erasing target number are as
follows:

Figure 5-8 Deactivate CFU service and erase target number

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 114

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

1. User dials ##21# to deactivate CFU service and erase target number.
2013 Mar 14 16:15:58.900 [00] 0x138E QMI Link 1 RX PDU
SduCtlFlags = REQ
MsgType = QMI_VOICE_SET_SUPS_SERVICE
Supplementary Service Info {
Service = Erase
Reason = Fwd Conditional
}
}
2013 Mar 14 16:15:58.906 [00] 0x138F QMI Link 1 TX PDU
MsgType = QMI_VOICE_SUPS_IND
MSG IMS/Error 16:15:59.080 /local/mnt/workspa 00549 549|
HttpConnection::Send| HTTP message :PUT /simservs.ngn.etsi.org/users/tel:
+15124210030/simservs.xm
MSG IMS/Error 16:15:59.080 /local/mnt/workspa 00549
conditions><cp:actions><forward-to><target></target></forward-to></
cp:actions></cp:rule>

2. Server responds with 200 OK indicating success.

MSG IMS/Error16:15:59.595 /local/mnt/workspa 00864 864|
HttpConnection::ProcessMessage|Response:HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0 Content-Langu
MSG IMS/High 16:15:59.595 QimfHttp.cpp 01064
HttpConnection::Process2xxMessage|Received 200 response.
.
2013 Mar 14 16:15:59.599 [00] 0x138F QMI Link 1 TX PDU
SduCtlFlags = RSP
MsgType = QMI_VOICE_SET_SUPS_SERVICE
QmiResult = QMI_RESULT_SUCCESS
QmiError = QMI_ERROR_NONE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 115

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

5.1.9 Reactivate CFU using existing configuration

The call flow and log messages for reactivating CFU using existing configuration are as follows:

Figure 5-9 Reactivate CFU using existing configuration

1. User dials *21# to reactivate CFU using existing configuration.
2013 Mar 14 16:22:49.521 [00] 0x138E QMI Link 1 RX PDU
SduCtlFlags = REQ
MsgType = QMI_VOICE_SET_SUPS_SERVICE
Supplementary Service Info {
Service = Activate
Reason = Fwd Conditional
}
}
2013 Mar 14 16:22:49.528 [00] 0x138F QMI Link 1 TX PDU
MsgType = QMI_VOICE_SUPS_IND
MSG IMS/Error 16:22:49.713 /local/mnt/workspa 00549 549|
HttpConnection::Send| HTTP message :PUT /simservs.ngn.etsi.org/users/tel:
+15124210030/simservs.xm

2. Server responds with 200 OK indicating success.

MSG IMS/Error16:22:50.287 /local/mnt/workspa 00864 864|
HttpConnection::ProcessMessage|Response:HTTP/1.1 200 OK
X-Powered-By: Servlet/3.0
Content-Langu

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 116

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS UT interface

MSG IMS/High 16:22:50.287 QimfHttp.cpp 01064

HttpConnection::Process2xxMessage|Received 200 response.
.
2013 Mar 14 16:22:50.291 [00] 0x138F QMI Link 1 TX PDU
SduCtlFlags = RSP
MsgType = QMI_VOICE_SET_SUPS_SERVICE
QmiResult = QMI_RESULT_SUCCESS
QmiError = QMI_ERROR_NONE

5.2 Enable or disable UT

The IMS setting API is used to dynamically enable/disable UT at runtime. The command from UI to
modem is as follows:
QMI_IMS_SETTINGS_SET_UT_CONFIG_REQ (boolean disable_ut)

5.3 XCAP error messages

When a supplementary service request is invoked, a request might fail on the network with an error
code 409 (conflict). When this error is provided by the network, a failure description string may also be
sent. This string must be sent to the applications for display. OEM must display the error on the UI
according to the network operator requirements. The following QMI command updates the response
received from server to AP:
QMI_VOICE_SET_SUPS_SERVICE_RESP (voice_set_sups_failure_desc)

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 117

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
6 IMS Wi-Fi handover

This chapter explains the handover between LTE to industrial wireless LAN (IWLAN) and vice versa. It
also covers the handover between the different states of the UE such as idle and connected.

6.1 Handover between IWLAN and LTE

There are two common scenarios where a handover takes place:
■ While the UE is in idle state
■ While the UE is in connected state
Different operators have different algorithms in place for determining which metrics are involved in
determining the handover process, so the call flows have been kept general on purpose.
The log messages listed are common to all of the handover scenarios and are used as markers to
determine whether the handover is taking place and between which RATs it is taking place.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 118

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

6.1.1 Handover between LTE and IWLAN while UE is in idle state

The call flow and log messages for the handover between LTE and IWLAN while UE is in idle state are
as follows:

Figure 6-1 IWLAN to LTE handover during idle state call flow
1. IMS registers with CNE for measurement reports.
20:01:21.603 qpDplHandOver.c 04695 qpDplWiFiMeasurementsSetParamEx:
Received START Command
20:01:21.603 qpDplHandOver.c 04628 DplHandOverSetCNEProfileForMetrics
- Profile Mask set by IMS --> 0x000000000000000f | DS mask -->
0x4f646e61486c704

2. CNE provides measurements when thresholds are reached that are cached in IMS.
The CNE event comes via DS Sys events.
20:01:31.604 qpDcm.c 11242 qpDplProcessCommonDSSysEvents:
CNE_PROFILE_MET Mask --> 0x0
HOAlgoFlavor represents the algorithm type that is in use.
1 – VzW
0 – Other

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 119

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

20:01:31.605 qpDplHandOver.c 04928 DplHandOverProcessCNEReport -

HOAlgoFlavor -->1
The UE checks whether a handover is possible. In the example below,
handover is not possible, as indicated by HO possible = 0.
srat = source rat trat = target rat
LTE – 10
iWLAN – 6
20:01:31.605 qpDplHandOver.c 03641 IsHandOverPossible: current srat =
10 trat= 6 prefrat = 10
20:01:31.605 qipcalliface_ho_mgr.c 03417
qipcalliface_process_handover_measurement_cb: SRAT = 10, TRAT = 6,
pHOStatus->bIsHOPossible 0 ===>
20:01:31.607 qipcalliface_ho_mgr.c 02271
qipcalliface_is_wwan_iwlan_handover_required: current system = 1, HO
possible = 0, pref system 0

3. IMS checks whether to do a handover.

NOTE There are other places where IMS checks for the possibility of a handover, but those
other places are operator-specific and are outside the scope of this document.
□ A RAT change triggers IMS to check if a handover is required
□ If SRAT 0 => source RAT, it indicates that there is no RAT, that is, LTE signal is lost
20:03:04.463 qipcalliface_ho_mgr.c 03172
qipcalliface_is_wwan_iwlan_measurement_params_changed: HO params changed
SRAT 0, TRAT 6, PrefRAT = 10
20:03:04.464 qpDplHandOver.c 03641 IsHandOverPossible: current srat =
0 trat= 6 prefrat = 10
IMS determines if handover is possible and the preferred system to handover to, based on the
metrics.
□ If HO possible = 1, then handover is possible
□ pref system 2 => preferred system is iWLAN
20:03:04.465 qipcalliface_ho_mgr.c 02271
qipcalliface_is_wwan_iwlan_handover_required: current system = 1, HO
possible = 1, pref system 2

4. IMS requests the APN to be moved to ePDG.

Preferred system:
□ 0 – WWAN
□ 2 – IWLAN
20:03:04.465 qipcalliface_ho_mgr.c 00374 qipcalliface_set_APN_pref_sys:
Handover requested to preffered sys 2
20:03:04.465 qipcalliface_ho_mgr.c 00920
qipcalliface_perform_handover_management :
HO conditions changed. Initiate HO to sys 2
HO conditions changed. Initiate HO to sys 2

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 120

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

5. IPSec tunnel moves IMS PDN to Wi-Fi

6. DS indicates to IMS that the handover is complete and successful.
20:03:07.697 PDPRATHandlerVoLTE.cpp 01981 EventHOSuccess HORat:6
currRAT:10 RegType[0]
20:03:07.697 PDPRATHandlerVoLTE.cpp 01988 EventHOSuccess raise event
RegType[0]

7. IMS initiates REGISTRATION with the PANI header set to Wi-Fi access.
20:03:07.741 sipConnection.cpp 03067 EVENT_SIP_REG_REQ_SENT: 43 Code =
0 RAT = 6
20:03:07.742 sipConnection.cpp 03823 EVENT_SIP_REQUEST_SEND: REGISTER
sip:test.3gpp.com SIP/2.0
f: <sip:[email protected]>;tag=41
P-Access-Network-Info: IEEE-802.11; i-wlan-node-id=000102030405 <= PANI
header from PCAP
20:03:07.855 qimfsiplib.cpp 04727 EVENT_SIP_MESSAGE_RECV:SIP/2.0 200
OK
Call-ID: 4150057853_1511000824@fc01:bbbb:cdcd:efe0:d867:adb

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 121

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

6.1.2 Handover between LTE and IWLAN while UE is in connected state

The call flow and log messages for the handover between LTE and IWLAN while UE is in connected
state are as follows:

Figure 6-2 Call flow for handover during active call

1. IMS registers with CNE for measurement reports.
20:01:21.603 qpDplHandOver.c 04695 qpDplWiFiMeasurementsSetParamEx:
Received START Command
20:01:21.603 qpDplHandOver.c 04628 DplHandOverSetCNEProfileForMetrics
- Profile Mask set by IMS --> 0x000000000000000f | DS mask -->
0x4f646e61486c704

2. CNE provides measurements when thresholds are reached that are cached in IMS.
The CNE event comes via DS Sys events.
20:01:31.604 qpDcm.c 11242 qpDplProcessCommonDSSysEvents:
CNE_PROFILE_MET Mask --> 0x0

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 122

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

HOAlgoFlavor represents the algorithm type that is in use.

1 – VzW
0 – Other
20:01:31.605 qpDplHandOver.c 04928 DplHandOverProcessCNEReport -
HOAlgoFlavor -->1
The UE checks whether a handover is possible. In the example below,
handover is not possible, as indicated by HO possible = 0.
srat = source rat trat = target rat
LTE – 10
iWLAN – 6
20:01:31.605 qpDplHandOver.c 03641 IsHandOverPossible: current srat =
10 trat= 6 prefrat = 10
20:01:31.605 qipcalliface_ho_mgr.c 03417
qipcalliface_process_handover_measurement_cb: SRAT = 10, TRAT = 6,
pHOStatus->bIsHOPossible 0 ===>
20:01:31.607 qipcalliface_ho_mgr.c 02271
qipcalliface_is_wwan_iwlan_handover_required: current system = 1, HO
possible = 0, pref system 0

3. MO/MT VT call is established.

4. IMS determines whether to do a handover after the call is connected.
□ InCall = 1 → Call is ongoing
□ CallType 2 → VT call
20:00:51.712 qipcalliface_ho_mgr.c 03171
qipcalliface_is_wwan_iwlan_measurement_params_changed: HO params changed
SRAT 10, TRAT 6, PrefRAT = 10
20:00:51.713 qpDplHandOver.c 04406 qpDplHandOverParamsSet: Old Pref
RAT = 10 New Pref RAT = 10
20:00:51.713 qpDplHandOver.c 04407 qpDplHandOverParamsSet: Old
InCall = 0 New Incall = 1
20:00:51.714 qpDplHandOver.c 04430 qpDplHandOverParamsSet: InCall -->
1
20:00:51.714 qpDplHandOver.c 04431 qpDplHandOverParamsSet: CallType --
> 2
20:00:51.715 qipcalliface_ho_mgr.c 03416
qipcalliface_process_handover_measurement_cb: SRAT = 10,
TRAT = 6, pHOStatus->bIsHOPossible 1
IMS determines handover is possible and the preferred system to handover
to based on measurements.
HO possible = 1 and pref system 2 = iWLAN
20:00:52.012 qipcalliface_ho_mgr.c 02270
qipcalliface_is_wwan_iwlan_handover_required: current system = 1, HO
possible = 1, pref system 2
20:00:52.012 qipcalliface_ho_mgr.c 00373 qipcalliface_set_APN_pref_sys:
Handover requested to preferred sys 2
20:00:52.012 qipcalliface_ho_mgr.c 00919

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 123

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

qipcalliface_perform_handover_management :
HO conditions changed. Initiate HO to sys 2

5. IMS requests the APN to be moved to ePDG.

Preferred system:
□ 0 – WWAN
□ 2 – IWLAN
20:03:04.465 qipcalliface_ho_mgr.c 00374 qipcalliface_set_APN_pref_sys:
Handover requested to preffered sys 2
20:03:04.465 qipcalliface_ho_mgr.c 00920
qipcalliface_perform_handover_management :
HO conditions changed. Initiate HO to sys 2
HO conditions changed. Initiate HO to sys 2

6. IPSec Tunnel moves IMS PDN to Wi-Fi

7. DS indicates to IMS that the handover is complete and successful.

20:03:07.697 PDPRATHandlerVoLTE.cpp 01981 EventHOSuccess HORat:6
currRAT:10 RegType[0]
20:03:07.697 PDPRATHandlerVoLTE.cpp 01988 EventHOSuccess raise event
RegType[0]
□ RTP handover is initiated to sys 2, which is iWLAN
20:00:52.014 qipcalliface_ho_mgr.c 00373
qipcalliface_set_APN_pref_sys: Handover requested to
preffered sys 2
20:00:52.014 qipcalliface_ho_mgr.c 00919
qipcalliface_perform_handover_management : HO conditions
changed. Initiate HO to sys 2
20:00:34.375 [IMS_AP] qpDplVideo.c 03940 | 1408 |DPL
qpRTPVideoHandoverStatusInfo : 1
20:00:34.375 [IMS_AP] qpDplVideo.c 03964 | 1408 |DPL
qpRTPVideoHandoverStatusInfo sent to qvpRTPIPCMessageToApp- SUCCESS
RTP handover is successful
20:00:38.685 [IMS_AP] qpDplVideo.c 03940 | 1408 |DPL
qpRTPVideoHandoverStatusInfo : 2
20:00:38.685 [IMS_AP] qpDplVideo.c 03964 | 1408 |DPL
qpRTPVideoHandoverStatusInfo sent to qvpRTPIPCMessageToApp- SUCCESS

8. Handover to LTE takes place upon loss of Wi-Fi or poor Wi-Fi conditions.
□ Handover determination in this case is triggered by a RAT change.
□ SRAT 0 => source RAT indicates no RAT, which means Wi-Fi is lost
20:02:42.485 qipcalliface_ho_mgr.c 03171
qipcalliface_is_wwan_iwlan_measurement_params_changed: HO params
changed SRAT 0, TRAT 10, PrefRAT = 10
20:02:42.485 qipcalliface_ho_mgr.c 03416
qipcalliface_process_handover_measurement_cb: SRAT = 0, TRAT = 10,

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 124

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

pHOStatus->bIsHOPossible 1 ===>
20:02:42.486 qipcalliface_ho_mgr.c 02270
qipcalliface_is_wwan_iwlan_handover_required: current system = 3, HO
possible = 1, pref system 0
20:02:42.486 qipcalliface_ho_mgr.c 00373
qipcalliface_set_APN_pref_sys:
Handover requested to preffered sys 0
20:02:42.486 qipcalliface_ho_mgr.c 00919
qipcalliface_perform_handover_management : HO conditions
changed. Initiate HO to sys 0
□ RTP handover is initiated to RAT 10, which is LTE.
20:02:24.981 [IMS_AP] qvp_rtp_app_cmd.c 12363 | 1408 |
qvp_rtp_set_handoff_status_cmd rat_type = 10 HO_status: 1
20:02:24.981 [IMS_AP] qvp_rtp_app_cmd.c 12368 | 1408 |QVP_RTP_HO_INIT
in app cmd sending 1
20:02:24.981 [IMS_AP] qpDplVideo.c 03940 | 1408 |DPL
qpRTPVideoHandoverStatusInfo : 1
20:02:24.981 [IMS_AP] qpDplVideo.c 03945 | 1408 |DPL QVP_RTP_HO_INIT
□ RTP handover is successful
20:02:26.726 [IMS_AP] qpDplVideo.c 03940 | 1408 |DPL
qpRTPVideoHandoverStatusInfo : 2
20:02:26.727 [IMS_AP] qpDplVideo.c 03964 | 1408 |DPL
qpRTPVideoHandoverStatusInfo sent to qvpRTPIPCMessageToApp- SUCCESS

9. DS indicates that handover is successful.

20:02:44.393 PDPRATHandlerVoLTE.cpp 01971 EventHOSuccess HORat:10
currRAT:6 RegType[0]
20:02:44.393 PDPRATHandlerVoLTE.cpp 01978 EventHOSuccess raise event
RegType[0]
□ RTP handover is successful
20:02:26.726 [IMS_AP] qpDplVideo.c 03940 | 1408 |DPL
qpRTPVideoHandoverStatusInfo : 2
20:02:26.727 [IMS_AP] qpDplVideo.c 03964 | 1408 |DPL
qpRTPVideoHandoverStatusInfo sent to qvpRTPIPCMessageToApp- SUCCESS

10. IMS initiates REGISTRATION with the PANI header set to LTE access.
20:02:44.432 sipConnection.cpp 03063 EVENT_SIP_REG_REQ_SENT: 43 Code =
0 RAT = 10
20:02:44.433 sipConnection.cpp 03823 EVENT_SIP_REQUEST_SEND: REGISTER
sip:test.3gpp.com SIP/2.0
f: <sip:[email protected]>;tag=16
P-Access-Network-Info: 3GPP-E-UTRAN-FDD; utran-cell-
id-3gpp=311480000B0038000 <= PANI from PCAP
20:02:44.541 qimfsiplib.cpp 04736 EVENT_SIP_MESSAGE_RECV:SIP/2.0 200
OK
Call-ID: 1644419514_2865829720@fc01:bbbb:cdcd:efe0:7ce8:750

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 125

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

6.2 Decode ESP packets on the ePDG tunnel

Use the following ADB commands to capture ePDG tunnel keys:
adb shell date >> ip_xfrm_state_dump
adb shell ip xfrm state >> ip_xfrm_state_dump
adb shell ip xfrm policy >> ip_xfrm_state_dump

Sample ip_xfrm_state_dump file:

Wed Jul 15 15:07:49 PDT 2015
src 208.54.77.252 dst 192.168.0.194
proto esp spi 0x71a0c012 reqid 0 mode tunnel
replay-window 0 flag af-unspec
auth-trunc xcbc(aes) 0x5a4525ec7ddd5b8c29fc568652086dee 96
enc cbc(aes)
0x465ba88c7fe8deb6c50451f0a9d8a6a4e34f43f6245f8cf7db3845cae4fd8a94
encap type espinudp sport 4500 dport 32012 addr 0.0.0.0
src 192.168.0.194 dst 208.54.77.252
proto esp spi 0x07326552 reqid 0 mode tunnel
replay-window 0 flag af-unspec
auth-trunc xcbc(aes) 0x91a8cb7800a8bdd713b0c011ad98d14d 96
enc cbc(aes)
0x797cd41d396d94e73020ecba278aea515065807c01807c7c8915053c4e23928a
encap type espinudp sport 32012 dport 4500 addr 0.0.0.0

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 126

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

TCP dump before decoding ESP packets

Figure 6-3 Filter ESP packet in WireShark

Figure 6-4 Decoding of ESP packet

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 127

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

Wed Jul 15 15:07:49 PDT 2015

src 208.54.77.252 dst 192.168.0.194
proto esp spi 0x71a0c012 reqid 0 mode tunnel
replay-window 0 flag af-unspec
auth-trunc xcbc(aes) 0x5a4525ec7ddd5b8c29fc568652086dee 96
enc cbc(aes)
0x465ba88c7fe8deb6c50451f0a9d8a6a4e34f43f6245f8cf7db3845cae4fd8a94
encap type espinudp sport 4500 dport 32012 addr 0.0.0.0
src 192.168.0.194 dst 208.54.77.252
proto esp spi 0x07326552 reqid 0 mode tunnel
replay-window 0 flag af-unspec
auth-trunc xcbc(aes) 0x91a8cb7800a8bdd713b0c011ad98d14d 96
enc cbc(aes)
0x797cd41d396d94e73020ecba278aea515065807c01807c7c8915053c4e23928a
encap type espinudp sport 32012 dport 4500 addr 0.0.0.0

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 128

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual IMS Wi-Fi handover

TCP dump after decoding ESP packets

Figure 6-5 Wireshark packet content after decoding of ESP packet

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 129

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
7 E911 call scenarios

E911 calls are emergency calls which override all other call scenarios. The following call flows and log
analysis can be used to debug various E911 call scenarios.

7.1 E911 call establishment in CS and IMS domains

E911 calls are emergency calls which override all other call scenarios. At power-on, IMS registers
internally with the CM for E911 calls over LTE. The CM controls E911 call routing to CS domain or IMS
domain.

■ Exception: If an emergency call is configured to CS domain only

□ NV 67348 = 1
■ The QXDM Professional™ tool (QXDM Pro) F3 message is as follows
IMS/High 02:02:51.676 qipcalliface.c 05684
qipcalliface_update_run_status_to_cm() :: eRUN_STATUS_INACTIVE:
emerg_call_cs_only is 1

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 130

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

NOTE NV 67348 is stored in EFS file /nv/item_files/ims/qipcall_config_items. The default value

is 0.

After IMS registration on Wi-Fi, IMS registers internally with CM for E911 calls over Wi-Fi
■ Exception:
□ If NV 73717 = 1, then E911 over Wi-Fi is disabled
■ The QXDM Pro F3 message:
IMS/High 02:46:54.653 qipcalliface.c 05426
qipcalliface_update_run_status_to_cm() :: eRUN_STATUS_ACTIVE:
emerg_wifi_call_disable is 1

NOTE NV 73717 is stored in EFS file /nv/item_files/ims/qp_ims_emerg_wifi_disable. The default

value is 1.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 131

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

CM routing decision to CS domain or IMS domain is outside the scope of this document. Henceforth,
this document assumes that all E911 calls are routed over IMS.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 132

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

7.2 E911 call flows

Following is the end-to-end call flow for E911 calls:

Figure 7-1 E911 basic call flow

The end-to-end call flow for E911 calls is described as follows:
1. Dial E911 call.
2. Call is initiated and RRC connection is established with cause set to Emergency.
3. NAS sends Attach Request message with EPS type set to Initial or Emergency.
4. NAS sends PDN connectivity message.
5. NAS sends Attach Accept message and IMS default bearer is established between the network
and the UE.
6. UE sends Attach Complete message.
7. NAS attach procedure is completed.

8. UE performs Emergency Registration with emergency PDN.

□ Verify that UE sends SIP Register with reg-type:sos

9. Network sends 401 challenge to the UE.

10. UE sends Register Response message to the P-CSCF.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 133

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

11. P-CSCF sends 200 OK message to the UE.

12. IMS registered successfully with IMS CN.
13. Verify that the UE sends a SIP INVITE urn:service:sos (SDP offer) message to the P-CSCF.
14. P-CSCF sends 180 Ringing message to the UE.
□ If received 180 Ringing message has the require header set as 100 rel, then UE responds
with PRACK.
15. UE responds with PRACK message to the P-CSCF.
16. P-CSCF sends 200 OK (PRACK) message to the UE.
17. P-CSCF responds with 200 OK (SDP answer) message to the UE for the INVITE.
18. E911 call is now connected.

7.3 E911 log analysis

The following log analysis shows the call flow from call origin till the packet is sent out from the device:
1. Dial an E911 call using the QMI VOICE API

2. CM call control returns the call type as emergency

MSG cmcall.c 20884 =CM= CC ret call type EMERG emerg srv categ
0 Call Manager/High
EVENT call_type: CM_CALL_TYPE_E911, srv_type: CM_SRV_TYPE_AUTOMATIC,
srv_opt: 0, drs_bit: 1, last_act_net: CM_SYS_MODE_NO_SRV
EVENT_CM_CALL_ORIG_START_P1

3. E911 over IMS possible

cmipapp.c 00792 =CM= Found active app 1 for call type 9, sys mode 9 Call
Manager/High
cmsds.c 01677 =CM= LTE_911 over IMS possible Call Manager/High

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 134

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

4. Emergency registration and PDN bringup

MSG IMS/Low qimfif.cpp 06010 Qimfif_RegisterServiceMonitor \\Emergency
registration
MSG IMS/High qipcallh.c 09988 Call id 1 moving to WAIT FOR EMERGENCY
REGISTRATION
MSG IMS/Low PDPRATHandler.cpp 01363 CPDPRATHandlerVoLTE::PdpActivate
enter, pdp state:0 RegType[1]
2000 Jan 8 21:33:35.864 [00] 0xB0E3 LTE NAS ESM Plain OTA Outgoing
Message -- PDN connectivity request Msg

pdn_connectivity_req
pdn_type = 3 (0x3) (Ipv4v6)
req_type = 4 (0x4) (emergency)
2000 Jan 8 21:33:37.092 [00] 0xB0E2 LTE NAS ESM Plain OTA Incoming
Message -- Activate default EPS bearer context request Msg
2000 Jan 8 21:33:37.095 [00] 0xB0E3 LTE NAS ESM Plain OTA Outgoing
Message -- Activate default EPS bearer context accept Msg

5. SIP registration over the emergency PDN

sipConnection.cpp 03611 3611|EVENT_SIP_REQUEST_SEND: REGISTER
sip:ims.vz.net SIP/2.0f: <sip:[email protected]>;tag=422
qimfsiplib.cpp 04584 4584|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OKi:
42225237_2367914208@2002:c023:9c17:75b:a41b:d7dc:6a

6. Originate call on the emergency PDN

2002:c023:9c17:75b:a41b:d7dc:6ae:b9f7
2002:c023:9c17:c003:7426:e097:66fe:8ad8 SIP/SDP 619 Request:
INVITE urn:service:sos
2002:c023:9c17:c003:7426:e097:66fe:8ad8
2002:c023:9c17:75b:a41b:d7dc:6ae:b9f7 SIP 504 Status: 100 Trying
2002:c023:9c17:c003:7426:e097:66fe:8ad8
2002:c023:9c17:75b:a41b:d7dc:6ae:b9f7 SIP/SDP 1017 Status: 180
Ringing |
2002:c023:9c17:75b:a41b:d7dc:6ae:b9f7
2002:c023:9c17:c003:7426:e097:66fe:8ad8 SIP 636 Request: PRACK
sip:11111@[2002:c023:9c17:c003:7426:e097:66fe:8ad8]:5060 |
2002:c023:9c17:c003:7426:e097:66fe:8ad8
2002:c023:9c17:75b:a41b:d7dc:6ae:b9f7 SIP 403 Status: 200 OK |
2002:c023:9c17:c003:7426:e097:66fe:8ad8
2002:c023:9c17:75b:a41b:d7dc:6ae:b9f7 SIP/SDP 1043 Status: 200 OK

7.3.1 Log messages during an E911 call originated with initial attach
The log messages during an E911 call originated with initial attach are as follows:
0x1391 QMI Link 2 TX PDU
MsgType = QMI_VOICE_ALL_CALL_STATUS_IND
MsgLength = 27
Service_Voc_V2 {

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 135

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

…
CallId = 1
CallState = ORIGINATION
CallType = EMERGENCY //E911 Call
Direction = MO: Mobile Originated Call
Mode = LTE
//Attach Request with Initial Attach
2013 Nov 19 19:43:32.911 [00] 0xB0ED LTE NAS EMM Plain OTA Outgoing
Message -- Attach request Msg
lte_emm_msg
emm_attach_request
att_type = 2 (0x2) (combined EPS/IMSI attach) //Initial Attach
id_type = 6 (0x6) (GUTI)
//RRC Connection
0xB0C0 LTE RRC OTA Packet -- UL_CCCH
value UL-CCCH-Message ::=
{
message c1 : rrcConnectionRequest :
{
establishmentCause emergency,
}
}

7.3.2 Log messages during an E911 call originated with emergency attach
The log messages during an E911 call originated with emergency attach are as follows:
//PDN Connectivity Request with Request Type = Emergency
0xB0E3 LTE NAS ESM Plain OTA Outgoing Message -- PDN connectivity request
Msg
msg_type = 208 (0xd0) (PDN connectivity request)
lte_esm_msg
pdn_type = 3 (0x3) (Ipv4v6)
req_type = 4 (0x4) (emergency)
access_pt_name_incl = 0 (0x0)
….
sm_container[0]
container_id = 13 (0xd) (DNS Server IPv4 Address Request)
sm_container[1]
container_id = 3 (0x3) (DNS Server IPv6 Address Request)
sm_container[2]
container_id = 1 (0x1) (P-CSCF IPv6 Address Request)
sm_container[3]
container_id = 12 (0xc) (P-CSCF IPv4 Address Request)
//E911 Call Origin, SIP Message flow – Emergency Call Origin procedure
sipConnection.cpp 03510 3510|EVENT_SIP_REQUEST_SEND: INVITE urn:service:sos
SIP/2.0f: "10138" <sip:[email protected]
qpSipSessionServic 01174 1174|EVENT_SIP_SESSION_START: INVITE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 136

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

urn:service:sos SIP/2.0f: "10138" <sip:[email protected]

qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 100 TryingVia:
SIP/2.0/UDP [fd00:0:0:2::1]:5060;branch=z9hG4
sipConnection.cpp 03510 3510|EVENT_SIP_REQUEST_SEND: PRACK
sip:service:sos@[fd00:0:20:1::1:5]:5060 SIP/2.0To: <urn:service:s
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK Record-
Route: <sip:[fd00:0:20:1::1:5]:5060;lr>Via: S
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OKRecord-
Route: <sip:[fd00:0:20:1::1:5]:5060;lr>Via: S
qpSipSessionServic 03439 3439|EVENT_SIP_SESSION_ESTABLISHED:CallId:
3773525069_1162039504@fd00:0:0:2::1

7.4 E911 call establishment/termination flows on UE with UICC

The various call scenarios when UE is with universal integrated circuit card (UICC), that is, the SIM
card are as follows:
■ Emergency call over IMS
■ E911 IMS registration rejected
■ Emergency call without a SIM card
■ Expiry of the ECBM timer from the CM module

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 137

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

7.4.1 Scenario 1: Emergency call over IMS

The following call flow and log analysis describe a scenario when an Emergency call is attempted over
IMS and SOS IMS registration is performed successfully:
1. UE has a UICC.
2. PS 911 with successful initial attach occurs when the UE is in LTE.
3. Secure user plane location (SUPL) determines the location of the UE.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 138

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 139

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

1. IMS registered on LTE, VoLTE call is in progress, and moves to eHRPD coverage
a. Power up the UE and activate Airplane mode.
b. Dial E911 call.
c. Call is initiated and RRC Connection is established with cause set to Emergency .
d. NAS sends Attach Request message with EPS type set to Initial.
e. NAS sends PDN Connectivity message with PDN Type set to IPv4v6, PCO for DNS and P-
CSCF, APN name not present, and ESM Information Transfer Flag set to 1.
f. UE sends the ESM Information Response with APN Name as IMS APN.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 140

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

g. NAS sends Attach Accept message and IMS default bearer is established between the
network and the UE.
h. UE sends Attach Complete message.
i. NAS Attach procedure is completed.
j. UE sends PDN Connectivity message with PDN type set to IPv4v6, request type as
Emergency, PCO for DNS and P-CSCF, APN name not present.
k. Network establishes default and dedicated EPS bearers with RRC Reconfiguration Request
message.
l. UE responds with RRC Reconfiguration Complete message.
m. UE performs Emergency Registration with Emergency PDN.
n. Verify that UE sends SIP register with reg-type:sos
o. Network sends 401 challenge to the UE.
p. UE sends Register Response message to the P-CSCF.
q. P-CSCF sends 200 OK message to the UE.
r. IMS registered successfully with IMS CN.

2. IMS registered on LTE, E911 call is in progress, and moves to eHRPD coverage.
a. Verify that the UE sends an SIP INVITE urn:service:sos (SDP offer) message to the P-CSCF.
b. Verify SIP header contents.
c. P-CSCF sends180 Ringing message to the UE.
d. UE responds with PRACK (180) message to the P-CSCF.
e. P-CSCF sends 200 OK (PRACK) message to the UE.
f. P-CSCF responds with 200 OK (SDP Answer) message to the UE for the Invite.
g. E911 call is now connected.
h. User terminates the E911 call.
i. UE sends BYE message to the P-CSCF.
j. P-CSCF responds with a 200 OK message to the UE.
k. Emergency PDN is disconnected after the emergency registration timer expires.

The log analysis for the E911 call scenarios is as follows:

■ E911 Call Origin, RRC connection establishment, NAT attach procedure
//E911 Call Origin
0x1391 QMI Link 2 TX PDU
MsgType = QMI_VOICE_ALL_CALL_STATUS_IND
MsgLength = 27
Service_Voc_V2 {
…
CallId = 1
CallState = ORIGINATION
CallType = EMERGENCY //E911 Call
Direction = MO: Mobile Originated Call
Mode = LTE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 141

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

//Attach Request with Initial Attach

2013 Nov 19 19:43:32.911 [00] 0xB0ED LTE NAS EMM Plain OTA Outgoing
Message -- Attach request Msg
lte_emm_msg
emm_attach_request
att_type = 2 (0x2) (combined EPS/IMSI attach) //Initial Attach
id_type = 6 (0x6) (GUTI)
//RRC Connection
0xB0C0 LTE RRC OTA Packet -- UL_CCCH
value UL-CCCH-Message ::=
{
message c1 : rrcConnectionRequest :
{
establishmentCause emergency,
}
}
//RRC Connection Complete
0xB0C0 LTE RRC OTA Packet -- UL_DCCH
value UL-DCCH-Message ::=
{
message c1 : rrcConnectionSetupComplete :
}
//Attach Accept
0xB0EC LTE NAS EMM Plain OTA Incoming Message -- Attach accept Msg
msg_type = 66 (0x42) (Attach accept)
lte_emm_msg
emm_attach_accept
attach_result = 2 (0x2) (comb EPS/IMSI attach)
//Activate Default EPS bearer request message
0xB0E2 LTE NAS ESM Plain OTA Incoming Message -- Activate default EPS
bearer context request Msg
eps_bearer_id_or_skip_id = 6 (0x6)
trans_id = 4 (0x4)
msg_type = 193 (0xc1) (Activate default EPS bearer context request)
lte_esm_msg
act_def_eps_bearer_context_req
//Attach Complete
0xB0ED LTE NAS EMM Plain OTA Outgoing Message -- Attach complete Msg
msg_type = 67 (0x43) (Attach complete)
emm_attach_complete
eps_bearer_id_or_skip_id = 6 (0x6)
msg_type = 194 (0xc2) (Activate default EPS bearer context accept)
■ Emergency PDN connectivity
//PDN Connectivity Request with Request Type = Emergency
0xB0E3 LTE NAS ESM Plain OTA Outgoing Message -- PDN connectivity
request Msg
msg_type = 208 (0xd0) (PDN connectivity request)

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 142

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

lte_esm_msg
pdn_type = 3 (0x3) (Ipv4v6)
req_type = 4 (0x4) (emergency)
access_pt_name_incl = 0 (0x0)
….
sm_container[0]
container_id = 13 (0xd) (DNS Server IPv4 Address Requestt)
sm_container[1]
container_id = 3 (0x3) (DNS Server IPv6 Address Request)
sm_container[2]
container_id = 1 (0x1) (P-CSCF IPv6 Address Request)
sm_container[3]
container_id = 12 (0xc) (P-CSCF IPv4 Address Request)
//RRC Re-Configuration Request and Complete
0xB0C0 LTE RRC OTA Packet -- DL_DCCH
value DL-DCCH-Message ::=
{
message c1 : rrcConnectionReconfiguration :
0xB0C0 LTE RRC OTA Packet -- UL_DCCH
value UL-DCCH-Message ::=
{
message c1 : rrcConnectionReconfigurationComplete :
…
}
//Activate Default
0xB0E2 LTE NAS ESM Plain OTA Incoming Message -- Activate default EPS
bearer context request Msg
eps_bearer_id_or_skip_id = 7 (0x7)
msg_type = 193 (0xc1) (Activate default EPS bearer context request)
access_point
num_acc_pt_val = 28 (0x1c)
acc_pt_name_val[0] = 9 (0x9) (length)
acc_pt_name_val[1] = 101 (0x65) (e)
acc_pt_name_val[2] = 109 (0x6d) (m)
acc_pt_name_val[3] = 101 (0x65) (e)
acc_pt_name_val[4] = 114 (0x72) (r)
acc_pt_name_val[5] = 103 (0x67) (g)
acc_pt_name_val[6] = 101 (0x65) (e)
acc_pt_name_val[7] = 110 (0x6e) (n)
acc_pt_name_val[8] = 99 (0x63) (c)
acc_pt_name_val[9] = 121 (0x79) (y)
//Activate Dedicated bearer
0xB0E2 LTE NAS ESM Plain OTA Incoming Message -- Activate dedicated EPS
bearer context request Msg
eps_bearer_id_or_skip_id = 11 (0xb)
msg_type = 197 (0xc5) (Activate dedicated EPS bearer context request)
lte_esm_msg

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 143

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

act_dedicated_eps_bearer_context_req
eps_bearer_id = 7 (0x7) (EPS bearer identity value 7)
■ E911 call up
//Emergency Call Origin
0x1391 QMI Link 2 TX PDU
…
QmiType = VOICE
ClientId = 1
SduCtlFlags = IND
TxId = 0
MsgType = QMI_VOICE_ALL_CALL_STATUS_IND
….
CallId = 1
CallState = ORIGINATION
CallType = EMERGENCY
Direction = MO: Mobile Originated Call
…
}
//SIP Message flow – Emergency Call Origin
sipConnection.cpp 03510 3510|EVENT_SIP_REQUEST_SEND: INVITE
urn:service:sos SIP/2.0f: "10138" <sip:[email protected]
qpSipSessionServic 01174 1174|EVENT_SIP_SESSION_START: INVITE
urn:service:sos SIP/2.0f: "10138" <sip:[email protected]
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 100 TryingVia:
SIP/2.0/UDP [fd00:0:0:2::1]:5060;branch=z9hG4
sipConnection.cpp 03510 3510|EVENT_SIP_REQUEST_SEND: PRACK
sip:service:sos@[fd00:0:20:1::1:5]:5060 SIP/2.0To: <urn:service:s
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK Record-
Route: <sip:[fd00:0:20:1::1:5]:5060;lr>Via: S
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OKRecord-
Route: <sip:[fd00:0:20:1::1:5]:5060;lr>Via: S
qpSipSessionServic 03439 3439|EVENT_SIP_SESSION_ESTABLISHED:CallId:
3773525069_1162039504@fd00:0:0:2::1

7.4.2 Scenario 2: E911 IMS registration is rejected

The following call flow and log analysis describe a scenario when E911 IMS registration is rejected
with cause 403:
1. UE has the valid UICC.
2. Emergency PDN is established succesfully when the UE is in LTE.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 144

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

3. IMS emergency registration fails

4. SUPL determines the location of the UE.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 145

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

1. E911 Call Origin, IMS registration on LTE

a. Power up the UE and activate Airplane mode.
b. Dial E911 call.
c. NAS sends Attach Request with EPS Type set to Initial.
d. IMS Registration is successful on LTE.
e. NAS sends PDN Connectivity message with PDN type set to IPv4v6, PCO for DNS and P-
CSCF, APN name not present, and ESM Information Transfer Flag set to 1.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 146

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

f. UE reattempts the E911 call by sending an RRC Connection Request with establishment
cause set to Emergency.
g. NAS sends ATTACH REQUEST with EPS Type set to Emergency.

2. PDN Connectivity Request, Emergency Registration fails, E911 Call Origin

a. UE sends PDN Connectivity message with PDN type set to IPv4v6, Request Type as
Emergency, PCO for DNS and P-CSCF, APN name not present.
b. NAS sends Attach Accept.
c. Network establishes Default and Dedicated EPS bearers with RRC Reconfiguration Request
message
d. UE responds with RRC Reconfiguration Complete message
e. Emergency Registration fails with Cause Code 403 - Forbidden
f. UE originates E911 call
– IMS registered on LTE, E911 call up

g. Verify the UE sends a SIP INVITE urn:service:sos (SDP offer) message to the P-CSCF
– Verify SIP header contents
h. P-CSCF sends180 Ringing message to the UE.
i. UE responds with PRACK (180) message to the P-CSCF.
j. P-CSCF sends 200 OK (PRACK) message to the UE.
k. P-CSCF responds with 200 OK (SDP Answer) message to the UE for the INVITE.
l. E911 call is now connected.
m. User terminates the E911 call.
n. UE will send BYE message to the P-CSCF.
o. P-CSCF will respond with a 200 OK message to the UE.
p. Emergency PDN is disconnected after the Emergency Registration timer expires.

The log messages when E911 IMS registration is rejected are as follows:

1. E911 Call origin, IMS registration fails

//Initial attach procedure is same as Call Flow 2
//Attach Request with Initial Attach
2013 Nov 19 19:43:32.911 [00] 0xB0ED LTE NAS EMM Plain OTA Outgoing
Message -- Attach request Msg
lte_emm_msg
emm_attach_request
att_type = 2 (0x2) (combined EPS/IMSI attach) //Initial Attach
id_type = 6 (0x6) (GUTI)
//Network sends 403 Forbidden message – IMS Registration Fails
sipConnection.cpp 03611 3611|EVENT_SIP_REQUEST_SEND: REGISTER
sip:test.3gpp.com SIP/2.0f: <sip:[email protected]>;t
qimfsiplib.cpp 04584 4584|EVENT_SIP_MESSAGE_RECV:SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP [fd00:0:0:3::1]:5060;branch=z9
sipConnection.cpp 02642 2642|EVENT_SIP_REG_RESP_RCVD : 44 Code = 403

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 147

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

2. Emergency PDN connectivity

//PDN Connectivity Request with Request Type = Emergency
0xB0E3 LTE NAS ESM Plain OTA Outgoing Message -- PDN connectivity
request Msg
msg_type = 208 (0xd0) (PDN connectivity request)
lte_esm_msg
pdn_type = 3 (0x3) (Ipv4v6)
req_type = 4 (0x4) (emergency)
access_pt_name_incl = 0 (0x0)
….
sm_container[0]
container_id = 13 (0xd) (DNS Server IPv4 Address Request)
sm_container[1]
container_id = 3 (0x3) (DNS Server IPv6 Address Request)
sm_container[2]
container_id = 1 (0x1) (P-CSCF IPv6 Address Request)
sm_container[3]
container_id = 12 (0xc) (P-CSCF IPv4 Address Request)
//RRC Re-Configuration Procedure and bearer activation procedure is same
as Call Flow 2

3. Emergency PDN connectivity and E911 call

//SIP Message flow – Emergency Call Origin procedure same as Call Flow 2

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 148

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

7.4.3 Scenario 3: Emergency call without a SIM card

The following call flow and log analysis describe a scenario when emergency call is attempted without
a SIM card:
1. UE does not have the SIM card
2. Emergency attach is succesful when the UE is in LTE
3. SUPL determines the location of the UE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 149

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

1. E911 Call Origin, NAS attach procedure

a. Remove the UICCand power up the UE.
b. Dial E911 call.
c. NAS sends Attach request with EPS type set to Emergency.
d. NAS sends PDN connectivity message withPDN type set to IPv4v6, IMEI, PCO for DNS and
P-CSCF, APN name not present.
e. NAS sends Attach Accept message and IMS default bearer is established between the
network and the UE.
f. UE sends Attach Complete message.
g. NAS Attach procedure is completed .

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 150

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

2. No Emergency Registration, E911 Call Origin

a. Network establishes default and dedicated EPS bearers with RRC Reconfiguration Request
message.
b. UE responds with RRC Reconfiguration Complete message.
c. UE does not perform Emergency Registration.
d. UE originates E911 call.

3. E911 call up

a. Verify that the UE sends a SIP INVITE urn:service:sos (SDP Offer) message to the P-CSCF.
– Verify SIP header contents.
b. P-CSCF sends 180 ringing message to the UE.
c. UE responds with PRACK (180) message to the P-CSCF.
d. P-CSCF sends 200 OK (PRACK) message to the UE.
e. P-CSCF responds with 200 OK (SDP answer) message to the UE for the Invite.
f. E911 call is now connected.
g. User terminates the E911 call.
h. UE sends BYE message to the P-CSCF.
i. P-CSCF responds with a 200 OK message to the UE.
j. Emergency PDN is disconnected after the Emergency Registration timer expires.

The log messages when an emergency call is made without a SIM card is as follows:

1. E911 Call Origin, NAS Attach procedure

//NAS Attach Procedure is same as Call Flow 2
//PDN Connectivity Request with Request Type = Emergency

0xB0E3 LTE NAS ESM Plain OTA Outgoing Message -- PDN connectivity
request Msg
msg_type = 208 (0xd0) (PDN connectivity request)
lte_esm_msg
pdn_type = 3 (0x3) (Ipv4v6)
req_type = 4 (0x4) (emergency)
access_pt_name_incl = 0 (0x0)
….
sm_container[0]
container_id = 13 (0xd) (DNS Server IPv4 Address Request)
sm_container[1]
container_id = 3 (0x3) (DNS Server IPv6 Address Request)
sm_container[2]
container_id = 1 (0x1) (P-CSCF IPv6 Address Request)
sm_container[3]
container_id = 12 (0xc) (P-CSCF IPv4 Address Request)
//RRC Re-Configuration Procedure and bearer activation procedure is same
as Call Flow 2

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 151

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

2. IMS registration not performed; E911 Call Origin

//SIP Message flow – Emergency Call Origin procedure same as Call Flow 2

7.5 E911 call with IMS-enabled SIM card

The log messages during E911 call with IMS-enabled SIM card are as follows:
1. Emergency PDN establishment
2016 Mar 2 22:02:52.969 [08] 0xB0E3 LTE NAS ESM Plain OTA Outgoing Message
-- PDN connectivity request Msg
msg_type = 208 (0xd0) (PDN connectivity request)
req_type = 4 (0x4) (emergency)

2. Emergency IMS registration

2016 Mar 2 22:02:55.090 [0C] 0x1832 IMS Registration
Registration Type = Emergency-Registration
Result = OK

3. Emergency call setup

2016 Mar 2 22:03:12.530 [C5] 0x1830 IMS VoLTE Session Setup
Dialled String = urn:service:sos

4. Emergency call termination

2016 Mar 2 22:02:32.201 [8B] 0x1831 IMS VoLTE Session End
Dialled String = urn:service:sos

7.6 E911 call without a SIM card

The following sequence is performed when an E911 call is placed over IMS without a SIM card:

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 152

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

1. Emergency PDN establishment

2110 Apr 6 08:07:58.875 [7B] 0xB0E3 LTE NAS ESM Plain OTA Outgoing
Message -- PDN connectivity request Msg
msg_type = 208 (0xd0) (PDN connectivity request)
req_type = 4 (0x4) (emergency)

2. Emergency call setup

IMS/High 08:08:00.273 qimfif.cpp 04035 qimfif_send_invite:
call_type = 512, Emerg_reg_status = 4
2154 Mar 23 03:29:24.203 [00] 0x1830 IMS VoLTE Session Setup
Dialled String = urn:service:[email protected]

3. Emergency call termination

2016 Mar 2 03:32:02.161 [8B] 0x1831 IMS VoLTE Session End
Dialled String = urn:service:[email protected]

7.7 E911 service category

The emergency service category is used by the PSAP to route the emergency call to the proper
authorities. The following are the supported emergency service categories:
Table 7-1 E911 service category

Service category Service bit position SOS URN

None (not specified) Not applicable urn:service:sos

Police 0 urn:service:sos.police
Ambulance 1 urn:service:sos.ambulance
Fire Brigade 2 urn:service:sos.fire
Marine Guard 3 urn:service:sos.marine
Mountain rescue 4 urn:service:sos.mountain

■ The emergency service category is specified through QMI VOICE through TLV “emer_cat”
■ If the emergency service category is not specified through QMI VOICE, then the CM looks up the
emergency service category from the phone book manager (PBM)
■ Sample Log analysis: The emergency service category is specified in QMI VOICE as
“ambulance”.
1980 Jan 17 19:34:11.677 [06] 0x138E QMI Link 1 RX PDU
MsgType = QMI_VOICE_DIAL_CALL_MSG
call_type = EMERGENCY
emer_cat = AMBULANCE_BIT
service_type = VOICE_DIAL_CALL_SRV_TYPE_AUTOMATIC
19:34:11.687 cm.c 02964 =CM= Emerg serv categ given = 1

19:34:11.753 /local/mnt/workspa 23392 23392|Emergency sub category

urn:service:sos.ambulance

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 153

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

■ Sample log analysis: The emergency service category is not specified in QMI VOICE; CM queries
PBM for this information.
1980 Jan 17 13:24:45.177 [06] 0x138E QMI Link 1 RX PDU
MsgType = QMI_VOICE_DIAL_CALL_MSG
call_type = EMERGENCY
service_type = VOICE_DIAL_CALL_SRV_TYPE_AUTOMATIC
13:24:45.186 cm.c 02964 =CM= Emerg serv categ given = 0
03:56:35.348 pbmlib.c 04706 Emergency number status 1 gw cat 15 1X cat 0
15 decimal = 0x0F = 0000 1111  service category bits

13:24:45.233 /local/mnt/workspa 23392 23392|Emergency sub category

urn:service:sos.police

Multiple service category bits are set in this example in which “police” is selected.

7.8 Alternate service handling for E911 service

An emergency call may be undetectable from the UE. The network responds to the Invite message
with 380 alternative service. The 380 alternative service response has a P-Asserted-Identity (PAI)
header whose value should match Path header received in 200 OK register response. For more
information on UE behavior on receiving 380 response, see the following:
■ Section 5.1.6.8.1 of Technical Specification Group Core Network and Terminals; IP multimedia call
control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol
(SDP); Stage 3 (Release 13) (3GPP TS 24.229)
■ Section 19.3.3.1 of Technical Specification Group Radio Access Network; Internet Protocol (IP)
multimedia call control protocol based on Session Initiation Protocol (SIP) and Session
Description Protocol (SDP); User Equipment (UE) conformance specification; Part 1: Protocol
conformance specification (Release 10) (3GPP TS 34.229)
Some network operators are non-compliant with the requirements of the 3GPP specifications
mentioned above. Such operators can ignore validation of PAI and Path header using the following
workaround:
■ Set NV 67257 [VoIPConfigQoS] = 1 in the UE

7.8.1 Log messages during non-compliant network behavior

The log message that is generated while an emergency call fails to be established with the 380
alternative service owing to non-compliant network behavior is as follows:

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 154

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

Result: Call failure

2016 Jun 6 13:13:04.711 [8D] 0x156E IMS SIP Message --
IMS_SIP_REGISTER/OK
Message ID = IMS_SIP_REGISTER
Response Code = OK (200)
Path: <sip:[fd29:cc43:7fb9:0002:020c:29ff:fe66:b4c7];lr>
2016 Jun 6 13:13:30.089 [52] 0x156E IMS SIP Message -- IMS_SIP_INVITE/
ALTERNATIVE_SERVICE
Contact: <urn:service:sos.ambulance>
P-Asserted-Identity: <sip:[fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7];lr>
IMS/High 19:19:42.661 qimfif.cpp 12975 Alternate
Handling:validate_p_asserted_id failed
IMS/High 19:19:42.661 qipcallh.c 42518 alternate_service_event: Some thing
wrong with P-ASSERTED-ID, Sending PERMANENT failure to CM

7.8.2 Log messages during non-compliant network behavior with UE workaround

If PAI header of 380 response does not match the path header of emergency register 200 OK
response, OEMs must set NV 67257 [VoIPConfigQoS] as 1.
Result: Emergency call silent redial on IMS domain or CS domain
2016 Jun 6 19:33:07.891 [8D] 0x156E IMS SIP Message --
IMS_SIP_REGISTER/OK
Message ID = IMS_SIP_REGISTER
Response Code = OK (200)
Path: <sip:[fd29:cc43:7fb9:0002:020c:29ff:fe66:b4c7];lr>
2016 Jun 6 19:33:07.989 [52] 0x156E IMS SIP Message -- IMS_SIP_INVITE/
ALTERNATIVE_SERVICE
Contact: <urn:service:sos.ambulance>
P-Asserted-Identity: <sip:[fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7];lr>
IMS/High 19:33:08.061 qipcallh.c 39270 Alternate Handling:Emergency
Alternative call over CS

NOTE Silent redial for the emergency call is performed over the IMS domain if LTE emergency
support is available and there is no emergency access barring.

Non-compliant network behavior with UE work around NV 67257 [VoIPConfigQoS] = 1 and the contact
header in 380 does not match to one of the supported emergency service categories.
Result: Emergency call silent redial on IMS domain or CS domain
2016 Jun 6 19:33:07.891 [8D] 0x156E IMS SIP Message --
IMS_SIP_REGISTER/OK
Message ID = IMS_SIP_REGISTER
Response Code = OK (200)
Path: <sip:[fd29:cc43:7fb9:0002:020c:29ff:fe66:b4c7];lr>
2016 Jun 6 19:33:07.989 [52] 0x156E IMS SIP Message -- IMS_SIP_INVITE/
ALTERNATIVE_SERVICE
P-Asserted-Identity: <sip:[fd29:cc43:7fb9:2:20c:29ff:fe66:b4c7];lr>

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 155

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

IMS/High 19:33:08.061 qipcallh.c 39270 Alternate Handling: Normal Voice call

over CS

NOTE In this example, the contact header is not present in the 380 Alternative Service, this is
handled as a normal CS call.

7.8.3 Log messages during the switchover between IMS domain and CS domain
Whether emergency service is supported over IMS or CS is identified by the EMC_BS flag value
received in Attach Accept. The log is as follows:
2016 Jan 1 19:19:12.451 [4C] 0xB0EC LTE NAS EMM Plain OTA Incoming
Message -- Attach accept Msg
EMC_BS = 1 (0x1) (Emergency bearer services in S1 Mode supported)

7.8.4 Log messages during emergency access barring is found in SIB2

If the ac-BarringForEmergency IE of SIB2 message is set as true, then emergency call on LTE is not
allowed. The following log shows if the UE can perform emergency call over LTE.
BCCH_DL_SCH/SystemInformation 19:26:00.468 Radio Bearer ID: 0, Freq:
348, SFN: 512
value BCCH-DL-SCH-Message ::=
{
message c1 : systemInformation :
{
criticalExtensions systemInformation-r8 :
{
sib-TypeAndInfo
{
sib2 :
{
ac-BarringInfo
{
ac-BarringForEmergency TRUE
IMS/High 19:33:08.061 qipcallh.c 39270 Alternate Handling:Emergency
Alternative call over CS

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 156

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

7.9 E911 over Wi-Fi

Figure 7-2 E911 over Wi-Fi call flow

1. WFC and VoWi-Fi must be enabled for E911 calls to be routed over Wi-Fi.
qipcalliface_ho_mgr.c 02533 qipcalliface_update_E911_capability WFC
status 1 and Wifi srv status =17
ims_settings_common.c 04304 ims_settings_get_ims_config: Enable VoWifi =1
a. IMS informs CM that VOICE is available on iWLAN for both regular and emergency calls.
qipcalliface.c 05426 qipcalliface_update_run_status_to_cm() ::
eRUN_STATUS_ACTIVE:
emerg_wifi_call_disable is 0
qipcalliface.c 05432 qipcalliface_update_run_status_to_cm
QIPCALL_IFACE_EPC is up, indicating CM about Active status

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 157

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

b. Only Wi-Fi RAT is available for IMS.

PDPManager.cpp 00676 EventChangeRat - ServiceOnRatMask = 0x00000640,
new RAT mask = 0x00000040

2. E911 call is routed to IMS. Emergency registration is triggered.

qipcallh.c 14878 Handling emergency Call Origination
qipcallh.c 45174 qipcall_is_emerg_call_on_emerg_pdn: Mode = 0,
SysModeMask = 6, E911 over
Emerg PDN
qimfif.cpp 08507 Qimfif_RegisterServiceMonitor ===== Emergency
registration

3. Emergency registration and call are set up.

sipConnection.cpp 03830 EVENT_SIP_REQUEST_SEND: REGISTER
sip:vzimstest.com SIP/2.0 f: <sip:[email protected]>;tag=17
P-Access-Network-Info: IEEE-802.11; i-wlan-node-id=C0FFD491A587
sipConnection.cpp 03830 EVENT_SIP_REQUEST_SEND: INVITE urn:service:sos
SIP/2.0
f: "QC" <sip:[email protected]>;tag=1
qimfsiplib.cpp 04727 EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK
From: "QC" <sip:[email protected]>;tag=1752116887

7.10 P-Emergency call mode preference

This feature is specific to Verizon as of now. The following steps are performed by the modem after
receiving call-originate request from UI:
1. The E911 call placed is routed to CS or iWLAN based on the P-Emergency Call Mode Preference
header value received in 200 OK of the Register message.

2. The P-Emergency Call Mode Preference header has the emergency call mode preference
(ECMP) indication that takes the following values:
□ 3GPP-CS
□ 3GPP-IMS

3. When the ECMP header is missing in 200 OK (REGISTER), the UE places the E911 call over the
CS domain by default.
\\ since ECMP is "3GPP" by default when ECMP is missing from 200 OK
( REGISTER )
\\ CM places the E911 call on CS domain
\\ ECMP 0 → CMIAPP_ECMP_3GPP
\\ ECMP 1→ CMIAPP_ECMP_IMS

01:13:46.243 cmipapp.c 01233 =CM= App 1 registers for ECMP 0 //

CMIPAPP_ECMP_3GPP
01:14:17.072 cmcall.c 12097 =CM= ECMP is 3GPP, IMS registered over WLAN,
trying it as CS initially

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 158

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

7.10.1 Expiry of the ECBM timer from the CM module

The ECBM timer is run by the CM module. The following call flows show what happens upon expiry of
the timer.
1. UE has the valid SIM card.
2. #911 is dialed instead of 911
3. ECBM timer expires
4. SUPL determines the location of the UE

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 159

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

1. E911 call origin, IMS registered on LTE, NAS attach procedure

a. Power up the UE
b. IMS registration is successful on LTE
c. Dial #911 call
d. NAS sends Attach request with EPS type set to Emergency
e. NAS sends PDN Connectivity message with PDN type set to IPv4v6; IMEI number, PCO for
DNS and P-CSCF, and APN name are not present
f. NAS sends Attach Accept message and IMS default bearer is established between the
network and the UE
g. UE sends Attach Complete message
h. NAS Attach procedure is completed

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 160

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

2. No Emergency registration, #911 Call Origin

a. Network establishes default and dedicated EPS bearers with RRC Reconfiguration Request
message
b. UE responds with RRC Reconfiguration Complete message
c. UE performs Emergency registration
d. Emergency registration is successful
e. UE originates #911 call

3. E911 call up
a. Verify that the UE sends an SIP INVITE urn:service:sos (SDP Offer) message to the P-CSCF
b. Verify SIP header contents
c. P-CSCF sends180 ringing message to the UE
d. UE responds with PRACK (180) message to the P-CSCF
e. P-CSCF sends 200 OK (PRACK) message to the UE
f. P-CSCF responds with 200 OK (SDP answer) message to the UE for the Invite
g. E911 call is now connected
h. User terminates the E911 call
i. UE sends Bye message to the P-CSCF
j. P-CSCF responds with a 200 OK message to the UE
k. Emergency PDN is disconnected after the emergency registration timer expires

The log messages for an E911 call in ECBM Mode are as follows:

1. E911 Call Origin, NAS Attach procedure

//IMS Registered on LTE
sipConnection.cpp 03510 3510|EVENT_SIP_REQUEST_SEND: REGISTER
sip:test.3gpp.com SIP/2.0f: <sip:[email protected]>;t
qpSipRegisterServi 01290 1290|EVENT_SIP_REGISTRATION_START:REGISTER
sip:test.3gpp.com SIP/2.0f: <sip:[email protected]
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 401
UnauthorizedVia: SIP/2.0/UDP [fd00::1:529d:4620:10cb:5aa
sipConnection.cpp 02595 2595|EVENT_SIP_REG_RESP_RCVD : 44 Code = 401
qpSipRegisterServi 01290 1290|EVENT_SIP_REGISTRATION_START:REGISTER
sip:test.3gpp.com SIP/2.0f: <sip:[email protected]
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OKVia:
SIP/2.0/UDP [fd00::1:529d:4620:10cb:5aa3]:5060;br
sipConnection.cpp 02595 2595|EVENT_SIP_REG_RESP_RCVD : 44 Code = 200
//NAS Attach Procedure is same as Call Flow 2
//PDN Connectivity Request with Request Type = Emergency
0xB0E3 LTE NAS ESM Plain OTA Outgoing Message -- PDN connectivity
request Msg
msg_type = 208 (0xd0) (PDN connectivity request)
lte_esm_msg
pdn_type = 3 (0x3) (Ipv4v6)

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 161

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

req_type = 4 (0x4) (emergency)

access_pt_name_incl = 0 (0x0)
….
sm_container[0]
container_id = 13 (0xd) (DNS Server IPv4 Address Request)
sm_container[1]
container_id = 3 (0x3) (DNS Server IPv6 Address Request)
sm_container[2]
container_id = 1 (0x1) (P-CSCF IPv6 Address Request)
sm_container[3]
container_id = 12 (0xc) (P-CSCF IPv4 Address Request)

2. Emergency registration is successful; E911 Call Origin

//Emergency Registration successful
sipConnection.cpp 03510 3510|EVENT_SIP_REQUEST_SEND: REGISTER
sip:test.3gpp.com SIP/2.0f: <sip:[email protected]>;t
qpSipRegisterServi 01290 1290|EVENT_SIP_REGISTRATION_START:REGISTER
sip:test.3gpp.com SIP/2.0f: <sip:[email protected]
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OKVia:
SIP/2.0/UDP [fd00:0:0:3::1]:5060;branch=z9hG4bK18
sipConnection.cpp 02595 2595|EVENT_SIP_REG_RESP_RCVD : 44 Code = 200
sipConnection.cpp 02596 2596|EVENT_SIP_REG_RESP_RCVD : 44 RAT = 10

3. Call Origin, SIP message flow – Emergency Call origin procedure

sipConnection.cpp 03510 3510|EVENT_SIP_REQUEST_SEND: INVITE
urn:service:sos SIP/2.0f: "10138" <sip:[email protected]
qpSipSessionServic 01174 1174|EVENT_SIP_SESSION_START: INVITE
urn:service:sos SIP/2.0f: "10138" <sip:[email protected]
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 100 TryingVia:
SIP/2.0/UDP [fd00:0:0:2::1]:5060;branch=z9hG4
sipConnection.cpp 03510 3510|EVENT_SIP_REQUEST_SEND: PRACK
sip:service:sos@[fd00:0:20:1::1:5]:5060 SIP/2.0To: <urn:service:s
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OK Record-
Route: <sip:[fd00:0:20:1::1:5]:5060;lr>Via: S
qimfsiplib.cpp 04528 4528|EVENT_SIP_MESSAGE_RECV:SIP/2.0 200 OKRecord-
Route: <sip:[fd00:0:20:1::1:5]:5060;lr>Via: S
qpSipSessionServic 03439 3439|EVENT_SIP_SESSION_ESTABLISHED:CallId:
3773525069_1162039504@fd00:0:0:2::1

7.11 E911 call setup timer expiry

If an emergency call is not established within the configurable E911 call setup timer (NV 67348
[E911_Call_Timer]), then SIP: CANCEL is sent by the UE and silent redial is performed on the CS
domain.
1. E911 call is routed to IMS
IMS/High 22:02:52.829 qipcallh.c 14077 Handling emergency Call Origination

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 162

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

2. The E911 call timer expires 20 seconds after the E911 call is originated, and Cancel message is
sent
IMS/High 22:03:12.527 qipcallh.c 03612 emergency call timer expired
(St:11) release call id 3
IMS SIP/High 22:03:12.541 sipConnection.cpp 03792 EVENT_SIP_REQUEST_SEND:
CANCEL urn:service:sos SIP/2.0

3. Since the E911 call failed over IMS, the UE performs silent redial for E911 over CS domain
2016 Mar 2 22:03:13.376 [67] 0xB0ED LTE NAS EMM Plain OTA Outgoing Message
-- Extended service request Msg
service_type = 2 (0x2) (mobile originating CS fallback emergency call)

NOTE The unit for NV 67348 [E911_Call_Timer] is measured in milliseconds. In the above
example, NV 67348 [E911_Call_Timer] = 20000 ms.

7.12 Transition of UE states based on NAS timers

The nonaccess stratum (NAS) timers run for all scenarios on different UE states.
Table 7-2 Transition of states on timer expiry

Timer Cause of start of the On expiry of the

State Normal stop
number timer timer

T3402 EMM- At attach failure and the ATTACH REQUEST Initiation of the attach
DEREGISTERED attempt counter is equal to sent procedure or TAU
5 procedure
EMM- At tracking area updating TRACKING AREA
REGISTERED failure and the attempt UPDATE REQUEST
counter is equal to 5 sent
T3410 EMM- ATTACH REQUEST sent ATTACH ACCEPT Start T3411 or T3402
REGISTERED- received as described in
INITIATED subclause 5.5.1.2.6
ATTACH REJECT
received
T3411 EMM- At attach failure due to ATTACH REQUEST Retransmission of the
DEREGISTERED; lower layer failure, T3410 sent ATTACH REQUEST
ATTEMPTING-TO- timeout or attach rejected or TRACKING AREA
ATTACH with other EMM cause UPDATE REQUEST
values than those treated
in subclause 5.5.1.2.5
EMM- At tracking area updating TRACKING AREA
REGISTERED; failure due to lower layer UPDATE REQUEST
failure, T3430 timeout or sent
ATTEMPTING-TO-
TAU rejected with other
UPDATE
EMM cause values than
those treated in subclause
5.5.3.2.5
T3412 EMM- In EMM-REGISTERED, When entering state Initiation of the
REGISTERED when EMM-CONNECTED periodic TAU
EMM-
mode is left procedure if the UE is
DEREGISTERED or
not attached for
when entering
emergency bearer
EMM-CONNECTED services
mode

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 163

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

Table 7-2 Transition of states on timer expiry (cont.)

Timer Cause of start of the On expiry of the

State Normal stop
number timer timer

Implicit detach from

network if the UE is
attached for
emergency bearer
services
T3417 EMM-SERVICE- SERVICE REQUEST sent Bearers have been Abort the procedure
REQUEST- set up
INITIATED EXTENDED SERVICE SERVICE REJECT
REQUEST sent in case f received
and g in subclause 5.6.1.1
T3420 EMM- AUTHENTICATION AUTHENTICATION On first expiry, the UE
REGISTERED- FAILURE (cause = #21 REQUEST received should consider the
INITIATED "synch failure") sent network as false and
follow item f of
subclause 5.4.2.7, if
the UE is not
attached for
emergency bearer
services.
EMM- —
REGISTERED
EMM- On first expiry, the UE
DEREGISTERED- follows subclause
INITIATED 5.4.2.7 under “For
items c, d, and e:”, if
the UE is attached for
emergency bearer
services.
EMM-TRACKING- —
AREA-UPDATING-
INITIATED
EMM-SERVICE- —
REQUEST-
INITIATED
T3440 EMM- ATTACH REJECT, Signaling connection Release the signaling
REGISTERED- DETACH REQUEST, released connection and
INITIATED TRACKING AREA proceed as described
UPDATE REJECT with in subclause 5.3.1.2
any of the EMM cause
numbers 11, 12, 13, 14, or
15
EMM-TRACKING- SERVICE REJECT Bearers have been
AREA-UPDATING- received with any of the set up
INITIATED EMM cause numbers 11,
12, 13, or 15
EMM- TRACKING AREA —
DEREGISTERED- UPDATE ACCEPT
INITIATED received after the UE sent
TRACKING AREA
UPDATE REQUEST in
EMM-IDLE mode with no
"active" flag

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 164

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

Table 7-2 Transition of states on timer expiry (cont.)

Timer Cause of start of the On expiry of the

State Normal stop
number timer timer

EMM-SERVICE- — —
REQUEST-
INITIATED
EMM- — —
REGISTERED
T3442 EMM- SERVICE REJECT TRACKING AREA None
REGISTERED received with EMM cause UPDATE REQUEST
#39 "CS domain sent
temporarily not available"

7.13 E911 conformance testing

The OEM is responsible for:
■ Setting NV 71545 [E911TestmodeON] = 1
■ Configuring 922 as a test number
To configure 922 as a test number, do the following:
1. Open the Qualcomm Product Support Tool (QPST) tool
2. Navigate to QPST Service Programming
3. Set NV 855 to 1 using Qualcomm eXtensible Diagnostic Monitor (QXDM) NV browser.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 165

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual E911 call scenarios

4. Under 1x/HDR Security tab, click Add Entry under Special Numbers section.

5. On Add Entry dialogue box, add 922 against the Number field, select E911, and then click OK.
The Add Entry dialog box closes.

6. Write to phone and change NV 855 back to 0 using QXDM NV browser.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 166

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
A Keywords for log analysis

IMS registration
srv_stat|sys_mod|pdprat|pdp_|pcscf|establishpdp|releasepdp|dcmcreate|isconn|
nonet|regmanager|registermanager|registrationhandler|registerservice|
servicemonitor|event_sip|policy|serviceavailable|registerhandler|
registrationstatus|ds sys|new rat|IMS reg st|IMS_PREF|rxd\:|sipdispatcher|
cmipapp|RPT name
E911
event_sip|sipmess|processin|processout|emer|event_sip|checkreg|new rat|sos|
pdprat|Eventpdpfailure|ims_update|reg_status_update|new rat|update_ser|inter
RAT|pdprat|checkreg|DOM SEL|DOMSEL|call_type|srv_status|qipcall|srv_status|
Call_type|callcmd|handover_failed_event|rat_handover_status|srv_stat|sys_mod|
ds|=reg=|send mc orig|cm callcmd|srch state|qmi_voice|proc cdma|proc hdr|
irat_to_do|cmipapp|RPT name|acq_hdr|acq_cdma|acq_gw|iDelay|starttimer|
stoptimer|start timer|stop timer|rxd\:\|qipcalldan
OTA Messages
0xB0ED|0xB0EC|0xB0E2|0xB0E3|emm_attach_request|pdn_connectivity_req|pdn_type|
req_type|eps_bearer_id|t3412|acc_pt_name|apn|esm_cause|emm_cause|IMSVoPS|
eps_bearer_id|emm_attach|Voice centric|Data centric|cause_value|
emm_service_rej|att_type

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 167

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
B Carrier configuration

Table B-1 UE behavior for dual-SIM L+L mode

Sub combo Home Roaming

(DDS + non-DDS) DDS Non-DDS DDS Non-DDS

CMCC + CMCC L/T/G (IMS/CSFB/ L/G (IMS/CSFB/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi) VoWiFi)
CMCC + CU L/T/G (IMS/CSFB/ L/W/G (IMS/CSFB/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi) VoWiFi)
CMCC + CT (IMS off) L/T/G (IMS/CSFB/ 1X (CS voice) L/W/G (CSFB) L/W/G (CSFB)
VoWiFi)
CMCC + CT (IMS on) L/T/G (IMS/CSFB/ LTE (IMS/VoWiFi)/1x L/W/G (CSFB) L/W/G (CSFB)
VoWiFi) CS voice *
CT (IMS off) + CMCC SRLTE (CS voice) L/G (IMS/CSFB/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi)
CT (IMS on) + CMCC hVoLTE (IMS/ L/G (IMS/CSFB/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi/1X CS voice) VoWiFi)
CT (IMS off) + CU SRLTE (CS voice) L/W/G (IMS/CSFB/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi)
CT (IMS on) + CU hVoLTE (IMS/ L/W/G (IMS/CSFB/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi/1X CS voice) VoWiFi)
CT (IMS off) +CT(IMS off) SRLTE (CS voice) N/A (Power Save) L/W/G (CSFB) L/W/G (CSFB)
CT (IMS off) +CT(IMS on) SRLTE (CS voice) LTE only (IMS/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi)
CT (IMS on) +CT(IMS off) hVoLTE (IMS/ N/A (Power Save) L/W/G (CSFB) L/W/G (CSFB)
VoWiFi/1X CS voice)
CT (IMS on) +CT(IMS on) hVoLTE (IMS/ LTE only (IMS/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi/1X CS voice) VoWiFi)
CU + CMCC L/W/G (IMS/CSFB/ L/G (IMS/CSFB/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi) VoWiFi)
CU + CT (IMS off) L/W/G (IMS/CSFB/ 1X (CS voice) L/W/G (CSFB) L/W/G (CSFB)
VoWiFi)
CU + CT (IMS on) L/W/G (IMS/CSFB/ LTE (IMS/VoWiFi)/1X L/W/G (CSFB) L/W/G (CSFB)
VoWiFi) CS voice
CU + CU L/W/G (IMS/CSFB/ L/W/G (IMS/CSFB/ L/W/G (CSFB) L/W/G (CSFB)
VoWiFi) VoWiFi)

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 168

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
C Decode TLS packets in Wireshark

TLS packets are decoded using Wireshark to do the following:

■ Filter QXDM Pro and PCAP logs to find the master key
■ Perform multiple TLS sessions

C.1 Requirements to decode TLS packet

■ Download Wireshark
■ Download QXDM Pro
■ Text file editor (for example, Notepad)

C.2 Procedure to decode TLS packet

1. Filter QXDM Pro logs on security logs.
a. Open QXDM Pro window.
b. To open the ISF file, press CTRL+L and select the file.
c. Press ALT+R to refilter items.
d. The Select Refiltering Config window opens.

e. In the Select Refiltering Config window, select the following:

– Item types – Message Packets
– Filter/Register On Target For Items

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 169

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Decode TLS packets in Wireshark

– Security – Security/Secure Sockets Layer

– Accept Unknowns

f. Click OK. The following screen opens.

g. Enter SSL: Master Secret and the following are displayed with the Master Key shown on
three lines:
92 cf 00 c0 0f e6 2a 26 04 36 97 71 0b c7 99 a3
0a f9 c9 28 a1 5c ba 82 88 1d f8 b7 83 66 ab 8e
44 98 2d e6 31 db 7c 67 07 6b f0 10 ea f5 a5 8e

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 170

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Decode TLS packets in Wireshark

2. Filter PCAP logs on SSL

In the Wireshark window, enter SSL in the Filter field as follows:

The session ID is displayed in the Server Hello message:

7615f6d8449b185379a1f75f324e85cd1d2e64caeb9d77afddbe146c998dece7

3. Create a .txt file with the session ID and the master key as follows
RSA Session-ID:<Session ID Value><space>Master-Key:<Master Key value>
<newline>
<newline>

NOTE Two <newline> entries are required or Wireshark does not decode the TLS packets.

The following is an example .txt file using the values from Steps 1 and 2:
RSA Session-
ID:7615f6d8449b185379a1f75f324e85cd1d2e64caeb9d77afddbe146c998dece7 Master-
Key:92cf00c00fe62a26043697710bc799a30af9c928a15cba82881df8b78366ab8e44982de
631db7c67076bf010eaf5a58e

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 171

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Decode TLS packets in Wireshark

4. Decode TLS packets in Wireshark using .txt file

a. In the Wireshark window, select Edit > Preferences > Protocols. The Preferences – Profile:
Default window opens.
b. Do the following as shown in the Preferences – Profile:Default window:
– Left pane – Select SSL.
– Click Reassemble SSL records spanning multiple TCP segments.
– Click Reassemble SSL Application Data spanning multiple SSL records.
– (Pre)-Master-Secret log filename – Browse to select the .txt file.
c. Click OK.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 172

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Decode TLS packets in Wireshark

C.2.1 Sample Wireshark window

The following is an example of the Wireshark window before TLS packets are decoded.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 173

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Decode TLS packets in Wireshark

The following is an example of the Wireshark window after TLS packets are decoded.

C.2.2 Multiple TLS sessions

If there are multiple TLS sessions negotiated, follow the directions in this section to create a single .txt
file that includes each session ID.
1. Complete the same steps in Procedure to decode TLS packet for each TLS session.
2. Find all Session IDs by entering ssl&& ssl.handshake.type = = “Server Hello”in the Wireshark
window Filter field.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 174

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual Decode TLS packets in Wireshark

The following is an example of three TLS sessions after performing the instructions three times:

Create a single .txt file including the session IDs for each TLS session. Two <newlines> are present at
the end of this .txt file.

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 175

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
D References

D.1 Related documents

Title Number

Qualcomm Technologies, Inc.

Architecture Changes for LTE + LTE Support in Multimode and Data Services 80-P9301-44
For non-Atlas product lines:
For Atlas product lines:
QMI IMSS for MPSS.NI.6.0.X, QMI IMS Settings Svc Spec 80-ND592-32
RCS 5.1 User Capability Exchange AIDL API Interface Specification 80-NE170-2
QMI IMSA for MPSS.NI.6.1, QMI IMS Application Svc Spec 80-ND593-36
EAB Reference Application 80-NK072-1
QMI Master Document (use for QMI_VOICE MPSS documents) 80-NK255-1
IMS Registration Call Flows and Log Analysis 80-PC414-1
IMS NV Reduction 80-P8761-1
ePDG – Modem Data Overview 80-NJ704-2
ePDG – Linux Data Overview 80-NJ704-3
ePDG – Connectivity Engine (CnE) Overview 80-NJ704-4
WLAN Offload via S2b Provisioning for MSM8974 Device on Verizon 80-NA157-197
Wireless
Standards
E-UTRAN - eHRPD Connectivity and Interworking: Core Network Aspects 3GPP2 X.S0057
E-UTRAN Architecture TS 36.401, TS 36.300, TS
23.002
S1 Interface TS 36.41x series, TS 29.274,
TS 24.301
X2 Interface TS 36.42x series
Cellular Radio Telecommunications Intersystem Operations TIA/EIA IS-41
MME Functions and Interfaces TSs23.401, 23.402, 23.002
S10/S11 Interface TS29.274
SAE-GW (SGW/PGW) Functions and Interfaces TS 23.401, TS 23.402, TS
23.002
S5/8 Interface TS 29.274 (GTP), 29.275
(PMIP)

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 176

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual References

Title Number

SGi Interface TS 29.061

Integrated Services Digital Network (ISDN) User Part (ISUP) to Session RFC 3398
Initiation Protocol (SIP) Mapping
S6a Interface TS 29.272
Technical Specification Group Core Network and Terminals; IP multimedia 3GPP TS 24.229
call control protocol based on Session Initiation Protocol (SIP) and Session
Description Protocol (SDP); Stage 3 (Release 13)
Technical Specification Group Radio Access Network; Internet Protocol (IP) 3GPP TS 34.229
multimedia call control protocol based on Session Initiation Protocol (SIP)
and Session Description Protocol (SDP); User Equipment (UE) conformance
specification; Part 1: Protocol conformance specification (Release 10)
Resources
Device Requirements Rich Communication Services Ver 8.0; issued May 2013

D.2 Acronyms and terms

Acronym or term Definition

ADB Android debug bridge

AIDL Android interface definition language
AMR Adaptive multirate codec
AMR-WB AMR wideband
AP Access point
APN Access point name
ARP Address resolution protocol
BGCF Breakout gateway control function
CN Core network
CRBT Customized ringback tone
CSFB Circuit-switched fallback
DR-VCC Dual radio-voice call continuity
DSDS Dual SIM dual standby
DTMF Dual-tone multifrequency
EAB Enhanced address book
ECBM Emergency callBack mode
eHRPD Evolved high rate packet data
eNB Evolved node B
ePDG Evolved packet data gateway
EPS Evolved packet system
E-UTRAN Evolved universal terrestrial radio access
FT File transfer
GBR Guaranteed bitrate

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 177

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual References

Acronym or term Definition

GSMA GEO Mobile Satellite Air Interface

GTP GPRS tunneling protocol
HO Handover
HSS Home subscriber server
ICSI IMS communication services identifier
IPSec Internet Protocol security
iRAT Inter radio access technology
IS Image share
IWF Interworking function
IWLAN Industrial wireless LAN
JNI Java Native Interface
KPI Key performance indicator
LPM Low-power mode
MAC Media access control
MGCF Media gateway control function
MGW Media gateway
MME Mobility management entity
MMTel ICSI IMS communication services identifier
MO Mobile originated
MRFC Media resource function controller
MRFP Media resource function processor
MT Mobile terminated
PCRF Policy and charging rules function
P-CSCF Proxy call session control function
PDCP Packet data convergence protocol
PDN Packet data network
PGW PDN gateway
PHY Physical layer
PRACK Provisional response acknowledgement
PRBT Personalized ringback tone
PSAP Public Safety Answering Point
QCI QoS class identifier
QoS Quality of service
RACH Random access channel
RAT Radio access technology
RCS Rich communication services
RLC Radio link control
RoHC Robust header compression

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 178

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION
IMS Design and Log Analysis Reference Manual References

Acronym or term Definition

RRC Radio resource control

RSRQ Reference signal received quality
RTP Real time transport protocol
SDP Session description protocol
SER Symbol error rate
SGW Serving gateway
SigComp Signaling compression
SIP Session initiation protocol
SUPL Secure user plane location
TBS Transport block set
TFT Traffic flow template
TLS Transport layer security
UDP User datagram protocol
UICC Universal integrated circuit card
VoIP Voice over IP
VoLTE Voice over long term evolution
VoWi-Fi Voice over Wi-Fi
VS Video Sharing
VT Videotelephony

80-PP068-3 Rev. A Confidential and Proprietary - Qualcomm Technologies, Inc. 179

MAY CONTAIN U.S. AND INTERNATIONAL EXPORT CONTROLLED INFORMATION