Information Sharing of Important VoLTE Issues (2016-11)

Information Sharing of Important
VoLTE Issues (2016-11)
Issue 01
Date 2016-12-29
HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2016. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and
the customer. All or part of the products, services and features described in this document may not be
within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements,
information, and recommendations in this document are provided "AS IS" without warranties, guarantees
or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in the
preparation of this document to ensure accuracy of the contents, but all statements, information, and
recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China
Website: http://www.huawei.com
Email: support@huawei.com
Issue 01 (2016-12-29) Huawei Proprietary and Confidential i

Copyright © Huawei
Technologies Co., Ltd.
Information Sharing of Important VoLTE Issues (2016-
11) Contents
Contents
1 Overview.........................................................................................................................................1
2 Fault Cases......................................................................................................................................2
2.1 Fault Cases for November 2016.....................................................................................................................................2
2.1.1 In the IMS-AKA Service, Calls Cannot Be Properly Released Because the SBC Does Not Use the Expected SA. .2
2.1.2 Calls Fail Because the Registration Cache Function Is Enabled for the SE2900.......................................................4
2.1.3 Calling Party Cannot Hear the Called Party Due to Inconsistent Payload Values......................................................4
2.1.4 Customized Ring Back Tone Heard by the CS Subscriber Is Not Complete in a CS-to-VoLTE Call........................6
2.1.5 MME Disconnects Calls Because the eMSC Server Returns a Handover Success Response Upon Receiving a 404
Message Indicating a Handover Failure...............................................................................................................................7
2.1.6 Media Negotiation Fails Because the Clock Rate of the Codec Used by the Call Is Different from the RFC2833
Clock Rate............................................................................................................................................................................8
2.1.7 Two More TransCoders Are Required Due to Inconsistent maxptime Values, Causing Poor Voice Quality.............9
2.1.8 Session Timer Negotiation Fails in Non-stable State................................................................................................10
2.2 Fault Cases for October 2016.......................................................................................................................................11
2.2.1 Due to Long Period of Paging, No Tone Is Played to a Called Party After the Called Party Answers a Call...........11
2.2.2 Calls from VoLTE Subscribers to Local Fixed-Line Subscribers Fail After an eSRVCC Handover........................15
2.2.3 Triggering the MCN Service Fails When the HSS Does Not Block an IMPU in IMSI Format...............................17
2.2.4 Conference Call Fails After Adding a Participant to the Conference Fails (Occurring Only for iPhones)...............19
2.2.5 Calls to VoLTE Subscribers Fail After They Are Handed Over to a 2G Network Because of Defective PSI
Procedure on the eMSC......................................................................................................................................................20
2.2.6 After Calling Parties Are Handed Over to a 2G Network, Their New Calls to VoLTE Subscribers Are Fallen Back
............................................................................................................................................................................................22
2.2.7 CFB Service Fails to Be Triggered for a VoLTE Subscriber on a 2G Network Because the ACM Message Sent
from the VMSC Server Does Not Carry a Cause Value.....................................................................................................23
2.2.8 Incorrect Call End Time Is Recorded in ACRs After the Bearer Release Timer Expires.........................................25
2.2.9 Measurement Result of Diameter Success But Data Not Exist Sharply Increases After Some Subscribers Are
Migrated from HSS1 to HSS2............................................................................................................................................27
2.2.10 No Ring Back Tone Is Played After the ATS Triggers the CFNRY Service...........................................................29
2.2.11 Calls Addressed to VoLTE Subscribers Served by NSN HSS May Fail.................................................................30
2.2.12 eSRVCC Handover Success Rate Decreases by 5% Because ALM-10828 Is Not Cleared as Instructed..............31
2.2.13 CPU Overload Alarms Are Generated for USRSU Boards on the DRA Because Low-end VoLTE UEs Initiate a
Large Number of PDN Connection and Disconnection Requests......................................................................................34
2.3 Fault Cases for August 2016.........................................................................................................................................36
Issue 01 (2016-12-29) Huawei Proprietary and Confidential ii

Copyright © Huawei
11) Contents
2.3.1 During Implementation of the IN SMS Service, the ATS9900 Does Not Support Use of the Location Information
IE of the IDP Message to Carry ECGI Information...........................................................................................................36
2.3.2 Call Forwarding Service Cannot Be Triggered When the History-Info Header Field of the INVITE Message
Received by the ATS9900 Contains the Privacy Parameter...............................................................................................37
2.3.3 After the Terminating SCC AS Triggers CS Retry, the Call Is Connected but the Calling and Called Parties Cannot
Talk with Each Other..........................................................................................................................................................38
2.3.4 Timestamps in ACR Messages Sent by the ATS9900 Are Incorrect When the Bearer Is Lost.................................39
2.3.5 Contact Header Field of the NOTIFY Message Sent by the ATS9900 Does Not Carry the Conference URI,
Causing a Failure in Inviting New Subscribers to the Conference....................................................................................40
2.3.6 After Call permitted with insufficient bandwidth Is Set to Y(Yes), the SE2900 Does Not Return a 488 Message
When Required Bandwidth Resources in the INVITE Message Sent by the Core Side Are Insufficient..........................41
2.3.7 Held Party Cannot Hear an Announcement...............................................................................................................42
2.3.8 NOTIFY and BYE Messages That Traverse the SE2900 Arrive Out of Order.........................................................42
2.3.9 During Alerting Switchover, the SCC AS Initiates an UPDATE Message to Change the Media PT Value,
Disconnecting the Voice Connection..................................................................................................................................43
2.3.10 TCP Links Fail to Be Established When Waiting for a TCP Link Establishment Response Times Out.................44
2.4 Fault Cases for July 2016.............................................................................................................................................45
2.4.1 Location Information Carried in the IMS-Visited-Network-Identifier AVP of CDRs Generated by the ATS9900 Is
Incorrect..............................................................................................................................................................................45
2.4.2 CDIV Services Cannot Be Triggered When VoLTE Subscribers Roam to a CS Network in Another Country.......46
2.4.3 Calling Party Cannot Hear the Local Ring Back Tone After the Customized Ring Back Tone Fails to Be Played. 47
2.4.4 CDIV Service Processing on the Next-hop NE Fails Because the Value of Privacy in the Diversion Header Field
of the INVITE Message Sent from the ATS9900 Is Incorrect............................................................................................48
2.4.5 Timestamp In ACR Messages Sent from the ATS9900 Is Incorrect.........................................................................49
2.4.6 ATS9900 Does Not Stopping Playing the Customized Ring Back Tone Upon Receiving a 183 Message That
Carries the P-Early-Media Header Field But Does Not Carry the SDP Information When a Call Is Routed to the CS
Network and Then the CFNRy Service Is Triggered..........................................................................................................50
2.4.7 ALM-20051 Bill Pool OverLoad Alarm Is Generated for the ATS9900...................................................................51
2.4.8 SPU Board Is Reset When There Are a Large Number of Calls in Two-System Networking..................................52
2.4.9 EXP USRINF May Fail to Run.................................................................................................................................53
2.5 Fault Cases for June 2016.............................................................................................................................................54
2.5.1 SE2900 May Fail to Connect Calls to Called Parties Due to UE Abnormalities......................................................54
2.5.2 SE2900 Returns a 404 Response After Receiving a Handover INVITE Message from the SRVCC IWF...............55
2.5.3 Second Call Fails When VoWiFi Subscribers Initiate Re-registrations in the ICS Domain After eSRVCC
Handovers...........................................................................................................................................................................56
2.5.4 eSRVCC Handover Fails for Conference Service Parties, Resulting in a Failure in Re-establishing Conference
Information.........................................................................................................................................................................57
2.5.5 S-CSCF Returns a 503 Message After Receiving an INVITE Message from the AS..............................................58
2.5.6 VoLTE Subscriber Fails to Receive a Call Immediately After Powering on the Mobile Phone...............................59
2.5.7 Terminating S-CSCF Returns a 500 Message for an Intra-VoLTE Call....................................................................60
2.5.8 eSRVCC Handover Success Rate for High-Speed Railway Dedicated Networks Is Low........................................61
2.5.9 Session Binding Service Fails When the origin-host in the CCA Message Is Inconsistent with the DMPEER host-
name Configured on the SPS..............................................................................................................................................62
2.5.10 Peer End Fails to Re-establish a Link with the SPS After the SPS Disconnects the Link with the Peer End Due to
the Failure in Receiving the DWA Message.......................................................................................................................63
Issue 01 (2016-12-29) Huawei Proprietary and Confidential iii

Copyright © Huawei
11) Contents
2.5.11 When Subscription to VoLTE SRVCC Is Not Enabled on the HSS, SRVCC Handovers Fail for VoLTE UEs in
Special Scenarios................................................................................................................................................................64
2.6 Fault Cases for May 2016.............................................................................................................................................66
2.6.1 Bandwidth Values Carried in AAR Messages Sent by the SE2900 Are Incorrect During an eSRVCC Handback. .66
2.6.2 404 Message Is Returned for an eSRVCC Handover Initiated by the Calling Party................................................67
2.6.3 When a VoLTE UE Initiates a Video Call, the SE2900 Does Not Use the Bandwidth Specified in the 'b=' Line of
SDP Information Carried in the UE-Initiated Message, Wasting Wireless Network Bandwidth Resources.....................68
2.6.4 VoLTE Calling Party Cannot Hear the Called Party After Initiating an aSRVCC Handover....................................69
2.6.5 SCC AS Does Not Include the +g.3gpp.mid-call Parameter in the Feature-Caps Header Field of the 200 Message
for Handover Success.........................................................................................................................................................71
2.6.6 ATS9900 Occasionally Sends 500 Messages to Calls Initiated from a VoLTE Subscriber to Another VoLTE
Subscriber Attached to the CS Domain..............................................................................................................................72
2.6.7 SRVCC Handover of the Second Call for a Subscriber Having Two Calls Fails as the SCC AS Does Not Send the
REFER Message.................................................................................................................................................................73
2.6.8 VoLTE UE Registration Fails as the S-CSCF Returns a 500 Message.....................................................................75
2.6.9 Registered VoLTE UE Fails to Initiate a Registration Again Using Plaintext as the S-CSCF Returns a 403 Message
............................................................................................................................................................................................76
2.6.10 400 Message (Bad Request) Is Returned to the Initial Registration of an iPhone..................................................77
2.6.11 486 Message Is Returned to the Initial Registration of a Non-iOS Terminal..........................................................79
2.6.12 Registration of VoBB Terminals at a VoBB+VoLTE Site Fails If the Minimum Registration Duration Is Modified
............................................................................................................................................................................................80
2.6.13 Deregistered Subscriber Is in the Registered State on the ATS...............................................................................82
2.6.14 Third-party Deregistration Fails..............................................................................................................................83
2.6.15 Registration on the 4G Network Is Successful But Calls Fell Back to the 2G/3G Network When Huawei CSCF
Cooperates with Bell PSBC................................................................................................................................................84
2.6.16 VoLTE Subscriber Fails to be Called After Roams to the Alcatel-Lucent PSBC as the P-Associated-URI
Contained in the 200 (to REGISTER) Message Does Not Carry a tel URI.......................................................................85
2.6.17 Subscriber Cannot Make or Receive Calls After the Registration Is Updated, Which Is Restored After the
Subscriber Initiates a Registration Again...........................................................................................................................87
2.6.18 CSCF Returns 403 Messages When Different Subscribers Use the Same Call-ID to Initiate Registrations..........88
2.6.19 CSCF Connects a Call After Receiving a 405 Message from the AS.....................................................................89
2.6.20 CSCF Sends a BYE Message Immediately After the Called Party Answers the Call............................................91
2.6.21 Originating S-CSCF Returns a 500 Message for a Call Between Two IMS Subscribers After Querying the
ENUM Server.....................................................................................................................................................................93
2.6.22 Teleconference Fails After a VoLTE Video Call Falls Back to a Voice Call...........................................................95
2.7 Fault Cases for April 2016............................................................................................................................................97
2.7.1 Called UE Returns a 488 Message............................................................................................................................97
2.7.2 RTA Message Does Not Carry the Origin-Host and Origin-Realm AVP..................................................................99
2.7.3 VoLTE Subscriber Fails to Send a Short Message After a LTE-to-3G Handover...................................................100
2.7.4 No-reply Timer in the Default Call Forwarding upon No Reply Service Uses an Incorrect Value........................102
2.7.5 SCU Module Restarts When More Than Two Extended Header Fields Are Removed..........................................105
2.7.6 SCC AS Sends a 480 Message Carrying "No appropriate session for SRVCC/eSRVCC" for a bSRVCC Handover
..........................................................................................................................................................................................106
2.7.7 SCC AS Sends a 480 Message Carrying "Do not match switch condition" for a bSRVCC Handover..................107
2.7.8 ESN Cannot Be Obtained When More Than Four IP Addresses Are Configured for the ATS...............................108
Issue 01 (2016-12-29) Huawei Proprietary and Confidential iv

Copyright © Huawei
11) Contents
2.7.9 Call Is Released Because the MSC Server Fails to Receive a PRACK Message Before the Timer Expires..........109
2.7.10 Encrypted SIP Signaling Hinders Fault Location..................................................................................................111
2.8 Fault Cases for March 2016........................................................................................................................................114
2.8.1 Inconsistent AMR Parameters Cause One-Way Audio...........................................................................................114
2.8.2 Inconsistent AMR Codec Attributes Cause One-Way Audio..................................................................................116
2.8.3 AGCF ua-profile Subscription Fails........................................................................................................................117
2.8.4 CSCF Incorrectly Uses Secure IP Addresses to Forward BYE Messages from Called Parties to Calling Parties..119
2.8.5 After Subscriber Migration, Alarms Indicating That Remote Addresses Are Unreachable Are Generated............121
2.8.6 404 Message May Occur in VoLTE Call Tests........................................................................................................122
2.8.7 SPG Fails to Return limitation-of-parallel-calls to the BSS....................................................................................123
2.8.8 Some Subscribers Fail to Register Due to the Incorrect qop Parameter.................................................................125
2.8.9 ATS Releases the Call Due to Unsupported Fax Codecs When a Voice Call Is Switched to a Fax Call................128
2.9 Fault Cases for February 2016...................................................................................................................................130
2.9.1 iPhones Fail to Register with IMS Networks..........................................................................................................130
2.9.2 Calls Cannot Be Made to iPhones That Are Running in the Data Mode................................................................131
2.9.3 VoLTE Subscribers Using iPhones Fail to Call CS Subscribers.............................................................................132
2.9.4 Calls Addressed to VoLTE Subscribers May Fail After IN Services Are Triggered...............................................136
2.9.5 Huawei and Bell Have Different Understandings of IMS Protocols.......................................................................137
2.10 Fault Cases for January 2016...................................................................................................................................139
2.10.1 Modifying Subscription Data on the PGW Fails Due to the Loss of KI Data......................................................139
2.10.2 Ut Service Test Can Be Performed Using the hosts File Embedded in an Android-Based Mobile Phone...........140
2.10.3 Diameter Links Between the CSCF and DRA Do Not Run Properly...................................................................141
2.10.4 SBC Cannot Receive REGISTER Messages from P-GW....................................................................................142
2.10.5 SPG Fails to Issue Service Provisioning Instructions Due to the Change in the Default Value of the INSP
Software Parameter..........................................................................................................................................................143
2.10.6 eSRVCC Handovers Fail Due to eNodeB Configuration Errors...........................................................................144
2.10.7 Calls Fail Due to Access-Side Bearer Resource Insufficiency..............................................................................146
2.10.8 Calls Fail Due to Poor Radio Network Coverage.................................................................................................148
2.10.9 eSRVCC Handovers Fail Due to Abnormal Messages Sent by the UE................................................................151
2.10.10 After the SCC AS Triggers CS Retry, the Terminating S-CSCF Returns a 500 Message...................................153
2.10.11 When Subscribers Register, the CSCF Returns a 403 Message Carrying "Administrator deregister user"........155
2.10.12 When a Call Is Addressed to a VoLTE Subscriber Who Returns to the 4G Network After an eSRVCC Handover,
CSFB Is Performed on the MT Side.................................................................................................................................158
2.10.13 End Office Takes More Than Four Seconds to Return a Response (to PSI) to the HSS.....................................160
2.11 Fault Cases for December 2015................................................................................................................................162
2.11.1 Digit Collection Fails for Calls Addressed to the Number 12580.........................................................................162
2.11.2 Subscribers Who Are Not Defined Using the China Mobile-specific Service Flow Fail to Register...................165
2.11.3 Calls Between VoBB and VoLTE Subscribers Fail...............................................................................................166
2.11.4 Subscribers Attached to SBCs of Another Vendors Cannot Make or Receive Calls After PROTOCOLPARA6
Bit1 Is Set to 1..................................................................................................................................................................168
2.11.5 eSRVCC Handover Requests May Be Forwarded to the I-CSCF When the SE2900 Releases CPU Resources Due
to an Internal Interruption.................................................................................................................................................169
2.12 Fault Cases for November 2015...............................................................................................................................171
Issue 01 (2016-12-29) Huawei Proprietary and Confidential v

Copyright © Huawei
11) Contents
2.12.1 Video Calls from M823 Terminal Subscribers to CS Subscribers Cannot Fall Back to Voice Calls....................171
2.12.2 Quick Signal Attenuation Causes eSRVCC Handovers to Fail.............................................................................172
2.12.3 Incorrect Route Configuration for the Gx Interface on the P-GW Causes a Failure in Establishing Dedicated
Bearers for Calls Between VoLTE Subscribers................................................................................................................174
2.12.4 Calls Initiated by 4G Subscribers to the VoLTE Test Card Fall Back to the 2G Network as Anchoring Data Is Not
Configured for the Card....................................................................................................................................................176
2.12.5 Calls Fail When Diameter Route Data Is Not Configured for the Rx Interface of the SBC.................................178
2.12.6 There Is a Long Delay in Establishing Calls.........................................................................................................179
2.12.7 When an X2-based Handover Is Performed in a Call, the EPC Does Not Send an QCI-1 Bearer Establishment
Request, Causing an Access Failure.................................................................................................................................180
2.12.8 When a Call Is Addressed to a Subscriber Who Has Just Registered, the Network Returns a 403 Message.......182
2.12.9 eSRVCC Handovers Fail Due to Registration Errors............................................................................................183
2.12.10 Calls Fail to Be Answered After aSRVCC Handovers Are Performed for VoLTE Subscribers Who Have
Subscribed to the CRBT Service and Are Being Alerted of Incoming Calls...................................................................185
2.12.11 ZTE Terminal Users Who Have Subscribed to IN Services Encounter Call Loss..............................................186
2.12.12 eSRVCC Handovers Fail When Calls Addressed to Roaming Subscribers Are in the Alerting State................188
2.12.13 Mid-Call Handover Fails for Calls Made by Dialing the Short Number............................................................192
2.12.14 After an eSRVCC Handover Is Performed for an Alerting Call but the Calling Party Hangs Up Before the
Called Party Answers the Handed-Over Call, the Call Cannot Be Released on the Terminating Side............................194
2.12.15 Calls Are Released When the LIA Message Returned by Bell DRA Contains Error Code 5012.......................196
2.12.16 Inband Digit Collection Fails for Calls from VoLTE Subscribers to the 114 Service Platform When the P-Early-
Media Header Field Value in the 183 Message Sent by MGCF Is sendonly...................................................................198
2.12.17 Announcements Fail for Video Calls Addressed to Powered-Off Phones...........................................................200
2.12.18 404 Message Is Returned When an iPhone Registers.........................................................................................202
2.12.19 During a Mid-Call Handover, the REFER Message Cannot Be Sent.................................................................206
2.13 Fault Cases for October 2015...................................................................................................................................207
2.13.1 When a Registered UE Initiates a Subscription to the Subscriber Status, the NOTIFY Message Returned by the
S-CSCF Carries "terminated;reason=noresource"...........................................................................................................207
2.13.2 After the S-CSCF Fails to Contact an AS, It Does Not Continue to Contact Another AS....................................209
2.13.3 After an eSRVCC Handover, the MGCF Fails to Send ICS Registrations Due to "Authentication Failure".......210
2.13.4 RCS Client Receives "Unsupported media type" When Sending MESSAGE Messages.....................................211
2.13.5 During a Mid-Call eSRVCC Handover (with One Held Session and One Active Session), the BYE Message Sent
by the SCC AS Carries "channel type not implemented".................................................................................................213
2.13.6 Incorrect Access Network Information in the CDRs Generated in VoWiFi Handover Scenarios Results in a
Failure in Sorting Out VoWiFi and VoLTE CDRs............................................................................................................215
2.13.7 Media Collision Occurs in "CS CFB + Precondition" Scenarios..........................................................................217
2.13.8 Calling Parties Cannot Hear the Ring Back Tone When Calls to CRBT Subscribers Are Forwarded Upon No
Reply.................................................................................................................................................................................219
2.13.9 CRBT Service Fails When the Time Between the UPDATE Message and 200 (to UPDATE) Message Is Too
Short.................................................................................................................................................................................223
2.13.10 DNS Query Fails When the SRV Record for a Host Name on the DNS Exceeds 512 Bytes and DNS Links
Configured on the CSCF Work in UDP Mode.................................................................................................................224
2.13.11 Calling Terminal Displays the Call Failure When a Call from an iPhone Subscriber in the CS Domain to a
VoLTE Subscriber (IN Service Subscriber) Is Normally Released by the VoLTE Subscriber.........................................226
Issue 01 (2016-12-29) Huawei Proprietary and Confidential vi

Copyright © Huawei
11) Contents
2.13.12 When a Subscriber in the CS Domain Calls a VoLTE Subscriber (CRBT Subscriber), the 491 Message Is
Generated..........................................................................................................................................................................228
2.13.13 One-Way Audio Occurs in Video Calls...............................................................................................................233
2.13.14 Two Announcements Play When Subscribers Attached to Ericsson VMSC Server Call VoLTE Subscribers Who
Are Busy...........................................................................................................................................................................235
2.13.15 When Huawei IMS Interworks with Bell SBC, the TAS Cannot Obtain the sbc-domain Field from the P-
Access-Network-Info Header Field..................................................................................................................................238
2.13.16 ATS Sends PUR Messages to Obtain Transparent Data from the HSS for Unregistered Subscribers................239
2.13.17 Initial Registrations from VoLTE Subscribers Fail..............................................................................................240
2.13.18 Codec Sequence Is Incorrect for SBC Calls and eSRVCC Handovers...............................................................241
2.14 Fault Cases for September 2015...............................................................................................................................243
2.14.1 When the eMSC Sends an INVITE Message to the I-CSCF, the IMS Side Returns a 403 Message, Causing the
Call to Fail........................................................................................................................................................................243
2.14.2 After the IMS Core Completes Initial Registration, the 401 Message Returned by the IMS Core Cannot Be
Routed to the UE Through the SBC Side.........................................................................................................................244
2.14.3 As the INVITE Message Sent by the UE of a Registered VoLTE Subscriber Fails to Traverse the P-GW, the Call
Fails..................................................................................................................................................................................245
2.14.4 E-CSCF Function Embedded in the SE2900 Is Required for IMS Emergency Calls...........................................248
2.14.5 During Subscriber Registration, the CSCF Returns a 500 Message After Receiving an SAA Message..............251
2.14.6 During Service Provisioning, the PUA Message Carries "diameter-error-user-data-not-recognized"..................253
2.14.7 During Third-Party Registration, the SNA Message Carries "diameter-error-user-data-cannot-be-notified"......255
2.14.8 During Third-Party Registration, Some Information in the UDA Message Returned by the HSS Is Lost...........256
2.14.9 During Third-Party Registration, the UDA Message Carries "diameter-error-user-data-not-recognized"...........257
2.14.10 SRVCCW IWF Does Not Carry the Extended Parameter UE-History-Information to the VMSC over the Sv
Interface, Causing a Handover Failure.............................................................................................................................259
2.14.11 When a 4G Subscriber Calls a 3G Subscriber, ZTE VMSC Server Does Not Respond to the UP Negotiation
Request from Huawei MGCF, Causing the Call to Be Released.....................................................................................260
2.14.12 Calls from 4G Subscribers to 3G Subscribers Are Released Due to Incompatibility of Some BICC Parameters
..........................................................................................................................................................................................262
2.14.13 When a Subscriber Roams from a 4G to 2/3G Network and Then Returns to the 4G Network for Registration, a
500 Message Is Received.................................................................................................................................................263
2.14.14 HTC Phones Fail to Call Marvell Phones...........................................................................................................265
2.14.15 In a Multi-Party Call, the Service Party Fails to Merge the Fourth Session.......................................................267
2.14.16 eSRVCC Handover Fails.....................................................................................................................................268
2.14.17 When a Call to B (CBRT Subscriber) Is Forwarded to C (not a CRBT Subscriber) Upon No Reply, C's Terminal
Itself Does Not Play an Alerting Tone..............................................................................................................................270
2.14.18 When the RAU of the Terminal Connects to the 2G Network and Then Returns to the 4G Network Through the
TAU, the VoLTE Indicator of the Terminal Is Lost..........................................................................................................272
2.14.19 Voice Calls May Fail to Be Switched to Video Calls for QualComm Terminals................................................275
2.14.20 VoLTE-to-VoLTE Calls Fail in Jinhua City in Zhejiang Province......................................................................279
2.14.21 SRVCC Handovers Fail During Comba Telecom Tests......................................................................................281
2.14.22 UE Cancels a Call Because the TFT Is Incorrectly Processed............................................................................286
2.14.23 Subsequent Call Fails If a TAU Request Is Initiated at the TA Edge Upon Call Completion.............................290
2.14.24 mid-call eSRVCC Handovers Fail When ZTE IMS Network Interworks with Huawei eMSC..........................293
2.14.25 VoLTE Video Calls Cannot Be Barred................................................................................................................294
Issue 01 (2016-12-29) Huawei Proprietary and Confidential vii

Copyright © Huawei
11) Contents
2.14.26 Announcement Placed to a Call Waiting Subscriber Is Incorrect........................................................................295

2.14.27 Intra-IMS VoLTE Hotline Call Fails...................................................................................................................296
2.14.28 Called Parties on a MPTY Call Are Not Released After Hanging Up................................................................297
2.14.29 Video Call Between a VoLTE Subscriber on an LTE Network and Another VoLTE Subscriber on a 2G/3G
Network Fails...................................................................................................................................................................299
2.14.30 SRVCC IWF Does Not Send an INVITE Message to the IMS Network During an eSRVCC Handover..........299
2.14.31 Participants Are Offline During a Three-Party Call Using Huawei Mate 7........................................................300
2.15 Fault Cases for August 2015.....................................................................................................................................302
2.15.1 Video Calls Fail After SE2900 V300R001C10 Is Upgraded to V300R001C20...................................................302
2.15.2 "ALM-27011 Diameter(SCTP) link path fault" Is Generated After the SE2900's SPU Resets............................303
2.15.3 SE2900 Does Not Switch Traffic Back to the Original I/S-CSCF That Has Already Recovered After the I/S-
CSCF Switchover.............................................................................................................................................................304
2.15.4 VoLTE Users Fail to Be Called Before They Are Re-registered and After the I/S-CSCF Recovered..................305
2.15.5 CSCF Wrongly Disconnects the Existing Call After Receiving a re-REGISTER Message.................................306
2.15.6 HTC UEs Are Registered Successfully but Fail to Initiate Calls After Being Upgraded......................................307
2.15.7 sbc-domain in Access-Network-Information of the CDRs Specific to Certain Originating or Terminating UEs
Does Not Carry Any Area Code Due to the Oversized P-Access-Network-Info Header Field.......................................308
2.15.8 Registration Service Fails When the Contact Header Field Contains More Than 256 Bytes...............................309
2.15.9 VoLTE and VoBB Performance Measurement Statistics Are Not Separated........................................................310
2.15.10 VoLTE Test Result Shows that the MATE 7's Video Fallback Function May Fail.............................................312
2.15.11 Galaxy S6/MATE7/iPhone6 Fails to Call the Fixed-Line Number Served by the MA5620..............................313
2.15.12 No-audio Issue Occurs After the Call Initiated by the M821 UE to a Fixed-Line Number Served by the MA5620
Is Established....................................................................................................................................................................314
2.15.13 Call Established Between Two VoLTE UEs Falls Back to the CS Domain Because the Nokia P-GW Cannot
Report the Charging AVP.................................................................................................................................................315
2.15.14 When the VoLTE CRBT User Is Called in the CS Domain, the Calling Party Can Hear the CRBTs but Cannot
Be Informed that the Called Party Is Busy If Being Rejected..........................................................................................317
2.15.15 No CDR Header Is Present in the Empty CDR File on the VoLTE Network......................................................318
2.15.16 When a VoLTE UE Calls a CS UE, the MGCF Keeps Retransmitting the Received UPDATE Message Specific
to the Precondition to the VoLTE UE...............................................................................................................................319
2.15.17 During eSRVCC Tests on Basic Calls, the Announcement of "Sorry, the number you dialed does not exist" Is
Played...............................................................................................................................................................................320
2.15.18 UE Fails to Join the Three-Party Conference, and the ATS Returns a 481 Response.........................................322
2.15.19 Roaming VoLTE UE Fails to Call the Local VoLTE UE, and the SBC Returns a 480 Response.......................323
2.15.20 eSRVCC Handover Fails Because the STN-SR Number in the Handover INVITE Message Is Not Updated. .325
2.15.21 Call to the Roaming VoLTE UE Fails, and the CS Domain Returns a 486 Response........................................327
2.15.22 Same Announcement Is Played When the UE Is Powered Off or Unavailable..................................................329
2.15.23 After UE A That Is Already on a Call with UE B Answers the Call from UE C, the Calls Among Them Are
Disconnected....................................................................................................................................................................332
2.15.24 Call from the CS Domain to a VoLTE UE Fails, and the MGCF Returns a 488 Response................................333
2.15.25 When a Called VoLTE UE Is Unavailable, the Call Is Forwarded and Established Even If the VoLTE UE Does
Not Subscribe to the Cal Forwarding Service on the ATS of the VoLTE Network..........................................................335
2.15.26 Multiple Copies of a Short Message Are Received After the Short Message Is Sent.........................................336
2.16 Fault Cases for July 2015.........................................................................................................................................338
Issue 01 (2016-12-29) Huawei Proprietary and Confidential viii

Copyright © Huawei
11) Contents
2.16.1 CFNR Service Fails...............................................................................................................................................338

2.16.2 Voice Quality Is Poor After Calls Are Forwarded to CS Subscribers Upon Non-Reply.......................................339
2.16.3 VoLTE Registration Fails.......................................................................................................................................340
2.16.4 SE2900 Receives a 404 Message After Sending a SUBSCRIBE Message..........................................................341
2.16.5 CH Service Fails....................................................................................................................................................342
2.16.6 CLIR Service Fails When Calls Are Addressed to Subscribers in the 4G Network.............................................343
2.16.7 MGCF Fails to Convert the ACM (User Busy) Message to a 486 Message.........................................................344
2.16.8 Announcements Are Still Played When Calls are Forwarded...............................................................................345
2.16.9 Domain Selection Fails..........................................................................................................................................345
2.16.10 Video Calls from Samsung S6 Encounter an Error.............................................................................................346
2.16.11 Calls Between VoLTE Subscribers in the 2G Network Occasionally Fail..........................................................347
2.16.12 Roaming VoLTE Subscribers Fail to Register.....................................................................................................348
2.16.13 Too Many SRV Records About the SCC AS Cause ENS Query to Fail.............................................................349
2.16.14 During a Conference Call, When the Conference Call Service Subscriber Initiates a SUBSCRIBE Message, the
MMTel AS Returns a 403 Message..................................................................................................................................350
2.16.15 CS-LOCATION Information Is Not Included in ACRs Generated for Calls Where the Called Party Is in the 2G
Network............................................................................................................................................................................351
2.16.16 Subscribers Cannot Be Provisioned Because Alias repository data download flag Is Set to TRUE..................352
2.16.17 Running ADD SBR on the MMTel AS Fails with the Internal Error Code 10010505.......................................353
2.16.18 Precondition Fails on a CS-to-VoLTE Call Due to Incorrect Software Parameter Setting on the MGCF..........354
2.16.19 Access-Network-Information AVP Does Not Contain the Area Code Due to Incorrect Data Configuration on the
SBC...................................................................................................................................................................................355
2.16.20 IMS Announcement Fails Because the SCC AS Does Not Carry the ICS Capability Indicator.........................356
2.16.21 CDRs Generated for VoLTE-to-VoLTE Calls Do Not Contain the TADS-Indication Due to Software Parameter
Setting on the ATS............................................................................................................................................................357
2.16.22 CFNR Calls to 2G/3G Subscribers Fail Due to Precondition Degrade Configuration on the MGCF................358
2.16.23 Call Waiting Tone Is Not Played Due to Data Configuration on the MGCF When the Service Subscriber Is on a
CS Network......................................................................................................................................................................359
2.16.24 Local Call Number Presentation Fails Because the HSS Provided by the Ericsson Does Not Support Download
of the Shared Alias Group ID Using an SAR Message....................................................................................................362
2.16.25 ATS Service Provisioning Fails Due to Inconsistent Service Rights on the HLR and ATS................................363
3 Historical Problems...................................................................................................................365
3.1 Calls Fail Because Terminals Do Not Support Dynamic Establishment of TCP Connections..................................366
3.2 ATS9900 Does Not Support Anchor IDP Messages with Variable-Length ASN.1 Coding.......................................367
3.3 Active VCU Process Occasionally Fails If the Format of the URI List for Conference Creation Does Not Comply
with the Interface Definition............................................................................................................................................368
3.4 SBC Proactively Sends a BYE Message to Release the Call Initiated by an IPSec AKA Authentication Subscriber
over TCP During Reregistration.......................................................................................................................................369
3.5 One-Way Media Occurs After an aSRVCC Handover...............................................................................................370
3.6 Call Fails to Be Retrieved After an SRVCC Handover Is Performed for a Hold Subscriber.....................................372
3.7 utran-cell-id-3gpp Cannot Be Recorded in CDRs When the P-Access-Network-Info Header Field in an INVITE
Message Exceeds 170 Bytes.............................................................................................................................................373
3.8 SCC AS Does Not Send a MESSAGE Message When the Feature-Caps Header Field in a REGISTER Message
Exceeds 512 Bytes............................................................................................................................................................375
Issue 01 (2016-12-29) Huawei Proprietary and Confidential ix

Copyright © Huawei
11) Contents
3.9 MGCF Returns a 400 Message After Receiving an INVITE Message for a Video Call Initiated by a VoLTE
Subscriber to a CS Subscriber..........................................................................................................................................376
3.10 One-Way Media Occurs When a VoLTE Subscriber Calls a CS Subscriber............................................................377
3.11 SCU Modules Are Overloaded When Multiple UEs in the Same Implicit Registration Set Are Traced.................381
3.12 Call Forwarding Fails If the Precondition Function Is Enabled...............................................................................382
3.13 Extra-long CDRs Are Generated by the ATS9900...................................................................................................384
3.14 SBC Returns an Error Because the Calling Party Hangs Up After an eSRVCC Handover Occurs But Before the
Called Party Answers the Call..........................................................................................................................................385
3.15 VoLTE Call Fallback Occurs Due to USSDs Delivered by the CN Side.................................................................386
3.16 3G SRVCC Handover Fails in the Separate Deployment Scenario.........................................................................387
3.17 Internal Tracing Logs About Subscriber Message Tracing Cannot Be Displayed...................................................389
Issue 01 (2016-12-29) Huawei Proprietary and Confidential x

Copyright © Huawei
11) OverviewOverview
1 Overview
This document summarizes VoLTE faults that occurred at various sites, aiming at improving
the efficiency of troubleshooting similar faults. VoLTE faults vary from site to site. All faults
mentioned in this document are used for reference only.
This document is maintained by Cui Zhaorui (ID: 00184322), who will collect fault cases in
real time or at the end of each month. At the start of each month, Cui Zhaorui will update this
document to Lin Hui (ID: 00150506).
Fault cases can be collected from the following sources:
1. China Mobile General Team (Zhang Min, the coordinator)
2. RTAC (Yi PengXiao)/GTAC (Wang Yufeng)
3. Maintenance Department's coordinator (Yang Erjie, Wu Junlin, Yang Yunyi, and Huang
Jianguo. )
4. TMO (Zhang Chao)
To ensure document quality and minimize workload, each coordinator must use the excel
form provided by Zhang Min to submit complete fault cases, rather than submitting only one
sentence as a fault case. This saves Chui Zhaorui from the painstaking efforts of clarifying
fault cases.
This document is updated monthly with new contents placed in the front.
Issue 01 (2016-12-29) Huawei Proprietary and Confidential 1

Copyright © Huawei
11) Fault CasesFault Cases
2 Fault Cases
2.1 Fault Cases for November 2016

2.2 Fault Cases for October 2016
2.3 Fault Cases for August 2016
2.4 Fault Cases for July 2016
2.5 Fault Cases for June 2016
2.6 Fault Cases for May 2016
2.7 Fault Cases for April 2016
2.8 Fault Cases for March 2016
2.9 Fault Cases for February 2016
2.10 Fault Cases for January 2016
2.11 Fault Cases for December 2015
2.14 Fault Cases for September 2015

Copyright © Huawei

2.1.1 In the IMS-AKA Service, Calls Cannot Be Properly Released
Because the SBC Does Not Use the Expected SA
Basic Information
Involved NE: SBC
Involved version: SE2900 V300R001C20
Applicable scope: global
Trouble ticket number:
Troubleshooting engineer: Pan Shaohua (employee ID: 00225212)
Defect Details
In the IMS-AKA service, the SBC's security association (SA) is not aged during the
registration but it is aged during the call. Consequently, the call cannot be properly released.
Probability of Occurrence
This issue will occur when the following conditions are met.
Condition
1. The SA is changed due to the reregistration.
5. The SA is aged during a call.
Root Cause
The SBC's SA is not aged during the registration but it is aged during the call. Consequently,
the call cannot be properly released.
 An IMS subscriber is registered at 12:14:26. The UE-negotiated SA1 contains port-uc
8028 and port-us 8904. The SBC's SA1 contains port-c 9952 and port-s 9900. The
negotiated aging duration is 1 hour. That is, the SA is aged at 13:14:26.
 The IMS subscriber initiates a reregistration request at 13:04:26, and the UE-negotiated
SA2 contains port-uc 8034 and port-us 8904. The SBC's SA2 contains port-c 9953 and
port-s 9900.
 The IMS subscriber receives a call at 13:13:07, and the UE uses SA1. In this case, the
SBC's SA1 is used according to configuration data.
 The call is ended at 13:16:13. The BYE message sent by the terminating SBC contains
the aged SA1. However, the UE's SA1 is aged, and it uses SA2. Therefore, messages
containing SA1 cannot be received, and the BYE message fails to be delivered.
Troubleshooting
1. Log in to the OMU client, and open the MML Command - SE2900 window.
6. Change bit 31 of BCFPARA9 to 1 to enable the SE2900 to use a new SA for service
requests if the old SA is to be aged.
MOD SFP: INSPN=BCFPARA9, MODTYPE=P1, BIT=31, BITVAL=1;

Copyright © Huawei
7. Run the following commands to configure the number of packets to be forwarded after
IPSec AKA signaling distribution resources are deleted:
SE2900 V300R002C00 does not support the preceding software parameters.
Reference
To obtain detailed information about SE9S00AKA00 IMS-AKA/IPSec, choose Description >
Feature Guide > Optional Features > SE9S00AKA00 IMS-AKA/IPSec in the SE2900
Product Documentation.
2.1.2 Calls Fail Because the Registration Cache Function Is

Enabled for the SE2900
Basic Information
Involved NE: SBC
Involved version: all versions of SE2900
Defect Details
After the registration cache function is enabled, the 200 (to REGISTER) message sent from
the SE2900 to the UE does not contain the P-Associated-URI header field. The UE uses a
temporary IMPU to initiate calls, and call failure occurs.
This issue will occur when the following condition is met.
Condition
The registration cache function is enabled.
Root Cause
After the registration cache function is enabled, the 200 (to REGISTER) message sent from
the SE2900 to the UE does not contain the P-Associated-URI header field. The UE uses a
temporary IMPU to initiate calls, and call failure occurs.
Troubleshooting

Copyright © Huawei
8. Set BCFPARA5 to 1 to enable the SE2900 to include the P-Associated-URI header field
in the 200 (to REGISTER) message to be returned to the UE.
2.1.3 Calling Party Cannot Hear the Called Party Due to

Inconsistent Payload Values
Basic Information
Involved NE: SBC
Involved version: all versions of SE2900
Defect Details
Symptom
The SDP offer sent from the calling party contains the codec payload value A, and the SDP
answer returned by the called party contains the same codec but the payload value is B. After
the call is set up, the calling party cannot hear the called party due to inconsistent payload
values.
Condition
The codecs of the calling and called parties are the same, but the payload values are different.
Cause Analysis
1. The codec carried in the INVITE message sent from the calling party is 102 AMR, but
the codec returned by the peer end is 103 AMR.

Copyright © Huawei
9. After the call is set up, the calling party checks the codec payload type and discards the
103 AMR packets. Therefore, the calling party cannot hear the called party.
Troubleshooting
11. Enable the payload-type value conversion function for the SBC.
MOD BCPLC: BCPLCNAME="xxxx", ENTYPE=ABCF, PTTRANS=Y;
2.1.4 Customized Ring Back Tone Heard by the CS Subscriber Is

Not Complete in a CS-to-VoLTE Call
Basic Information
Involved NE: MSOFTX3000
Involved version: MSOFTX3000 V200R010C20SPC100
Troubleshooting engineer:
Defect Details
Symptom
When a CS subscriber calls a VoLTE subscriber who has subscribed to the CRBT service, the
customized ring back tone heard by the CS subscriber is not complete.

Copyright © Huawei
Condition
The CRBT center sends an UPDATE message to the MGCF.
Cause Analysis
When a CS subscriber calls a VoLTE subscriber who has subscribed to the CRBT service, the
CRBT center sends an UPDATE message to the MGCF. If the MGCF does not convert the
UPDATE message to a 18x message and sends it to the previous NE, the customized ring
back tone is not complete. An UPDATE message can carry the P-Early-Media header field as
defined in RFC5009.
Troubleshooting
Select Supporting the P-Early-Media header field in the UPDATE message for Extra
software parameter 4 of service control.
Parameter Description
Determines whether the SIP trunk group of the MGCF supports the P-Early-Media header
field in the UPDATE message. If Supporting the P-Early-Media header field in the
UPDATE message is selected, the SIP trunk group of the MGCF supports the P-Early-Media
header field in the UPDATE message. If Supporting the P-Early-Media header field in the
UPDATE message is cleared, the SIP trunk group of the MGCF does not support the P-Early-
Media header field in the UPDATE message.
Reference
RFC5009
2.1.5 MME Disconnects Calls Because the eMSC Server Returns a

Handover Success Response Upon Receiving a 404 Message
Indicating a Handover Failure
Basic Information
Defect Details
The ATCF sends a 404 message to the eMSC server, indicating that the handover fails. The
eMSC server returns an SRVCC PS TO CS COMPLETE NOTIFICATION message to the
MME, indicating a handover success. The MME disconnects the call.

Copyright © Huawei
Cause Analysis
After the SRVCC IST flow fails, the ATCF sends a 404 message to the eMSC server,
indicating that the handover fails. The eMSC server returns an SRVCC PS TO CS
COMPLETE NOTIFICATION message to the MME, indicating a handover success. The
MME disconnects the call.
Troubleshooting
Run MOD GTPPE with SRVCC PS to CS Complete Notification contains a cause value
indicating IST failure selected for GTP peer entity capability list. This setting enables the
eMSC server to send an SRVCC PS TO CS COMPLETE NOTIFICATION message
containing a failure cause to the MME, indicating that the IST flow fails.
Summary and Reference

N/A
2.1.6 Media Negotiation Fails Because the Clock Rate of the Codec
Used by the Call Is Different from the RFC2833 Clock Rate
Basic Information
Defect Details
Symptom
The clock rate of the codec used by the call is different from the RFC2833 clock rate.
Therefore, media negotiation fails.
The problem occurs when the following condition is met.
Condition
The clock rate of the codec used by the call is different from the RFC2833 clock rate.
Cause Analysis
The clock rate of the codec used by the call is different from the RFC2833 clock rate. The
peer device determines that RFC2833 is not supported upon receiving the SDP information.
Therefore, media negotiation fails.

Copyright © Huawei
Troubleshooting
Select Sending the telephone-event codec after normalization for Extra software
parameter 5 of service control, and set bit 5 of P1509 to 0.
maxptime determines whether maxptime is included when AMR-WB is preferentially used as
the codec.
 If Sending the telephone-event codec after normalization is selected, the maxptime
parameter is carried over the Mc interface and Nc interface (SIP interface) when AMR-
WB is preferentially used as the codec. The value of maxptime is set to the value of
Maxptime defined by running MOD SIPTG.
 If Sending the telephone-event codec after normalization is cleared, the maxptime
parameter is not carried over the Mc interface and Nc interface (SIP interface) when
AMR-WB is preferentially used as the codec.

N/A
2.1.7 Two More TransCoders Are Required Due to Inconsistent

maxptime Values, Causing Poor Voice Quality
Basic Information
Defect Details
Symptom
Two more TransCoders are detected than expected, and voice quality deteriorates.

Copyright © Huawei
This issue will occur when the following conditions are met.
Condition
1. A 3G subscriber calls a 4G subscriber.
2. Support transmission of maxptime for AMR-WB over SIP/Mc interface is selected for
Extra software parameter 5 of service control.
Cause Analysis
When a 3G subscriber calls a 4G subscriber, the maxptime parameter values in the media
negotiation result are inconsistent. Therefore, two more TransCoders are required for the
UMG, and voice quality deteriorates.
Troubleshooting
Clear Support transmission of maxptime for AMR-WB over SIP/Mc interface for Extra
Support transmission of maxptime for AMR-WB over SIP/Mc interface determines
whether maxptime is included when AMR-WB is preferentially used as the codec.
 If Support transmission of maxptime for AMR-WB over SIP/Mc interface is
selected, the maxptime parameter is carried over the Mc and Nc interfaces (SIP
interface) when AMR-WB is preferentially used as the codec.
 If Support transmission of maxptime for AMR-WB over SIP/Mc interface is cleared,
the maxptime parameter is not carried over the Mc and Nc interfaces (SIP interface)
when AMR-WB is preferentially used as the codec.

N/A
2.1.8 Session Timer Negotiation Fails in Non-stable State

Basic Information
Defect Details
Symptom
VoLTE subscriber A calls VoLTE subscriber B who has subscribed to the CRBT service. An
alerting SRVCC handover occurs during announcement playback. The session timer
negotiation fails, and the session fails.

Copyright © Huawei
Condition
The session timer is negotiated in non-stable state.
Cause Analysis
VoLTE subscriber A calls VoLTE subscriber B who has subscribed to the CRBT service. An
alerting SRVCC handover occurs during announcement playback. When the eMSC server
sends an INVITE message to the ATCF to establish a bearer, the ATS sends an UPDATE
message to the eMSC server through the ATCF because the INVITE message carries the
CRBT media information. The UPDATE message contains the session-timer parameter. The
negotiation fails, and the session fails.
Troubleshooting
Set bit 3 of P1523 to 0.

N/A

2.2.1 Due to Long Period of Paging, No Tone Is Played to a Called
Party After the Called Party Answers a Call
Involved NE: all
Applicable Scope: global
Troubleshooting Engineer: Liang Yongjun (ID: 00302438)
Defect Details
Symptom UE_A and UE_B are both VoLTE subscribers. UE_B resides in an area
with poor network coverage. UE_A initiates a call to UE_B, and UE_B
answers the paging after UE_A releases the call. After UE_B answers the
call, no tone is played to UE_B.
Trouble N/A
Ticket
Number
Root Cause For this call, the calling number is +853668xxxxx and the called number is
+853663xxxxx.
The details about the first call failure are as follows:
At 13:10:23, an IMS domain is selected for the call and an INVITE
message is sent to UE_B over the IMS domain.

Copyright © Huawei
The Call-ID in the INVITE message is

20134s22991bb1or03rs87911b9s0pr8@10.106.128.7.
At 13:10:34, the AS does not receive a 180 message from UE_B within 10
seconds. The AS triggers a CS retry and sends an INVITE message to
UE_B over a CS domain.
At 13:10:43, UE_B does not respond, and UE_A sends a CANCEL

message to release the call.
At 13:11:10, another INVITE message is sent to UE_B. Because UE_B is
engaged in the first call (waiting for an ACK message from UE_A), UE_B
returns a 180 message carrying the call waiting (CW) indicator. The 180
message carries neither an SDP body nor the P-Early-Media header field.
At 13:11:23, UE_B does not receive an ACK message before the

transaction timer expires and sends a BYE message to the SBC. The SBC
does not find the mapping session and returns a 481 message.
At 13:11:47, UE_A sends a CANCEL message to release the second call.
How do we determine that UE_B is engaged in the first call when the
second call arrives?
The traced messages show that UE_B returns a 180 message at 13:10:54
and a 200 message at 13:11:03 in the first call. Because UE_A sends a

Copyright © Huawei
CANCEL message to cancel the first call at 13:10:43, UE_A does not
return an ACK message. The Call-ID in the INVITE message for the
second call (sent at 13:11:10) is
asbc20134s22991bb1or03rs87911b9s0pr8@10.106.128.7, which is the
same as that carried in the INVITE message for the first call (sent at
13:10:23). The same Call-ID means that the INVITE message for the
second call is a retransmitted INVITE message.
Access network configuration queried by running LST SIPAN is as

follows:
When Timeout interval for initial requests is set to 0, the SBC

retransmits an INVITE message at an interval of 1, 2, 4, 4, and 4 seconds
until the retransmission times out (32 seconds) if a called UE does not
respond.
The overall call failure procedure is as follows:
1. At 13:10:23, UE_B is in the IDLE state. After an IMS domain is
selected as the terminating access domain, the SBC receives an INVITE
message and sends it to the UGW. The UGW sends a DDN message
instructing the MME to page UE_B. The MME then instructs the
eNodeB to page UE_B. However, UE_B does not answer the paging.
2. At 13:10:33, the SBC receives a CANCEL message from the CSCF
(because a CS retry is triggered). The SBC does not stop the message
retransmission. The retransmission lasts for 32 seconds. In addition, the
S-GW buffers the data for 3 to 6 seconds.
3. At 13:10:53, UE_B answers the paging. The eNodeB notifies the MME,
which then notifies the S-GW. The S-GW sends the INVITE message to

Copyright © Huawei
UE_B through the eNodeB.

4. UE_B receives the INVITE message, sends 100, 180, and 200 messages
in sequence, and waits for an ACK message.
For UE_A, user experience is as follows:
 From 13:10:23 to 13:10:43, "Calling..." is displayed on UE_A, but no
tone is played.
 From 13:11:10 to 13:11:47, "Ringing..." is displayed on UE_A. Two
cases are possible: First, UE_A plays a common ring back tone when
receiving a 180 message that does not carry an SDP body or the P-
Early-Media header field, as instructed in the SIP protocol. Second,
UE_A may play a CW tone or does not play any tone when receiving
the CW indicator. The second case is rare.
For UE_B, user experience is as follows:
 From 13:10:23 to 13:10:53, no information is displayed on UE_B.
 From 13:10:53 to 13:11:03, UE_B receives an INVITE message and is
alerted.
 From 13:11:10 to 13:11:47, UE_B receives the second call and returns a
180 message carrying the CW indicator.
 From 13:10:03 to 13:11:23, UE_B answers the call, but no tone is played.
 At 13:11:23, UE_B releases the call.
Condition  A called UE resides in an area with poor network coverage.
 An IMS network is selected. The called UE answers paging after the
SBC receives a CANCEL message from the SCC AS.
 The Precondition function is disabled.
Probability This issue may occur when the preceding conditions are met.
of
Occurrence
Involved Version
VoLTE V500R005C00
Solution
Workarounds:
Change the duration of the transaction timer on the SBC to 6 seconds.
It is recommended that the duration of the transaction timer on the SBC plus 3 seconds is less than the
duration of the CS retry timer on the SCC AS.
INITREQTM Timeout interval for initial This parameter specifies the timeout
requests(s) interval for unsolicited initial requests
(OPTIONS, MESSAGE, SUBSCRIBE,
REFER, PUBLISH, and INVITE) sent
to the access network.
Value range: 0-32
Default value: 0

Copyright © Huawei
When setting this parameter, note the

following:
 This parameter is displayed only
when Logical entity type is set to
P-CSCF(P-CSCF).
 When this parameter is set to 0, this
parameter does not take effect and
the SBC uses the timeout interval
defined in SIP.
 You are advised to set this parameter
to 6 in VoLTE scenarios to decrease
the number of retransmitted
requests.
Preventive measures:
When receiving a CANCEL message from the core network, the terminating SBC stops
sending an INVITE message to the access network. This measure is planned to be
implemented in VoLTE V500R005C10.
2.2.2 Calls from VoLTE Subscribers to Local Fixed-Line

Subscribers Fail After an eSRVCC Handover
Troubleshooting Engineer:
Defect Details
Symptom UE_A (a VoLTE subscriber) initiates a call to UE_B. After the call is
connected, UE_A initiates an eSRVCC handover. Then UE_A places the
call with UE_B on hold and initiates a call to UE_C (a fixed-line
subscriber). The call to UE_C fails, and an announcement is played, stating
that the dialed number is invalid. (The call is successful if the called party
is a CSFB or VoLTE subscriber.)
Trouble N/A
Ticket
Number
Root Cause After the eSRVCC handover, UE_A is connected to the eMSC. The eMSC
sends a MAP UPDATE LOCATION REQ message to the convergent
HLR/HSS for a location update. In this case, if UE_A initiates a new call,
the call request is processed by the eMSC.
The following figure shows the location update flow triggered by the
eMSC:

Copyright © Huawei
When UE_A initiates a call to UE_C by dialing UE_C's number alone, the
VMSC server has not initiated a location update and therefore does not
store UE_C's subscriber data. As a result, the VMSC server does not prefix
UE_C's number with the local area code. Instead, it transparently transmits
the call request to the eMSC.
The following figure shows the call request transparently transmitted from
the VMSC server to the eMSC:
The eMSC, which processes all calls in the entire province, does not add an
area code to UE_C's number either. The eMSC forwards the call request to
the CMN by sending an IAM message.
The CMN detects that the called number is not prefixed with an area code
and sends an REL message carrying the cause value unassigned-number to
release the call.
When a VoLTE subscriber, after being handed over to a 2G network, places

an ongoing call on hold and initiates a call to a fixed-line number (without
dialing the area code), the new call always fails. In addition, the eMSC is
responsible for generating CDRs in such a scenario. The billing center can

Copyright © Huawei
associate the ID of the eMSC server and therefore cannot identify whether
a call is a local or toll call.
Condition  An FMC network is deployed.
 An IDP message is sent to trigger an O-CSI service for a VoLTE
subscriber.
 The O-CSI and SMS services have been subscribed to for the subscriber
by running ADD MSR or MOD MSR.
Probability This issue will occur when the preceding conditions are met.
of
Occurrence
Involved Version
MSOFTX3000 V200R010C20
Solution
Workarounds:
N/A
It is update to the carrier whether a patch needs to be developed to enable the eMSC server to
add an area code to a dialed number or whether end users are required to dial an area code
before a fixed-line number.
2.2.3 Triggering the MCN Service Fails When the HSS Does Not
Block an IMPU in IMSI Format
Involved NE: HSS9860
Defect Details
Symptom UE_A is a VoLTE subscriber and has subscribed to the Miss Call Notify
(MCN) service. After UE_A enables the airplane mode, UE_B initiates a
call to UE_A and receives an announcement played by the MCN service
platform. After UE_A disables the airplane mode and accesses the VoLTE
network, no short message is sent to UE_A to indicate the missed call.
Trouble N/A
Ticket
Number
Root Cause Check the messages traced on the ATS. When UE_A is called, the ATS
receives an INVITE message and then a 480 message.

Copyright © Huawei
The ATS sends an INVITE message to the MCN service platform.
The INVITE message carries the History-Info header field, which is set to
the original called number, an IMPU in IMSI format. The MGCF converts
the INVITE message to an IAM message and sends the IAM message to
the MCN service platform. The MCN service platform does not store the
mapping between the IMSI and MSISDN. As a result, the MCN service
platform does not know to which number it should send a short message.
Why does the ATS include an IMPU in IMSI format into the INVITE
message?
The traced messages show that the HSS does not block the IMPU in IMSI
format. In the SAA message sent over the Cx interface, the
BarringIndication field is set to 0, indicating that the blocking function is
disabled.
After the subscription data on the HSS is modified by blocking the IMPU
in IMSI format, the ATS includes the original called number in the correct
format into the INVITE message, and UE_A successfully receives a short
message indicating the missed call.
The root cause is as follows: The HSS does not block the IMPU in IMSI
format. Consequently, the ATS sends this IMPU to the MCN service
platform, and the MCN service platform cannot identify the IMPU and
does not send a short message to indicate the missed call.
Condition The HSS does not block IMPUs in IMSI format.
Probability This issue will occur when the preceding condition is met.
of
Occurrence
Involved Version
HSS9860 V900R008C50

Copyright © Huawei
Solution
Workarounds:
N/A
Modify the subscription data on the HSS by blocking IMPUs in IMSI format.
2.2.4 Conference Call Fails After Adding a Participant to the

Conference Fails (Occurring Only for iPhones)
Involved NE: ATS9900
Defect Details
Symptom A conference call is established for UE_A, UE_B, and UE_C, where UE_A
is the chairperson. UE_A forces UE_B to leave the conference, initiates a
new call to UE_B, and then merges the new call with the previous one. A
message is displayed, indicating that the merging fails. The call is released,
and UE_A starts to search for signals and register with the network. (This
issue occurs when UE_A uses an iPhone 6. It does not occur if UE_A uses
a Mate 8.)
Trouble N/A
Ticket
Number
Root Cause At 14:59:53, a conference call is established. Two REFER messages are
sent to invite UE_B and UE_C to the conference.
At 14:59:59, UE_A sends a REFER message to remove UE_B from the

conference.
At 15:00:19, UE_A initiates a new call to UE_B and places the conference

Copyright © Huawei
call on hold.
At 15:00:31, UE_A merges the two calls. However, an INVITE message
used to place UE_C on hold is sent, but a REFER message used to invite
UE_C to the new conference is not sent.
When the chairperson who uses an iPhone does not send a REFER message
to invite a subscriber to a conference but sends an INVITE message to
place the subscriber on hold, no 4G signals are displayed on the iPhone.
The traced messages on the SBC show that the bearer of the iPhone is
released, causing the ongoing calls to fail.
When the chairperson uses a Mate 8, a REFER message is sent to invite a
subscriber to a conference.
Condition An iPhone subscriber forces a subscriber to leave a conference, invites the
subscriber again, and merges the new call with the previous one.
of
Occurrence
Involved Version
iPhone
Solution
Workarounds:
N/A
This issue occurs because the iPhone does not send a REFER message when inviting a
subscriber to a conference, which is not protocol complaint. The iPhone must be rectified to
resolve the issue.
2.2.5 Calls to VoLTE Subscribers Fail After They Are Handed

Over to a 2G Network Because of Defective PSI Procedure on the
eMSC

Copyright © Huawei
Defect Details
Symptom UE_A and UE_B are on a voice call and then both are handed over to a 2G
network. UE_C initiates a call to UE_A. UE_A places the call with UE_B
on hold and answers the call from UE_C. The call is connected for about 5
seconds and is then automatically released.
Trouble N/A
Ticket
Number
Root Cause After the call with UE_B is connected, UE_A initiates an eSRVCC
handover. After UE_A is handed over to a 2G network, UE_C initiates a
call to UE_A. When UE_A answers the call, a 200 message is sent to the
BGCF through the MGCF. The MGCF does not receive an ACK message
and retransmits the 200 message for another four times (lasting for 5
seconds). The MGCF does not receive any ACK message in response to the
retransmitted 200 message and therefore sends a BYE message.
After the ATS receives the 200 message, the ATS sends a UDR message to
the HSS to query UE_A's location information (at 17:02:39). Five seconds
later (at 17:02:44), the HSS returns a UDA message.
The HSS sends a PSI message to the eMSC to obtain UE_A's location
information and the eMSC responds after 5 seconds.
Consequently, the HSS returns the information to the ATS 5 seconds after
receiving the UDR message. The call on the MGCF times out and is
therefore released.
The eMSC is defective when processing a PSI message received after a

connection is established. The internal processing error causes the eMSC to
respond to the PSI message after the timer (with the duration set to 5
seconds) expires. In addition, the PSI_ACK message carries subscriber

Copyright © Huawei
location information stored previously, rather than real-time location

information.
Condition A call is addressed to a subscriber after the subscriber is handed over to a
2G network.
of
Occurrence
Involved Version
Solution
Workarounds:
Change the duration of the timer on the eMSC to 3 seconds.
MOD TIMER: MPID=PID223, TMRIDX=0, TMRSEQ=20, TMRVAL=3;
A patch will be released to resolve the issue.
2.2.6 After Calling Parties Are Handed Over to a 2G Network,

Their New Calls to VoLTE Subscribers Are Fallen Back
Defect Details
Symptom UE_A and UE_C are both VoLTE subscribers. When UE_A is on a call
with UE_B, an eSRVCC handover is triggered. Then UE_A initiates a call
to UE_C. UE_C is not alerted when an IMS domain is selected as the
terminating access network. After a CSFB is triggered, the call to UE_C is
connected.
Trouble N/A
Ticket
Number
Root Cause The networking is as follows: eMSC -------- STP -------- Anchor AS
After UE_A is handed over to a 2G network, UE_A initiates a location
update and its call is processed by the eMSC.
The eMSC queries the T-CSI from the HSS and sends a message to the
anchor AS through the STP to obtain an anchoring prefix. The anchor AS
returns an anchoring prefix but the eMSC fails to receive it.
This is because the STP does not forward the CONNECT message sent
from the anchor AS to the eMSC.

Copyright © Huawei
The following figure shows the message sent by the eMSC to obtain an
anchoring prefix:
The following figure shows that the message sent by the anchor AS carries
an anchoring prefix (the message does not reach the eMSC). This message
can be traced by creating an SCCP-layer GT tracing task on the eMSC and
anchor AS.
The following figure shows that the eMSC server does not receive the
CONNECT message at the SCCP layer:
The eMSC does not receive the anchoring prefix. After the relevant timer
expires, the eMSC triggers the procedure to obtain UE_C's CSRN. After
obtaining the CSRN, the eMSC routes the call request to the CMN and
connects the call over a CS domain. As a result, UE_C falls back to a 2G
network.
The STP does not forward the CONNECT message to the eMSC, because
the eMSC returns an error.
Condition The CAP subsystem of the eMSC is not configured.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Add the CAP subsystem for the eMSC.
ADD SCCPSSN: SSNNM="XXX", NI=NAT, SSN=CAP, SPC="XXX", OPC="XXX",
RELSSN1=UNDEF, RELSSN2=UNDEF, RELSSN3=UNDEF, RELSSN4=UNDEF,
RELSSN5=UNDEF, INCGT=YES, MOG="PUBLIC";

Copyright © Huawei
2.2.7 CFB Service Fails to Be Triggered for a VoLTE Subscriber on

a 2G Network Because the ACM Message Sent from the VMSC
Server Does Not Carry a Cause Value
Defect Details
Symptom UE_A and UE_B are both VoLTE subscribers. UE_A resides on an LTE
network, and UE_B resides on a 2G network. UE_B has subscribed to the
Call Forwarding Busy (CFB) service, with the forwarded-to party set to
UE_C.
When UE_B is engaged in another call, a call from UE_A to UE_B fails to
be forwarded. Specifically, no ring back tone is displayed. After a period of
time, the call is automatically released or an announcement is played,
stating that the called party is powered off.
Trouble N/A
Ticket
Number
Root Cause The networking is as follows: VMSC server (Huawei) --- MGCF (ZTE) ---
IMS (Huawei)
Messages from the IMS domain show that: When a CS domain is selected
as the terminating access domain for the call, the CSCF receives a 480
message from the MGCF, which then forwards the message to the ATS.
The ATS triggers the CFB service only after receiving a 486 message.
Therefore, the CFB service is not triggered when the ATS receives the 480
message.
Messages from the VMSC server show that: UE_B initiates a call to a
special service number before receiving the call from UE_A. The MGCF
converts the INVITE message from the IMS network to an IAM message
and sends the IAM message to the VMSC server. The VMSC server
responds with an ACM message.

Copyright © Huawei
The ACM message does not carry the BUSY indicator, because the ACM
message sent from the VMSC server to the ACM does not carry a cause
value. Therefore, the MGCF converts the ACM message to a 480 message
and sends the 480 message to the ATS.
In the office direction data queried by running LST OFC

BOFFICEPARA, ACM With Cause is not selected for Office Param.
After ACM With Cause is selected, the ACM message sent from the
VMSC server carries an abnormal announcement cause value. The MGCF
coverts this ACM message to a 486 message. When the ATS receives the
486 message, it triggers the CFB service.
The root cause is as follows:
The ACM message sent from the VMSC server does not carry a cause
value. The MGCF converts this ACM message to a 480 message and sends
the 480 message to the IMS domain. When receiving the 480 message, the
ATS determines that UE_B is not in the busy state and therefore does not
trigger the CFB service.
Condition ACM messages sent from the VMSC server to the MGCF do not carry a
cause value.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A

Copyright © Huawei
Run MOD OFC to select ACM With Cause for Office Param so that ACM messages sent
from the VMSC server carry a cause value.
2.2.8 Incorrect Call End Time Is Recorded in ACRs After the

Bearer Release Timer Expires
Defect Details
Symptom The call end time recorded in a final call detail record (CDR) is more than
30 seconds later than the actual call end time.
Traced messages on the SmartCare show that at 01:39:45, a BYE
message is sent to the originating ATS. At 01:39:48, the originating ATS
receives a new call (with the same calling and called parties). The
originating ATS sends a BYE message to the terminating network to
release the first call. In the final CDR generated for the first call, the call
end time is 01:40:14.
Trouble Ticket N/A
Number
Root Cause The BYE message sent at 01:39:45 carries the Reason header field, with
the cause value set to 503. The ATS determines that the BYE message is
caused by bearer release.
Reason:
SIP;cause=503;text="03077.08574.A.005.404.228.0.0.00060.00000000
Bearer Released"
Therefore, the ATS starts the bearer release timer with the duration set to
8 seconds. This timer enables the ATS to release the call and generate an
ACR [Stop] message upon the timer expiry.
The ATS receives the new call 3 seconds after it starts the timer. Because
the ATS is configured to check active calls of a subscriber when a new
call is addressed to the subscriber, the ATS releases the first call without
waiting for the timer expiry. However, the ATS does not send an ACR
[Stop] message when it releases the call.
Instead, the ATS sends an ACR [Stop] message after the transaction timer
(with the duration set to 34 seconds) expires. In this message, the call end
time is the time when the message is sent minus 8 seconds.

Copyright © Huawei
The timestamps for important events are listed as follows:

 200 (to INVITE): 01:39:11
 BYE (bearer release): 01:39:45 (the actual call end time)
 New INVITE: 01:39:48
 Transaction timer expiry: 01:40:22 (sending of the ACR [Stop]
message)
 Call end time in ACR [Stop]: 01:40:14 (01:40:22 minus 8 seconds)
Difference between the charged call end time and the actual call end time
= Duration from the start of the bearer release timer to the receipt of the
second INVITE message + (Duration of the transaction timer - Duration
of the bearer release timer) = x + (34 - 8) = x + 26
Because x is greater than 0 but less than 8, the difference falls within the
range between 26 and 34.
Condition  The ATS is configured to check active calls of a subscriber when a new
call is addressed to the subscriber.
 The bearer of the first call is released.
 The second call arrives within 8 seconds after the bearer release.
Probability of This issue will occur when the preceding conditions are met.
Occurrence
Involved Version
ATS9900 V100R008C20SPC100
Solution
Workarounds:
Run MOD BCCFG to deselect CHKWHENMO(Check current call during new MO call
setup) and CHKWHENMT(Check current call during new MT call setup) for Check
current call during new call setup. The configuration enables the ATS not to check active
calls of a subscriber when a new call is addressed to the subscriber.
Impact of the workaround: The ATS will send a 486 message to reject the second call.
Consequently, the call completion rate slightly decreases.

Copyright © Huawei
Optimize the function provided by Check current call during new call setup. In the case of
bearer release, if the ATS needs to release the first call when receiving a new call request, the
ATS sends an ACR [Stop] message immediately. This optimization ensures the correct call
end time recorded in final CDRs.
This measure will be resolved in the ATS9900 V100R008C20SPH106 patch.
2.2.9 Measurement Result of Diameter Success But Data Not Exist

Sharply Increases After Some Subscribers Are Migrated from
HSS1 to HSS2
Troubleshooting Engineer: Wu Junlin (ID: 00365955) and Li Yong (ID: 00380413)
Defect Details
Symptom After some subscribers are migrated from HSS1 to HSS2, the measurement
result of the measurement entity Diameter Success But Data Not Exist in
the measurement unit ATS SH Interface Measurement sharply increases.
Trouble N/A
Ticket
Number
Root Cause The ATS is connected to the HSS through the DRA.
Obtaining location information about migrated subscribers over the Sh
interface fails. The cause is as follows:
The ATS uses MSISDNs to obtain location information. However, the DRA
is configured with routing data for these subscribers' IMSIs, but not for
their MSISDNs. Consequently, UDR messages used to obtain the location
information are sent to HSS1, causing the failure in obtaining the location
information.
Condition  The ATS is connected to the HSS through the DRA.

 The ATS is configured to use UDR messages and MSISDNs to obtain
subscriber location information. The following figure is command
output for LST HSSCFG:

Copyright © Huawei
 For subscribers migrated from HSS1 to HSS2, no routing data is

configured for their MSISDNs on the DRA.
of
Occurrence
Involved Version
ATS9900 V200R011C10SPC100
Solution
Workarounds:
N/A
Configure routing data for MSISDNs on the DRA, with the destination pointed to the HSS to
which subscribers are migrated.
2.2.10 No Ring Back Tone Is Played After the ATS Triggers the
CFNRY Service
Troubleshooting Engineer: Wang Linlin (ID: 00284077)
Defect Details
Symptom UE_A is a VoLTE or CS subscriber, UE_B is a VoLTE subscriber who has

subscribed to the CFNRY service, and UE_C is a VoLTE or VoBB
subscribers. When UE_A initiates a call to UE_B and UE_B does not
answer the call, the call is forwarded to UE_C. However, after the call is
forwarded, no ring back tone is played to UE_A.
Trouble N/A
Ticket
Number
Root Cause The INVITE message sent to UE_C does not carry an SDP body, and

Copyright © Huawei
UE_C returns a 180 message that carries an SDP body. The SBC adds the
P-Early-Media header field (with the value set to gated) to the 180
message and sends the message to ATS_C. ATS_C transparently transmits
the 180 message to ATS_B, and ATS_B converts the 180 message to an
UPDATE message for media renegotiation. The 180 message disappears,
and no device plays a ring back tone during this process.
Condition After media negotiation is complete, a 180 message carrying an SDP body
is returned.
of
Occurrence
Involved Version
ATS9900 V100R008C10SPC100 or V100R008C20SPC100
Solution
Workarounds:
N/A
 If the 180 message does not carry the P-Early-Media header field or carries the P-Early-
Media header field with an invalid value, set P2323 to 1:
MOD SFP: SPID=2323, VAL=1;
 If the 180 message does not carry Require:precondition, set P2323 to 2:
2.2.11 Calls Addressed to VoLTE Subscribers Served by NSN

HSS May Fail
Troubleshooting Engineer: Zhou Qiang (ID: 00232207)
Defect Details
Symptom After subscribers whose data is stored on NSN HSS have subscribed to
VoLTE services, some calls addressed to them fail.
Trouble N/A
Ticket
Number
Root Cause Messages traced on the SEQ show that the IMS registration status obtained
by the SCC AS from the HSS is 2, indicating that the subscriber is not
registered with the IMS domain. After the SCC AS downloads the
subscriber data, it uses the CS domain as the terminating access domain
and obtains a CSRN from the HSS.

Copyright © Huawei
After the SCC AS sends a UDR message to obtain the CSRN (at 07:55:30),
the HSS does not return a UDA message. The relevant timer expires on the
SCC AS (at 07:55:38).
The message traced on the SCC AS show that the SCC AS, after the 8-
second timer expires, returns a 480 message.
The HSS obtains the CSRN from the CS network. Due to a software defect,
the HSS does not return the CSRN to the SCC AS, causing the call failure.
Condition NSN HSS does not return a CSRN to the SCC AS.
of
Occurrence
Involved Version
Solution
Workarounds:

Copyright © Huawei
N/A
NSN HSS must be rectified to resolve the issue.
2.2.12 eSRVCC Handover Success Rate Decreases by 5% Because

ALM-10828 Is Not Cleared as Instructed
Involved NE: CSC3300
Troubleshooting Engineer: Chen Tao (ID: 00342064)
Defect Details
Symptom A fiber is disconnected, adversely affecting VoLTE services. After the fiber
is reconnected, the eSRVCC handover success rate decreases from 93% to
88%.
Trouble 6303633
Ticket
Number
Root Cause 5. SIP messages exchanged between the ATCF and eMSC are traced on
the SBC. The decrease in the eSRVCC handover success rate is as
follows: The ATCF receives an INVITE message from the eMSC for an
eSRVCC handover of a subscriber. Because the subscriber is not
registered with the ATCF, the ATCF returns a 404 message, in which the
Warning header field is set to Init Invite from EMSC Not Found
Former Call. The handover fails. In a word, the INVITE message used
for an eSRVCC handover is sent to an incorrect ATCF.
6. During the fiber disconnection, ALM-10828 High Rate of SIP Request
Retransmission is generated on two CSCFs. The alarm is manually
cleared, without following the instructions provided in the online help.
Consequently, a small proportion of subscribers is registered with two
ATSs simultaneously, causing the decrease in the eSRVCC handover
success rate.
--------------------------------------------------------------------
The alarm details are as follows:
 At 20:04:48 on June 10, ALM-10828 High Rate of SIP Request

Copyright © Huawei
Retransmission was generated on the I-CSCF at the JD site. The peer of

the I-CSCF in the alarm information was the S-CSCF at the RY site.
The alarm was manually cleared at 06:54:59 in June 11.
 At 21:18:06 in May 29, ALM-10828 High Rate of SIP Request
Retransmission was generated on the I-CSCF at the RY site. The peer of
the I-CSCF in the alarm information was the S-CSCF at the JD site. The
alarm was manually cleared at 00:20:45 in May 30.
Though the alarms are cleared, the faults are not rectified. As a result,
REGISTER messages are not sent to the S-CSCF at the other site through
the I-CSCF. Consequently, some subscribers are registered with both ATSs,
causing the decrease in the eSRVCC handover success rate.
The details are as follows:

7. When receiving a REGISTER message from a subscriber at the JD site,
the ATS sends STN-SR 888888 to the HSS.
8. When receiving a REGISTER message from the subscriber at the RY
site, the I-CSCF queries the HSS and detects that the subscriber is
registered with the S-CSCF at the JD site. Therefore, the I-CSCF
attempts to send the REGISTER message to the S-CSCF at the JD site.
Because the connection between the I-CSCF and the S-CSCF at the JD
site is abnormal, the I-CSCF reselects the local S-CSCF. The ATS sends
STN-SR 888999 to the HSS.
9. When the subscriber moves back to the JD site and initiates a
registration, the ATS still uses the subscriber data stored in the previous
registration. The STN-SR is not changed. The ATS does not send STN-
SR 888888 to the HSS. Therefore, the STN-SR stored on the HSS is
888999.
10. When the subscriber initiates a call at the JD site and an eSRVCC
handover occurs during the call, the MME sends a PS to CS Request
message carrying STN-SR 888999 to the eMSC. The eMSC sends an

Copyright © Huawei
INVITE message to the SBC at the RY site for the eSRVCC handover.
However, the call to be handed over is not at the RY site. Therefore, the
SBC sends a 404 message to reject the request.
Condition  On a VoLTE network, the S-CSCF preferentially selects the local ATS.
Alternatively, the following situation occurs: After a subscriber registers
with the ATS, the IP network between the S-CSCF and ATS is faulty.
Then the subscriber registers with another ATS, and the IP network is
restored. Finally, the subscriber registers with the first ATS.
 ALM-10828 High Rate of SIP Request Retransmission is generated on
the CSCFs at both sites, and the alarm is manually cleared, rather than
by following the instructions provided in the online help.
of
Occurrence
Involved Version
CSC3300 V100R011C10SPC100
Solution
Run RCV SIPPEER on the CSCFs at both sites to clear the alarm.
2.2.13 CPU Overload Alarms Are Generated for USRSU Boards on

the DRA Because Low-end VoLTE UEs Initiate a Large Number
of PDN Connection and Disconnection Requests
Involved NE: SPS, UGW9811, and USN9810
Defect Details
Symptom CPU overload alarms are generated for USRSU boards on two DRAs.
Trouble 6813188
Ticket
Number
Root Cause The issue is as follows:
At 00:43, subscriber data is removed on the UGW. UEs initiate a large
number of PDN connection and disconnection events within a short period
of time. The number of Gx interface messages between the P-GW and
DRA sharply increases, causing CPU overload alarms on the DRA.
11. CPU overload is caused by the burst of CCR-I and CCR-T message sent
from the P-GW.
12. PS CDRs obtained from the SEQ database show that the burst of CCR-I

Copyright © Huawei
and CCR-T messages occurs after the removal of subscriber data. The
UEs initiate a large number of PDN connection requests in a short
period of time. After the connections are established, the UEs initiate
PDN disconnection requests, causing the increase of the Gx interface
messages.
13. From 00:45 to 00:55, a single UE initiates 4500 PDN connection and
disconnection requests at most. Such a UE is a low-end smartphone.
14. No IMS registration requests are initiated during the period of PDN
connection and disconnection. No message burst occurs on the SBC,
CSCF, and HSS, and the number of initial registration requests, re-
registration requests, and deregistration requests, and the registration
success rate remain stable.
Condition  The IMS APN is deactivated on the UGW.
 Low-end VoLTE UEs are used.
of
Occurrence
Involved Version
 SPS V300R007C10SPC200
 UGW9811 V900R010C05SPC300
 USN9810 V900R012C05SPC300
Solution
Workaround:
Enable the S1 signaling suppression on the USN (MME). To do so, perform the following
operations:
Step 1 Enable the license used for signaling suppression.
SET LICCTRL: PN="82205492", SWITCH=ON;
If this license is unavailable at your site, apply for it.
Step 2 Adjust the suppression threshold.

SET S1SMARTPARA: ATTACHTHRESH=1000, SRVREQTHRESH=1000,
PDNCONNTHRESH=1000;
Set the threshold based on site requirements.
Step 3 Add the suppression behavior for UEs.

ADD S1SMARTRULE: UETYPE=UNKNOWN_TYPE,
ATTACHCTRLRULE=SPECCAUSEREJ-1&PARKAPNACT-0&DISCARD-1,
SRVREQCTRLRULE=SPECCAUSEREJ-1&CNDETACH-0,
PDNCONNCTRLRULE=SPECCAUSEREJ-1&PARKAPNACT-0&CNDETACH-1,
PDNCONNREJCAUSE=MULTI_PDN_FOR_APN_NOT_ALLOWED,
DETACHCAUSE=PROTOCOL_ERROR_UNSPEC;

Copyright © Huawei
----End
The abnormal behavior of these low-end UEs is uncontrollable. Carriers need to work
together on resolving this issue.

2.3.1 During Implementation of the IN SMS Service, the ATS9900
Does Not Support Use of the Location Information IE of the IDP
Message to Carry ECGI Information
Involved NE: ATS
Troubleshooting: N/A
Defect Details
Symptom During the implementation of the IN SMS service, when the MESSAGE
message from the MO side and the P-Access-Network-Information header
field of the registration message do not contain the network-provided
parameter, the ATS9900 does not support use of the location information IE
of the IDP message to carry ECGI information.
Trouble N/A
Ticket
Number
Root Cause In the preceding scenario, the ATS9900 does not support use of the location
information IE of the IDP message to carry ECGI information.
Condition  FMC networks are deployed.
 An O-CSI IDP message is triggered by a VoLTE subscriber.
 The O-CSI and SMS services have been enabled for the subscriber by
running ADD MSR or MOD MSR.
of
Occurrence
Involved Version
ATS9900 V100R008C20SPC100
Solution
Workarounds
N/A

Copyright © Huawei
Preventive Measures
Install the ATS9900 V100R008C20SPH102 patch. After the installation:
 The MML configuration is modified by running MOD SMSCTL:
SMSPARA=SM_SUPPORT_E-CGI, VAL=1, ECGIRM=HSS;.
 Software parameter 2080 is used. When software parameter 2080 is set to 1, the
ATS9900 obtains ECGI information from the HSS and includes it in the location
information IE of the IDP message.
 Software parameter 2081 is used. When software parameter 2081 is set to 1, the
ATS9900 does not include the ECGI IE in the message sent to the SMSC.
2.3.2 Call Forwarding Service Cannot Be Triggered When the

History-Info Header Field of the INVITE Message Received by
the ATS9900 Contains the Privacy Parameter
Involved NE: ATS
Defect Details
Symptom When the Privacy parameter value length of the History-Info header field
of the INVITE message received by the ATS9900 is 4 or a multiple of 4,
the ATS9900 converts the History-Info header field to a Diversion header
field. However, the Privacy parameter in the Diversion header field is
displayed as garbled characters, causing a failure in triggering the call
forwarding service.
Trouble N/A
Ticket
Number
Root Cause The ATS9900 encounters an internal defect.
 A call forwarding service has been enabled for the subscriber by running
ADD MSR or MOD MSR.
 SFPARA has been set to SEND_DIVERSION-1 by running MOD
SIPCFG on the ATS9900.
 The Privacy parameter value of the History-Info header field of the
INVITE message received by the ATS9900 is none or user.
of
Occurrence
Involved Version
ATS9900 V100R008C20SPC100
Solution

Copyright © Huawei
Workarounds
N/A
Preventive Measures
Install the ATS9900 V100R008C20SPH102 patch.
2.3.3 After the Terminating SCC AS Triggers CS Retry, the Call Is

Connected but the Calling and Called Parties Cannot Talk with
Each Other
Involved NE: ATS
Defect Details
Symptom When the terminating SCC AS receives a 503 message (indicating bearer
loss) during resource reservation, it triggers CS Retry. However, after the
call is connected, the calling and called parties cannot talk with each other.
Trouble N/A
Ticket
Number
Root Cause When the terminating SCC AS triggers CS Retry, it receives an UPDATE
message from the originating side and returns a 200 (to UPDATE) message
in which the media port is 0. The calling UE does not support processing of
media information whose media port is 0 before the call is connected.
Consequently, after the call is connected, media information cannot be
updated and the calling and called parties cannot talk with each other.
 CS Retry Switch has been set to ON(ON), CS Retry Switch After 183
has been set to YES(YES), and CS Retry Trigger Code After 183 has
been set to SIP503(SIP STATUS CODE 503 SERVICE
UNAVAILABLE) by running MOD CSRETRYCFG on the
terminating SCC AS.
 The terminating SCC AS receives a 503 message (indicating bearer loss)
during resource reservation. When it triggers CS Retry, it receives an
UPDATE message from the originating side.
 The calling UE does not support processing of media information in
which the media port is 0 before the call is connected.
of
Occurrence
Involved Version
All versions of the ATS9900

Copyright © Huawei
Solution
Workarounds
N/A
Preventive Measures
After the installation, software parameter 3396 is used to determine whether the ATS9900 sets
the media port to 0 or set the media direction to inactive for the 200 (to UPDATE) message
returned to the calling UE when the following conditions are met:
 The terminating SCC AS receives a 503 message (indicating bearer loss) during resource
reservation. When it triggers CS Retry, it receives an UPDATE message from the
originating side.
 The terminating MMTel AS fails to initiate a call as resource reservation is incomplete.
Then, it receives the UPDATE message from the originating side when playing an
announcement to the originating side.
2.3.4 Timestamps in ACR Messages Sent by the ATS9900 Are

Incorrect When the Bearer Is Lost
Involved NE: ATS
Defect Details
Symptom VoLTE subscriber A calls VoLTE subscriber B. The originating ATS9900

receives a 200 (to INVITE) message from B and a CANCEL message
carrying the cause value 503 (indicating bearer loss) from A almost at the
same time. Then, the ATS9900 sends an ACR [Start] message to the CCF
and starts a bearer loss timer (T_229_0_16_Timer for Waiting for an
SRVCC or eSRVCC Switchover After Bearer Loss). When this timer
expires, the ATS9900 sends an ACR [Stop] message to the CCF. There is a
low probability that SIP-Response-Timestamp in the ACR [Stop] message
is earlier than that in the ACR [Start] message.
Trouble N/A
Ticket
Number
 The originating ATS9900 receives a 200 (to INVITE) message from the
called party and a CANCEL message carrying the cause value 503
(indicating bearer loss) from the calling party almost at the same time.
Probability There is a low probability that this issue will occur when the preceding
of conditions are met.
Occurrence

Copyright © Huawei
Involved Version
Solution
Workarounds
N/A
Preventive Measures
2.3.5 Contact Header Field of the NOTIFY Message Sent by the

ATS9900 Does Not Carry the Conference URI, Causing a Failure
in Inviting New Subscribers to the Conference
Involved NE: ATS
Defect Details
Symptom When a conference service party creates a conference, the Contact header
field of the NOTIFY message sent by the ATS9900 does not carry the
conference URI. Consequently, the conference service party cannot obtain
the conference URI to invite new subscribers to the conference.
Trouble N/A
Ticket
Number
 The CSCF address in the Route header field of the INVITE message used
for creating a conference is in domain name format.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures

Copyright © Huawei
After the installation, software parameter 2037 is used to determine whether the Contact
header field of the NOTIFY message sent by the ATS9900 carries the Conference URI and
isFocus parameters during creation of a conference.
2.3.6 After Call permitted with insufficient bandwidth Is Set to

Y(Yes), the SE2900 Does Not Return a 488 Message When
Required Bandwidth Resources in the INVITE Message Sent by
the Core Side Are Insufficient
Involved NE: SBC
Defect Details
Symptom Call permitted with insufficient bandwidth has been set to Y(Yes) by
running ADD BCPLC for the called UE's SIPAN or PBX-type ISIPTG.
When required bandwidth resources in the INVITE message sent by the
core side are insufficient, the SE2900 returns a 503 message, not a 488
message returned by the SE2600.
Trouble N/A
Ticket
Number
Root Cause When required bandwidth resources in the INVITE message sent by the
core side are insufficient, the SE2900 returns a 503 message rather than
determining whether Call permitted with insufficient bandwidth is set to
Y(Yes).
Condition  Call permitted with insufficient bandwidth has been set to Y(Yes) by
running ADD BCPLC for the called UE's SIPAN or PBX-type ISIPTG.
 The CAC bandwidth restriction function has been enabled.
 Required bandwidth resources in the INVITE message sent by the core
side are insufficient.
of
Occurrence
Involved Version
All versions of the SE2900
Solution
Workarounds
N/A
Preventive Measures
Install the SE2900 V300R002C00SPH216 patch.

Copyright © Huawei
When required bandwidth resources in the INVITE message sent by the core side are
insufficient, the SE2900 returns a 488 message if finding that Call permitted with
insufficient bandwidth is set to Y(Yes). Otherwise, the SE2900 returns a 503 message.
2.3.7 Held Party Cannot Hear an Announcement

Involved NE: SBC
Defect Details
Symptom The held party cannot hear an announcement.

Trouble N/A
Ticket
Number
Root Cause The SE2900 performs media bypass for the call between subscribers
connected to the same NAT device. When the call is held, the media bypass
status is changed. As a result, the SE2900 needs to perform media latching
again. However, as the held UE no longer sends packets, the SE2900
cannot obtain the NAT device's address to forward packets to the NAT
device.
Condition  The calling and called parties are connected to the same NAT device.
 The Media Bypass service has been configured on the SE2900. The
media bypass mode is Automatic media bypass or Intra-AN
automatic media bypass.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
After the installation, a software parameter is used to enable the SE2900 to not perform media
latching when the media bypass status is changed.
2.3.8 NOTIFY and BYE Messages That Traverse the SE2900 Arrive
Out of Order
Involved NE: SBC

Copyright © Huawei

Defect Details
Symptom The NOTIFY and BYE messages that traverse the SE2900 arrive out of
order.
Trouble N/A
Ticket
Number
Root Cause The SE2900 first receives a NOTFIY message and then a BYE message
less than 10 ms later. As the NOTIFY message is typically outside the
dialog and the BYE message is inside the dialog, these two messages are
placed in queues of different priorities. The SE2900 preferentially
processes the BYE message and then the NOTIFY message as the BYE
message queue has a higher priority than the NOTIFY message queue.
Consequently, the upper layer first receives the BYE message and then the
NOTIFY message.
Condition  The call transfer service is being implemented.
 The interval between the time when the SE2900 receives a NOTIFY
message and the time when the SE2900 receives a BYE message is less
than 10 ms.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
After the installation, a software parameter is used to place an NOTIFY message in the in-
dialog message queue when the Event header field of the NOTIFY message contains the
Refer field.
2.3.9 During Alerting Switchover, the SCC AS Initiates an

UPDATE Message to Change the Media PT Value, Disconnecting
the Voice Connection
Involved NE: SBC

Copyright © Huawei
Defect Details
Symptom During alerting switchover, the SCC AS initiates an UPDATE message to

change the media PT value, disconnecting the voice connection.
Trouble N/A
Ticket
Number
Root Cause During alerting switchover, the SCC AS returns a 183 message and then
initiates an UPDATE message for media renegotiation. The PT value in the
UPDATE message is different from that in the 183 message. Due to an
internal defect, the SE2900 still uses the PT value in the 183 message to
perform PT conversion, disconnecting the voice connection.
Condition During alerting switchover, the SCC AS returns a 183 message and then
initiates an UPDATE message for media renegotiation. The PT value in the
UPDATE message is different from that in the 183 message.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
2.3.10 TCP Links Fail to Be Established When Waiting for a TCP

Link Establishment Response Times Out
Involved NE: CSCF
Defect Details
Symptom When the MRFC requests the MCU to establish a TCP link, the MCU
returns a response after 40 ms. Once the MRFC receives the response, it
disconnects the socket connection, resulting in a failure in establishing the
TCP link.
Trouble N/A
Ticket

Copyright © Huawei
Number
Root Cause The duration for waiting for a TCP link establishment response has been set
to 40 ms. If a TCP link establishment response does not arrive within 40
ms, the MRFC determines that the TCP link is faulty and therefore
disconnects the socket connection automatically.
Condition The latency for the CSCF to establish TCP links with other NEs exceeds 40
ms.
of
Occurrence
Involved Version
All versions of the CSC3300
Solution
Workarounds
N/A
Preventive Measures
Install the CSC3300 V100R011C20SPH102 patch.
After the installation, the duration for waiting for a TCP link establishment response is
changed to 2s and TCP links with a latency of less than 2s can be established.

2.4.1 Location Information Carried in the IMS-Visited-Network-
Identifier AVP of CDRs Generated by the ATS9900 Is Incorrect
Involved NE: ATS
Defect Details
Symptom The location information carried in the IMS-Visited-Network-Identifier

AVP of CDRs generated by the ATS9900 is obtained from the P-Visited-
Network-ID header field rather than the local configuration.
Trouble N/A
Ticket
Number
Root Cause The ATS9900 cannot obtain the visited domain from the local configuration
to set the IMS-Visited-Network-Identifier AVP.

Copyright © Huawei

 VCU AVP Control List is set to Visited-Network-Id-1 by running
MOD RFPARAM in the MML Command - ATS9900 window of the
OMU client.
of
Occurrence
Involved Version
ATS9900 V100R008C10SPC100
Solution
Workarounds
N/A
Preventive Measures
P3388 is added to determine how the ATS9900 sets the IMS-Visited-Network-Identifier AVP
in ACRs.
2.4.2 CDIV Services Cannot Be Triggered When VoLTE

Subscribers Roam to a CS Network in Another Country
Involved NE: ATS
Defect Details
Symptom The ATS9900 is configured not to trigger Communication Diversion

(CDIV) services for calls routed to a CS network by running SET/ADD
RMSRVPOL in the MML Command - ATS9900 window of the OMU
client. VoLTE subscriber A has subscribed to CDIV services with voice-
mail-call-completion set to true and call forwarding type set to CFD.
When subscriber A is attached to the CS domain and is roaming
internationally, CDIV services fail.
Trouble N/A
Ticket
Number
Root Cause The ATS9900 does not trigger CDIV services for subscriber A.
 The ATS9900 is configured not to provide CDIV services, including the
Call Forwarding Busy (CFB), Call Forwarding No Reply (CFNR), and
Call Forwarding on User Not Reachable (CFNRc), for calls routed to a
CS network by running SET/ADD RMSRVPOL.

Copyright © Huawei
 Subscriber A has subscribed to CDIV services with voice-mail-call-

completion set to true and call forwarding type set to CFD.
NOTE
The ATS9900 determines that this a CFD service request when any of the following
condition is met:
 rule id is set to any of the following values:
CFB for voice calls: id="call-forwarding-default-by-busy-by-audio";
CFNR for voice calls: id="call-forwarding-default-by-no-answer-by-audio";
CFNRc for voice calls: id="call-forwarding-default-by-not-reachable-by-audio";
CFB for video calls: id="call-forwarding-default-by-busy-by-video";
CFNR for video calls: id="call-forwarding-default-by-no-answer-by-video";
CFNRc for video calls: id="call-forwarding-default-by-not-reachable-by-video";
 ADD VMNUM has been run to add a target number.
 Subscriber A is attached to the CS domain and is roaming internationally.
of
Occurrence
Involved Version
ATS9900 V100R008C10SPC100
Solution
Workarounds
N/A
Preventive Measures
The ATS9900 is enhanced to trigger CDIV services, including CFB, CFNRc, and CFNR,
when the preceding conditions are met.
2.4.3 Calling Party Cannot Hear the Local Ring Back Tone After
the Customized Ring Back Tone Fails to Be Played
Involved NE: ATS
Defect Details
Symptom Play the ring back tone at the MT side is set to NO(NO) by running
ADD LDNSET in the MML Command - ATS9900 window of the OMU
client. VoLTE subscriber B has subscribed to the Customized Ring Back
Tone Control and Trigger (CRBT) service but has not subscribed to the ring
back tone service. When subscriber A calls subscriber B, the CRBT service
is triggered. The customized ring back tone fails to be played, and

Copyright © Huawei
subscriber A cannot hear the ring back tone.

Trouble N/A
Ticket
Number
Root Cause The ATS9900 cannot play the local ring back tone in the preceding
scenarios.
 Play the ring back tone at the MT side is set to NO(NO) by running
ADD LDNSET in the MML Command - ATS9900 window of the
OMU client.
 VoLTE subscriber B has subscribed to the CRBT service but has not
subscribed to the ring back tone service.
 When subscriber A calls subscriber B, the CRBT service is triggered, but
CRBT announcement playback fails.
of
Occurrence
Involved Version
ATS9900 of all versions
Solution
Workarounds
N/A
Preventive Measures
The ATS9900 is enhanced to play the local ring back tone when Failure processing mode is
set to Customized processing by running MOD CRBTCTL.
2.4.4 CDIV Service Processing on the Next-hop NE Fails Because

the Value of Privacy in the Diversion Header Field of the INVITE
Message Sent from the ATS9900 Is Incorrect
Involved NE: ATS
Defect Details
Symptom The ATS9900 converts the History-Info header field in an INVITE message
to the Diversion header field before sending the INVITE message. The
value of Privacy in the Diversion header field is incorrect. Consequently,
CDIV service processing on the next-hop NE fails.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause The ATS9900 transparently transmits the Privacy parameter when
converting the History-Info header field to the Diversion header field.
 P2329 is set to 0, and SEND_DIVERSION(Send Diversion) is selected
for Software parameter of service control by running MOD SIPCFG.
 The ATS9900 converts the History-Info in an INVITE message to the
Diversion header field before sending the INVITE message to the next-
hop NE.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
P3394 is added to determine whether the ATS9900 adaptively configures the Privacy
parameter complying with RFC7544 when converting the History-Info header field to the
Diversion header field.
2.4.5 Timestamp In ACR Messages Sent from the ATS9900 Is

Incorrect
Involved NE: ATS
Defect Details
Symptom In an original ACR [Interim] on the CCF, the time is the same between the
SIP-Request-Timestamp AVP and SIP-Response-Timestamp AVP.
However, the value of the SIP-Request-Timestamp-Fraction AVP is greater
than that of the SIP-Response-Timestamp-Fraction AVP. Consequently, an
extra long ACR is generated.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause The ATS9900 assigns values to SIP-Request-Timestamp-Fraction and SIP-

Response-Timestamp-Fraction AVPs in an ACR sent to the CCF. Time
obtainment methods for these two AVPs are different, as a result, their AVP
values are different occasionally.
 P1736 is set to 1.
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
Rectify the internal defect that caused this issue.
2.4.6 ATS9900 Does Not Stopping Playing the Customized Ring

Back Tone Upon Receiving a 183 Message That Carries the P-
Early-Media Header Field But Does Not Carry the SDP
Information When a Call Is Routed to the CS Network and Then
the CFNRy Service Is Triggered
Involved NE: ATS
Defect Details
Symptom Subscriber A calls subscriber B, and the call is routed to the CS network. B
is alerted, and the CRBT service is triggered. The IMS domain plays a
customized ring back tone. During the announcement playback, B does not
answer the call, and the CFNRy service is triggered. The ATS9900 does not
stopping playing the customized ring back tone when receiving a 183
message that carries the P-Early-Media header field but does not carry the
SDP information. Subscriber A cannot hear subsequent other
announcements.
Trouble SR6234004
Ticket
Number

Copyright © Huawei
Root Cause The ATS9900 is not configured to stop playing the customized ring back
tone when receiving a 183 message that carries the P-Early-Media header
field but does not carry the SDP information.
 The called party has subscribed to the CRBT service by running ADD
MSR or MOD MSR.
 The call is routed to the CS network.
 The CFNRy service is triggered for the called party in the CS domain.
The ATS9900 receives a 181 message and then a 183 message that
carries the P-Early-Media header field (set to sendrecv or sendonly) but
does not carry the SDP information.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
P2084 is added to determine whether the ATS9900 stops playing a customized ring back tone
when receiving a 183 message that carries the P-Early-Media header field but does not carry
the SDP information.
 Subscriber A calls subscriber B, and the call is routed to the CS network.
 The CRBT service is triggered for subscriber B. The IMS domain plays a customized
ring back tone.
 The CFNRy service is triggered for subscriber B in the CS domain. The ATS9900
receives a 183 message that carries the P-Early-Media header field (set to sendrecv or
sendonly) but does not carry the SDP information.
2.4.7 ALM-20051 Bill Pool OverLoad Alarm Is Generated for the

ATS9900
Involved NE: ATS
Defect Details
Symptom ALM-20051 Bill Pool OverLoad Alarm is generated for the ATS9900.

Copyright © Huawei
Trouble SR6382584
Ticket
Number
Root Cause The ATS9900 receives a large number of INVITE messages for media
renegotiation. After media renegotiation is complete, the ATS9900 delivers
ACR [Interim] messages. A large number of ACR [Interim] messages are
accumulated, and ALM-20051 Bill Pool OverLoad Alarm is generated.
 The ATS9900 receives a large number of INVITE messages for media
renegotiation due to a network error.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
P3391 is added to determine whether the ATS9900 sends ACR [Interim] messages based on
the value of ReInvite Bill Flag configured by running MOD RFPARAM after receiving an
INVITE message for media renegotiation.
2.4.8 SPU Board Is Reset When There Are a Large Number of

Calls in Two-System Networking
Involved NE: SBC
Defect Details
Symptom In two-system networking, a large number of concurrent calls may cause

SPU board resetting.
Trouble N/A
Ticket
Number
Root Cause In two-system networking, media forwarding triggers log printing. If there
are a large number of calls, frequent log printing uses many CPU resources.
This may cause SPU board resetting.

Copyright © Huawei
Condition  The dual-system hot backup networking is used.

 There are more than 7000 concurrent calls.
of
Occurrence
Involved Version
SE2900 of all versions
Solution
Workarounds
N/A
Preventive Measures
In two-system networking, media forwarding does not trigger log printing.
2.4.9 EXP USRINF May Fail to Run

Involved NE: CSCF
Defect Details
Symptom Running of EXP USRINF may fail due to timeout.

Trouble SR6302659
Ticket
Number
Root Cause After a user runs EXP USRINF, the host queries subscriber information
and sends the information to the maintenance command processing
module. The module uses a method different from the host to calculate the
message length. As a result, the module accesses the protected memory in
addition to the message package, resulting in the failure of the command.
Condition A user attempts to run EXP USRINF.
of condition is met.
Occurrence
Involved Version
CSC3300 of all versions
Solution

Copyright © Huawei
Workarounds
N/A
Preventive Measures
The maintenance command processing module now uses the same method as the host to
calculate the message length.
2.5 Fault Cases for June 2016

2.5.1 SE2900 May Fail to Connect Calls to Called Parties Due to
UE Abnormalities
Involved NE: SBC
Defect Details
Symptom At a certain site, calls to some subscribers may fail. The symptom is that
the calling party releases the call because no ring back tone is played, and
the called party is not alerted of the incoming call.
Trouble N/A
Ticket
Number
Root Cause A UE has registered with the Contact header field carrying the
transport=tcp parameter. When a call is addressed to the UE, the SE2900
uses TCP links to exchange messages with the UE. This may cause the call
to fail due to an internal defect of the SE2900. After links are aged and re-
established, the call can be restored. However, before link re-establishment,
the call fails.
Condition A call is initiated to a UE that has registered with the Contact header field
carrying the transport=tcp parameter.
Probability This issue may occur when the preceding condition is met.
of
Occurrence
Involved Version
SE2900 V300R001C30SPH100
Solution
Workarounds
1. Change the TCP client's link aging time of the SBC to 2 minutes.

Copyright © Huawei

2. Reset the active and standby SCU processes of the SBC.
This operation does not affect services. Only module alarms are generated.
Resetting method: First reset the standby SCU process and then the active SCU process after
the resetting progress of the standby SCU process reaches 100%. (To check the resetting
progress, click Module Management Pane.)x`
)
RST MODULE: MEID=xxx, MN=xxx, HAST=ACTIVE;
Preventive Measures
2.5.2 SE2900 Returns a 404 Response After Receiving a Handover

INVITE Message from the SRVCC IWF
Involved NE: SBC
Defect Details
Symptom In eSRVCC handover scenarios, when the SRVCC IWF sends a handover
INVITE message to the SE2900, the SE2900 returns a 404 response.
Trouble N/A
Ticket
Number
Root Cause When the Feature-caps header field of a 183 message sent by the called
party contains an SRVCC handover capability parameter that ends with a
comma (,) the SE2900 cannot recognize this parameter. Consequently, the
SE2900 cannot obtain the SRVCC handover capability carried by the called
party, resulting in a handover failure.
Condition In eSRVCC handover scenarios, the Feature-caps header field contains an
SRVCC handover capability parameter that ends with a comma (,).
of

Copyright © Huawei
Occurrence
Involved Version
SE2900 V300R002C00SPH200
Solution
Workarounds
N/A
Preventive Measures
2.5.3 Second Call Fails When VoWiFi Subscribers Initiate Re-

registrations in the ICS Domain After eSRVCC Handovers
Involved NE: ATS
Defect Details
Symptom VoWiFi subscriber A calls subscriber B through WiFi access, and the call is
connected. During the call, A is first handed over to the LTE network.
Then, after an eSRVCC handover, A is handed over to the CS domain. A
initiates a re-registration in the ICS domain. When C calls A at this time,
the ATS9900 routes the call to the IMS domain through domain selection.
As A is unreachable in the IMS domain, the call between A and C fails.
Trouble SR6142398
Ticket
Number
Root Cause A first initiates a call in the IMS domain. Therefore, the IMPI obtained
during the re-registration is specific to the IMS domain. As A has already
registered with in the ICS domain, the IMPI has been replaced with the
IMPI specific to the ICS domain. This means that the ATS9900 cannot use
the IMS domain-specific IMPI to query the ESN, resulting in no update of
the domain selection information.
When a call is addressed to A, the ATS9900 routes the call to the IMS
domain through domain selection, causing the call to fail.
Condition This issue occurs only on FMC networks when both of the following
conditions are met:
 The number of concurrent calls allowed for A is 2.
 A first initiates a call in the IMS domain. After a handover, A re-registers
with the ICS domain and then receives a call.
of

Copyright © Huawei
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
2.5.4 eSRVCC Handover Fails for Conference Service Parties,

Resulting in a Failure in Re-establishing Conference Information
Involved NE: ATS
Defect Details
Symptom A calls B and C. After the calls are connected, A creates a conference and
sends SUBSCRIBE message for a subscription to the conference. Then, A
invites B and C to the conference. At this time, an eSRVCC handover
occurs for A. When this handover fails, the conference information cannot
be re-established.
Trouble N/A
Ticket
Number
Root Cause When the ATS9900 is configured to support conference information re-
establishment (this function is achieved by running MOD SRVCCCFG
with SUPMR(Support conference information reestablishment)
selected for SRVCC Extension Parameter), the Contact header field is
constructed for the 200 response to the conference handover request. The
Contact header field contains the conference URI. In version 11.1, the
conference URI is obtained from the To header field in the SUBSCRIBE
message used for a subscription to conferences.
In this failure scenario, the To header field in the SUBSCRIBE message
carries the conference factory URI and user=phone, instead of the
conference URI (on the live network, the conference URI is carried by the
Request-URI.) If the To header field carries user=phone, the URI
information in the header field is converted into the tel URI format for
storage. However, when the ATS9900 constructs the Contact header field
for a 200 (to a handover request) response, it checks the URI type. If the
URI type is not SIP URI, the ATS9900 returns a failure message rather than
constructing the Contact header field. That is, the ATS9900 cannot returns a
200 (to a handover request), resulting in a failure in re-establishing

Copyright © Huawei
conference information.
Condition This issue occurs only on FMC networks when all of the following
conditions are met:
 The ATS9900 has been configured to support conference information re-
establishment (this function is achieved by running MOD SRVCCCFG
with SUPMR(Support conference information reestablishment)
selected for SRVCC Extension Parameter).
 The To header field in the SUBSCRIBE message used for a subscription
to conferences carries the conference factory URI, instead of the
conference URI.
 The conference factory URI is a SIP URI with user=phone.
of
Occurrence
Involved Version
ATS9900 V100R008C10SPH100
Solution
Workarounds
N/A
Preventive Measures
2.5.5 S-CSCF Returns a 503 Message After Receiving an INVITE

Message from the AS
Involved NE: CSCF
Defect Details
Symptom During a call, the S-CSCF receives an INVITE message from the AS and
returns a 503 message, in which the Warning header field carries "Server
Internal Error." After receiving the 503 message, the AS triggers CS Retry
and receives the same 503 message.
Trouble SR6104100
Ticket
Number
Root Cause A subscriber initiates a call and then immediately releases it. Consequently,
the S-CSCF cannot find the associated session after receiving the INVITE
message from the AS.
Condition  A subscriber initiates a call and then immediately releases it.

Copyright © Huawei
 The S-CSCF takes a long time to contact the AS. Before the S-CSCF
receives an INVITE message from the AS, it receives a CANCEL
message.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
Enable the S-CSCF to returns a 481 message, not a 503 message. This prevents the AS from
accidentally triggering CS Retry.
2.5.6 VoLTE Subscriber Fails to Receive a Call Immediately After

Powering on the Mobile Phone
Involved NE: CSCF
Defect Details
Symptom A VoLTE subscriber is called immediately after powering on the mobile

phone. The SBC sends a 487 message to release the call.
Trouble SR6183366
Ticket
Number
Root Cause The S-CSCF receives a REGISTER message from the VoLTE subscriber
and an INVITE message from the calling party at the same time. As the
VoLTE subscriber has not completed the registration procedure, the S-
CSCF does not have data of the subscriber. Therefore, the S-CSCF sends
an SAR message to the HSS to download data of the subscriber.
Due to an internal system error, the S-CSCF accidentally changes the
VoLTE subscriber's registration status when processing the SAA message.
After the registration is successful, the VoLTE subscriber initiates a
subscription. The S-CSCF returns a NOTIFY message indicating that the
VoLTE subscriber has been deregistered. The SBC receives the NOTIFY
message and sends a 487 message to release the ongoing call.

Copyright © Huawei
Condition  A VoLTE subscriber initiates a registration and receives a call at the same
time.
 Before the S-CSCF receives an SAA (to SAR) message during the
registration, a call is initiated to the VOLTE subscriber. The SAA (for
the registration) message is returned before the SAA (for the call).
 The UE initiates a subscription after a successful registration.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
The internal system defect that caused this issue has been rectified.
2.5.7 Terminating S-CSCF Returns a 500 Message for an Intra-

VoLTE Call
Involved NE: CSCF
Defect Details
Symptom During an intra-VoLTE call, the terminating S-CSCF returns a 500 message
in which the Warning header field carries "Server Internal Error" when
processing the initial INVITE message. The call fails to be established.
Trouble SR6000114
Ticket
Number
Root Cause During the call establishment, the called party is handed over or initiates a
deregistration. As a result, the subscriber data on the S-CSCF is deleted.
When S-CSCF fails to obtain the subscriber data, the call fails.
Condition The called party is deregistered before the S-CSCF sends an INVITE
message to the P-CSCF.
of
Occurrence

Copyright © Huawei
Involved Version
Solution
Workarounds
N/A
Preventive Measures
The S-CSCF now returns a 480 message, not a 500 message if it fails to query subscriber data.
Based on the 480 message, the AS can trigger CS Retry to connect the call.
To provide the preceding solution, install the CSC3300 V100R010C10SPH219 patch.
2.5.8 eSRVCC Handover Success Rate for High-Speed Railway

Dedicated Networks Is Low
Involved NE: BSC
Defect Details
Symptom At a certain site, the eSRVCC handover success rate for high-speed railway
dedicated networks is very low, only about 60%.
Trouble N/A
Ticket
Number
Root Cause The information collected for the site shows that the handover failure cause
is "3 Handover /Relocation Failure with Target system". Based on the
failure cause, it is found that the failure is caused by the fact the eSRVCC
handover switch is not enabled on the BSC. Two switches are used on the
BSC side to control SRVCC handovers: SRVCC handover switch and inter-
RAT incoming handover switch. SRVCC handover is allowed only when
either of the two switches is enabled. As the SRVCC handover switch is
license-controlled, the SRVCC handover switch is disabled at the site. In
addition, the inter-RAT incoming handover switch is disabled at the site.
After either of the two switches is enabled, the eSRVCC handover success
rate for high-speed railway dedicated networks increases from 60% to 98%.
Condition Neither the SRVCC handover switch nor the inter-RAT incoming handover
switch is enabled.
of
Occurrence
Involved Version

Copyright © Huawei
All versions of the BSC

Solution
Workarounds
N/A
Preventive Measures
Enable the SRVCC handover switch, inter-RAT incoming handover switch, or both on the
BSC.
2.5.9 Session Binding Service Fails When the origin-host in the

CCA Message Is Inconsistent with the DMPEER host-name
Configured on the SPS
Involved NE: SPS
Defect Details
Symptom The session binding service has been enabled on the SPS to support routing
of IP-CAN session messages sent by the same subscriber through different
GGSNs to the same PCRF. However, tests show that the session binding
service does not work. The CCR message sent by a subscriber through
GGSN1 is routed to PCRF1, but the message sent by the same subscriber
through GGSN2 is routed to PCRF2 based on flexible routing rules, not
using the session binding service.
Trouble N/A
Ticket
Number
Root Cause 1. A subscriber initiates an IP-CAN session through GGSN1. GGSN1 sends
a CCR_I message to the SPS. The SPS routes the message to PCRF1 based
on flexible routing rules. On the SPS, the host name of PCRF1 is set to
pcrf1.
2. PCRF1 returns a CCA_I message in which the origin-host is
pcrf1.aaa.com. Therefore, when the SPS saves the session binding
information of the subscriber, it saves pcrf1.aaa.com as the host-name.
3. The SPS forwards the CCA-I message to GGSN1.
4. The subscriber initiates an IP-CAN session through GGSN2. GGSN2
sends a CCR_1 message to the SPS. At this time, the SPS queries session
binding data and changes the destination-host in the message to
pcrf1.aaa.com. However, as the host-name is configured on the SPS, the
SPS cannot route the message to PCRF1 based on pcrf1.aaa.com. Instead,
the SPS routes the message to PCRF2 based on flexible routing rules.

Copyright © Huawei
Condition In VoLTE networking scenarios, no S-CSCF capabilities have been

configured for a subscriber, and the ISCAP priority configured for
subscribers at other sites is consistent with that configured for subscribers
in the local province.
of
Occurrence
Involved Version
Solution
Workarounds
Preventive Measures
When PCRF1 returns a CCA message, it includes the correct origin-host (pcrf1) in the
message. Then, after session binding is performed for subsequent messages, they can be
directly routed to PCRF1 based on pcrf1.
2.5.10 Peer End Fails to Re-establish a Link with the SPS After the
SPS Disconnects the Link with the Peer End Due to the Failure in
Receiving the DWA Message
Involved NE: SPS
Defect Details
Symptom The SPS serves as the server but cannot receive the device watchdog
answer (DWA) message sent by the peer. Then, the link between the SPS
and the peer is disconnected and fails to be re-established.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause After the SPS sends a device watchdog request (DWR) message to the peer
end, it does not receive a DWA message. Then, the SPS disconnects the
link with the peer end. Due to an internal defect, the SPS accidently
releases the SCTP association. When the peer end attempts to establish a
link with the SPS, the SPS cannot process the init message from the peer
end, causing a failure in establishing the link.
Condition  The SPS is configured with Diameter links and serves as the server.
 The peer port number is not 0.
 The SPS sends a DWR message to the peer end but does not receive a
DWA message. Then, the SPS disconnects the link with the peer end
and the peer end sends a link establishment request.
of
Occurrence
Involved Version
All patch versions earlier than SPS V300R007C10SPH216
Solution
Workarounds
Run ACT DMLNK to activate Diameter links.
Preventive Measures
If the current version is SPS V300R007C10, upgrade it to SPS V300R007C10SPH216 or
later.
2.5.11 When Subscription to VoLTE SRVCC Is Not Enabled on

the HSS, SRVCC Handovers Fail for VoLTE UEs in Special
Scenarios
Involved NE: HSS9860
Defect Details
Symptom When SRVCC handovers fail for VoLTE UEs of Hutchison (Hong Kong),
the SBC returns a 404 message in which the Warning header field carries
"Random Message To ATCF Address".
Warning: 399 00000.00000.A.200.402.228.0.5.02062.00000000 "Random
Message To ATCF Address"
Trouble SR6302659
Ticket
Number
Root Cause 1. When a VoLTE UE initiates a network attach procedure, it does not

Copyright © Huawei
carry the information element (IE) MS-network-capability to support

SRVCC. Therefore, when the MME sends a ULR message to the HSS
for a location update, the UE-SRVCC-Capability in the message is set
to 0 (not supporting SRVCC).
2. After the VoLTE UE attaches to the network, it sends a REGISTER

message for an initial registration. After the initial registration, the S-
CSCF initiates a third-party registration (SRVCC/eSRVCC) to the ATS
(SCC AS). When the ATS (SCC AS) learns from the HSS that the UE-
SRVCC-Capability is set to 0 (not supporting SRVCC), it does not send
a MESSAGE message to push ATU-STI and C-MSISDN to the SBC
(ATCF).
3. The VoLTE UE initiates a network attach procedure again. The IE MS-

network-capability is carried. The value of bits 21-24 of the IE is 0xE
(1110). The value of bit 21 is 1 (supporting SRVCC).
4. As the VoLTE UE now supports SRVCC, the MME sends an NOR

message to the HSS. In the message, the UE-SRVCC-Capability is set
to 1 (supporting SRVCC).
5. At this time, as the SRVCC subscription is disabled on the HSS, the

HSS does not send a PNR message to push the SRVCC capability to the
ATS (SCC AS).
6. After the VoLTE UE attaches to the network, it sends a REGISTER
message for an initial registration. After the initial registration, the S-
CSCF initials a third-party registration (SRVCC/eSRVCC) to the ATS
(SCC AS). When the ATS (SCC AS) detects that the UE-SRVCC-
Capability is set to 0 (not supporting SRVCC), it still does not send a
MESSAGE message to push ATU-STI and C-MSISDN to the SBC
(ATCF).
7. The subscriber initiates a call. During the call, a handover occurs. The
MME sends an SRVCC PS to CS Request message to the eMSC
(SRVCC IWF). Then, the eMSC sends an INVITE message (for an

Copyright © Huawei
SRVCC handover) to the SBC (ATCF). In the INVITE message, the

Request-URI is STN-SR.
8. As the ATS (SCC AS) has not sent a MESSAGE message, the SBC
returns a 404 message in which the Warning header field carries
"Random Message To ATCF Address" when it fails to obtain the
corresponding C-MSISDN from the received INVITE message (for an
SRVCC handover).
Condition 1. When the VoLTE UE attaches to the TAU or RAU (4G-to-3G) again,
the SRVCC capability is changed.
2. Subscription to VoLTE SRVCC is not enabled on the HSS.
of Note: In normal cases, the SRVCC capabilities of commercial UEs are not
Occurrence changed. Therefore, this issue rarely occurs.
Involved Version
HSS9860 V900R009C00SPC200
Solution
Workarounds
1. Power off the VoLTE UE or enable the offline mode for the VoLTE UE.
2. Wait for one minute (VoLTE UE deregistration takes about 32 seconds; you are advised
to wait for one minute) and power on the VoLTE UE or disable the offline mode for the
VoLTE UE to send an initial registration and obtain the SRVCC capability from the HSS
while the ATS (SCC AS) is performing a third-party registration.
Preventive Measures
On the HSS, set bit 0 of the software parameter VoLTE Enhanced Feature Switch to 1 to
enable subscription to VoLTE SRVCC.
2.6 Fault Cases for May 2016

2.6.1 Bandwidth Values Carried in AAR Messages Sent by the
SE2900 Are Incorrect During an eSRVCC Handback
Involved NE: SBC
Defect Details
Symptom When a UE fails to perform an SRVCC handover, the UE sends an INVITE

message to hand back the session. The bearer bandwidth value carried in
the INVITE message is 49000 bit/s. However, the bandwidth value carried
in the AAR message sent by the SBC is 33000 bit/s.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause On the access network side, the IP address type is IPv6. However, on the
core network side, the IP address type is IPv4. As a result, bandwidth
calculation during an eSRVCC handback is incorrect.
Condition IPv6 addresses are used on the access network side, and IPv4 addresses are
used on the core network side.
of
Occurrence
Involved Version
SE2900 V300R001C20SPH100
Solution
Workarounds
N/A
Preventive Measures
2.6.2 404 Message Is Returned for an eSRVCC Handover Initiated

by the Calling Party
Involved NE: SBC
Applicable Scope: China
Defect Details
Symptom When an initial call between the calling and called parties is not set up and
the calling party sends an INVITE message to perform an eSRVCC
handover, the SE2900 returns a 404 message, stating that the called party
does not exist. However, the called party does exist.
Trouble N/A
Ticket
Number
Root Cause Conflict exists in the handover and call processes. The following figure
shows the detailed processes.

Copyright © Huawei
The SBC returns a 404 message, indicating that the called party does not
exist. However, the called number exists.
Condition  After the SE2900 receives an INVITE message for an eSRVCC
handover, it determines that C-MSISDN/STN-SR matching fails.
 After the SE2900 receives an INVITE message for an eSRVCC
handover, it determines that the original call to be handed over does not
exist.
 After the SE2900 receives an INVITE message for an eSRVCC
handover, it determines that the 180, 183, and 200 messages of the
original call to be handed over are not received.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds
N/A
Preventive Measures
2.6.3 When a VoLTE UE Initiates a Video Call, the SE2900 Does

Not Use the Bandwidth Specified in the 'b=' Line of SDP
Information Carried in the UE-Initiated Message, Wasting
Wireless Network Bandwidth Resources
Involved NE: SBC

Copyright © Huawei

Defect Details
Symptom When a VoLTE UE initiates a video call, the SE2900 does not use the
bandwidth specified in the 'b=' line of SDP information carried in the UE-
initiated message, wasting wireless network bandwidth resources.
Trouble 5432868
Ticket
Number
Root Cause The SE2900 preferentially uses the configured service bandwidth rather
than the 'b=' line as the minimum bandwidth of the Rx interface.
Condition The configured service bandwidth is higher than the bandwidth in the 'b='
line.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds
N/A
Preventive Measures
2.6.4 VoLTE Calling Party Cannot Hear the Called Party After
Initiating an aSRVCC Handover
Involved NE: SBC
Defect Details
Symptom After a VoLTE subscriber, serving as the calling party, initiates an aSRVCC
handover, the calling party cannot hear the called party after the call is
connected.
Trouble 5732167
Ticket
Number
Root Cause During a call handover, PT changes on the originating and terminating

Copyright © Huawei
sides are not considered, which results in incorrect PT value delivery. (The
PT values carried in the INVITE message received by the SBC are 97 and
101. The PT values carried in the INVITE message forwarded by the SBC
are 96 and 97.)
On the media plane, the core network node will receive four PTs, including
the local voice PT, remote voice PT, local 2833 PT, and remote 2833 PT.
In handover failure scenarios, the four PT values are 97, 97, 97, and 101.
When the iMedia identifies the packet type based on the local PT = 97, the
iMedia process voice packets (whose PT is 97) based on local 2833
packets. As a result, voice packet parsing fails and are discarded, and the
calling party cannot hear the called party.
In handover success scenarios, the four PT values are 96, 97, 97, and 101.
In addition, the delivered PT conversion flag enables the HRU to change
the PT (97) of voice packets to 96. In this case, for iMedia, the voice PT is
96 and 2833 PT is 97, and the iMedia can correctly identify voice packets.
Condition The PT and mode-set values carried in the handover requests in the alerting
phase and the original call requests are inconsistent.
of
Occurrence

Copyright © Huawei
Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds
N/A
Preventive Measures
2.6.5 SCC AS Does Not Include the +g.3gpp.mid-call Parameter in

the Feature-Caps Header Field of the 200 Message for Handover
Success
Involved NE: ATS
Troubleshooting: Huang Zhenghua (employee ID: 00248152)
Defect Details
Symptom Subscriber A has two calls. The call between subscribers A and B is placed
on hold, and the call between subscribers A and C is active. Subscriber A
initiates a handover, and the call between A and C is first handed over.
During the handover, the Contact header field in the 200 message sent by
the ATS9900 carries the +g.3gpp.mid-call parameter. However, the peer
SRVCC IWF can parse only the +g.3gpp.mid-call parameter carried in the
Feature-Caps header field. As a result, +g.3gpp.mid-call parsing fails, and
the SRVCC IWF cannot initiate the handover request for the call between A
and B.
Trouble N/A
Ticket
Number
Root Cause As stipulated in 3GPP 24.237-B40, the +g.3gpp.mid-call parameter is
carried in the Contact header field of the 200 message. Currently, the ATS
supports only 3GPP 24.237-B40.
As stipulated in the latest version 3GPP 24.237-B60, the +g.3gpp.mid-call

parameter is carried in the Feature-Caps header field of the 200 message.

Copyright © Huawei
conditions are met:
 Subscriber A has two calls. The call between subscribers A and B is
placed on hold, and the call between subscribers A and C is active.
 Subscriber A initiates a handover.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds
N/A
Preventive Measures
The software parameter P2048 is added. When the software parameter is set to 1, the
+g.3gpp.mid-call parameter is carried in the Feature-Caps header field of the 200 message
sent by the ATS9900 for handover success.
2.6.6 ATS9900 Occasionally Sends 500 Messages to Calls Initiated

from a VoLTE Subscriber to Another VoLTE Subscriber Attached
to the CS Domain
Involved NE: ATS
Defect Details
Symptom Subscribers A and B are VoLTE subscribers, and subscriber B is attached to

the CS domain. When subscriber A initiates calls to subscriber B, and the
ATS9900 receives 200 messages from subscriber B, the ATS9900
occasionally sends 500 messages to subscriber A. As a result, the calls fail.
Trouble N/A
Ticket
Number
Root Cause After the ATS9900 receives a call destined to subscriber B, the ATS9900
downloads service data of subscriber B from the HSS and saves it. By
default, the data can be saved for 90s. After 90s, the ATS9900 sends an
SNR message to the HSS to cancel subscription if the call is released. After
the ATS9900 receives an SNA message from the HSS, the ATS9900 deletes
service data of subscriber B. If the ATS9900 receives a new call destined to

Copyright © Huawei
subscriber B before receiving the SNA message from the HSS, the service
data are deleted during the new call processing. As a result, after the
ATS9900 receives a 200 message from the called party, service data query
fails, and the ATS9900 returns a 500 message.
conditions are met:
 After the service data saving timer on the ATS9900 expires, the ATS9900
sends an SNR message to the HSS to cancel subscription.
 Before the ATS9900 receives an SNA message from the HSS, the
ATS9900 receives a new call destined to the subscriber.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds
N/A
Preventive Measures
After the service data saving timer on the ATS9900 expires, the ATS9900 deletes service data
after it sends an SNR message to the ATS9900. After the ATS9900 receives a new call
destined to a subscriber, the ATS9900 downloads service data of the subscriber from the HSS
again.
2.6.7 SRVCC Handover of the Second Call for a Subscriber

Having Two Calls Fails as the SCC AS Does Not Send the REFER
Message
Involved NE: ATS
Defect Details
Symptom An iPhone 6s plus terminal served by the SBC provided by ZTE initiates a
mid-call SRVCC handover for two calls. One call is placed on hold and the
other is active. However, the SCC AS does not send an REFER message.
As a result, handover of the second call fails.
Trouble 5950888
Ticket
Number

Copyright © Huawei
Root Cause When the iPhone 6s plus terminal served by the SBC provided by ZTE
sends an INVITE message for a mid-call SRVCC handover of two calls
(one is active and the other is placed on hold) to the SCC AS, the SCC AS
sends a BYE instead of an REFER message. As a result, handover of the
second call fails.
The following shows the corresponding printed logs:

Level(WARNING) -> [../patchsrc/VCU_V100R006C10SPH212_sc.c
FileID(3028): 225 <SC_SrvccModifyReferTo>] create To failed, Ret =
[8723297].
The SDP body carries the @ sign, and the SCC AS cannot process the sign.
As a result, the SCC AS fails to construct the Refer-To header field based
on the SDP body.
conditions are met:
 The terminal supports handover of multiple calls.
 Before the handover, a subscriber has two calls that meet any of the
following conditions:
− One call is active and the other is placed on hold. The INVITE
message sent to the SCC AS for handing over the held call carries
the @ sign in the SDP body.
− One call is active and the other is placed on hold. The INVITE
message sent to the SCC AS for handing over the active call carries
the @ sign in the SDP body.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds
N/A
Preventive Measures

Copyright © Huawei
The SCC AS function is enhanced to ensure that it can process the @ sign in the SDP body.
2.6.8 VoLTE UE Registration Fails as the S-CSCF Returns a 500

Message
Troubleshooting: Lin Guoqiang (employee ID: 00342085)
Defect Details
Symptom A VoLTE UE fails to register with the IMS network. The message tracing
result shows that the S-CSCF returns a 500 message to the second
REGISTER message after it sends a 401 message. The Warning header
field in the 500 message carries 399
0.0.S.260.5.115.255.255.5938.0.0.xx.xxx.com "Server Internal Error."
Trouble 4890663
Ticket
Number
Root Cause According to the user message tracing result on the CSC3300, after the S-
CSCF downloads subscriber data from the HSS through the SAR/SAA
process, the S-CSCF does not return a 200 (to REGISTER) message.
Instead, the S-CSCF sends another SAR message carrying
serverAssignmentType:administrativeDeregistration (8), instructing the
HSS to clear the registration state of the subscriber.
From the printed logs, the length of the compressed Contact header field
value is 306.
CscfCompContactParam SipSerialSipHdr fail, ulRet=[72b272c]
ulRealLen=[306]
However, the CSC3300 supports the maximum length of 255 characters for
the Contact header field value. If the Contact header field value in the
REGISTER message exceeds 255 characters and cannot be compressed to
less than 255 characters, registration fails. Currently, a maximum of 1023
characters can be compressed to 255 characters.
Condition The length of the Contact header field value exceeds 255 characters and
cannot be compressed to less than 255 characters.
of
Occurrence
Involved Version
CSC3300 V100R010C10 or later (excluding V500 versions)
Solution
Workarounds
N/A

Copyright © Huawei
Preventive Measures
Compare the Contact header field in the REGISTER message with that in a normal
REGISTER message to check the parameters that are added. Run the following commands to
configure the data:
ADD SRVCAP: FEATURETYPE=FEATURENAMEANDVALUE,
FEATURENAME="+g.3gpp.iari-ref", FEATUREVALUE="urn%3Aurn-7%3A3gpp-
application.ims.iari.rcs", SERVICEID=ALL, COMPRESSFLAG=Y, RESERVED=0;
ADD SRVCAP: FEATURETYPE=FEATURENAMEANDVALUE,
FEATURENAME="+g.3gpp.iari-ref", FEATUREVALUE="urn%3Aurn-7%3A3gpp-
application.ims.iari.rcs.mnc000.mcc460.cloudfile", SERVICEID=ALL,
COMPRESSFLAG=Y, RESERVED=0;
2.6.9 Registered VoLTE UE Fails to Initiate a Registration Again

Using Plaintext as the S-CSCF Returns a 403 Message
Involved NE: SE2900
Defect Details
Symptom A registered VoLTE UE initiates a registration again using plaintext.

However, the S-CSCF returns a 403 message. As a result, the registration
fails. The 403 message carries 399
0.0.S.260.5.119.255.255.5144.0.0.xx.yyy.com "Administrator deregister
user."
Trouble 5671208
Ticket
Number
Root Cause 1. After a VoLTE UE successfully registers with the network using the
IMS-AKA or IPSec authentication mode, IP address and port number of
the UE at the transport layer are not changed. However, the port-s
parameter value used for IPSec negotiation is changed.
2. When the VoLTE UE initiates a registration again using plaintext (not
encrypted using IPSec), the PORT parameter in the Path header field of
the REGISTER message changes but the Contact header field does not
change when the SE2900 forwards the REGISTER message to the S-
CSCF.
3. The S-CSCF considers the registration abnormal and returns a 403
message whose Warning header field carries "Administrator deregister
user."
Condition  The SE2900 interworks with the S-CSCF and verifies the PORT
parameter in the Path header field and IP address and port number
information in the Contact header field.
 In VoLTE networking, the SE2900 functions as the P-CSCF and the port
multiplexing function is enabled.
 After a VoLTE UE successfully registers with the network using the IMS-
AKA or IPSec authentication mode, the IP address and port number at

Copyright © Huawei
the transport layer are not changed. However, the port-s parameter used
for IPSec negotiation is changed, and the UE initiates a registration
again using plaintext (not encrypted using IPSec).
of
Occurrence
Involved Version
SE2900 V300R001C20
Solution
Workarounds
N/A
Preventive Measures
Bit 10 of BCFPARA11 is added to control how the SE2900 sets the port number in the
Contact header field of the forwarded REGISTER request (involving IMS-AKA/IPSec). To
solve this problem, set bit 10 of BCFPARA11 to 1.
Bit 10
Determines the mode that the SE2900 sets the port number in the Contact header field of the forwarded
REGISTER request (involving IMS-AKA/IPSec) when port multiplexing is enabled.
Value:
= 0: The SE2900 sets the port number in the Contact header field of the forwarded REGISTER request
based on the source transport-layer port of the UE-initiated REGISTER request.
= 1: The SE2900 sets the port number in the Contact header field of the forwarded REGISTER request
based on the port-s parameter in the Security-Client header of the UE-initiated REGISTER request.
Default value: 0
2.6.10 400 Message (Bad Request) Is Returned to the Initial

Registration of an iPhone
Defect Details
Symptom An iPhone sends a REGISTER message to initiate a registration. After

receiving a 401 message from the S-CSCF, the terminal sends another
REGISTER message. However, the S-CSCF returns a 400 (Bad Request)
message. The Warning header field in the 400 message carries
3995123.2343.S.260.5.105.7.16.4872.0.0.xx.xxxx.com

Copyright © Huawei
"Sipkeyparameterinvalid."
Trouble N/A
Ticket
Number
Root Cause The registration flow is as follows: 1. At 23:06:58:259, the REGISTER
message is sent to PSBC2. The ISBG4-I (I-CSCF/S-CSCF co-located)
returns a 401 message.
2. The terminal sends another REGISTER message. The REGISTER

message is sent to PSBC1 at 23:06:58:413. The ISBG4-S returns a 400
(Bad Request) message.
The Call-ID parameters in the first and second REGISTER messages are
the same. The CSeq is 48 in the first REGISTER message and 49 in the
second REGISTER message. The Authorization header field in the second
REGISTER message does not carry the response parameter. As a result, the
CSCF cannot complete registration and returns a 400 message.
According to 3GPP 24.229, after the S-CSCF returns a 401 message to the
first REGISTER message, it needs to start a timer to wait for the second
REGISTER message with authentication information to complete
registration.
After the terminal sends the first REGISTER message, it starts the Treg
timer. By default, the timer duration is 64s. If the terminal does not receive
a response within 64s, it registers with another PSBC.
Condition  After a terminal sends a REGISTER message, the S-CSCF returns a 401
message. Within a specified time (32 seconds by default), the S-CSCF
receives the second REGISTER message from the terminal.
 The Call-ID parameters in two REGISTER messages are the same.
However, the CSeq parameter value in the second REGISTER message
is greater than that in the first REGISTER message.
 The Authorization header field does not carry the response parameter or
the response parameter value is null.
of
Occurrence

Copyright © Huawei
Involved Version
All CSC3300 versions
Solution
Workarounds
N/A
Preventive Measures
Install the CSC3300 V100R010C10SPH217 patch released in April to ensure that the
CSC3300 returns a 401 message to the second REGISTER message according to the latest
protocol requirements. (The solution requires cooperation from the terminal and PSBC.)
2.6.11 486 Message Is Returned to the Initial Registration of a

Non-iOS Terminal
Defect Details
Symptom A non-iOS terminal sends a REGISTER message to initiate a registration.

After receiving a 401 message from the S-CSCF, the terminal sends another
REGISTER message. However, the S-CSCF returns a 486 (Busy) message.
The Warning header field in the 486 message carries
3995123.2343.S.260.5.117.6.5.5642.0.0.xxx.com"Toomanyregisterinparall
el."
Trouble N/A
Ticket
Number
Root Cause The registration flow is as follows: 1. At 22:50:31:918, a REGISTER
message is sent to PSBC1. ISBG4-I sends the message to SBG3-S, and
ISBG3-S returns a 401 message.
2. The terminal sends another REGISTER message. At 22:50:49:669, the

message is sent to SBG4-I. SBG4-I forwards the message to ISGB3-S, and
ISBG3-S returns a 486 (Busy) message. (The SEQ tracing result is for
reference only. It is used to indicate that the interval between two
REGISTER messages is within 32 seconds.)

Copyright © Huawei
Call-ID in the first REGISTER message: 3893892875@IP1

Call-ID in the second REGISTER message: 1692536583@IP1
According to 3GPP 24.229, after the S-CSCF returns a 401 message to the
first REGISTER message, it needs to start a timer to wait for the second
REGISTER message with authentication information to complete
registration. As the Call-ID parameters contained in two REGISTER
messages are different, the S-CSCF does not complete the first REGISTER
message, and therefore returns a 486 (Busy) message to the second
REGISTER message.
Condition  After the terminal receives a 401 message from the S-CSCF, the terminal
sends another REGISTER message within 32 seconds.
 In the second REGISTER message, the Call-ID parameter changes.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
Install the CSC3300 patch released in April to ensure that the CSC3300 returns a 401 message
to the second REGISTER message according to the latest protocol requirements.
2.6.12 Registration of VoBB Terminals at a VoBB+VoLTE Site

Fails If the Minimum Registration Duration Is Modified
Defect Details
Symptom The minimum registration duration needs to be set to 3600s. However, at

convergent sites, after this parameter is modified, the VoBB terminal
cannot modify the expires parameter contained in the Expires or Contact

Copyright © Huawei
header field according to the received 423 message. As a result, registration

fails, and services are affected.
Trouble N/A
Ticket
Number
Root Cause After a VoBB terminal receives a 423 message, it does not set the expires
parameter in the Expires or Contact header field of the REGISTER
message to the value of the Min-Expires header field in the 423 message.
As a result, registration update fails, and the S-CSCF deregisters the
subscriber.
Description of the 423 message in RFC3261:
21.4.17 423 Interval Too Brief
The server is rejecting the request because the expiration time of the
resource refreshed by the request is too short. This response can be used by
a registrar to reject a registration whose Contact header field expiration
time was too small.
10.2.8 Error Responses
If a UA receives a 423 (Interval Too Brief) response, it MAY retry the
registration after making the expiration interval of all contact addresses in
the REGISTER request equal to or greater than the expiration interval
within the Min-Expires header field of the 423 (Interval Too Brief)
response.
Condition  The registration duration contained in the REGISTER message sent by
the VoBB terminal is less than the minimum registration duration set on
the CSCF.
 After the terminal receives a 423 message, the terminal does not change
the registration duration to the minimum registration duration specified
in the 423 message before sending a REGISTER message.
of
Occurrence
Involved Version
Solution
Workarounds
Roll back the configuration.
Preventive Measures
The VoBB terminal configuration needs to be modified. Alternatively, modify the minimum
registration duration of the VoBB terminal and then modify the minimum registration duration
of the VoLTE terminal.

Copyright © Huawei
2.6.13 Deregistered Subscriber Is in the Registered State on the

ATS
Defect Details
Symptom After CNL URCNL is executed on the CSCF to deregister a subscriber, a

third-party REGISTER message is sent to the ATS to deregister the
subscriber. However, the subscriber is still in the registered state on the
ATS.
Trouble N/A
Ticket
Number
Root Cause 1. The third-party REGISTER message does not carry contents in the first-
party REGISTER message. The ATS checks whether the Contact
address of the first-party REGISTER message in the third-party
REGISTER message is consistent with the saved subscriber data. The
ATS deregisters the subscriber only if they are consistent.
2. After SPH211, third-party REGISTER messages for deregistration on
the CSCF carry contents of the first-party REGISTER messages.
However, the third-party registration iFC data configured on the CSCF
shows that the third-party REGISTER messages are not configured to
carry contents in the first-party REGISTER messages. To enable third-
party REGISTER messages carry contents in first-party REGISTER
messages, configure data as follows:
<SPT><ConditionNegated>0</ConditionNegated><Group>5</Group>
<DeregTriggerType>1</DeregTriggerType></SPT>
Condition The registration iFC data configuration on the CSCF is incomplete. As a
result, third-party REGISTER messages do not carry contents in first-party
REGISTER messages.
of
Occurrence
Involved Version
CSC3300 V100R010C10SPC200
Solution
Workarounds
N/A
Preventive Measures

Copyright © Huawei
Load V100R010C10SPH211 or later on the CSCF and modify the third-party registration iFC
data. Add the following data to trigger points:
<SPT><ConditionNegated>0</ConditionNegated><Group>5</Group><DeregTriggerType>1
</DeregTriggerType></SPT>
2.6.14 Third-party Deregistration Fails

Defect Details
Symptom A terminal does not update the registration within a specified period of
time. After the registration times out, the terminal initiates a third-party
deregistration. However, the ATS returns a 403 message indicating that the
subscriber to be deregistered does not register.
Trouble N/A
Ticket
Number
Root Cause The CSCF determines whether subscribers' registrations time out using a
second timer. In each second, registrations of a certain number of
subscribers are checked. Therefore, registration timeout determination may
be delayed for 0 to 60s.
The ATS starts a timer for each registered subscriber. When the timer times
out, the ATS deregisters the subscriber immediately.
Therefore, after registration on the CSCF times out, and the CSCF sends a
third-party REGISTER message for deregistration to the ATS, the
subscriber status on the ATS is deregistered. As a result, the ATS returns a
403 message.
Condition The registration of a terminal times out as the terminal does not update the
registration.
of
Occurrence
Involved Version
CSC3300 V100R010C10SPC200
Solution
Workarounds
N/A
Preventive Measures

Copyright © Huawei
A CSC3300 patch will be released to solve the problem. When a terminal is deregistered due
to registration timeout, the CSCF will not send a REGISTER message for deregistration to the
ATS.
2.6.15 Registration on the 4G Network Is Successful But Calls Fell

Back to the 2G/3G Network When Huawei CSCF Cooperates with
Bell PSBC
Defect Details
Symptom A VoLTE subscriber in X province (where Huawei CSCF is deployed)

roams to B province (where Bell P-SBC is deployed). The registration is
successful. However, when the VoLTE subscriber makes calls, the calls fell
back to the 2G/3G network.
Trouble N/A
Ticket
Number
Root Cause During registration of the roaming VoLTE subscriber, the REGISTER
message sent by the Bell PSBC contains two Path header fields. One
contains the ATCF address (for SRVCC handover), and the other contains
the SBC address. In the 200 (to REGISTER) message sent by Huawei S-
CSCF, the Service-Route header field contains the S-CSCF address and the
ATCF address in the Path header field of the REGISTER message sent by
Bell PSBC. The registration is successful. However, when the subscriber
makes a call, the Bell SBC sends the INVITE message to the Bell ATCF
instead of Huawei S-CSCF. As a result, the call fails.
Condition Huawei CSCF interworks with Bell PSBC, and the Path header field in the
REGISTER message contains two hop addresses.
of
Occurrence
Involved Version
CSC3300 V100R010C10SPC200
Solution
Workarounds
Data configuration on Huawei S-CSCF needs to be adjusted to ensure that the S-CSCF does
not include the address contained in the Path header field of the REGISTER message from the
Bell SBC in the 200 (to REGISTER) message.

Copyright © Huawei
Error tolerance processing is added on the Bell SBC. When the Bell SBC receives a 200 (to
REGISTER) message in which the Service-Route header field contains a local address, the
Bell SBC ignores this address.
Preventive Measures
Set bit 16 of SCSCFPARA2 to 1.
MOD SFP: INSPN=SCSCFPARA2, MODTYPE=P1, BIT=16, BITVAL=1;
Bit 16
Determines whether the S-CSCF adds the Path header field value in a REGISTER message to the
Service-Route header field in a 200 (to REGISTER) message.
= 0: When multiple hop addresses are included in the Path header field of a REGISTER message and bit
7 of PCSCFPARA2 is 0, the S-CSCF adds both the top hop address in the Path header field value of the
REGISTER message and the S-CSCF host name to the Service-Route header field in a 200 (to
REGISTER) message.
= 1: The S-CSCF adds only the S-CSCF host name to the Service-Route header field in a 200 (to
REGISTER) message.
Default value: 0
2.6.16 VoLTE Subscriber Fails to be Called After Roams to the

Alcatel-Lucent PSBC as the P-Associated-URI Contained in the
200 (to REGISTER) Message Does Not Carry a tel URI
Defect Details
Symptom When a VoLTE subscriber roams to the Alcatel-Lucent PSBC, an error

message is displayed when the VoLTE subscriber is called.
Trouble N/A
Ticket
Number
Root Cause When the INVITE message is sent to the peer P-CSCF, the peer P-CSCF
returns a 404 message because the 200 (to REGISTER) message sent by
Huawei S-CSCF does not carry the tel URI. However, the INVITE
message carries the tel URI, and the Alcatel-Lucent PSBC regards that the
tel URI is illegal.
When some devices, for example, the terminal or P-CSCF do not support
carry the tel URI in the P-Associated-URI header field of INVITE
messages, registration data may fail to be saved. As a result, the terminal or
P-CSCF regards that the registration fails.
The following figure shows the bases for default tel URI settings.

Copyright © Huawei
Condition Huawei CSCF interworks with the Alcatel-Lucent PSBC.

of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
Set bit 0 of SCSCFPARA2 to 1.
Bit 0
Bit 0 is used for function control.
Determines whether the S-CSCF includes the tel URI in the P-Associated-URI header field of the 200
(to REGISTER) message.

Copyright © Huawei
= 0: The S-CSCF does not include the tel URI in the P-Associated-URI header field of the 200 (to
REGISTER) message. Instead, the S-CSCF converts the tel URI to a SIP URI carrying the user=phone
parameter and includes the SIP URI in the P-Associated-URI header field of the 200 (to REGISTER)
message.
= 1: The S-CSCF includes the tel URI in the P-Associated-URI header field of the 200 (to REGISTER)
message.
Default value: 0
2.6.17 Subscriber Cannot Make or Receive Calls After the

Registration Is Updated, Which Is Restored After the Subscriber
Initiates a Registration Again
Involved NE: CSC3300 and SBC
Defect Details
Symptom At 09:06, a subscriber sends a REGISTER message carrying the

authentication information. The S-CSCF returns a 200 message directly
(without authentication). The re-registration is successful, and the call is
normal.
At 09:52, the subscriber sends a REGISTER message again (with the
terminal IP unchanged) without authentication information. The SBC
forwards the REGISTER message to the S-CSCF. The S-CSCF does not
perform authentication, and returns a 200 message directly. When the
subscriber sends an INVITE message to make a call, the SBC returns a 403
message (invalid user) directly. When the subscriber is called and sends
183 message to the SBC, the SBC does not make any response.
At 09:57, the subscriber sends a REGISTER message without
authentication information using the same IP address to the S-CSCF. The
S-CSCF returns a 401 message. The subscriber sends another REGISTER
message, and the S-CSCF returns a 200 message. The registration is
complete, and subsequent MO and MT services are normal.
Trouble N/A
Ticket
Number
Root Cause According to the signaling tracing result, after the CSCF receives a
REGISTER message, it directly returns a 200 message regardless of
whether the REGISTER message carries authentication information. No
authentication times of re-register is set to a value other than 0
(maximum value is 5) by running MOD SREG on the CSCF. If integrity-
protected=yes is carried in the Authentication header field of REGISTER
messages for re-registrations and the number of re-registrations without
authentication is within the value of No authentication times of re-
register, the CSCF directly returns a 200 message without authentication.
The subscriber cannot make or receive calls after the registration is updated
because the SE2900 (P-SBC) incorrectly determine the port number
information.
When the UE sends a REGISTER message using plaintext, the PSBC

Copyright © Huawei
determines that the REGISTER message is used for re-registration as the

PSBC saves the previous registration information of the UE. In this case,
the PSBC includes integrity-protected=yes in the REGISTER message and
forwards the REGISTER message to the S-CSCF. As a result, the S-CSCF
directly returns a 200 message instead of a 401 message. The 200 message
forwarded by the PSBC to the UE does not carry the Security-Server
header field, and the UE determines that the IPSec negotiation with the P-
CSCF fails. In this case, when the UE sends an INVITE message using
plaintext to initiate a call, the UE uses the port number used for
registration, which is inconsistent with the port number saved on the PSBC.
As a result, the PSBC returns a 403 message.
Condition When a registered UE initiates a re-registration using plaintext, No
authentication times of re-register on the CSCF is not set to 0 and the
integrity-protected parameter in the first REGISTER message originating
from the registered UE is set to no on the SE2900.
of
Occurrence
Involved Version
All SE2900 versions
Solution
Workarounds
N/A
Preventive Measures
MOD PCSCF: PCSCFLEN="XXXXXX", PHEADERPL=INTPRO_NO-1;
PHEADERPL: This parameter specifies the P-CSCF header field processing policy.
INTPRO_NO(Setting integrity-protected to no): The P-CSCF embedded in the SBC sets the
integrity-protected parameter in the first REGISTER message originating from a registered
UE to no.
After modification, integrity-protected is set to yes for REGISTER messages for re-
registration using ciphertext and no for REGISTER messages for re-registration using
plaintext.
2.6.18 CSCF Returns 403 Messages When Different Subscribers

Use the Same Call-ID to Initiate Registrations
Defect Details
Symptom Call-ID of the GIONEE F100 terminal is asbcQWh19pSh1o3lGM7HwSY,

Copyright © Huawei
and IMSI is 46002057443****.

The GIONEE F100 terminal sends a REGISTER message to the CSCF
through PSBC01, and the CSCF returns a 401 message. When the VOVO
X6D terminal with the same Call-ID and tag as but different IMSI
(46002707773****) from that of the GIONEE F100 terminal sends a
REGISTER message to the CSCF through PSBC02, the CSCF returns a
403 message carrying "Conflictiveuser"."
Trouble N/A
Ticket
Number
Root Cause The CSCF uses the Call-ID parameter to associate REGISTER messages
before and after the 401 message. If the two REGISTER messages have the
same IMPU, the CSCF rejects the registration and returns a 403 message.
The CSCF processing mechanism is based on the RFC3261: In a new
request created by a UAC outside of any dialog, the Call-ID header field
MUST be selected by the UAC as a globally unique identifier over space
and time unless overridden by method-specific behavior. All SIP UAs must
have a means to guarantee that the Call-ID header fields they produce will
not be inadvertently generated by any other UA.
Condition Two subscribers use the same Call-ID to initiate registrations.
of
Occurrence
Involved Version
GIONEE F100 and VOVO X6D terminals
Solution
Workarounds
N/A
Preventive Measures
Call-ID of terminals must be unique.
2.6.19 CSCF Connects a Call After Receiving a 405 Message from

the AS
Defect Details
Symptom After the CSCF receives an INVITE message from a UE, the CSCF
contacts the AS based on the iFC data. The AS returns a 405 message, and
the CSCF forwards the INVITE message to the MGCF. However, the

Copyright © Huawei
CSCF is configured to connect calls after receiving a 500 message instead

of a 405 message from the AS.
Trouble N/A
Ticket
Number
Root Cause According to the SEQ tracing result, the S-CSCF does not transparently
forward the 405 message received from the SCP AS to the UE. Instead, it
continues to send the INVITE message to the MGCF.
The CSCF is not configured to continue a call when receiving a 405

message from the AS and will not continue the call according to the NE
implementation. When the problem is reproduced, we found that the 405
message returned by the SCP AS does not carry the Allow header field,
which does not comply with the RFC3261 protocol. As a result, the CSCF
converts the 405 message to a 500 message and continues the call.
21.4.6 405 Method Not Allowed

The response MUST include an Allow header field containing a list of
valid methods for the indicated address.
Condition The 405 message does not carry the Allow header field.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures

Copyright © Huawei
It is recommended that configuration on the AS be modified to ensure that the Allow header
field is included in 405 messages.
2.6.20 CSCF Sends a BYE Message Immediately After the Called

Party Answers the Call
Defect Details
Symptom The CSCF sends a BYE message immediately after the called party
answers the call for a subscribed-to service. The BYE message carries
Reason:SIP;text="SessionTimerCheckMessageFailedforINVITE2xx."
Trouble N/A
Ticket
Number
Root Cause 1. According the BYE message information, the refresher parameter in the
Session-Expires header field of the 200 (to INVITE) message is uac, but
the Require header field in the 200 (to INVITE) message does not carry
the timer parameter.
2. Check of protocol compliance defined by running MOD STMR is

used to check whether session timer related parameters are checked
according to the RFC4028 protocol.
3. The CSCF sends the BYE message because the 200 message sent by the
AS does not carry Require:timer.
The following describes scenarios for checking whether session timer
related parameters are processed according to the RFC4028 protocol.
RFC4028
For session timer related parameter negotiation, refresher is uac and the

Copyright © Huawei
timer parameter is carried in the Supported and Require header fields of

2XX messages.
9.UAS Behavior
If the refresher parameter in the Session-Expires header field in the 2xx
response has a value of 'uac', the UAS MUST place a Require header field
into the response with the value 'timer'. This is because the uac is
performing refreshes and the response has to be processed for the UAC to
know this.
 During session timer related parameter negotiation, the Session-Expires
value in 2XX messages must be less than the value of Min-SE in
requests. If Min-SE is not included in requests, the Session-Expires
value must be greater than or equal to 90.
 During session timer related parameter negotiation, the value of Session-
Expires in the INVITE message must be less than that in the 200
message.
If the UAS wishes to accept the request, it copies the value of the Session-
Expires header field from the request into the 2xx response. The UAS
response MAY reduce its value but MUST NOT set it to a duration lower
than the value in the Min-SE header field in the request, if it is present;
otherwise the UAS MAY reduce its value but MUST NOT set it to a
duration lower than 90 seconds. The UAS MUST NOT increase the value
of the Session-Expires header field.
 During session timer related parameter negotiation, if the Session-
Expires header field in the 2XX message does not carry the refresher
parameter, and the Supported header field does not carry the timer
parameter, the CSCF sends a BYE message to release the call. If the
timer parameter is included in the Supported header field, RFC4028 is
supported. Therefore, the refresher parameter carried in 2XX messages
must meet the following requirements:
The UAS MUST set the value of the refresher parameter in the Session-
Expires header field in the 2xx response.
 During session timer related parameter negotiation, if the refresher

parameter is not included in the Session-Expires header field of the
2XX message, the CSCF sends a BYE message to release the call in any
of the following scenarios:
 The refresher parameter is included in the Session-Expires header field of
the request.
 The values of the Session-Expires header fields in the request and
response are different.
 During session timer related parameter negotiation, if the refresher
parameter in the request is uas, and it is changed to uac in the response,
the call is not released. Otherwise, the call is released.

Copyright © Huawei
 The CSCF returns a 400 message if the request meets any of the
following conditions:
− The refresher parameter is included in the Session-Expires header
field and the timer parameter is included in the Supported header
field.
− The Session-Expires value is less than 90s.
− The Session-Expires value is less than the Min-SE value.
Condition  Check of protocol compliance is set to Yes on the CSCF.
 The value of Session-Expires in the INVITE message is less than the
value of Session-Expires in the 200 message.
 The refresher parameter in the Session-Expires header field of the
INVITE message is uac. However, the 200 (to INVITE) message does
not carry the Require header field, or the Require header field does not
carry the timer parameter.
Probability This issue occurs if the preceding conditions are met.
of
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
Modify data configuration on NEs that do not comply with protocols.
2.6.21 Originating S-CSCF Returns a 500 Message for a Call

Between Two IMS Subscribers After Querying the ENUM Server
Defect Details
Symptom IMS subscriber A calls IMS subscriber B. After the originating S-CSCF
queries the ENUM server, it returns a 500 message. The Warning header
field in the 500 message carries 399
37963.2172.S.261.5.105.0.27.544839.0.0.xx.xxx.com "Number Analysis
Failed."
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause The printed information shows that the S-CSCF processes the ENUM
return result incorrectly.
The following printed information shows the current configuration:
<NaConvertEnumQuryResult>] NaConvertEnumQuryResult: Call
SAdaptEnumHandleNaptrURI failed!ulRet=[9], MatchPlus=[1],
MatchFailPly=[1]
The ulRet value is not 0, which indicates that matching or replacement
fails.
The MatchPlus value is 1, which indicates that the value of bit 1 of
SCSCFPARA8 is 1.
The MatchFailPly value is 1, which indicates that the value of bit 6 of
SCSCFPARA8 is 1.
The matching expression returned by the ENUM server carries the plus
sign (+). In regular expressions, the plus sign (+) means to match the
preceding subexpression one or more times. To match the plus sign (+)
itself, add an escape character (\) before the plus sign (+).
The following figure shows the correct configuration.

For example, if the ENUM server is embedded in the CSCF, the query
result is as follows:
Condition The regular expression configuration on the ENUM server is incorrect.

of

Copyright © Huawei
Occurrence
Involved Version
Solution
Workarounds
N/A
Preventive Measures
Modify configuration on the ENUM server to ensure that the regular expression returned by
the ENUM server has the escape character (\) added before the plus sign (+).
Bit 1 of SCSCFPARA8
Determines whether the S-CSCF prefixes the E.164 number (converted from the subscriber number)
with the plus (+) sign to match the regular expression after querying the ENUM server is successful.
Value:
= 0: The S-CSCF does not prefix the E.164 number (converted from the subscriber number) with the
plus (+) sign to match the regular expression.
= 1: The S-CSCF prefixes the E.164 number (converted from the subscriber number) with the plus (+)
sign to match the regular expression.
Default value: 0
In other words, bit 1 determines whether the S-CSCF adds a plus sign (+) before the subscriber number
used to match the regular expression returned by the ENUM server. For example, the subscriber number
is 8675510000016, and the regular expression returned by the ENUM server is \+86755(.*).
If 8675510000016 is used to match \+86755(.*), the matching fails. If +8675510000016 is used to match
\+86755(.*), the matching is successful.
Bit 6 of SCSCFPARA8
Determines whether the CSCF continues to route the call or rejects the call when it fails to match the
called number with the regular expression obtained by querying the ENUM/NP server based on the
called number.
Value:
= 0: The CSCF continues to route the call when the replacement expression returned by the ENUM/NP
server is a specific number. If the replacement expression returned by the ENUM/NP server is not a
specific number, the CSCF rejects the call.
= 1: The CSCF rejects the call.
Default value: 1
2.6.22 Teleconference Fails After a VoLTE Video Call Falls Back

to a Voice Call

Copyright © Huawei
Defect Details
Symptom VoLTE subscriber A initiates a voice call to subscriber B, and B answers

the call.
A switches the voice call to a video call, and B answers the call.
A switches the video call back to a voice call, and B answers the call.
A invites C to the call, and B hears an announcement stating that "The
subscriber you dial is using the call hold function. Please wait."
After C answers the call, A presses the a key to merge calls. However, B
hangs up, and the call between A and C is normal.
NOTE
The preceding problem recurs when the three test terminals serve as the calling and
called parties in polling mode. If only the VoLTE voice service is used during the
third-party call, the preceding problem does not occur.
Trouble N/A
Ticket
Number
Root Cause According to tracing result of messages sent by the VoLTE AS and MRFC,
when A sends a call merging request, the MRFC sends a 488 message to
release the call.
The Warning header field carries 399
0448202576.MRFC.xx.xxx.com.250.007.102.0000002D.00000000 "Get
SDP fail."
The INVITE message sent to the MRFC carries the transport attribute
RTP/AVPF. In versions earlier than V100R010C10SPH205, the MRFC
does not support the transport attribute. In V100R010C10SPH205 or later,
bit 12 of MRCPARA8 is added to control whether the MRFC supports the
transport attribute.
Condition The AVPF is carried in the SDP body of the INVITE message.
of
Occurrence
Involved Version
Solution

Copyright © Huawei
Workarounds
N/A
Preventive Measures
For CSC3300 V100R010C10SPH205 or later versions, set bit 12 of MRCPARA8 to 1.
MOD SFP: INSPN=MRCPARA8, MODTYPE=P1, BIT=12, BITVAL=1;
Bit 12 of MRCPARA8
Determines whether the MRFC changes RTP/AVPF included in the SDP body of INVITE messages to
RTP/SAVP.
Value:
= 0: The MRFC does not change RTP/AVPF included in the SDP body of INVITE messages to
RTP/SAVP.
= 1: The MRFC changes RTP/AVPF included in the SDP body of INVITE messages to RTP/SAVP.
Default value: 0
2.7 Fault Cases for April 2016

2.7.1 Called UE Returns a 488 Message
Involved NE: SBC
Troubleshooting Engineer: Chen Xingwu (ID: 00145812)
Defect Details
Symptom The SBC receives hundreds of 488 messages for mobile terminated (MT)
calls every day. These failed calls are from VoBB subscribers to VoLTE
subscribers. Traced messages show that a VoLTE UE returns a 488 message
after receiving an INVITE message from the SBC.
Trouble N/A
Ticket
Number
Root Cause In the SDP body of the INVITE message sent from the SBC to the VoLTE
UE, G.711 and telephone-event codecs are carried but AMR and AMR WB
are not.
An example SDP body is as follows:

Copyright © Huawei
The SBC is configured to include the locally supported codecs in the SDP
body.
Further analysis shows that only a small proportion of calls from VoBB
subscribers to VoLTE subscriber fail.
In these failed calls, the SDP body in the INVITE messages sent from the
VoBB UEs carry "a=silencesupp: off - - - -", which is not carried in
successful calls from VoBB subscribers to VoLTE subscribers.
The INVITE messages sent from the S-CSCF to the SBC also carry
"a=silencesupp: off - - - -". As a result, the SBC processes the calls as faxes
and does not include AMR or AMR WB in the INVITE messages sent to
the VoLTE UEs. VoLTE UEs from Apple cannot use G.711 to establish
calls and return 488 messages.
Condition A VoBB subscriber calls a VoLTE subscriber, and the SDP body in the
INVITE message sent from the VoBB UE carries "a=silencesupp: off - - -
-".
of
Occurrence
Involved Versions
SE2900 V300R001C20SPC100
Solution
Workarounds:
N/A
Run MOD TCCAP on the SBC to enable the SBC not to process calls that carry
"a=silencesupp" as faxes.

Copyright © Huawei
2.7.2 RTA Message Does Not Carry the Origin-Host and Origin-
Realm AVP
Involved NEs: CSCF and HSS
Applicable Scope: global (sites that interwork with the NSN HSS)
Troubleshooting Engineer: Yang Erjie (ID: 00191244)
Defect Details
Symptom The NSN HSS sends an RTR message to deregister a UE, and the S-CSCF
responds with an RTA message that does not carry the Origin-Host and
Origin-Realm AVP. The NSN HSS determines that the RTA message does
not comply with 3GPP TS 29.229 and rejects it.
Trouble N/A
Ticket
Number
Root Cause The structure of the RTA message is defined as follows in 3GPP TS 29.229:
The Origin-Host and Origin-Realm AVPs are mandatory in the RTA

message.

Copyright © Huawei
Condition  The Huawei CSCF interworks with the NSN HSS.

 The CSCF version is earlier than CSC3300 V100R011C10SPH103.
of
Occurrence
Involved Versions
CSC3300 V100R11C10SPC100
Solution
Workarounds:
N/A
CSC3300 V100R011C10SPH103 has been developed to resolve this issue.
2.7.3 VoLTE Subscriber Fails to Send a Short Message After a

LTE-to-3G Handover
Involved NEs: ATS and HSS
Applicable Scope: America (sites that use the ANSI protocol)
Defect Details

Copyright © Huawei
Symptom After a handover from an LTE network to a 3G network, a VoLTE

subscriber does not send a deregistration message to the IMS network.
Consequently, the subscriber fails to send short messages.
Trouble 5801773
Ticket
Number
Root Cause The detailed flow is as follows:
1. The IP-SM-GW fails to send a short message over the IMS network.
2. The IP-SM-GW sends an SRI message to the HLR to request the MSC
server information, but the HLR sends the message back to the IP-SM-
GW. The SRI message sent from the HSS is incorrect.
Specifically, the IP-SM-GW fills the MSC server's global title (GT)
code padded with a zero in the Called address field, because the original
MSC server's GT code contains 11 digits. The HLR detects that the
received GT code is different from any stored one and therefore does
not forward the message to the required MSC server. Instead, the HLR
sends the message back to the IP-SM-GW. An example GT code padded
with a zero is as follows:
ADD
SCCPGT:GTNM="LOCAL_00",NI=NAT,GTI=GT6,TRANSLATETY
PE="00",ADDR=K'197XXXX9441,RESULTT=LSPC2,SPC="H'023D
6E";
The following figure shows the enhanced short message routing flow
(routing preferentially to the IMS domain):

Copyright © Huawei
The root cause is as follows: ANSI used at America sites does not
specify the odd/even flag in SRI messages. As a result, the HLR cannot
process the SRI messages correctly.
Condition The ANSI protocol is used for GT translation.
of
Occurrence
Involved Versions
ATS9900 V100R08C10SPC100
Solution
Workarounds:
N/A
An HSS9860 patch will be released to enable the HLR to determine whether to perform
maximum prefix matching.
2.7.4 No-reply Timer in the Default Call Forwarding upon No

Reply Service Uses an Incorrect Value
Involved NE: ATS

Copyright © Huawei

Defect Details
Symptom A VoLTE subscriber has subscribed to the default call forwarding upon on
reply service. The duration of the no-reply timer applied for the subscriber
is different from the value of default no reply timer configured on the
ATS.
Trouble 5978726
Ticket
Number
Root Cause Three parameters in ADD MSR or MOD MSR are related to the CFNR
timer:
Parameter 1: no reply timer under subscriber communication diversion
Parameter 2: CFD no reply timer under actions of rule set
Parameter 3: default no reply timer under operator communication

diversion
When parameter 2 is not specified, the ATS preferentially selects the value
of parameter 1. However, the ATS should preferentially select the value of
parameter 3 if parameter 2 is not specified for the default call forwarding
upon on reply service.

Copyright © Huawei
In the preceding subscriber data:

"NotReplyTime = 5" maps to parameter 1.
"NotReplyTime = 30" maps to parameter 3.
Condition The ATS version is earlier than ATS9900 V100R008C10SPH115.
of
Occurrence
Involved Versions

Copyright © Huawei
ATS9900 V100R008C10SPC100
Solution
Workarounds:
N/A
ATS9900 V100R008C10SPH115 has been developed to resolve this issue.
2.7.5 SCU Module Restarts When More Than Two Extended

Header Fields Are Removed
Involved NE: CSCF
Defect Details
Symptom SIP signaling filtering data is configured on the CSCF to enable the CSCF
to remove multiple extended header fields. When the CSCF removes more
than two extended header fields, the SCU module restarts.
Trouble 5968959
Ticket
Number
Root Cause When the CSCF removes the first extended header field, the extended
header field pointer configured by the CSCF is null. When the CSCF
processes the second extended header field, an exception occurs during the
memory access. Consequently, the SCU module restarts.
Condition The CSCF is configured to remove multiple extended header fields.
of
Occurrence
Involved Versions
CSC3300 V100R11C10SPC100
Solution
Workarounds:
Delete the SIP signaling filtering data on the CSCF.
A CSC3300 patch will be released in May 2016.

Copyright © Huawei
2.7.6 SCC AS Sends a 480 Message Carrying "No appropriate

session for SRVCC/eSRVCC" for a bSRVCC Handover
Involved NE: ATS
Troubleshooting Engineer: Huang Jianguo (ID: 00135928)
Defect Details
Symptom A calls B. Before B is alerted, A's UE initiates a handover. The call fails to
be connected.
Trouble N/A
Ticket
Number
Root Cause The traced messages on the SEQ show that:
1. Media negotiation is complete using 183, PRACK, and 200 messages.
The SCC AS receives an UPDATE message from the calling UE and
forwards it to the called UE. Before receiving a 200 (to UPDATE)
message from the called UE, the SCC AS receives an INVITE message
from the SBC for a handover.
2. The SCC AS responds with a 480 message carrying "No appropriate
session for SRVCC/eSRVCC" to the handover request.
3. The SCC AS also sends a CANCEL message to the called UE and a
480 message carrying "No appropriate session for SRVCC/eSRVCC" to
the calling UE.
The root cause is as follows: The SCC AS always sends a 480 message to
reject a handover request if the session and media are unstable. In this
failed call, the transaction associated with the UPDATE message (mostly
the precondition flow) is not complete. Therefore, the handover is a type of
bSRVCC handover, which is supported only by ATS9900 V100R008C20
and later versions.
A Warning header field is as follows:
Warning: 399
2283028.239.ATS.sccas01b.sccas.xxxxx.ims.mnc000.mcc460.3gppnetwor
k.org.13.608 "No appropriate session for SRVCC/eSRVCC"
Condition A bSRVCC handover occurs.
of
Occurrence
Involved Versions

Copyright © Huawei
ATS9900 V100R006C10SPC100
Solution
Workarounds:
N/A
Upgrade the ATS9900 to V100R008C20 to support bSRVCC handovers.
2.7.7 SCC AS Sends a 480 Message Carrying "Do not match switch
condition" for a bSRVCC Handover
Involved NE: ATS
Defect Details
Symptom A calls B. At the moment when B is alerted, A's UE initiates a handover.

The call fails to be connected.
Trouble N/A
Ticket
Number
Root Cause The traced messages on the SEQ show that:
1. The SCC AS receives a 180 message carrying the Require header field
with the value set to 100rel. Before receiving a PRACK message from
the calling UE, the SCC AS receives an INVITE message from the SBC
for a handover.
2. The SCC AS responds with a 480 message carrying "Do not match
switch condition" to the handover request.
3. The SCC AS also sends a CANCEL message to the called UE and a 480
message carrying "Do not match switch condition" to the calling UE.
The root cause is as follows: The SCC AS always sends a 480 message to
reject a handover request if the session and media are unstable. In this
failed call, the transaction associated with the 180 message (mostly the
precondition flow) is not complete. Therefore, the handover is a type of
bSRVCC handover, which is supported only by ATS9900 V100R008C20
and later versions.
A Warning header field is as follows:
Warning: 399

Copyright © Huawei
2283028.815.ATS.hzsccas01bhw.sccas.zj.ims.mnc000.mcc460.3gppnetwor
k.org.13.619 "Do not match switch condition"
Reason: Q.850;cause=66;text="channel type not implemented"
Condition A bSRVCC handover occurs.
of
Occurrence
Involved Versions
ATS9900 V100R006C10SPC100
Solution
Workarounds:
N/A
Upgrade the ATS9900 to V100R008C20 to support bSRVCC handovers.
2.7.8 ESN Cannot Be Obtained When More Than Four IP

Addresses Are Configured for the ATS
Involved NE: ATS
Troubleshooting Engineer: Wu Junlin (ID: 00365955)
Defect Details
Symptom A capacity expansion is performed on a VoLTE or IMS network. After the

capacity expansion, more than four IP addresses are configured for the
ATS. The ESN cannot be obtained, and a license cannot be applied for the
ATS.
Trouble N/A
Ticket
Number
Root Cause The GetEsn tool of V3.1 generates an ESN for the ATS configured with
four or less IP addresses. If more than four IP addresses are configured, the
tool cannot generate an ESN.
Condition More than four IP addresses are configured for the ATS after capacity
expansion.
of
Occurrence

Copyright © Huawei
Involved Versions
All ATS9900 versions
Solution
Workarounds:
1. Use the GetEsn tool of V2.8.
2. Specify the parameters as follows:
a. Sequence the IP addresses based on the IFM module number from the smallest to
the largest.
b. If multiple IP addresses are configured for the same IFM module number, sequence
the IP addresses based on their values. For example, if 10.85.133.130 and
10.85.133.131 are configured for the same IFM module number, sequence
10.85.133.130 before 10.85.133.131.
c. Fill the IP addresses in IPv4 format in the input area of the GetEsn tool to obtain an
ESN.
Contact Huawei technical support engineers to optimize the GetEsn tool.
2.7.9 Call Is Released Because the MSC Server Fails to Receive a

PRACK Message Before the Timer Expires
Involved NE: MSC server and Samsung UE
Defect Details
Symptom A VoLTE UE from Samsung calls a CS subscriber. The call is abnormally

released after being connected. A large number of records SIPAPP module
times out.timer_name =SIP_CALL_TMR_WAIT_PRACK_IN,
timer_length =32000 are displayed in CHRs generated by the MSC server.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause
The call flow is as follows:

1. A calls B, and an INVITE message is sent to the terminating MSC
server. The terminating MSC server returns a 183 message, and the
calling UE sends a PRACK message.
2. Before sending a 200 (to PRACK) message, the terminating MSC
server receives an ACM message from the called UE, converts the ACM
message to a 180 message, and sends the 180 message to the calling
UE.
3. The calling UE receives the 180 message but does not send a PRACK
message to indicate that it has received the 180 message. Even after
receiving a retransmitted 180 message, the calling UE does not respond
with a PRACK message. As a result, an internal timer of the MSC
server expires, causing the call to be released.
Condition 1. A VoLTE UE from Samsung is used, and the User-Agent header field
with the value Samsung IMS 5.0 is carried in messages sent by the UE.
2. The UE receives a 180 message prior to a 200 (to PRACK) message.
of
Occurrence
Involved Versions
All MSOFTX3000 versions

Copyright © Huawei
Solution
The UE is defective and should be improved.
Workarounds:
N/A
Ask the UE vendor to rectify the fault.
2.7.10 Encrypted SIP Signaling Hinders Fault Location

Involved NE: UGW
Troubleshooting Engineer: Zhang Hao (ID: 00338320)
Defect Details
Symptom The UGW is always required to locate VoLTE faults. However, packets
captured on the UGW contain a large amount of encrypted data, which
hinders fault location.
For example, if you filter SIP packets directly without performing a
decryption, only 401 and REGISTER messages can be obtained. Data after
the authentication is encrypted using ESP and cannot be parsed. Example
messages are as follows:
Trouble N/A
Ticket
Number
Root Cause In a VoLTE call, signaling plane data is protected by using IPsec to perform
integrity protection and encryption. As defined in GSMA IR.92, if IMS
AKA authentication is used between UEs and IMS networks, integrity
protection is mandatory but encryption is optional. However, encryption is
enabled for most commercial sites.
Condition The encryption function is enabled.
of
Occurrence

Copyright © Huawei
Involved Versions
All UGW9811 versions
Solution
Workarounds:
N/A
Configure the Wireshark to decrypt packets that are encrypted using IPsec.
Configure the Wireshark as follows:
Obtain the parameter values as follows:

1. Obtain msip from messages traced on the UGW.

Copyright © Huawei
2. Obtain ealg and alg from the 401 message sent by the P-CSCF.
3. Obtain the CK and IK parameters from the 401 message sent from the S-CSCF to the P-
CSCF.

Copyright © Huawei
After the configuration, the Wireshark can be used to decrypt SIP packets.
2.8 Fault Cases for March 2016

2.8.1 Inconsistent AMR Parameters Cause One-Way Audio
Involved NE: SBC
Defect Details
Symptom When the call from a VoLTE subscriber to another VoLTE subscriber
roaming in the 3G network is connected, the calling party cannot hear the
called party, causing one-way audio.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause
1. The blue arrows indicate the signaling messages when this issue occurs.
When the MGCF sends an INVITE message to the MSC server, the
INVITE message carries AMT pt=118 for the calling party. However,
the peer end returns AMR pt=108.
2. When the MGCF instructs the UMG to use pt=108 but the media
streams sent by the called party use pt=118, the UMG discards the
streams, causing one-way audio.
3. As stipulated in RFC 3264, the PT value in the Offer indicates the PT
value supported by the local end, and when the peer end uses the PT
value in the Offer to sent RTP streams, the local end should support this
action.
For recvonly RTP streams, the payload type numbers indicate the value of
the payload type field in RTP packets the offerer is expecting to receive for
that codec. For sendonly RTP streams, the payload type numbers indicate
the value of the payload type field in RTP packets the offerer is planning to
send for that codec. For sendrecv RTP streams, the payload type numbers
indicate the value of the payload type field the offerer expects to receive,
and would prefer to send. However, for sendonly and sendrecv streams,
the answer might indicate different payload type numbers for the same
codecs, in which case, the offerer MUST send with the payload type
numbers from the answer.
Condition 1. The call traverses the MGCF, and the PT value in the AMR used by the
receiving direction is different from that in the AMR used by the
sending direction.
2. The peer end uses the PT value in the Offer, instead of the PT value in
the Answer, to send media packets.
of
Occurrence
Involved Versions
MGCF V200R010C020SPC100 and MGCF V200R010C030SPC100
Solution
Workarounds:
Solution 1:

Copyright © Huawei
Run MOD SIPTG on the MGCF (MSC server) with Peer does not allow a change in the
PT value selected for Extra software parameter 3 of service control. After this selection,
the MSC server negotiates about the same PT value with the peer end.
MOD SIPTG: TGN="xxx", ESFPARA3=SRV30-1;
This software parameter determines whether the peer end allows a change in the PT value. If
this value option is selected, the peer end cannot change the PT value. In this case, the codec's
PT value in an SDP response returned by the MSOFTX3000 must be the same as the PT value
in an SDP request received from the peer end. In addition, if the MSOFTX3000 needs to send
an SDP renegotiation request to the peer end, the codec's PT value in the request must be the
same as that received from the peer end during the previous negotiation. After receiving
media information from the peer end, the MSOFTX3000 does not send a renegotiation
request to the peer end, if the MSOFTX3000 has completed the media negotiation with the
peer end and the negotiation result does not change.
Solution 2:
Run MOD SIPTG on the MGCF (MSC server) with Peer uses different PT values in the
receiving and sending channels selected for Extra software parameter 3 of service
control. After this selection, the re-INVITE/200 message exchange is added to the service
flow, as indicated by the red arrows.
MOD SIPTG: TGN="xxx", ESFPARA3=SRV31-1;
This software parameter determines whether the peer end can use different PT values when
receiving and sending bearer information. If this value option is selected, the peer end can use
different PT values when receiving and sending bearer information. In this case, the preferred
codec's PT value in an SDP response returned by the MSOFTX3000 must be the same as the
PT value in an SDP request received from the peer end. If the MSOFTX3000 detects that the
preferred codec's PT value in the SDP response received from the peer is different from that in
the SDP message sent to the peer end, it must send a renegotiation request carrying the
received PT value to the peer end. If this value option is not selected, the peer end must use
the same PT value when receiving and sending bearer information.
Prefer solution 1.
2.8.2 Inconsistent AMR Codec Attributes Cause One-Way Audio

Involved NE: SBC
Defect Details
Symptom When the call from a VoLTE subscriber to another VoLTE subscriber
roaming in the 3G network is connected, the calling party cannot hear the
called party, causing one-way audio.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause
1. As shown in the preceding figure, the INVITE message sent by VoLTE

subscriber A carries 108 AMR and octet-align =1, but the 200 message
returned by the peer end carries 108 AMR and mode-set =1.
2. When the SBC detects the difference, it discards RTP packets, causing
one-way audio.
Condition 1. The call traverses the SBC, the AMR codec is used in the Offer and
Answer, but the AMR codec attribute in the Answer is different from
those in the Offer (one is octet-align =1 and the other is mode-set =1).
2. The peer end uses the AMR codec attribute in the Answer to send RTP
packets.
of
Occurrence
Involved Version
SBC V100R002C00SPC200
Solution
Workarounds:
On the SBC, enable payload type switch.
MOD BCPLC: BCPLCNAME="DEFAULTABCFBCPLC", PTTRANS=Y;
On the SBC, enable payload type switch.
MOD BCPLC: BCPLCNAME="DEFAULTABCFBCPLC", PTTRANS=Y;
2.8.3 AGCF ua-profile Subscription Fails

Involved NEs: AGCF and ATS
Defect Details

Copyright © Huawei
Symptom AGCF ua-profile subscription fails in ATS VCU scenarios.

Trouble N/A
Ticket
Number
Root Cause 1. The user message tracing result shows that the Route header field in the
SUBSCRIBE message received by the ATS from the S-CSCF contains
two values. The first value is the ATS host name, and the second value
is the S-CSCF address. This is because the S-CSCF needs to contact the
ATS through the iFC and add the S-CSCF address when it receives a
SUBSCRIBE message from the AGCF. When the ATS processes the
SUBSCRIBE message, it sends the SUBSCRIBE message to the S-
CSCF (as indicated in the following figure) based on the second Route
header field value. However, the correct behavior is that the ATS does
not forward the SUBSCRIBE message to the S-CSCF after receiving a
ua-profile subscription.
Currently, the VCU does not support explicit ua-profile subscription.

Therefore, change the ua-profile subscription mode to implicit on the
AGCF for the subscriber and change data on the ATS to enable the
subscriber to support implicit ua-profile subscription. After these
changes, this issue is resolved.
Condition  The AGCF sends an explicit ua-profile subscription message.
 The ATS uses the VCU to process services.
of
Occurrence
Involved Version
ATS9900 V100R06C10SPC100
Solution
Workarounds:
N/A

Copyright © Huawei
Change the ua-profile subscription mode to implicit on the AGCF for the subscriber and
change data on the ATS to enable the subscriber to support implicit ua-profile subscription.
2.8.4 CSCF Incorrectly Uses Secure IP Addresses to Forward BYE

Messages from Called Parties to Calling Parties
Involved NE: CSCF
Defect Details
Symptom The CSCF incorrectly uses secure IP addresses to forward BYE messages
from called parties to calling parties.
Trouble N/A
Ticket
Number
Root Cause 1. The details are as follows:
Three IP addresses, 66, 192, and 194 have been configured on the S-
CSCF. 192 and 194 are secure IP addresses (ANIT configuration) used
to interwork only with Diameter devices.
However, at the P2 phase, the S-CSCF selects the IP address 194 to
send a BYE message from the called party to the I-SBC.

Copyright © Huawei
The reason is as follows:

At the P1 phase, the I-CSCF sends an INVITE message to the IP
address 194 of the S-CSCF. The S-CSCF records the IP address. At the
P2 phase, the S-CSCF preferentially selects the recorded IP address
194. However, as the IP address 194 is used for interworking only with
Diameter devices, it cannot be used to send the BYE message to the I-
SBC.
Condition Secure IP addresses have been configured on the S-CSCF, and these IP
addresses support SIP over UDP.
of
Occurrence
Involved Version
CSCF3300 V100R011C10SPC100

Copyright © Huawei
Solution
Workarounds:
N/A
The customer allows use of only the IP address 194 to interwork with Diameter devices.
Therefore, disable SIP over UDP for this IP address so that this IP address is not selected to
send SIP messages.
2.8.5 After Subscriber Migration, Alarms Indicating That Remote

Addresses Are Unreachable Are Generated
Involved NEs: CSCF and HSS
Defect Details
Symptom After subscriber migration, alarms indicating that remote addresses are
unreachable are generated.
Trouble N/A
Ticket
Number
Step 1: Subscriber A has registered at site 1.
Step 2: Subscriber A at site 1 is migrated to site 2.
Step 3: Site 1 does not work any more, for example, because of
hardware removal.
After several days (subscriber A's registration at site 1 has expired),
when B calls A, an alarm is generated, indicating that the route from the
S-CSCF at site 2 to the P-CSCF at site 1 is unreachable.
Site 1 does not work (each device at site 1 do not work). Although
subscriber A's registration at site 1 has expired, the S-CSCF at site 1
cannot send an SAR message to deregister subscriber A from the HSS.
This causes the HSS to retain subscriber A's registration information,
such as the Path header field value (P-CSCF host name at site 1).
When a call is addressed to subscriber A, the MT redundancy flow is
triggered. That is, subscriber A's data (including the P-CSCF host name
at site 1) is downloaded from the HSS. This causes the S-CSCF at site 2
to send an INVITE message to the P-CSCF at site 1. Obviously, the S-
CSCF at site 2 cannot receive any response and therefore enables
heuristic OPTIONS detection. After this detection fails several times,
the S-CSCF at site 2 generates an alarm indicating that the remote
address is unreachable and adds the P-CSCF address at site 1 to the
OPTIONS detection blacklist.
Condition  Subscribers at site 1 have been migrated but have not initiated a

Copyright © Huawei
registration to site 2.
 The S-CSCF at site 1 does not work. That is, when a subscriber's
registration expires, the S-CSCF cannot send an SAR message to
deregister the subscriber from the HSS.
of
Occurrence
Involved Version
CSCF3300 V100R010C10SPC100
Solution
Workarounds:
N/A
1. After the subscriber initiates a registration, this issue is resolved.
2. If such subscribers cannot be identified on the live network (generally, there is no
method for the identification), add the non-working P-CSCF address to the OPTIONS
whitelist to screen this alarm.
2.8.6 404 Message May Occur in VoLTE Call Tests

Involved NE: ATS
Defect Details
Symptom When the customer uses a test tool to perform a call test, a 404 message
may occur, causing a call failure.
Trouble N/A
Ticket
Number
Root Cause The details are as follows:
The customer uses a test tool to perform a call test (an enormous number of
calls are simulated using this tool). A 404 message may occur.
The message tracing result shows that the 404 message is caused by the
fact that the ATS fails to query subscriber data (including the call source).
Further analysis of the traced messages shows that the ATS involves
deleting subscriber data for a call for which the 404 message is returned.
This is because that the subscriber is an unregistered subscriber. When the
ATS receives an INVITE message and finds that it has not stored data of
the subscriber, it downloads the data from the HSS and stores it for a
specified time. The ATS has two timers (timers A and B) configured to

Copyright © Huawei
control the duration for which data of unregistered subscribers is stored.

The value of timer A is 90s, which cannot be modified. After the ATS
downloads subscriber data, the call ends within 90s. The ATS triggers only
timer A (90s). After 90s the ATS deletes subscriber data. When timer A
expires, if the subscriber is still busy on a call (regardless of whether the
call is the original or new one), the ATS starts timer B whose value is set to
32s by default. Therefore, if there is no call, the ATS deletes subscriber data
regardless of whether timer A or B expires. If the ATS receives a new call
during subscriber data deletion, it deletes and queries subscriber data
simultaneously. When the ATS detects that subscriber data has been deleted
while processing the INVITE message, it returns a 404 message for the call
due to the data query failure.
Condition  Subscribers have not registered services.
 During call setup, ATS deletes subscriber data due to the expiration of
timer A or B.
of
Occurrence
Involved Version
ATS9900 V100R08C10SPC100
Solution
Workarounds:
ATS9900 engineers are planning to develop a patch to eliminate the root cause of this issue.
The current workaround is to increase the duration of timer B to reduce the occurrence
probability of this issue.
Wait for ATS engineers to develop a patch.
2.8.7 SPG Fails to Return limitation-of-parallel-calls to the BSS

Involved NE: ATS and SPG
Defect Details
Symptom The BSS is used to provision services for VoLTE subscribers. When LST
MSR is run with the path parameter specified to query imitation-of-
parallel-calls, the SPG does not return the query result to the BSS.

Copyright © Huawei
Trouble N/A
Ticket
Number
When the customer uses the path parameter to query limitation-of-
parallel-calls, the SPG does not return the query result to the BSS.
The query command received by the ATS is as follows:
The query result returned by the ATS to the SPG is as follows:
The query result received by the BSS is as follows:

Copyright © Huawei

The customer uses the common service flow provided by the ATS.
When the SPG receives the query result from the ATS, it obtains
limitation-of-parallel-calls from the full directory
/m:SERVICEDATA/xcap:MMTel-extension/xcap:basic-
part/xcap:limitation-of-parallel-calls. However, as the query result
returned by the ATS to the SPG is incomplete, the SPG fails to obtain
the corresponding information.
Condition LST MSR is run with the path parameter specified to query imitation-of-
parallel-calls.
of
Occurrence
Involved Version
ATS9900 V100R06C20SPC100
Solution
Workarounds:
N/A
Wait for ATS engineers to develop a patch. It is expected that a patch will be released at April
30, 2016.
2.8.8 Some Subscribers Fail to Register Due to the Incorrect qop

Parameter
Involved NE: CSCF
Defect Details
Symptom Some subscribers fail to register, and the CSCF returns a 403 message
indicating "Invalid Subsequent Register Request".

Copyright © Huawei
Trouble N/A
Ticket
Number
Some subscribers fail to register, and the CSCF returns "Invalid Subsequent
Register Request".
The 401 message is as follows:
The REGISTER message received by the P-CSCF after the 401 message is
as follows:
The REGISTER message sent by the P-CSCF to the I-CSCF after the 401
message is as follows:

Copyright © Huawei
At this time, the REGISTER message sent by the P-CSCF to the I-CSCF
does not contain the authentication header field (the protocol stack deletes
this header field). As a result, the S-CSCF determines that the REGISTER
message is abnormal, causing the registration failure.
The reason is that the S-CSCF does not include the qop parameter in the
401 message but the subsequent REGISTER message carries this
parameter.
If the UE needs to carry the qop parameter, the value of this parameter
must be set to the qop parameter value in the 401 message sent to the UE.
Condition The 401 message does not contain the qop parameter, but the REGISTER
message sent after the 401 message contains the qop parameter whose
value is left unspecified.
of
Occurrence

Copyright © Huawei
Involved Version
ATS9900 V100R08C10SPC100
Solution
Workarounds:
N/A
Rectify the UE to be protocol-compliant.
2.8.9 ATS Releases the Call Due to Unsupported Fax Codecs

When a Voice Call Is Switched to a Fax Call
Involved NE: ATS
Defect Details
Symptom When a voice call is switched to a T.38 fax call for a subscriber, the ATS
releases the call with a BYE message. This is because the subscriber' data
on the ATS indicates that the T.38 codec is not supported.
Trouble N/A
Ticket
Number
When a voice call is switched to a T.38 fax call for a subscriber, the ATS
releases the call with a BYE message. This is because the subscriber' data
on the ATS indicates that the T.38 codec is not supported.
The following figure shows the switchover from a voice call to a T.38 fax
call:

Copyright © Huawei
The following figure shows the ATS releases the call with a BYTE
message:
In ATS 10.0 or later, this issue can be resolved by modifying SIPCFG data.
In ATS 9.1 or 9.2, this issue can be resolved by changing the setting of
software parameter 3183.
Condition  Voice calls are switched to fax calls.
 Subscriber data does not indicate any support for fax calls.
of
Occurrence

Copyright © Huawei
Involved Version
ATS9900 V100R05C02SPC100
Solution
Workarounds:
N/A
Modify the setting of software parameter 3183 or run MOD SIPCFG:
SFPARA=SIP_SEND_488_NO_MEDIA_AFTER_FILTER-1;.
2.9 Fault Cases for February 2016

2.9.1 iPhones Fail to Register with IMS Networks
Involved NE: SBC
Defect Details
Symptom iPhones fail to register with IMS networks and therefore cannot use VoLTE
services.
Trouble N/A
Ticket
Number
Root Cause The following two scenarios are involved.
1. An iPhone initiates a network attach request and obtains a newly
assigned IP address. However, the iPhone still uses the original IP address
to initiate a registration, resulting in a failure for the PGW to forward the
registration to the SBC. When the maximum number of re-registrations
initiated by the iPhone is reached, the iPhone no more initiates a
registration.
2. When an iPhone uses the same IP address and a different ipsec sa port to
initiate a registration, the SBC includes the proprietary ipsec sa port in the
Via header field. Once the CSCF detects the port change, it returns a 403
message to the iPhone to deny the registration. When the iPhone receives a
403 message for two consecutive times, it no more initiates a registration.
Condition  An iPhone initiates a network attach request and obtains a newly
assigned IP address. However, the iPhone still uses the original IP
address to initiate a registration.
 The SBC includes the proprietary ipsec sa port in the Via header field.
of
Occurrence

Copyright © Huawei
Involved Version
Solution
Workarounds:
N/A
For scenario 1, the Apple needs to identify and resolve the iPhone issue.
For scenario 2, a patch will be developed to resolve the SBC issue.
2.9.2 Calls Cannot Be Made to iPhones That Are Running in the

Data Mode
Involved NE: CSCF
Defect Details
Symptom When a call addressed to an iPhone running in the data mode is connected
in the IMS network, the SBC returns a 404 message.
Trouble N/A
Ticket
Number
Root Cause 1. The reason why the SBC returns a 404 message is that the iPhone has
deregistered when a call is addressed to the iPhone.
2. The time when the CSCF initiates a deregistration is three minutes later
than the SBC. When the CSCF that has not deregistered the iPhone
happens to forward a call to the SBC that has deregistered the iPhone, the
SBC returns a 404 message.
Condition  The subscriber has registered with the IMS network.
 A call is addressed to the iPhone that encounters a registration timeout.
of
Occurrence
Involved Version
CSC3300 V100R010C10
Solution
Workarounds:

Copyright © Huawei
N/A
Load the V100R010C10SPH213 patch on the CSCF and perform data configuration.
Data Configuration:
Set bit 12 of DBMSPARA5 to 1.
MOD SFP: INSPN=DBMSPARA5, MODTYPE=P1, BIT=12, BITVAL=1;
Bit 12 of DBMSPARA5 is used for function control.

Determines how the CSCF scans subscriber data when detecting that a subscriber has encountered a
registration timeout.
= 0: The CSCF scans subscriber relationship table data.
= 1: The CSCF scans subscriber registration control blocks.
Default value: 0
Bits 11-9 of DBMSPARA5 are used for value setting.
Determines the number of subscribers scanned by the CSCF every second when detecting that a
subscriber has encountered a registration timeout. Bits 11-9 of DBMSPARA5 are valid only when bit 12
of DBMSPARA5 is set to 1.
Value range: 0x0 to 0x7; the unit is thousand subscribers.
= 0x0: The S-CSCF scans data of 3,000 subscribers every second.
= 0x1 to 0x7: The S-CSCF scans data of a specified number of subscribers every second.
Default value: 0x0
2. In extreme situations (for example, when the SBC module restarts and subscriber data
exists on the CSCF/TAS), the SBC returns a 404 message. To ensure voice connection when
this issue occurs, add the 404 message to the CS RETRY error codes configured on the SCC
AS. The detailed configuration is as follows:
MOD CSRETRYCFG: CSRETRYSWITCH=ON, TRIGGERCODE=SIP404-1&SIP408-
1&SIP410-1&SIP503-1&SIP504-1;
2.9.3 VoLTE Subscribers Using iPhones Fail to Call CS

Subscribers
Involved NE: UE
Defect Details
Symptom After iPhone subscribers are upgraded to VoLTE subscribers, they fail to
call CS subscribers. The traced subscriber messages show that the MGCF
returns a 400 message to the previous hop immediately when receiving an
INVITE message.
Trouble N/A
Ticket
Number
Root Cause It is found that the iOS version of the iPhone is 9.0, 9.0.2, or 9.1, which is

Copyright © Huawei
earlier than 9.2.1. When the INVITE message sent by the iPhone is not
protocol-compliant, the MGCF releases the call.
The message tracing logs contain the following information:
2. Simulate SDP information. It is found that a semicolon (;) is placed

between 104 and max-red=220; and between 102 and max-red=220;,
which causes a failure in resolving SDP information. The following shows
the comparison between the successful and failed SDP resolutions:
The SEQ signaling analysis shows that the INVITE message sent by the
iPhone contains extra semicolons (;).
[Related Protocols]
As stipulated in RFC4566, there is no semicolon (;) for "<format> <format
specific parameters>".

Copyright © Huawei
According to 3GPP TS 26.103, see RFC4867 for details about how SDP
information is carried in AMR-WB.
As stipulated in RFC4867, when there are multiple <format specific

parameters>, these parameters are separated by a semicolon (;).
RFC4867 gives the following description about the IE:

Copyright © Huawei
Condition The INVITE message sent by the iPhone is not protocol-compliant.

of
Occurrence
Involved Version
All versions of the iPhone
Solution
Workarounds:

Copyright © Huawei
N/A
The Apple needs to resolve this issue.
2.9.4 Calls Addressed to VoLTE Subscribers May Fail After IN

Services Are Triggered
Involved NE: SCP
Defect Details
Symptom Calls addressed to VoLTE subscribers may fail after Intelligent Network
(IN) services are triggered.
Trouble N/A
Ticket
Number
Root Cause 1. After the SBC sends an INVITE message to the called party, it does not
receive any response. Then, after several seconds, the originating UE
sends a REGISTER message that contains a different IP address. When
the S-CSCF receives the REGISTER message, it determines that this
request is a new initial registration or used for a deregistration and
therefore releases the previous call.
2. The SCP AS sends a message to the HSS, requesting the real-time 4G

location information. As the MSC server on the live network does not
support the real-time information acquisition, it sends a paging request
to the 2G network. The 2G network cannot determine whether this
paging request is a voice call or short message service (SMS) paging
request. After the mobile phone is handed over to the 2G network, it
cannot receive the INVITE message from the SBC. Consequently, the
mobile phone cannot respond to the INVITE message. When the mobile
phone does not receive a voice setup message before the corresponding
timer of the mobile phone expires, it is handed over to the 4G network.
At this time, the mobile phone sends a deregistration or an initial
registration, causing the previous call to be released.

Copyright © Huawei
Condition This issue occurs when the ATI message sent by the SCP AS carries the
currentlocation and LocationInformation EPS-Supported fields.
of
Occurrence
Involved Version
All versions of the SCP AS
Solution
Workarounds:
N/A
Rectify the SCP AS so that the ATI message sent by the SCP AS does not contain the
currentlocation or LocationInformation EPS-Supported field.
2.9.5 Huawei and Bell Have Different Understandings of IMS

Protocols
Involved NE: CSCF
Defect Details
Symptom VoLTE subscribers served by the Bell VoLTE device cannot call VoLTE
subscribers served by the Huawei VoLTE device who are in the 2/3G
network but cannot call VoLTE subscribers served by the Huawei VoLTE
device who are in the 4G network. This is because the History-Info header
field in the INVITE message sent by the Bell VoLTE device contains only
one record.
Trouble N/A
Ticket
Number
Root Cause 1. In normal call flows, the INVITE message sent by the Bell device to the
Huawei S-CSCF contains the History-Info header field. However, this
header field contains only one record, that is, B's number. After the S-
CSCF contacts the SCC AS, the SCC AS routes the call to the 2/3G
subscriber through domain selection. The Request-URI is changed to the
CSRN, that is, C's number. When the S-CSCF detects that the Request-URI
is changed and the History-Info header field is carried, it determines that a
call forwarding event has occurred. However, as stipulated in the relevant
protocol, the History-Info header field must contain two records, that is, the
original called number and forwarded-to number.
The following is an INVITE message sent by the Bell VoLTE device:

Copyright © Huawei
The following is an INVITE message sent by the SCC AS after the SCC
AS routes the call to the 2/3G network through domain selection:
2. Service Scenario Analysis

 Call Forwarding Service
The normal call forwarding flow applies. For example, when A calls B, B
forwards the call to C. The AS changes the Request-URI from B's number
to C's number and carries the History-Info header field that contains two
records. Then, the CSCF continues to trigger the subsequent iFCs.
 Domain Selection Service
When the AS routes the call to the 2/3G network through domain selection,
it changes the Request-URI from B's number to the CSRN and does not
carry the History-Info header field. This means that outgoing number
analysis is performed (there is no need to continue to trigger iFCs).

Copyright © Huawei
Condition The Bell VoLTE device carries the History-Info header field in non-call
forwarding scenarios.
of
Occurrence
Involved Version
Solution
Workarounds:
Modify software parameter settings on the S-CSCF to resolve the issue caused by the
incorrect way that the Bell device processes messages. However, the issue of continuing to
trigger iFCs after number change cannot be resolved.
Suggestion by Huawei:
As the INVITE message sent by the Bell VoLTE device to the S-CSCF for basic calls contains
the abnormal History-Info header field, the S-CSCF denies the calls.
The Bell VoLTE device needs to be rectified in such a way that it does not carry the History-
Info header field in non-call forwarding scenarios.
2.10 Fault Cases for January 2016

2.10.1 Modifying Subscription Data on the PGW Fails Due to the
Loss of KI Data
Involved NE: HSS
Troubleshooting Engineer: Wan Jun (ID: 00265982)
Defect Details
Symptom Subscribing to T-CSI data fails on the PGW. The system displays the error
message "Template not defined."
%%MOD TCSI: IMSI="51502960000xxxx", PROV=TRUE,
TPLID=102;%%
RETCODE = 3003 ERR3003:Template not defined
There is together 1 report
--- END

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause Check the template and it is found that the template has been defined.
Then, check whether the subscriber has registered. It is found that the
subscriber has registered. However, the subscriber fails to use the same
USIM card to register with the 3G network. The reason is that KI data has
been deleted. After KI data is added, subscribing to T-CSI data is
successful.
Condition KI data has been deleted.
of
Occurrence
Involved Version
All versions of the HSS9860
Solution
Workarounds:
N/A
Add KI data to ensure successful subscription to T-CSI data.
2.10.2 Ut Service Test Can Be Performed Using the hosts File

Embedded in an Android-Based Mobile Phone
Involved NE: UE
Defect Details
Symptom In VoLTE networks, Ut services use the data APN or a newly established
APN. Due to the business flow on the customer side, it takes a long time to
create UIM domain resolution data records on the DNS server. This gives
rise to a question: How to perform a Ut service test without this wait?
Trouble N/A
Ticket
Number
Root Cause If an Android-based mobile phone is rooted, use the embedded hosts file
for domain resolution and perform a Ut service test.
The details are as follows: 1. Connect the mobile phone to a computer
using a data cable. 2. Install the data cable driver. 3. Apply for CPM serial
rights. 4. Install the ADB environment.

Copyright © Huawei
Then, click 1_pull_hosts.bat and back up the hosts file to the current
directory.
Modify the hosts file as required, click 2_push_hosts.bat, and upload the
modified hosts file to the mobile phone.
Restart the mobile phone for the modification to take effect.
See the attachment for the ADB tool, scripts, and sample hosts file.
Attachment:
ADB.rar modify hosts.rar
Condition This issue occurs when the corresponding domain resolution data records
are not configured on the DNS server.
of
Occurrence
Involved Version
All versions of the UE
Solution
Workarounds:
N/A
Use the script files in the attachment to modify the UE configuration.
2.10.3 Diameter Links Between the CSCF and DRA Do Not Run
Properly
Involved NE: CSCF
Defect Details
Symptom Diameter links are established between the CSCF and DRA and run
properly. However, after the peer host name is changed (MOD IDRA:
DRANM="IDRA", DN="xxx.xxx.xx", HN="xxx.xxx.xxx.xx";) as required
by DRA engineers, Diameter links do not run properly.
Trouble N/A
Ticket
Number
Root Cause 1. Check whether interworking parameters are correct. If yes, perform the
following step:
2. Check the local end for Diameter link fault alarms.
3. Trace Diameter messages. It is found that the CSCF does not initiate a

Copyright © Huawei
Diameter link establishment request after receiving a CEA message from

the DRA.
4. Obtain the debug logs. It is found that the following error information is
displayed:
M0032P198F00S01M 2015-01-29 16:28:08
ERR [../../../../source/COMMON/Sig/DiamRM/src/diameterlm.c
FileID(770) : 5283 <DiamDebugSend>]
Diameter Stack Debug:Error Information[DiamCmProcCEA, 4580]Server
Returned Failure CEA
5. Analyze why this error information is displayed. It is found that the peer
host name is modified without resetting the local end. When the CSCF still
uses the original peer host name for communication with the DRA,
Diameter links cannot be established.
Conclusion: When modifying the peer host name used for establishing
Diameter links, reset the local end. Alternatively, delete the original links
and create new ones.
Condition This issue occurs when the peer host name used for establishing Diameter
links is modified without resetting the local end.
of
Occurrence
Involved Version
CSC3300 V100R011C10
Solution
Workarounds:
N/A
When modifying the peer host name used for establishing Diameter links, delete the original
links by running RMV IDRAL and then create new ones.
2.10.4 SBC Cannot Receive REGISTER Messages from P-GW

Involved NE: P-GW
Troubleshooting Engineer: Xi Dongbo (ID: 00351334)
Defect Details
Symptom The P-GW sends a REGISTER message to the access-side signaling IP

address of the SBC. However, the signaling messages traced on the SBC
show that the SBC does not receive the REGISTER message.
Networking: P-GW-----LAN switch----Firewall------Router-----SBC

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause First check whether there is a problem with 4G attach. It is found that the
signaling messages traced on the P-GW show that the P-GW sends the SBC
IP address to the UE, and it is also found that the UE obtains the IP address.
Therefore, there is no problem with 4G attach.
Then check whether the IP address is pingable. It is found that the
messages captured on the UE show the UE sends a REGISTER message.
(Before IP information is configured, pinging the P-GW IP address is
successful.) It is also found that there is no problem with the router and the
REGISTER message is not filtered out by the firewall. Perform TraceRoute
on the SBC and it is found that the LAN switch can be pingable but the UE
IP address pool on the P-GW cannot be accessed. Therefore, there must be
a problem with the P-GW. Check the newly configured data used for
interworking between the P-GW and SBC and it is found that block
information is configured for the IMS APN and outgoing data from the P-
GW to P-CSCF is disabled.
Condition This issue occurs when IMS APN data is incorrectly configured on the P-
GW.
of
Occurrence
Involved Version
All versions of the P-GW
Solution
Workarounds:
N/A
Correct the configuration on the P-GW as follows:
Sys
APN IMS
ims-sig-filter 2 source src-any sportop sp-any dest des-any dportop dp-any protop pro-any
2.10.5 SPG Fails to Issue Service Provisioning Instructions Due to

the Change in the Default Value of the INSP Software Parameter
Involved NE: HSS
Troubleshooting Engineer: Xi Dongbo (ID: 00351334)
Defect Details

Copyright © Huawei
Symptom When a service provisioning command is run on the SPG, the system
displays "RETCODE = 5004HSS-ERR5004:Session ID invalid or time
out."
Trouble N/A
Ticket
Number
Root Cause Check the setting of the INSP software parameter on the USCDB.
1. In HSS9860 C10, the SOAP interface is controlled by the software
parameter obtained by running LST INSP: INSPT=PGW,
INSPN=RIGHTSWITCH.
2. In HSS9860 C20, the SOAP interface is controlled by the software
parameter obtained by running LST INSP: INSPT=FE,
INSPN=PROVRIGHTSWITCH.
The default value is 1, indicating that rights are checked.
Value:
= 0: Rights are not checked.
= 1: Rights are checked.
= 2: Rights check is enabled for MML commands, not SOAP commands.
Condition This issue occurs when the setting of the INSP software parameter is
changed.
of
Occurrence
Involved Version
HSS9860 C20
Solution
Workarounds:
N/A
Run the following command on the USCDB:
MOD INSP: INSPT=FE, INSPN=PROVRIGHTSWITCH, INSPV=0, FETYPEN="USCDB";
2.10.6 eSRVCC Handovers Fail Due to eNodeB Configuration

Errors
Involved NE: eNodeB
Troubleshooting Engineer: Cui Zhaorui (ID: 00184322)
Defect Details

Copyright © Huawei
Symptom Apple performed a VoLTE test on a certain carrier's network. At 13: 26, the
eSRVCC handover failed. That is, the UE still displayed the VoLTE
network, not the 2G/3G network.
Trouble N/A
Ticket
Number
Root Cause Trace messages on the IWF. It is found that the eSRVCC handover failure
is caused by the fact that the MME cancels the handover request. See
Figure 2-1.
Figure 2-1 Messages traced on the IWF
Check the messages traced on the MME. It is found that the MME receives
the HANDOVER REQUIRED message from the eNodeB. Then, the MME
converts the message to the SRVCC PS to CS Request message and sends
it to the IWF. One second later, the MME receives the HANDOVER
CANCEL message from the eNodeB. The HANDOVER CANCEL
message is used to cancel the handover request, causing the handover
failure. See Figure 2-2.
Figure 2-2 Messages traced on the MME
Conclusion: The time (1 second) for the eNodeB to wait for the handover
response is so short that it cancels the handover request before the core side
completes the handover.
Condition This issue occurs when the time for the eNodeB to wait for the handover
response is less than 3 seconds.

Copyright © Huawei
Probability This issue occasionally occurs.

of
Occurrence
Involved Version
All versions of the eNodeB
Solution
Workarounds:
N/A
Change the time for the eNodeB to wait for the handover response to a large value.
Make this change based on site requirements.
2.10.7 Calls Fail Due to Access-Side Bearer Resource Insufficiency

Involved NE: RNC
Defect Details
Symptom Apple performed a VoLTE test on a certain carrier's network. At 14:37, the
call was dropped.
Trouble N/A
Ticket
Number
Root Cause The messages traced on the SBC show that the call was dropped before an
eSRVCC handover. The reason is "insufficient-Bearer-Resources". At
14:38:21.055, the SBC received an ASR message from the PCRF. See
Figure 2-1.
Figure 2-1 Messages traced on the SBC
At 14:38:21.040, the PCRF sent an ASR message to the SBC. At

14:38:21.039, the PCRF received a CCR-T message from the UGW. See
Figure 2-2.
Figure 2-2 Messages traced on the PCRF

Copyright © Huawei
At 14:38:21, the UGW sent a Credit Control Request message to the PCRF.
At 14:38:21, the UGW received a Release Access Bearers Request message
from the MME. See Figure 2-3.
Figure 2-3 Messages traced on the UGW
The messages traced on the MME show that the MME received a release
message from the eNodeB at 14:38:21. The reason value is radio-
connection-with-ue-lost, which causes the call to be dropped. See Figure
2-4.
Therefore, access-side bearer resources insufficiency is the root cause of

the call drop.
Condition This issue occurs when the access-side bearer resources are insufficient.
of
Occurrence
Involved Version
All versions of the RNC
Solution
Workarounds:
N/A
Optimize the radio access network.

Copyright © Huawei
2.10.8 Calls Fail Due to Poor Radio Network Coverage

Involved NE: RNC
Defect Details
call failed.
Trouble N/A
Ticket
Number
Root Cause The messages traced on the SBC show that when the iPhone initiates a call,
the SBC receives an INVITE message and forwards it to the CSCF. See
Figure 2-1.
The CSCF contacts the MO ATS and forwards the message to the CS
domain. The MO CSCF receives a 500 message indicating call release. See
Figure 2-2.
Figure 2-2 Messages traced on the CSCF
When the MGCF receives an INVITE message, it converts the message an

IAM message (BICC message) and sends the IAM message to the MSC
server. See Figure 2-3.
Figure 2-3 Messages traced on the MGCF

Copyright © Huawei
When the MSC server receives an IAM message from the MGCF, it sends a
Paging message instructing the RNC to page the called party. However, as
the Ec/No value is less than -13 dbm, the RNC releases the call and sends a
call release message to the MSC server.
See Figure 2-4.
Figure 2-4 Messages traced on the RNC
When the RB is being established, the UE sends a call update to the RNC.
If the Ec/No quality is too poor, the RB establishment fails.

Copyright © Huawei
When the MSC server receives a call release message from the RNC, it
changes the release cause value to No route to destination and sends the
value to the MGCF.
Figure 2-5 Messages traced on the MSC server
When the MGCF receives a call release message from the MSC server, it
converts the BICC message to a 500 message (SIP message) and sends the
500 message to the CSCF.

Copyright © Huawei
Condition This issue occurs when the radio network coverage is poor.
of
Occurrence
Involved Version
All versions of the RNC
Solution
Workarounds:
N/A
Optimize the radio network to improve its coverage.
2.10.9 eSRVCC Handovers Fail Due to Abnormal Messages Sent

by the UE
Involved NE: UE
Defect Details
call was dropped.
Trouble N/A
Ticket
Number
Root Cause The messages traced on the SBC show that the call was dropped before an
eSRVCC handover. The reason is "bearer-Released." At 12:43:18.850, the
SBC received an ASR message from the PCRF. See Figure 2-1.

Copyright © Huawei
At 12:43:18.842, the PCRF sent an ASR message to the SBC. At

12:43:18.742, the PCRF received a CCR-T message from the UGW. See
Figure 2-2.
Figure 2-2 Messages traced on the PCRF
At 12:43:19.277, the UGW sent a Credit Control Request message to the

PCRF. At 12:43:19.276, the UGW received a Delete Session Request
message from the MME. See Figure 2-3.
Figure 2-3 Messages traced on the UGW
The messages traced on the MME show that when the calling and called
parties are in the call, the MME receives an Attach Request message from
an UE, causing the call to be dropped. See Figure 2-4.
Condition This issue occurs when a UE sends an attach request to the MME during a
call.

Copyright © Huawei
of
Occurrence
Involved Version
iPhone IOS 9.2
Solution
Workarounds:
N/A
Submit this issue to Apple and request Apple to resolve it.
2.10.10 After the SCC AS Triggers CS Retry, the Terminating S-

CSCF Returns a 500 Message
Involved NE: CSCF
Defect Details
Symptom During session establishment, when the called VoLTE subscriber hands
over from the 4G to 2/3G network (a deregistration is sent to the 4G
network), the S-CSCF returns a 480 message. After the SCC AS triggers
CS Retry, the MT S-CSCF returns a 500 message, causing the CS Retry
failure.
Trouble N/A
Ticket
Number
Root Cause Although the S-CSCF returns a 480 message during the handover, the SCC
AS triggers CS Retry normally. However, when the S-CSCF receives an
INVITE message related to CS Retry, it returns a 500 message to release
the call. The following figure shows the message flow:

Copyright © Huawei
Trigger conditions:
1. During session establishment (the 1xx (other than 100), 2xx, or Oxx
message is not received when an initial INVITE message is sent to the
called VoLTE subscriber), the called VoLTE subscriber hands over from the
4G to 2G network.
2. During the handover, a deregistration is sent to the original network.
3. The route selection attribute code has been configured on the CSCF by
running ADD SRTSAC.
4. CS Retry has been enabled on the CSCF.
Bit 14 of SCSCFPARA8 is used for value setting.
It determines which SIP response is used by the CSCF to release the call
when the called subscriber deregisters, changes the registration IP address,
fails to contact the AS for registration, or encounters an AS deregistration
during call establishment.
= 0: The 487 message is used by the CSCF to release the call.
= 1: The 480 message is used by the CSCF to release the call.
Default value: 0
Troubleshooting:
1. In common CS Retry scenarios, the S-CSCF downloads subscriber
information from the HSS through the SAR/SAA and stores it regardless of
whether subscribers have registered or not.
a. Registered subscribers: The S-CSCF downloads subscriber information
during registration.
b. Unregistered subscribers: The S-CSCF downloads subscriber
information when unregistered services are triggered.
2. In deregistration scenarios, the subscribe type cannot be obtained for the
CS Retry call.
MID(104) PID(261) Level(ERR) -> SCALLRouteAttributeAnaProc: Call
CallNaGetUserTypeForSRTSAC failed! ulRet=[16643]
The reason is as follows: As the route selection attribute code has been
configured on the S-CSCF by running ADD SRTSAC, a route needs to be

Copyright © Huawei
selected based on the route selection attribute code. This means the
subscriber type (that is, the called VoLTE subscriber type) needs to be
obtained during route analysis. However, as the called VoLTE subscriber
has deregistered, the corresponding registration information does not exist
any more. This causes a failure in obtaining the called VoLTE subscriber
type. Finally, CS Retry fails, and the calling party cannot establish a call to
the called VoLTE subscriber.
Condition This issue occurs when all of the following conditions are met:
 The route selection attribute code has been configured on the S-CSCF by
running ADD SRTSAC, which means that a route needs to be selected
based on the route selection attribute code.
 The VoLTE subscriber has deregistered.
 A call is addressed to the VoLTE subscriber.
of
Occurrence
Involved Version
CSC10.1
Solution
Workarounds:
N/A
This issue will be resolved in the CSC10.1SPH216 patch, which is to be released by the end
of January 2016.
2.10.11 When Subscribers Register, the CSCF Returns a 403

Message Carrying "Administrator deregister user"
Involved NE: SBC
Defect Details
Symptom iPhone 6 fails to register. It is found that after iPhone 6 receives a 401
message, it sends a second REGISTER message but the S-CSCF returns a
403 message whose Warning header field carries "Administrator deregister
user."
Warning: 399 0.0.S.260.5.119.255.255.5144.0.0.bj.chinamobile.com
"Administrator deregister user"
Trouble N/A
Ticket

Copyright © Huawei
Number
Root Cause Within a short time, iPhone 6 (User-Agent: iOS/9.2.1 (13D15) iPhone)
initiates a reregistration and then an initial registration. The reregistration is
successful (see line 4783). For the initial registration, the S-CSCF returns a
401 message requesting an authentication. When iPhone 6 initiates a
second REGISTER message, the S-CSCF returns a 403 message whose
Warning header field carries "Administrator deregister user."
For the first and second REGTSTER messages, their Contact header fields
contain the same IP address and port number. However, their Path header
fields contain the same IP address but the different port numbers, which
means that the two registrations are initiated using the same IP address but
different port numbers.
1. Reregistration: The authentication is carried, the integrity protection flag
is set to yes, and the port number in the Path header field is 49153.
Authorization: Digest
nonce="PazhaZiaq1HMOR4bBtzy+ACeBPlsW3JMOUatpBxWma0=",
uri="XXXXXX",
response="5951937da36c748efb6297918afff1f9",algorithm=AKAv1-MD5,
nc=00000001,integrity-protected=yes
Contact: <sip:
[XXXXXXXX]:5060;transport=udp;Hpt=8e82_16;suid=AcARBiQJiACG
EADkCFze5gE9yXUBAAAA;srti=d0_1024>;+g.3gpp.icsi-ref="urn
%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;
+g.3gpp.smsip;+g.3gpp.srvcc-alerting;
+sip.instance="<urn:gsma:imei:35439406-123707-0>"
Path:
<sip:term@XXXXX:5060;transport=udp;lr;ssn;hwnos;TYPE=V6;IP=XXX
XXXXX;PORT=49153;Hpt=8e82_86;TRC=7f5-
ffffffff;suid=AcARBiQJiACGEADkCFze5gE9yXUBAAAA;srti=d0_1024
>
2. Initial registration: The authentication information is not carried, the
integrity protection flag is set to no, and the port number in the Path header
field is 58909.
Authorization: Digest
realm="ims.mnc000.mcc460.3gppnetwork.org",nonce="",

Copyright © Huawei
uri="sip:ims.mnc000.mcc460.3gppnetwork.org",response="",
algorithm=AKAv1-MD5,integrity-protected=no
Contact: <sip:
[XXXXXXX]:5060;transport=udp;Hpt=8e82_16;suid=HeYRBiQJiACGE
ADkCFze5gE9yXUBAAAA;srti=d0_1025>;+g.3gpp.icsi-ref="urn
%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";+g.3gpp.mid-call;
+g.3gpp.smsip;+g.3gpp.srvcc-alerting;
+sip.instance="<urn:gsma:imei:35439406-123707-0>"
Path:
<sip:term@XXXX:5060;transport=udp;lr;ssn;hwnos;TYPE=V6;IP=2409:8
800:8610:E4:85C:DEE6:13D:C975;PORT=58909;Hpt=8e82_86;TRC=7f5-
ffffffff;suid=HeYRBiQJiACGEADkCFze5gE9yXUBAAAA;srti=d0_1025
>
For the two registrations, the Path header field is changed but the Contact
header field is kept unchanged. When storing subscriber data, the S-CSCF
considers the registration abnormal, returns a 403 message, and deletes
subscriber data.
The root cause is as follows: After the VoLTE UE has completed the IMS-
AKA/IPSec registration, the IP address is unchanged, the port number is
changed, and the changed port number is in plain text (not encrypted using
IPSec). When an initial registration is initiated again, the PORT parameter
in the Path header field of the REGISTER message forwarded by the SBC
is changed. However, as the Contact header field is not changed, the S-
CSCF considers the registration abnormal and returns a 403 message
whose Warning header field carries "Administrator deregister user."
Condition This issue occurs when both of the following conditions are met:
 After the VoLTE UE has completed the IMS-AKA/IPSec registration, the
IP address is unchanged and the port number is changed.
 The changed port number is in plain text (not encrypted using IPSec) and
used to initiate an initial registration.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
This issue will be resolved by a SBC patch, which is to be released by February 2016.

Copyright © Huawei
2.10.12 When a Call Is Addressed to a VoLTE Subscriber Who

Returns to the 4G Network After an eSRVCC Handover, CSFB Is
Performed on the MT Side
Involved NEs: SBC and UE
Defect Details
Symptom When two VoLTE subscribers in a call roam to areas with 2G/GSM
coverage, an eSRVCC handover is performed. After the handover, the call
continues for three minutes and then ends normally. However, after these
two VoLTE subscribers return to the 4G network and a call is initiated
between them again, circuit switched fallback (CSFB) is performed on the
MT side.
Trouble N/A
Ticket
Number
Root Cause 1. When a call is addressed to a VoLTE subscriber who returns to the 4G
network after an eSRVCC handover, the VoLTE subscriber's UE receives a
TCP SYN message (for attempting an INVITE message) from the network
side. The TCP SYN message is used to create a TCP connection. However,
as there is already a TCP connection that in the established state, the UE
discards the connection.
2. After the called UE hands over to the 2G network, the SBC sends an
RST message due to the aging of TCPs links on the MT side. However, as
the called UE is still in the 2G network, it has not received the RST
message. After the called UE returns to the 4G network and a call is
initiated to the UE, the SBC sends an SYN message for re-establishing
links. However, the UE has not received the RST message, causing TCP
link status inconsistency. Therefore, the UE does not respond to the SYN
message.
Condition This issue occurs when a TCP connection is used between the UE and
network.
of
Occurrence
Involved Version
SE2900 V300R001C20
Solution
Workarounds:
1. Change the duration of the TCP aging timer on the SBC to one hour. The usage of TCP
resources on the SBC is assessed as follows:

Copyright © Huawei
The keepalive period for the server mode is set to one hour, and the keepalive period for the
client mode is set to 32 seconds. A single SCU module supports 50,000 subscribers as well as
80,000 TCP connections for the server mode and 40,000 connections for the client mode. As a
single SCU module supports about 8,000 concurrent calls, TCP connections are sufficient.
Bit 22 of BCFPARA9 is used for function control.
It determines whether the aging time of TCP server links used by IPSec AKA subscribers on
the SE2900 is configurable.
= 0: The aging time is not configurable. It is fixedly set to 3 minutes.
= 1: The aging time is configurable. Use bits 7-0 of BCFPARA10 to configure the aging time.
For details, see the description of BCFPARA10.
Default value: 0
BCFPARA10 is used for value setting. It uses bits 7-0.
It determines the aging duration of TCP server links used by IPSec AKA subscribers. Value
range: 0-60 (in minutes)
The default value is 0, indicating that the aging time is the subscriber registration duration
plus 3 minutes. The aging timer is released when a subscriber deregisters or the SA in use is
handed over.
When the value 1 is used, the link aging time is 2 minutes as the link keepalive period is also
1 minute.
When the value 60 is used, the link aging time is 60 minutes.
Recommended value: 60
Bit 23 of BCFPARA9 is valid only when bit 22 of BCFPARA9 is set to 1.
Bit 23 of BCFPARA9 is used for function control.
It determines whether the aging time of TCP client links used by IPSec AKA subscribers on
the SE2900 is configurable.
= 0: The aging time is not configurable. Links are released 32 seconds after the call ends.
= 1: The aging time is configurable. Use bits 15-8 of BCFPARA10 to configure the aging
time. For details, see the description of BCFPARA10.
Default value: 0

Copyright © Huawei

BCFPARA10 is used for value setting. It uses bits 15-8.
It determines the aging time of TCP client links used by IPSec AKA subscribers. Value range:
1-60
The default value is 0, indicating that links are released 32 seconds after the call ends.
When the value 1 is used, the link aging time is 2 minutes as the link keepalive period is also
1 minute.
When the value 60 is used, the link aging time is 60 minutes.
Recommended value: 60
BCFPARA10 is valid only when bit 23 of BCFPARA9 is set to 1.
Optimize the TCP link establishment mechanism of the SBC as follows:
1. Optimize handover scenarios. If an eSRVCC handover is performed to the 2G network, the
RST/FIN message is not sent to the UE even if the TCP connection times out. The RST/FIN
message is sent to the UE only after it returns to the 4G network.
2. The SBC does not support link teardown using the plaintext FIN message. Currently, TCP
connection encrypted only for AKA subscribers can be torn down using the FIN message.
Plaintext TCP connections cannot be torn down using the FIN message (the port number is
5060).
3. If the UE carries transport=tcp, the BYE/PRACK message sent by the SBC cannot be
converted to a UDP message. Therefore, if the UE still cannot receive messages, the
maximum number of retransmissions times and the retransmission time of the TCP must be
modified.
This issue is considered as a service requirement that will be fulfilled in the
V300R001C20SPH117 patch.
Optimize the UE as follows:
In the client mode, after the UE hands over to the 3G network and then back to the VoLTE
network, the TCP link is still in the connected state. In this case, when the UE receives an
SYN message, it must send an ACK message rather than discarding the SYN message.
2.10.13 End Office Takes More Than Four Seconds to Return a

Response (to PSI) to the HSS
Involved NE: UE
Defect Details
Symptom When a call is addressed to a subscriber (VoLTE@CS), the TAS sends an

UDR message to query the HSS for 2/3G location information. However,
the end office takes more than four seconds to return a response to the PSI
message.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause 1. The UDR message sent by the VoLTE AS contains currentLocation.
2. The HSS has the following service requirements:

Location service requirements: The currentlocation and
currentLocationRetrieved fields can be forwarded. When the MAP ATI
message contains the currentlocation field, the HLR needs to forward
the currentLocation field to the MSC or SGs MSC through the
MAP_Provide_Subscriber_Information(PSI) message. When the SGs
MSC returns the currentLocationRetrieved field through the PSI ACK
message, the HLR does not need to report an error or filter the field out.
Instead, it needs to transparently transmit the field to the location
service platform through the ATI ACK message.
3. By default, the MSC returns subscriber information to the HSS after
receiving the PSI message.
4. After the MSC receives the PSI message, it determines whether the
message contains the Location Information or Subscriber State
information element (IE) and Whether to page when PSI in the
MAPPARA table is set to Yes. If yes, the MSC sends a paging message
to the wireless side to obtain the accurate location information and
status of the subscriber.
5. As the duration of the timer for the ATS to wait for the UDA message is
five seconds and the duration of the timer for the HSS to wait for the
response (to PSI) is four seconds, the UDA message obtained by the
TAS does not contain 2/3G location information.
Condition This issue occurs when the end office takes more than four seconds to
return a response (to PSI) to the HSS.
of
Occurrence
Involved Version
iPhone IOS 9.2
Solution
Workarounds:

Copyright © Huawei
N/A
This issue will be resolved in MSOFTX3000 V100R007C10SPH738 (for CPCI) and
MSOFTX3000 V200R009C02SPH138 (for ATCA).
2.11 Fault Cases for December 2015

2.11.1 Digit Collection Fails for Calls Addressed to the Number
12580
Involved NE: MGCF
Troubleshooting Engineer: Wang Yuanyuan (ID: 00258474)
Defect Details
Symptom When a VoLTE subscriber initiates a call to the number 12580, digit
collection fails.
Trouble N/A
Ticket
Number
Root Cause 1. Trace messages on the MGCF for the call from the VoLTE subscriber to
the number 12580. It is found that pressing keys does not work and there
are no outband DTMF messages. Simulate a scenario in which a VoLTE
subscriber initiates a call to the number 10086. Trace messages on the
MGCF for the call. It is found that pressing keys works and there are also
no outband DTMF messages.
These two calls share the same call path: UE-SBC-SCSCF-MGCF-GMSC-
service platform. The only differences are as follows: The 10086 service
platform returns both the ACM and ANM messages while playing an
announcement, but the 12580 platform returns only the ACM message
while playing an announcement.
Check data configured on the MGCF.
SIPTG data for interworking between the MGCF and S-CSCF:
BICCTG data for interworking between the MGCF and GMSC server:
2. Why are there no DTMF messages for the number 10086?

Check SIPTG data configured for interworking between the MGCF and S-
CSCF:

Copyright © Huawei
Change the value of Outgoing call open DTMF detect to YES (MOD
SIPTG: TGN="HKMGCF1-HKSCSF1-SIP", CALLERDTMF=YES;).
When the VoLTE subscriber initiates a call again to the number 10086, the
message tracing result shows that the MGCF, after receiving an ANM
message from the next-hop NE, returns a 200 message to the previous-hop
NE and then sends an SMMSG_DETECT_DTMF_REQ message. Finally,
the MOD_REQ message is used to instruct the IM-MGW to perform
DTMF detection.
For a SIP-to-BICC call, when the incoming SIP trunk detects an inband
DTMF signal, it converts the signal to an outband message and sends it to
the next-hop NE. In the message tracing result, it is found that APM
messages are sent when the VoLTE subscriber presses keys, and digit
collection is normal.
However, in the message tracing result for the call to the number 12580, it

Copyright © Huawei
is found that no APM messages are sent when the VoLTE subscriber
presses keys, and pressing keys still does not work.
In the message tracing result, it is also found that no MOD_REQ messages
are sent to instruct the IM-MGW to perform DTMF detection.
3. Select the following parameter value when modifying SIPTG data:
In the message tracing result, it is found that before the MGCF returns a
183 message to the previous-hop NE, it has issued DTMF detection to the
IM-MGW.
However, pressing keys still does not work, and no outband DTMF
signaling is found.
4. After comparison with messages in other provinces, it is found that the
value of the p-early-media information element (IE) in the 180 message
sent by the MGCF to the S-CSCF is sendonly in the local province and
sendrecv in other provinces.
This reason is that as the IE is incorrectly set, the terminal cannot report
inband DTMF signals.
Modify SIPTG data by deselecting the following parameter value:
Condition The p-early-media IE in the 180 message sent by the MGCF to the S-CSCF
is set to sendonly.
of
Occurrence
Involved Version
MGCF V200R010C020SPC100
Solution
Workarounds:
N/A

Copyright © Huawei
Modify SIPTG data by deselecting Including sendonly in P-Early-Media for Extra
2.11.2 Subscribers Who Are Not Defined Using the China Mobile-
specific Service Flow Fail to Register
Involved NE: ATS
Defect Details
Symptom After the MMTel AS is upgraded to V100R006C10SPH218 for China

Mobile, subscribers who are not defined using the China Mobile-specific
service flow fail to register. However, subscribers who are defined using
the service flow can register.
Trouble N/A
Ticket
Number
Root Cause It is found that some subscribers are defined by running ADD MSR but the
IMS-CAMEL-Services (IN service) flag is not selected for them. However,
in the iFC template of the MMTel AS, type in the SERVER parameter
carries the ssf field, which means that IN service-related flows will be
performed, for example, UDR messages are sent to issue IN service data.
After the V100R006C10SPH218 patch is installed, the ATS sends an SNR
message to subscribe to IN service data for parameters in the iFC template
that carry the ssf field. However, when subscribers are defined on the ATS
without selecting the MS-CAMEL-Services flag, a subscription error
occurs, affecting calls.
If the China Mobile-specific service flow is adopted, the ATS will carry the
IMS-CAMEL-Services flag for subscribers to be defined. In this case, this
issue does not occur.
Condition The V100R006C10SPH218 patch is installed.
of
Occurrence
Involved Version
ATS V100R006C010SPC200
Solution
Workarounds:
N/A

Copyright © Huawei
In the iFC template (CSCF and HSS) of the MMTel AS, change type=mmtel_ssf_scc to
type=mmtel_scc for the SERVER parameter, that is, remove the ssf parameter.
The following are example modifications:
MOD
SIFCINF:SIFCTPLID=100,PRIORITY=4200,SERVER="sip:aspool1.voltetas.xx.chinamobile
.com\;type=mmtel_scc";
MOD
.com\;orig\;type=mmtel_scc";
MOD
MOD
MOD
SIFCINF:SIFCTPLID=100,PRIORITY=300,SERVER="sip:aspool1.voltetas.xx.chinamobile.
com\;type=mmtel_scc";
Commands before the modifications:
ADD
SIFCINF:SIFCTPLID=101,IFCNAME="VoLTE_AS_MO_INVITE",PRIORITY=2100,PART
IND=PARTIND_DEFAULT,SERVER="sip:aspool2.voltetas.sx.chinamobile.com\;orig\;type=
mmtel_ssf_scc",DEFHND=SESSION_TERMINATED,INCLUDEREGREQ=N,TRIGPT="<
TriggerPoint><ConditionTypeCNF>1</ConditionTypeCNF><SPT><ConditionNegated>0</
ConditionNegated><Group>0</Group><SessionCase>0</SessionCase></SPT><SPT><Cond
itionNegated>0</ConditionNegated><Group>0</Group><SessionCase>3</SessionCase></S
PT><SPT><ConditionNegated>0</ConditionNegated><Group>1</Group><Method>INVIT
E</Method></SPT><SPT><ConditionNegated>1</ConditionNegated><Group>2</Group><
SIPHeader><Header>P-Access-Network-
Info</Header><Content>.*3POC.*</Content></SIPHeader></SPT></TriggerPoint>";
2.11.3 Calls Between VoBB and VoLTE Subscribers Fail

Involved NE: SBC
Defect Details
Symptom Calls between VoLTE subscribers and IMS fixed-line subscribers fail. Two
types of symptoms occur:
Symptom 1:
 When Samsung S6, Huawei Mate 7, or iPhone 6 on the VoLTE network
initiates a call to an IMS fixed-line phone, the call fails without any
announcement. Trace signaling messages on the CSCF. It is found that a
488 message is returned.
 Calls from some of Huawei Mate 7 phones to IMS fixed-line phones fall
back to 2/3G networks and then are connected. Trace signaling

Copyright © Huawei
messages on the CSCF. It is found that a 488 message is returned.
Symptom 2
 When M821 on the VoLTE network initiates a call to a VoBB IMS fixed-
line phone, the call is connected without any audio.
 When a VoBB IMS fixed-line phone initiates a call to a VoLTE
subscriber, the call is connected with one-way audio (that is, the fixed-
line phone can hear the voice but the mobile phone cannot).
Trouble N/A
Ticket
Number
Root Cause 1. During voice call interworking between VoLTE and VoIP/VoBB
subscribers, the signaling messages sent by the IMS network to the
fixed-line subscriber contain extra SDP parameters that are irrelevant to
the fixed-line network, including LTE codecs and bandwidth. In
addition, the LTE codecs is placed in the most front, which indicates
that fixed-line subscribers preferentially use LTE codecs. However, this
signaling format causes the PON on the fixed-line network to fail in
parsing SDP information. Consequently, the call fails.
2. The following example illustrates that Huawei PON fails:
1. When a VoLTE subscriber initiates a call, the first 10 VoLTE codecs
in the SDP information of the INVITE message sent by the IMS
network is irrelevant to fixed-line devices and exceed a maximum of
eight codecs that can be processed by the MxU. As a result, the MxU
returns a 488 message, causing the call to fail.
2. Some of devices of earlier versions do not support the b=AS field.
When a VoLTE subscriber initiates a call, the IMS network sends
irrelevant bandwidth parameters (b=AS:38b=RS:0b=RR:0) to fixed-line
devices, causing one-way audio or no audio.

Copyright © Huawei
Condition  The SDP information of the INVITE message sent by the IMS network
contains more than eight codecs.
 The IMS network sends irrelevant bandwidth parameters
(b=AS:38b=RS:0b=RR:0) to fixed-line devices.
of
Occurrence
Involved Version
SE2600 V200R009C30SPH111
Solution
Workarounds:
N/A
Configure the SBC on the fixed-line network side to remove the codes and SDP parameters
(including "a=" line parameters) unsupported by the fixed-line network before sending
messages to the GPON.
2.11.4 Subscribers Attached to SBCs of Another Vendors Cannot

Make or Receive Calls After PROTOCOLPARA6 Bit1 Is Set to 1
Involved NE: SBC
Defect Details

Copyright © Huawei
Symptom PROTOCOLPARA6 bit1 is set to 1 to resolve the pre-normalization

problem with the ATS when subscribers are roaming in an area where Bell
SBC is deployed. However, after this setting, subscribers attached to ZTE
SBC cannot make or receive calls.
Trouble N/A
Ticket
Number
Root Cause The reason why subscribers attached to ZTE SBC cannot receive calls is
that in the P-Access-Network-Info header field of the PRACK message
sent by the S-CSCF, ue-ip contains an additional pair of square brackets
([]). The reason why subscribers attached to ZTE SBC cannot make calls is
that the P-Access-Network-Info header field of the 183 message sent by the
S-CSCF to the SBC is incorrect.
The following is the example information sent to the SBC:
domain=sbc.0317.he.chinamobile.com";ue-
ip=[[2409:8801:8140:1df:1:1:b272:b26f]];"ue-port=5082".
Condition The P-Access-Network-Info header field of the 183 message sent by the S-
CSCF to the SBC is incorrect.
of
Occurrence
Involved Version
Solution
Workarounds:
Run the following parameter to modify the software parameter:
MOD SFP: INSPN=PROTOCOLPARA6, MODTYPE=P1, BIT=1, BITVAL=0;
N/A
2.11.5 eSRVCC Handover Requests May Be Forwarded to the I-

CSCF When the SE2900 Releases CPU Resources Due to an
Internal Interruption
Involved NE: SBC
Troubleshooting Engineer: Zhao Feng (ID: 00186785)
Defect Details
Symptom An eSRVCC handover occurs when a VoLTE subscriber is in the alerting

state. There is a possibility that the eSRVCC handover fails. As a result, an

Copyright © Huawei
abnormality announcement, for example, the "number unallocated"

announcement, is played.
Trouble N/A
Ticket
Number
Root Cause The SE2900 receives a handover INVITE message and then sends it to the
I-CSCF. The I-CSCF returns a 404 message. The SE2900 forwards the 404
message to the eMSC server, causing a handover failure.
When the SE2900 updates DRT data on the SDB module, CPU resource
release is interrupted, and consequently there is a low probability that CPU
resources are preempted by other modules and DRT data is wrongly
modified. When DRT data fails to be queried later, the eSRVCC handover
fails. Note that common calls do not experience this issue.
Condition An eSRVCC handover occurs when a VoLTE subscriber is in the alerting
state.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100 and SE2900 V300R001C20SPH111
Solution
Workarounds:
On the I-CSCF, add the following configurations:
ADD
IPSI:SUBDN="njsccas10bhw.sccas.js.ims.mnc000.mcc460.3gppnetwork.org",ASADDR="sip
:10.189.100.22";
ADD
IPSI:SUBDN="njsccas11bhw.sccas.js.ims.mnc000.mcc460.3gppnetwork.org",ASADDR="sip
:10.189.99.22";
Install SE2900 V300R01C20SPH117 or later.

Copyright © Huawei

2.12.1 Video Calls from M823 Terminal Subscribers to CS
Subscribers Cannot Fall Back to Voice Calls
Involved NE: MGCF
Troubleshooting Engineer: Su Wei (ID: 00266878)
Defect Details
Symptom When a subscriber uses an M823 terminal to initial a video call to a CS

subscriber, the video call cannot fall back to a voice call. Consequently, the
video call is automatically released.
Trouble N/A
Ticket
Number
Root Cause Theoretically, the MGCF must perform fallback for video calls from
VoLTE subscribers to CS subscribers. That is, when the MGCF detects that
the SDP body of an INVITE message carries the video indicator, it must set
the video port to 0 and perform a voice call connection in the CS domain.
The message traced on the live network show that the MGCF releases the
call with a 400 message upon receiving an INVITE message from the
M823 terminal.
The message log analysis shows that the MGCF encounters an error when
parsing the "m=fmtp" line of the video SDP body.
SIPAPP_SDP_GetVideoFmtpH264Params():SDP H264 param Type(0)
invalid, MediaIndex = 1, AttrIndex = 1, ulParamIndex = 2. file:
sipsnc.c_12708.
The following is an example of the "m=fmtp" line that is sent by the M823

Copyright © Huawei
terminal but fails to be parsed by the MGCF:

a=fmtp:113 profile-level-id=42C01E;packetization-mode=1;sar-
understood=16;sar-supported=1;sprop-parameter-
sets=Z0KAHtoHgUaAbQoTUA==,aM4G8g==
However, the MGCF can parse the following "m=fmtp" line to perform
video fallback:
a=fmtp:120 profile-level-id=42C01E;packetization-mode=0;sprop-
parameter-sets=Z0LAHtoHgUZA,aM4G4g==
The comparison shows that the MGCF encounters an error when parsing
the following parameters in the "m=fmtp" line:
sar-understood=16;sar-supported=1;
Currently, the MGCF returns an error and releases the call when it does not
recognize SDP parameters.
Condition The MGCF receives unrecognized SDP parameters.
of
Occurrence
Involved Version
MGCF V200R010C020SPC100
Solution
Workarounds:
Use the SIP-I International Adaptation feature to remove the SDP parameters of an incoming
INVITE message that cannot be recognized by the MGCF.
Load the V200R010C020SPH113 patch.
After the loading, the MGCF can continue the call regardless of unrecognized SDP
parameters.
2.12.2 Quick Signal Attenuation Causes eSRVCC Handovers to

Fail
Involved NE: eNodeB
Defect Details
Symptom eSRVCC handovers fail in elevators.

Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause On the UE side:

At 14:19:07.140, the UE reported the inter-RAT measurement event A2.
At 14:19:07.174, the UE issued B1 measurement control.
At 14:19:09.940, the service area degraded to -131 after 2.8s.
Before the B1 measurement report was submitted, the call was dropped due
to network disconnection.
According to the previous test result and handover preparation time, it
takes about 8s to complete the handover. In addition, it is found that the
network coverage was -90dbm at 14:19:04.970 and an inter-frequency
handover occurred at 14:19:06.007. This quick signal attenuation causes
the handover to fail in the elevator.
Condition The signal attenuates quickly.

of
Occurrence
Involved Version

Copyright © Huawei
All versions of the eNodeB

Solution
Workarounds:
N/A
N/A
To ensure the successful SRVCC handover in this scenario, the network coverage must be
changed to -90dbm for the inter-RAT measurement event A2 of the PCI138 and the inter-
frequency handover must be prevented. This is impractical.
2.12.3 Incorrect Route Configuration for the Gx Interface on the P-

GW Causes a Failure in Establishing Dedicated Bearers for Calls
Between VoLTE Subscribers
Involved NE: PGW
Defect Details
Symptom When a VoLTE subscriber calls another VoLTE subscriber, the LDRA does
not distribute AAR messages, causing a failure in establishing a bearer for
the calling party.
Trouble N/A
Ticket
Number
Root Cause When an IMS APN bearer is established, the LDRAs route Gx-interface
signaling messages of the P-GW to any of intra-province PCRFs in a pool
in load sharing mode.
When a VoLTE subscriber uses voice services, the SBCs route Rx-interface
signaling messages to any LDRA in load sharing mode. Then, the LDRA
routes the Rx-interface signaling messages to the PCRF that is responsible
for establishing an IMS APN bearer for the subscriber.
Therefore, the session binding function must be configured on the LDRA
for the Gx and RX interfaces. That is, after the LDRA routes Gx-interface
signaling messages to a certain PCRF in a pool, it records the binding
between the subscriber's IP address and the PCRF address. When the
LDRA receives Rx-interface signaling messages from the SBC, it uses the
subscriber's IP address in the messages to query the binding record locally
and forwards the messages to the corresponding PRCF.

Copyright © Huawei
As the routing data configured on the P-GW is incorrect and the P-GW
directly routes subscriber registration messages to the PCRF without
traversing the LDRA, the LDRA does not store the session binding
information. When the LDRA fails to query the session binding
information, it discards AAR messages that fail to be routed. Consequently,
a bearer cannot be established for the calling party.
Condition The routing data configured on the P-GW is incorrect.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Configure global routing data for the P-GW to directly contact the LDRA, which then
performs session binding.

Copyright © Huawei
2.12.4 Calls Initiated by 4G Subscribers to the VoLTE Test Card

Fall Back to the 2G Network as Anchoring Data Is Not
Configured for the Card
Involved NE: HSS
Defect Details
Symptom The customer has prepared a VoLTE test card (15768144308).

When a VoLTE subscriber initiates a call to the VoLTE test card, the call is
connected successfully. However, when a 2G or 4G subscriber on the live
network initiates a call to the VoLTE test card, the call falls back to the 2G
network through circuit switched fallback (CSFB).
Trouble N/A
Ticket
Number
Root Cause Trace the messages on the IMS network for the called party. It is found that
the terminating S-CSCF and VoLTE AS do not receive any messages. This
indicates that the anchoring service is not triggered for the called party.
Instead, the call is directly routed to the MSC server for the called party.
Then, the MSC server performs combined paging to trigger the CSFB
procedure that enables call fallback to the 2G network.

Copyright © Huawei
The reason is that anchoring data (T-CSI, ServiceKey, and SCF Address) is
not configured on the HSS for the VoLTE test card.
Condition Anchoring data (T-CSI, ServiceKey, and SCF Address) is not configured on
the HSS for the VoLTE test card.
of
Occurrence
Involved Version
N/A
Solution
Workarounds:
N/A
Configure anchoring data (T-CSI, ServiceKey, and SCF Address) on the HSS for the VoLTE
test card.
The HSS is an Ericsson device.

Copyright © Huawei
2.12.5 Calls Fail When Diameter Route Data Is Not Configured for
the Rx Interface of the SBC
Involved NE: SBC
Defect Details
Symptom VoLTE voice calls occasionally fail.

Trace signaling messages on the originating side. It is found that the
originating SBC, after receiving an INVITE message from the calling
terminal, returns a CANCEL message to the calling terminal, indicating
that the media bearer is lost. Then, trace signaling messages on the
terminating side. It is found that the terminating SBC, after receiving a 183
message from the S-CSCF, returns a CANCEL message to the S-CSCF and
sends a 503 message ("Service Unavailable") to the called terminal,
indicating that the media bearer is lost.
Trouble N/A
Ticket
Number
Root Cause The message tracing result shows that the SBC fails to send an AAR
message to the PCRF, causing a failure in reserving resources.
Consequently, the calling party does not receive a 183 message from the
SBC before a timeout occurs and therefore the calling party sends a
CANCEL message to release the call.

Copyright © Huawei
Check data configuration on the SBC. It is found that Diameter routes from
the SBC to PCRF are not configured.
Condition Diameter routes from the SBC to PCRF are not configured.
of
Occurrence
Involved Version
All SE2900 versions
Solution
Workarounds:
N/A
On the SBC, run ADD DIAMRT to add Rx interface-specific routes from the SBC to PCRF.
2.12.6 There Is a Long Delay in Establishing Calls

Involved NE: MME
Defect Details
Symptom When a call is addressed to a 4G subscriber, there is a long delay in paging

the 4G subscriber, resulting in the calling party sending multiple INVITE
messages that carry the same CallID. After the paging is successful, the
called party receives these INVITE messages and returns multiple 100
(Trying) messages.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause To improve the LTE paging success rate of the live network in Guangzhou
City, enable accurate addressing on the MME. Accurate addressing means
addressing first from the last eNodeB and then from the track area (TA) list.
After accurate addressing is enabled, the delay in establishing some calls
will be prolonged.
Condition Accurate addressing is enabled.
of
Occurrence
Involved Version
All USN9810 versions
Solution
Workarounds:
N/A
Disable accurate addressing for the VoLTE network.
After accurate addressing is disabled, the delay in establishing calls will be reduced by 300
milliseconds.
2.12.7 When an X2-based Handover Is Performed in a Call, the

EPC Does Not Send an QCI-1 Bearer Establishment Request,
Causing an Access Failure
Involved NE: SGW
Defect Details
Symptom When an X2-based handover is performed in a call, the EPC does not send
an QCI-1 bearer establishment request, causing an access failure. The
details are as follows: When a QCI-1 bearer fails to be established on the
originating side, the TQOS timer of the calling terminal will expire,
causing the calling terminal to release the call with a CANCEL message;
when a QCI-1 bearer fails to be established on the terminating side, the
TQOS timer of the called terminal will expire, causing the called terminal
to release the call with a 580 message.
Trouble N/A
Ticket

Copyright © Huawei
Number
Root Cause 1. Signaling analysis on the terminal side: Trace SIP messages on the
calling terminal. It is found that the calling terminal sends a CANCEL
message eight seconds after receiving a 200 (to PRACK) message. During
this process, the calling terminal does not send an UPDATE message. This
indicates that the calling terminal does not receive a QCI-1 bearer
establishment request.
2. Signaling analysis on the eNodeB side: The eNodeB does not receive the
QCI1 establishment message from the MME on the EPC network.
Therefore, it does not issue a command to instruct the terminal to establish
a QCI1 bearer.
3. Signaling analysis on the SBC side: The SBC sends an AAR message to
the PCRF and receives the AAA message from it. This indicates that the
AAA/AAR message exchange is successful.
4. Signaling analysis on the SAEGWP-GW side: The terminal initiated a
VoLTE call at 16:40:42 and performed an X2 handover at 16:40:43. Almost
at 16:40:43, the PCRF sent an RAR message to instruct the SAEGWP-GW
to establish the dedicated QCI=-1 bearer. Almost at 16:40:43, the SAEGW
returned an RAA (cause code = 4002) to the PCRF.
It is concluded that X2-based handover conflicts with dedicated bearer
establishment. It is because the SAEGW does not send a QCI-1 bearer
establishment request that the call fails to be connected.
Condition X2-based handover conflicts with dedicated bearer establishment.
of
Occurrence
Involved Version
Ericsson SAEGW
Solution
Workarounds:
N/A
The corresponding 3GPP protocol stipulates how the MME should behave when the eNodeB
is performing an X2-based handover, but not how the S-GW behave in this scenario. It is
recommended that the S-GW do the same as the MME in this scenario.
It is recommended Ericsson SAEGW continue to send a Create Bearer Request to the MME
for implementing VoLTE services because it can increase the call connection rate.
If this issue occurs, Huawei SAEGW does not consider the terminal unstable because the
handover is complete for the terminal. Therefore, Huawei SAE can continue to send a QCI-1
bearer establishment request to ensure the call connection.

Copyright © Huawei
2.12.8 When a Call Is Addressed to a Subscriber Who Has Just

Registered, the Network Returns a 403 Message
Involved NE: UE
Defect Details
Symptom When a call is addressed to a subscriber who has just registered, the
network returns a 403 message. The call failure cause is "User is busy".
When a call is attempted to the subscriber again, the network still returns a
403 message.
Trouble N/A
Ticket
Number
Root Cause 1. Shortly after the calling party sent an INVITE message at 13:32:28.924,
an RRC connection and default bearer were established. At 13:32:30.265,
the network received a 100 (Trying) message and then a 403 (to INVITE)
message to the calling party, indicating that the called party was busy. The
calling party then sent a CANCEL message to release the call.
2. When the calling party initiated the call, the called party had just
registered with the IMS network.
3. At 13:33:21.282, the calling party sent an INVITE message again.
However, the network still returned a 403 message to the calling party,
indicating that the called party was busy.
As the first CANCEL message sent by the calling party carries SDP
information as opposed to RFC 6337/3312, IMS resources are not released
properly. When the calling party initiates a call again, the network still
returns a 403 message to deny the call.
The following are excerpts from RFC 6337/3312:
If a UAC generates an initial INVITE without an offer and receives an
offer in a 1xx or 2xx response which is not acceptable, it SHOULD
respond to this offer with a correctly formed answer and immediately send
a CANCEL or a BYE.
580 (Precondition Failure) responses and BYE and CANCEL requests,
indicating failure to meet certain preconditions, SHOULD contain an SDP
description, indicating which desired status triggered the failure. Note that
this SDP description is not an offer or an answer, since it does not lead to
the establishment of a session.
The format of such a description is based on the last SDP (an offer or an
answer) received from the remote UA.
Condition The CANCEL message sent by the calling terminal carries SDP
information.
of
Occurrence

Copyright © Huawei
Involved Version
N/A
Solution
Workarounds:
N/A
1. Configure the SBC to delete SDP information from the CANCEL message. The final
solution is to urge terminal engineers to resolve the terminal defect.
2. Install the ATS9900 V300R001C20SPC109 patch to delete SDP information from the
CANCEL message.
2.12.9 eSRVCC Handovers Fail Due to Registration Errors

Involved NE: ATS/DNS
Defect Details
Symptom When a call is addressed to a Shenzhen subscriber roaming in Guangzhou,

an eSRVCC handover may occasionally fail with an announcement. The
details are as follows: The terminal shows that the subscriber has switched
to the GSM network. However, an announcement is immediately played
stating that the STN-SR does not exist, and then the call is automatically
released.
Trouble N/A
Ticket
Number
Root Cause Trace signaling messages on the ATCF. It is found that the ATCF does not
receive an INVITE message (for handover) from the eMSC server. Trace
signaling messages on the MME. It is found that the PS_TO_CS_Handover
message sent by the MME carries the STN-SR (8613445248). However,
the STN-SR is the number defined on the HSS but number analysis data is
not configured for the STN-SR. When the eMSC server fails to analyze the
STN-SR, it instructs the end office to play an announcement stating that the
SNR-SR does not exist.

Copyright © Huawei
The STN-SRs of the SBC in Guangzhou are 13445236, 13445237,

13445238, and 13445239. When a Shenzhen subscriber is roaming to
Guangzhou, the SCC AS must send a PUR message to update the STN-SR
on the HSS upon subscriber reregistration. Trace signaling messages on the
SCC AS. It is found that the SCC AS does not actually send a PUR
message to update the STN-SR upon subscriber registration. Consequently,
the HSS does not send an IDR message to instruct the MME to update the
STN-SR. During an eSRVCC handover, the MME carries the incorrect
STN-SR to the eMSC server, resulting in the handover failure
announcement.
The reason why the SCC AS does not send a PUR message is that no
MESSAGE message is sent to the SBC after subscriber registration.
The reason why no MESSAGE message is sent to the SBC is that the
ATCF domain name fails to be obtained through DNS query. Check data
configuration on the DNS in Guangzhou and it is found that gzatcf1bhw gd
ims mnc000 mcc460 3gppnetwork org is incorrect, causing the DNS query
failure.
Condition Data configuration on the DNS is incorrect.

of

Copyright © Huawei
Occurrence
Involved Version
N/A
Solution
Workarounds:
N/A
On the DNS, modify SRV query data for the ATCF.
2.12.10 Calls Fail to Be Answered After aSRVCC Handovers Are

Performed for VoLTE Subscribers Who Have Subscribed to the
CRBT Service and Are Being Alerted of Incoming Calls
Involved NE: eMSC
Defect Details
Symptom The call fails to be answered after an aSRVCC handover is performed for a
VoLTE subscriber (in Shenzhen) who has subscribed to the CRBT service
and is being alerted of an incoming call. The eMSC server returns a 488
message.
Trouble N/A
Ticket
Number
Root Cause After a handover is completed, the terminal answers the call by returning a
200 message. The CRBT AS needs to update SDP information. The SCC
AS sends an INVITE message to the eMSC server through the SBC,
instructing the eMSC server to update SDP information. The INVITE
message carries the codecs as shown in the following figure.
However, the eMSC server returns a 488 message carrying "Incompatible
media format".

Copyright © Huawei
The reason is that the INVITE message carries AMR rate set 7 but the
eMSC server supports only AMR rate set 1.
Condition The codecs supported by the SCC AS and eMSC server are different.
of
Occurrence
Involved Version
MSOFTX3000 V200R010C10SPC100
Solution
Workarounds:
N/A
Modify data configuration on the eMSC server.
That is, set the inter-office codec to UMTS-AMR2(set 7).
2.12.11 ZTE Terminal Users Who Have Subscribed to IN Services

Encounter Call Loss
Involved NE: ATS
Defect Details
Symptom A ZTE terminal user has subscribed to an Intelligent Network (IN) service.
After the ZTC terminal user initiates a call and talks with the called party
for three minutes and six seconds, the call is automatically released.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause The call flow is as follows:
After the call is answered, the SCP AS sends an OPTIONS message to the
ZTE terminal every three minutes. The ZTE terminal (using the MKT chip)
includes SDP information in a 200 (to OPTIONS) message but the SCC AS
does not transparently transmit the message. Consequently, the MMTel AS
sends a 408 message, resulting in the SCP AS releasing the call.
Currently, when the 200 (to OPTIONS) message carries SDP information,
the SCC AS fails to match the message with the Offer/Answer model and
therefore discards it.
According to RFC 3261, the 200 (to OPTIONS) message returned by the
ZTE terminal is allowed to carry SDP information.
RFC 3261
A message body MAY be sent, the type of which is determined by the
Accept header field in the OPTIONS request (application/sdp is the default
if the Accept header field is not present). If the types include one that can
describe media capabilities, the UAS SHOULD include a body in the
response for that purpose. Details on the construction of such a body in the
case of application/sdp are described in [13].
According to RFC 3264, SDP information does not affect the offer/answer
negotiation unless the port number is 0.
An SDP constructed to indicate media capabilities is structured as follows:
It MUST be a valid SDP, except that it MAY omit both "e=" and "p=" lines.
The "t=" line MUST be equal to "0 0". For each media type supported by
the agent, there MUST be a corresponding media description of that type.

Copyright © Huawei
The session ID in the origin field MUST be unique for each SDP
constructed to indicate media capabilities. The port MUST be set to zero,
but the connection address is arbitrary. The usage of port zero makes sure
that an SDP formatted for capabilities does not cause media streams to be
established if it is interpreted as an offer or answer.
The preceding analysis shows that the issue is caused by the fact that the
SCC AS incorrectly processes the SDP information in the 200 (to
OPTIONS) message.
Condition ZTE terminal users has subscribed to IN services.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
Workarounds:
N/A
Install the V100R006C10SPH218 patch.
2.12.12 eSRVCC Handovers Fail When Calls Addressed to

Roaming Subscribers Are in the Alerting State
Involved NE: AS
Defect Details
Symptom A subscriber in Hunan Province is roaming in Jiangsu Province. When one

call addressed to the subscriber is in the alerting state, an eSRVCC
handover may fail.
Trouble N/A
Ticket
Number
Root Cause Three eSRVCC handover tests have been performed, but only one eSRVCC
handover is successful.
Messages Traced for the First Failed eSRVCC Handover
1. Messages traced on the SBC

Copyright © Huawei
2. Messages traced on the eMSC server
Messages Traced for the Successful eSRVCC Handover

1. Messages traced on the SBC
2. Messages traced on the eMSC server
Message flow for the failed eSRVCC handover:
Message flow for the successful eSRVCC handover:

Copyright © Huawei
According to 3GPP 24237, the SCC AS sends an INFO message only

after receiving a PRACK (to 183) message.
The following are excerpts from 3GPP 24237:
Session transfer for incoming call is in alerting phase using PS to
CS SRVCC procedure: PS to CS
In the example flow at the figure A.17.2-1, SC UE A has an incoming
session with speech media component which is anchored at SCC AS.
The session is in alerting phase. Based upon measurement reports sent
from the UE to E-UTRAN, the source E-UTRAN decides to trigger a
PS to CS SRVCC handover to CS access.

Copyright © Huawei
This issue is caused by incorrect actions performed by the SCC AS

(ZTE device) that serves the roaming subscriber.
Condition The AS performs an eSRVCC handover for one call addressed to a roaming
subscriber that is in the alerting state.
of
Occurrence
Involved Version
N/A

Copyright © Huawei
Solution
Workarounds:
N/A
ZTE needs to rectify the SCC AS to resolve this issue.
2.12.13 Mid-Call Handover Fails for Calls Made by Dialing the

Short Number
Involved NE: eMSC
Defect Details
Symptom A calls C by dialing the short number. After the call is answered, A places
the call on hold and calls B. The call is answered by B. A triggers an
eSRVCC handover. The call between A and B can be handed over but the
call between A and C cannot.
Trouble N/A
Ticket
Number
Root Cause The following figure shows the correct mid-call handover procedure:

Copyright © Huawei
Different from the correct mid-call handover procedure, the eMSC server
does not send an INVITE message as in step 28 after receiving a REFER
message and returning a 202 message.
When the eMSC server receives the REFER message pertaining to the
second call, it tries to analyze the called number in the Refer-To header
field. As number analysis data is not configured for the called number that
is a short number, analyzing the called number fails and the handover flow
is terminated. The following figure shows the incorrect handover
procedure:

Copyright © Huawei
To resolve this issue, configure the eMSC server to select a route based on
the ATCF URI in the Refer-To header field rather than analyzing the called
number.
Condition A mid-call handover occurs for calls made by dialing the short number.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
2.12.14 After an eSRVCC Handover Is Performed for an Alerting

Call but the Calling Party Hangs Up Before the Called Party
Answers the Handed-Over Call, the Call Cannot Be Released on
the Terminating Side
Defect Details
Symptom eSRVCC handover test result: After an alerting call is handed over but the
calling party hangs up before the called party answers the handed-over call,

Copyright © Huawei
the call cannot be released on the terminating side. The message tracing
result of the SCC AS shows that the SCC AS returns a 487 message to the
originating side and a 480 (Reason: Q.850;cause=66;text="channel type not
implemented") message to the ATCF after receiving a CANCEL message
from the originating side.
The feedback from NSN engineers for the eMSC server (SRVCC IWF)
shows that the SCC AS (Huawei) must send a CANCEL or BYE message
to stop the alerting tone after the eMSC server (NSN) returns a 480
message.
Trouble 5443542
Ticket
Number
Root Cause The message tracing result shows that the SCC AS initiates a handover
request to the eMSC server (as indicated in line 151) and receives a 183
message (as indicated in line 177). At this time, the called party is being
alerted of an incoming call.
Later, the SCC AS receives a 503 message from the PSBC side. The
original call is released, and the handover is successful. After nine seconds,
the calling party sends a CANCEL message (as indicated in line 239).
Then, the SCC AS converts the CANCEL message to a 480 message (as
indicated in line 280) and sends the 480 message to instruct the eMSC
server to release the handed-over call.
The reason why the SCC AS converts the CANCEL message to a 480
message is as follows:
The SCC AS receives an INVITE message from the eMSC server and
returns a 183 message to the eMSC server. To terminate the INVITE
transaction, the SCC AS must return a final response to the eMSC server.
However, as the calling party releases the call, the final response can only
be Oxx or 480.
The CANCEL message is used to cancel the previous request. As the SCC
AS itself receives an INVITE message from the eMSC server, it cannot

Copyright © Huawei
send a CANCEL message to instruct the eMSC server to cancel the

INVITE request. The only thing that the SCC AS can do is to return an Oxx
message.
In addition, as the SCC AS has not sent a 200 (to INVITE) message to the
eMSC server, it cannot release the call with a BYE message. There is a
problem with the eMSC server when it does not stop the alerting tone for
the called party upon receiving a 480 message. Therefore, ask NSN to
resolve this problem.
Condition An eSRVCC handover is performed for an alerting call but the calling party
hangs up before the called party answers the handed-over call.
of
Occurrence
Involved Version
ATS9900 V100R010C10SPH213
Solution
Workarounds:
N/A
Ask NSN to rectify the eMSC server.
2.12.15 Calls Are Released When the LIA Message Returned by

Bell DRA Contains Error Code 5012
Defect Details
Symptom After the I-CSCF receives an INVITE message from the AS, it sends an
LIR message to Bell DRA. After eight seconds, the I-CSCF has not
received an LIA message, causing the I-CSCF to release the call with a 488
message.
Although the feedback from Bell engineers shows that Bell DRA has sent
an LIA message to the I-CSCF, Huawei finds that the I-CSCF has not
received the LIA message.
Trouble N/A
Ticket
Number
Root Cause Trace Diameter messages on the CSCF. It is found that the CSCF has
received an LIA message half a second after it sends an LIR message to

Copyright © Huawei
Bell DRA.
However, the subscriber messages traced on the CSCF show that the I-
CSCF has sent an LIR message and encountered a timeout after eight
seconds.
If the LIA message can be traced through Diameter message tracing but not
through subscriber message tracing (service layer tracing), the Diameter
protocol layer may encounter an error. Enable the debug tracing on the
CSCF. The following information is displayed:
M0161P192F03S08M 2015-11-26 16:13:03
ERR [a/source/Sig/DiamRM/src/diameterlm.c FileID(770) : 5260
<DiamDebugSend>]
Diameter Stack Debug:Error Information[DiamRmValidateRsp, 3594]E-Bit
set in the answer message.ResultCodeType = 5ResultCodeValue = 5012
It is found that E-Bit (indicated in error) is set to TRUE in the case of
ResultCodetype=5012.
According to RFC 3588, E-Bit can be set to TRUE only when the error
code falls within the range 3001 to 3010. That is, E-Bit cannot be set to
TRUE when the error code is 5012.
7.1.3 Protocol Errors
Errors that fall within the Protocol Error category SHOULD be treated on a
per-hop basis, and Diameter proxies MAY attempt to correct the error, if it
is possible. Note that these and only these errors MUST only be used in

Copyright © Huawei
answer messages whose 'E' bit is set.

DIAMETER_COMMAND_UNSUPPORTED3001
The Request contained a Command-Code that the receiver did not
recognize or support. This MUST be used when a Diameter node receives
an experimental command that it does not understand.
Therefore, this issue is related to the HSS.
Condition Error code 5012 is returned when the I-CSCF sends an LIR message to the
HSS of another vendor.
of
Occurrence
Involved Version
CSC3300 V100R010C10SPH210
Solution
Workarounds:
N/A
Ask the corresponding vendor to rectify the HSS.
2.12.16 Inband Digit Collection Fails for Calls from VoLTE

Subscribers to the 114 Service Platform When the P-Early-Media
Header Field Value in the 183 Message Sent by MGCF Is
sendonly
Defect Details
Symptom When a VoLTE subscriber in Shanxi Province initiates a call to the 114
service platform, the platform returns a 183 message and plays an
announcement. However, when the subscriber follows the announcement to
press the key 1, 2, or 3, no response is returned. The messages traced on the
MGCF show that the UMG does not send a NOTIFY message to report
DTMF signals.
The subscriber can initiate a call to the 10086 service platform. The
message flow is different from that for calls made to the 114 service
platform. The details are as follows: The 10086 service platform returns a
200 message. After the subscriber presses keys, responses are returned. The
MGCF can receive the NOTFIY message and send the APM message (out-
of-band message).

Copyright © Huawei
Trouble 5346500
Ticket
Number
Root Cause The message tracing result shows that when the subscriber initiates a call to
the 114 service platform, the terminating side returns a 183 message to the
subscriber and immediately plays an announcement to instruct the
subscriber to press keys. This is inband digit collection during the session
establishment.
Trace subscriber messages on the SBC. It is found that the subscriber
presses keys on the terminals after the MGCF returns a 183 message. It is
also found that the MGCF sends media packets to the terminal but the
terminal does not send media packets to the MGCF. This indicates that the
terminal does not send the media streams related to pressed keys to the
MGCF.
Trace signaling messages on the MGCF. It is found that the SDP body of
the 183 (to INVITE) message sent by the MGCF carries a=rtpmap:102
telephone-event/8000, which indicates that DTMF digit collection is
supported. Then, check the 183 message used for playing an
announcement. It is found that the P-Early-Media header field value is
sendonly.
According to 3GPP 34.229, when the P-Early-Media header field value is

sendonly or sendrevc, another DTMF signaling messages will be generated
and the most recently received P-Early-Media header field will be used.
That is, if the P-Early-Media header field value is sendonly, the terminal
does not implement inband digit collection through DTMF.
If the UE supports the P-Early-Media header field as defined in
IETFRFC5009, and a P-Early-Media header field has been received, then
the UE shall send any available user generated media, e.g. speech or
DTMF, on media stream(s) associated with the early dialog for which the
most recent P-Early-Media header field, as described in IETFRFC5009,
contained a "sendrecv" or a "recvonly" header field value. If there is more
than one such early dialog, the UE shall use the early dialog where the P-
Early-Media header field was most recently received.
Therefore, this issue is caused by the inband 183 message sent by the
MGCF. To resolve this issue, run MOD SIPTG on the MSOFTX3000 to

Copyright © Huawei
set ESFPARA7 to FUNC15-0.

When the MSOFTX3000 includes the P-Early-Media header field in a 18x
message, this header field is set to sendrecv by default. If this header field
is set to sendonly, run the following example command on the
MSOFTX3000:
MOD SIPTG: TGN="XXX", ESFPARA7= FUNC15-0;
Condition 1. Inband digit collection occurs before session establishment.
2. FUNC15 is enabled for ESFPARA7 by running MOD SIPTG on the
MSOFTX3000.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Run MOD SIPTG on the MSOFTX3000 to set ESFPARA7 to FUNC15-0.
MOD SIPTG: TGN="XXX", ESFPARA7= FUNC15-0;
2.12.17 Announcements Fail for Video Calls Addressed to

Powered-Off Phones
Involved NE: MRFC
Defect Details
Symptom When a video call is made to a powered-off phone, the MRFC returns a
500 message after the MMTEL AS sends an INVITE message to request
the MRFC to play an announcement.

Copyright © Huawei
Trouble 5489225
Ticket
Number
Root Cause The error information Cro response pb fail,Bc=27(1625) is typically
generated due to a license restriction. Check H.248 messages between the
MRFC and MRFP. It is found that the following information is displayed.
This indicates that there is no H.264 license. The DSP LICENSERES

command output of the MRFP does not contain the H.264 license.
However, the video call contains the H.264 codec.
Condition There is no H.264 license.

of
Occurrence
Involved Version
All MRFC versions
Solution
Workarounds:
N/A
As there are no video resources involved for the MRFP to play announcements, run MOD
MRFPRES on the MRFC to delete all video capabilities of the MRFP.

Copyright © Huawei
MOD MRFPRES: MRFPNAME="MAR_MRFP", VCODEC=H261-0&H263-0&H264-

0&MPEG4-0;
Application Limitation: On the live network, the MRFC does not interwork with the convergent
conference system of the MediaX (that is, there is no VOBB&VoLTE& convergent conferencing
scenario). Therefore, the video license is not required.
2.12.18 404 Message Is Returned When an iPhone Registers

Involved NE: SBC
Defect Details
Symptom During the iPhone access test, when the SCC AS includes the C-MSISTN
and ATU-STI in the MESSAGE message sent to the ATCF, the SBC returns
a 404 message, indicating that the corresponding subscriber data record
cannot be found.
Trouble N/A
Ticket
Number
Root Cause Trace messages on the live network. It is found that this issue occurs when
the iPhone, after completing an eSRVCC handover and releasing the
handed-over call, returns from the IMS to CS domain for registration. The
following are the message flows for the successful and failed registrations:
Message Flow for the Successful Registration

Copyright © Huawei
The key descriptions are as follows:

1. The iPhone uses Address-A to initiate a call, completes an eSRVCC
handover, and then releases the call in the CS domain. (The call lasts about
10 seconds.)
2. The iPhone returns to the VoLTE domain from the CS domain and uses
Address-B to register. The IMS Core needs to remove the binding between
the iPhone subscriber and Address-A, that is, to initiate the corresponding
deregistration flow. (The blue part in the preceding figure shows the
deregistration flow.)
3. The S-CSCF receives a REGISTER message after returning a 401
message. Then, the S-CSCF sends two NOTIFY messages to the SBC, one
for the terminal to subscribe to the subscriber status, and the other for the
SBC to subscribe to the subscriber status. The SBC can quickly return a
response for its subscription to the subscriber status. However, the SBC
cannot receive a response for the subscription sent by the terminal through
Address-A. Consequently, the SBC transmits the NOTIFY message
repeatedly.
4. The S-CSCF sends a REGISTER message to the SCC AS for the
deregistration initiated using Address-A. At the same time, the S-CSCF
also sends a REGISTER message to the SCC AS for the registration
initiated using Address-B. Then, the S-CSCF sends a 200 (to REGISTER)
message to the SBC.
5. When the SCC AS first receives the REGISTER message for the
deregistration initiated using Address-A, it removes the subscriber
information.

Copyright © Huawei
6. When the SCC AS then receives the REGISTER message for the
registration initiated using Address-B, it exchanges messages with the HSS
to obtain the subscriber information. This operation takes several seconds.
After this operation, the SCC AS sends a MESSAGE message to the ATCF
to update the C-MSISDN and STU-STI.
7. The SBC receives a 200 (to REGISTER) message and creates the
corresponding subscriber data record. If the received MESSAGE message
can match the created subscriber data record and the subscriber's C-
MSISDN and STU-STI can be successfully inserted, it returns a 200 (to
MESSAGE) message.
Message Flow for the Failed eSRVCC Handover
The first four steps are similar to those in the message flow for the
successful eSRVCC handover.
1. The iPhone uses Address-A to initiate a call, completes an eSRVCC
handover, and then releases the call in the CS domain. (The call lasts about
10 seconds.)
2. The iPhone returns to the VoLTE domain from the CS domain and uses
Address-B to register. The IMS Core needs to remove the binding between
the iPhone subscriber and Address-A, that is, to initiate the corresponding
deregistration flow. (The blue part in the preceding figure shows the
deregistration flow.)

Copyright © Huawei
3. The S-CSCF receives a REGISTER message after returning a 401

message. Then, the S-CSCF sends two NOTIFY messages to the SBC, one
for the terminal to subscribe to the subscriber status, and the other for the
SBC to subscribe to the subscriber status. The SBC can quickly return a
response for its subscription to the subscriber status. However, the SBC
cannot receive a response for the subscription sent by the terminal through
Address-A. Consequently, the SBC transmits the NOTIFY message
repeatedly.
4. The S-CSCF sends a REGISTER message to the SCC AS for the
deregistration initiated using Address-A. At the same time, the S-CSCF
also sends a REGISTER message to the SCC AS for the registration
initiated using Address-B. Then, the S-CSCF sends a 200 (to REGISTER)
message to the SBC.
The main differences are as follows:
When the S-CSCF performs a third-party registration, it first sends a
REGISTER message for the deregistration initiated using Address-A and
then sends a REGISTER message for the registration initiated using
Address-B. The two REGSITER messages are sent by the S-CSCF almost
at the same time.
As SIP message are UDP-based, the UDP protocol cannot ensure the
sequence in which messages are transmitted. Therefore, the SCC AS may
first receive a REGISTER message for the registration initiated using
Address-B and then receives a REGISTER message for the deregistration
using Address-A.
1. If the SCC AS first receives a REGISTER message for the registration
initiated using Address-A, it uses the subscriber's IMPU to query the
subscriber data. When the SCC AS finds the subscriber data and the
registration part contains expire=3600, the SCC AS determines that the
reregistration flow is initiated. In the reregistration flow, the SCC AS does
not need to interact with the HSS to obtain any data. Instead, it sends a
MESSAGE message that contains the C-MSISDN and ATU-STI to the
ATCF.
2. The 200 (to REGISTER) message is sent by the S-CSCF to the SBC
through the I-CSCF, but the MESSAGE message is directly sent by the
SCC AS to the SBC. Therefore, the SBC may receive the 200 (to
REGISTER) and MESSAGE messages almost at the same time or may first
receive the MESSAGE message and then the 200 (to REGISTER)
message. This causes the SBC to encounter a defect. That is, the SBC
cannot use the C-MSISDN in the MESSAGE message to query the
subscriber data, resulting in the SBC returning a 404 message.
3. When the SCC AS receives a REGISTER message for the registration
initiated using Address-B and then a REGISTER message for the
deregistration initiated using Address-A, the subscriber data on the SCC AS
is not affected. That is, when the SCC AS determines that Address-A used
for the deregistration does not match Address-B bound with the subscriber,
it does not modify the subscriber data locally.
Note that the registration flows of the iPhones and Huawei Mate 7 phones
vary as follows:
1. After an eSRVCC handover, the iPhone performs re-attachment,
modifies the local IP address, and then registers when returning from the
CS to VoLTE domain.

Copyright © Huawei
2. After an eSRVCC handover, Huawei Mate 7 phone still uses the original
IP address for registration when returning from the CS to VoLTE domain.
Condition The iPhone registers after an eSRVCC handover.
of
Occurrence
Involved Version
SE2900 V300R001C02
Solution
Workarounds:
N/A
2.12.19 During a Mid-Call Handover, the REFER Message Cannot

Be Sent
Involved NE: ATS
Troubleshooting:
Defect Details
Symptom During a mid-call handover, as the number in the P-Asserted-Identity

header field for the call from C to A is not a global one, the REFER
message cannot be sent.
Trouble N/A
Ticket
Number
Root Cause 1. When C in a call calls A, A is alerting and an eSRVCC handover is
performed for the alerting call. The number in the P-Asserted-Identity
header field for the call from C to A is not a global one.

Copyright © Huawei
2. During the eSRVCC handover, the SCC AS constructs a REFER

message after receiving a 200 (to the handover INVITE message) and ACK
message. When constructing the REFER message, the SCC AS sets the
From header field to the value of the P-Asserted-Identity header field in the
initial INVITE message.
3. When the SCC AS fails to obtain the calling number prefixed with the
plus sign (+), it normalizes the calling number by querying the local DN
set. However, as the SCC AS does not store the data from the MMTel AS,
the normalization fails. Consequently, the REFER message cannot be sent,
causing the eSRVCC handover failure.
Condition During a mid-call handover, the number of the P-Asserted-Identity header
field is not a global one.
Probability This issue occurs when the preceding condition is met.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC100
Solution
Workarounds:
N/A

2.13.1 When a Registered UE Initiates a Subscription to the
Subscriber Status, the NOTIFY Message Returned by the S-CSCF
Carries "terminated;reason=noresource"

Copyright © Huawei

Defect Details
Symptom When a registered UE initiates a subscription to the subscriber status, the

NOTIFY message returned by the S-CSCF carries
"terminated;reason=noresource".
Trouble N/A
Ticket
Number
Root Cause 1. Check the traced subscriber messages. It is found that this issue is
caused by the fact that the S-CSCF fails to query subscriber data.
Theoretically, after a UE registers, the S-CSCF stores the corresponding
subscriber data (see the following figure).
2. Analyze why the S-CSCF fails to query the subscriber data. The
analysis result shows that the S-CSCF with which the UE has registered
is not the S-CSCF to which the UE has initiated a subscription to the
subscriber status. Consequently, the latter S-CSCF cannot query the
subscriber data locally.
Address of the S-CSCF with which the UE has registered:
Address of the S-CSCF to which the UE has initiated a subscription to

the subscriber status:
3. Analyze why the SBC sends the SUBSCRIBE message to the incorrect
S-CSCF. The data configuration submitted by field engineers shows that
the SBC uses an embedded DNS for managing mappings between

Copyright © Huawei
domain names and IP addresses. Due to the data configuration on the

DNS, the SBC sends the SUBSCRIBE message to the incorrect S-
CSCF.
4. Correct the data configuration on the SBC. It is found that this issue is
resolved.
Condition  A registered UE sends a subscription to the subscriber status.
 The DNS data configuration for the P-CSCF is inconsistent with that for
the I-CSCF.
of
Occurrence
Involved Version
CSC3300 V100R011C10SPC100
Solution
Workarounds:
N/A
Correct the DNS data on the SBC to enable the SBC to map S-CSCF host names to the
corresponding S-CSCF IP addresses.
2.13.2 After the S-CSCF Fails to Contact an AS, It Does Not

Continue to Contact Another AS
Defect Details
Symptom When the S-CSCF contacts an AS, the AS returns a 598 message. Then, the
S-CSCF does not continue to contact another AS.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause STASFPLCY data on the S-CSCF determines whether the S-CSCF denies
the call or continues to process the call based on iFC data when it fails to
contact an AS. If STASFPLCY data is not configured, the S-CSCF by
default denies the call when it fails to contact an AS.
This issue is caused by lack of STASFPLCY data.

In addition, note the following:
In STASFPLCY data, Policy must be set to CHKDFHAND(Check
default handling). The value of Default handling in the iFC data is also
used to determine whether the S-CSCF continues the call.
As the protocol stack does not forward some special failures (for example,
481) to the service layer, the S-CSCF directly releases the corresponding
calls. Therefore, STASFPLCY data does not take effect for such special
failures.
By default, STASFPLCY data takes effect for the following failures: 408,
500, 501, 502, 504, 505, 513, 533, and 580.
Condition STASFPLCY data is not configured on the S-CSCF.
of
Occurrence
Involved Version
CSC3300 V100R011C10SPC100
Solution
Workarounds:
N/A
Configure the corresponding STASFPLCY data on the S-CSCF.
2.13.3 After an eSRVCC Handover, the MGCF Fails to Send ICS

Registrations Due to "Authentication Failure"

Copyright © Huawei
Defect Details
Symptom After an UE hands over from the LTE to CS network, the MGCF fails to
proxy ICS registrations for the UE due to an authentication failure.
Trouble N/A
Ticket
Number
Root Cause It is found that the REGISTER message sent by the MGCF has carried
integrity-projected="auth-done" and TDMI data on the S-CSCF shows
that the S-CSCF allows registration in auth-done mode.
Theoretically, when the S-CSCF receives the REGISTER message from the
MGCF, it determines that CS authentication has been performed and IMS
authentication is not required. However, the message tracing result shows
that the S-CSCF still sends an MAR message. This is because the S-CSCF
does not trust auth-done carried in the REGISTER message sent by the
MGCF.
The analysis of TDMI data submitted by field engineers shows that the
following two TDMI data records conflict:
ADD TDMI: ADDRT=IPADDRESS, IPSEG="10.145.34.120",
MASK="255.255.0.0", ALLOWAUTHDONE=N;
ADD TDMI: ADDRT=IPADDRESS, IPSEG="10.145.34.62",
MASK="255.255.0.0", ALLOWAUTHDONE=Y;
After the S-CSCF matches the first TDMI data record, it does not trust
auth-done carried in the REGISTER message sent by the MGCF and
therefore sends an MAR message to request authentication. This causes an
authentication failure.
Condition TMDI data on the S-CSCF is incorrect.
Probability This issue always occurs.
of
Occurrence
Involved Version
CSC3300 V100R011C10SPC100
Solution
Workarounds:
N/A
Correct TDMI data on the S-CSCF.
MOD TDMI: ADDRT=IPADDRESS, IPSEG="10.145.34.120", MASK="255.255.0.0",
ALLOWAUTHDONE=Y;

Copyright © Huawei
2.13.4 RCS Client Receives "Unsupported media type" When

Sending MESSAGE Messages
Defect Details
Symptom When an RCS client sends a MESSAGE message, the CSCF returns a 415
message carrying "Unsupported media type".
Trouble N/A
Ticket
Number
Root Cause 1. When an RCS client sends a MESSAGE message, the CSCF returns a
415 message carrying "Unsupported media type" (see the following figure).
This is because that the CSCF does not support the content in the
MESSAGE message sent by the RCS client.
2. However, due to privacy protection, the content cannot be viewed in the

subscriber message tracing result. Therefore, contact field engineers to
trace IP messages.
3. The IP message tracing result (CGP IP messages can be converted to
CAP messages) shows that the MESSAGE message carries the following
media types:

Copyright © Huawei
4. It is found that SMSG data has been modified on the customer side
(SMSG data before modification can support all media types). This issue
can be resolved after SMSG data is corrected.
Condition SMSG data on the S-CSCF is incorrect.
of
Occurrence
Involved Version
CSC3300 V100R011C10SPC100
Solution
Workarounds:
N/A
Configure SMSG data.
ADD SMSG: MEDT=APPLICATION, MEDST=ALL, MSGLEN=1500;
2.13.5 During a Mid-Call eSRVCC Handover (with One Held

Session and One Active Session), the BYE Message Sent by the
SCC AS Carries "channel type not implemented"
Defect Details
Symptom During a mid-call eSRVCC handover, the SCC AS sends a BYE message to
release the call.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause 1. In the normal handover flow, after the SCC AS returns a 200 (to
INVITE) message, it needs to send a REFER message instructing the
eMSC server to perform media negotiation for the second call.
2. The Refer-To header field in the REFER message needs to contain

session information (call-id, from-tag, and to-tag) and SDP information.
However, as SDP information exceeds 1024 bytes, the SCC AS fails to
construct a REFER message.
Condition The SDP information carried for the held session exceeds 1024 bytes.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC210
Solution
Workarounds:
N/A

Copyright © Huawei
ATS9900 V100R006C10SPH212 has been developed to resolve this issue.
2.13.6 Incorrect Access Network Information in the CDRs

Generated in VoWiFi Handover Scenarios Results in a Failure in
Sorting Out VoWiFi and VoLTE CDRs
Defect Details
Symptom Incorrect access network information in the CDRs generated in VoWiFi

handover scenarios results in a failure in sorting out VoWiFi and VoLTE
CDRs.
Trouble 4956699
Ticket
Number
Root Cause 1. After the UE hands over from the VoLTE to VoWiFi network and
releases the call, Access-Network-Information in the VoWiFi CDRs is
still set to 3GPP-E-UTRAN-FDD;utran-cell.
2. When the CCF consolidates ACRs, it obtains pAccessNetworkinfo from
the first ACR message and fills the information in the pAccessNetworkinfo
field. If the CCF receives such an ACR message during a handover between
VoLTE and VoWiFi networks, the CCF starts ACR consolidation.
3. The ATS is configured to first send an ACR [Start] message and then an
ACR [Interim]message at an interval of three minutes. The access network
information in the ACR [Start] message is the same as that in the ACR
[Interim] message. This may cause the CCF to fill incorrect access network
information during ACR consolidation. Due to the incorrect access network
information, the billing center cannot sort out VoLTE and VoWiFi CDRs.
4. The detailed analysis is as follows:
4.1 The calling party (A) registers with IMS over LTE.
4.2 A calls B. After the call is connected, the ATS sends an ACR [Start]
message to the CCF.
4.3 Media renegotiation is performed, and an ACR [Interim] message is

sent to the CCF.

Copyright © Huawei
4.4 A handover to VoWiFi is performed, and an ACR [Interim] message is

sent to the CCF.
1. After three minutes, another ACR [Interim] message is sent to the CCF.
1. After the call ends, an ACR [Stop] message is sent to the CCF.
In this way, the ACR consolidation for steps 4.1 and 4.2 is correct but the
access network information in the ACR consolidation for steps 4.3 and 4.4

Copyright © Huawei
is incorrect.
Condition A handover is performed between the VoWiFi and VoLTE networks.
of
Occurrence
Involved Version
ATS9900 V100R008C10 TR5
Solution
Workarounds:
N/A
This issue has been resolved in ATS9900 V100R008C10 TR6.
2.13.7 Media Collision Occurs in "CS CFB + Precondition"

Scenarios
Defect Details
Symptom Media collision occurs in "CS CFB + precondition" scenarios.

Trouble 4884748
Ticket
Number
Root Cause The test scenario is as follows:
1. VoLTE subscribers A, B, C, and D belong to the same home network. A
and B are attached to the 2/3G network.
2. B has subscribed to the CFB service with C as the forwarded-to party. A
and C are idle. A call is established between B and D.
3. A calls B.
4. The call from A is forwarded to C.
The message flow is as follows:

Copyright © Huawei
Condition The preceding test scenario occurs.

of
Occurrence
Involved Version
Solution
Workarounds:
N/A
The following figure shows the description of bit 8 of P1510:

Copyright © Huawei
2.13.8 Calling Parties Cannot Hear the Ring Back Tone When
Calls to CRBT Subscribers Are Forwarded Upon No Reply
Involved NE: ATS
Troubleshooting Engineer: Wu Dai (ID: 00146329)
Defect Details
Symptom A, B, and C are VoLTE subscribers. B has subscribed to the Customized

Ring Back Tone Control and Trigger (CRBT) service and Call Forwarding
No Reply (CFNR) service. C is under VoLTE coverage. When a call from A
to B is forwarded to C upon no reply, A cannot hear the ring back tone from
C. However, if C is in the CS domain, A can hear the ring back tone from
C.
Trouble N/A
Ticket
Number
Root Cause The call scenario is as follows:
B has subscribed to the CRBT service. The following figure shows the
networking diagram where B is alerted:

Copyright © Huawei
As shown in the figure, A hears the CBRT announcement through inband

signaling. This is because the PEM indicator in the 180 message sent by the
CRBT platform is set to sendrecv.
The following figure shows the networking diagram where a 180 message
is returned when the forwarded-to subscriber is under VoLTE coverage:

Copyright © Huawei
The 180 message does not carry any PEM indicator. According to the
relevant protocol, the calling mobile phone takes the PEM indicator
received last time. However, as the inband signaling for the CRBT
announcement has been released, the CRBT announcement cannot be
played.
The following figure shows the networking diagram where C is in the CS
domain:
The MGCF converts the ACM message to a 180 message whose PEM
indicator is inactive. When the mobile phone receives this indicator, it
switches to the local mode for playing the ring back tone.

Copyright © Huawei
The following are excerpts from relevant protocols:

3GPP TS 24.628:
The UE shall not generate the locally generated communication progress
information if an early dialog exists where the last received P-Early-Media
header field as described in IETF RFC 5009 [12] contains "sendrecv" or
"sendonly".
RFC 5009:
After an early media authorization request has been received within a
dialogue, and a subsequent message is received without the P-Early-Media
header field, the previous early media authorization remains unchanged.
3GPP TS 24.229:
NOTE 7: If the UE supports the P-Early-Media header field and if the most
recently received P-Early-Media header field within the dialog includes a
parameter applicable to media stream with value "inactive", then based on
local configuration, the UE will provide an indication that the invited user
is being alerted and stop presenting received early media to the user if
requested by any previous receipt of P-Early-Media header field within the
dialog.
To sum up, this issue is caused by the fact that the MMTel AS processes the
180 message incorrectly.
Condition The "call forwarding + CRBT" scenario occurs.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
Workarounds:
N/A
ATS SPH215 has been developed to resolve this issue. Specifically, P3302 is used to resolve
this issue.
Subsequent patches will be developed to resolve all the issues related to the "call forwarding
+ CRBT" scenario.
To resolve the issue that occurs when B is in the CS domain, use P2311 and P3302.
To resolve the issue that occurs when B is in the IMS domain, use P2311.
The following is the description of P2311:
P2311 is used for function control.
P2311 is used to determine whether the ATS includes the P-Early-Media header field whose
PEM indicator is inactive in an outgoing 180 message in the following scenarios:

Copyright © Huawei
 The called terminal is in the LTE network, and the 180 message sent by the called
terminal does not carry any SDP information or the P-Early-Media header field.
 In non-forking scenarios, the ATS that serves the One Number or Virtual PBX subscriber
sends a 180 message to the calling party.
P2311 applies only in FMC networks.
Default value: 0
= 0: The ATS does not include the P-Early-Media header field whose PEM indicator is
inactive in an outgoing 180 message.
= 1: The ATS includes the P-Early-Media header field whose PEM indicator is inactive in an
outgoing 180 message.
2.13.9 CRBT Service Fails When the Time Between the UPDATE
Message and 200 (to UPDATE) Message Is Too Short
Involved NE: ATS
Defect Details
Symptom The CRBT service fails when the time between the UPDATE message and
200 (to UPDATE) message is too short.
Trouble N/A
Ticket
Number
Root Cause 1. First trace messages on the MMTel AS for the forwarding party.
2. Check whether an UPDATE message has been retransmitted many
times.
3. Find the time when the UPDATE message was first received and check
whether a 200 message has been received in the same direction at the
same time. It is found that a 200 message has been received in the same
direction at the same time and the 200 message has been transparently
transmitted but the UPDATE has not.
This is because a large number of UPDATE messages are generated in the
precondition flow when the CRBT service platform is involved.
Condition The "call forwarding + CRBT" scenario occurs.
of
Occurrence

Copyright © Huawei
Involved Version
ATS9900 V100R006C10SPC200
Solution
Workarounds:
N/A
A patch will be developed by the end of November 2015 to resolve this issue.
2.13.10 DNS Query Fails When the SRV Record for a Host Name
on the DNS Exceeds 512 Bytes and DNS Links Configured on the
CSCF Work in UDP Mode
Defect Details
Symptom When mobile subscribers in City Chongqing are roaming in City Ningxia,
DNS query fails. Specifically, after the SRV returns a query result, the
ENUM returns NULL.
Trouble 5296561
Ticket
Number
Root Cause Check external messages. It is found that there are SRV records but these
records carry the TC parameter.

Copyright © Huawei
When the bit for the TC parameter in the response to a query request is set
to 1, only the first 512 bytes are returned if the response exceeds 512 bytes.
When the CSCF receives the TC parameter, it finds that the returned result
is incomplete. Then, the CSCFR uses the TCP mode to perform DNS
query. However, it finds that there are no TCP links because the transport
protocol type configured on the SDNSL is UDP. For details, see the
following debug logs:
ERR [a/source/Sig/ENUM/src/enumproc.c FileID(707) : 3216
<EnumStackLogprint>] RM: [eENUM_LOG_ERROR][Module 112]
[EnumQm_HandleResponseMsg:3512]:
EnumCm_TrTcpSelect()/EnumCm_TcpLinkPriSelect()failed when
received truncated response, return 0x10A04327! M0112P191F01S03M
2015-10-26 17:44:50 ERR [a/source/Sig/ENUM/src/enumproc.c
Therefore, you can infer that this issue is caused by the fact that the SRV
record for a host name on the DNS exceeds 512 bytes and DNS links
configured on the CSCF work in UDP mode. That is, the DNS query result
that exceeds 512 bytes is not supported.
Condition  The DNS query result exceeds 512 bytes.
 DNS links configured on the CSCF work in UDP mode.
of
Occurrence
Involved Version
CSCF V100R010C10SPC200
Solution

Copyright © Huawei
Workarounds: N/A
Method 1: Change the link transmission mode configured on the SDNSL from UDP to TCP.
Method 2: Compress the SRV record for a host name.
2.13.11 Calling Terminal Displays the Call Failure When a Call

from an iPhone Subscriber in the CS Domain to a VoLTE
Subscriber (IN Service Subscriber) Is Normally Released by the
VoLTE Subscriber
Troubleshooting Engineer: Su Wei (ID: 00266878
Defect Details
Symptom The calling terminal displays the call failure when a call from an iPhone
subscriber in the CS domain to a VoLTE subscriber (IN service subscriber)
is normally released by the VoLTE subscriber. The following is a snapshot
of the call failure displayed on the calling terminal:

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause Analyze the traced messages.

Copyright © Huawei
The analysis is as follows:

1. When the called terminal releases the call, it sends a BYE message that
does not carry the Reason header field.
2. When the SCP AS receives the BYE message, it includes the Reason
header field in the BYTE message. The Reason header field carries the SIP
cause value 487 and Q.850 cause value 16.
3. When the MGCF receives the BYE message that carries the Reason
header field, it preferentially converts the topmost SIP cause value 487 to
the corresponding BICC cause value 127 (Interworking, unspecified).
4. When the UE receives the cause value 127, it determines that the call
release is an abnormal one (16 normal clear) and therefore displays the
call failure.
Condition The iPhone subscriber in the CS domain calls a VoLTE subscriber (IN
service subscriber).
Probability The problem occurs when the preceding condition is met.
of
Occurrence
Involved Version
Solution
Workarounds:
Configure data on the MGCF to convert the SIP cause value 487 to the cause value 159
(normal unspecified).
ADD CVTSIPCAU: ON="officename", SRCCAU=SC487, DESCAU=CV159;
A patch will be developed to resolve this issue.

Copyright © Huawei
2.13.12 When a Subscriber in the CS Domain Calls a VoLTE

Subscriber (CRBT Subscriber), the 491 Message Is Generated
Defect Details
Symptom B is a VoLTE subscriber who has subscribed to the CRBT service. When A
in the CS domain calls B, the 491 message is generated in the signaling
message flow. However, the call can be connected.
Trouble N/A
Ticket
Number
Root Cause The 491 message is described in the relevant protocol as follows:
21.4.27 491 Request Pending
The request was received by a UAS that had a pending request within
the same dialog.
The 491 message occurs in the following scenarios:
Scenario 1:

Copyright © Huawei
When the MGCF receives an UPDATE message from the CRBT platform,
it returns a 200 message. At the same time, the MGCF sends an UPDATE
message.
The MGCF sends the 200 and UPDATE messages at the same time. That
is, the MGCF sends the UPDATE message immediately after sending the
200 message.

Copyright © Huawei
As SIP over UDP is used, the message sequence is as follows:

1. 200
2. UPDATE
Due to the transmission path, the sequence of the messages that reach the
S-CSCF may be as follows:
1. UPDATE
2. 200
When the S-CSCF that is waiting for the 200 message receives the
UPDATE message, it sends a 491 message notifying the peer end that
message collision occurs.
Scenario 2:
An error occurs on the CAT AS.

Specifically, the UPDATE message highlighted in blue is not required in

Copyright © Huawei
the CRBT service scenario. The reason why the UPDATE message is sent
is as follows:
A in the CS network calls B in the VoLTE network and the call is
forwarded to C for some reason (for example, when B does not reply or is
busy). If there is no UPDATE message for connecting the call to C, the
precondition flow for C cannot be implemented, causing a failure in
connecting the call.
The corresponding message flow is as follows:
Condition A subscriber in the CS domain calls a VoLTE subscriber who has

subscribed to the CRBT service.
Probability This issue may occur.
of
Occurrence

Copyright © Huawei
Involved Version
Solution
Workarounds:
Configure the CRBT platform in such a way that the UPDATE message sent by it does not
carry a=conf.
N/A
2.13.13 One-Way Audio Occurs in Video Calls

Involved NE: SBC
Defect Details
Symptom In City Suzhou, China, when A initiates a video call to B, A can neither
view the video of B nor hear the voice of B but B can do both.
Trouble N/A
Ticket
Number
Root Cause The analysis of signaling messages shows that the call can be connected;
the analysis of media packets generated after the call is answered shows
that SBC-2 on the originating side can receive media packets from the
calling terminal and send them to SBC-1 on the terminating side. However,
SBC-2 does not receive media packets from SBC-1.
The analysis of messages traced on SBC-1 shows that SBC-1 can receive
packets from SBC-2 and send them to the called terminal. SBC-1 can also
receive media packets from the called terminal and send them to SBC-2.
The message flow on the media plane is as follows:

Copyright © Huawei
Ping the peer IP address from SBC-1. It is found that the bearer channel
fails.
+++SE2900/*MEID:5*/2015-10-14 19:26:48+08:00
O&M#162
%%PING: SRN=0, SN=1, IPTYPE=IPV4, DIPV4="10.189.109.150",
SIPV4="10.189.103.137", VRFFLAG=Y,
VRFNAME="ChinaMobile_IMS_Media", DATATYPE=DYNAMICLEN;
%%
RETCODE = 0 Operation succeeded
The result is as follows
------------
Sent packets = 5
Received packets = 0
Packet loss ratio(%) = 100
Maximum round time(ms) = NULL
Minimum round time(ms) = NULL
Average round time(ms) = NULL
(Number of results = 1)
---END
It is found that the bearer plane IP address configuration on SBC-1 is
incorrect. That is, the peer IP address is incorrectly set to a signaling plane
IP address, resulting in the IP interworking failure. This issue is resolved
after the bearer plane IP address configuration is corrected.
Condition The bearer plane IP address configuration the SBC is incorrect.
of
Occurrence
Involved Version

Copyright © Huawei

Solution
Workarounds:
N/A
Correct the bearer plane IP address configuration on the SBC.
2.13.14 Two Announcements Play When Subscribers Attached to

Ericsson VMSC Server Call VoLTE Subscribers Who Are Busy
Defect Details
Symptom When a CS subscriber attached to Ericsson VMSC server calls a VoLTE

subscriber who is busy, the busy tone plays. However, after the busy tone
finishes playing, the CS subscriber hears an announcement stating that the
subscriber you have dialed cannot be connected for the moment.
Trouble N/A
Ticket
Number
Root Cause Perform the message flow analysis.
1. In the normal message flow, when the IMS returns the SIP cause value
487, the MGCF converts the cause value to 31 and then sends an REL
message carrying the cause value 31.
2. In the abnormal message flow, when the IMS returns the SIP cause value
487, the MGCF converts the cause value to 127 and then sends an REL
message carrying the cause value 127.

Copyright © Huawei
You can doubt that the VMSC server plays an announcement for the cause
value 127. Perform a test on Ericsson VMSC server Huawei VMSC server.
Compare the test results and it is found that this doubt can be confirmed.
Then comes the next question: What is the cause value conversion
mechanism of the MGCF? The cause value conversion mechanism of the
MGCF is as follows:
First, the MGCF parses the Reason header filed in the SIP message.
The Reason header field can contain multiple cause values, which are
classified into SIP and Q.850 causes values. SIP and Q.850 cause values
are separated by coma (,).
The MGCF preferentially obtains the first cause value.
If the first cause value is a Q.850 value greater than 127, the MGCF
discards it and obtains the next one.
If the first cause value is a SIP cause value, the MGCF converts the cause
value to another value using the configured mapping between SIP status
codes and cause values. Alternatively, when the SIPSL sends an REL
message to the CCB, it queries the data configured by running ADD
CVTSIPCAU to perform this conversion.
In the normal message flow, the Reason header field is as follows:
Reason: Q.850;cause=31;text="normal",SIP;cause=487
In the abnormal message flow, the Reason header field is as follows:
Reason: SIP;cause=487,Q.850;cause=31

Copyright © Huawei
According to the Reason header field value selection mechanism, the

MGCF selects 31 in the normal message flow and 487 in the abnormal
message flow.
Perform further analysis for the abnormal message flow. It is found that the
called party is an IN service subscriber and an MT IN service is triggered.
When the MT IN service is triggered, the ATS generates a 487 message but
the SCP AS modifies the Reason header field of the message.
This issue is caused by this modification. The following figure shows that
the 487 message sent to the SCP AS carries the correct the Reason header
field:
However, the SCP AS changes the Reason header field in the 487 message.
This issue is caused by the fact that the SCP AS changes the sequence of
cause values in the Reason header field. This issue will be resolved in

Copyright © Huawei
subsequent versions.
Condition A subscriber attached to Ericsson VMSC server calls a VoLTE subscriber
who is busy.
Probability The problem occurs when the preceding condition is met.
of
Occurrence
Involved Version
Solution
Workarounds:
Configure data on the MGCF to convert the SIP cause value 487 to the cause value 159
(normal unspecified).
ADD CVTSIPCAU: ON="officename", SRCCAU=SC487, DESCAU=CV159;
2.13.15 When Huawei IMS Interworks with Bell SBC, the TAS
Cannot Obtain the sbc-domain Field from the P-Access-Network-
Info Header Field
Involved NE: ATS
Troubleshooting Engineer: zhang Minchao (ID: 00290970)
Defect Details
Symptom An interoperability test is performed between Huawei IMS and Bell SBC.
The details are as follows: A is a VoLTE subscriber whose area code is
0772. When A is roaming in the 4G network in another location (with the
area code 0771) in the same province and initiates a call to a PSTN number
in the home location without dialing the area code, the system plays an
announcement stating that the number you have dialed is invalid.
Trouble N/A
Ticket
Number
Root Cause The traced messages show that the TAS incorrectly performs number
normalization. That is, it normalizes the PSTN number to a global number
prefixed with 86772. The internal logs show that the TAS fails to obtain the
sbc-domain field from the P-Access-Network-Info header field. This is
because the ATS cannot recognize the sub-domain sent by Bell SBC that is
not enclosed with quotation marks.
The sbc-domain, ue-ip, and ue-port in the P-Access-Network-Info header

Copyright © Huawei
field sent by Bell SBC are not enclosed with quotation marks.
A software parameter is used to determine whether the sbc-domain, ue-ip,
and ue-port in the P-Access-Network-Info header field sent by the SE2900
are enclosed with quotation marks.
The ATS supports only the following P-Access-Network-Info header field:

P-Access-Network-Info:3GPP-E-UTRAN-FDD;utran-cell-id-
3gpp=4600800154601;"sbc-
domain=sbc1.010.bj.chinamobile.com";network-provided
That is, the ATS can process only "sbc-
domain=sbc1.010.bj.chinamobile.com".
Condition The sub-domain is not enclosed with quotation marks.
of
Occurrence
Involved Version
All versions of the ATS
Solution
Workarounds:
N/A
2.13.16 ATS Sends PUR Messages to Obtain Transparent Data

from the HSS for Unregistered Subscribers
Involved NE: ATS
Defect Details
Symptom When the ATS sends a PUR message to obtain transparent data from the

Copyright © Huawei
HSS for the unregistered subscriber during a call, the call fails.
Trouble N/A
Ticket
Number
Root Cause When the CSCF routes a call from a VoLTE subscriber to the TAS, the TAS
returns "query adb failed". When you run LST MSR, the system displays
that the VoLTE subscriber does not exist (subscriber data sent through the
UDA message is incomplete). When you run ADD MSR, the system
displays that the VoLTE subscriber exists (The HSS returns the error code
5105 to the PUR message).
1. When the subscriber initiates a registration before being defined on the
ATS, the MMTel AS cannot obtain subscriber data, causing the registration
to fail. However, as the SCC AS does not need to obtain subscriber data,
the registration is successful.
2. When the subscriber is defined on the TAS, the MMTel AS sends a PUR
message to push TAS-UPDATE-DATA with SequenceNumber set to 0.
However, as the SCC AS has pushed TAS-UPDATE-DATA during the
subscriber registration, SequenceNumber must be set to 1.
Condition A subscriber has registered with the ATS before being defined on the ATS.
of
Occurrence
Involved Version
ATS9900 V100R006C10
Solution
Workarounds:
Delete transparent data from the HSS.
ATS SPH218 has been developed to resolve this issue.
2.13.17 Initial Registrations from VoLTE Subscribers Fail

Involved NE: CSCF
Defect Details
Symptom On the live VoBB network, nationwide VoLTE capabilities have been added
on the I-CSCF. Consequently, when a VoBB subscriber from a province
registers, the S-CSCF for another province is selected.
Trouble N/A

Copyright © Huawei
Ticket
Number
Root Cause When a VoBB subscriber is defined at a site, the I-CSCF randomly selects
one of S-CSCFs with the same priority based on ISCAP data if it has not
been configured with nationwide S-CSCF capabilities. However, if
nationwide VoLTE capabilities have been configured with the same priority
as the S-CSCF for the subscriber's province, the I-CSCF will select one S-
CSCF outside the subscriber's province when the subscriber sends an initial
registration. Consequently, the initial registration fails.
Condition Nationwide VoLTE capabilities have been configured on the I-CSCF.
of
Occurrence
Involved Version
CSC3300 V100R010C10
Solution
Workarounds:
N/A
1. On the HSS Management page of the SPG2800 web portal, run LST HMOCAP to check
whether national VoLTE capabilities have been configured for some sample VoBB
subscribers.
2. If national VoLTE capabilities have not been configured for VoBB subscribers, do not
configure national VoLTE capabilities on the I-CSCF on the VoBB network or lower the
priorities of newly added S-CSCF capabilities.
3. Add VoLTE capabilities after VoBB sites are enhanced to support S-CSCF capability-based
subscriber definition.
2.13.18 Codec Sequence Is Incorrect for SBC Calls and eSRVCC

Handovers
Involved NE: SBC
Troubleshooting Engineers: Liang Chenjie (ID: 00138148)
Defect Details
Symptom The codec sequence is incorrect for SBC calls and eSRVCC handovers.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause When a VoLTE subscriber calls a VoBB subscriber, the call path is IMS-
UGC-UMG-PRA. The codecs carried by an incoming SIP message do not
overlap with the codecs (including G.729, G.711, and AMR2) configured
by running ADD MGW. The UGC obtains the first eight codecs from the
received codecs. The common call failure scenario is as follows: The SBC
carries more than eight codecs to the MGCF, and the first eight codecs do
not contain G.711 or AMR2. As the UGC and MGCF support a maximum
of eight codecs and AMR2 and G.711 are generally configured on them, the
codecs carried by the UGC or MGCF do not overlap with those carried by
the SBC.
Condition The SBC carries more than eight codecs to the MGCF, and the first eight
codecs do not contain G.711 and AMR2.
of
Occurrence
Involved Version
SE2900 V300R001C20
Solution
Workarounds:
N/A
The SBC uses the TC function to adjust the sequence of the codecs carried by it. That is, the
SBC places G711 and AMR2 12.2K in the front.
1. Delete the duplicate AMR WB and NB codecs.
2. When the VoLTE subscriber resides in the EMSC server after a handover, the SBC sends
AMR2 to the EMSC server as the first codec.
a. Run the following command to add a bearer control policy data record:
ADD
BCPLC:BCPLCNAME="AMR_SORT",QOSSAMPLERATE=50,SINGLEWAYCHK=N,EN
TYPE=ABCF,LPCHECKP1=CHECKMEDIATYPE-0&CHECKBANDWIDTH-
0&CHECKCODE-0&CODESORT-0&AMRSORT-0,
LPCHECKP2=CHECKMEDIATYPE-0&CHECKBANDWIDTH-0&CHECKCODE-
0&CODESORT-0&AMRSORT-0,LPCHECKP3=CHECKMEDIATYPE-
0&CHECKBANDWIDTH-0&CHECKCODE-0&CODESORT-1&AMRSORT-0,
LPCHECKP4=CHECKMEDIATYPE-0&CHECKBANDWIDTH-0&CHECKCODE-
0&CODESORT-0&AMRSORT-0,FBDMT=AUDIO-0&VIDEO-0&APPLICATION-
0&DATA-0&CONTROL-0&IMAGE-0&MESSAGE-0&TEXT-0&OTHER-0,
MCFPL=REJECT_WITH_488RSP,MEDIADETECT=Y,TMLINE=Y,NBWCTL=N,VIDEOB
WREDRATE=0,MODIFYPATH=Y,SYNTCPLINK=N,RFC2198ENABLE=N,MBM=DISAB
LE,PORTOBTAINMODE=M_line,PTTRANS=N,MEDIASMOOTH=N,

Copyright © Huawei
HOLDRTCPMODE=Y,ANS=OTHER,RR=2000,RS=600,CHKCNPPORT=N,CONVIDEO=
N;
b. Add the codec sequencing function to place AMR in the first position.
Note: After an eSRVCC handover, AMR2 must be located before all the other codecs sent by
the SBC to the eMSC server. The SBC originally placed AMRWB in the first position, and the
eMSC server supports only AMR2 12.5k. Therefore, to resolve this issue, the SBC needs to
place ARM2 in the first position.
ADD
CODECINF:CINAME="AMR",ENTYPE=ABCF,BCPLCNAME="AMR_SORT",DMT=BO
TH,MEDT=AUDIO,CODN="AMR",CLOCR=8000,CN=ANY,ALLOW=Y,PRIO=0;
c. Modify the SIP AN data record for the ATCF. That is, change the value of BCPLCNAME
to the newly added BCPLC.
MOD SIPAN: ANNAME="ATCF_SIPAN", LETYPE=ATCF,
BCPLCNAME="AMR_SORT";
2.14 Fault Cases for September 2015

2.14.1 When the eMSC Sends an INVITE Message to the I-CSCF,
the IMS Side Returns a 403 Message, Causing the Call to Fail
Troubleshooting Engineer: Zhang Zhao (ID: 00302145)
Defect Details
Symptom During a call from a CS subscriber on the CS network to a VoLTE

subscriber on the VoLTE network, after the eMSC receives the IMRN
anchoring prefix from the ATS, it fails to send an INVITE message to the I-
CSCF. Consequently, the call fails.
Trouble N/A
Ticket
Number
Root Cause According to the VoLTE signaling manual, the V/GMSC server sends an
initial detection point (IDP) message to the anchor AS to trigger the T-CSI
services for obtaining the IMRN. The anchor AS sends a Connect message
that carries the IMRN to the V/GMSC Server. The V/GMSC server
analyzes the IMRN to obtain the MGCF address and routes the call request
to the MGCF. The MGCF analyzes the IMRN to obtain the I-CSCF address
and routes the call request to the I-CSCF. When the eMSC (incorporating
the functions of the VMSC, MGCF, and eSRVCC-IWF) receives the IMRN
prefix 123 from the ATS and sends an INVITE message to the I-CSCF, the
I-CSCF returns a 403 (server internal error) message to the eMSC. The
message tracing result shows that the value formats of some header fields
in the INVITE message sent by the MGCF are incorrect. That is, before the
MGCF sends an INVITE message, it must remove the MT anchoring prefix

Copyright © Huawei
to restore the called number and then normalize the called number to a
global number. Only in this way can the I-CSCF recognize the called
number and anchor the call to the IMS domain.
Condition A CS subscriber on the CS network calls a VoLTE subscriber on the VoLTE

network.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Run the following command to add an outgoing number processing data record to delete the
IMRN prefix:
ADD OUTNUMPREPRO: CSCNAME="all", TGN="SIP-TO-I-CSCF", P=0, PFX=K'123,
CIDN="INVALID", ODIDN="INVALID", CLRFT=UNKNOW, CDN="DEFAULT",
CLDFT=UNKNOW, DDN="DELETE_123", ORICLDFT=UPFXIN, RDFT=UNKNOW,
RDDN="DEFAULT", GENFT=UNKNOW, GENNCN="DEFAULT", FCCLI=NO;
2.14.2 After the IMS Core Completes Initial Registration, the 401
Message Returned by the IMS Core Cannot Be Routed to the UE
Through the SBC Side
Involved NE: SE2900
Troubleshooting Engineer: Zhang Chao (ID: 00302145)
Defect Details
Symptom After the IMS Core completes initial registration, it returns a 401

Copyright © Huawei
(unauthorized) message but the message cannot be routed by the SBC side
to the UE. Consequently, the UE fails to register.
Trouble 4748325
Ticket
Number
Root Cause As the REGISTER messages sent before and after a 401 message are the
same, you can infer that the UE has not received the 401 message. The
REGISTER message sent by the UE after the IMS Core returns a 401
message does not contain the RES that is calculated based on the shared
secret key and RAND.
Typically, the time from when the SBC sends a 401 message to the UE
until the UE sends a REGISTER message again should be in milliseconds.
In this example, the UE sends a REGISTER message again after 16
seconds. This obviously shows that the UE has not received a 401 message
from the SBC.
Therefore, check test messages on the EPC side to see whether a 401
message has been sent to the UE. In addition, check the messages traced on
the LAN switch on the SBC side to see whether the SBC has sent a 401
message.
Condition Route data on the LAN switch is incorrect.
of
Occurrence
Involved Version
SE2900 V300R001C20
Solution
Workarounds:
N/A
On the LAN switch and backbone network, configure route data about backhaul IP addresses
for the UE address pool.

Copyright © Huawei
2.14.3 As the INVITE Message Sent by the UE of a Registered

VoLTE Subscriber Fails to Traverse the P-GW, the Call Fails
Involved NE: UGW
Troubleshooting Engineer: Zhang Chao (ID: 00302145)
Defect Details
Symptom After the INVITE message sent by the UE of a registered VoLTE

subscriber fails to traverse the P-GW, the call fails.
Trouble N/A
Ticket
Number
Root Cause First check whether the UE fails to send a call request. Connect the UE to a
PC and simulate the UE to initiate multiple calls. Check the messages
traced on the UE. It is found that the INVITE message sent by the UE is
correct.
Then check whether the INVITE message sent by the UE is possibly lost
when traversing the P-GW. Analyze this possibility by checking the
messages traced on the P-GW. Lines 140-144 in the UGW message tracing
result show that the UGW has not forwarded messages to the P-CSCF on
the core side. In addition, this error is not logged on the EMS.
Perform mirroring on the access-side IP address port of the SBC and trace
messages on the SBC. It is found that the SBC has not received INVITE
message. Therefore, you can infer that the INVITE message is lost when
traversing the P-GW.
It is found from other failure cases that when the UGW IP message that
exceeds the 1500 bytes is lost, check whether the FPIC supports message
fragmentation. It is found that the UGW does not support message
fragmentation.

Copyright © Huawei
The following information shows that message fragmentation is supported:
Further analyze the traced messages. It is found that some unfragmented

messages have been forwarded and some fragmented messages have not
been forwarded. In addition, fragmented messages from other carriers have
been forwarded. Therefore, check data on the live network and it is found
that the following configuration applies:
apn ims
apn-softpara-byte 3 1
The software parameter APN_BYTE3 is described as follows:
APN_BYTE3 is used to enable or disable forwarding-plane functions for a
specific APN instance.
Bit 1:
This bit is used to determine whether the UGW9811 performs IP
fragmentation and reassembly for a specific APN instance.
 = 0: The UGW9811 performs IP fragmentation and reassembly for a
specific APN instance.
 = 1: The UGW9811 does not perform IP fragmentation and reassembly
for a specific APN instance.
After APN_BYTE3 bit 1 is set to 0, perform the same test again. It is found
that the SBC side can receive the INVITE message, the VoLTE call is
successful, and the traced signaling and media messages are correct.
Condition An alarm about IP fragmentation resource insufficiency is generated.
of
Occurrence
Involved Version
UGW V900R011C00
Solution

Copyright © Huawei
Workarounds:
Use the software parameter apn-softpara-byte to disable IP fragmentation and reassembly for
some APNs.
N/A
2.14.4 E-CSCF Function Embedded in the SE2900 Is Required for

IMS Emergency Calls
Involved NE: SE2900
Defect Details
Symptom In the current VoLTE solution, CSFB-based emergency calls are preferred.
However, after the VoWiFi introduction, the network side needs to support
IMS emergency calls made by iPhones in flight mode. The VoLTE/VoWiFi
prefers the E-CSCF/EATF function embedded in the SE2900. The
ECSCF/EATF function is license-controlled.
Note:
1. The way Samsung S6 phones accessing IMS over Wi-Fi initiate
emergency calls is different from the way iPhones initiate such calls. That
is, when Samsung S6 phones initiate such calls, the flight mode is
automatically disabled and the calls fall back to the CS network for being
connected.
2. Carriers can assign an emergency call APN or reuse the IMS APN.
3. The SBC can be configured to return a 380 message after identifying
emergency call numbers. The 380 message is used to instruct the mobile
phone to fall back to the CS network for connecting emergency calls.

Copyright © Huawei
Notes: If mobile phones in flight mode access IMS over Wi-Fi to initiate
emergency calls, the IMS emergency call solution is used. In other cases,
the CSFB solution is used regardless of the emergency call handover flow.
The PSAP is located in the CS domain. The E-CSCF first routes the
emergency call number to the MGCF and then the MGCF contacts the
PSAP. CDRs are generated for emergency calls when the E-CSCF
interworks with the CCF.
Trouble N/A
Ticket
Number
Root Cause Emergency call data is incomplete.
Condition  The call is an emergency call.
 Emergency call data is incomplete.
of
Occurrence

Copyright © Huawei
Involved Version
Solution
Workarounds:
N/A
Perform the following operations on the SBC:
1. Configure general emergency call data to enable the SBC to identify emergency calls.
ADD GEMC: ENTYPE=ABCF, ANN="ALL", ADDRT=URNSERVICE,
URN="urn:service:sos", QOSPRI=QP7;
ADD GEMC: ENTYPE=ABCF, ANN="ALL", ADDRT=TELNUM, EMCNUM="112",
QOSPRI=QP7;
Note: The URN varies depending on the corresponding value carried by the mobile phone.
Emergency call numbers also vary from country to country.
2. Configure PSAP data.
ADD EEMCC: ADDRT=URNSERVICE, URN="urn:service:sos", LIF=INVALID,
EMCCAT=TELNUM, EMCCNUM="tel:##0112";
Note: The preceding data is about routing the emergency call numbers to the MGCF. The data
must be negotiated with the MGCF.
3. Add the local E-CSCF entity.
ADD ECSCF: ECSCFLEN="ECSCFTWA1H", LRFR=Y, PTYPE=DIAMETER;
4. Configure data for the P-CSCF to contact the E-CSCF.
Configure data about the embedded DNS:
ADD DNSSRV: DOMAINNAME="_sip._udp.ecscf.ims.mncxxx.mccxxx.3gppnetwork.org",
PORT=5060, TARGET="ecscf.ims.mncxxx.mccxxx.3gppnetwork.org ";
ADD DNSRESA: NAME="ecscf.ims.mncxxx.mccxxx.3gppnetwork.org", IPTYPE=IPV4,
ADDR="xxx.xxx.xxx.xxx";
Configure dynamic route data for the P-CSCF to contact the E-CSCF:
ADD ART: RTNAME="PCSCF_ECSCF_ART", SOPLY=AUTO, SBPLY=MANUAL,
RTTYPE=DYNAMIC, DOMAIN="ecscf.ims.mncxxx.mccxxx.3gppnetwork.org ",
ISMPORT=N, LINKINFO=UDP, ADDRGN="CORE_SIG_ACNADDRG",
MEDDN="CORE_MEDIA_MEDDN", CHB=CTHB,
CHBLADDRNAME="TO_CORE_SIG", CHBLPORT=5060;
Configure an emergency call route for the P-CSCF SIP AN:
MOD SIPAN: ANNAME="xxx", LETYPE=P-CSCF, ERTNAME="PCSCF_ECSCF_ART";
5. Configure data for the E-CSCF to contact the MGCF.
Configure the SIP TG, OFC, and ART:

Copyright © Huawei
ADD ASIPTG: TGNAME="ECSCF-MGCF", LINKINFO=UDP, IPTYPE=IPV4,

PIPV4="xxx", VRFFLAG=N, CHB=CTHB, CHBLADDRNAME="ECSCF_Core",
BCPLCNAME="DEFAULTABCFBCPLC";
ADD AOFC: OFCNAME=" ECSCF-MGCF", TG1NAME=" ECSCF-MGCF ";
ADD ART: RTNAME="ECSCF_MGCF_ART", RTTYPE=STATIC, ISMPORT=N,
ADDRGN="ECSCF_ACNADDRG", MEDDN="CORE_MEDIA_MEDDN",
OFC1NAME=" ECSCF-MGCF";
Configure E-CSCF SIP AN data:
ADD SIPAN: ANNAME="access_ecscf_mgcf", LETYPE=E-CSCF,
ADDRNAME="ECSCF_Access", IPTYPE=IPV4, UEIP="xxx", UEMASK="xxx",
LAPT=5060, LCPT=5060, RTNAME="ECSCF_MGCF_ART", ECSCFLEN="ECSCF",
CMDENABLE=Y;
Note: Set UEIP to the P-CSCF core-side address segment.
6. If the E-CSCF needs to generate emergency call CDRs, configure data for the SBC to
interwork with the CCF.
MOD RFPLC: ENTITYPE=ECSCF, NFUN=ECSCF, ECCH=Y, CANCH=N,
EMCCOFCH=N, EMCCFCH=N, RUCH=N, START=Y;
2.14.5 During Subscriber Registration, the CSCF Returns a 500

Message After Receiving an SAA Message
Troubleshooting Engineer: Xu Junqi (ID: 00302795)
Defect Details
Symptom The CSCF returns a 500 message carrying the cause value "Query data
error" after receiving an SAA message.
The networking is as follows:

UE (Huawei Ascend P1) -> PCSCF (HW) -> I/SCSCF (HW) -> IMS HSS
(HP)
Trouble N/A
Ticket
Number
Root Cause The charging address AVP in the SAA message returned by the HP HSS is
incorrect. The value of the AVP must be aaa//ccf.huawei.com. As shown in
the following figure, the CSCF returns a 500 message because
dummycharging1 is carried:

Copyright © Huawei
[Protocol Reference]
The following descriptions in the 3GPP TS 29.229 are for your reference:
1.3.20 Primary-Event-Charging-Function-Name AVP
The Primary-Event-Charging-Function-Name AVP is of type DiameterURI.
This AVP contains the address of the Primary Online Charging Function.
The receiving network element shall extract the FQDN of the DiameterURI
in this AVP and may use it as content of the Destination-Host AVP for the
Diameter accounting requests. The parent domain of the FQDN in the
DiameterURI shall be used as Destination-Realm. The number of labels
used for the Destination-Realm shall be determined before the Charging
Information is provisioned and may be a configuration option.
In RFC3588, the DiameterURI format requirements are as follows:

DiameterURI The DiameterURI MUST follow the Uniform Resource
Identifiers (URI)syntax [URI] rules specified below:"aaa://" FQDN [ port ]
[ transport ] [ protocol ]; No transport security"aaas://" FQDN [ port ]
[ transport ] [ protocol ]; Transport security used FQDN = Fully Qualified
Host Name port = ":" 1*DIGIT; One of the ports used to listen for;
incoming connections.; If absent,; the default Diameter port (3868) is;
assumed.transport = ";transport=" transport-protocol; One of the transports
used to listen; for incoming connections. If absent,; the default SCTP
[SCTP] protocol is; assumed. UDP MUST NOT be used when; the aaa-
protocol field is set to; diameter.transport-protocol = ( "tcp" / "sctp" / "udp"
)protocol = ";protocol=" aaa-protocol; If absent, the default AAA protocol;
is diameter.aaa-protocol = ( "diameter" / "radius" / "tacacs+" )The
following are examples of valid Diameter host
identities:aaa://host.example.com;transport=tcp
aaa://host.example.com:6666;transport=tcp
aaa://host.example.com;protocol=diameter
aaa://host.example.com:6666;protocol=diameter
aaa://host.example.com:6666;transport=tcp;protocol=diameter
aaa://host.example.com:1813;transport=udp;protocol=radius

Copyright © Huawei
Condition The charging address AVP does not comply with the protocol.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Ask HP engineers to correct the charging address in the SAA message returned by the IMS
HSS.
2.14.6 During Service Provisioning, the PUA Message Carries

"diameter-error-user-data-not-recognized"
Troubleshooting Engineer: Yang Jianqun (ID: 00267249)
Defect Details
Symptom The PUA message carries "diameter-error-user-data-not-recognized".
Trouble N/A
Ticket
Number
Root Cause As stipulated in the protocol of the new version, dataReference in AVP
703 of the PUR message must be set to 0. However, Huawei ATS is
compatible with the old version where dataReference is set to the default
value 20 (as shown in the following figure). There is no error reported for
interworking with Huawei HSS. To interwork with the HSS of another
vendor, adaptation needs to be made based on the compatibilities of the
peer end.

Copyright © Huawei
[Protocol Reference]
Relevant contents in 3GPP TS 29.328 C30 are as follows:
Condition The compatibilities of the HSS are insufficient.

of
Occurrence
Involved Version
ATS9900 V100R006C00SPC100
Solution
Workarounds:
N/A

Copyright © Huawei
In the MML Command - ATS window of the OMU client, run the MOD SPCFG:
ALREPDATA=FALSE; command.
After this configuration, the value of dataReference in the PUR message is changed from 20
to 0.
Alias repository data download flag determines whether the Data-Reference AVP in a
request message can be set to 20(AliasesRepositoryData) when repository data needs to be
downloaded for subscribers in an alias set. 20(AliasesRepositoryData) indicates that alias
repository data needs to be downloaded from the HSS.
Value:
FALSE: The Data-Reference AVP is set to 0(RepositoryData).
TRUE: The Data-Reference AVP is set to 20(AliasesRepositoryData).
2.14.7 During Third-Party Registration, the SNA Message Carries

"diameter-error-user-data-cannot-be-notified"
Troubleshooting Engineer: Yue Peng (ID: 00148445)
Defect Details
Symptom After HP HSS receives an SNR message, it returns an SNA message that
carries "Diameter-error-user-data-cannot-be-notified".
Trouble N/A
Ticket
Number
Root Cause HP HSS returns the incorrect SNA message because it does not support the
SNR message.
Condition The HSS does not support the SNR message.
of
Occurrence
Involved Version
Solution
Workarounds:

Copyright © Huawei
The SNR message following the REGISTER message is used for subscribing to subscriber
data while downloading it. HP HSS does not support this function. To rectify this issue,
configure Huawei ATS to first send an UDR message to download subscriber data from HP
HSS and then send an SNR message to subscribe to it.
Before the configuration:
After the configuration:

HP HSS still does not support subscription to subscriber data.
N/A
2.14.8 During Third-Party Registration, Some Information in the

UDA Message Returned by the HSS Is Lost
Defect Details
Symptom The UDA message does not report error information, but shUserData in
the UDA message contains only the MSISDN. Consequently, the ATS
returns a 500 message when it receives the UDA message.

Copyright © Huawei
(HP)
Trouble N/A
Ticket
Number
Root Cause HP HSS does not allow dataReference (AVP 703) or serviceIndication
(AVP 704) in the UDR or SNR message to carry multiple values. When HP
HSS carries only the MSISDN to the ATS, the ATS returns a 500 message.
Condition HP HSS does not allow dataReference (AVP 703) or serviceIndication
(AVP 704) in the UDR or SNR message to carry multiple values.
of
Occurrence
Involved Version
ATS9900 V100R006C00SPC100
Solution
Workarounds:
MOD SPCFG: MDFLAG=FALSE;
N/A
2.14.9 During Third-Party Registration, the UDA Message Carries

"diameter-error-user-data-not-recognized"
Defect Details
Symptom The UDA message carries "diameter-error-user-data-not-recognized".

(HP)
Trouble N/A

Copyright © Huawei
Ticket
Number
Root Cause dataReference in the UDR message carries only the IMSI, but HP HSS
does not support dataReference whose value is IMSI. Consequently, an
error is reported.
Currently, HP HSS supports dataReference as follows:
Condition HP HSS does not support dataReference whose value is IMSI.

of
Occurrence
Involved Version
ATS9900 V100R006C00SPC100
Solution
Workarounds:
The IMSI is not a mandatory parameter for the VoLTE network. It is used only to test whether
HP HSS supports dataReference whose value is IMSI. Therefore, run the following
command to enable the ATS not to download the IMSI from the HSS:
MOD SPCFG: IMSIFLAG=FALSE;
MOD SPCFG
IMSI download flag Specifies whether to download the IMSI from the HSS.
When the system needs to support VoLTE subscribers or

Copyright © Huawei
ICS subscribers, set this parameter to TRUE(TRUE).

This parameter applies only in FMC networks.
Value:
FALSE(FALSE)
TRUE(TRUE)
No default value
N/A
2.14.10 SRVCCW IWF Does Not Carry the Extended Parameter

UE-History-Information to the VMSC over the Sv Interface,
Causing a Handover Failure
Troubleshooting Engineer: Zhu Sihong 00287786
Defect Details
Symptom 1. After the SRVCC IWF receives a PS-TO-CS-REQ message from the
MME, it sends an MAP-PREPARE-HANDOVER-REQ message to the
VMSC. The MAP-PREPARE-HANDOVER-REQ message encapsulates
the RELOCATION-REQUEST message that need to be sent by the VMSC
to the target RNC.
2. The VMSC returns an MAP-PREPARE-HANDOVER-CNF message to
indicate a handover failure.
The feedback from ZTE engineers shows that Source RNC to Target
RNC Transparent Container in the RELOCATION-REQUEST message
sent by the SRVCC IWF does not contain UE History Information.

UE (Huawei Ascend P1) -> eNodeB (ZTE)-> MME (ZTE) -> SRVCC IWF
(HW) -> VMSC (ZTE)-> RNC (ZTE) (the UE hands over from the
eNodeB to the RNC)
Trouble N/A
Ticket

Copyright © Huawei
Number
Root Cause As stipulated in 3GPP-25413, UE History Information in Source RNC to
Target RNC Transparent Container must be set to 0, which indicates an
optional information element (IE). That is, when the SRVCC IWF serves as
an optional IE, it does not necessarily need to be transmitted transparently.
However, as stipulated in 3GPP-36413, L2U handover is mandatory. This
means that Source RNC to Target RNC Transparent Container needs to
contain UE History Information.
Condition An alarm about IP fragmentation resource insufficiency is generated.

of
Occurrence
Involved Version
Solution
Workarounds:
N/A
A patch has been developed to rectify the SRVCC IWF.
2.14.11 When a 4G Subscriber Calls a 3G Subscriber, ZTE VMSC

Server Does Not Respond to the UP Negotiation Request from
Huawei MGCF, Causing the Call to Be Released
Involved NE: MGW
Defect Details
Symptom ZTE VMSC server does not respond to the UP negotiation request, causing

Copyright © Huawei
the call to be released.

UE (Huawei Ascend P1) -> IMS Core (HW)-> MGCF (HW) ->
MGW(HW) -> VMSC (ZTE) ->MGW(ZTE)-> RNC (ZTE)
Trouble N/A
Ticket
Number
Root Cause The messages traced on Huawei MGW show that Huawei MGW transmits
five UP negotiation requests to ZTE VMSC server but does not receive any
response, causing the call to be released.
As stipulated in the relevant protocol, the Nb interface must support UP

negotiation. However, data has been configured on both ZTE VMSC server
and Huwei MGW to determine whether the Nb interface supports UP
negotiation. The purpose of this configuration is to support application
scenarios unspecified in the relevant protocol. This issue occurs because
ZTE VMSC server is configured not to support UP negotiation.
Condition ZTE VMSC server does not respond to the UP negotiation request.
of
Occurrence
Involved Version
Solution
Workarounds:
//Use software parameter P853 to enable the working mode of the user plane to suit a specific
office direction.
MOD MSFP: ID=P853, MODTYPE=P1, BIT=11, BITVAL=0,CONFIRM=Y;
//Enable the codec specific to the required office direction to use the transparent mode.

Copyright © Huawei
ADD CODECCFG: ON="DERI_MSC", CODECID=UMTSAMR2, PAYLOADTYPE=108,

PKTIME=PKT_20, CLOCKRATE=CKR_8000,CONFIRM=Y;
After the preceding operations, trace messages on Huawei MGW. It is found that the user
plane no longer sends codec negotiation.
N/A
2.14.12 Calls from 4G Subscribers to 3G Subscribers Are Released

Due to Incompatibility of Some BICC Parameters
Involved NE: MGCF
Troubleshooting Engineer: Lin Jiamu 00142797
Defect Details
Symptom When a 4G subscriber calls a 3G subscriber, the MGCF receives an REL

message from the VMSC server. Consequently, the call is released.
UE (Huawei Ascend P1) -> IMS Core (HW)-> MGCF (HW) -> VMSC
(ZTE)-> RNC (ZTE)
Trouble N/A
Ticket
Number
Root Cause ZTE VMSC server supports the echo cancellation and satellite circuit IEs,
but BICC messages sent by Huawei MGCF to ZTE VMSC server do not
carry these IEs.
In addition, the calling number sent by Huawei MGCF needs to be
converted to an international number as required by ZTE VMSC server.
Condition ZTE VMSC server interworks with Huawei VMSC server.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
\\Run the following scripts to adapt to IEs (including the echo cancellation and satellite circuit
IEs) required by ZTE VMSC server.

Copyright © Huawei
MOD MSFP: ID=P1302, MODTYPE=P1, BIT=5, BITVAL=0;

MOD OFC: ON="DERI_MSC", BICCSENDMSK=8;
MOD IMSGMSK: AOT=BICC, SM=8, MSG=1, MV=USED, MC=YES, MM=1;
ADD IFLDVAL: SM=8, FLD=87, MSG=1, ACT=ALT, OLDV=1, NEWV=0;
ADD IFLDVAL: SM=8, FLD=89, MSG=1, ACT=ALT, OLDV=1, NEWV=0;
\\Roll back the scripts.
MOD OFC: ON="DERI_MSC", BICCSENDMSK=64;
MOD IMSGMSK: AOT=BICC, SM=8, MSG=1, MV=USED, MC=NO, MM=1;
MOD IFLDVAL: SM=8, FLD=87, MSG=1, OLDV=1, ACT=NA, NEWV=1;
RMV IFLDVAL: SM=8, FLD=87, MSG=1, OLDV=1;
MOD IFLDVAL: SM=8, FLD=89, MSG=1, OLDV=1, ACT=NA, NEWV=1;
RMV IFLDVAL: SM=8, FLD=89, MSG=1, OLDV=1;
Add an outgoing number processing data record in the OUTNUMPREPRO table to convert
the calling number to an international number.
After the preceding operations, the IEs contained in an IAM message are as follows:
2.14.13 When a Subscriber Roams from a 4G to 2/3G Network and

Then Returns to the 4G Network for Registration, a 500 Message
Is Received
Involved NE: SE2900

Copyright © Huawei

Troubleshooting Engineer: Xu Shiqin (ID: 00284743)
Defect Details
Symptom When a subscriber roams from a 4G to 2/3G network and then returns to
the 4G network for registration, a 500 message carrying "Server Internal
Error/AKA IP+Port conflict" is received.
Trouble 4841304
Ticket
Number
Root Cause For the previous registration, port-s is 6000.
For the registration (after the subscriber returns to the 4G network from the
2/3G network), port-s is 6000.
When a subscriber deregisters, 32 seconds are reserved for the SBC to

release resources. If a subscriber deregisters and then quickly re-registers,
the port-s value is the same for the previous and current registrations.
Consequently, the network returns a 500 message.
Condition A subscriber deregisters and then re-registers within 32 seconds.
of
Occurrence
Involved Version
SE2900 V300R001C10SPC100
Solution
Workarounds:
N/A
The port-s value is random. The SBC must not deny a registration whose port-s value is the
same as the previous registration. A patch has been developed to resolve this issue.

Copyright © Huawei
Patch version: V300R001C10SPH109

Original Ticket SN: DTS2015071502871
2.14.14 HTC Phones Fail to Call Marvell Phones

Involved NE: UE
Defect Details
Symptom An HTC phone calls a Marvel phone. An INVITE message is sent to the
MT side and the MT side returns a 183 message. However, the MO does
not receive the 183 message. In addition, the MT receives multiple INVITE
messages. Huawei phones can make successful calls to marvel phones.
Trouble N/A
Ticket
Number
Root Cause The subscriber messages traced on the SBC show that the HTC phone does
not receive the 100 or 183 message, causing the SBC to retransmit the
INVITE message.
The IP messages traced on the SBC show that IP packets are received from
the terminal and the timestamps and packet lengths of these packets are
consistent with those logged by the terminal.
Check the host logs that match the timestamps.
SIP STACK ERR LOG
Failed to Validate the Message;
Call SipTptLiStrRecvInf failed
Copy the 183 message to the superCodec tool. The tool displays a message
indicating that the mandatory To header field cannot be parsed. The issue
lies in the 306th byte.
DecodefailDetails:
t: <tel:13454100672;phone-
context=ims.mnc002.mcc460.3gppnetwork>;tag=af49a7436
ErrorPos:306
As stipulated in RFC3966, the Phonecontext field value of the To header
field cannot start with numbers.
The "tel" URI has the following syntax:
telephone-uri= "tel:" telephone-subscriber
telephone-subscriber = global-number / local-number
global-number= global-number-digits *par
local-number= local-number-digits *par context *par
par= parameter / extension / isdn-subaddress
isdn-subaddress= ";isub=" 1*uric
extension= ";ext=" 1*phonedigit

Copyright © Huawei
context= ";phone-context=" descriptor

descriptor= domainname / global-number-digits
global-number-digits = "+" *phonedigit DIGIT *phonedigit
local-number-digits=
*phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex
domainname= *( domainlabel "." ) toplabel [ "." ]
domainlabel= alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel= ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter= ";" pname ["=" pvalue ]
pname= 1*( alphanum / "-" )
pvalue= 1*paramchar
paramchar= param-unreserved / unreserved / pct-encoded
unreserved= alphanum / mark
mark= "-" / "_" / "." / "!" / "~" / "*" /
"'" / "(" / ")"
pct-encoded= "%" HEXDIG HEXDIG
param-unreserved= "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit= DIGIT / [ visual-separator ]
phonedigit-hex= HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator= "-" / "." / "(" / ")"
alphanum= ALPHA / DIGIT
reserved= ";" / "/" / "?" / ":" / "@" / "&" /
"=" / "+" / "$" / ","
uric= reserved / unreserved / pct-encoded
Condition The Phonecontext field value of the To header field starts with numbers.
of
Occurrence
Involved Version
UE
Solution
Workarounds:
N/A
Marvel has confirmed and resolved this issue.

Copyright © Huawei
2.14.15 In a Multi-Party Call, the Service Party Fails to Merge the

Fourth Session
Involved NE: UE
Defect Details
Symptom In a multi-party call, the service subscriber fails to merge the fourth
session. A 400 message carrying "400 Bad Request/Mandatory header
absent" is received.
Trouble N/A
Ticket
Number
Root Cause The logs generated by the terminal show that when the terminal sends a
REFER message and the network returns a 400 message carrying "Bad
Request/Mandatory header absent".
Copy the REFER message to the superCodec tool. The tool displays a
message indicating that the Refer-to header field is not present. The issue
lies in the 1002th byte.
DecodefailDetails:
r: <sip:15958139482@ims.mnc002.mcc460.3gppnetwork.org;user=phone?
Replaces=asbcOGU1N2Q5OTEyODIzYTE3YWMwNGVhMzdiMDM2N
mM5YjY.%3Bto-tag%3D921e4d4ceb.rqoryzottorqq%3Bfrom-tag
%3D8d74a2041Session-ID==c723ff7bfb29b8a93c4eaee98b2213ca>
ErrorPos:1002
According to RFC3261, there is no such regular matching as "==".
Refer-To = ("Refer-To" / "r") HCOLON ( name-addr / addr-spec ) * (SEMI
generic-param)
name-addr= [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec= SIP-URI / SIPS-URI / absoluteURI
telephone-uri= "tel:" telephone-subscriber
telephone-subscriber = global-number / local-number
global-number= global-number-digits *par
local-number= local-number-digits *par context *par
par= parameter / extension / isdn-subaddress
isdn-subaddress= ";isub=" 1*uric
extension= ";ext=" 1*phonedigit
context= ";phone-context=" descriptor
descriptor= domainname / global-number-digits
global-number-digits = "+" *phonedigit DIGIT *phonedigit
local-number-digits =
*phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex

Copyright © Huawei
domainname= *( domainlabel "." ) toplabel [ "." ]

domainlabel= alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel= ALPHA / ALPHA *( alphanum / "-" ) alphanum
parameter= ";" pname ["=" pvalue ]
pname= 1*( alphanum / "-" )
pvalue= 1*paramchar
paramchar= param-unreserved / unreserved / pct-encoded
unreserved= alphanum / mark
mark= "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
pct-encoded= "%" HEXDIG HEXDIG
param-unreserved= "[" / "]" / "/" / ":" / "&" / "+" / "$"
phonedigit= DIGIT / [ visual-separator ]
phonedigit-hex= HEXDIG / "*" / "#" / [ visual-separator ]
visual-separator= "-" / "." / "(" / ")"
alphanum= ALPHA / DIGIT
reserved= ";" / "/" / "?" / ":" / "@" / "&" /
"=" / "+" / "$" / ","
uric= reserved / unreserved / pct-encoded
Condition The SIP header field values do not comply with the protocol.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Marvel has confirmed and resolved this issue.
2.14.16 eSRVCC Handover Fails

Involved NE: eMSC
Defect Details
Symptom The eSRVCC handover fails.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause The STN-SR in the ps-to-cs-request message contains the prefix 19.
According to 3GPP 29.280, the STN-SR must contain the NANPI.
Therefore, the eMSC server cannot change the STN-SR.
ADD CNACLD: P=0, PFX=K'198613742682, ADDR=ALL,
CSTP=BASE, CSA=MLCT, RSNAME="SIP_SRVCC_ATCF03",
MINL=3, MAXL=32, ICLDTYPE=PS, DEST=65535, IAC=NO,
GAIN=LGN, RDT=0, SNO=0, DP=0, DT=0, RCM=NOC, ECOS=FALSE,
TOLLDNLEN=0, SRP=FALSE, NPRTIND=FALSE, ISEACM=FALSE,
EACM=0, ISERVICECHECKNAME="INVALID", SPDNCHG=NO,
DNPREPARE=TRUE, CLIANA=FALSE, ADDSIG=FALSE,
NUMNAME="INVALID", CUGSSNT=NIND, TARIFF=NI,
CHGNAME="INVALID", NCN="INVALID", SDCSN="INVALID",
SN="LOCAL", MOG="PUBLIC";
ADD PFXPRO: CSCNAME="ESRVCC", PFX=K'198613742682,
CLDNCN="D-0-2", CLINCN="DEFAULT", STF=NSDT,
PT=DONTPROC;
After the GTPPE/GTPPEERENTITYCAPLIST is selected, the STN-SR
prefixed with 19 can be processed.
Condition The STN-SR does not contain the NANPI.

of
Occurrence
Involved Version
Solution
Workarounds:
N/A

Copyright © Huawei
Run the following commands on the eMSC server:

ADD GTPPE: GTPPENM="NBMME56", DSAI="4600047770001",
CSCNAME="ESRVCC", GTPPEERENTITYCAPLIST=RSVBIT0-1;
ADD GTPPE: GTPPENM="NBMME57", DSAI="4600047770001",
CSCNAME="ESRVCC", GTPPEERENTITYCAPLIST=RSVBIT0-1;
ADD GTPPATH: GTPPATHNM="NBMME56_1", RMTIP="10.70.3.252",
LOCIP="10.71.5.18", GTPPENM="NBMME56";
As peer entities and paths have been configured, run the following commands on the eMSC
server:
MOD GTPPE: GTPPENM="HZMME56", GTPPEERENTITYCAPLIST=RSVBIT0-1;
MOD GTPPE: GTPPENM="HZMME57", GTPPEERENTITYCAPLIST=RSVBIT0-1;
2.14.17 When a Call to B (CBRT Subscriber) Is Forwarded to C

(not a CRBT Subscriber) Upon No Reply, C's Terminal Itself
Does Not Play an Alerting Tone
Defect Details
Symptom When a call to B (CBRT subscriber) is forwarded to C (not a CRBT

subscriber) upon no reply, C's terminal itself does not play an alerting tone.
Trouble N/A
Ticket
Number
Root Cause When A calls B, A hears the CRBT announcement.

Copyright © Huawei
P-Early-Media: sendrecv
When the timer for the CRBT announcement expires, the call is forwarded
to C. According to the relevant protocol, the P-Early-Media: inactive must
be carried to enable the terminal itself to play an announcement.
3GPP TS 24.628:
The UE shall not generate the locally generated communication progress
information if an early dialog exists where the last received P-Early-Media
header field as described in IETF RFC 5009 [12] contains "sendrecv" or
"sendonly"
RFC 5009:
After an early media authorization request has been received within a
dialogue, and a subsequent message is received
without the P-Early-Media header field, the previous early media
authorization remains unchanged.
3GPP TS 24.229:
NOTE 7: If the UE supports the P-Early-Media header field and if the most
recently received P-Early-Media header
field within the dialog includes a parameter applicable to media stream
with value "inactive", then based
on local configuration, the UE will provide an indication that the invited
user is being alerted and stop
presenting received early media to the user if requested by any previous
receipt of P-Early-Media header
field within the dialog.
Condition The carried PEM does not comply with the protocol.
of
Occurrence
Involved Version
ATS9900 V100R006C00SPC100
Solution
Workarounds:
N/A
On the MMTel AS, change the value of the software parameter 2311 to 1.

Copyright © Huawei
2.14.18 When the RAU of the Terminal Connects to the 2G

Network and Then Returns to the 4G Network Through the TAU,
the VoLTE Indicator of the Terminal Is Lost
Involved NE: MME
Defect Details
Symptom Mate 7 has registered with the IMS network through the 4G network and
can use VoLTE services. When the RAU of the terminal connects to the 2G
network and then returns to the 4G network through the TAU, the VoLTE
indicator of the terminal is lost. After a long time, the terminal still cannot
automatically register with the IMS network. The issue can be resolved
after the terminal is either restarted or first changed to the flight mode and
then exits the mode.
Trouble N/A
Ticket
Number
Root Cause The messages traced on the MME show that after the attachment procedure
is successful, the terminal initiates an IMS PDN establishment request.
After the IMS PDN is successfully established, the terminal also initiates a
PDN connectivity request where the APN is COMNET and the address
type is IPV6. As the subscriber has not subscribed to the CMNET service
of the IPV6 type, the MME uses the APN correction policies to change the
CMNET to IMS. Consequently, two default IMS bearers result.

Copyright © Huawei
That is, there are two IMS PDN connections. One is a normal IMS PDN
connection that will assign P-CSCF addresses. The other is the IMS PDN
corrected from the CMNET (this IMS PDN does not assign P-CSCF
addresses and therefore cannot be used for implementing VoLTE services).
After the RAU of the terminal connects to the 2G network, the IMS PDN
needs to be activated as required. At this time, the normal IMS PDN is
activated and the corrected IMS PDN is retained. When the terminal returns
to the 4G network and finds that one IMS PDN is already present, it does
not activate the current IMS PDN. As the retained IMS PDN cannot assign
P-CSF addresses, it cannot be used for implementing VoLTE services.
Now, the next question comes: When the terminal performs VoLTE
registration through the 4G network, why is the CMNET IPV6 service still
requested after the IMS PDN is activated?
In the attachment procedure, when the terminal requests the default bearer
(APN = 0), the MME returns an attach accept message in which eSM-cause
is #52. Consequently, the terminal again requests the PDN specific to the
CMNET IPV6 service.

Copyright © Huawei
In this scenario, the MME must send the cause value #50, which indicates
that the terminal does not request the PDN specific to the CMNET IPV6
service.
The following are protocol specifications:
Condition The MME does not send the cause value #50.
of
Occurrence
Involved Version
USN9810 V900R013C00SPC100
Solution
Workarounds:
This reason for this issue is that the APN is changed from cmnet to ims, causing two
activations of the default bearer for the IMS APN.
Run the following command on the MME to modify the data subscription method to prevent
the APN from being changed from cmnet to ims:

Copyright © Huawei
ADD SMSUBDATA: SUBRANGE=ALL_USER, TYPE=SUBSCRIBED_PARAMETER,

APNNIRANGE=APNNI_SPECIAL, APNNI="CMNET", PDPTYPE=IPV4,
IPV4PDPADDRTYPE=ALLOCATION_IPV4PDP_DYNAMIC, CORRECTAPNNI=NO,
NEWPDPTYPE=IPV4/IPV6, NEWIPV4PDPADDRTYPE=DYNAMIC,
NEWIPV6PDPADDRTYPE=DYNAMIC;
After the preceding configuration, a test has been performed on both the lab and live network
for individual subscribers. The test result shows that when the MME sends an attach accept
message that carries the cause value #52 to the terminal, it directly uses the cmnet rather than
changing the APN to ims when the UE initiates activation again. That is, when an activation
request is initiated to the P-GW for the PDN of the IPV6 type, the request is denied directly or
due to a timeout, causing the PDN request failure.
This issue will be resolved in USN10.5 SPH306.
2.14.19 Voice Calls May Fail to Be Switched to Video Calls for

QualComm Terminals
Involved NE: UE
Defect Details
Symptom Voice calls cannot be switched to video calls for QualComm terminals.
Trouble N/A
Ticket
Number
Root Cause QualComm terminal analysis:
When the network configures the video EPS, the eval_prec value
encounters a conflict.
2015 Aug 1315:21:57.696[A4]0xB0E2LTE NAS ESM Plain OTA
Incoming Message--Modify EPS bearer context request Msg
pkt_version = 1 (0x1)
rel_number = 9 (0x9)
rel_version_major = 5 (0x5)
rel_version_minor = 0 (0x0)
eps_bearer_id_or_skip_id = 7 (0x7)
prot_disc = 2 (0x2) (EPS session management messages)
trans_id = 0 (0x0)
msg_type = 201 (0xc9) (Modify EPS bearer context request)
lte_esm_msg
mod_eps_bearer_context_req
eps_qos_incl = 0 (0x0)
tft_incl = 1 (0x1)
tft

Copyright © Huawei
tft_op_code = 3 (0x3) (Add packet filters to existing TFT)

e_bit = 0 (0x0)
num_packet_filters = 2 (0x2)
rec[0]
pkt_filter_dir = 2 (0x2) (uplink only)
pkt_filter_id = 4 (0x4)
eval_prec = 187 (0xbb)
filter_len = 41 (0x29)
num_components = 4 (0x4)
rec[1]
pkt_filter_dir = 1 (0x1) (downlink only)
eval_prec = 186 (0xba)
2015 Aug 1315:22:10.987[87]0xB0E2LTE NAS ESM Plain OTA Incoming
Message--Activate dedicated EPS bearer context request Msg
pkt_version = 1 (0x1)
rel_number = 9 (0x9)
rel_version_major = 5 (0x5)
rel_version_minor = 0 (0x0)
eps_bearer_id_or_skip_id = 8 (0x8)
prot_disc = 2 (0x2) (EPS session management messages)
trans_id = 0 (0x0)
msg_type = 197 (0xc5) (Activate dedicated EPS bearer context request)
lte_esm_msg
act_dedicated_eps_bearer_context_req
linked_eps_bearer_id = 6 (0x6) (EPS bearer identity value 6)
eps_qos
qci = 2 (0x2) (QC2)
oct4_incl = 1 (0x1)
max_bit_rate_ul = 137 (0x89) (1152 kbps)
oct5_incl = 1 (0x1)
max_bit_rate_dl = 137 (0x89) (1152 kbps)
oct6_incl = 1 (0x1)
guaranteed_bit_rate_ul = 137 (0x89) (1152 kbps)
oct7_incl = 1 (0x1)
guaranteed_bit_rate_dl = 137 (0x89) (1152 kbps)
oct8_incl = 0 (0x0)
oct9_incl = 0 (0x0)
oct10_incl = 0 (0x0)

Copyright © Huawei
tft
tft_op_code = 1 (0x1) (Create new TFT)
e_bit = 0 (0x0)
num_packet_filters = 4 (0x4)
rec[0]
pkt_filter_dir = 2 (0x2) (uplink only)
eval_prec = 187 (0xbb)
rec[1]
pkt_filter_dir = 1 (0x1) (downlink only)
eval_prec = 186 (0xba)
UGW analysis:
The messages traced on the UGS show that the RAR messages in lines 116
and 120 carry two RULES, under which duplicate streams are present. The
way the UGW processes the duplicate streams causes the failure on the
terminal side. To find the reason why duplicate streams are carried to the
UGW through the RAR message, perform PCRF analysis.
charging-rule-name:S103_R1_VoLTE_Dedicate_Audio000174B6
flow-description:permit in 17 from
2409:8805:8300:8E:8AB6:C18B:7929:F136 50010 to
2409:8015:8029:13:FFFF:0:0:2 35286
flow-description:permit out 17 from 2409:8015:8029:13:FFFF:0:0:2 35286
to 2409:8805:8300:8E:8AB6:C18B:7929:F136 50010
2409:8805:8300:8E:8AB6:C18B:7929:F136 50011 to
2409:8015:8029:13:FFFF:0:0:2 35287
to 2409:8805:8300:8E:8AB6:C18B:7929:F136 50011
charging-rule-name:S103_R1_VoLTE_Dedicate_Audio000174B7
2409:8805:8300:8E:8AB6:C18B:7929:F136 50011 to
2409:8015:8029:13:FFFF:0:0:2 35287
to 2409:8805:8300:8E:8AB6:C18B:7929:F136 50011

Copyright © Huawei
PCRF analysis:
As the AAR-I sent by the SBC for the first time does not carry the RR-
bandwidth or RS-bandwidth and the AAR-U sent by the SBC for the
second time carries the RR-bandwidth and RS-bandwidth whose values are
0, the second streams are combined to the first streams. However, RTCP
stream rules are not deleted for the first streams.
To resolve this issue, configure the SBC to send an AAR message that does
not carry the RS-Bandwidth or RR-Bandwidth or an AAR message that
carries the RS-Bandwidth and RR-Bandwidth whose values are not 0.
SBC analysis:
The RS-Bandwidth and RR-Bandwidth carried by the QualComm terminal
for the voice call are set to 0.
b=AS:49
b=RS:0
b=RR:0
QualComm terminal analysis:
Voice service settings by the QualComm are incorrect. That is, the RS-
Bandwidth and RR-Bandwidth must not be set to 0.
Condition The RS-Bandwidth and RR-Bandwidth carried by the QualComm terminal
for the voice call are set to 0.
of
Occurrence
Involved Version
UE
Solution
Workarounds:
N/A

Copyright © Huawei
The voice service settings on the QualComm terminal have been corrected.
When the RS-Bandwidth and RR-Bandwidth carried by the QualComm terminal for the voice
call are set to 0, the PCRF will not carry the same settings to the UGW. The PCRF of the C30
version will provide this function.
If the PCRF carries the same settings to the UGW, the PCRF will perform compatibility
processing. Patch 306 will be developed for the PCRF of the 10.5 version to provide this
function.
2.14.20 VoLTE-to-VoLTE Calls Fail in Jinhua City in Zhejiang

Province
Involved NE: eNodeB
Defect Details
Symptom The VoLTE test performed in Jinhua City in Zhejiang province shows that
VoLTE-to-CS calls are successful but VoLTE-to-VoLTE calls fails.
Trouble N/A
Ticket
Number
Root Cause Create a subscriber message tracing task on both the P-GW and MME.
First check the subscriber messages traced on the UGW to see whether a
voice bearer is established for the voice service. It is found that the create
bearer response returned by the MME carries request rejected(94), which
indicates that the voice bearer establishment flow is abnormal on the side
comprising the MME, eNodeB and UE. Then check the subscriber
messages traced on the MME to see whether the create bearer flow is
normal. It is found that when the eNodeB returns an E-RAB setup
response, the MME notifies the UGW that the bearer cannot be created.

Copyright © Huawei
To further find the cause, check whether the e-rab setup response message
is abnormal. It is found that the eNodeB returns the cause radio-resources-
not-available(25) when responding to the e-rab setup request.
The eNodeB analysis result shows that the bandwidth requested for
establishing a bearer exceeds the one configured on the eNodeB, causing
the bearer failure. After the bandwidth on the eNodeB is modified, VoLTE-
to-VoLTE calls can be made successfully.

Copyright © Huawei
Condition The bandwidth requested for establishing a bearer exceeds the one
configured on the eNodeB.
of
Occurrence
Involved Version
eRAN7.0
Solution
Workarounds:
N/A
The eNodeB analysis shows that the bandwidth requested for establishing a bearer exceeds
the one configured on the eNodeB. To resolve this issue, modify the bandwidth on the
eNodeB.
2.14.21 SRVCC Handovers Fail During Comba Telecom Tests

Involved NE: eNodeB

Copyright © Huawei
Defect Details
Symptom eSRVCC handovers fail during VoLTE calls.
Trouble N/A
Ticket
Number
Root Cause Create a user message tracing task on the MME.

Copyright © Huawei
Check the Handover Required message, which indicates that an SRVCC

handover has been initiated.
Handover data over the Sv interface has been configured for the target LAC
580E on the MME.

Copyright © Huawei
The MME has sent the handover request to the eMSC, but the eMSC
returns an error code.
The eMSC engineer identified that this is because the length of the mobile-
station-classmark-2 IE in the SRVCC PS to CS Response message does not

Copyright © Huawei
meet specifications.
Check the Handover Required message to determine whether the MME

incorrectly processes the IE or the IE reported by the eNodeB does not
meet specifications.
The result shows that the MME has not processed the IE but only carries
the value reported by the eNodeB.
Check the protocol to obtain the correct length of the value of the MS

Copyright © Huawei
Classmark 2 IE.
As defined in 3GPP TS 36.413:
The MS Classmark 2 IE in the Handover Required message is set to the

value of classmark information type 2 as defined in 3GPP TS 48.008.
As defined in 3GPP TS 48.008
Condition This issue occurs when the length of the MS Classmark2 IE in the
Handover Required message does not meet specifications.
of
Occurrence
Involved Version
eRAN 7.0
Solution
Workarounds:
N/A
The eNodeB is optimized to carry only octets 3 to 5 in the MS Classmark2 IE of the
Handover Required message, and does not carry octets 1 and 2.
2.14.22 UE Cancels a Call Because the TFT Is Incorrectly Processed

Involved NE: UGW

Copyright © Huawei

Defect Details
Symptom During a terminal test, A calls B. After B answers the call, A places B on
hold and calls C. A cancels the call.
Trouble N/A
Ticket
Number
Root Cause The network incorrectly processes A's traffic flow template (TFT), and A
cancels the call.
To modify the TFT of a VoLTE call, the UGW sends an Update Bearer
Request message to the MME, and the MME sends a Modify EPS Bearer
Context Request to the UE. To identify the fault, check whether the UGW
correctly processes the message. Create a user message tracing task on the
UGW.
At 10:28:30, A places B on hold.
At 10:28:31, A calls C.
The terminal supplier identifies that the network incorrectly deletes the
TFT when A calls C.

Copyright © Huawei
In the message tracing result, when A calls C, the TFT for which filter-id is
set to 0 in the second Update Bearer Request message was deleted.
The analysis is as follows (each digit in the brackets identifies a filter ID):
A calls B.
rule_dedidate_audio0000F244
permit in 17 from 2409:8895:8200:73:1:2:97FD:8AA1 40000 to
0:0:0:0:0:0:0:0/0 65535
permit out 17 from 0:0:0:0:0:0:0:0/0 65535 to
2409:8895:8200:73:1:2:97FD:8AA1 40000
0:0:0:0:0:0:0:0/0 65535
2409:8895:8200:73:1:2:97FD:8AA1 40001
B answers the call. TFTs 0, 1, 2, and 3 are modified.
2409:8095:8201:800:0:0:0:4 53324
permit out 17 from 2409:8095:8201:800:0:0:0:4 53324 to
2409:8895:8200:73:1:2:97FD:8AA1 40000
2409:8095:8201:800:0:0:0:4 53325
2409:8895:8200:73:1:2:97FD:8AA1 40001
RAR message in line 15: TFTs 0, 1, 2, and 3 are updated but remain
unchanged.

Copyright © Huawei

2409:8095:8201:800:0:0:0:4 53324
2409:8895:8200:73:1:2:97FD:8AA1 40000
2409:8095:8201:800:0:0:0:4 53325
2409:8895:8200:73:1:2:97FD:8AA1 40001
RAR message in line 21: A places B on hold. TFT 0 is removed.
2409:8095:8201:800:0:0:0:4 53324
//One permit out is removed.
2409:8095:8201:800:0:0:0:4 53325
2409:8895:8200:73:1:2:97FD:8AA1 40001
RAR in line 29: A calls C (TFTs 0, 4, 5, and 6)
0:0:0:0:0:0:0:0/0 65535
2409:8895:8200:73:1:2:97FD:8AA1 40002
0:0:0:0:0:0:0:0/0 65535
2409:8895:8200:73:1:2:97FD:8AA1 40003
RAR message in line 37: TFTs 0, 4, 5, and 6 re modified.
2409:8095:8201:808:0:0:0:1 52568
2409:8895:8200:73:1:2:97FD:8AA1 40002
2409:8095:8201:808:0:0:0:1 52569
2409:8895:8200:73:1:2:97FD:8AA1 40003
RAR message in line 45: TFTs 0, 4, 5, and 6 are updated but remain
unchanged.
2409:8095:8201:808:0:0:0:1 52568
2409:8895:8200:73:1:2:97FD:8AA1 40002
2409:8095:8201:808:0:0:0:1 52569

Copyright © Huawei

2409:8895:8200:73:1:2:97FD:8AA1 40003
RAR message in line 53: The session between A and C is released. TFTs 0,
4, 5, and 6 are removed.
RAR message in line 59: The session between A and B is removed.
Condition This issue occurs when the following conditions are met:
 The parameter temporarily-reject-retransmit enable is set to Yes for
the UGW and bit 909 is set to 1.
 Two Update Bearer Response messages are generated for one RAR
message.
of
Occurrence
Involved Version
UGW9811 V900R010C02SPC100
Solution
Workarounds:
N/A
This issue occurs when the TFT cache indicator is not removed when the following conditions
are met:
 The parameter temporarily-reject-retransmit enable is set to Yes for the UGW and bit
909 is set to 1.
 Two Update Bearer Response messages are generated for one RAR message.
This issue will be solved in the UGW9811 V900R010C02SPH220 patch.
2.14.23 Subsequent Call Fails If a TAU Request Is Initiated at the

TA Edge Upon Call Completion
Involved NE: MME
Defect Details
Symptom A UE initiates a TAU request at a TA edge after a call is complete. When

the UE initiates a new call, the IMS network returns a 503 message, and the
UE access fails.

Copyright © Huawei
Trouble DTS2014112901215
Ticket
Number
Root Cause SIP Signaling Messages
After a call is released, the UE initiates a new call. The network sends a
100 (to INVITE) message and then a 503 message, indicating that services
are unavailable.
The layer-3 signaling message result shows that the UE initiates a TAU
request 30 ms after receiving a 200 (to BYE) message but does not receives
a Deactivate EPS Bearer Context Request message, instructing it to release
the bearer with QCI 1. The UE receives the Deactivate EPS Bearer Context
Request message until it initiates a new call.
Check the Tracking Area Update Request message shown in the following
figure. The UE carries the active flag of the bearer with QCI 1, indicating
that the bearer with QCI 1 has not been deactivated.

Copyright © Huawei
Check the Tracking Area Update Accept message, the EPC releases the
bearer with QCI 1, as shown in the following figure.
Check the Deactivate EPS Bearer Context Request message received when
a new call is initiated. The bearer with QCI 1 has been deactivated, as
shown in the following figure.
Analysis on the IMS Network

The UE fails to initiate a voice call.
The message tracing result shows that the P-GW fails to establish a bearer
and returns an error code, carrying the cause code
abortCause:insufficientBearerResources (2).
Analysis on the EPC Network

After the UE sends a BYE message, a Delete Bearer Request message is
sent to the MME through the UGW. However, the MME does not request
the eNodeB and UE to delete the bearer due to handover conflict. The

Copyright © Huawei
MME deletes the bearer on itself and notifies the UGW that the bearer has
been deleted.
When the UE initiates a new call, the MME sends a Create Bearer Request
message to the eNodeB. The preceding bearer on the eNodeB has not been
deleted, and a new bearer cannot be established due to bearer ID conflict.
Consequently, the MME requests to the eNodeB and UE to delete the
bearer. Then, the UE falls back from a 4G network to a 2G/3G network.
Condition An error occurs when the EPC processes the Delete Bearer Request and
Tracking Area Update Request messages.
of
Occurrence
Involved Version
USN9810 V900R013C00SPC100
Solution
Workarounds:
N/A
This issue will be solved in USN9810 10.5.
Note:
This issue has been included in UGW9811 V900R010C02SPH220.
2.14.24 mid-call eSRVCC Handovers Fail When ZTE IMS

Network Interworks with Huawei eMSC
Involved NE: eMSC

Copyright © Huawei
Defect Details
Symptom During handover of a held call, the 200 (to INVITE) message returned by
the IMS network carries a=recvonly. The call is still in held state after the
handover is completed.
Trouble N/A
Ticket
Number
Root Cause The MSOFTX3000 cannot identify a=recvonly as a handover request of a
held call.
Condition This issue occurs when the 200 (to INVITE) message returned by the IMS
network carries a=recvonly during handover of a held call.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
This issue will be solved in the MSOFTX3000 V200R010C20SPH954T patch.
2.14.25 VoLTE Video Calls Cannot Be Barred

Involved NE: ATS
Troubleshooting Engineer: Yu Kening (ID: 00317578)
Defect Details
Symptom After the Outgoing Call Barring service is enabled, audio calls can be
barred, but video calls cannot be barred.
Trouble 5118595
Ticket
Number
Root Cause If a call carries audio-video codecs and the "a=" line is set to sendrev or is
not carried, video calls are barred.
If a call carries audio-video codecs and the "a=" line is set to inactive, the
ATS does not check whether video call barring is required. In the
subsequent procedure for updating the media streams, the ATS sets the
video codec in inactive state. A voice call is set up instead of a video call.

Copyright © Huawei
In this example, a video call in which the "a=" line is set to inactive is
converted to a voice call, and call barring fails.
Condition This issue occurs when the video Outgoing Call Barring service is
registered.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH213
Solution
Workarounds:
N/A
The ATS has been optimized to bar a video call when the call carries audio-video codecs and
the "a=" line is set to inactive.
2.14.26 Announcement Placed to a Call Waiting Subscriber Is

Incorrect
Involved NE: ATS and MSOFTX3000
Defect Details
Symptom A VoLTE subscriber who has subscribed to the Call Waiting service is not
alerted about another incoming call but hears the ring back tone, which
occasionally occurs. This issue has been detected before but has not been
reproduced.
This issue occurred when the test number tel:+8613429104753 is located in
office xxx but did not occur when the test number is located in hotel xxx.
Trouble 4972697
Ticket
Number
Root Cause Call waiting parameters have not been configured for a SIP trunk group of
the MGCF. If this SIP trunk group is used, after receiving an ACM message
that carries the cw indicator, the MGCF includes the P-Early-Media header
field that is set to inactive in a 180 message and sends the 180 message to
the ATS. The ATS transparently transmits the 180 message because the 180
message does not carry the Alert-Info header field. If a normal SIP trunk
group is used, after receiving an ACM message that carries the cw
indicator, the MGCF includes the Alert-Info header field in a 180 message
and sends the 180 message to the ATS. The ATS instructs the MRFP to play

Copyright © Huawei
a call waiting tone, and the MRFP sends an Update message to negotiate
media information.
Condition This issue occurs when some call waiting parameters are not specified for
some SIP trunk groups of MGCF03 and MGCF04.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH213
MSOFTX_V200R010C20SPH111
Solution
Workarounds:
N/A
Modify the SIP trunk group of HZSCSCF5-2 on MGCF03 and SIP trunk group of
HZSCSCF5-2 on MGCF04 with Call waiting service interworking selected for Extra
software parameter of service control.
2.14.27 Intra-IMS VoLTE Hotline Call Fails

Involved NE: ATS
Defect Details
Symptom A call addressed to a hotline number does not carry the P-Access-Network-
Info header field, and the call fails.
Trouble 5092962
Ticket
Number
Root Cause The format of the P-Access-Network-Info header field is incorrect is after
processed by the ATS. Therefore, the S-CSCF removes the P-Access-
Network-Info header field before sending the INVITE message to the I-
CSCF.
The P-Access-Network-Info header field is as follows before sent to the
MMTel AS:
P-Access-Network-Info: 3GPP-E-UTRAN;utran-cell-id-
3gpp=4600057B96093A01;"sbc-
domain=SBC4.0571.zj.chinamobile.com";"ue-
ip=[2409:8805:8360:1BB:1:1:7AB1:A795]";"ue-port=31100";network-
provided

Copyright © Huawei
The P-Access-Network-Info header field is as follows after processed by

the MMTel AS:
P-Access-Network-Info: 3GPP-E-UTRAN;utran-cell-id-
3gpp=4600057B96093A01;"sbc-
domain=SBC4.0571.zj.chinamobile.com";ue-
ip=[[2409:8805:8360:1BB:1:1:7AB1:A795]];"ue-port=31100";network-
provided
Condition This issue occurs when the following conditions are met:
 P2346 is enabled for the ATS and bit 1 of PROTOCOLPARA6 is enabled
for the CSCF.
 ue-ip carries quotation marks.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH213
Solution
Workarounds:
N/A
1. If ue-ip carries quotation marks, disable P2346 for the ATS and bit 1 of
PROTOCOLPARA6 for the CSCF to enable the ATS to transparently transmit the INVITE
message.
2. If ue-ip does not carry quotation marks, install a patch to enable the ATS to transparently
transmit the INVITE message when the software parameters are enabled.
2.14.28 Called Parties on a MPTY Call Are Not Released After

Hanging Up
Involved NE: SE2900
Defect Details
Symptom Samsung mobile phones are used to test the Multi-party Function (MPTY).
After the MPTY call is ended, the called parties are not released after
hanging up.
A is an MPTY subscriber, and B and C are the called parties. A three-party
call is set up between A, B, and C. B and C are not released after hanging
up. Although B and C hang up, the BYE messages are not sent to the IMS
network, and B and C are not released.

Copyright © Huawei
Trouble 5134948
Ticket
Number
Root Cause The INVITE message received by the SBC carries the isfocus parameter
(required for conference calls). Therefore, the SBC does not convert the
IPv4 address in the Contact header field to an IPv6 address. The INVITE
message sent to the UE carries an IPv4 address. Consequently, the BYE
messages sent by the called parties are incorrectly transmitted, and the
called parties are not released.
An example abnormal Contact header field is as follows:
Contact: <sip:10.189.33.4:5060;TRC=ffffffff-ffffffff;Dpt=ebaa-
200>;isfocus
An example normal Contact header field is as follows:
Contact: <sip:
[2409:8015:8029:0013:FFFF:0000:0000:0001]:9900;Dpt=eb0a-
200;Hpt=8ef2_16;CxtId=4;TRC=1d8-ffffffff>;isfocus
Condition This issue occurs when bit 17 of BCFPARA2 is set to 1 for the SE2900 and
conference calls are initiated.
of
Occurrence
Involved Version
SE2900 V300R001C20SPH106
Solution
Workarounds:
N/A
Set bit 17 of BCFPARA2 to 0.
Software parameter description:
This software parameter determines whether the A-SBC processes the isfocus parameter in a
received SIP message.
Value:
= 0: The A-SBC changes the IP address in the Contact header field to the local A-SCB address
before forwarding the SIP message regardless of whether the Contact header field contains the
isfocus parameter.
= 1: The A-SBC does not change the IP address in the Contact header field before forwarding
the SIP message when the Contact header field contains the isfocus parameter. If the Contact

Copyright © Huawei
header in the SIP message does not contain the isfocus parameter, the A-SBC changes the IP
address in the Contact header to the local address before forwarding the SIP message.
Default value: 1
2.14.29 Video Call Between a VoLTE Subscriber on an LTE

Network and Another VoLTE Subscriber on a 2G/3G Network
Fails
Troubleshooting Engineer: Zhu Guoqing (ID: 00302152)
Defect Details
Symptom A VoLTE subscriber (13519593819) attached on an LTE network initiates a

video call to another VoLTE subscriber (18295501464) attached on a
2G/3G network. The ATS obtains the MSRN tel:+86134XXXX and sends
it to the MGCF, and the MGCF returns a 503 message.
Trouble 5106921
Ticket
Number
Root Cause The MGCF detects that the video port number in the INVITE message is 0
and returns a 503 message to release the call. This is because the the video
port number in the INVITE message is set to 0 on the terminating ATS.
Condition This issue occurs when video fallback is enabled for the ATS.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH213
Solution
Workarounds:
N/A
Disable video fallback for the ATS and enable the MGCF to implement video fallback.
2.14.30 SRVCC IWF Does Not Send an INVITE Message to the

IMS Network During an eSRVCC Handover
Involved NE: SRVCC IWF and MME

Copyright © Huawei
Troubleshooting Engineer: Yang Shiliang (ID: 00258341)

Defect Details
Symptom When the eSRVCC IWF and VMSC are co-located, an eSRVCC handover
to a 2G network fails. After receiving an SRVCC PS to CS Request
message from the MME, the MSC adds an access-side end point and
requests the BSC to allocate air interface resources. Then, the MSC does
not send an INVITE message to the ATCF. The SIP module releases the call
carrying the cause code cv-switching-equipment-fault (27). The SRVCC
IWF sends a Clear Command message to the BSC and returns an SRVCC
PS to CS Response message to the MME, carrying the cause code no-
resource-available (73).
Trouble 5102338
Ticket
Number
Root Cause In the office direction table configured on the SRVCC IWF to the ATCF,
IFADJUSTCODECRATE is set to Yes. However, the codec rate of
AMR2 has not been selected. The MSC cannot select AMR2, and the
eMSC does not send the INVITE message to the ATCF.
The IFADJUSTCODECRATE parameter does not need to be set to Yes.
If this parameter is set to Yes, the codec rate must be configured. However,
the codec rate is not configured, and the codec does not take effect.
Condition This issue occurs when eSRVCC handovers use the codec AMR2 but the
codec rate has not been configured.
of
Occurrence
Involved Version
MSOFTX3000 V200R010C20SPH112
Solution
Workarounds:
N/A
Run MOD OFC with IFADJUSTCODECRATEset to Yes to enable the MSC to select
codec rates from the Media Gateway (MGW) table.
2.14.31 Participants Are Offline During a Three-Party Call Using

Huawei Mate 7
Involved NE: SBC

Copyright © Huawei
Defect Details
Symptom The user message tracing task created on the originating SBC shows call
flow in the dialing test.
1. At 21:45:57, A, B, and C attend a conference call.
2. At 22:00:57, the calling party sends an INVITE message to update the
session, and the core network returns a 200 message, indicating that the
session is successfully updated.
3. At 22:01:11, B and C are offline. The core network does not detect BYE
messages, and there is no message exchange with UEs. The calling party
hangs up. A BYE message is sent to release the call.
Trouble N/A
Ticket
Number
Root Cause The SBC does not change the IP address in the Contact header field of the
INVITE message before forwarding it. When a participant initiates a
session update request, the SBC cannot match against a session and returns
a 481 message. The participant is offline.
Condition This issue occurs when the SBC does not change the IP address in the
Contact header field of the INVITE message before forwarding it.
of
Occurrence

Copyright © Huawei
Involved Version
SE2900 V300R001C10SPC100
Solution
Workarounds:
N/A
Run the following command with Delete Local Record-Route set to N(No):
MOD SIGPLC: SIGPLCNAME="pcscf", ENTYPE=ABCF, DELLOCRR=N;
This parameter must be set to N(No) when conference services are required, and the default
value is Y(Yes).

2.15.1 Video Calls Fail After SE2900 V300R001C10 Is Upgraded to
V300R001C20
Involved NE: SE2900
Defect Details
Symptom Voice calls are normal but video calls fail after SE2900 V300R001C10 is
upgraded to V300R001C20.
Trouble N/A
Ticket
Number
Root Cause The SDP information about the video calls contains "a=rtpmap:115
H264/90000", which indicates that the H.264 codec is used and the
required bandwidth is higher than 1000 kbit/s. These calls are high-
definition video calls, which are supported in V300R001C20SPC100 only
after the high-definition video call license is loaded. This license, however,

Copyright © Huawei
is not loaded.
Condition SE2900 V300R001C10 is upgraded to V3R1C20SPC100, but the matching
license is not obtained.
of
Occurrence
Involved Version
SE2900 V3R1C20SPC100
Solution
Workarounds:
N/A
Apply for a license file to obtain SD/HD video call control items.
2.15.2 "ALM-27011 Diameter(SCTP) link path fault" Is Generated

After the SE2900's SPU Resets
Involved NE: SE2900
Defect Details
Symptom "ALM-27011 Diameter(SCTP) link path fault" is generated and cannot be

cleared after the reset SPU is registered.
Trouble N/A
Ticket
Number
Root Cause "ALM-27011 Diameter(SCTP) link path fault" and "ALM-27012 Diameter
link fault" are generated when all SCTP paths in an SCTP link fail. The
SE2900 attempts to clear these alarms when the SCTP paths recover but
fails to clear "ALM-27011 Diameter(SCTP) link path fault" due to a
software defect.
Condition The SCTP link fails because both the SCTP paths in the link fail.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100

Copyright © Huawei
Solution
Workarounds:
The SE2900's functions are not affected even if this alarm persists. To mask the alarm, run
SET ALMSHLD.
Upgrade the SE2900 to V300R001C20SPC109.
2.15.3 SE2900 Does Not Switch Traffic Back to the Original I/S-
CSCF That Has Already Recovered After the I/S-CSCF
Switchover
Involved NE: SE2900
Defect Details
Symptom The SE2900 does not switch traffic back to the original I/S-CSCF that has
already recovered after the I/S-CSCF switchover.
Trouble 5037683
Ticket
Number
Root Cause According to the policy defined in ADD ART, if the SE2900 finds that I-
CSCF 1 or S-CSCF 1 fails, it automatically sends traffic to I-CSCF 2 or S-
CSCF 2; if I-CSCF 1 or S-CSCF 1 recovers, the SE2900 does not send
traffic to the recovered I-CSCF 1 or S-CSCF 1 because manual switchback
is configured.
Condition Automatic switchover and manual switchback are configured in the I/S-
CSCF redundancy policy.
of
Occurrence
Involved Version
All SE2900 versions
Solution
Workarounds:
Run SET SWITCHMODE to manually switch traffic back to the I-CSCFs or S-CSCFs.

Copyright © Huawei
If manual switchback is configured using ADD ART, run SET SWITCHMODE to manually
switch traffic back to the original I-CSCF or S-CSCF.
If automatic switchback is configured using ADD ART, the SE2900 automatically sends
traffic to the recovered I-CSCF or S-CSCF.
2.15.4 VoLTE Users Fail to Be Called Before They Are Re-

registered and After the I/S-CSCF Recovered
Involved NE: CSCF and HSS
Defect Details
Symptom VoLTE users fail to be called before they are re-registered and after the I/S-
CSCF recovers.
Trouble 5030500
Ticket
Number
Root Cause 1. When I-CSCF 1 or S-CSCF 1 fails, the MGCF interworks with I-CSCF 2
or S-CSCF 2 to process the calls to VoLTE users. Redundancy is enabled
on S-CSCF 2, which is configured to automatically restore the registered
services when users are called. S-CSCF 2 fails to obtain registration
information from the HSS and therefore returns a 480 response. The carried
cause value is as follows:
Warning: 399 37963.2172.S.261.5.108.0.35.34346.0.0.hi.chinamobile.com
"There were no URIs in the target set after the application of explicit
preferences"
Reason: Q.850;cause=18,SIP;cause=480
I/SCSCF configurations are as follows:
2. CSCF redundancy is enabled on the HSS using the software parameter

SCFDISASRSWITCH.
CSCFDISASRSWITCH (Whether to support S-CSCF network
redundancy)
(1) Parameter item name
INSPN
(2) Description
This parameter helps the IMS network to detect the S-CSCF's working
condition and enable the operational S-CSCF in another area to take over
services from the failed S-CSCF automatically once an S-CSCF is out of

Copyright © Huawei
service, which ensures uninterrupted service provisioning.

(3) Parameter value
0: The HSS does not support the S-CSCF redundancy function.
1: The HSS supports the S-CSCF redundancy function.
(4) Recommended value
Set the parameter based on site requirements.
(5) Configuration method
MOD INSP: INSPT=IMS-HSS, INSPN=CSCFDISASRSWITCH,
INSPV=1;
Condition An CSCF switchover is triggered, but the HSS does not support S-CSCF
redundancy.
of
Occurrence
Involved Version
IMS10.1
Solution
Workarounds:
N/A
1. Enable network redundancy on the I-CSCF or S-CSCF, and configure the I-CSCF or S-
CSCF to automatically restore the registered services when users are called.
MOD MEPARA: NEEDGR=Y, GRPLY=RESTORECALLEESERVICE;
2. Configure the HSS to support S-CSCF redundancy.
MOD INSP: INSPT=IMS-HSS, INSPN=CSCFDISASRSWITCH, INSPV=1;
2.15.5 CSCF Wrongly Disconnects the Existing Call After

Receiving a re-REGISTER Message
Involved NE: CSCF and SE2900
Defect Details
Symptom The CSCF wrongly disconnects the existing call after receiving a re-
REGISTER message.
Trouble 5021447
Ticket

Copyright © Huawei
Number
Root Cause The IP address and port number carried in the Contact header field of the
re-REGISTER message are different from those carried in the REGISTER
message of the same UE. As a result, the S-CSCF wrongly considers the re-
REGISTER message to be an initial REGISTER message and disconnects
the existing call of the user.
Contact:
<sip:460001494135577@[2409:8800:9200:10F0:0000:0000:0000:0001]:31
106;
Condition The IP address and port number carried in the Contact header field of the
re-REGISTER message are different from those carried in the REGISTER
message.
of
Occurrence
Involved Version
IMS10.1
Solution
Workarounds:
N/A
The message sent from the UE is not a standard message, and therefore this issue needs to be
rectified on the UE.
2.15.6 HTC UEs Are Registered Successfully but Fail to Initiate

Calls After Being Upgraded
Involved NE: CSCF and SE2900
Defect Details
Symptom HTC UEs are registered successfully but fail to initiate calls after being
upgraded.
Trouble 5023008
Ticket
Number
Root Cause The Contact header field in the REGISTER message sent from an HTC UE
is as follows:
Contact:
sip:460023073296001@[2409:8809:120:28:5093:56ea:7077:7a0c]:5060

Copyright © Huawei
The IMPU in the Contact header field of the INVITE message sent from
the HTC UE, however, is in the TEL URI format. The SE2900 fails to
associate the INVITE message with the REGISTER message and therefore
returns a 403 response carrying the cause value of Warning: 399
03079.01234.A.005.401.228.0.6.08453.00000000.1075445762 "Invalid
User".
m: sip: +8615073221414@[2409:8809:120:28:5093:56ea:7077:7a0c]:5060
Condition The Contact header field in the INVITE message is different from that in
the REGISTER message.
of
Occurrence
Involved Version
IMS10.1
Solution
Workarounds:
N/A
The message sent from the UE is not a standard message, and therefore this issue needs to be
rectified on the UE.
2.15.7 sbc-domain in Access-Network-Information of the CDRs

Specific to Certain Originating or Terminating UEs Does Not
Carry Any Area Code Due to the Oversized P-Access-Network-
Info Header Field
Defect Details
Symptom When the CDRs generated by the CCF are verified, it is found that sbc-
domain in Access-Network-Information of the CDRs specific to certain
originating or terminating UEs does not carry any area code.
For example, during the test, sbc-domain contains an area code when
Huawei Mate7 initiates a call but does not contain any area code when an
Apple UE initiates a call.
Trouble 4849797
Ticket
Number

Copyright © Huawei
Root Cause The P-Access-Network-Info header field carried in the message initiated by
Huawei Mate7 is 3GPP-E-UTRAN;utran-cell-id-
3gpp=46000630C5761C0D;"sbc-
domain=jnpsbc2bhw.0531.sd.chinamobile.com";"ue-
ip=[2409:8807:8070:3C:1:3:731:1665]";"ue-port=5385";network-provided,
which contains a total of 169 bytes.
The P-Access-Network-Info header field carried in the message initiated by
an Apple UE is 3GPP-E-UTRAN;utran-cell-id-
3gpp=46000630C5761C0D;"sbc-
domain=jnpsbc2bhw.0531.sd.chinamobile.com";"ue-
ip=[2409:8807:8070:208:4CA:310E:57:995E]";"ue-port=49152";network-
provided, which contains more than 170 bytes.
The ATS9900 supports the P-Access-Network-Info header field with a
maximum of 170 bytes. If this header field contains more than 170 bytes,
the ATS9900 uses the P-Access-Network-Info header field in the
REGISTER message, but the P-Access-Network-Info header field in the
REGISTER message does not carry any area code.
The area code is obtained over the Rx interface based on the mapping
between the user location and area code that is configured using ADD
LAMAP of the SE2900.
Condition The P-Access-Network-Info header field contains more than 170 bytes.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
Workarounds:
Enable the HMR function on the SE2900 so that the oversized header field can be cut off.
Install ATS9900 V100R006C10SPH212.
2.15.8 Registration Service Fails When the Contact Header Field

Contains More Than 256 Bytes
Defect Details
Symptom The registration service fails when the Contact header field contains more
than 256 bytes.

Copyright © Huawei
Trouble 4615829
Ticket
Number
Root Cause The Contact header field carried in the REGISTER message contains more
than 256 bytes, but the CSCF can process the Contact header field with a
maximum of 256 bytes. As a result, the CSCF returns a 500 response, and
the registration service fails.
Condition The Contact header field contains more than 256 bytes.
of
Occurrence
Involved Version
CSC3300 V100R010C10SPC200
Solution
Workarounds:
N/A
Run ADD SRVCAP to enable compression of the feature name and feature value in the
Contact header field.
ADD SRVCAP implementation: The CSC3300 compresses the matched feature names and
feature values in the Contact header field as internal identifiers and then restores the
compressed contents when sending the message carrying the Contact header field.
2.15.9 VoLTE and VoBB Performance Measurement Statistics Are

Not Separated
Troubleshooting Engineer: Zhu Guoqing (ID: 00302152)
Defect Details
Symptom Separate VoLTE and VoBB performance measurement is configured as

follows:
/*A VoLTE subscriber identification record is added.*/
ADD LTEUSERRCG:
IMPIKEY=".*@ims\\.mnc.*\\.mcc460\\.3gppnetwork\\.org$";
/*Add an access type data record so that the access types of VoLTE and
VoBB subscribers can be identified.*/
ADD SACCTYPE: ACCTYPE=LTE_ACCESS, PANI="^3GPP-E-
UTRAN.*", CONTACT=".*", PRI=0; ADD SACCTYPE:
ACCTYPE=FIXED_ACCESS, PRI=1;

Copyright © Huawei
VoLTE statistics are not separated from VoBB statistics.

+++ CSCF/*MEID:5 MENAME:XIMISBG2BHW*/
2015-08-24 16:18:56+08:00
O&M #64929
%%DSP SURN: ATYPE=REG_VOLTE_USERNUMBER;%%
The result is as follows
------------
Equivalent total number of registered VoLTE subscribers = 0
Actual total number of registered VoLTE subscribers = 0
Trouble 5036750
Ticket
Number
Root Cause When bit 7 of the software parameter DBMSPARA3 is set to 1, the number
of registered VoLTE users on the S-CSCF is always displayed 0 incorrectly.
The DSP SURN command output indicates the same error.
Bit 7
Determines how the CSC3300 counts the number of registered subscribers.
= 0: The CSC3300 counts the number of registered subscribers based on
implicit registration sets.
Number of subscribers = Number of implicit registration sets + Number of
PBX extension numbers/2
Number of Multiple IMPIs = Number of IMPIs - Number of implicit
registration sets of non-VoLTE subscribers - 2 x Number of implicit
registration sets of VoLTE subscribers
Number of Multiple IMPUs = Number of IMPUs (excluding the IMPUs of
PBX extension numbers) - 2 x Number of implicit registration sets of non-
VoLTE subscribers - 4 x Number of implicit registration sets of VoLTE
subscribers
Number of Multiple Contacts = Number of Contacts - Number of implicit
registration sets of non-VoLTE subscribers - 2 x Number of implicit
registration sets of VoLTE subscribers - Number of Multiple IMPIs
For example, 10 common subscribers and 10 VoLTE subscribers have
registered, and one PBX subscriber with 100 extension numbers has made
calls. A common subscriber has one IMPI and three IMPUs, a VoLTE
subscriber has three IMPIs and four IMPUs, and a PBX subscriber has one
IMPI and six IMPUs. The number of subscribers is calculated as follows:
Number of subscribers = (10 + 1) (Number of implicit registration sets of
non-VoLTE subscribers) + 10 (Number of implicit registration sets of
VoLTE subscribers) + 100/2 (Number of PBX extension numbers/2) = 71
Number of Multiple IMPIs = (10 + 30 + 1) (Number of IMPIs) - (10 + 1)
(Number of implicit registration sets of non-VoLTE subscribers) - 2 x 10 (2
x Number of implicit registration sets of VoLTE subscribers) = 10
Number of Multiple IMPUs = (30 + 40 + 6) (Number of IMPUs) - 2 x (10
+ 1) (Number of implicit registration sets of non-VoLTE subscribers) - (4 x

Copyright © Huawei
10) (4 x Number of implicit registration sets of VoLTE subscribers) = 14

Number of Multiple Contacts = (10 + 30 + 1) (Number of Contacts) - (10 +
1) (Number of implicit registration sets of non-VoLTE subscribers) - 2 x 10
(2 x Number of implicit registration sets of VoLTE subscribers) - 10
(Number of Multiple IMPIs) = 0
NOTE:
A VoLTE subscriber is a subscriber whose IMPI carried during registration
is in @ims.mncXXX3gppnetwork.org or @ics.mncXXX3gppnetwork.org
format. XXX indicates zero or multiple random characters.
= 1: The CSC3300 counts the number of registered subscribers based on
the model in which one subscriber has one IMPI and two IMPUs. The
number of subscribers is the larger value between the number of IMPIs and
half the number of IMPUs.
Default value: 0
Application scenario: This bit is used to determine how the CSC3300
counts the number of registered subscribers. To enable the CSC3300 to
count the number of registered subscribers based on implicit registration
sets, retain the default value 0. In this case, the CSC3300 supports
measurement of subscriber quantity based on the number of additional
IMPIs, the number of additional IMPUs, or the number of additional
contact addresses. To enable the CSC3300 to count the number of
registered subscribers based on the model in which one subscriber has one
IMPI and two IMPUs, set bit 7 to 1.
Impact on the system: By default, the CSC3300 counts the number of
registered subscribers based on implicit registration sets. If you change the
value of bit 7 to 1, the values of the number of registered subscribers
counted before and after the modification are different or exceed the
maximum number specified by the license. You are advised to retain the
default value.
Condition Separate VoLTE and VoBB performance measurement is configured.
of
Occurrence
Involved Version
CSC3300 V100R010C10SPC200
Solution
Workarounds:
N/A
Run the following command to change the value of bit 7 to 0:
MOD SFP: INSPN=DBMSPARA3, MODTYPE=P1, BIT=7, BITVAL=0;

Copyright © Huawei
2.15.10 VoLTE Test Result Shows that the MATE 7's Video
Fallback Function May Fail
Involved NE: MATE7 UE
Troubleshooting Engineer: Yi Pengxiao (ID: 00287123)
Defect Details
Symptom After MGCF and SBC resource reservation is configured, the MATE7's
video fallback function may fail.
Trouble N/A
Ticket
Number
Root Cause The messages captured during failed and successful video fallback
scenarios show that the MGCF returns the same 183 response to the SBC.
After receiving 183 responses, the SBC processes the responses and then
sends different responses to MATE7. As a result, MATE7 fails to return an
Update message and disconnects the call.
NOTE: The 183 responses sent from the SBC are protocol-compliant.
Condition The MATE7's patch version is 718 or earlier.
of condition is met.
Occurrence
Involved Version
MATE7's 718 patch version or earlier
Solution
Workarounds:
N/A
Install MATE7's patch version 719.
2.15.11 Galaxy S6/MATE7/iPhone6 Fails to Call the Fixed-Line

Number Served by the MA5620
Involved NE: SE2900
Applicable Scope: global (beta site)
Defect Details

Copyright © Huawei
Symptom The call initiated by Galaxy S6/MATE7/iPhone6 on the VoLTE network to

the fixed-line number 56922283 served by the MA5620 cannot be
established, no prompt tone is played, and the 488 responses are returned.
The signaling flow is as follows:
UE--VoLTE SE2900--VoLTE SCSCF—(Query for ENS) —VoBB I/S-
CSCF—VoBB P-CSCF—MA5620
Trouble N/A
Ticket
Number
Root Cause The GPON device on the access network fails to support the required
codecs and therefore returns 488 responses.
Condition More than eight codecs are carried in the message sent to the GPON
device.
of
Occurrence
Involved Version
All SE2900 versions
Solution
Workarounds:
1. Improve the transcoding capability on PSBC 1 (before network entry) of the VoLTE
network so that the SBC carries eight codecs in the message sent to the core network
without adding AMR-WB and AMR.
2. ENUM query is not performed during VoLTE/VoBB interworking.
N/A
NOTE: This is a common codec negotiation issue encountered during VoLTE/VoBB
interworking. Huawei cannot solve this issue alone because the factors, such as access
network and multi-vendor device interconnection and VoLTE/VoBB interworking cost
between different regions, need to be considered.
2.15.12 No-audio Issue Occurs After the Call Initiated by the

M821 UE to a Fixed-Line Number Served by the MA5620 Is
Established
Involved NE: SE2900
Applicable Scope: global (beta site)
Defect Details

Copyright © Huawei
Symptom The M821 on the VoLTE network calls the fixed-line number 56922283
served by the MA5620. The call can be established, but no audio can be
heard.
The signaling flow is as follows:
UE--VoLTE SE2900--VoLTE SCSCF—(Query for ENS) —VoBB I/S-
CSCF—VoBB P-CSCF—MA5620
Trouble N/A
Ticket
Number
Root Cause The GPON device on the access network does not support the SDP
information carrying b=AS:80. As a result, the 200 OK response carries
a=inactive, resulting in no audio.
Condition The message sent to the GPON device carries b=AS:80.
of
Occurrence
Involved Version
All SE2900 versions
Solution
Workarounds:
ENUM query is not performed during VoLTE/VoBB interworking.
Solution description:
When a VoLTE UE calls a VoBB UE, the CSCF that serves the VoLTE UE does not perform
ENUM query but sends the call message to the MGCF, which then sends the message to the
interworking gateway. The gateway forwards the message to the VoBB UE of the IMS
network.
When a VoBB UE calls a VoLTE UE, the CSCF that serves the VoBB UE does not query the
UE's number segment but sends the call message to the MGCF, which then sends the message
to the interworking gateway. The gateway forwards the message to the VoLTE UE.
N/A
NOTE: This is a common codec negotiation issue encountered during VoLTE/VoBB
interworking. Huawei cannot solve this issue alone because the factors, such as access
network and multi-vendor device interconnection and VoLTE/VoBB interworking cost
between different regions, need to be considered.

Copyright © Huawei
2.15.13 Call Established Between Two VoLTE UEs Falls Back to

the CS Domain Because the Nokia P-GW Cannot Report the
Charging AVP
Involved NE: SE2900
Troubleshooting Engineer: Huang Chuanhai (ID: 00171878)
Defect Details
Symptom The IOT test results show that the call established between two VoLTE UEs
falls back to the CS domain when the networking is Nokia EPC+Nokia
PCRF+Huawei SBC but does not fall back to the CS domain when the
networking is Huawei EPC+Huawei PCRF+Huawei SBC.
Trouble 4836303
Ticket
Number
Root Cause The PCRF does not return charging information within the specified
duration.
As the location information event has been subscribed, the SBC sends an
AAR message after receiving the INVITE message. In the successful
service procedure, the PCRF includes the charging AVP
"accessNetworkChargingIdentifierValue-OR-etsiSipAuthenticationInfo
(503)" in the AAA message, and therefore the SBC does not need to wait
charging AVP.
In the failed service procedure, no charging AVP is returned within the
specified duration (3 second by default, which can be changed).
If charging is not required, remove the charging event subscription
configuration.
The call connected using Huawei P-GW does not fall back to the CS
domain. The call connected using Nokia P-GW fails because the P-GW
does not support the charging AVP
"accessNetworkChargingIdentifierValue-OR-etsiSipAuthenticationInfo
(503)" and does not convey the charging AVP to the SBC. As a result, the
SBC fails to process the required charging AVP within the specified
duration.
Condition The charging AVP has been subscribed on the SBC.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds:

Copyright © Huawei
Run the following command on the SBC to cancel charging event subscription:
MOD RXPLC: PLCN="RXPLC_01", MBSE=CCE-0;
N/A
NOTE: The RAA message returned by the Nokia S-GW/P-GW is defective, which has been
conveyed to Nokia for rectification.
2.15.14 When the VoLTE CRBT User Is Called in the CS Domain,

the Calling Party Can Hear the CRBTs but Cannot Be Informed
that the Called Party Is Busy If Being Rejected
Defect Details
Symptom When the VoLTE CRBT user is called in the CS domain, the calling party
can hear the CRBTs but cannot be informed that the called party is busy if
being rejected.
This issue does not occur if no CRBT service is involved.
Trouble 4846549
Ticket
Number
Root Cause If no CRBT service is involved, the busy tone is transparently transmitted
from the CS domain through a 183 response. The later 183 response does
not carry media, and therefore the busy tone is played using the media port
carried in the first 183 response.
If a CRBT service is involved, the calling party obtains the CRBT media
after hearing the CRBT. The 183 response specific to user-busy does not
carry SDP information. The media carried in the first 183 response is
unavailable for the calling party because the CRBT media is played. The
user-busy announcement played by the CS domain cannot be transparently
transmitted to the calling party.
Condition The user has subscribed to the CRBT service.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds:

Copyright © Huawei
N/A
Configure the MGCF to perform conversion between ACM failure cause codes and SIP status
codes and to suppress announcements for the CS domain. The user-busy announcement is
played by the TAS without being transparently transmitted from the CS domain.
Run MOD SIPTG to select FUNC29(MGCF suppressing announcement playing as
specified in 3GPP 29163) and FUNC30(Interchanging between failure cause codes and
SIP status codes as specified in 3GPP 29163) for Extra software parameter 5 of service
control.
MOD SIPTG: TGN="IMS_TG", ESFPARA5=FUNC29-1&FUNC30-1;
2.15.15 No CDR Header Is Present in the Empty CDR File on the

VoLTE Network
Involved NE: VoLTE
Defect Details
Symptom An empty CDR file is generated, but no CDR header is present in the
empty CDR file.
Trouble 4892763
Ticket
Number
Root Cause No CDR header is carried in the empty CDR file when the format engine
package is configured.
Condition The format engine package is incorrectly configured.
of
Occurrence
Involved Version
VoLTE V100R002C00SPC100
Solution
Workarounds:
N/A
Modify the format engine package by following the configuration in the figure.

Copyright © Huawei
2.15.16 When a VoLTE UE Calls a CS UE, the MGCF Keeps

Retransmitting the Received UPDATE Message Specific to the
Precondition to the VoLTE UE
Involved NE: VoLTE
Troubleshooting Engineer: Zhao Chaojian (ID: 00284738)
Defect Details
Symptom When a VoLTE UE calls a CS UE, the MGCF keeps retransmitting the
received UPDATE message specific to the precondition to the VoLTE UE.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause The MSC server sends the UPDATE message because the precondition in
this message carries the confirmation status.
According to RFC3312, if confirmation status is carried and the

precondition is met, the UPDATE message needs to be sent.
The UPDATE message sent by the protocol stack is not acknowledged

before the timer times out, and therefore this message is retransmitted after
the timer expires.
Condition The precondition in the UPDATE message carries the confirmation status.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Contact the technical support engineer of the peer end to configure the peer end not to include
the confirmation status in the UPDATE message.
2.15.17 During eSRVCC Tests on Basic Calls, the Announcement

of "Sorry, the number you dialed does not exist" Is Played
Involved NE: SE2900
Defect Details
Symptom VoLTE UEs A are B are on a call, and UE A initiates an eSRVCC handover
and attempts to initiate a second eSRVCC handover (handback) because the

Copyright © Huawei
first handover fails. During the second eSRVCC handover, the

announcement of "Sorry, the number you dialed does not exist " is played
for UE A.
Trouble 4887881
Ticket
Number
Root Cause
Line 1992: indicates the second eSRVCC handover due to the failed
handover, with the "Reason: handover cancelled" carried. The message is
as follows:
Line 2335: indicates the 404 response returned by the SBC after the ATCF
receives a second handover INVITE message from the IWF. The 404
response is as follows:
The SBC fails to locate the call for which the eSRVCC handover is
performed due to a software defect.
Condition  The UE initiates a second eSRVCC handover after the first handover

Copyright © Huawei
fails.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds:
N/A
This issue will be solved in later SE2900 versions.
2.15.18 UE Fails to Join the Three-Party Conference, and the ATS

Returns a 481 Response
Involved NE: VoLTE
Defect Details
Symptom The three-party conference service to CRBT users fails. When a UE sends
a Refer message to invite the first party to a conference, the ATS returns a
481 response to the Refer message. This is because the ATS cannot
recognize the Call-ID, To-tag, or From-tag carried in the Refer-to header
field of the Refer message.
Trouble N/A
Ticket
Number
Root Cause UE B sends an in-dialog Refer message to invite UE A to join the
conference, and the Replaces in the Refer-to header field of the Refer
message carries the ID information (Call-ID, To-tag, and From-tag) about
the call between UE B and the A-SBC. Detailed information is as follows:
Refer-To: sip:user1_public2@home1.net?
Replaces=cb03a0s09a2sdfglkj490333%3Bto-tag314159%3Bfrom-
tag171828;method=INVITE----------------------Replaces carry Call-ID, To-
tag, and From-tag about the call between UE B and UE A.
In the call model used on site, the following ASs are triggered in sequence:
MMTEL AS--->CAT AS--->SCC AS---->Called UE (involved in the
meeting).
The AS functions as a B2BUA and can change the Call-ID, To-tag, and
From-tag values. The MMTEL AS and CAT AS can also change these
values but the SCC AS cannot. That is, the following Call-IDs are involved

Copyright © Huawei
in the call:
As shown in the figure, the MMTEL AS can recognize Call-ID1 and Call-
ID2 only. The Refer-to header field in the Refer message sent by the UE
carries Call-ID4, which is then mapped to Call-ID3 by the SBC (P-
CSCSF). Then the Refer message is directly sent to the MMTEL AS.
The ATS, however, cannot recognize Call-ID3 and therefore cannot find the
call. As a result, a 481 response is returned.
Condition  The CAT AS is used.
 A three-party conference is initiated.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Modify the implementation of the CAT AS as follows:
When the CAT AS deployed behind the MMTEL AS functions as a B2BUA, it must either
always retain the Dialog ID (A-B, A-C) or change the Dialog ID (including the ID in the
Replaces of the Refer message).
2.15.19 Roaming VoLTE UE Fails to Call the Local VoLTE UE, and
the SBC Returns a 480 Response
Involved NE: SE2900
Defect Details

Copyright © Huawei
Symptom A VoLTE UE roams to another area but fails to call the local VoLTE UE.
Trouble N/A
Ticket
Number
Root Cause After receiving the PRACK message, the SBC queries the home S-CSCF
using the embedded DNS function, but fails to find any record. Therefore,
the SBC returns a 480 response without querying the external DNS server.
SBC R&D engineers confirm that bit 0 of the software parameter

PROTOCOLPARA31 must be set to 1 so that recursive DNS query is
performed. The bit setting takes effect only after the BSU module is
restarted.
Condition The software parameter is incorrectly set on the SBC for DNS query.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution

Copyright © Huawei
Workarounds:
N/A
Set bit 0 of PROTOCOLPARA31 to 1 and then restart the BSU module.
2.15.20 eSRVCC Handover Fails Because the STN-SR Number in

the Handover INVITE Message Is Not Updated
Defect Details
Symptom During an SRVCC handover test in the roaming scenario, the handover
fails because the STN-SR number in the handover INVITE message is not
updated and the INVITE message is not sent to the ATCF.
Trouble N/A
Ticket
Number
Root Cause The handover INVITE message sent from the MME to the IWF is as
follows:
The STN-SR number displayed in the LST ATCF command output of the
SBC is as follows:
The MME fills a different STN-SR number in the handover INVITE

message sent to the IWF. As a result, the message cannot be sent to the

Copyright © Huawei
ATCF.
The following explains why the access-side STN-SR number carried in the
REGISTER message is not updated to the HSS:
The following figure shows the message flow of the third-party
registration.
The captured messages show that a large number of MESSAGE messages

on the SCC AS are not sent. This is because no ATCF address is added to
DNS data.
During the registration procedure, ZTE or Ericsson SCC AS will send a
PUR message to the HSS to update the STN-SR number only after sending
the MESSAGE message.
Condition The ATCF address is not added to DNS data on the SCC AS.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds:

Copyright © Huawei
N/A
Add the ATCF address to DNS data.
2.15.21 Call to the Roaming VoLTE UE Fails, and the CS Domain

Returns a 486 Response
Involved NE: UE
Defect Details
Symptom A VoLTE UE roams to another area and is registered with the roaming
VoLTE network. When this VoLTE UE is called, the SCC AS sends the call
message to the CS domain, which then returns a 486 response. The call
service fails.
Trouble N/A
Ticket
Number
Root Cause The message traced on the SCC AS shows that the SCC AS has changed
the R-URI in the message. The CSCF routes the received message to the
MGCF, which then forwards the message to the CS domain.
The CS domain returns a 486 response.

Copyright © Huawei
When a registered VoLTE UE is called, the SCC AS should not send the
call message to the CS domain.
The UPDATE message that the HSS sends to the SCC AS during the
registration shows that the UE does not support the SRVCC. Therefore, the
SCC AS sends the call message to the CS domain when the UE is called.
The CS domain returns a 486 response because the UE is registered with
the VoLTE network.
The service flow on the SCC AS is as follows:

Copyright © Huawei
Condition The UE does not support SRVCC.

of
Occurrence
Involved Version
UE
Solution
Workarounds:
N/A
Configure the UE to support SRVCC during registration.
2.15.22 Same Announcement Is Played When the UE Is Powered

Off or Unavailable

Copyright © Huawei
Defect Details
Symptom The announcement of "The number you have dialed cannot be connected at
the moment" is played when the called UE is powered off, and this
announcement is also played when the called UE is unavailable (for
example, the battery is removed).
Trouble N/A
Ticket
Number
Root Cause When the called UE is unavailable, the SCC AS performs the CS Retry
procedure, and the CS domain returns a 408 response (indicating that the
UE does not respond) with the cause value of 18.
The announcement playing configuration on the ATS shows that the

announcement numbered 20 is played when the 408 response is returned.
The announcement playing procedure when the UE is powered off is as

follows:

Copyright © Huawei
The SCC AS returns a 480 response with the cause value of 20. Details are
as follows:
The RBT platform removes the Reason header from the 480 response.
Details are as follows:
The 480 response sent from the S-CSCF to the MMTEL AS carries the
cause value of 18. Therefore, the same announcement is played.

Copyright © Huawei
The announcement whose ID is 20 is "The number you have dialed cannot

be connected at the moment".
Condition The RBT platform removes the Reason header from the 480 response.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH200
Solution
Workarounds:
N/A
Configure the RBT platform to transparently transmit the Reason header. On the MMTEL AS,
run ADD OPTID to add the announcement resource ID 185 specific to the 480 response with
the cause value of 20, and run MOD MRFVARCFG to add an announcement.

Copyright © Huawei
2.15.23 After UE A That Is Already on a Call with UE B Answers

the Call from UE C, the Calls Among Them Are Disconnected
Involved NE: UGW
Defect Details
Symptom After UE A that is already on a call with UE B answers the call from UE C,
the calls among them are disconnected.
Trouble N/A
Ticket
Number
Root Cause The messages traced on the SBC show that the PCRF sends an ASR
message to the SBC to release the calls unexpectedly.
The ASR message reporting procedure is as follows:
The 503 response shows that the bearer is disconnected by the EPC.

Copyright © Huawei
EPC engineers check that bit 1674 (controlling whether the UGW9811
optimizes TFT filter operation types) is set to 0.
Condition  Bit 1674 is not set to 1.
of
Occurrence
Involved Version
Solution
Workarounds:
N/A
Set bit 1674 to 1 so that the UGW9811 optimizes TFT filter operation types.
2.15.24 Call from the CS Domain to a VoLTE UE Fails, and the

MGCF Returns a 488 Response
Involved NE: MGW
Defect Details
Symptom The call initiated by a CS user to a VoLTE user fails, and the MGCF returns
a 488 (Not Acceptable Here) response.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause The 200 OK response specific to the UPDATE message carries the codec
AMR.
The LST MGW command output on the MGCF(MSOFTX3000) shows

that no UMTS AMR is included in the codec list.
Condition The negotiated codecs are inconsistent.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds:
N/A
Run MOD MGW to add the UMTS AMR codec.
The LST MGW command output is as follows:

Copyright © Huawei
2.15.25 When a Called VoLTE UE Is Unavailable, the Call Is

Forwarded and Established Even If the VoLTE UE Does Not
Subscribe to the Cal Forwarding Service on the ATS of the
VoLTE Network
Involved NE: VoLTE
Defect Details
Symptom When a called VoLTE UE is unavailable, the call is forwarded and

established even if the VoLTE UE does not subscribe to the cal forwarding
service on the ATS of the VoLTE network.
Trouble N/A
Ticket
Number
Root Cause An INVITE message is sent to the UE but the UE does not respond. The
SCC AS sends the INVITE message to the CS network through the MGCF
for a CS retry.
The CS network returns a 181 response, indicating that the call is

successfully forwarded. The UE, however, does not subscribe to the call
forwarding service on the VoLTE network. Therefore, the call should have
not been forwarded even if the call message is sent to the CS network for
processing. This issue is caused by service data inconsistency between the
VoLTE and CS networks. It is confirmed with customers that no specific
service data synchronization plan has been outlined for VoLTE and CS
networks.
Condition Service data on the VoLTE and CS networks are inconsistent.
of
Occurrence

Copyright © Huawei
Involved Version
Solution
Workarounds:
N/A
N/A
It is advised to encourage customers to work out and implement a service data
synchronization plan for VoLTE and CS networks.
2.15.26 Multiple Copies of a Short Message Are Received After

the Short Message Is Sent
Involved NE: UE
Defect Details
Symptom Multiple copies of a short message are received after the short message is
sent
Trouble N/A
Ticket
Number
Root Cause In the short message terminating procedure of the LTE UE, the MESSAGE
message sent from the UEdoes not carry the In-Reply-To header field. As a
result, the IP-SM-GW fails to use Call-ID to determine that the sent
MESSAGE messages belong to the same transaction. Instead, the IP-SM-
GW considers the second MESSAGE message to be an initial MESSAGE
message and therefore retransmits the MESSAGE message.

Copyright © Huawei
Protocol description is as follows:

5.3.2.4 Sending a delivery report
When an SM-over-IP receiver wants to send an SM delivery report over IP,
the SM-over-IP receiver shall send a SIP MESSAGE request with the
following information:
a)the Request-URI, which shall contain the IP-SM-GW;
NOTE1:The address of the IP-SM-GW is received in the P-Asserted-
Identity header in the SIP MESSAGE request including
the delivered short message.
b)the From header, which shall contain a public user identity of the SM-
over-IP receiver.
c)the To header, which shall contain the IP-SM-GW;
d)the In-Reply-To header which shall contain the Call-Id of the SIP
MESSAGE request that was received in the received short message;
e)the Content-Type header shall contain "application/vnd.3gpp.sms";
f)the body of the request shall contain the RP-ACK or RP-ERROR
message for the SM delivery report, as defined in 3GPPTS24.011[8].
NOTE2:The SM-over-IP sender will use content transfer encoding of type
"binary" for the encoding of the SM in the body of the SIP MESSAGE
request.
Condition The MESSAGE message sent by the UE does not carry the In-Reply-To
header field.
of
Occurrence
Involved Version
UE
Solution
Workarounds:
N/A
Configure the UE to include the In-Reply-To header field in the MESSAGE message to be
sent.

2.16.1 CFNR Service Fails

Copyright © Huawei

Defect Details
Symptom The Call Forwarding No Reply (CFNR) service fails.

A is a VoLTE subscriber whose number is 14700241004.
B is a VoLTE subscriber whose number is 14700241003. B has subscribed
to the CFNR service with C as the forwarded-to party.
C is a CS subscriber whose number is 13955119552.
When the call from A to B encounters no reply, it fails to be forwarded to
C.
The message tracing result shows that the ATS returns a 491 message.
Trouble 4804696
Ticket
Number
Root Cause When the call from A to B encounters no reply, the precondition flow
(resource reservation flow) is started between B and C. The UPDATE
message sent from the C side (from the MGCF to the CS network) affects
the precondition flow, causing message flow collision. Consequently, the
ATS fails to process the CFNR service.
Condition  The forwarded-to party is a CS subscriber.
 B has subscribed to the CFNR service.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH210
Solution
Workarounds:
None
Perform the following operations on the MGCF:
1. Run MOD SIPTG to set Support 3gOoBTC to No, which indicates that the SDP
information does not contain the 3gOoBTC parameter.
2. Run MOD OFC with 3GoOBTC Not Send Renegotiate selected for Office extra param.
2.16.2 Voice Quality Is Poor After Calls Are Forwarded to CS

Subscribers Upon Non-Reply

Copyright © Huawei

Defect Details
Symptom The voice quality is poor after calls are forwarded to CS subscribers upon
non-reply.
A is a VoLTE subscriber whose number is 14700241004.
B is a VoLTE subscriber whose number is 14700241003. B has subscribed
to the CFNR service with C as the forwarded-to party.
C is a CS subscriber whose number is 13866170397.
When the call from A to B encounters no reply, the call is forwarded to C.
A encounters a long delay in hearing C and the voice quality is poor.
However, C hears A normally.
Trouble 4806999
Ticket
Number
Root Cause The clock frequency for the AMR codec on the MGCF is incorrectly set to
16000.
Condition  The forwarded-to party is a CS subscriber.
 The clock frequency for the AMR codec on the MGCF is incorrectly set.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH210
Solution
Workarounds:
None
On the MGCF (MSOFTX3000), run MOD CODECCFG to set the clock frequency to 8000
for the UMTSAMR and UMTSAMR2.
Note: In order not to affect the services of the live network (including the MGCF) to the
greatest extent, set the clock frequency to 8000 for the newly added UMTSAMR and
UMTSAMR2 in the office directions that interwork with the CSCF at a newly deployed
VoLTE site.
2.16.3 VoLTE Registration Fails

Involved NE: SE2900

Copyright © Huawei
Defect Details
Symptom Some VoLTE terminals, such as Huawei P7 and Mate 7, can register, but
other VoLTE terminals cannot.
Trouble 4812179
Ticket
Number
Root Cause IPsec is enabled on the terminal but it is not configured on the SE2900.
Condition The encryption data on the terminal is inconsistent with that on the
SE2900.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds:
None
Configuration item No: PSBC10 Enable IPsec Encryption
Configuration item name: Enable IPsec Encryption
Parameter description: specifies whether to enable IPsec encryption.
Default value: Disable
Recommended value: Enable (to ensure service availability, it is recommended that
AKAENABLE is set to AUTO)
Configuration method:
On the SE2900, perform the following operations:
1. Run ADD ENCRYPLC to enable IMS-AKA/IPsec and set encryption and decryption
policies.
ADD ENCRYPLC: ENPLCNAME="IMS_AKA_PLC", PRTL=IMS-AKA,
AKAENABLE=AUTO, AKAENCRYPT=AUTO, AKATCPFBEN=N;
2. Run ADD ENCRYPLCSET to configure an encryption and decryption policy set.
ADD ENCRYPLCSET: ENPLCSETNAME="IMS_AKA_PLCSET",
ENPLCNAME1="IMS_AKA_PLC";
3. Run ADD SIGPLC to configure a signaling policy (DIGESTAUTH=N) and disable Digest
authentication.

Copyright © Huawei
ADD SIGPLC: SIGPLCNAME="IMS_AKA_SIGPLC", ENTYPE=ABCF,

CONFOPTPROPOLY=N, ADDPAIDP=NONE, ADDPAIFP=NONE, DIGESTAUTH=N;
4. Run MOD SIPAN to apply the encryption and decryption policy set in the SIP AN specific
to the P-CSCF so that the IMS-AKA encryption policy takes effect for the SIP AN.
MOD SIPAN: ANNAME="A129086SIPAN1", LETYPE=P-CSCF,
PCSCFLEN="SE2900_PCSCF", SIGPLCNAME="IMS_AKA_SIGPLC",
ENPLCSETNAME=" IMS_AKA_PLCSET ";
2.16.4 SE2900 Receives a 404 Message After Sending a

SUBSCRIBE Message
Involved NE: SE2900
Defect Details
Symptom When a VoLTE subscriber registers, the SE2900 incorrectly sends a

SUBSCRIBE message to NSN S-CSCF. Consequently, NSN S-CSCF
returns a 404 message.
Actually, the SUBSCRIBE message must be sent to Huawei S-CSCF.
Trouble 4869925
Ticket
Number
Root Cause The terminal is incorrectly registered with NSN S-CSCF. The message
tracing result shows that NSN S-CSCF probably does not support
subscription.
Condition  NSN S-CSCF is used.
 The terminal sends a SUBSCRIBE message.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution
Workarounds:
None
Enable the terminal to register with Huawei S-CSCF.

Copyright © Huawei
2.16.5 CH Service Fails

Defect Details
Symptom The call hold service fails during a test. That is, after A places B on hold, A
cannot initiate a new call. In this test, Huawei Mate 7 of the B718 version
is used.
Trouble 4819110
Ticket
Number
Root Cause Due to an HMR configuration error, sendonly is deleted from the SDP
information in the INVITE message sent to the ATS. When the ATS
receives an INVITE message whose SDP information does not contain
sendonly, it determines that the Call Hold (CH) service is not triggered.
The HMR specifies header modification rules. Frontline engineers have
incorrectly configured the HMR in such a way that sendonly, instead of
maxptime, is deleted.
Condition The HMR is incorrectly configured.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
Workarounds:
None
Correct the HMR configuration.
The following is an example incorrect configuration:
ADD
HMRBDYRL:BRLNAME="Maxptime_DEL",BRSETID="Maxptime_DEL",PRIORITY=5,
BTPS=DEACTIVATED,BCPS=ACTIVATED,MHPREG="a=maxptime:240\\r\\n",BST=DEL
ETE,FINDALL=N,SEMC=N,MPA=N;
Correct configuration:
Delete \\r\\n.

Copyright © Huawei
2.16.6 CLIR Service Fails When Calls Are Addressed to

Subscribers in the 4G Network
Defect Details
Symptom A has subscribed to the Calling Line Identification Restriction (CLIR)

service that operates in permanent mode. When A calls a subscriber who
resides in a 2G network, A's number is not presented to the subscriber.
However, when A calls a subscriber who resides in a 4G network, A's
number is still presented to the subscriber.
Trouble 4871291
Ticket
Number
Root Cause The CLIR service is not triggered. The following command has been
executed on the SBC to anonymize the From header field.
MOD PCSCF: PCSCFLEN="HZPSBC12",
PHEADERPL=DEL_PRIVACY-1;
However, there is a configuration error on the SBC.
Condition  There is a configuration error on the SBC.
 VoLTE subscribers in the 2G network have subscribed to the Calling Line
Identification Presentation (CLIP) service.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC210
Solution
Workarounds:
None
Run the following commands on the SBC:
MOD PCSCF: PCSCFLEN="JNPSBC1BHW", PHEADERPL=DEL_PRIVACY-1;

Copyright © Huawei
2.16.7 MGCF Fails to Convert the ACM (User Busy) Message to a

486 Message
Defect Details
Symptom When a call is addressed to a subscriber in a CS network who is busy, the

MSC server returns an ACM message (user busy) to the MGCF. However,
the MGCF converts the ACM message to a 183 message, not a 486
message.
Trouble 4877648
Ticket
Number
Root Cause MGCF suppressing announcement playing as specified in 3GPP 29163

is not selected for Extra software parameter 5 of service control in
MOD SIPTG.
Condition FUNC29(MGCF suppressing announcement playing as specified in
3GPP 29163) is not selected for Extra software parameter 5 of service
control in MOD SIPTG.
of
Occurrence
Involved Version
Solution
Workarounds:
None
Run MOD SIPTG with FUNC29(MGCF suppressing announcement playing as specified
in 3GPP 29163) and FUNC30(Interchanging between failure cause codes and SIP status
codes as specified in 3GPP 29163) selected for Extra software parameter 5 of service
control to enable MGCF-T announcement suppressing.
MOD SIPTG: TGN="IMS_TG", ESFPARA5=FUNC29-1&FUNC30-1;
2.16.8 Announcements Are Still Played When Calls are Forwarded


Copyright © Huawei

Defect Details
Symptom The MMTel AS is configured not to play the announcement "Your call to
this number is forwarded." However, this announcement is still played
when calls are forwarded.
Trouble 4836352
Ticket
Number
Root Cause Software parameter 1933 is incorrectly set to 1, which indicates that the
announcement whose ID is 332 will be played.
Condition Software parameter 1933 is incorrectly set to 1.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC210
Solution
Workarounds:
None
Change the value of software parameter 1933 to 0.
Software parameter 1933: Determines whether the ATS9900 plays an announcement before
forwarding a call to the destination party.
= 0: The ATS9900 does not play an announcement.
=1: The ATS9900 plays the announcement whose ID is 332.
Other values are not used.
Default value: 0
2.16.9 Domain Selection Fails

Defect Details
Symptom A is a VoLTE subscriber who has registered with a VoLTE network.

B is a VoLTE subscriber who is roaming in the CS domain.

Copyright © Huawei
When A calls B, the call fails.

Trouble 4840358
Ticket
Number
Root Cause The INVITE message sent by the SCC AS does not carry the Feature-Caps
parameter. This is because data configured by running ADD CSRTCFG is
incorrect.
Condition Data configured by running ADD CSRTCFG is incorrect.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC210
Solution
Workarounds:
None
On the SCC AS, run the following command to correct the data:
MOD CSRTCFG: ICSIND=YES;
2.16.10 Video Calls from Samsung S6 Encounter an Error

Defect Details
Symptom Video calls from Samsung S6 encounter an error. However, voice calls
from Samsung S6 are normal.
Trouble 4862852
Ticket
Number
Root Cause When video calls are made using Samsung S6, the SDP information sent to
the terminating ATS exceeds 1900 bytes. Consequently, the ATS filters out
extra bytes.
It is found that when calls traverse the SE2900, the SE2900 adds the AMR-
WB AND AMR codecs again to the SDP information, causing the SDP
information to exceed the ATS's maximum length of 1900 bytes.
Condition SDP information exceeds 1900 bytes.

Copyright © Huawei
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC210
Solution
Workarounds:
None
1. Run the following command on the SBC to modify transcoding capabilities: ++
+SE2900/*MEID:5*/2015-07-14 15:03:56+08:00
O&M#1945
%%MOD TCCAP: TCCAPNAME="TC_HKABCF1", ENTYPE=ABCF,
TCPOLICY=AUDIOCODEC-1&PTIME-1&MAXPTIME-0&FAX-0&DTMF-
1&AMR_MODESET-0&AMR_MODECHG-1&ANSWER_PREFER_NBCODEC-
1&ANSWER_PREFER_WBCODEC-1&OFFER_FORBID_WBCODEC-0,
ACODEC=AMR-WB-1&AMR-1&G729-1&PCMA-1&PCMU-1, FCODEC=PCMA-
1&PCMU-1, DTMFACCESS=INBAND_2833, DTMFCORE=INBAND_2833,
NB2833PTVAL=97, WB2833PTVAL=103, DTMFINFOTYPE=DTMF_SIGNAL,
DTMFINFODURATION=270, G711PTIME=TIME_20, G723RATE=RATE_63,
G729PTIME=TIME_20, ILBCPTVAL=96, ILBCRATE=RATE_152,
AMRMSET1=RATE_0-1&RATE_1-1&RATE_2-1&RATE_3-1&RATE_4-1&RATE_5-
1&RATE_6-1&RATE_7-1, AMRPTVAL1=101, AMRPARA1=MCHGCAP_2-
1&ADD_MAXRED-1, AMRPTIME=TIME_20, AMRMPTIME=TIME_80, AMRTYPE2=Y,
AMRPTVAL2=100, AMRWBMSET=RATE_0-1&RATE_1-1&RATE_2-1&RATE_3-
1&RATE_4-1&RATE_5-1&RATE_6-1&RATE_7-1&RATE_8-1, AMRWBPTVAL=102,
AMRWBPARA=MCHGCAP_2-1&ADD_MAXRED-1, AMRWBPTIME=TIME_20,
AMRWBMPTIME=TIME_80, JBDLYFDATA=40, JBAJTFVOICE=Y, JBUPPERIOD=36,
JBDOWNPERIOD=6000, INITJBFVOICE=40, MAXJBDLYFVOICE=120,
FAXCTRL=FAX, SILSCTRL=G711FAX, T38PTIME=TIME_20, RESERVED1=0,
RESERVED2=0, RESERVED3=0, RESERVED4=0;%%
2. Install the ATS 212 patch to allow SDP information of more than 4000 bytes.
2.16.11 Calls Between VoLTE Subscribers in the 2G Network

Occasionally Fail
Involved NE: CSCF3300
Defect Details
Symptom Calls between VoLTE subscribers in the 2G network occasionally fail.

When a call failure occurs, the codec in the INVITE message sent by the

Copyright © Huawei
MGCF to the terminating S-CSCF is m=audio 548 RTP/AVP 108 8.

When the domain selection flow ends, the terminating S-CSCF sends the
roaming number to the MGCF. Then, the MGCF returns a 488 message that
contains the following information:
Warning: 399 MSX_SIPCOM "479 sipsl_rcv_mgw_info_proc, none codec
exists after force codec interset."
Reason: Q.850;cause=38;text="Network out of order"
When a call is successful, the codec in the INVITE message sent by the
MGCF to the terminating S-CSCF is m=audio 420 RTP/AVP 108 8 0 100
102.
Although the same calling and called parties and test terminals are used to
simulate successful or failed calls, the codecs sent by the MGCF to the
terminating S-CSCF are different.
Trouble 4822522
Ticket
Number
Root Cause The AMR2 codec configured on the MGCF supports multiple rates, but the
AMR2 codec configured on the MGW supports only the rate of 12.2 kbit/s.
When the offer/answer negotiation result is a rate other than 12.2 kbit/s,
calls fail.
Condition  The codecs supported by the MGCF and MGW are different.

of
Occurrence
Involved Version
CSCF V100R010C10SPH208
Solution
Workarounds:
None
Run MOD MGW to raise the limitation that only the rate of 12.2 kit/s is supported.
2.16.12 Roaming VoLTE Subscribers Fail to Register

Defect Details
Symptom When a roaming VoLTE subscriber registers, the I-CSCF queries the HSS.
The HSS returns S-CSCF capability 201. Although S-CSCF capability 201

Copyright © Huawei
is configured on the I-CSCF, the message tracing result shows that S-CSCF
capability 201 fails to be queried.
Trouble 4822522
Ticket
Number
Root Cause Only the first 100 records in the ISCAP/BSCAP table are supported. That
is, if the number of records in the table exceeds 100, the extra records are
invalid.
Condition  VoLTE subscribers are roaming.
 More than 100 records are configured in the ISCAP/BSCAP table.
of
Occurrence
Involved Versions
Solution
Workarounds:
Reduce the number of records in the ISCAP table until it is less than 100.
Install the patch of V100R010C10SPH205 or later.
2.16.13 Too Many SRV Records About the SCC AS Cause ENS
Query to Fail
Defect Details
Symptom Six SRV records about the SCC AS have been added on the ENS. During a
registration, five records are returned when an SRV query is performed and
only the aspool record is returned during an A query. The value of AUT-
STI on the SBC is NULL.
During a call, an SRV query fails with a 480 message.
Trouble 4845797
Ticket
Number
Root Cause When the CSCF queries the ENS for the TAS domain name, the CSCF
does not report an error if less than six SRV records are returned. However,
when the CSCF queries the ENS for the domain name of the SCC AS, the

Copyright © Huawei
CSCF reports an error if six or more SRV records are returned.

It is also found that the packet returned during an SRV query exceeds 512
bytes. However, UDP supports a maximum of 512 bytes.
Condition  More than five SRV records about the SCC AS have been configured on
the ENS.
 The transport protocol is UDP.
of
Occurrence
Involved Version
Solution
Workarounds:
None
On the CSCF, run the following commands to change the type of the transport protocol of
links to the ENS from UDP to TCP:
1. SCSCF: MOD SDNSL
2. ICSCF: MOD IDNSL
2.16.14 During a Conference Call, When the Conference Call

Service Subscriber Initiates a SUBSCRIBE Message, the MMTel
AS Returns a 403 Message
Defect Details
Symptom During a conference call, when the Conference Call service subscriber
initiates a SUBSCRIBE message, the MMTel AS returns a 403 message.
Trouble 4817027
Ticket
Number
Root Cause Software parameter 2325 is used for function control. It determines
whether the ATS9900 supports conference status subscription.
Software parameter 2325 applies in FMC networks.
= 0: The ATS9900 does not support conference status subscription.

Copyright © Huawei
= 1: The ATS9900 supports conference status subscription.

Default value: 0
The default value indicates that the ATS9900 does not support conference
status subscription. To enable the ATS9900 to support conference status
subscription, change the value of software parameter 2325 to 1.
Condition  Software parameter 2325 is incorrectly set.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH210
Solution
Workarounds:
None
On the ATS, change the value of software parameter 2325 to 1.
2.16.15 CS-LOCATION Information Is Not Included in ACRs

Generated for Calls Where the Called Party Is in the 2G Network
Defect Details
Symptom After domain selection to a 2/3G network for VoLTE subscribers, ACRs do
not contain CS-LOCATION information. In addition, ANI information is
different from that in normal ACRs.
Trouble 4869396
Ticket
Number
Root Cause The 200 message does not carry the PANI:CS header field. Therefore,
ACRs do not carry CS-LOCATION-INFORMATION.
UDA is obtained and then CS-LOCATION-INFORMATION is carried
only after the PANI header field is obtained.
In normal cases, when the TAS receives the PANI header field, it queries
the HSS again. The UDA returned by the HSS this time has the higher
priority. Upon reception of a 200 message (carrying the PANI header field),
the UDR/UDA message pair will be exchanged.

Copyright © Huawei
Condition  The 200 message does not carry the PANI header field.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPH210
Solution
Workarounds:
None
1. Run MOD SIPTG on the MGCF.
FUNC29(MGCF suppressing announcement playing as specifiedin 3GPP 29163) is
selected for Extra software parameter 5 of service control in MOD SIPTG. The purpose is
to enable the 200 message to carrry the PANI header field.
2. Change the value of software parameter 2348 of the ATS to 1.
Software parameter 2348 is used for function control.

Software parameter 2348: Determines whether the CS-Location-Information AVP is included in an ACR.
Software parameter 2348 applies only in FMC networks.
= 0: The CS-Location-Information AVP is not included in an ACR.
= 1: The CS-Location-Information AVP is included in an ACR.
Default value: 0
2.16.16 Subscribers Cannot Be Provisioned Because Alias

repository data download flag Is Set to TRUE
Troubleshooting Engineer: Qi Guotao (ID: 00214884)
Defect Details
Symptom On the ATS9900 Management page of the SPG2800 web portal, ADD
MSR fails with "Result/ResultCode=22007;
Result/ResultDesc=NCVoLTETAS1-Data cannot be modified."
Trouble N/A
Ticket
Number
Root Cause This issue is related to Whether alias repository data supports

Copyright © Huawei
datareference value 0 in SET HSYSTEMPARA. Whether alias

repository data supports datareference value 0 indicates that the HSS
processes alias repository data through datareference=0. It is found that
Whether alias repository data supports datareference value 0 is set to
true.
Alias repository data download flag also needs to be modified on the
ATS. Alias repository data download flag determines whether the Data-
Reference AVP in a request message can be set to
20(AliasesRepositoryData) when repository data needs to be downloaded
for subscribers in an alias set. 20(AliasesRepositoryData) indicates that
alias repository data needs to be downloaded from the HSS. Alias
repository data download flag applies only in FMC networks.
Value:
FALSE: The Data-Reference AVP is set to 0(RepositoryData).
TRUE: The Data-Reference AVP is set to 20(AliasesRepositoryData).
As stipulated in 3GPP specifications, the Data-Reference AVP must be set
to RepositoryData. Currently, the default value on the ATS is
AliasRepositoryData. Therefore, the value must be changed to
RepositoryData.
Condition  The current network is an FMC network.
 Alias repository data download flag is set to TRUE.
 Whether alias repository data supports datareference value 0 in SET
HSYSTEMPARA (run on the HSS) is set to true
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
MOD SPCFG: ALREPDATA=false;
2.16.17 Running ADD SBR on the MMTel AS Fails with the

Internal Error Code 10010505
Defect Details
Symptom Running ADD SBR on the MMTel AS fails with the internal error code
10010505. The following is an snapshot of the error message:

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause The domain name of the MMTel AS is

mnc000.mcc460.3gppnetwork.org, but the source domain name of the
MMTel AS in a PUR message is ims.mnc000.mcc460.3gppnetwork.org.
Condition  The current network is an FMC network.
 The ATS interworks with the HSS through the DRA.
 The domain name of the MMTel AS is different from the MMTel AS's
domain name configured on the HSS.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
Change the MMTel AS's domain name on the HSS to be the same as the domain name of the
MMTel AS.
MOD DMPE: EN="VoLTETAS2", PEERTYPE=AS,
DN="ims.mnc000.mcc460.3gppnetwork.org ";
2.16.18 Precondition Fails on a CS-to-VoLTE Call Due to Incorrect

Software Parameter Setting on the MGCF
Defect Details
Symptom When a CS subscriber calls a VoLTE subscriber, precondition fails.

This is because the MSOFTX3000 does not send an UPDATE message to
the VoLTE subscriber to update media information (indicating that
resources have been reserved for the calling party).
Trouble N/A
Ticket
Number
Root Cause Bit 3 of P1536 determines whether the MSOFTX3000 sends an UPDATE
message to the peer end if the "a=curr:" line in a 18x message received

Copyright © Huawei
over the SIP trunk meets the requirements of the "a=conf:" line. If this
parameter is set to 0, the MSOFTX3000 sends an UPDATE message. If
this parameter is set to 1 (default value), the MSOFTX3000 does not send
an UPDATE message. Bit 3 of P1536 is set to the default value 1.
 The current network is an FMC network.
 A CS subscriber calls a VoLTE subscriber, and the precondition function
needs to be started.
 Bit 3 of P1536 is set to the default value 1.
of
Occurrence
Involved Version
MSOFTX3000VV200R010C20SPH111
Solution
In the MML Command - MSOFTX3000 window of the OMU client, run the following
command:
2.16.19 Access-Network-Information AVP Does Not Contain the

Area Code Due to Incorrect Data Configuration on the SBC
Involved NE: SE2900
Defect Details
Symptom The Access-Network-Information AVP in CDRs of VoLTE calls does not

contain the area code.
Trouble N/A
Ticket
Number
Root Cause The value of Access network domain name must start with sbc. If the
value starts with characters other than sbc, the area code cannot be
included in the Access-Network-Information AVP.
ADD
LAMAP:LAMAPN="LAMAP_0791",LOCTAI="4600069B0",ANUM="
0791";
ADD
SIGPLC:SIGPLCNAME="PCSCF_SIGPLC",ENTYPE=ABCF,ADDPUP
=Y,ADDPAIDP=SBCD,ANDN="psbc1.jx.chinamobile.com",ADDPAIFP
=NONE,SIGNAT=BASE_HEADER,KEEPLIVE=UDPPKG,FUVH=N,S

Copyright © Huawei
DRSP=N,UNREGRSP=500,DISLINKRSP=408,DIGESTAUTH=N,IGUN
=N,CLSPRECND=N,ADDPA=Y,DELLOCRR=Y,HDNAT=Y;
 The value of Access network domain name configured on the SE2900
does not start with sbc.
of
Occurrence
Involved Version
SE2900 V300R001C10SPC100
Solution
In the MML Command - SE2900 window of the OMU client, run the following command:
MOD SIGPLC: SIGPLCNAME="PCSCF_SIGPLC", ENTYPE=ABCF, ADDPAIDP=SBCD,
ANDN="sbc1.jx.chinamobile.com";
2.16.20 IMS Announcement Fails Because the SCC AS Does Not

Carry the ICS Capability Indicator
Defect Details
Symptom VoLTE subscribers A, B, and C belong to one home network. B roams to a

CS network and has been configured with the Call Waiting (CW) and
conference services. When A calls B who is on a call with C, A hears a CS
announcement other than an IMS announcement.
Trouble N/A
Ticket
Number
Root Cause The INVITE message sent by the ATS does not contain Feature-Caps:*;
+g.3gpp.ics, notifying the MGCF that the call is to be routed to a CS
network. If the INVITE message contains Feature-Caps:*;+g.3gpp.ics, the
MGCF prevents the CS domain from playing a ring back tone or failure
announcement to the calling party.
ICS capability indicator is set to NO(NO) for the ATS.
%%LST CSRTCFG:;%%
The result is as follows:
------------

Copyright © Huawei
CS route mode = Use CSRN

ICS capability indicator = NO
 ICS capability indicator is set to NO(NO) for the ATS.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
In the MML Command - ATS9900 window of the OMU client, run the following command:
MOD CSRTCFG: ICSIND=YES;
2.16.21 CDRs Generated for VoLTE-to-VoLTE Calls Do Not

Contain the TADS-Indication Due to Software Parameter Setting
on the ATS
Defect Details
Symptom The CDRs generated for a VoLTE-to-VoLTE call do not contain the TADS-
Indication. Normal CDRs contain the following parameters:
Emulational-Service-Type : Empty value
User-to-User-Signalling1-Count : Empty value
Calling-Party-Sub-Addressing : Empty value
Called-Party-Sub-Addressing : Empty value
TADS-Indication : {LTE}
Trouble N/A
Ticket
Number
Root Software parameter P2318 is set to 0 other than 1.

Cause P2318 determines whether the ATS includes the TADS-Indication AVP in an
ACR message when a call addressed to a VoLTE subscriber is to be routed
to an IMS network.
= 0: The ACR message does not contain the TADS-Indication AVP.

Copyright © Huawei
= 1: The ACR message contains the TADS-Indication AVP, which is set to

LTE.
Probabilit This issue will occur when the preceding conditions are met.
y of
Occurrenc
e
Involved Version
ATS9900 V100R006C10SPC200
Solution
In the MML Command - ATS9900 window of the OMU client, run the following command:
2.16.22 CFNR Calls to 2G/3G Subscribers Fail Due to Precondition

Degrade Configuration on the MGCF
Defect Details
Symptom A and C are 2G/3G subscribers, and B is a VoLTE subscriber. A calls B, and
B does not answer the call. The call is forwarded to C but fails.
This is because the MGCF releases the call upon receiving an UPDATE
message that contains the precondition information.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Bit 7 of P1535 is set to 1. This software parameter determines whether the
Cause MGCF supports degrade for the "a=des:" line upon receiving an UPDATE
message.
= 0: The MGCF supports degrade for the "a=des:" line.
= 1: The MGCF does not support degrade for the "a=des:" line.
Default value: 1
 Bit 7 P1535 of MSOFTX3000 is set to 1.
y of
Occurrenc
e
Involved Version
Solution
command:
2.16.23 Call Waiting Tone Is Not Played Due to Data

Configuration on the MGCF When the Service Subscriber Is on a
CS Network
Defect Details
Symptom VoLTE subscribers A, B, and C belong to one home network. The CW

service has been configured and activated for B who is attached to a 2G
network. C calls B, and B answers the call. When B communicates with C,
A calls B, and B receives a prompt indicating that there is an incoming call
from A. A does hear a calling waiting tone. When B receives a prompt
indicating that there is an incoming call from A, the MGCF sends a 182
message other than a 180 message to the CSCF.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root The configuration is as follows:

Cause The 180 message sent by the MGCF contains SDP information for media
negotiation with A. The SDP information contains the P-Early-Media and
Alert-Info header fields, and the Alert-Info header field is set to
<urn:alert:service:call-waiting>. After receiving the 180 message, the ATS
detects that A has subscribed to the CW service and requests the MRFP to
play a call waiting tone.
To enable the MGCF to interwork with the CSCF, Extra software
parameter 18 of service control must be configured to support the Call
waiting service interworking function. If Call waiting service
interworking is selected, the MGCF includes the Alert-Info header field in
the 180 message sent to the previous hop when the CW service is triggered
for the called party. If Call waiting service interworking is deselected, the
MGCF does not include the Alert-Info header field in the 180 message sent
to the previous hop when the CW service is triggered for the called party.
However, Call waiting service interworking is deselected for Extra

Copyright © Huawei
 Call waiting service interworking is deselected for Extra software
parameter 18 of service control.
y of
Occurrenc
e
Involved Version
Solution
command:
MOD SIPTG: TGN="VoLTE_SCSCF_HGT_01", ESFPARA=SRV18-1;

Copyright © Huawei
2.16.24 Local Call Number Presentation Fails Because the HSS

Provided by the Ericsson Does Not Support Download of the
Shared Alias Group ID Using an SAR Message
Defect Details
Symptom On a local VoLTE-to-VoLTE call, national numbers are displayed in the

format of global numbers.
Trouble 4913910
Ticket
Number
Root The HSS provided by Ericsson does not return the shared Alias group ID
Cause using an SAA message. The S-CSCF cannot add tel URIs to the From and
P-Asserted-Identity header fields. Consequently, the ATS fails to adjust the
calling number presentation mode for SIP URIs. Bit 8 of SCSCFPARA29
determines whether the S-CSCF adds tel URIs to the From and P-Asserted-
Identity header fields.
 The S-CSCF interworks with an HSS provided by Ericsson.
 Bit 8 of SCSCFPARA29 is set to 1.
y of
Occurrenc
e
Involved Version
CSC3300 V100R010C10
Solution

Copyright © Huawei
In the MML Command - CSC3300 window of the OMU client, run the following command:
2.16.25 ATS Service Provisioning Fails Due to Inconsistent

Service Rights on the HLR and ATS
Involved NEs:HSS9860 and ATS9900
Defect Details
Symptom After basic VoLTE account creation is performed on the HLR, service
provisioning by running MOD MSR on the in the MML Command -
ATS9900 window of the OMU client fails. The ATS9900 returns error code
22002 indicating that service provisioning fails.
In the user message tracing created on the ATS, the ATS sends a PUR
message containing the IP-SM-GW data to the HSS, the HSS returns a PUA
message containing DIAMETER_UNABLE_TO_COMPLY. Other
repository data is successfully sent to the HSS.
Trouble 4924120
Ticket
Number
Root The IP SMS service has not been configured for the subscriber on the
Cause HSS9860.
HLRSN = 1
IMSI = 4xxxxxxxxxxxxx
ISDN = 9xxxxxxxxx
CardType = USIM

Copyright © Huawei
NAM = BOTH
CATEGORY = COMMON
"SABLOCK"
"Basic Service"
Telephony (TS11)
Emergency Call (TS12)
General-DataCDS (BS30)
Data CDA-9600bps (BS26)
DefaultCall = Telephony (TS11)
 Supplementary service rights on the ATS and HSS9860 are inconsistent.
y of
Occurrenc
e
Involved Version
ATS9900 V100R006C10SPC200HSS9860 V900R008C30SPC100
Solution
Configure IP SMS service rights on the HSS9860.

Copyright © Huawei
11) Historical ProblemsHistorical Problems
3 Historical Problems
3.1 Calls Fail Because Terminals Do Not Support Dynamic Establishment of TCP
Connections
3.2 ATS9900 Does Not Support Anchor IDP Messages with Variable-Length ASN.1 Coding
3.3 Active VCU Process Occasionally Fails If the Format of the URI List for Conference
Creation Does Not Comply with the Interface Definition
3.4 SBC Proactively Sends a BYE Message to Release the Call Initiated by an IPSec AKA
Authentication Subscriber over TCP During Reregistration
3.5 One-Way Media Occurs After an aSRVCC Handover
3.6 Call Fails to Be Retrieved After an SRVCC Handover Is Performed for a Hold Subscriber
3.7 utran-cell-id-3gpp Cannot Be Recorded in CDRs When the P-Access-Network-Info
Header Field in an INVITE Message Exceeds 170 Bytes
3.8 SCC AS Does Not Send a MESSAGE Message When the Feature-Caps Header Field in a
REGISTER Message Exceeds 512 Bytes
3.9 MGCF Returns a 400 Message After Receiving an INVITE Message for a Video Call
Initiated by a VoLTE Subscriber to a CS Subscriber
3.10 One-Way Media Occurs When a VoLTE Subscriber Calls a CS Subscriber
3.11 SCU Modules Are Overloaded When Multiple UEs in the Same Implicit Registration
Set Are Traced
3.12 Call Forwarding Fails If the Precondition Function Is Enabled
3.13 Extra-long CDRs Are Generated by the ATS9900
3.14 SBC Returns an Error Because the Calling Party Hangs Up After an eSRVCC Handover
Occurs But Before the Called Party Answers the Call
3.15 VoLTE Call Fallback Occurs Due to USSDs Delivered by the CN Side
3.16 3G SRVCC Handover Fails in the Separate Deployment Scenario
3.17 Internal Tracing Logs About Subscriber Message Tracing Cannot Be Displayed

Copyright © Huawei
3.1 Calls Fail Because Terminals Do Not Support Dynamic

Establishment of TCP Connections
Involved NE: SE2900
Application Scope: global
Defect Details
Symptom When a CS subscriber calls a VoLTE subscriber, an INVITE message is

sent to the terminating SBC. Then the terminating SBC returns a 100
message and then a 499 message whose Warning header field is Client Tpt
Internal Error.
Trouble N/A
Ticket
Number
Root Cause
After checking the 499 message whose Warning header field is Client Tpt
Internal Error, it is found that the SBC returns the 499 message 30
seconds after it receives the INVITE message. This indicates that the error
does not occur during service processing. In normal conditions, an error
message is sent immediately when a service processing failure occurs. The
packet capturing result shows that the SBC did not forward the INVITE
message.
If the SBC receives an INVITE message that exceeds 1500 bytes, it will try
to forward the INVITE message based on data configurations. If the
terminal does not support dynamic establishment of a TCP connection, the
SBC will return a 449 message.
/* MOC = ENCRYPLC */ADD
ENCRYPLC:ENPLCNAME="AKA",PRTL=IMS-
AKA,AKAENABLE=AUTO,AKAENCRYPT=AUTO,AKATCPFBEN=
N,AKATCPFBVAL=1500;
/* MOC = ENCRYPLCSET */ADD
ENCRYPLCSET:ENPLCSETNAME="AKA_PLCSET",ENPLCNAME1
="AKA";
/* MOC = SIPAN */ADD
SIPAN:ANNAME="P_SBC_IPV6",LETYPE=P-
CSCF,ADDRNAME="P_ACCESS_IPv6",PCSCFLEN="HZPSBC12",AN
T=E-
UTRAN,IPTYPE=IPV6,UEIPV6="0:0:0:0:0:0:0:0",PRELEN=0,ANMEDI
ADN="ACCESS_MEDIA_MEDDN_IPv6",FROUTING=N,RTNAME="T
O_HZCSCF04",ERTNAME="ECSCF_URI",BUFREGPLY=UNSUPPORT
,IPSETID="in-invite-del-
fork",OPSETID="out_hmr_pmark03",APCEC=Y,CC="8",AID="6",SIGPL
CNAME="PCSCF_SIGPLC",ENPLCSETNAME="AKA_PLCSET",BCP
LCNAME="DEFAULTABCFBCPLC",TCCAPNAME="TC_PSBC01",F
WTENABLE=Y,EMCC=REJEMCC-1&REJUNREGEMCC-
0&EREGEMCC-0&REJNONEREGCALL-0&REJEMCCHLD-
0,MATCHTYPE=WHOLE-
MATCH,CMDENABLE=Y,ESRVCC=Y,ISPBX=N,RESERVED1=0,RESE

Copyright © Huawei
RVED2=0,RESERVED3=0,RESERVED4=0;
 The SBC is configured to support TCP fallback.
 The length of an INVITE message sent in the terminating flow exceeds
the packet length set for TCP fallback on the SBC (1300 bytes by
default).
 The terminal has initiated a registration through UDP. The terminal does
not support dynamic establishment of TCP connections as the called
party.
of
Occurrence
Involved Versions
SE2900 V300R001C10SPC100
SE2900 V300R001C20SPC100
Solution
Workarounds:
If any terminal on the VoLTE network does not support dynamic establishment of TCP
connections, change the value of Packet length threshold for TCP fallback to 65535 in the
AKA encryption policy.
MOD ENCRYPLC: ENPLCNAME="AKA", PRTL=IMS-AKA, AKATCPFBEN=N,
AKATCPFBVAL=65535;
Dynamic TCP fallback is a basic capability defined in RFC 3261 (SIP protocol). It is
recommended that frontline engineers coordinate with customers to promote terminal
adjustment.
3.2 ATS9900 Does Not Support Anchor IDP Messages

with Variable-Length ASN.1 Coding
Application Scope: global
Defect Details
Symptom The MSC sends an anchor IDP message with variable-length ASN.1 coding
to the ATS9900, but the ATS9900 fails to process the message and returns
cap-errcode-missingparameter (7). Variable-length ASN.1 coding uses the
TLV structure, in which the Length field is 0x80 and the Value field ends
with two consecutive 0x00s.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause The ATS9900 does not support IDP messages with variable-length coding.
 The anchor IDP messages sent by the MSC use unfixed-length coding.
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
This issue has been resolved in ATS9900 V100R006C10SPH207.
After the V100R006C10SPH207 patch is installed, the ATS9900 can resolve IDP messages
with unfixed-length coding.
3.3 Active VCU Process Occasionally Fails If the Format of

the URI List for Conference Creation Does Not Comply
with the Interface Definition
Application Scope: global (An iPhone6 is used for a VoWiFi test.)
Defect Details

Copyright © Huawei
Symptom If the URI-list-based mode is used to create a conference, the active VCU
process occasionally fails when the format of the URI list does not comply
with the interface definition.
Trouble N/A
Ticket
Number
Root Cause The internal protection is insufficient. As a result, the active VCU process
occasionally fails if the format of the URI list in the INVITE message
does not comply with the interface definition.
Condition This issue may occur when both of the following conditions are met:
 The URI-list-based mode is used, and the format of the URI list in the
INVITE message for conference creation does not comply with the
interface definition.
To be specific, the INVITE message carries the multipart body. In the
multipart body, multiple Content-Type fields are contained. The first
Content-Type is in Content-Type: multipart/mixed format and the other
Content-Type fields are not in Content-Type: application/resource-
lists+xml format.
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
After the V100R006C10SPH207 patch is installed, the ATS9900 can process conference call
requests carrying an invalid URI list.
3.4 SBC Proactively Sends a BYE Message to Release the

Call Initiated by an IPSec AKA Authentication Subscriber
over TCP During Reregistration
Involved NE: SE2900
Application Scope: global (A MediaTek terminal is used for a VoLTE test.)
Defect Details
Symptom After a call is set up over TCP for a subscriber who uses IPSec AKA
authentication, the subscriber initiates a reregistration. 100 to 300 seconds
later, the call is released. The message tracing result shows that the SBC

Copyright © Huawei
sends a BYE message carrying Reason:

Q.850;cause=31,SIP;text="A.450.403.228.0.0.00112.00000000
Released the session because of released by SIP STACK".
Trouble N/A
Ticket
Number
Root Cause In the IPSec-AKA scenario, the subscriber successfully initiates a call
after registering with the network. The subscriber then initiates a
reregistration, during which a 401 message is sent to re-negotiate security
association (SA). After successful SA negotiation, the SBC releases the
TCP link established based on the original SA result. When the SBC
performs link verification and detects that the TCP link for the established
session is interrupted, it proactively releases the session.
 TCP link verification is enabled on the SBC.
 A subscriber who uses IPSec AKA authentication has established a call
over a TCP link.
 A 401 message is sent for reregistration during the call.
of
Occurrence
Involved Version
SE2900V300R001C20 (TR5 version)
Solution
This issue has been resolved in SE2900V300R001C20SPC100 (GA version).
After the SE2900 is upgraded to this GA version, the SBC will not perform verification on
dynamic TCP links in the IPSec-AKA scenario.
3.5 One-Way Media Occurs After an aSRVCC Handover

Involved NE: SE2900
Defect Details
Symptom In an alerting SRVCC (aSRVCC) test, the calling party keeps on the
VoLTE network and the called party hands over to the GSM network.
After the handover, the called party cannot hear the calling party but the
calling party can hear the called party.
Trouble N/A
Ticket
Number

Copyright © Huawei
Root Cause During the initial call setup, the voice codec is AMR-WB. When a
handover occurs, the INVITE message sent by the eMSC to the ATCF for
handover contains only AMR-NB.
The Transcode policy parameter in the transcoding capability data record
configured for the SIPAN of the ATCF contains the value
OFFER_FORBID_WBCODEC(Disallowing broadband codec
negotiation in offer processing). This value indicates that the SBC
instructs the BGF not to add wideband codecs to the SDP offer forwarded
to the answerer during media negotiations and checks if the offerer uses
narrowband codecs. If this value is not selected, the BGF can add
wideband codecs to the SDP offer forwarded to the answerer during media
negotiations and checks no matter whether the offerer uses wideband
codecs.
When the SBC detects that the terminating side uses wideband codec but
the originating side uses narrowband codec, it discards the AMR-WB
media packet sent from the terminating side but does not forward the
packet.
After the ATCF receives an INVITE message for handover, it determines
that the call to be handed over uses the broadband codec AMR-WB. As
the ATCF is configured not to add wideband codecs, it is intended to
forward such a message through SRVCC but the ATCF incorrectly
forwards the message through eSRVCC due to an code logical error. As a
result, the signaling is normal but the RTP packet carrying AMR-WB from
the terminating side is discarded, causing one-way media. This issue has
been resolved in versions later than SE2900 V300R001C20. To solve this
issue in SE2900 V300R001C20, modify data configurations.
 The AMR-WB codec is used during conversation.
 The INVITE message sent by the eMSC to the ATCF for handover
contains only AMR-NB.
 The value OFFER_FORBID_WBCODEC is selected for the ATCF.
of
Occurrence
Involved Version
SE2900 V300R001C20SPC100
Solution
To resolve this issue in SE2900 V300R001C20, deselect the value
OFFER_FORBID_WBCODEC(Disallowing broadband codec negotiation in offer
processing) of the Transcode policy parameter in the transcoding capability data record
configured for the SIPAN of the ATCF.
MOD TCCAP: TCCAPNAME="XXX", TCPOLICY=OFFER_FORBID_WBCODEC-0;

Copyright © Huawei
In SE2900 V300R002C00 or later, the value OFFER_FORBID_WBCODEC(Disallowing

broadband codec negotiation in offer processing) has been deselected for INVITE
processing in an eSRVCC handover. To be specific, the SBC adds wideband codecs. The
subsequent negotiation (for example, REINVITE) is performed based on TCCAP
configurations.
3.6 Call Fails to Be Retrieved After an SRVCC Handover Is

Performed for a Hold Subscriber
Involved NE: eMSC (MSOFTX3000)
Defect Details
Symptom VoLTE subscriber A calls VoLTE subscriber B. After the call is set up, A
places B on hold and triggers an SRVCC handover. After the handover is
complete, A requests to retrieve B. Then the MSC sends a REINVITE
message carrying only PCMA, which is transparently transmitted to B. As
B does not support PCMA codec, B rejects the request and returns a 488
message. As a result, the call with B fails to be retrieved.
Trouble N/A
Ticket
Number
Root Cause The message tracing result shows that VoLTE subscriber B returns a 488
message after receiving PCMA.
Through further analysis, it is found that the REINVITE message sent by

the eMSC to the SBC carries PCMA and the SBC does not perform TC
conversion.
//Note: In the current version, the SBC does not support TC addition
during re-negotiation.
Through analysis of messages on the eMSC, it is found that the

REINVITE message received by the eMSC from the vMSC carries PCMA
and the eMSC transparently transmits the message.
//Note: On the live network, the PCMA codec is forcibly used between the
vMSC and the eMSC.
During re-negotiation, if the eMSC detects that the re-negotiated codec

Copyright © Huawei
has no intersection with the previously negotiated codec and that the peer
end is the ATCF or IMS, the eMSC can determine whether to transparently
transmit the REINVITE message. However, the eMSC determines to
transparently transmit the REINVITE message.
 A REINVITE message is sent after a party places an intra-VoLTE call on
hold.
 The PCMA codec is forcibly used between the vMSC and the eMSC.
 The ESFPARA2 parameter is set to SRV16-0 in the SIP trunk group
data record on the eMSC.
of
Occurrence
Involved Version
Solution
Change the value of the ESFPARA2 parameter for the SIP trunk group destined for the IMS
and ATCF on the eMSC to SRV16-1.
MOD SIPTG: TGN="JDN_IMS1_SCSCF", ESFPARA2=SRV16-1;
3.7 utran-cell-id-3gpp Cannot Be Recorded in CDRs When

the P-Access-Network-Info Header Field in an INVITE
Message Exceeds 170 Bytes
Defect Details
Symptom The P-Access-Network-Info header field in the INVITE message received by

the ATS carries utran-cell-id-3gpp, but the pAccessNetworkInfo information
element in the ACR message sent by the ATS does not carry utran-cell-id-
3gpp. As a result, utran-cell-id-3gpp is absent from CDRs, which affects

Copyright © Huawei
charging.
Trouble N/A
Ticket
Number
Root The ATS supports the P-Access-Network-Info header field carrying a

Cause maximum of 170 bytes. If the P-Access-Network-Info header field exceeds
170 bytes, the ATS does not record the P-Access-Network-Info field value.
In the VCU deployment, the ATS obtains the P-Access-Network-Info header
field as follows:
1. The ATS preferentially obtains the P-Access-Network-Info header field
from an INVITE message.
2. If the INVITE message does not carry the P-Access-Network-Info header
field or the carried P-Access-Network-Info header field exceeds 170 bytes,
the ATS obtains the P-Access-Network-Info header field from a third-party
REGISTER message.
3. If the third-party REGISTER message does not carry the P-Access-
Network-Info header field or the carried P-Access-Network-Info header field
exceeds 170 bytes, the ATS does not record the P-Access-Network-Info
header field in a sent message.
As the P-Access-Network-Info header field carried in the INVITE message
exceeds 170 bytes but that carried in the third-party REGISTER message
carries less than 170 bytes, the ATS records the P-Access-Network-Info
header field carried in the third-party REGISTER message. However, this
header field does not contain utran-cell-id-3gpp.
 The P-Access-Network-Info header field exceeds 170 bytes.
y of
Occurrenc
e
Involved Version
ATS9900 V100R006C10SPC200
Solution
Test patch: ATS9900 V100R006C10SPH938T (developed on the basis of SPH208)
Formal patch: ATS9900 V100R006C10SPH212
Note: Confirm with the customer that the first 170 bytes in the P-Access-Network-Info
header field indicate the utran-cell-id-3gpp field.
After the patch is installed, change the value of P2376 to 1. The value 1 indicates that the ATS
obtains the first 170 bytes in the P-Access-Network-Info header field in an INVITE message
and stores the 170-byte string as the value of the [Access-Network-Info] AVP in CDRs if the
P-Access-Network-Info header field exceeds 170 bytes.

Copyright © Huawei
P2376 determines whether the ATS supports INVITE messages whose P-Access-Network-Info header
field exceeds 170 bytes.
= 0: The ATS does not support INVITE messages whose P-Access-Network-Info header field exceeds
170 bytes.
= 1: The ATS supports INVITE messages whose P-Access-Network-Info header field exceeds 170 bytes.
In this case, the ATS obtains the first 170 bytes in the P-Access-Network-Info header field in an INVITE
message and stores the 170-byte string as the value of the [Access-Network-Info] AVP in CDRs.
Default value: 0
3.8 SCC AS Does Not Send a MESSAGE Message When

the Feature-Caps Header Field in a REGISTER Message
Exceeds 512 Bytes
Defect Details
Symptom The SCC AS does not send a MESSAGE message when the Feature-Caps
header field in a REGISTER message exceeds 512 bytes.
Trouble N/A
Ticket
Number
Root The SCC AS supports the Feature-Caps header field carrying a maximum of
Cause 512 bytes. If the Feature-Caps header field exceeds 512 bytes, the SCC AS
fails to obtain the Feature-Caps header field and therefore does not send a
MESSAGE message.
 The subscriber has subscribed to SRVCC capabilities, including STN-SR
and C-MSISDN.
 The UE supports the SRVCC function.
 The registration message carries +g.3gpp.atcf-mgmt.
y of
Occurrenc
e
Involved Version
ATS9900 V100R006C10SPC200

Copyright © Huawei
Solution
After the V100R006C10SPH207 patch is installed, the SCC AS deletes parameter description
in URI but only stores basic data if the Feature-Caps header field exceeds 523 bytes but is less
than 1024 bytes. This processing ensures that valid information is stored for subsequent flows.
3.9 MGCF Returns a 400 Message After Receiving an

INVITE Message for a Video Call Initiated by a VoLTE
Subscriber to a CS Subscriber
Involved NE: MGCF (MSOFTX3000)
Application Scope: global (An HTC terminal is used for a VoLTE test.)
Defect Details
Symptom The MGCF returns a 400 message after receiving an INVITE message for a
video call initiated by a VoLTE subscriber to a CS subscriber. As a result,
the video call cannot be fallen back to a voice call.
The message tracing result shows that the 400 message carries Warning:
399 MSX_SIPCOM "10039 OFFER RECEIVE FAILED!".
Trouble N/A
Ticket
Number
Root The SDP in the INVITE message for the video call carries the H.264 codec.
Cause The a=fmtp attribute line contains sar-understood=16;sar-supported=1
that is not recognized by the MGCF (MSOFTX3000).
m=video 18516 RTP/AVP 113 114
b=AS:1183
b=RS:600
b=RR:2000
a=rtpmap:113 H264/90000
a=rtpmap:114 H264/90000
a=curr:qos local none
a=curr:qos remote none

Copyright © Huawei
a=des:qos mandatory local sendrecv

a=des:qos optional remote sendrecv
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=rtcp-fb:* ccm fir
a=rtcp-fb:* ccm tmmbr
a=sendrecv
a=extmap:2 urn:3gpp:video-orientation
a=tcap:1 RTP/AVPF
a=pcfg:1 t=1
As defined by the internal processing mechanism, the MSOFTX3000 does
not perform subsequent processing but directly returns a failure when
receiving a message carrying unidentifiable parameters.
 The INVITE message for a SIP incoming video call carries the H.264
codec.
 The a=fmtp attribute line contains unidentifiable parameters.
y of
Occurrenc
e
Involved Version
Solution
This issue has been resolved in MSOFTX3000 V200R010C20SPH114.
After the V200R010C20SPH114 patch is installed, the MSOFTX3000 ignores unidentifiable
parameters carried in the received H.264 codec.
3.10 One-Way Media Occurs When a VoLTE Subscriber

Calls a CS Subscriber
Involved NE: SE2900
Defect Details
Symptom A VoLTE subscriber who roams to Guangzhou initiates a call to a CS

subscriber in Shenzhen. One-way media occurs after the call is set up. To be
specific, the CS subscriber can hear the VoLTE subscriber but the VoLTE
subscriber cannot hear the CS subscriber.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root The payload type (PT) of the media packet received by the SE2900 from the
Cause code side is different from the PT used during SDP offer/answer negotiation
at the signaling plane. As a result, verification fails and packet loss occurs,
which causes one-way media.
1. During initial negotiation, the SDP offer/answer uses the AMR codec in
which the PT is 106.
2. After the UE initiates renegotiation, the SDP offer sent by the SE2900 to
the core side carries three AMR codecs whose PTs are 106, 114, and 115,
respectively.
v=0
o=- 3220 3220 IN IP4 10.132.171.1
s=SBC call
c=IN IP4 10.132.171.1
t=0 0
m=audio 13088 RTP/AVP 106 102 113 114 115 18 8 0
b=AS:29
b=RR:1387
b=RS:462
a=rtpmap:106 AMR/8000/1
a=fmtp:106 mode-change-capability=2;max-red=0
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
a=maxptime:240
a=sendrecv
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory remote sendrecv
a=rtpmap:113 AMR-WB/16000
a=rtpmap:114 AMR/8000
a=fmtp:114 mode-change-period=2
a=rtpmap:115 AMR/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
3. The SDP answer received by the SE2900 from the core side shows that
the peer end does not use the AMR codecs carried in the SDP offer but
uses the AMR codec whose PT is 100. In addition, the SDP answer

Copyright © Huawei
contains many other attributes.

v=0
o=- 1663292567 3180377534 IN IP4 10.131.158.1
s=-
c=IN IP4 10.131.157.21
t=0 0
a=sendrecv
m=audio 7548 RTP/AVP 100 102
c=IN IP4 10.131.157.21
b=RR:1087
b=RS:362
a=rtpmap:100 AMR/8000/1
a=fmtp:100 mode-set=0,2,4,7;mode-change-period=2;mode-change-
capability=2;mode-change-neighbor=1;max-red=0
a=rtpmap:102 telephone-event/8000
a=fmtp:102 0-15
a=ptime:20
a=maxptime:40
a=curr:qos local sendrecv
a=curr:qos remote sendrecv
a=des:qos mandatory remote sendrecv
4. As the AMR attribute in the received SDP answer is different from all
AMR attributes in the sent SDP offer and the mode-change-period field
has high requirements on compatibility, the SE2900 has to select the
nearest AMR codec (that is, the AMR codec whose PT is 114) as the local
PT attribute.
5. Actually, the peer end (core side) sends media packets by using PT 106,
which is different from the local and remote PTs selected by the SE2900.
Therefore, the SE2900 discards the media packets, resulting in one-way
media.

Copyright © Huawei
Condition This issue occurs when the codec in the SDP answer returned by the peer end
is different from all codecs in the SDP offer sent by the SE2900 and the PT
used by the peer end to send media packets is inconsistent with the SDP
negotiation result.
y of
Occurrenc
e
Involved Version
SE2900 V300R001C10SPC100
Solution
Deselect the value AMR_MODESET(AMR mode set conversion) of the Transcode policy
parameter in the transcoding capability data record configured for the SIPAN of the SE2900.
This configuration enables the terminal and core side to negotiate with each other.
MOD TCCAP: TCCAPNAME="XXX", TCPOLICY=AMR_MODESET-0;

Copyright © Huawei
3.11 SCU Modules Are Overloaded When Multiple UEs in

the Same Implicit Registration Set Are Traced
Defect Details
Symptom A message tracing task is created for multiple UEs in an implicit registration
set. After a UE in the implicit registration set initiates a registration or call,
the CPU usage of some SCU modules rises to 100%. As a result, SCU
modules are overloaded.
Trouble N/A
Ticket
Number
Root After a message tracing task is created for multiple UEs in an implicit
Cause registration set, the CSCF allocates a tracing handle for each tracing task.
When a UE in the implicit registration set initiates a registration or call, the
SCU module processing the registration or call request associates all tracing
handles of the implicit registration set and sends a broadcast message to
notify other modules. If the UE's data is also present on an SCU module that
receives the broadcast message, the SCU module also associates tracing
handles and sends a broadcast message. In this case, multiple SCU modules
associate tracing handles and send a broadcast message, leading to a CPU
usage surge.
 Two or more SCU modules are configured for the CSCF.
 A UE is not registered, and a message tracing task is created for multiple
UEs in the implicit registration set to which the UE belongs.
 MOD PACN is run to set From large PBX to Yes, STR EVEN is run to
balance the number of subscribers on SCU modules, or the UE has both
registered and unregistered services. Any of the preceding scenarios
causes the data of the UE to be present on multiple SCU modules.
 The UE initiates a registration or call.
y of
Occurrenc
e
Involved Version

Copyright © Huawei
CSC3300 V100R010C10SPC200
Solution
This issue has been resolved in CSC3300 V100R010C10SPH208.
After the V100R010C10SPH208 patch is installed, an SCU module will determine whether an
association among tracing handles already exists. If the association already exists, the SCU
module does not associate tracing handles.
3.12 Call Forwarding Fails If the Precondition Function Is

Enabled
Involved NE: MGCF (MSOFTX3000)
Defect Details
Symptom The call initiated by CS subscriber 72 to VoLTE subscriber 13 through the

MGCF is forwarded to VoLTE subscriber 14 because VoLTE subscriber 13
does not answer the call. After receiving a 181 message for precondition
negotiation, the MGCF returns a 200 message but does not send an
UPDATE message to complete precondition negotiation. As a result, the
call is released due to timeout.

Copyright © Huawei
Trouble N/A
Ticket
Number
Root Cause Serving as the MGCF, the MSOFTX3000 cannot send an UPDATE
message carrying the precondition information after receiving an
UPDATE message in which the precondition information contains the
conf line.
 The MSOFTX3000 serves as the MGCF.
 The precondition function is enabled on the SIP trunk groups between
the MGCF and the CSCF.
 The call initiated by CS subscriber A to VoLTE subscriber B is
forwarded to VoLTE subscriber C because VoLTE subscriber B does
not answer the call. Then subscriber C sends a 183 message carrying
Require: Precondition to request precondition negotiation. Then the
ATS as MMTel exchanges UPDATE messages with the MGCF to
update the precondition information.
of
Occurrence

Copyright © Huawei
Involved Version
Solution
This issue has been resolved in MSOFTX3000 V200R010C20SPH101.
After you install the patch, perform the following operations:
Bit 15 of P1536 (X*** **** **** ****) determines whether the MSOFTX3000 can send the following
messages to the next hop when receiving an UPDATE message in which the precondition information
contains the conf line:
 200 (to UPDATE) message not containing the conf line.
 UPDATE message containing the precondition information.
= 0: The MSOFTX3000 can send the preceding messages.
= 1: The MSOFTX3000 cannot send the preceding messages.
Default value: 1
Application scenario: When the next hop triggers the CFNRy flow by sending an UPDATE message
containing the conf line to the MSOFTX3000, the MSOFTX3000 must respond with another UPDATE
message to continue the call. To enable the MSOFTX3000 to send another UPDATE message, set bit 15
to 0.
Impact on the system: None
Related software parameter: Bit 3 of P1536
Note: The MSOFTX3000 can send another UPDATE message to the next hop only when bit 3 of P1536
is set to 0.

Bit 3 of P1536 (**** **** **** X***) determines whether the MSOFTX3000 can send an UPDATE
message to the next hop during a SIP call if the received 18X message contains a conf line in
precondition and precondition on the MSC server meets the conf line requirements.
= 0: The MSOFTX3000 can send an UPDATE message.
= 1: The MSOFTX3000 cannot send an UPDATE message.
Default value: 1
Application scenario: If the next hop continues a call only after receiving an UPDATE message from the
MSOFTX3000, set bit 3 to 0.
Impact on the system: None
Related software parameter: Bit 15 of P1536
3.13 Extra-long CDRs Are Generated by the ATS9900


Copyright © Huawei
Defect Details
Symptom The billing center detects extra-long CDRs generated by the ATS9900
when it sorts CDRs.
Trouble N/A
Ticket
Number
Root Cause Through CDR analysis, it is found that seconds in an intermediate CDR
and a start CDR are the same but the millisecond in the intermediate CDR
is less than the millisecond in the start CDR. In a word, the time recorded
in the intermediate CDR is earlier than the time recorded in the start CDR.
When the CCF combines CDRs, it detects that the subtraction between the
time in two CDRs is a negative integer. As a result, an overturn occurs and
an extra-long CDR is generated.
The Service-Delivery-Start-Time-Stamp and
serviceDeliveryStartTimeStampFraction AVPs in CDRs are set by the
ATS9900 and included in an ACR message sent to the CCF. As P1413 is
set to 0 by default, the ATS9900 separately obtains values for the two
AVPs. Therefore, time difference may exist.
If P1413 is set to 1, the ATS9900 sets the Service-Delivery-Start-Time-
Stamp and serviceDeliveryStartTimeStampFraction AVPs to the same
value. In this case, time difference can be prevented.
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
After the V100R006C10SPH210 patch is installed, the ATS9900 will set the Service-
Delivery-Start-Time-Stamp and serviceDeliveryStartTimeStampFraction AVPs on the basis of
the same seconds and milliseconds. After patch installation, the function is not controlled by
P1413.
3.14 SBC Returns an Error Because the Calling Party

Hangs Up After an eSRVCC Handover Occurs But Before
the Called Party Answers the Call
Involved NE: SE2900

Copyright © Huawei

Defect Details
Symptom An eSRVCC handover occurs on the call in the alerting state. The calling
party hangs up after the successful handover, and the called party keeps the
alerting state until the call is released due to timeout.
Trouble N/A
Ticket
Number
Root Cause After an eSRVCC handover is complete, if the calling party hangs up
before the called party answers the call, a CANCEL message is sent to the
SBC. After the SBC receives the CANCEL message for the handed over
call, it fails to distribute the message and returns a 481 message. As a
result, the CANCEL flow is abnormal.
 The VoLTE networking is deployed.
 The calling party sends a CANCEL message immediately after sending
an INVITE message for eSRVCC handover.
of
Occurrence
Involved Versions
All SE2600 versions
SE2900 V300R001C10 and TR5 and GA versions of SE2900 V300R001C20 used at VoLTE
commercial sites or trial commercial sites
Solution
This issue has been resolved in SE2900 V300R001C20SPH102.
To solve the issue in the SE2900 V300R001C10 or V300R001C20, upgrade the SE2900 to
V300R001C20 and then install the V300R001C20SPH102 patch.
To solve the issue in SE2900 V300R001C20SPC100, install the V300R001C20SPH102
patch.
3.15 VoLTE Call Fallback Occurs Due to USSDs Delivered

by the CN Side
Involved NE: N/A
Defect Details
Symptom Issue 1: When a VoLTE subscriber initiates a call to a CS subscriber who

Copyright © Huawei
has enabled the mobile phone contact, the VoLTE subscriber is fallen back
to a 2G network.
Issue 2: After a call of a PPS subscriber is complete, the PPS subscriber
receives a USSD notification about tariff. As the USSD fallback solution
is used on the live network, the caller fallback is triggered each time a call
is complete. In the multi-line call scenario, the call will fail. For example,
if the calling party in a conference call is a PPS subscriber, the calling
party will receive a tariff notification when any one called party leaves the
conference. As a result, fallback occurs and the conference ends.
Trouble N/A
Ticket
Number
Root Cause As defined by the 3GPP protocol, the CN side cannot deliver USSDs
through an IP network but can deliver USSDs only through a 2G or 3G
network. Therefore, during a VoLTE call, the CN side falls back the call to
a 2G or 3G network and then delivers USSDs.
Condition These issues occur when the CN side sends USSDs during a VoLTE call.
of
Occurrence
Involved Version
N/A
Solution
It is found that the issue is caused by USSDs delivered from the subscriber who has enabled
the mobile phone contact. The marketing department needs to promote the customer to
migrate subscribers who have enabled the mobile phone contact to the call signature platform.
Huawei IN devices used at Kuwait VIVA allow tariff notifications to be delivered by short
messages. Frontline engineers already promote the customer to allow the USSD center to send
tariff notifications by short messages.
3.16 3G SRVCC Handover Fails in the Separate

Deployment Scenario
Defect Details
Symptom The SRVCC IWF and target MSC server are separately deployed. After
the target MSC server sends a relocation-request message to the RNC, the
RNC returns a failure. As a result, a 3G SRVCC handover fails. The IWF
and target MSC server are Huawei devices, the devices at the 3G radio

Copyright © Huawei
side are NSN devices.

Trouble N/A
Ticket
Number
Root Cause The analysis result from NSN shows that the handover fails because the
relocation-request message does not carry UE History Information.
After comparing transparent-container in the srvcc-ps-to-cs-req message
with sourceRNC-to-targetRNC-transparent-container in the relocation-
request message, it is found that about a dozen of bytes is absent from the
relocation-request message. UE History Information should be contained
in these absent bytes.
Bit 0 of P730 determines whether UE History Information can be
transparently transmitted. This function is added in V200R10C20.
It is found that this function has been enabled both on the IWF and the
target MSC server. The IWF can transparently transmit UE History
Information through MAP-Prepare-handover-req to the target MSC server.
However, the version of the target MSC server is V200R009C02, which
cannot transparently transmit UE History Information to the RNC.
Condition This issue occurs when the SRVCC IWF and target MSC server are
separately deployed and the target MSC server is earlier than
V200R10C20.
of
Occurrence
Involved Version
Solution
To solve this issue in MSOFTX3000 V200R10C20, set bit 0 of P730 to 0, enabling the MSC
server to transparently transmit eSRVCC handover information elements.
P730 - RANAP Part2 Software Parameter 31

Copyright © Huawei
To solve this issue in MSOFTX3000 V200R009C02, a patch needs to be developed.

Separate deployment is used at subsequent commercial sites, and most target MSC
servers are of earlier versions and a large number of CPCI devices are deployed.
Therefore, the V200R009C02 and V100R009C02 patches have been developed based on
the function determined by bit 0 of P730 to prevent 3G commercial use risks.
3.17 Internal Tracing Logs About Subscriber Message

Tracing Cannot Be Displayed
Defect Details
Symptom Both internal message tracing and message tracing logs are selected when
a subscriber message tracing task is created on the ATS. However, only
few logs can be viewed, which does not facilitate problem location.
Trouble N/A
Ticket
Number
Root Cause To prevent CPU overload on the VCU module due to subscriber message
tracing, P515 has been added to ATS9900 V100R006C20. This parameter
specifies the level of logs to be displayed in message tracing results. Its
default value is 4, indicating error level.
 Both internal message tracing and message tracing logs are selected
when a subscriber message tracing task is created on the ATS.

Copyright © Huawei
of
Occurrence
Involved Version
ATS9900 V100R006C10SPC200
Solution
During problem location, you can change the level of logs to be displayed from 4 (error level)
to 0 (debug level).
Note: This software parameter applies only during commissioning of the ATS (with VCU
deployed) or test at a delivered site. In principle, do not modify this software parameter
at a commercial site. If this software parameter must be modified on a commercial ATS
(with VCU deployed), modify the parameter under guidance of R&D engineers.

Copyright © Huawei

Information Sharing of Important VoLTE Issues (2016-11)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Information Sharing of Important VoLTE Issues (2016-11)

Uploaded by

Copyright:

Available Formats

Information Sharing of Important

VoLTE Issues (2016-11)

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential i

Issue 01 (2016-12-29) Huawei Proprietary and Confidential ii

Issue 01 (2016-12-29) Huawei Proprietary and Confidential iii

Issue 01 (2016-12-29) Huawei Proprietary and Confidential iv

Issue 01 (2016-12-29) Huawei Proprietary and Confidential v

Issue 01 (2016-12-29) Huawei Proprietary and Confidential vi

Issue 01 (2016-12-29) Huawei Proprietary and Confidential vii

2.14.26 Announcement Placed to a Call Waiting Subscriber Is Incorrect........................................................................295

Issue 01 (2016-12-29) Huawei Proprietary and Confidential viii

2.16.1 CFNR Service Fails...............................................................................................................................................338

Issue 01 (2016-12-29) Huawei Proprietary and Confidential ix

Issue 01 (2016-12-29) Huawei Proprietary and Confidential x

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 1

2.1 Fault Cases for November 2016

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 2

2.1 Fault Cases for November 2016

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 3

SE2900 V300R002C00 does not support the preceding software parameters.

2.1.2 Calls Fail Because the Registration Cache Function Is

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 4

2.1.3 Calling Party Cannot Hear the Called Party Due to

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 5

2.1.4 Customized Ring Back Tone Heard by the CS Subscriber Is

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 6

2.1.5 MME Disconnects Calls Because the eMSC Server Returns a

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 7

Summary and Reference

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 8

Summary and Reference

2.1.7 Two More TransCoders Are Required Due to Inconsistent

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 9

Summary and Reference

2.1.8 Session Timer Negotiation Fails in Non-stable State

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 10

Summary and Reference

2.2 Fault Cases for October 2016

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 11

The Call-ID in the INVITE message is

At 13:10:43, UE_B does not respond, and UE_A sends a CANCEL

At 13:11:23, UE_B does not receive an ACK message before the

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 12

Access network configuration queried by running LST SIPAN is as

When Timeout interval for initial requests is set to 0, the SBC

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 13

UE_B through the eNodeB.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 14

When setting this parameter, note the

2.2.2 Calls from VoLTE Subscribers to Local Fixed-Line

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 15

When a VoLTE subscriber, after being handed over to a 2G network, places

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 16

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 17

The ATS sends an INVITE message to the MCN service platform.

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 18

2.2.4 Conference Call Fails After Adding a Participant to the

At 14:59:59, UE_A sends a REFER message to remove UE_B from the

Issue 01 (2016-12-29) Huawei Proprietary and Confidential 19

2.2.5 Calls to VoLTE Subscribers Fail After They Are Handed