0% found this document useful (0 votes)

356 views307 pages

CSC3300 V100R009C01 Feature Description

Uploaded by

aranibarm

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

356 views307 pages

CSC3300 V100R009C01 Feature Description

Uploaded by

aranibarm

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 307

HUAWEI CSC3300 Call Session Controller

V100R009C01
Feature Description

Issue 01

Date 2012-08-24

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2012. 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 the 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: [email protected]

Huawei Proprietary and Confidential

Issue 01 (2012-08-24) i
Copyright © Huawei Technologies Co., Ltd.
HUAWEI CSC3300 Call Session Controller
Feature Description Contents

Contents

1 Basic Features ................................................................................................................................. 1

1.1 MI2S0CSCBS01 CSC3300 V100R009 Basic SW - per NE ............................................................................ 1
1.1.1 SWP-CSCF-BS-010100 Basic Protocols ................................................................................................ 1
1.1.2 SWP-CSCF-BS-010101 IPv4 ................................................................................................................. 2
1.1.3 SWP-CSCF-BS-010103 SIP over UDP .................................................................................................. 3
1.1.4 SWP-CSCF-BS-010104 Diameter over SCTP ....................................................................................... 3
1.1.5 SWP-CSCF-BS-010105 Diameter over TCP .......................................................................................... 4
1.1.6 SWP-CSCF-BS-010106 DNS/ENUM over TCP .................................................................................... 5
1.1.7 SWP-CSCF-BS-010107 DNS/ENUM over UDP ................................................................................... 6
1.1.8 SWP-CSCF-BS-010108 COPS over TCP............................................................................................... 7
1.1.9 SWP-CSCF-BS-010200 Operation and Maintenance Functions ............................................................ 8
1.1.10 SWP-CSCF-BS-010300 NE Redundancy ........................................................................................ 10
1.1.11 SWP-CSCF-BS-010400 Multiple Signaling Links .......................................................................... 11
1.1.12 SWP-CSCF-BS-010500 Link Layer OAM ...................................................................................... 13
1.1.13 SWP-CSCF-BS-010600 IP Address Conflict Detection .................................................................. 14
1.1.14 SWP-CSCF-BS-010700 Blacklist of Routing Failure ........................................................................ 15
1.1.15 SWP-CSCF-BS-010800 ARP Detection .......................................................................................... 17
1.1.16 SWP-CSCF-BS-010900 Flow Control............................................................................................. 18
1.1.17 SWP-CSCF-BS-011000 Hardware Fault Diagnosis ........................................................................ 25
1.1.18 SWP-CSCF-BS-011100 Offline Charging .......................................................................................... 28
1.1.19 SWP-CSCF-BS-011200 Addressing ................................................................................................... 30
1.1.20 SWP-CSCF-BS-011300 Session Timer .............................................................................................. 32
1.1.21 SWP-CSCF-BS-011400 Long Call Audit ........................................................................................... 41
1.1.22 SWP-CSCF-BS-011500 Seamless Upgrade..................................................................................... 42
1.1.23 SWP-CSCF-BS-011600 I-CSCF Redundancy Supported by the P-CSCF/S-CSCF ........................... 43
1.1.24 SWP-CSCF-BS-011700 DNS Buffer Supported by the P/I/S-CSCF .................................................. 47
1.1.25 SWP-CSCF-BS-011800 Enhanced Subscriber Tracing Function .................................................... 48
1.1.26 SWP-CSCF-BS-011900 PSI Feature .................................................................................................. 48
1.1.27 SWP-CSCF-BS-012100 Quick Re-Registration ................................................................................. 54
1.1.28 SWP-CSCF-BS-012200 Independent Charging Network Port ........................................................... 56
1.1.29 SWP-CSCF-BS-012300 Lawful Interception .................................................................................. 57
1.1.30 SWP-CSCF-BS-012400 MRFC-Supported Interfaces for Interworking with Multiple Devices ........ 60
1.2 MI2SCSCPSR01 CSC3300 V100R009 P-CSCF Subscriber Registered - per k subs ................................. 62

Issue 01 (2012-08-24) Huawei Proprietary and Confidential ii

1.2.1 SWP-CSCF-PSR-012300 Registration Supported by the P-CSCF ....................................................... 62

1.2.2 SWP-CSCF-PSR-012400 Registration Events Subscribed by the P-CSCF .......................................... 65
1.2.3 SWP-CSCF-PSR-012500 Roaming Supported by the P-CSCF ............................................................ 66
1.2.4 SWP-CSCF-PSR-012600 Distinguishing Subscriber Registration Features by userinfo on the P-CSCF
....................................................................................................................................................................... 68
1.3 MI2SCSCSSR01 CSC3300 V100R009 S-CSCF Subscriber Registration ..................................................... 69
1.3.1 SWP-CSCF-SSR-012700 Registration Supported by the S-CSCF ....................................................... 69
1.3.2 SWP-CSCF-SSR-012800 Registration Event Subscription Supported by the S-CSCF ....................... 74
1.3.3 SWP-CSCF-SSR-012900 HTTP Digest Authentication Supported by the S-CSCF ............................. 77
1.3.4 SWP-CSCF-SSR-013000 Roaming Supported by the S-CSCF ............................................................ 80
1.3.5 SWP-CSCF-SSR-013100 AS-Initiated Deregistration Supported by the S-CSCF ............................... 81
1.4 MI2SMRCIVR01 CSC3300 V100R009 MRFC-Supported Audio IVR Channels ........................................ 83
1.4.1 SWP-CSCF-MSR-013200 Audio IVR Operations ............................................................................... 83
1.4.2 SWP-CSCF-MSR-013201 RFC4240-Based Playing ............................................................................ 83
1.4.3 SWP-CSCF-MSR-013202 MSML-Based Playing ............................................................................... 88
1.4.4 SWP-CSCF-MSR-013203 RFC4240-Based IVR ................................................................................. 95
1.4.5 SWP-CSCF-MSR-013204 MSML-Based DTMF Collection ............................................................... 99
1.4.6 SWP-CSCF-MSR-013205 MSML-Based Recording ......................................................................... 106

2 Optional Features ...................................................................................................................... 113

2.1 MI2SPCSCSP00 P-CSCF Session Processing ............................................................................................. 114
2.1.1 SWP-CSCF-PSP-020100 P-CSCF Session Processing ...................................................................... 114
2.1.2 SWP-CSCF-PSP-020200 Early Session Supported by the P-CSCF ................................................... 117
2.1.3 SWP-CSCF-PSP-020300 Emergency Call Supported by the P-CSCF ............................................... 119
2.1.4 SWP-CSCF-PSP-020400 Protocol Interfaces Supported by the P-CSCF ........................................ 123
2.1.5 SWP-CSCF-PSP-020600 Gq Interface Between CSCF and PDF.................................................. 124
2.2 MI2SSBERSP00 S/B/E-CSCF Session Processing ..................................................................................... 126
2.2.1 SWP-CSCF-SSP-020700 Session Establishment Supported by the S-CSCF .................................. 126
2.2.2 SWP-CSCF-SSP-020800 Media Negotiation Supported by the S-CSCF ........................................ 129
2.2.3 SWP-CSCF-SSP-020900 Session Release Supported by the S-CSCF ............................................ 130
2.2.4 SWP-CSCF-SSP-021000 iFC-based Service Triggering .................................................................... 131
2.2.5 SWP-CSCF-SSP-021100 Different AS Modes Supported by the S-CSCF ......................................... 133
2.2.6 SWP-CSCF-SSP-021200 Number Analysis Supported by the S-CSCF .......................................... 134
2.2.7 SWP-CSCF-SSP-021300 Early Session Supported by the S-CSCF .............................................. 137
2.2.8 SWP-CSCF-SSP- 021400 Media Capabilities Check Supported by the S-CSCF .............................. 138
2.2.9 SWP-CSCF-SSP-021500 Interworking Supported by the S-CSCF /BGCF........................................ 139
2.2.10 SWP-CSCF-SSP-021600 Protocol Interfaces Supported by the S-CSCF ...................................... 141
2.2.11 SWP-CSCF-ESP-022200 Emergency Calls Supported by the E-CSCF ........................................... 143
2.3 MI2SICSCSP00 I-CSCF Session Processing ............................................................................................ 148
2.3.1 SWP-CSCF-ISP-021700 Registration Supported by the I-CSCF ....................................................... 148
2.3.2 SWP-CSCF-ISP-021800 Session Establishment Supported by the I-CSCF ....................................... 151
2.3.3 SWP-CSCF-ISP-021900 Number Analysis Supported by the I-CSCF ............................................ 152
2.3.4 SWP-CSCF-ISP-022000 Topology Hiding Supported by the I-CSCF ............................................... 156

Issue 01 (2012-08-24) Huawei Proprietary and Confidential iii

2.3.5 SWP-CSCF-ISP-022100 Transit Supported by the I-CSCF ............................................................... 166

2.4 MI2SIBCFSP00 IBCF Session Processing .................................................................................................. 173
2.4.1 SWP-CSCF-IBSP-022300 IBCF Session Processing ...................................................................... 173
2.4.2 SWP-CSCF-IBSP-022500 Routing Hiding Supported by the IBCF................................................... 176
2.4.3 SWP-CSCF-IBSP-022600 Transit Supported by the IBCF ................................................................ 178
2.4.4 SWP-CSCF-IBSP-022700 IBCF Trunk Management ........................................................................ 182
2.4.5 SWP-CSCF-IBSP-022701 Trunk-based Routing Supported by the IBCF .......................................... 184
2.4.6 SWP-CSCF-IBSP-022702 Trunk-based Number Conversion Supported by the IBCF ...................... 187
2.4.7 SWP-CSCF-IBSP-022703 Trunk Blocking Supported by the IBCF .................................................. 191
2.4.8 SWP-CSCF-IBSP-022704_PBX Trunk Access Supported by the IBCF ............................................ 193
2.4.9 SWP-CSCF-IBSP-022705_ENUM Query Supported by the IBCF .................................................... 203
2.5 MI7S00ACCC00 Audio Conference Channels Supported by the MRFC .................................................... 209
2.5.1 RFC4240-Based Conference ............................................................................................................... 209
2.6 MI7SSDVCCC00 Video Conference Channels Supported by the MRFC ................................................... 214
2.6.1 MSML-Based Conference .................................................................................................................. 214
2.7 MI7S00ATCC00 MRFC Audio transcoding Channels ................................................................................ 225
2.8 MI7SHDVCCC00 High Definition Video Conference Channels Supported by the MRFC ..................... 229
2.8.1 Cooperating with the MCU to Provide the HD Video Conference Function ...................................... 230
2.9 MI2S00TVCC00 Telepresence Conference Channels Supported by the MRFC ......................................... 235
2.9.1 Cooperating with the MCU to Provide the Telepresence Video Conference Function ....................... 235
2.10 MI2SSCSCMP00 CSC3300 P-CSCF Message Processing .................................................................... 236
2.11 MI2SPCSCMP00 CSC3300 S-CSCF Message Processing..................................................................... 236
2.12 MI2SPCSCPP00 CSC3300 P-CSCF Presence Processing...................................................................... 238
2.13 MI2SSCSCPP00 CSC3300 S-CSCF Presence Processing...................................................................... 239
2.14 MI2S0PCSRX00 Policy Control Support(Rx) .............................................................................. 241
2.15 MI2S0PCSGQ00 Policy Control Support(Gq') .......................................................................................... 243
2.16 MI2S0PCSMM00 Policy Control Support (Cable) ............................................................................ 246
2.17 MI2SMCH24800 Media Control(H.248) Supported by Boarder Gateway ................................................ 264
2.18 MI2S00PASA00 Enhanced Authentication ............................................................................................. 266
2.18.1 SWP-CSCF-AKAA-023200 IMS AKA Authentication................................................................. 266
2.18.2 SWP-CSCF-EISA-023300 Early IMS Authentication ................................................................... 268
2.18.3 SWP-CSCF-NASSA-023400 NASS-Bundled Authentication ...................................................... 269
2.18.4 SWP-CSCF-NASSA-023401 e2 Interface to the TISPAN NASS .................................................... 271
2.19 MI2S00CRHN00 Call Restriction to Hotline Numbers ............................................................................. 272
2.20 MI2SSIGFLT00 Filtering of SIP Signaling ................................................................................................ 275
2.21 MI2S00IDNS00 Intra-DNS server function ............................................................................................ 281
2.22 MI2S00ENUM00 Intra-Enum server function(S-CSCF) ........................................................................ 282
2.23 MI2S0CSCNP00 Number Portability(Number Portability) ....................................................................... 283
2.24 MI2S0CSCGR00 Geographical Redundancy ......................................................................................... 289
2.25 MI2SCSCFMT00 Media Transcoding Control .......................................................................................... 293
2.26 MI2SIBCFCR00 Trunk-based Call Restriction .......................................................................................... 298

Issue 01 (2012-08-24) Huawei Proprietary and Confidential iv

3 Acronyms and Abbreviations ................................................................................................. 301

Issue 01 (2012-08-24) Huawei Proprietary and Confidential v

1 Basic Features

About This Chapter

1.1 MI2S0CSCBS01 CSC3300 V100R009 Basic SW - per NE
1.2 MI2SCSCPSR01 CSC3300 V100R009 P-CSCF Subscriber Registered - per k subs
1.3 MI2SCSCSSR01 CSC3300 V100R009 S-CSCF Subscriber Registration
1.4 MI2SMRCIVR01 CSC3300 V100R009 MRFC-Supported Audio IVR Channels

1.1 MI2S0CSCBS01 CSC3300 V100R009 Basic SW - per NE

1.1.1 SWP-CSCF-BS-010100 Basic Protocols
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The CSC3300 is an IP-based device. It supports the IPv4 and IPv6 protocol stacks at the IP
layer, UDP, TCP, and SCTP at the transport layer, and SIP, Diameter, DNS, ENUM, H.246
and COPS at the application layer. The MRFC supports the standard protocols defined in
3GPP IMS, including SIP, Diameter, DNS, H.248, and HTTP.

Benefits
For subscribers
Subscribers can enjoy the IMS services over an IP network.
For carriers
The CSC3300 supports all the communication protocols defined by 3GPP for the CSCF.
Thus, it facilitates the CSC3300 to interwork with devices from other vendors.

Description
Basic protocols used on the interfaces of the CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 1

Enhancement
The basic protocols feature is provided from CSC3300 V100R002 onwards.

Dependency
None

1.1.2 SWP-CSCF-BS-010101 IPv4

Availability
This feature is introduced in CSC3300 V100R002.

Summary
The CSC3300 allows user equipment (UEs) to access the IMS network using IPv4 addresses
and communicates with other devices through IPv4.

Benefits
For subscribers
Subscribers can access the IMS network using IPv4 addresses.
For carriers
The CSC3300 supports all the communication protocols defined by 3GPP for the CSCF.
Thus, it facilitates the CSC3300 to interwork with devices from other vendors.

Description
The CSC3300 allows UEs to access the IMS network using IPv4 addresses.
The CSC3300 communicates with other devices through IPv4.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 2

Enhancement
The IPv4 feature is provided from CSC3300 V100R002 onwards.

Dependency
None

1.1.3 SWP-CSCF-BS-010103 SIP over UDP

Availability
This feature is introduced in CSC3300 V100R002.

Summary
The CSC3300 allows UEs to access the IMS network using SIP over UDP and communicates
with other devices through SIP over UDP.

Benefits
For subscribers
Subscribers can access the IMS network using SIP over UDP.
For carriers
The CSC3300 supports all the communication protocols defined by 3GPP for the CSCF.
Thus, it facilitates the CSC3300 to interwork with devices from other vendors.

Description
The CSC3300 supports the SIP protocol in compliance with 3GPP 24.229 and IETF RFC
3261.
The CSC3300 supports the following SIP methods: REGISTER, SUBSCRIBE, NOTIFY,
PUBLISH, MESSAGE, INVITE, ACK, PRACK, UPDATE, BYE, CANCEL, OPTIONS,
INFO, and REFER.
The CSC3300 can transmit SIP messages over UDP.

Enhancement
The SIP over UDP feature is provided from CSC3300 V100R002 onwards.

Dependency
None

1.1.4 SWP-CSCF-BS-010104 Diameter over SCTP

Availability
This feature is introduced in CSC3300 V100R002.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 3

Summary
The CSC3300 can communicate with other devices through Diameter over SCTP.

Benefits
For subscribers
The CSC3300 provides access authentication and charging for subscribers.
For carriers
The CSC3300 supports all the communication protocols defined by 3GPP for the CSCF.
Thus, it facilitates the CSC3300 to interwork with devices from other vendors.

Description
The CSC3300 supports the Diameter protocol in compliance with 3GPP TS 29.229, TS
29.329, TS 29.209, and IETF RFC 3588.
The S-CSCF and I-CSCF use Diameter to communicate with the home subscriber server
(HSS)/subscription locator function (SLF) through the Cx/Dx interface to obtain user
profiles.
The P-CSCF, I-CSCF, and S-CSCF use Diameter to communicate with the call control
function (CCF) through the Rf interface to implement the offline charging function.
The P-CSCF uses Diameter to communicate with the policy decision function (PDF)
through the Gq interface to implement the quality of service (QoS) function.
The P-CSCF uses Diameter to communicate with the service-based PDF (SPDF) through
the Gq interface to implement the QoS function.
The P-CSCF uses Diameter to communicate with the PCRF through the Rx interface to
implement the QoS function.
The P-CSCF uses Diameter to communicate with the connectivity session location and
repository function (CLF) through the e2 interface to implement the location function.
The online charging gateway (OCG) uses Diameter to communicate with the online
charging system (OCS) through the Ro interface to implement the online charging
function.
The CSC3300 can transmit Diameter messages over SCTP.
The CSC3300 can be configured to communicate with other devices through Diameter
over SCTP.

Enhancement
The CSC3300 V100R002 and later versions can communicate with other devices through
Diameter over SCTP.

Dependency
None

1.1.5 SWP-CSCF-BS-010105 Diameter over TCP

Availability
This feature is introduced in CSC3300 V100R002.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 4

Summary
The CSC3300 can communicate with other devices through Diameter over TCP.

Description
The CSC3300 supports the Diameter protocol in compliance with 3GPP TS 29.229, TS
29.329, TS 29.209, and IETF RFC 3588.
The S-CSCF and I-CSCF use Diameter to communicate with the HSS/SLF through the
Cx/Dx interface to obtain user profiles.
The P-CSCF, I-CSCF, and S-CSCF use Diameter to communicate with the CCF through
the Rf interface to implement the offline charging function.
The P-CSCF uses Diameter to communicate with the PDF through the Gq interface to
implement the QoS function.
The P-CSCF uses Diameter to communicate with the SPDF through the Gq interface to
implement the QoS function.
The P-CSCF uses Diameter to communicate with the PCRF through the Rx interface to
implement the QoS function.
The P-CSCF uses Diameter to communicate with the CLF through the e2 interface to
implement the location function.
The OCG uses Diameter to communicate with the OCS through the Ro interface to
implement the online charging function.
The CSC3300 can transmit Diameter messages over TCP.
The CSC3300 can be configured to communicate with other devices through Diameter
over TCP.

Enhancement
The CSC3300 V100R002 and later versions can communicate with other devices through
Diameter over TCP.

Dependency
None

1.1.6 SWP-CSCF-BS-010106 DNS/ENUM over TCP

Availability
This feature is introduced in CSC3300 V100R002.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 5

Summary
The CSC3300 can query the domain name system (DNS) to obtain the IP address of the
next-hop network entity (NE).
The CSC3300 can obtain the SIP URI or the NP data of the callee by querying the ENUM
table.

Benefits
For subscribers
As the DNS is adopted for unified IP addresses management, the impact of IP address
change on subscribers is lightened.
For carriers
The CSC3300 supports all the communication protocols defined by 3GPP for the CSCF.
Thus, it facilitates the CSC3300 to interwork with devices from other vendors.

Description
The CSC3300 supports the DNS protocol in compliance with IETF RFC 1034, RFC
1035, RFC 2782, RFC 2915, RFC 3263, and RFC 3596.
The CSC3300 supports the following DNS query types: NAPTR, SRV, A, and AAAA.
The CSC3300 can transmit DNS messages over TCP.
The CSC3300 can be configured to communicate with DNS devices through
DNS/ENUM/NP over TCP.

Enhancement
The CSC3300 V100R002 and later versions can communicate with DNS/ENUM/NP devices
through DNS over TCP.

Dependency
None

1.1.7 SWP-CSCF-BS-010107 DNS/ENUM over UDP

Availability
This feature is introduced CSC3300 V100R006.

Summary
The CSC3300 can query the DNS to obtain the IP address of the next-hop NE.
The CSC3300 can obtain the SIP URI or the NP data of the callee by querying the ENUM
table.

Benefits
For subscribers
As the DNS is adopted for unified IP addresses management, the impact of IP address
change on subscribers is lightened.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 6

For carriers
The CSC3300 supports all the communication protocols defined by 3GPP for the CSCF.
Thus, it facilitates the CSC3300 to interwork with devices from other vendors.

Enhancement
The CSC3300 V100R006 and later versions can communicate with DNS/ENUM/NP devices
through DNS over UDP.

Dependency
None

1.1.8 SWP-CSCF-BS-010108 COPS over TCP

Availability
This feature is introduced in CSC3300 V100R002.

Summary
The CSC3300 can communicate with the SBC through COPS to keep the NAT mappings that
are involved during subscriber access alive and control the media exchange during a session.

Benefits
For subscribers
Subscribers can access the IMS network through NAT devices.
For carriers
The CSC3300 supports all the communication protocols defined by 3GPP for the CSCF.
Thus, it facilitates the CSC3300 to interwork with devices from other vendors.

Description
The CSC3300 supports the COPS protocol in compliance with IETF RFC 2748 and RFC
3084.
The CSC3300 can transmit COPS messages over TCP.
The CSC3300 can be configured to communicate with SBC devices through COPS over
TCP.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 7

Enhancement
The CSC3300 V100R002 and later versions can communicate with COPS devices through
COPS over TCP.

Dependency
None

1.1.9 SWP-CSCF-BS-010200 Operation and Maintenance

Functions
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The CSC3300 supports the following operation and maintenance (O&M) functions:
Security management
− User management, operation logs, secure connection, and authority and domain based
management.
− Operating system (OS) security of the host.
− Anti-attack mechanism.
Performance management
Traffic statistics of an NE.
Fault management
Troubleshooting and maintenance manuals.
Configuration management
Device data configuration.
Device management
− Device panel.
− Real-time display of the CPU usage.
− Real-time display of the memory usage.
Trace management
The system supports interface-based message tracing and subscriber-based message
tracing.
Log management
− Running logs.
− Call logs.
Alarm management
− Link fault alarms.
− Network interface fault alarms.
− Board component fault alarms.
− Service resource alarm.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 8

Benefits
For subscribers
This feature helps to identify faults efficiently.
For carriers
Carriers are the main beneficiaries of the O&M functions.
These O&M functions help the carriers optimally manage their equipment and networks.

Description
Security management
− User management, operation logs, secure connections, and authority and domain
based management
User management: User management involves account management and login
security.
Operation logs: All the operations performed on the device are recorded in logs.
Secure connections: The OMU provides several types of secure connections such as
SFTP, FTPS, and SSH connections.
Authority and domain based management: Users are classified into several groups for
management.
− OS security of the host
Compact Linux OS installation package, compact service package provided by the
Linux OS, compact and reinforced file system, secure login, password management,
and security audit.
− Anti-attack mechanism
The anti-attack mechanism is implemented at the IP layer and application layer.
Performance management
− Traffic statistics of an NE
Measurement of the traffic over a network interface, CPU usage of a board, memory
usage, traffic over a logical link, service provisioning, CPU usage of a process,
number of messages (SIP, Diameter, or DNS) over an interface, number of
subscribers, traffic of an NE, failure cause codes, and charging messages.
Fault management
− Troubleshooting and maintenance manuals
These manuals provide the methods for identifying faults during routine maintenance.
Configuration management
− Device data configuration
The device data and service data required for the operation of the system can be
configured.
Device management
− Device panel
The status of a board or a service process is displayed.
− Real-time display of the CPU usage
The CPU usage of each process in the system is displayed.
− Real-time display of the memory usage
The memory usage of the system is displayed.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 9

Trace management
− The system supports interface-based message tracing and subscriber-based message
tracing.
Interface-based tracing: The operator can trace the SIP messages, Diameter messages,
messages over the transport layer (TCP, UDP or SCTP), DNS/ENUM messages, and
COPS messages.
Subscriber-based tracing: The operator can trace the messages of a certain subscriber
during routine maintenance to learn how the services of the subscriber are processed
by the CSCF.
Log management
− Running logs
The running logs mainly record the system-level errors.
− Call logs
When a call fails, the system records the route information and key information
elements related to the call in the call logs.
Alarm management
− Link fault alarms
The links between the CSCF and the external devices are monitored. When a link is
faulty, the system alarms the operator. If all the links over a logical interface are
faulty, the system reports a communication interruption alarm to the operator.
− Network interface fault alarms
When a network interface is faulty, the system alarms the operator.
− Board component fault alarms
When a key component on a board such as the storage device is faulty, the system
alarms the operator of the faulty component.
− Service resource alarm
When a service resource is not available, the system alarms the operator that the
network entity is not able to provide a certain service.

Enhancement
The fault management, configuration management, device management, log management, and
alarm management are provided from CSC3300 V100R002 onwards.
The performance management and trace management are provided from CSC3300 V100R003
onwards.
The security management is provided from CSC3300 V100R005 onwards.

Dependency
None

1.1.10 SWP-CSCF-BS-010300 NE Redundancy

Availability
This feature is available in all versions of the CSC3300. The CSC3300 supports this feature
when serving as a P-CSCF, an I-CSCF, an S-CSCF, a BGCF, or an OCG.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 10

Summary
All the power boards, switch boards, subrack management boards, and service processing
boards support 1+1 redundancy. The fan modules support N+1 redundancy. The physical
connections between the service processing boards support 1+1 redundancy. The software
modules support 1+1 redundancy. Automatic or manual switchovers can be performed
between the active and standby processes.

Benefits
For subscribers
Subscribers can gain higher availability.
For carriers
This feature helps to improve the system reliability, reduce the losses, and improve the
brand name of the carriers.

Description
All the power boards, switch boards, subrack management boards, and service processing
boards support 1+1 redundancy. The fan modules support N+1 redundancy. The physical
connections between the service processing boards support 1+1 redundancy. The software
modules support 1+1 redundancy. Automatic or manual switchovers can be performed
between the active and standby processes.

Enhancement
None

Dependency
None

1.1.11 SWP-CSCF-BS-010400 Multiple Signaling Links

Availability
This feature is introduced in CSC3300 V100R002.

Summary
The CSC3300 sets up signaling links with a peer NE for communication. Based on the
interface type, the CSC3300 can set up SIP over TCP/SCTP links, Diameter over TCP/SCTP
links, DNS over TCP links, and COPS over TCP links. To improve the reliability and support
high volume of messages between NEs, the CSC3300 can set up multiple signaling links with
the peer NE. The links are identified by quintuples and support the active/standby, load
sharing, and session ID based link selection modes.

Benefits
For subscribers
The communication reliability and capacity between NEs are improved, and thus the
serviceability of the network is improved.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 11

For carriers
Carriers are the main beneficiaries of the multiple signaling links feature.
When multiple signaling links are set up, the communication between NEs is more
reliable, and thus the QoS is improved; on the other hand, the transmission capacity of
the links is increased so that the NEs can communicate even when the traffic is heavy.

Description
Configuration of multiple signaling links:
A link is identified by the quintuple (source IP address, source port number, destination IP
address, destination port number, and protocol type). Therefore, the quintuple must be unique
for each link.
When multiple broadband signaling units (BSUs) are available for the CSCF, it is
recommended that you distribute the links evenly to the BSUs to enhance reliability. Figure
1-1 shows the configuration of multiple Diameter links between the I-CSCF and the HSS.

Figure 1-1 Multiple signaling links between the I-CSCF and the HSS

Selection of multiple signaling links:

Active/standby mode
When multiple links are available, the link with the smallest ID, for example, Link0,
takes precedence. If this link is faulty, the CSCF selects another link to send messages.
For Diameter links, if the active link is congested, the CSCF selects another link to send
messages. The Diameter, DNS, and COPS signaling links support the active/standby
mode. When configuring the peer device data, set Link selection mode to Active or
standby.
Load sharing mode
When multiple links are available to a certain peer NE, the CSCF selects the links in turn
to send messages to balance the load. The SIP, Diameter, DNS, and COPS signaling links
support the load sharing mode. When configuring the peer device data, set Link
selection mode to Polling.
Session ID based mode
When multiple links are available, the CSCF selects the same link to send the messages
with the same session ID. Only Diameter links support session ID based selection. When
configuring the peer device data, set Link selection mode to Session ID based.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 12

Table 1-1 Link selection modes

Active/Standby Load Sharing Session ID Based

SIP × √ ×
Diameter √ √ √
DNS √ √ ×
COPS √ √ ×

Enhancement
Multiple SIP over TCP/SCTP links are supported from CSC3300 V100R005 onwards.
CSC3300 V100R005 and later versions also support configurable CRC and ADLER
algorithms for Diameter over SCTP links.

Dependency
To enable this feature, the peer NE must support multiple signaling links.

1.1.12 SWP-CSCF-BS-010500 Link Layer OAM

Availability
This feature is introduced in CSC3300 V100R005.

Summary
The Operation, Administration, and Maintenance (OAM) sublayer is used to monitor the
communication status of the link layer.

Benefits
For subscribers
Subscribers can enjoy more stable and reliable services.
For carriers
If the link layer is blocked, the system can report the fault timely and provide details.
If a healthier DPU process is available, the system performs an active/standby
switchover of the DPU processes to improve the reliability.

Description
The OAM sublayer is used to monitor the communication status of the link layer. OAM is an
optional layer implemented in the data link layer between the MAC and LLC sublayers. It can
detect faults at the bottom layers of the Ethernet timely and efficiently. In addition, the layers
are independent of each other; the fault at one layer does not affect other layers. The OAM
implements the control and management of each layer through point-to-point interoperations.
The operation of OAM on an Ethernet interface does not adversely affect data traffic as OAM
is a slow protocol with very limited band potential, and it is not required for normal link

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 13

operation. This slow protocol can be implemented in hardware or software, ensuring media
independence.
Discovery is the first phase of the IEEE 802.3ah OAM protocol. It identifies the devices in the
network along with their OAM capabilities. Discovery relies on the information OAM
protocol data units (OAMPDUs). During discovery, the periodic information OAMPDUs are
adopted.
Link monitoring: The link monitoring tools are for detecting and indicating link faults under a
variety of circumstances. Link monitoring uses the Event Notification OAMPDU, and sends
events to the remote OAM entity when there are problems detected on the link. To ensure
normal operation of link monitoring, the discovery phase must be successful.
Remote loopback: In loopback mode, every frame received is transmitted back on that same
port except for OAMPDUs and pause frames. An OAM entity can put its remote entity into
loopback mode using a loopback control OAMPDU.
Remote failure indication: There are three types of fault, namely, link fault, dying gasp, and
critical event. If such a fault is detected at the local entity (A), the local entity modifies bits
0-2 in the Flag field in the OAMPDU and sends the OAMPDU to the peer entity (B). Based
on the Flag field in the OAMPDU, the peer entity determines the faulty status of the local
entity (A) and the type of the fault.

Enhancement
None

Dependency
None

1.1.13 SWP-CSCF-BS-010600 IP Address Conflict Detection

Availability
This feature is introduced in CSC3300 V100R005.

Summary
The CSC3300 supports IPv4 and IPv6 address conflict detection in active detection or
network sensing mode.

Benefits
For subscribers
Assume that another device on the network uses the IP address of the CSCF to interact
with the external system. This device will broadcast an ARP request to refresh the ARP
caches of all the devices on the network. Thus, the CSCF cannot use this IP address for
communication. In this case, the system will report an alarm pertaining to the IP address
conflict.
For carriers
This feature helps to ensure that the IP address of the CSCF does not conflict with that of
any existing device (another NE or a third-party device) on the network.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 14

Description
The IPv4 address conflict detection may be implemented in either of the following modes:
Active detection
The CSCF sends an ARP request with the source IP address set to 0 and destination IP
address set to the local IP address to check for IP address conflicts. If another device on
the network uses the local IP address, this device responds to the ARP request (according
to ARP defined in RFC 2131). The CSCF analyzes the response and determines whether
it is from a conflict source.
Network sensing
An external device initiates an ARP request. The CSCF checks the request: If the source
IP address of the request is an IP address managed by the CSCF, the CSCF determines an
IP address conflict and reports an alarm to the background. If the CSCF does not detect
the conflict of the same IP address in 30 seconds, the CSCF determines that the conflict
source disappears and reports a clear alarm.
The IPv6 address conflict detection may be implemented in either of the following modes:
Active detection
The CSCF sends an ICMPv6 packet with the source IP address set to 0 and destination IP
address set to the IP address to be checked. If another device on the network uses this IP
address, this device returns a response (according to the neighbor discovery protocol
defined in RFC 2461). The CSCF analyzes the response and determines whether it is
from a conflict source.
Network sensing
The CSCF receives an ICMPv6 packet from the neighbor node. It checks whether the
source IP address of the packet is the local IP address. If yes, the CSCF determines there
is an IP address conflict and reports an alarm.

Enhancement
None

Dependency
None

1.1.14 SWP-CSCF-BS-010700 Blacklist of Routing Failure

Availability
This feature is introduced in CSC3300 V100R005.

Summary
The IMS solution of Huawei supports the heuristic detection mechanism that is used to
automatically detect a peer NE. The mechanism applies to the UDP-based SIP interfaces. The
connection between IMS NEs through a UDP-based SIP interface is unreliable. When the peer
NE is faulty, its counterpart cannot detect the fault or generate an alarm. To solve this problem,
Huawei designs a UDP fault detection mechanism. If an NE sends an INVITE message and
does not receive a response within the specified period, the mechanism is enabled and Option
messages are sent within the preset period to detect the status of the peer entity. When the peer

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 15

entity is faulty, an alarm is generated in time without manual intervention. This mechanism
facilitates fault identification, improves the maintenance efficiency of the whole network, and
reduces the maintenance cost.
The IMS solution also supports to detect the status of peer entity by OPTION message
according to configuration.

Benefits
For subscribers
This feature decreases the call failures and call delay caused by the single-point failure
occurred on the network.
For carriers
Carriers can monitor the status of NEs on flat networks instead of configuring the peer
NE data on the local NE.

Description
What is the Option message?
The Option message is a message defined in RFC 261 to detect the capability of the peer
NE. In Huawei IMS solution, the Option message is used to detect the running status of
the peer NE.
The following is the application scenario of the UDP Option detection mechanism
supported by the CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 16

1. After obtaining the address of the next-hop I-CSCF by querying the DNS, the S-CSCF
sends an INVITE message to the I-CSCF. If the S-CSCF does not receive a response from the
I-CSCF within the specified period, the S-CSCF enables the Option detection mechanism. If
the S-CSCF determines that the peer entity is faulty, the S-CSCF generates an alarm and does
not send requests to the faulty I-CSCF.
2. The S-CSCF repeatedly sends Option messages to the peer I-CSCF within the preset period
to detect the status of the I-CSCF. When the peer I-CSCF is recovered, the I-CSCF sends an
Option 200 message to the S-CSCF. The S-CSCF deletes the IP address of the I-CSCF from
the blacklist, stops sending Option messages to the I-CSCF, and generates a clear alarm. After
that, subsequent requests are routed to the recovered I-CSCF.

Enhancement
The usage and content of the blacklist can be viewed by running commands.
The blacklist can be deleted manually.
The duration of the TimerB and TimerF timers can be changed to adapt to different
networks.
Support detect peer according to configuration since IMS8.1.

Dependency
The peer NE must support the Option detection mechanism.

1.1.15 SWP-CSCF-BS-010800 ARP Detection

Availability
This feature is introduced in CSC3300 V100R005.

Summary
This feature is used to detect the status of the network layer between a board and a LAN
Switch.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 17

Benefits
For subscribers
Subscribers can enjoy more stable and reliable services.
For carriers
Carriers are the main beneficiaries of the ARP detection feature.
If the ARP detection fails, the system informs the operator of the failure causes. The ARP
detection failure indicates that a large number of packets are lost. Based on the alarm
information, the operator can adjust the system and recover the network.

Description
The ARP layer of the CSCF sends a data frame, which is named ARP request, to each host on
the Ethernet. The ARP request data frame carries the IP address of the destination host,
indicating "if you are the owner of this IP address, please reply with your MAC address."
When the ARP layer of the destination host receives this broadcast message and detects that
the sender is querying its IP address, the destination host replies with an ARP response. This
ARP response carries the IP address and MAC address of the destination host.
This mechanism helps to detect the status of the network layer between a board and a LAN
Switch.

Enhancement
None

Dependency
None

1.1.16 SWP-CSCF-BS-010900 Flow Control

Summary
When a large number of calls make the CSC3300 overloaded, the CSC3300 may fail. Flow
control is an important method to ensure that the system and services run properly in the case
of system overload.
The system resources are consumed gradually. The flow control is enabled when the ratio of
available system resources is lower than the alerting level. The number of rejected requests
increases when the available resources decrease.
The system enables the flow control based on the CPU usage, network interface traffic, and
service requests. When the system is busy, the proper rejection policy is required to prevent
interruption of ongoing sessions and release failures. Therefore, the system rejects only initial
requests. It does not reject deregistration requests or in-session requests initiated by the
network. In addition, the system informs the subscribers about request rejection through
failure responses. For transport-layer flow control, the system does not send a failure response
but directly rejects requests. The flow control policy varies according to services.

Benefits
Table 1-2 describes the benefits of the Flow Control feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 18

Table 1-2 Benefits of the Flow Control feature

Beneficiary Description
Carriers The Flow Control feature provides benefits mainly
to carriers. In the case of traffic overload, services
are available for certain subscribers and the system
does not break down.
Subscribers The subscribers that have set up call connections are
not affected by traffic overload. In the case of traffic
overload, subscribers with higher priorities can
continue to use the services.

Availability
Table 1-3 describes the requirements for implementing the Flow Control feature.

Table 1-3 Requirements for implementing the Flow Control feature

Required NEs Required Version License Support

P-CSCF V100R003C01 or later A license is not required for this feature.
I-CSCF
S-CSCF
IBCF V100R008C02 or later

Dependency
The CSC3300 rejects only initial session requests. It does not reject deregistration
requests initiated by the network or in-session requests.
The CSC3300 restricts emergency calls when the number of emergency calls exceeds
two times the system threshold.
The DoS attack defense and DDoS attack defense of the CSC3300 depend on the Flow
Control features to implement message suppression.
The CSC3300 restricts the Hotline Numbers requests. For the feature description of the
Call Restriction to Hotline Numbers, see 2.20 SWP-CSCF-HLR-023700 Call Restriction
to Hotline Numbers.

Description
Flow Control Range
The CSC3300 implements the flow control mainly for SIP messages and Diameter messages
when the traffic between interfaces is overloaded. The flow control focuses on the service
input points and the output points for key NEs. The flow control range of the CSC3300 is as
follows:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 19

SIP interfaces: The CSC3300 implements the flow control for all the external SIP
interfaces, for example, the Gm, Mm, Mg, ISC, Mr, Mj, and Mw interfaces.
Diameter interfaces: The CSC3300 implements the output flow control, namely the Hard
To Reach (HTR) flow control, for the Cx, Dx, and Rf interfaces to protect the HSS and
CCF.
Overload Judgment and Processing
The system adjusts the call restriction level based on the CPU usage at the startup. When the
system is running properly, calls are not restricted.
The system restricts only the following messages:
Initial REGISTER requests
Initial INVITE requests
INFO messages
OPTIONS messages
SUBSCRIBE messages
NOTIFY messages
MESSAGE messages
The system does not restrict the following messages:
Challenge registration requests (REGISTER after 401 authentication response)
Requests during a session
Subscription requests
All the responses
The system state is divided into three levels: ordinary overload, severe overload and no
overload. The handling procedures for the three states are as follows:
Ordinary overload control:
− When an NE is overloaded, the system rejects the current registration or session
request and responds with a 480 message. The 480 message contains "Reason-Phrase
= OverLoad", "Reason-Phrase = Flow Control", or "Reason-Phrase = Too many
requests" indicating that the NE is overloaded; the message also carries the
Retry-After header field which includes a time value.

If a 480 message contains "Reason-Phrase = Lack Of Resource, ResID is xxx", the system resources are
insufficient. In this case, whitelist subscribers are also rejected.
− The previous hop receives the 480 response and tries to send the rejected request
(initial registration or session request) to other servers.
− If all the other servers cannot process the request, this hop responds to the previous
hop with a 480 message. For details, see 3GPP TS24.229.
Severe overload control:
− When an NE is overloaded, the system rejects the current registration or session
request and responds with a 503 message. The message carries the Retry-After header
field that contains a time value.
− The previous hop receives the 503 response and tries to send the rejected request
(initial registration or session request) to other servers.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 20

− Within the time specified in the Retry-After header field, the previous hop cannot
send any requests to the overloaded NE. For details on the 503 message, see RFC
3261.
No overload:
The system accepts all the requests.
Basic Flow
The following describes the flow of ordinary overload control implemented by the CSC3300.
The flow of severe overload control is similar to the flow of ordinary overload control.
However, in the flow of severe overload control, the overloaded NE responds with a 503
message which carries the Retry-After header field containing a time value. The 503 message
indicates that the previous hop cannot send any request to the overloaded NE within the time
specified by the time value.
Figure 1-2 shows the flow of flow control of registration requests.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 21

Figure 1-2 Flow of flow control of initial registration requests

The flow of flow control of registration requests is as follows:

1. The UE sends the REGISTER request.
2. The P-CSCF receives the REGISTER request.
− If the P-CSCF is overloaded, the P-CSCF responds to the UE with the 480 message.
− If the P-CSCF is not overloaded, the P-CSCF obtains the I-CSCF address from the
DNS based on the home domain name contained in the REGISTER request, and
forwards the REGISTER request to the I-CSCF.
3. The I-CSCF receives the REGISTER request.
− If the I-CSCF is overloaded, the I-CSCF responds to the P-CSCF with the 480
message to instruct the P-CSCF to forward the REGISTER request to another
I-CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 22

− If the I-CSCF is not overloaded, the I-CSCF queries the HSS for the subscriber
registration status (the HTR flow control is implemented).
4. Based on the UAA message from the HSS, the I-CSCF obtains the S-CSCF address
allocated to the subscriber.
5. The I-CSCF sends the REGISTER request to the S-CSCF.
6. The S-CSCF receives the REGISTER request.
− If the S-CSCF is overloaded, the S-CSCF determines the REGISTER request is an
initial registration message, and responds to the I-CSCF with the 480 message to
instruct the I-CSCF to forward the REGISTER request to another S-CSCF.
− If the S-CSCF is not overloaded, the S-CSCF queries the HSS for the authentication
set of the subscriber (the HTR flow control is implemented) and authenticates the
subscriber based on the obtained authentication information.
Figure 1-3 shows the flow of flow control of session requests.

Figure 1-3 Flow of flow control of session requests

The flow of flow control of session requests is as follows:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 23

1. The UE sends the INVITE request.

2. The P-CSCF receives the INVITE request.
− If the P-CSCF is overloaded, the P-CSCF responds to the UE with the 480 message
to reject the INVITE request.
− If the P-CSCF is not overloaded, the P-CSCF forwards the INVITE request to the
S-CSCF.
3. The S-CSCF receives the INVITE request.
− If the S-CSCF is overloaded, the S-CSCF responds to the P-CSCF with the 480
message to reject the INVITE request.
− If the S-CSCF is not overloaded, the S-CSCF forwards the INVITE request to the
terminating I-CSCF.
4. The I-CSCF receives the INVITE request (the HTR flow control is implemented).
− If the I-CSCF is overloaded, the I-CSCF responds to the S-CSCF with the 480
message to instruct the S-CSCF to forward the INVITE request to another I-CSCF.
− If the I-CSCF is not overloaded, the I-CSCF queries the HSS for the subscriber
location information.
Flow Control of Session Requests from Subscribers with Higher Priorities
Assume that subscribers are registered with higher priorities. Figure 1-4 shows the flow of
flow control of session requests from subscribers with higher priorities.

Figure 1-4 Flow of flow control of session requests from subscribers with higher priorities

The flow of flow control of session requests from subscribers with higher priorities is as
follows:
1. The P-CSCF processes the INVITE request from the core network side as follows:
− The P-CSCF determines whether the INVITE request is sent from the subscriber in
the white list based on the IP address and port number contained in the INVITE
request. If yes, the P-CSCF accepts the INVITE request (the whitelist subscribers are
restricted when the system resources are insufficient).
− The P-CSCF adds the Resource-Priority header field to the INVITE request based on
the service level in the subscriber data.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 24

− The P-CSCF routes the INVITE request to the S-CSCF.

2. The S-CSCF receives the INVITE request.
− The S-CSCF finds that the INVITE request contains the Resource-Priority header
field and accepts the INVITE request.
− The S-CSCF adds the Resource-Priority header field to the request destined for an
AS.
− The S-CSCF routes the INVITE request to the I-CSCF.
3. The I-CSCF receives the INVITE request.
− The I-CSCF finds that the INVITE request contains the Resource-Priority header
field and accepts the INVITE request.
− The I-CSCF routes the INVITE request to the S-CSCF.
4. The S-CSCF receives the INVITE request.
− The S-CSCF finds that the INVITE request contains the Resource-Priority header
field and accepts the INVITE request.
− The S-CSCF adds the Resource-Priority header field to the request destined for the
AS.
− The S-CSCF routes the INVITE request to the P-CSCF.
5. After the INVITE request is routed to the P-CSCF, the P-CSCF finds that the INVITE
request contains the Resource-Priority header field and accepts the INVITE request. The
P-CSCF deletes the Resource-Priority header field from the message destined for the
access side.

Enhancement
Table 1-4 lists the release history of the Flow Control feature.

Table 1-4 Release history of the Flow Control feature

History Version Details Release Plan

Third release V100R008C02 The flow control is -
enhanced.
Second release V100R006C01 The flow control is -
not implemented for
the subscribers with
higher priorities.
Initial release V100R003C01 Service-layer flow -
control is
implemented.

1.1.17 SWP-CSCF-BS-011000 Hardware Fault Diagnosis

Availability
This feature is introduced in CSC3300 V100R002.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 25

Summary
The CSC3300 can detect hardware faults using the sensors on the ATCA board. There are two
types of hardware fault: outband faults and inband faults. The outband faults are reported
through the Intelligent Platform Management Bus (IPMB) to the SMM board and are
determined by the baseboard management controller (BMC) on the board. The inband faults
do not depend on the BMC on the board and are detected only when the OS on the board is
started.

Benefits
For subscribers
Subscribers can gain higher availability.
For carriers
Hardware faults can be detected and rectified timely to minimize the losses and improve
the brand name of the carriers.

Description
The CSC3300 can detect hardware faults using the sensors on the ATCA board. There are two
types of hardware fault: outband faults and inband faults. The outband faults are reported to
the SMM board through the IPMB and are determined by the BMC on the board. The inband
faults do not depend on the BMC on the board and are detected only when the OS on the
board is started.

Enhancement
None

Dependency
None

SWP-CSCF-BS-011001 Inband Fault Diagnosis

Availability
This feature is introduced in CSC3300 V100R002.

Summary
The inband faults do not depend on the BMC on the board and are detected only when the OS
on the board is started. All the components on a board can be detected, including the hard
disks, RAID controller, memory, and network interfaces. When a fault is detected, the system
reports an alarm to the OMU. For the faults on the network interfaces to external networks,
the system attempts to rectify the faults by switching to other DPU processes.

Benefits
For subscribers
Subscribers can gain higher availability.
For carriers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 26

Hardware faults can be detected and rectified timely to minimize the losses and improve
the brand name of the carriers.

Description
The inband faults do not depend on the BMC on the board and are detected only when the OS
on the board is started. All the components on a board can be detected, including the hard
disks, RAID controller, memory, and network interfaces. When a fault is detected, the system
reports an alarm to the OMU. For the faults on the network interfaces to external networks,
the system attempts to rectify the faults by switching to other DPU processes.

Enhancement
None

Dependency
None

SWP-CSCF-BS-011002 Outband Fault Diagnosis

Availability
This feature is introduced in CSC3300 V100R002.

Summary
The outband faults are reported to the SMM board through the IPMB and are determined by
the BMC on the board. Outband faults are mainly pertaining to the board/CPU temperature
and fan speed.

Benefits
For subscribers
Subscribers can gain higher availability.
For carriers
Hardware faults can be detected and rectified timely to minimize the losses and improve
the brand name of the carriers.

Description
The outband faults are reported to the SMM board through the IPMB and are determined by
the BMC on the board. Outband faults are mainly pertaining to the board/CPU temperature
and fan speed.

Enhancement
None

Dependency
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 27

1.1.18 SWP-CSCF-BS-011100 Offline Charging

Availability
This feature is introduced in CSC3300 V100R002.

Summary
The CSC3300 supports the offline charging scenario in compliance with 3GPP TS 32.260 and
TS 32.299. The CSC3300 can charge each successful session, failed session, successful
transaction request, and failed transaction request, and transmit the charging information
through Diameter. This facilitates carriers to charge subscribers for using the resources of the
IMS network and troubleshoot service failures.
The CSC3300 supports the three-level buffer technology. When all the interworking charging
devices are faulty, the CSC3300 saves the charging information in the local buffer. This
prevents the charging bill loss. When the charging devices are recovered, the CSC3300 reads
the charging bills from the buffer and sends them to the charging devices.

Benefits
For subscribers
Based on the charging bills, subscribers can calculate the fees for using the IMS network
resources.
For carriers
Based on the charging bills, carriers can conduct service charging and troubleshoot
service failures.
The three-level buffer technology ensures the secure storage of charging information.

Description
The following figure shows the IMS offline charging structure defined by 3GPP.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 28

The CSC3300 supports the interworking with multiple CCF devices. Based on the CCF
address contained in the user profile, the CSC3300 can select a CCF for storing the charging
information of a single subscriber. When the active CCF is faulty, the standby CCF takes over
all the services.
The following figure shows the storage of charging information. When the interworking CCF
is faulty, the charging information is saved to the shared memory. The data stored in the
shared memory on the standby board is synchronized with that on the active board. In case
that the active board fails, the data on the standby board can be used. The shared memory is
independent of service processes. Thus, the charging information is not lost when a process
failure occurs. When the usage of the shared memory reaches the threshold, the CSC3300
dumps the charging information from the shared memory to a permanent storage, such as the
hard disk on a board.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 29

Enhancement
The CSC3300 V100R002 and later versions support offline charging.
The shared memory technology introduced in the CSC3300 V100R005 and later versions
enhances the storage reliability of charging information.
The CSC3300 V100R006 and later versions use permanent storage to store charging
information, thus improving the storage capacity of the CSC3300.

Dependency
None

1.1.19 SWP-CSCF-BS-011200 Addressing

Availability
This feature is introduced in CSC3300 V100R002.

Summary
This feature is the addressing and routing mechanism for accessing services in the IP
multimedia (IM) core network (CN) subsystem. Addressing involves identification of
subscribers at the application layer and domain names or IP addresses at the signaling layer.
This feature applies to the P-CSCF, I-CSCF, S-CSCF, BGCF, and OCG.

Benefits
For subscribers
This feature is the routing basis for setting up calls on the IMS network.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 30

For carriers
This feature is the routing basis for setting up calls on the IMS network.

Description
The addressing on the IMS network involves the following features:
NAI
The network access identifier (NAI) is used to identify a subscriber in the specific
domain. The format of the NAI is similar to that of an Email address. It consists of two
parts: the user part and the realm part. The two parts are separated by the ampersat
symbol @, for example, [email protected].
At present, both ITU and 3GPP adopt the NAI format. For example, E.164 and
international mobile subscriber identity (IMSI) are in the NAI format.
On the IMS network, IP multimedia private identity (IMPI) also adopts the NAI format.
Each IMS subscriber can have one or more IMPIs. IMPIs are allocated by the home
network carrier and are used for registration, authorization, management, and charging.
SIP URI
SIP URI is defined in IETF RFC 3261 and RFC 2396.
SIP URI is the SIP addressing schema to call another subscriber through SIP. That is, a
SIP URI is the SIP telephone number of a subscriber. The format of the SIP URI is the
same as that of an Email address.
The format of the SIP URI is sip:x@y:Port.x is the subscriber name, and y is the domain
name or IP address of the host. The following are examples of SIP
URIs:sip:[email protected]:[email protected]:22444032@phonesy
stem.3cx.com
On the IMS network, IP multimedia public identity (IMPU) adopts the SIP URI format,
for example, sip:[email protected].
E.164/TEL URL
TEL URI is defined in IETF RFC 3261 and RFC2396.
On the IMS network, IMPU also adopts the E.164/TEL URL format, for example,
tel:+8675528712345.
The IMPU of the E.164 format cannot be routed within the IMS network and must be
converted to the SIP URI format. The ENUM server is used to convert the E.164 format
to the SIP URI format. The ENUM, a standard released by IETF, defines how to convert
telephone numbers of the E.164 format to the domain name format and store them on the
DNS server. Each ENUM record maps a group of uniform resource identifiers (URIs).
The S-CSCF can use the ENUM DNS translation mechanism to convert the address of
the E.164 format contained in Request-URI to the SIP URI that can be routed through
SIP.
One IMPI mapping multiple IMPUs
On the IMS network, each subscriber is allocated one IMPI or one or more IMPUs by
carriers. An intelligent card used within the GSM/UMTS network saves one IMPI and at
least one IMPU. The HSS is a database used to store all the subscriber-related data. The
IMPIs and IMPUs are stored in the HSS. Both the HSS and the S-CSCF associate the
IMPIs with the IMPUs. As stipulated in 3GPP R5, each IMS subscriber can have one
IMPI or multiple IMPUs, and can use one or more IMPUs to communicate with others.
For example, a subscriber can print his/her IMPU on the contact card.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 31

One IMPU mapping multiple IMPIs

In 3GPP R6, the relationship between the IMPI and the IMPU is expanded. One IMS
subscriber can have multiple IMPIs. On the UMTS network, only one IMPI is stored in
an intelligent card. A subscriber, however, can have multiple intelligent cards embedded
in different IMS terminals. In this way, some IMPUs are used with multiple IMPIs.
In a user profile, multiple IMPUs can be shared by multiple IMPIs. Therefore, multiple
UEs that use different IMPIs and different contact addresses can register one special
IMPU.

Enhancement
None

Dependency
None

1.1.20 SWP-CSCF-BS-011300 Session Timer

Availability
Table 1-5 describes the requirements for implementing the Session Timer feature.

Table 1-5 Requirements for implementing the Session Timer feature

Required NEs Required Version License Support

P-CSCF V100R003C02 or later This feature does not require
license support.
S-CSCF
MRFC V100R001 or later
UE None

Summary
The Session Timer feature is used after the establishment of a session. It enables a UE or
network entity to periodically originate REINVITE messages or UPDATE messages
(UPDATE messages by default) to ensure that the session is active. When neither the calling

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 32

party or the called party supports the session timer feature, the CSCF initiates UPDATE to
refresh sessions.
During a session setup, CSCF network entities add the negotiation of session update interval.
At the same time when the session is set up successfully, the negotiation of the session update
interval is complete, and the UE or network entity (refresher) that originates update request is
determined.
Then, the UE or network entity periodically originates the session update request according to
the determined interval (half the negotiated interval), thus ensuring that the session is active.
If the receiver and CSCF do not receive the session update request in the period defined by
the Session Timer, or the refresher does not receive the response to the session update request,
it indicates that the session is interrupted. In this case,
When the Session Timer times out, the refresher sends the BYE message to the peer end
to release related resources.
When the Session Timer times out, the medium node (such as the P-CSCF, S-CSCF or
MRFC) of the IMS system releases related resources.
This ensures that related resources are released in time. Thus, the release failure of network
resources caused by abnormalities do not occur.

Benefits
Table 1-6 describes the benefits of the Session Timer feature.

Table 1-6 Benefits of the Session Timer feature

Beneficiary Description

Carriers When the network is abnormal, the feature can

prevent loss to subscribers, thus improving
subscriber satisfaction. In addition, the resources can
be released in time to reduce resource waste.
Subscribers When the network is abnormal, the media stream
may be interrupted but the signaling may not be
interrupted without the Session Timer feature.
Therefore, the charging is not stopped. This may
cause extra-long-conversation-time bills. By means
of the Session Timer feature, the session can be
ended in time, thus preventing the loss to
subscribers.

Description

In terms of the implementation of the Session Timer feature, there are some differences between the
implementation principle of the MRFC and that of the P/S-CSCF. To focus on the feature description,
this section only specifies the implementation principle of the P/S-CSCF.

Description of Implementation Principle

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 33

When the UE supports the Session Timer, the Session Timer feature requires the coordination
of the CSCF and the UE. When the UE does not support the Session Timer, the CSC3300 can
implement the Session Timer feature independently.
The refresher periodically originates the session update request after the negotiation of
session update interval is successful.
The P-CSCF/S-CSCF performs update interval negotiation, activate the resource timer,
and release the related resource when the timer times out.
The following headers must be expanded in the SIP message to realize the feature:
In the SIP request:
− Session-Expires
− Supported:timer
− Min-SE
In the SIP response (422):
− Session Interval Too Small
− Min-SE
Implementation of the Session Timer feature
If the Support header in the request carries the timer parameter:
If the request does not contain the Session-Expires header, the P-CSCF/S-CSCF
processes the request as follows:
− If Reduce Session-Expires in request is N, the P-CSCF/S-CSCF uses the Session
Expires value locally configured to construct the Session-Expires header in the
request
− If Reduce Session-Expires in request is Y, the P-CSCF/S-CSCF uses the Min-SE
value locally configured to construct the Session-Expires header int he request.
If the value of the Session-Expires header in the request is smaller than the Min-SE value
locally configured, the P-CSCF/S-CSCF returns a 422 response to reject the request. The
Min-SE value carried by the 422 response is used to indicate the minimal duration of
refresher supported by the local end.
If the value of the Session-Expires header in the request is greater than the Min-SE value
locally configured, the P-CSCF/S-CSCF proceeds as follows based on the Reduce
Session-Expires in request parameter:
− IfReduce Session-Expires in request isY, that is, the P-CSCF/S-CSCF reduces the
Session-Expires value in the request, then the P-CSCF/S-CSCF uses the higher value
between the Min-SE value in the request and the Min-SE value locally configured to
modify the value of the Session-Expires header in the request.
− IfReduce Session-Expires in request isN, that is, the P-CSCF/S-CSCF has
configured with the value that cannot modify the Session-Expires value in the request,
then the P-CSCF/S-CSCF allows the users to communicate by using the
Session-Expires value in the request.
If the Support header in the request does not carry the timer parameter:
If the request does not contain the Session-Expires header, the P-CSCF/S-CSCF
processes the request as follows:
− If Reduce Session-Expires in request is N, the P-CSCF/S-CSCF uses the Session
Expires value locally configured to construct the Session-Expires header in the
request

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 34

− If Reduce Session-Expires in request is Y, the P-CSCF/S-CSCF uses the Min-SE

value locally configured to construct the Session-Expires header int he request.
When the request contains the Session-Expires header and the value of the header is
smaller than the Min-SE value configured on the CSCF, the P-CSCF/S-CSCF changes
the value of the header to the Min-SE value locally configured.
If the value of the Session-Expires header in the request is greater than the Min-SE value
configured on the P-CSCF/S-CSCF, the P-CSCF/S-CSCF proceeds as follows based on
the Reduce Session-Expires in request parameter:
− IfReduce Session-Expires in request isY, that is, the P-CSCF/S-CSCF reduces the
Session-Expires value in the request, the maximum value between the Min-SE value
in the request and the Min-SE value configured by the P-CSCF/S-CSCF is configured
on the P-CSCF/S-CSCF to modify the value of the Session-Expires header in the
request.
− If Reduce Session-Expires in request is N, that is, the P-CSCF/S-CSCF is unable to
lower the Session-Expires value, the P-CSCF/S-CSCF allows the users to
communicate by using the Session-Expires value.
Basic Flow
The negotiation of the Session Timer is performed at the initial stage of the session. After the
conversation starts, the refresher periodically originates the session update request.
Figure 1-5 lists the initial Session Timer negotiation flow.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 35

Figure 1-5 Message flow of initial Session Timer negotiation

The Session Timer negotiation flow is as follows:

1. By means of the Session Timer feature, the caller UE1 originates the session request
INVITE. The timer is filled in the Supported header of the message and the expected
session interval is filled in the Session-Expire header of the message, as mentioned
below:
INVITE sips:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com; branch=z9hG4bKnashds8
Supported: timer
Session-Expires: 500
Max-Forwards: 70
To: Bob <sips:[email protected]>

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 36

From: Alice <sips:[email protected]>;tag=1928301774

Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sips:[email protected]>
Content-Type: application/sdp
Content-Length: 142
2. After receiving the message, the P-CSCF checks it according to the local configuration
principle. If the value of the Session-Expires header is smaller than the value in the local
configuration of the P-CSCF, the P-CSCF returns a 422 response. The minimum value of
the Session Expires supported by the P-CSCF is filled in the Min-SE header in the
response, as mentioned below:
SIP/2.0 422 Session Interval Too Small
Via: SIP/2.0/UDP pc33.atlanta.example.com; branch=z9hG4bKnashds8;
received=192.0.2.1
Min-SE: 600
To: Bob <sips:[email protected]>;tag=9a8kz
From: Alice <sips:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
3. After receiving the 422 response, UE1 sends the request again using the Call-ID, From,
and To that are the same as those in the previous INVITE, refilled Session-Expires value,
and the Min-SE header, as mentioned below:
INVITE sips:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds9
Supported: timer
Session-Expires: 600
Min-SE: 600
Max-Forwards: 70
To: Bob <sips:[email protected]>
From: Alice <sips:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314160 INVITE
Contact: <sips:[email protected]>
Content-Type: application/sdp
Content-Length: 142
4. The P-CSCF checks the message again. After the check, the P-CSCF sends the message
to the S-CSCF.
5. After receiving the message, the S-CSCF checks it according to the local configuration
principle. If the value of Session Expires header is smaller than the value in the local
configuration of the S-CSCF, the S-CSCF returns a 422 response. The minimum value of
the Session Expires supported by the S-CSCF is filled in the Min-SE header in the
response, as mentioned below:
SIP/2.0 422 Session Interval Too Small
Via: SIP/2.0/UDP pc33.atlanta.example.com; branch=z9hG4bKnashds9;
received=192.0.2.1
Min-SE: 3600
To: Bob <sips:[email protected]>;tag=9a8kz
From: Alice <sips:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
6. The P-CSCF forwards the 422 response to UE1.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 37

7. After receiving the 422 response, UE1 sends the request again using the Call-ID, From,
and To that are the same with those in the previous INVITE, refilled Session-Expires
value, and the Min-SE header, as mentioned below:
INVITE sips:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bdegfdhs10
Supported: timer
Session-Expires: 3600
Min-SE: 3600
Max-Forwards: 70
To: Bob <sips:[email protected]>
From: Alice <sips:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
Contact: <sips:[email protected]>
Content-Type: application/sdp
Content-Length: 142
8. The P-CSCF checks the INVITE message again. When the message passes the check,
the P-CSCF sends the message to the next-hop S-CSCF.
9. The S-CSCF checks the INVITE message again. When the message passes the check,
the S-CSCF sends the message to the next-hop I-CSCF on the callee side.
10. The terminating I-CSCF forwards the INVITE message to the terminating S-CSCF.
11. The terminating S-CSCF checks the INVITE message again. When the message passes
the check, the terminating S-CSCF sends the message to the next-hop P-CSCF on the
callee side.
12. After the message is negotiated several times, it is sent to UE2. After receiving the
message, UE 2 checks it according to the local policy:
− If the value of Session Expires is too small, UE2 returns a 422 response. The Min-SE
header of the response carries the supported minimum value of Session-Expires.
After receiving the 422 response, UE1 sends a request that can pass the check by all
the network entities and UE2.
− If the value of Session-Expires is greater than that configured on the OMU client of
UE2, UE2 returns a 200 OK response.
13. UE2 fills the value of Session-Expires in the final response to the request, as mentioned
below:
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com;branch=z9hG4bKnashds11;
received=192.0.2.1
Require: timer
Supported: timer
Record-Route: sips:p1.atlanta.example.com;lr
Session-Expires: 3600;refresher=uac
To: Bob <sips:[email protected]>;tag=9as888nd
From: Alice <sips:[email protected]>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314161 INVITE
Contact: <sips:[email protected]>
Content-Type: application/sdp
Content-Length: 142
14. After receiving the 200 OK response, the P-CSCF is unable to modify the
Session-Expires value and it enables the Session Timer based on the value of
Session-Expires. If a session request is not received again before the timer times out, the
related resources are released.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 38

The negotiation comprises the negotiation of the Session-Expires value and the
negotiation of the refresher value in the Session Expires header.
Generally, if UE1 fills in the Refresher field in the Session Expires header when
originating the request, the P-CSCF, S-CSCF, I-CSCF, and UE2 are unable to modify the
value of this field. Table 1-7 lists the negotiation processing rules for the Refresher field.

Table 1-7 Negotiation rules for the Refresher field

Whether the UAC Refresher Value in the Refresher Value in the

Supports the Expansion Request Response
of Session Timer
N none uas
N uac NA
N uas NA
Y none uas or uac
Y uac uac
Y uas uas

− If the UAC (caller) does not support the expansion of Session Timer and the
expansion is expected by the UAS (callee), the UAS fills in the Session Expires field
in the 200 response and uas as the refresher value. This means that the UAS actively
originates the Session refresh operation.
− If the UAC (caller) does not support the expansion of Session Timer, regardless of
whether the Session Expires header in the request contains the Refresher field with
the value uac or uas, the UAS is not required to support the expansion.
− If the UAC (caller) supports the expansion of Session Timer and the Session Expires
header in the request does not contain the Refresher field, the UAS on the callee side
determines to set the refresher value in the final response to uac or uas according to
the local policy. This mode is recommended by the protocol, and it is also the most
commonly used mode.
− If the UAC (caller) supports the expansion of Session Timer and fills the Refresher
field in the Session Expires header of the request with uac, it indicates that the
Session refresh operation is originated by the UAC (caller) and the UAS is unable to
modify the value.
− If the UAC (caller) supports the expansion of Session Timer and fills the Refresher
field in the Session Expires header of the request with uas, it indicates that the
Session refresh operation is originated by the UAS (callee) and the UAS is unable to
modify the value.
15. After receiving the 200 OK response, the terminating S-CSCF is unable to modify the
Session-Expires value and it enables the Session Timer based on the value of
Session-Expires. The terminating S-CSCF then forwards the message to the terminating
I-CSCF.
16. After receiving the 200 response, the terminating I-CSCF is unable to modify the
Session-Expires value. The I-CSCF enables the timer based on the value of the
Session-Expires. The I-CSCF directly forwards the message to the originating S-CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 39

17. After receiving the 200 OK response, the originating S-CSCF is unable to modify the
Session-Expires value and it enables the Session Timer based on the value of
Session-Expires. The originating S-CSCF directly forwards the message to the
originating P-CSCF.
18. After receiving the 200 OK response, the originating P-CSCF is unable to modify the
Session-Expires value and it enables the Session Timer based on the value of
Session-Expires. The originating P-CSCF then forwards the message to UE1. UE1
originates the session update request based on the value uac of the refresher parameter.
After completing these steps, the whole Session Timer negotiation is complete. The P-CSCF
and S-CSCF obtain the session update interval, and enable related Session Timer according to
the negotiated interval.
Session Update Flow
The session update flow is almost the same as the session negotiation flow. The difference is
the time to enable the timer after processing the final response. In the session update flow, you
must stop the previous timer and enable the new timer based on the new negotiation result.
Session Abnormal Release Flow

Figure 1-6 Typical scenario of abnormal release scenario of the Session Timer feature

UE1(UAC) P-CSCF S-CSCF IBCF S-CSCF P-CSCF UE2(UA)

1.
REFRESH 2.
3.
Request REFRESH 4.
REFRESH 5.
Request REFRESH 6.
Request REFRESH
Request REFRESH
Request
Request
7. 500
8. 500
9.500
10. 500
11. 500
12. 500

13. BYE 14. BYE

15. BYE
16. BYE
17. BYE
18. BYE
19.200 (BYE)
20.200 (BYE)
21.200 (BYE)
22.200 (BYE)
23.200 (BYE)
24.200 (BYE)

As shown in the Figure 1-6, when abnormality occurs:

1. As a caller of the refresher, the UAC originates the session update request (Message 1 to
Message 6) at half of the value that the Session Timer times out.
2. The UE2 (UAS) is interrupted; therefore, the UE2 returns a 500 response (Message 7 to
Message 12).
3. As a caller of the refresher, after receiving a 500 response from the UAS, the UAC sends
a BYE message (Message 13 to Message 18) to release related resources.
4. The UAS returns a 200 response (BYE) to release related resources.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 40

Enhancement
Table 1-8 lists the release history of the Session Timer feature.

Table 1-8 Release history of the Session Timer feature

History Version Details Release Plan

Second release V100R008C01 The CSCF can set -

up a Session Timer
even when the UE
does not support the
Session Timer
mechanism.
Initial release V100R003C02 - -

Dependency
The Session Timer feature does not have any interaction with other features.

1.1.21 SWP-CSCF-BS-011400 Long Call Audit

Availability
The P-CSCF and S-CSCF support this feature from CSC3300 V100R006 onwards.

Summary
The P-CSCF and S-CSCF can use INFO/OPTION messages to detect long calls. When
detecting a long call, the P-CSCF or S-CSCF instructs the calling party and called party to
release the call, thus preventing resource deadlock.

Benefits
For subscribers
This feature can prevent unnecessary call charges resulting from long calls.
For carriers
This feature can prevent resource deadlock and unnecessary call charges, thus helping to
improve the credit standing of carriers.

Description
Based on the configured period, the P-CSCF or S-CSCF sends INFO messages to the UEs at
both sides to detect whether the session is suspended. The messages, which are configurable,
can be INFO or UPDATE.
Upon receiving a 481 response from any UE, the P-CSCF or S-CSCF sends a BYE message
to the UEs at both sides to terminate the session.
If no response is received from an UE or a 408 response is received, the P-CSCF or S-CSCF
resends INFO messages to the peer entity. The number of times that the P-CSCF or S-CSCF

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 41

resends INFO messages is configurable. If a 408 response is still received, the P-CSCF or
S-CSCF sends a BYE message to the UEs at both sides to terminate the session.
After receiving a response other than 481 or 408, the P-CSCF/S-CSCF restarts the detection
timer.
The following parameters are supported:
Enable long call audit: Indicates whether to enable the long call audit feature. By
default, the feature is enabled.
Audit period: Indicates the interval for detecting long calls. The default value is 30
minutes.
Sending times of audit message: Indicates the number of times audit messages are
resent. The default value is 0, that is, no audit message is resent.
Sending interval of audit message: Indicates the interval for resending audit messages.
The default value is 0 seconds, that is, an audit message is resent immediately after a
timeout response is received.
Message type: Indicates the message type that supports the long call audit. The options
are INFO and UPDATE. The default message is INFO.

Enhancement
None

Dependency
None

1.1.22 SWP-CSCF-BS-011500 Seamless Upgrade

Availability
This feature is available from CSC3300 V100R006 onwards. The CSC3300 supports this
feature when serving as a P-CSCF, an I-CSCF, an S-CSCF, a BGCF, or an OCG.

Summary
The CSC3300 supports dual-plane software upgrade. That is, one plane provides services
while the other plane performs the software upgrade. The upgrade process consists of
preparation, plane division, upgrade of the secondary plane, switchover of the primary and
secondary planes, upgrade of the primary plane, plane combination, and upgrade verification.
In addition, the CSC3300 supports dynamic data backup between the two planes so that the
connected services are not disrupted during the plane switchover. During the plane switchover,
the system may fail to accept new service requests within 10 seconds.

Benefits
For subscribers
The system availability is improved.
For carriers
This feature helps to minimize service disruption during software upgrade and thus
improve the brand name of the carriers.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 42

Description
The CSC3300 supports dual-plane software upgrade. That is, one plane provides services
while the other plane performs the software upgrade. The upgrade process consists of
preparation, plane division, upgrade of the secondary plane, switchover of the primary and
secondary planes, upgrade of the primary plane, plane combination, and upgrade verification.
In addition, the CSC3300 supports dynamic data backup between the two planes so that the
connected services are not disrupted during the plane switchover. During the plane switchover,
the system may fail to accept new service requests within 10 seconds.

Enhancement
None

Dependency
None

1.1.23 SWP-CSCF-BS-011600 I-CSCF Redundancy Supported by

the P-CSCF/S-CSCF
Availability
Table 1-9 describes the requirements for implementing the I-CSCF Redundancy Supported by
the P/S-CSCF feature.

Table 1-9 Requirements for implementing the I-CSCF Redundancy Supported by the P/S-CSCF
feature

Required NEs Required Version License Support

P-CSCF V100R003C02 or later This feature does not require
license support.
I-CSCF
S-CSCF

Summary
When the P-CSCF or the S-CSCF queries the IP address of the I-CSCF by the DNS server,
multiple IP addresses are obtained. If the time for the P-CSCF or the S-CSCF to send a
request to the IP address of the first I-CSCF expires, this request is sent to other I-CSCF in
sequence. In this way, geographic disaster recovery of the I-CSCF is provided.
The IMS solution introduces the concept of control and bearer separation into the telecom
network based on IP. The CSC3300 controls the services of the entire network. The terminals
of different types access the IMS, and then use the IMS services through their own access
networks. Based on this network structure, the CSC3300 is the core part for service
processing in the telecom network. The reliability of the CSC3300 subsystem is the basis of
the reliability of the entire network.
The IMS solution, based on 3GPP, has mechanisms to ensure high reliability of the IMS
network, including the following:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 43

When the P-CSCF is faulty, the UE can obtain several P-CSCF domain name lists
through Dynamic Host Configuration Protocol (DHCP) to choose another P-CSCF to
access the network.
When the S-CSCF is faulty, the I-CSCF can select an S-CSCF again.
When the re-registration is invalid, the UE can send an initial registration request.
Based on these mechanisms, when the P-CSCF and the S-CSCF are faulty, the UE can regain
the network services by re-registration. Before re-registration, however, the services are
interrupted.

Benefits
Table 1-10 describes the benefits of the I-CSCF Redundancy Supported by the P/S-CSCF
feature.

Table 1-10 Benefits of the I-CSCF Redundancy Supported by the P/S-CSCF feature

Beneficiary Description
Carriers When a fault occurs, carriers can maintain the
service, thus enhancing stability and reliability of
networks.
Subscribers The UE of a subscriber can detect the failure of a
key network entity and select another backup
network entity to process the call.

Description
Multiple IP addresses are configured for the domain name of the I-CSCF in the DNS. The
I-CSCFs that can be backed up for each other are specified. When an I-CSCF is faulty, the
network entity that sends the message to the I-CSCF can obtain another I-CSCF IP address
from the DNS and resend the message to this I-CSCF. In this way, network reliability is
enhanced.
Processing I-CSCF Redundancy Supported by the P-CSCF
Figure 1-7 shows the procedure for processing I-CSCF redundancy supported by the P-CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 44

Figure 1-7 Procedure for processing I-CSCF redundancy supported by the P-CSCF

The procedure for processing the I-CSCF redundancy supported by the P-CSCF is as follows:
1. The P-CSCF receives the SIP requests from the UE, such as the REGISTER and
INVITE messages, and then the P-CSCF sends or forwards these requests to the I-CSCF.
2. When the P-CSCF queries the DNS for the IP address of the I-CSCF domain name, the
DNS returns two or over two IP address lists.
3. Based on the IP address list returned by the DNS, the P-CSCF sends a SIP request to the
first I-CSCF listed in the IP address list.
4. When the time for forwarding the SIP request to the first I-CSCF expires, the P-CSCF
sends the SIP request to the next I-CSCF in the IP address list. (By default, the time for
the P-CSCF to wait for the response from the I-CSCF is 32s.)
5. When the time for forwarding the SIP request to this I-CSCF expires, the P-CSCF sends
the SIP request to the next I-CSCF.
6. After the available I-CSCF is determined, the message is forwarded to the S-CSCF.
7. The S-CSCF returns a response to the I-CSCF that initiates the message.
8. The I-CSCF returns the response to the P-CSCF.
9. The P-CSCF continues to forward the received response to the UE.
Processing I-CSCF Redundancy Supported by the S-CSCF
Figure 1-8 shows the procedure for processing I-CSCF redundancy supported by the S-CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 45

Figure 1-8 Procedure for processing I-CSCF redundancy supported by the S-CSCF

The procedure for processing I-CSCF redundancy supported by the S-CSCF is as follows:
1. The S-CSCF receives an INVITE request from the P-CSCF.
2. When the S-CSCF queries the IP address of the I-CSCF domain name from the DNS, the
DNS returns two or more than two IP address lists.
3. Based on the IP address list returned by the DNS, the S-CSCF sends a SIP request to the
first I-CSCF listed in the IP address list.
4. When the time for forwarding the SIP request to the first I-CSCF expires, the S-CSCF
sends the SIP request to the next I-CSCF in the IP address list. (By default, the time for
the S-CSCF to wait for the response from the I-CSCF is 32s.)
5. When the time for forwarding the SIP request to this I-CSCF expires, the S-CSCF sends
the SIP request to the next I-CSCF.
6. After the available I-CSCF is determined, the message is forwarded to the terminating
S-CSCF.
7. The terminating S-CSCF returns a response to the I-CSCF that initiates the message.
8. The I-CSCF returns the response to the originating S-CSCF.
9. The S-CSCF continues to forward the received response to the P-CSCF.

Enhancement
Table 1-11 lists the release history of the I-CSCF Redundancy Supported by the P/S-CSCF
feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 46

Table 1-11 Release history of the I-CSCF Redundancy Supported by the P/S-CSCF feature

History Version Details Release Plan

Initial release V100R003C02 - -

Dependency
The I-CSCF redundancy supported by the P-CSCF/S-CSCF feature does not have any
interaction with other features.

1.1.24 SWP-CSCF-BS-011700 DNS Buffer Supported by the

P/I/S-CSCF
Availability
This feature is introduced in CSC3300 V100R003.

Summary
The CSCF can buffer the DNS query results. Thus, the CSCF need not query the DNS server
frequently. In addition, it can use the data in the buffer when the DNS server is faulty.

Benefits
For subscribers
Subscribers can enjoy more reliable services.
For carriers
Carriers are the main beneficiaries of this feature.
This function helps to improve system reliability.

Description
Record range of the DNS buffer
By default, the CSCF can buffer 200 records, and does not buffer the ENUM data and
NP data. Each service processes (SCU) has a DNS buffer.
Update policy of the DNS buffer
The DNS server checks DNS records periodically and updates the data at an interval of
600 seconds. In this way, when any record changes on the DNS server, the record is also
updated in the system buffer. The update is triggered by services.
Aging overflow processing of the DNS buffer
An aging DNS record is reserved for a period but not deleted. When a record is added to
the service module buffer, the record with the shortest TTL is deleted if the space in the
buffer is insufficient.

Enhancement
The service buffer is provided from CSC3300 V100R006 onwards.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 47

Dependency
None

1.1.25 SWP-CSCF-BS-011800 Enhanced Subscriber Tracing

Function
Availability
This feature is introduced in CSC3300 V100R003.

Summary
When identifying a problem, this feature helps you trace a single subscriber to obtain the
processing tracks of the subscriber on the CSCF.

Benefits
For subscribers
When a fault is detected, this feature helps subscribers to find the location of the fault
quickly.
For carriers
Carriers are the main beneficiaries of this feature and can rectify faults conveniently.

Description
When a fault is detected, enter the subscriber ID that involves the fault on the OMU. The call
tracks of the subscriber on the CSCF are synchronized to the OMU. By performing the
analysis of the call tracks, you can identify the fault.

Enhancement
None

Dependency
None

1.1.26 SWP-CSCF-BS-011900 PSI Feature

Availability
Table 1-12 describes the requirements for implementing the PSI feature.

Table 1-12 Requirements for implementing the PSI feature

Required NEs Required Version License Support

P-CSCF V100R003C01 or later This license does not require

license support.
I-CSCF

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 48

Required NEs Required Version License Support

S-CSCF
HSS V900R002 or later
AS V100R002 or later

Summary
The services and groups owned by an application server (AS) can be identified by a PSI.
A PSI is not the URI of a subscriber. It is an identity that identifies a service or a group hosted
by an AS, such as presence, messaging list, and conferencing. These services can be used
without registration. Subscribers can create temporary PSIs in the ASs to use these services.
A PSI is in SIP URI or TEL URI format. For example, in message services, the messaging list
service uses the PSI sip:[email protected]. A PSI must be unique.
A PSI is planned based on the existing SIP route rules.
The PSI is classified into the following types:
Wildcard PSI
A wildcard PSI contains wildcards, for example, sip:as!.*[email protected]. It can be
sip:[email protected] or [email protected].
Specific PSI
A specific PSI does not contain wildcards, for example, sip:[email protected].

Benefits
Table 1-13 describes the benefits of the PSI feature.

Table 1-13 Benefits of the PSI feature

Beneficiary Description
Carriers The PSI feature enables carriers to provide various
value-added services through third-party service
providers, thus increasing the number of subscribers
and business revenues.
Subscribers The PSI feature enables subscribers to enjoy
diversified value-added services, thus enhancing
customer satisfaction.

Description
When the PSI is used for call origination, messages are sent to the S-CSCF directly.
When the PSI is used for call termination, the call can be terminated on the caller side
based on iFC. The terminating S-CSCF can also routes the call to the destination AS

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 49

based on iFC, or the terminating I-CSCF can also directly route the call to the destination
AS based on the configured AS address.
If the I-CSCF and S-CSCF support the P-Profile-Key header field, the I-CSCF and
S-CSCF send PSI subscriber information through this header field during a PSI call. If
no direct route to the AS is configured on the I-CSCF, the I-CSCF queries the HSS to
determine whether the subscriber is a PSI subscriber, and then sends the PSI subscriber
information to the S-CSCF through the P-Profile-Key header field. The S-CSCF queries
the local data of the PSI subscriber first. If no matching data is found, the S-CSCF
queries the HSS for the PSI subscriber data. The HSS then queries only the PSI
subscriber data table. Thus, the query efficiency is improved.
When the PSI Is Used for Call Origination
When the PSI is used for call origination, Huawei IMS system routes the call as follows:
If the AS can resolve the address of the I-CSCF in the home network of the callee, the
AS directly sends a request to the I-CSCF on the callee side, as shown in the Figure 1-9.

Figure 1-9 When the PSI is used for call origination (1#)
1. INVITE 2. INVITE 3. INVITE 4. INVITE

AS I-CSCF S-CSCF P-CSCF UE

Normally, an S-CSCF is allocated to serve an AS. The call from the AS is first routed to
the serving S-CSCF and then is processed by the S-CSCF as a normal call, as shown in
the Figure 1-10.

Figure 1-10 When the PSI is used for call origination (2#)

1. INVITE from 2. INVITE Other

PSI domain
AS S-CSCF

When the PSI Is Used for Call Termination

When the PSI is used for call termination (that is, Request-URI is a PSI),the PSI call can be
terminated either on the caller side or on the callee side. The scenarios are as follows:
The PSI call is terminated on the caller side and is routed to the AS with this PSI based
on the iFC of the caller, as shown in the Figure 1-11.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 50

Figure 1-11 When the PSI call is terminated on the caller side

1. INVITE 2. INVITE

UE P-CSCF S-CSCF

A PSI call is terminated on the callee side. The terminating I-CSCF routes the call to the
AS with this PSI in the following three ways:
1. If a PSI route is configured on the I-CSCF, the I-CSCF queries the local configuration
for the AS address, and then directly routes the call to the destination AS.
2. If a PSI route is not configured on the I-CSCF, but the PSI and iFC data are configured
on the HSS, the I-CSCF queries the HSS for the address of the terminating S-CSCF, and
then routes the call to the terminating S-CSCF. The terminating S-CSCF then routes the
call to the destination AS based on the iFC data of the PSI. This routing process is
similar to the routing process of a normal call.
3. If a PSI route is not configured on the I-CSCF, but the PSI and the associated AS address
are configured on the HSS, the terminating I-CSCF queries the HSS for the AS address
and then directly routes the call to the destination AS.
Implementation Flow
Assume that the I-CSCF and S-CSCF support the P-Profile-Key header field. The following
describes the implementation flow of a call that is originated from an ordinary subscriber to a
PSI subscriber and terminated on the callee side, as shown in the Figure 1-12.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 51

Figure 1-12 Implementation flow of a call to a PSI subscriber

Originating
network Terminating network

S-CSCF I-CSCF HSS S-CSCF Mediax

1. INVITE

P1
2a. INVITE
L1
2. INVITE

P2
3a. INVITE
L2
3. LIR

P3
4. LIA

P4
5. INVITE
5a. INVITE
L3
P5
6. SAR

P6
7. SAA

P7
8. INVITE

The implementation flow on the callee side is as follows: (The call is processed according to
the ordinary call flow on the caller side. The implementation flow on the caller side is not
described here.)
P1: After receiving an INVITE message, the terminating I-CSCF-T sends an LIR message to
the HSS.
P2: If the HSS finds PSI subscriber data, the HSS returns an LIA message to the I-CSCF,
which carries a wildcard PSI AVP such as sip:chatroom-!.*[email protected].
P3: After receiving the LIA message, the I-CSCF determines whether the LIA message
contains the P-Profile-Key header field. If yes, the I-CSCF deletes the header field from the
LIA message and then adds the P-Profile-Key header field to the LIA message. The I-CSCF
fills the P-Profile-Key header field with the value of wildcard PSI AVP. For example, the
P-Profile-Key header field P-Profile-Key:<sip:chatroom-!.*[email protected]> indicates a
wildcard PSI. Then, the I-CSCF forwards the INVITE message to the S-CSCF based on the
address or capability set of the S-CSCF carried in the LIA message returned by the HSS.

If the P-Profile-Key header field is

P-Profile-Key:<sip:chatroom-!.*[email protected]>;usertype=wpui, , it indicates that the IMPU is a
wildcard IMPU.

P4: After receiving the INVITE message, the S-CSCF determines whether the INVITE
message contains the P-Profile-Key header field without the extension parameter
usertype=wpui. If yes, the S-CSCF regards the subscriber as a PSI subscriber. If the S-CSCF

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 52

does not find any matching record in the local PSI subscriber data, the S-CSCF fills the
wildcard PSI AVP in an SAR message with sip:chatroom-!.*[email protected] in the
P-Profile-Key header field, and then sends the SAR message to the HSS to download service
data.
P5: After receiving the SAR message, the HSS determines whether the SAR message contains
a wildcard PSI AVP. If yes, the HSS queries the PSI subscriber data table based on the AVP. If
the HSS finds the PSI subscriber data record, the HSS returns an SAA message to the S-CSCF,
which carries the subscriber type DISTINCT_PSI or WILDCARDED_PSI.
P6: After receiving the SAA message, the S-CSCF resolves the SAA message and determines
that the subscriber is a PSI subscriber. In addition, the S-CSCF adds the subscriber
information to the local PSI subscriber data and forwards the INVITE message to the
destination AS.
The branch scenarios are as follows:
L1: If a PSI route is configured on the I-CSCF, the I-CSCF directly routes the call to the
destination AS.
L2: If the associated AS address is configured on the HSS, the HSS returns the AS address to
the I-CSCF through the LIA message, and the I-CSCF directly routes the call to the
destination AS.
L3: For this branch, there are two scenarios:
If the PSI is configured with the iFC data on the HSS, the I-CSCF queries the HSS for
the address of the terminating S-CSCF and then routes the call to the terminating
S-CSCF. The terminating S-CSCF then routes the call to the destination AS based on the
iFC data of the PSI.
If the S-CSCF finds PSI data in the local PSI dynamic configuration table, the S-CSCF
directly routes the call the PSI subscriber without querying the HSS.

Enhancement
Table 1-14 lists the release history of the PSI feature.

Table 1-14 Release history of the PSI feature

History Version Details Release Plan

Second release V100R006C03 The I-CSCF and -
S-CSCF support the
P-Profile-Key
header field.
Initial release V100R003C01 - -

Dependency
The PSI feature does not have any interaction with other features.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 53

1.1.27 SWP-CSCF-BS-012100 Quick Re-Registration

Availability
This feature is introduced in CSC3300 V100R006.

Summary
Before forwarding an initial registration request to the core network, the P-CSCF changes the
value of expire to reduce the messages sent to the S-CSCF during the re-registration.

Benefits
When the traffic is heavy, this function helps to prevent the S-CSCF from receiving large
number of frequent re-registration requests, thus improving the processing capability of the
S-CSCF.

Description
Initial registration procedure
On receiving an initial registration request, the P-CSCF checks the registration validity period
in the request. If the period is shorter than that set on the core network, the edge agent device
changes the period in the same way as set on the core network, and then forwards the request
to the S-CSCF. In this case, the registration validity period stored on the S-CSCF is prolonged.
This helps to reduce the re-registration message exchanges between network entities, thus
lightening the traffic on the network.
The following figure takes an example to describe the initial registration procedure. Assume
that:
A terminal sends an initial registration request with the registration period as 30s.
The registration period on the core network set by the P-CSCF is 1200s.
The I-CSCF processing, and the interworking and authentication between the S-CSCF
and the HSS are omitted.
Figure 1-4 Initial registration procedure

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 54

Re-registration procedure
On receiving a re-registration request, the P-CSCF checks the registration validity period in
the request to determine whether to perform the re-registration on the core network. If the
re-registration is required, the P-CSCF changes the registration period in the re-registration
request in the same way as set on the core network, and then forwards the re-registration
request to the S-CSCF. This helps to reduce the signaling exchange between the P-CSCF and
the S-CSCF. On the S-CSCF, the number of received re-registration requests is reduced, and
thus the load caused by the frequent re-registration is also reduced. The response messages
sent to the terminal are normal messages, such as the 200 responses, and are not restricted by
terminal types.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 55

Enhancement
The quick re-registration function is provided from CSC3300 V100R006 onwards.

Dependency
None

1.1.28 SWP-CSCF-BS-012200 Independent Charging Network Port

Availability
This feature is introduced in CSC3300 V100R006.

Summary
The network port for transmitting charging information can be independent of service
network port or use the same service network port.
Under the heavy system load, this function ensures the reliable transmission of charging
information.

Benefits
For subscribers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 56

Subscribers can enjoy optimized charging services.

For carriers
The reliable charging system design helps carriers to provide optimized services and gain
more benefits.

Description
The charging network port can be independent of service network port: When configuring NE
IP addresses, you can set multiple IP addresses and specify an IP address as the charging IP
address through which only the charging information is sent.
The charging network port can use the service network port: If the charging IP address is not
configured, the charging information and service information are sent through the same IP
address.

Enhancement
None

Dependency
None

1.1.29 SWP-CSCF-BS-012300 Lawful Interception

Availability
This feature is introduced in CSC3300 V100R003.

Summary
Lawful interception allows the national security agency of a country to intercept the call
activities and the communication contents of a specific subscriber according to security
requirements.
The CSC3300 supports the following lawful interception schemes:
Distributed lawful interception, compliant with the 3GPP TS 33.107 and 3GPP TS
33.108 specifications
Centralized lawful interception, compliant with the ETSI TS 187 005 specifications
The lawful interception feature supports the following protocols:
The distributed lawful interception supports the ETSI PS protocols (3GPP TS 33.107 and
3GPP TS 33.108)
The centralized lawful interception supports the ETSI CS (ETSI TS 101 671) and SOSM
protocols.

Benefits
For subscribers
None
For carriers
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 57

Description
Distributed lawful interception

1. The LIG, located between the NEs and the monitoring center, implements the conversion
between the X interface and the HI interface. The LIG provides the functions of the
ADMF, DF2, and DF3. The ADMF implements management functions such as
allocating intercept objects, the DF2 processes IRI reports, and the DF3 processes CC
reports.
2. The P/S-CSCF provides the X1/X2 interface for the LIG, through which the IRI report is
sent to the LIG. The GGSN/SBC provides the X3 interface for the LIG, through which
the CC report is sent to the LIG. The GGSN sends the CC report to the LIG directly;
however, the SBC sends the CC report to the LIG through the P-CSCF, on which the
SPDF controls and copies the CC report.
3. When an object is monitored from multiple monitoring centers, the GGSN/SBC sends
only one media copy to the LIG and the LIC makes multiple copies and then sends them
to the monitoring centers.
Centralized lawful interception

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 58

1. The LIG, located between the NEs and the monitoring center, provides the conversion
between the X interface and the HI interface. The LIG provides the functions of the
ADMF, DF2, and DF3. The ADMF implements management functions such as
allocating intercept objects, the DF2 processes IRI reports, and the DF3 processes CC
reports.
2. The ATS/P-CSCF/S-CSCF/CCTF provides the X1 interface for the LIG. The
ATS/P-CSCF/S-CSCF provides the X2 interface for the LIG, through which the IRI
report is sent to the LIG. The CCTF/UMG, under the control of the S-CSCF, copies the
media of the monitored subscriber to the LIG (or to the monitoring center) in the mode
of originating a call by using ISUP/PRA/SIP-I. The call will be divided into the caller's
media session and the callee's session.
3. When an object is monitored from multiple monitoring centers, the NE is responsible for
making multiple copies and sending them to the monitoring centers.

Enhancement
The distributed lawful interception is provided from CSC3300 V100R003.
The centralized lawful interception is provided from CSC3300 V100R006.

Dependency
The distributed lawful interception requires the coordination of the SPDF, SBC, and LIG.
The centralized lawful interception requires the coordination of the CCTF/UMG, ATS,
and LIG.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 59

1.1.30 SWP-CSCF-BS-012400 MRFC-Supported Interfaces for

Interworking with Multiple Devices
SWP-CSCF-BS-012401 Mr (MRFC - CSCF)

Availability
This feature is introduced in CSC3300 V100R006.

Summary
The Mr interface allows the MRFC to exchange SIP messages with the S-CSCF.
The Mr interface complies with 3GPP TS 24.229-740 and supports RFC3261, RFC3262
(100rel), RFC3311 (UPDATE), RFC3455 (3G headers), RFC3312 (precondition), and session
timer.

Benefits
None

Description
None

Enhancement
None

Dependency
None

SWP-CSCF-BS-012402 Sr (MRFC - AS)

Availability
This feature is introduced in CSC3300 V100R006.

Summary
The MRFC communicates with the AS over the Sr interface.
The Sr interface complies with 3GPP TR 24.880-100. Currently the Sr interface is used to
obtain VXML scripts from the HTTP server and reports the execution results to the AS. When
using the HTTP interface, the MRFC serves as a client and complies with RFC2616.

Benefits
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 60

Description
None

Enhancement
None

Dependency
None

SWP-CSCF-BS-012403 Mp (MRFC - MRFP)

Availability
This feature is introduced in CSC3300 V100R006.

Summary
The MRFC communicates with the MRFP over the Mp interface and supports the following
interfaces:
NETANN (RFC4240) over SIP
VoiceXML2.0 over SIP
MSML (IETF draft-saleem-msml) over SIP
H.248

Benefits
None

Description
None

Enhancement
None

Dependency
None

SWP-CSCF-BS-012404 Rf (MRFC - CCF)

Availability
This feature is introduced in CSC3300 V100R006.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 61

Summary
The MRFC performs offline charging through the Rf interface. The Rf interface adopts the
Diameter protocol and complies with 3GPP TS 32.240-630, 32.260-640, 32.299-650,
RFC3588, and RFC4006.

Benefits
None

Description
None

Enhancement
None

Dependency
None

1.2 MI2SCSCPSR01 CSC3300 V100R009 P-CSCF

Subscriber Registered - per k subs
1.2.1 SWP-CSCF-PSR-012300 Registration Supported by the
P-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
IMS registration is performed to bind an IMPU to an IP address on the CSCF, and thus the UE
can enjoy IMS services.
IMS deregistration is performed to unbind an IMPU with an IP address on the CSCF.
An MON subscriber has multiple IMPUs. These IMPUs together comprise a set. On the
CSC3300, if an IMPU in the set is registered, the other IMPUs are registered automatically.
The P-CSCF supports the registration, deregistration, and implicit registration of subscribers.

Benefits
For subscribers
This feature enables subscribers to enjoy IMS services.
For carriers
This feature enables carriers to provide IMS services to subscribers.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 62

Description
This feature provides the following functions:
Initial registration

1. The P-CSCF receives an initial registration request.

The P-CSCF adds the host name or domain name to the path header field.
The P-CSCF adds Require:path.
The P-CSCF adds P-Visited-Network-ID to identify the visited network where the
P-CSCF is located.
The P-CSCF generates icid and adds P-Charging-Vector for the correlation of call
detail records (CDRs).
The P-CSCF queries the DNS for the home network of the subscriber, and forwards the
registration request to the I-CSCF of the home network.
2. The I-CSCF receives the initial registration request and determines whether the request is
from the trusted domain. For the request from a distrust domain, the I-CSCF returns a 403
message to reject the request. The I-CSCF obtains impu, impi, and P-Visited-Network-ID of
the subscriber, and sends a user-authorization-request (UAR) to the HSS to check the
subscriber rights. If the HSS returns a roaming restriction, the I-CSCF returns a 403 message
to reject the registration request; if the HSS returns a success response, the I-CSCF selects a
suitable S-CSCF based on the subscriber rights returned by the HSS.
3. The S-CSCF returns a 200 OK response, indicating that the registration is successful. The
P-CSCF records the subscriber registration status and related information (such as impu,
contact address, and service-route) in the database.
Re-registration

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 63

1. The P-CSCF receives a re-registration request.

1. The P-CSCF receives a deregistration request.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 64

The P-CSCF queries the DNS for the home network of the subscriber, and forwards the
registration request to the I-CSCF of the home network.
2. The I-CSCF receives the deregistration request. The I-CSCF obtains impu, impi, and
P-Visited-Network-ID of the subscriber, sends a UAR message to the HSS to query the
S-CSCF that serves the subscriber, and then forwards the deregistration request to the
S-CSCF.
3. The S-CSCF returns a 200 OK response, indicating that the deregistration is successful.
The P-CSCF clears the subscriber registration data and related information from the database.
Implicit registration
Through the implicit registration function, if an IMPU of a subscriber is registered, the other
IMPUs in the same set are registered automatically. If an IMPU is deregistered, the other
IMPUs in the same set are also deregistered automatically.
The HSS, P-CSCF, and S-CSCF support the implicit registration.
During the registration, the HSS downloads all the IMPUs registered through the implicit
registration to the S-CSCF through the SAA (Cx) interface; the S-CSCF sends the IMPUs to
the P-CSCF and UE through the P-Associated-URI in the 200 OK response. For example:
SIP/2.0 200OK
P-Associated-URI: <sip:[email protected]>,
<sip:[email protected]>,
<sip:[email protected];user=phone>

Through this message, the UE can learn the registered IMPUs and use these IMPUs to make
calls. The P-Associated-URI is defined for transferring the SIP URI. Therefore, the S-CSCF
sends the URI (Tel: +86-755-1234567) in Tel mode to the P-CSCF and UE in SIP URI format.

Enhancement
None

Dependency
None

1.2.2 SWP-CSCF-PSR-012400 Registration Events Subscribed by

the P-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
When a subscriber is registered successfully, the P-CSCF sends a subscription request to the
S-CSCF for the subscriber registration status.

Benefits
For carriers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 65

When a subscriber is deregistered on the network side, the P-CSCF learns the
deregistration through the NOTIFY message sent from the S-CSCF, and deletes the local
subscriber data to improve network performance.

Description
When a subscriber is registered successfully, the P-CSCF sends a subscription message
to the S-CSCF for the subscriber registration status.
When the subscription times out, the P-CSCF sends a re-subscription message.
When the registration status of the subscriber changes, the S-CSCF sends a NOTIFY
message to inform the P-CSCF of the status change. If the P-CSCF detects that the
registration status of the subscriber changes to deregistered, the P-CSCF deletes the local
subscriber data.
The P-CSCF determines whether to charge for the P-CSCF subscription and NOTIFY
messages based on the configuration.

Enhancement
None

Dependency
None

1.2.3 SWP-CSCF-PSR-012500 Roaming Supported by the P-CSCF

Availability
This feature is introduced in CSC3300 V100R002.

Summary
When subscribers roam to other networks, the roaming function of the CSC3300 enables the
subscribers to enjoy the services provided by the home network.
The CSC3300 and the HSS work together to implement the roaming function and the roaming
restriction function. Carriers can specify the networks where subscribers can roam. The
roaming restriction function enables the system to implement subscriber mobility
management. That is, the system can prohibit subscribers from roaming or restrict the
roaming areas. When subscribers roam to an area that is prohibited by the system, the system
does not allow the subscriber to register or use any IMS service.

Benefits
For subscribers
The subscribers on the visited network can enjoy the services provided by the home
network.
For carriers
Carriers can implement subscriber mobility management.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 66

Description

P: Assume that a subscriber is defined in Xi'an, and the allowed roaming area is Xi'an.
P1: The subscriber connects to the network through the SBC in Xi'an.
P2: Based on the source IP address and destination IP address in the registration packet, the
P-CSCF learns that the subscriber connects to the network through the SBC of Xi'an. The
P-CSCF obtains the visited network ID from the access network in Xi'an, and adds the ID to
the registration request. The P-CSCF queries the DNS to find the I-CSCF on the subscriber's
home network in Xi'an, and forwards the registration request to the I-CSCF.
P3: The HSS compares the visited network ID in the UAR with the visited network ID set
when the subscriber is defined. If the two IDs are the same, the HSS returns a success
response.
P5: The subscriber connects to the network through the SBC in Ankang.
P6: Based on the source IP address and destination IP address in the registration packet, the
P-CSCF learns that the subscriber connects to the network through the SBC of Ankang. The
P-CSCF obtains the visited network ID from the access network in Ankang, and adds the ID
to the registration request. The P-CSCF queries the DNS to find the I-CSCF on the
subscriber's home network in Xi'an, and forwards the registration request to the I-CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 67

P7: The HSS compares the visited network ID in the UAR with that set when the subscriber is
defined. If the two IDs are different, the HSS returns a failure response, indicating the
roaming restriction.
P8: The I-CSCF receives a failure UAA response, and returns a 403 message to reject the
registration request.

Enhancement
The roaming restriction based on the access network is provided from CSC3300 V100R005
onwards.

Dependency
None

1.2.4 SWP-CSCF-PSR-012600 Distinguishing Subscriber

Registration Features by userinfo on the P-CSCF
Availability
This feature is introduced in CSC3300 V100R003.

Summary
The CSC3300 enables multiple subscribers with the same IP address and port number to
access the IMS network.

Benefits
For subscribers
Multiple subscribers with the same IP address and port number can access the IMS
network at a time.
For carriers
The access flexibility of carriers is improved.
The devices that use only fixed IP addresses and ports can connect to the IMS network
conveniently.

Description
The IAD, PBX, and MSAN may use the fixed IP addresses and ports to connect to the IMS
network. When multiple subscribers access the IMS network through a single terminal, these
subscribers use the same IP address and port number. userinfo (usually containing the
subscriber number) in the Contact header field of the REGISTER or INVITE messages vary
with according to the subscribers. The CSC3300 can distinguish subscribers by userinfo and
enable the subscribers to access the IMS network.

Enhancement
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 68

Dependency
None

1.3 MI2SCSCSSR01 CSC3300 V100R009 S-CSCF

Subscriber Registration
1.3.1 SWP-CSCF-SSR-012700 Registration Supported by the
S-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
IMS registration refers to a binding between the IMPU of a UE and the URI containing a host
name or IP address when the UE accesses a server. The registration can be implemented by
sending a Register request.
Registration is a process in which a subscriber requests IMS services and the IMS network
authenticates and authorizes the subscriber to access the network. Before setting up a session,
a UE must be registered with the IMS network.
The S-CSCF supports the functions such as initial registration, re-registration, deregistration,
and third-party registration.

Benefits
For subscribers
Registration is the prerequisite for subscribers to use IMS services.
For carriers
Registration is the prerequisite for subscribers to use IMS services.

Description
This feature provides the following functions:
Initial registration

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 69

1. The UE sends a registration request to the P-CSCF. Depending on the type of the IP
access network, the UE can query the DHCP/DNS for the P-CSCF or follow the PDP
context activation process of the GPRS to find the P-CSCF
2. The P-CSCF queries the home network of the subscriber from the DNS, and forwards
the registration request to the I-CSCF of the home network.
3. The I-CSCF submits the subscriber data to the HSS. After the HSS assigns service rights
to the subscriber, the HSS returns the capability set of the S-CSCF serving the subscriber
to the I-CSCF. Then, the I-CSCF selects an S-CSCF based on the required capability.
4. After receiving the registration request, the S-CSCF downloads the subscriber related
data (authentication information) from the HSS. Then, the S-CSCF sends a 401
(Unauthorized) response to the UE based on the subscriber authentication information.
5. The UE sends another registration request with a response containing in the
Authorization to the S-CSCF. After receiving the registration request, the S-CSCF
authenticates the subscriber. After the authentication is passed, the S-CSCF downloads
the subscriber related data (user profile) from the HSS and saves the data in its database.
Re-registration

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 70

1. The UE sends a re-registration request to the P-CSCF.

2. The P-CSCF queries the home network of the subscriber from the DNS, and forwards
the registration request to the I-CSCF of the home network.
3. The I-CSCF submits the subscriber data to the HSS. After the HSS assigns service rights
to the subscriber, the HSS returns the S-CSCF with which the subscriber has registered
to the I-CSCF.
4. After receiving the re-registration request, the S-CSCF refreshes the registration period
of the subscriber.
Deregistration

The UE sends a deregistration request to the P-CSCF.

The P-CSCF queries the home network of the subscriber from the DNS, and forwards
the deregistration request to the I-CSCF of the home network.
The I-CSCF submits the subscriber data to the HSS. After the HSS assigns the service
rights to the subscriber, the HSS returns the S-CSCF with which the subscriber has
registered to the I-CSCF.
After receiving the deregistration request, the S-CSCF deletes the registration data of the
subscriber from its database, and notifies the subscriber of the deregistration. The HSS
also deletes the registration data of the subscriber.
Third-party registration

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 71

After a subscriber is successfully registered, the S-CSCF checks the downloaded filtering
criteria of the subscriber. Assume that an online AS serves the subscriber. The AS needs to
know whether the subscriber is registered. Thus, the filtering criteria iFC must be set to
trigger to the AS. After the subscriber is successfully registered, the S-CSCF generates a
third-party Register request containing the registered IMPU and sends the request to the AS.
Implicit registration
With the implicit registration function, if an IMPU of a subscriber is registered, the other
IMPUs in the same set are registered automatically; if an IMPU is deregistered, the other
IMPUs in the same set are also deregistered automatically.
The HSS, P-CSCF, and S-CSCF support the implicit registration.
During the registration, the HSS downloads all the IMPUs registered in implicit registration
mode to the S-CSCF through the SAA(Cx) interface, and then the S-CSCF sends the IMPUs
to the P-CSCF and terminals through the P-Associated-URI in the 200 OK response. For
example:
SIP/2.0 200OK
P-Associated-URI: <sip:[email protected]>,
<sip:[email protected]>
<sip:[email protected];user=phone>

With this message, the terminals learn the registered IMPUs and use these IMPUs to make
calls. The P-Associated-URI is defined for transferring the SIP URI. Therefore, the S-CSCF
must convert the URI of the telephone number format to the SIP URI format before sending
the 200 OK response.
Cx/Dx (CSCF - HSS/ CSCF - SLF)
The Cx interface is an interface between the I-CSCF and the HSS or between the S-CSCF and
the HSS.
The Dx interface is an interface between the I-CSCF and the SLF or between the S-CSCF and
the SLF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 72

The difference between these two interfaces is that the SLE provides the Diameter redirection
proxy function, whereas the HSS functions as the Diameter server. The I-CSCF and S-CSCF
always function as the Diameter client.
Note that the P-CSCF does not use the Cx or Dx interface.
List of commands sent through the Cx interface

Command Name Abbrevi Function Command

ation Direction
User-Authorization UAR This command is used between the CSCF->HSS
-Request/Answer /UAA I-CSCF and the HSS. It is used to HSS->I-CSCF
obtain the S-CSCF capability to
select the S-CSCF or obtain the
S-CSCF name during the SIP
registration.
Server-Assignment SAR/ This command is used between the S-CSCF->HSS
- Request/Answer SAA S-CSCF and the HSS. It is used to HSS->S-CSCF
update the S-CSCF name in the
HSS and download subscriber
configuration data to the S-CSCF.
Location-Info- LIR/LIA This command is used between the I-CSCF->HSS
Request/Answer I-CSCF and the HSS. It is used to HSS->I-CSCF
obtain the S-CSCF serving the
subscriber or the S-CSCF capacity
to select the S-CSCF during the
setup of a SIP call.
Multimedia-Auth- MAR/M This command is used between the S-CSCF->HSS
Request/Answer AA S-CSCF and the HSS to exchange HSS->S-CSCF
information so that the IMS home
network can authenticate
subscribers.
Registration-Termi RTR/RT This command is used between the HSS->S-CSCF
nation- A S-CSCF and the HSS so that the S-CSCF->HSS
Request/Answer HSS can deregister one or more
registered IMPUs of a subscriber.
Push-Profile- PPR/PPA This command is used between the HSS->S-CSCF
Request/Answer S-CSCF and the HSS. It is used to S-CSCF->HSS
send the modified user profile in
the HSS to the S-CSCF.

Dx interface:
When multiple HSS servers that can independently perform addressing are deployed on a
network, the I-CSCF and S-CSCF do not know to which HSS to contact. The Dx
interface is therefore designed. The Dx interface is always used with the Cx interface.
The function of the Dx interface is implemented through the routing mechanism
provided by an enhanced Diameter redirection proxy.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 73

To obtain an HSS address, the I-CSCF or S-CSCF sends a Cx request to the SLF. Based
on the HSS address returned from the SLF, the I-CSCF or S-CSCF sends the Cx request
to the HSS.

Enhancement
None

Dependency
None

1.3.2 SWP-CSCF-SSR-012800 Registration Event Subscription

Supported by the S-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The UE and P-CSCF can subscribe to registration events from the S-CSCF. When the
registration status of a subscriber changes, the S-CSCF notifies the UE and P-CSCF of the
current registration status of the subscriber.

Benefits
For subscribers
Subscribers know their registration status in real time. Thus, the service experience of
subscribers is improved.
For carriers
Subscription initiators (UEs or other NEs) know the registration status of subscribers in
real time, thereby maintaining consistent with the registration status on the IMS network.

Description
This feature provides the following functions:
Registration events subscribed by the UE

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 74

After successful initial registration, the UE sends a Subscribe request to subscribe to its
own registration status. The subscription applies only to the reg event, which is indicated
in the Event field of the request.

UE P-CSCF S-CSCF

Successful Registration

1、Subscribe
Event: reg
2、Subscribe
3、200 OK
4、200 OK

5、Notify
6、Notify

7、200 OK

8、200 OK

1. After successful registration, the UE sends a Subscribe request to subscribe to the

registration status of its own IMPU. The header values of the Subscribe request are as
follows:
− Event header: reg
− P-Preferred-Identity header: A registered IMPU of the subscription initiator
− Request-URI and To headers: A registered IMPU to be subscribed to
− Expires header: Subscription duration
2. Upon receiving the Subscribe request from the UE, the P-CSCF checks whether the
IMPU contained in the P-Preferred-Identity header is valid. If the IMPU is valid, the
P-CSCF fills the IMPU in the P-Asserted-Identity header field.
3. After receiving the Subscribe request, the S-CSCF performs the following operations:
Check whether the IMPU contained in the P-Asserted-Identity (PAI) is registered with
the S-CSCF.
Check the rights of the IMPU contained in the P-Asserted-Identity (PAI) and the rights
of the IMPU contained in the Request-URI. Only the IMPUs in the same implicit
registration set can subscribe to each other.
Check whether the subscription duration contained in the Expires header is out of the
configured range.
4. After successful subscription, the S-CSCF returns a 200 OK response, and sends a
Notify message to the UE. The Notify message contains an XML file, listing the current
registration status of all the IMPUs in the same implicit registration set with the IMPU
that is subscribed to.
Registration events subscribed by the P-CSCF

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 75

UE P-CSCF I-CSCF HSS S-CSCF

Successful Registration
1、Subscribe
Event: reg 2、LIR(Cx)
3、LIA(Cx)

4、Subscribe
5、200 OK
6、200 OK

7、Notify
8、Notify

9、200 OK
10、200 OK

1. After the UE is successfully registered, the P-CSCF sends a Subscribe request to

subscribe to the registration status of the UE's IMPU. The header values of the request
are as follows:
− Event header: reg
− P-Asserted-Identity header: P-CSCF (subscription initiator)
− Request-URI and To header: A registered IMPU to be subscribed to
− Expires header: Subscription duration
2. After receiving the Subscribe request, the S-CSCF performs the following operations:
Check the rights of the IMPU contained in the P-Asserted-Identity (PAI) and the rights
of the IMPU contained in the Request-URI. Only the P-CSCF with which the UE is
registered can subscribe to the registration status of the UE.
Check whether the subscription duration contained in the Expires header is out of the
configured range.
3. After successful subscription, the S-CSCF returns a 200 OK response, and sends a
Notify message to the P-CSCF. The Notify message contains an XML file, listing the
current registration status of all the IMPUs in the same implicit registration set with the
IMPU that is subscribed to.
Registration event notification
1. After successful subscription, the subscription initiator (UE or P-CSCF) receives a
Notify message from the S-CSCF, containing the current registration status of all the
IMPUs in the same implicit registration set with the IMPU that is subscribed to.
2. When events that affect the registration status of subscribers occur, such as
re-registration, subscriber initiated deregistration, or deregistration initiated on the
network side, the S-CSCF sends a Notify message. The contents contained in the XML
file vary according to events. For example:
When the HSS initiates a deregistration, the S-CSCF sends a Notify message containing
deregister in the Event header.
When the time for registration expires, the S-CSCF sends a Notify message containing
expire in the Event header.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 76

Notify SIP:P-CSCF.huawei.com
Subscription-State: terminated;reason=noresourse
<?xml version="1.0"?>
<reginfo mlns="urn:ietf:params:xml:ns:reginfo" version="3" state="partial">
<registration aor="sip:[email protected]" id="as9" state=" active ">
<contact id="76" state="terminated" event="expire">
<uri>sip:10.85.16.1</uri>
</contact>
</registration>
<registration aor="sip:[email protected]" id="as10" state=" active ">
<contact id="86" state=" terminated " event=" expire ">
<uri>sip:10.85.16.1</uri>
</contact>
</registration>
</reginfo>

Enhancement
None

Dependency
None

1.3.3 SWP-CSCF-SSR-012900 HTTP Digest Authentication

Supported by the S-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The SIP terminals on the fixed network do not support the authentication and key agreement
(IMS AKA) and Early IMS authentication schemes because the terminals are not equipped
with the subscriber identity module (SIM) card, UMTS SIM (USIM) card or ISIM card. The
HTTP Digest authentication scheme is adopted to allow these terminals to access the IMS
network.
HTTP Digest authentication is based on the HTTP protocol. For a terminal on the fixed
network that adopts HTTP Digest authentication, the subscriber must provide the user name
and password, and can access the IMS network only after passing the authentication.

Benefits
For subscribers
This feature supports authentication for fixed subscribers and mobile subscribers who
want to access the IMS network.
For carriers
The carriers can provide authentication services to both fixed and mobile subscribers by
using the existing network devices. In this way, the carriers' investment is protected and
the network access security is enhanced.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 77

Description
HTTP Digest authentication
The SIP terminals on the fixed network do not support the IMS AKA and Early IMS
authentication schemes because the terminals do not support the SIM card, USIM card, or
ISIM card. The HTTP Digest authentication scheme is adopted to allow these terminals to
access the IMS network.
HTTP Digest authentication is based on the HTTP protocol. Its authentication parameters are
the user name and password. A subscriber must provide the user name and password, and can
access the IMS network only after passing the authentication.

1. When registering with the HSS, the subscriber sets the user name and password. The
user name and password are stored in the UE and the HSS.
2. The UE sends a registration request to the IMS network.
3. The S-CSCF sends a multimedia authentication request (MAR) to the HSS to request the
authentication information.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 78

(The I-CSCF and S-CSCF use the subscriber's IMPI to query the Cx interface. In most
cases, the I-CSCF and S-CSCF obtains the IMPI from the username contained in the
Authorization header. If the Authorization header does not exist, the I-CSCF and
S-CSCF obtain the IMPU and removes the "sip:" part from the IMPU to generate the
IMPI).
4. Based on the Authentication-Scheme contained in the MAR, the HSS determines that
HTTP Digest authentication scheme should be used. The HSS calculates the HA1 based
on the Digest-Realm, user name, and password, and then sends a multimedia
authentication answer (MAA) containing the HA1 to the S-CSCF.
(The Digest-Realm is contained in the MAR message, and the user name and password
are obtained by using the IMPU to query the database.)
5. The S-CSCF saves the HA1, and generates and sends an authentication challenge to the
UE.
6. The UE calculates the Response and sends it to the S-CSCF. The S-CSCF calculates the
Response, and then compares the calculated Response with the Response received from
the UE. If the responses are the same, the authentication is passed.
Multiple authentication algorithms supported by the S-CSCF
As a result of the fixed-and-mobile convergence, the IMS network supports multiple
authentication schemes. The IMS-AKA authentication scheme for terminals equipped with
ISIM cards and the EARLY-IMS authentication scheme for terminals equipped with SIM or
USIM cards have been defined in the 3GPP standards. The EARLY-IMS authentication
scheme depends on the authentication performed by the GGSN for the UE. Two
authentication schemes for fixed terminals are defined in the TISPAN standards: the NBA
scheme and the HTTP Digest scheme. For details on the following authentication schemes,
see the related optional features.
-- AKAv1-MD5: The IMS AKA is an IMS security mechanism defined in 3GPP
TS33.203.It is applicable for an IMS subscriber using the ISIM card.
-- Early IMS: The Early IMS scheme is used to authenticate subscribers by comparing IP
addresses. It is applicable for subscribers who do not support the IMS AKA
authentication, such as 2G subscribers.
-- NBA: The NBA scheme is supported by the HSS to allow early fixed subscribers to
access the IMS network.
-- Early-AKA: For terminals equipped with the SIM or USIM cards, the HSS supports
not only the Early IMS authentication scheme, but also the Early-AKA authentication
scheme. The HSS obtains an authentication quintuple from the cHLR/AUC and performs
the Early-AKA authentication.

Enhancement
The CSC3300 V100R002 and later versions support the AKAv1-MD5, HTTP Digest, and
Early IMS authentication schemes.
The CSC3300 V100R003 and later versions support the NBA and Early-AKA authentication
schemes and multiple authentication negotiation mechanisms.
The CSC3300 V100R005 and later versions use the qop mechanism that supports the HTTP
Digest authentication scheme.

Dependency
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 79

1.3.4 SWP-CSCF-SSR-013000 Roaming Supported by the S-CSCF

Availability
This feature is introduced in CSC3300 V100R002.

Summary
Network roaming is a basic requirement since the deployment of the second generation
cellular land mobile network, that is, a network must support roaming of subscribers among
different networks. IMS subscribers can roam between countries or networks depending on
the roaming protocols agreed by the home network and the visited network.

Benefits
For subscribers
Subscribers can roam to other networks or other countries.
For carriers
The IMS network can implement charging based on the visited domain information
determined through the SIP proxy domain name in the visited domain when subscribers
roam to another network or another country. This solves the problem in the
PSTN/multimedia integrated softswitch solution that cross-area calls can only be charged
based on the IP addresses of the subscribers.

Description
IMS roaming types
The IMS network is based on the SIP protocol. The IMS networks are distinguished by
domain names. Each network has a unique domain name. The user profiles are stored in the
home HSS. Subscribers access the IMS network through the IP-CAN. After roaming to
another network, IMS subscribers can obtain the access address of the IP CAN through the
visited network or home network.
Based on the two IP-CAN access modes, the IMS network defines two basic roaming
scenarios: the IP-CAN roaming and IMS roaming. With the evolution of the network, the
roaming technology between the IMS domain and the CS domain is widely researched. The
mainstream equipment vendors have launched their solutions. The following section briefly
describes IMS roaming based on the three roaming scenarios.
IMS roaming
IMS roaming refers to accessing the home network through the P-CSCF on the visited
network.
After attaching to the IP-CAN on the visited network, subscribers can access the IMS
network through the P-CSCF on the visited network. Upon receiving the registration
request from a subscriber, the P-CSCF on the visited network queries the DNS for the
I-CSCF on the subscriber's home network. Then, the P-CSCF sends the registration
request to the S-CSCF on the home network through the I-CSCF on the home network.
The S-CSCF performs subscriber registration. All the signaling related to subscriber
services is forwarded through the P-CSCF on the visited network. This is the IMS
network roaming.
The S-CSCF supports registration of roaming subscribers.
The S-CSCF supports processing the sessions of roaming subscribers.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 80

The S-CSCF supports processing the message services and presentation services of
roaming subscribers.
IP-CAN roaming
IP-CAN roaming refers to accessing the P-CSCF on the home network by using an IP
address within the home network. The IP-CAN roaming access includes the GPRS
roaming access and other mobile IP access.
During the IP-CAN roaming, subscribers attach to the IP-CAN on the home network.
Thus, IP-CAN roaming is also called the GPRS roaming. When the GGSN is on the
home network, IMS subscribers can access the IP-CAN through the GGSN, and then
access the IMS home network. In this way, the subscribers enjoy the services provided
by the IMS home network. IMS subscribers access the IMS network through the P-CSCF
on the home network, register with the S-CSCF, and then originate calls through the
P-CSCF and S-CSCF on the home network. The calls are sent to the I-CSCF on the
home network, and then forwarded to the callees through the S-CSCF and P-CSCF on
the home network.
IP-CAN roaming mainly focuses on subscriber mobility management, authentication,
authorization, and charging during roaming. The GPRS> roaming adopts the roaming
structure of the GSM network. The SGSN on the visited network accesses the HLR/AuC
on the home network through the MAP interface, thus implementing the roaming
management of subscribers.
Inter-domain roaming
Inter-domain roaming refers to switching between domains. When the domain serving
subscribers fails to provide services because of various reasons, the services are switched
to another available domain to serve the subscribers. A typical example of the
inter-domain roaming is the VCC. When the WiFi fails, the services provided by the
WiFi are switched to the CS domain through GSM. In this way, subscribers can continue
to enjoy the services.
In the VCC scenario, a VCC application server is deployed in the IMS domain. All the
calls originated from the IMS or CS domain must be routed to the VCC application
server. Domain transfer is initiated by the UE based on the predefined conditions. The
VCC application server sets up a connection between the domain to be switched to and
the UE, switches the remote session connection to the new connection, and releases the
session connection of the switched domain. For details, see TS 23.206.

Enhancement
None

Dependency
None

1.3.5 SWP-CSCF-SSR-013100 AS-Initiated Deregistration

Supported by the S-CSCF
Availability
This feature is introduced in CSC3300 V100R006.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 81

Summary
The S-CSCF can process the registration query request or deregistration request initiated by a
trusted third-party AS.

Benefits
For carriers
The capability of processing the registration query request or deregistration request
initiated by a third party is enhanced.

Description
The S-CSCF can process the registration query request or deregistration request initiated by a
trusted third-party NE (such as the AS).
The S-CSCF can process the registration query request initiated by the AS

1. The AS sends a registration request to the S-CSCF to query the registration status of a
subscriber or the registered contact addresses of the subscriber. In the registration request,
the value of the From header is the address of the AS, and the value of the To header is
the subscriber's identity. The Contact header is not included in the request.
2. The S-CSCF checks the received registration request and finds that the values contained
in the From header and To header are different, only one address is contained in the Via
header, and the Contact header is not present. Thus, the S-CSCF determines that the
request is a registration query request initiated by the AS.
3. The S-CSCF checks whether the AS contained in the From header is the AS in the iFC
data of the subscriber or a local trusted AS. If not, the S-CSCF returns a 403 message.
4. If the AS is the one in the iFC data of the subscriber or a local trusted AS, the S-CSCF
sends the AS a 200 OK response containing all the contact addresses of the subscriber.
The S-CSCF can process the deregistration request initiated by the AS

1. The AS sends a registration request to the S-CSCF to deregister a subscriber. In the

registration request, the value of the From header is the address of the AS, the value of
the To header is the subscriber's identity, and the value of the Expires header is 0.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 82

If the AS wants to deregister some contact addresses of the subscriber, the value of the
Contact header is the contact addresses; if the AS wants to deregister all the contact
addresses, no Contact header is contained in the registration request.
2. The S-CSCF checks the received registration request and finds that the values contained
in the From header and To header are different, only one address is contained in the Via
header, and the value of the Expires header is 0. Thus, the S-CSCF determines that the
request is a deregistration request initiated by the AS.
3. The S-CSCF checks whether the AS contained in the From header is the AS in the iFC
data of the subscriber or a local trusted AS. If not, the S-CSCF returns a 403 message.

Enhancement
None

Dependency
For the registration query request or deregistration request initiated by the AS or other NEs,
the header values must comply with the rules configured on the S-CSCF.

1.4 MI2SMRCIVR01 CSC3300 V100R009

MRFC-Supported Audio IVR Channels
1.4.1 SWP-CSCF-MSR-013200 Audio IVR Operations
1.4.2 SWP-CSCF-MSR-013201 RFC4240-Based Playing
Summary
RFC4240-based playing is also called ANNC playing. According to the RFC4240 standard,
the playing function is implemented on the Mr interface through the ANNC indicator and play
parameters carried in the Request-URI in the INVITE message.

Benefits
Table 1-15 describes the benefits of the RFC4240-Based Playing feature.

Table 1-15 Benefits of the RFC4240-Based Playing feature

Beneficiary Description
Carriers The playing function can bring about various
applications. Carriers can gain economic benefits
from the provisioning of these services.
Subscribers The playing function can bring about various
applications. Subscribers can enjoy rich multimedia
services.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 83

Availability
Table 1-16 describes the requirements for implementing the RFC4240-based Playing feature.

Table 1-16 Requirements for implementing the RFC4240-based Playing feature

Required NEs Required Version License Support

MRFC V100R001 or later A license is required for the

implementation of this
feature.
MRFP V100R001 or later A license is required for the
implementation of this
feature.
AS V100R001C02 or later A license is required for the
implementation of this
feature.

Dependency
This feature does not have any interaction with other features.

Description
Introduction to ANNC Indicator
The RFC4240-based playing function is implemented through the play parameters carried in
the ANNC indicator. This section describes the ANNC indicator and its play parameters.

For details on the ANNC indicator, refer to the RFC4240 protocol.

Specification for ANNC Playing

In the RFC4240 protocol, the specifications for the ANNC playing are as follows:
ANNC-URL= sip-ind annc-ind "@"hostport; annc-parameters uri-parameters
Where:
sip-ind= "sip:" / "sips:"
annc-ind= "annc"
annc-parameters = ";" play-param [ ";" content-param ]
[ ";" delay-param]
[ ";" duration-param ]
[ ";" repeat-param ]
[ ";" locale-param ]
[ ";" variable-params ]

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 84

[ ";" extension-params ]
Uri-parameters support the following formats:
http/https
ftp
file (referencing a local or NFS (RFC 3530 [16]) object)
nfs (RFC 2224 [14])
Description of ANNC Parameters
Table 1-17 describes annc-parameters carried in the ANNC indicator.

Table 1-17 ANNC play parameters in RFC4240

Parameter Description
play Specifies the resource to be played.
content Specifies the format of the media to be played.
delay Specifies a delay interval between announcement repetitions. The delay
is measured in milliseconds.
duration Specifies the maximum duration of the announcement. The duration is
measured in milliseconds. The announcement will be stopped when the
maximum duration is reached.
repeat Specifies how many times the media server should repeat the
announcement.
locale Specifies the language and country variant. A default locale is used
when a corresponding language variant is unavailable.
variable Specifies a mechanism for transmitting play parameters. A maximum of
9 parameters are available ranging from param1 to param9.
extension Specifies a mechanism fro extending the parameter set.

Example of ANNC Indicator

Example 1: The file to be played is "http://audio.example.net/allcircuitsbusy.g711".
sip:[email protected]; play=http://audio.example.net/allcircuitsbusy.g711
Example 2: The file to be played is "file://provisioned/1000_welcome_alaw.wav". Where,
"repeat" is 11, "delay" is 100 milliseconds, and "locale" is English.
sip:[email protected];play=file://provisioned/1000_welcome_alaw.wav;repeat=11;delay
=100;locale=eng
RFC4240-Based Playing Procedure
Figure 1-13 shows the RFC4240-based playing procedure in the case that the Mp interface
supports H.248.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 85

The RFC4240-based playing function is triggered and controlled by the AS. The following message flow
is based on the interworking scenario of messages between the AS and the MRF being exchanged
through the S-CSCF. The message exchange between the AS and the S-CSCF is not shown in this figure.

Figure 1-13 RFC4240-based playing procedure

Creating Playing
The procedure for creating ANNC playing is as follows:
1. The S-CSCF sends an INVITE to the MRFC. The Request-URI in the INVITE carries
the ANNC indicator and play parameters.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 86

2. The MRFC sends an ADD_Request, instructing the MRFP to create a termination for the
playing.
3. After successfully creating a termination, the MRFP sends an ADD_Reply to the MRFC.

The subsequent steps 4 to 10 are optional, which are related to the precondition feature, 100rel feature,
and UPDATE procedure.
4. If the INVITE indicates that the precondition feature and the 100rel feature are required,
the MRFC sends a 183 response to the S-CSCF after receiving the INVITE.
5. The S-CSCF sends a PRACK to the MRFC, acknowledging the receipt of 183.
6. The MRFC sends a 200 PRACK to the S-CSCF.
The AS (for which, messages are transferred by the S-CSCF) and MRFC complete the
resource negotiation and resource reservation through the resource parameters carried in
183 and PRACK.
7. After completing the resource reservation, the AS sends an UPDATE to the MRFC
through the S-CSCF.
8. After receiving the UPDATE, the MRFC sends a MOD_Request to the MRFP,
requesting resource modification.
9. After completing the resource modification, the MRFP sends a MOD_Reply to the
MRFC.
10. After receiving the MOD_Reply, the MRFC sends a 200 UPDATE to the AS, indicating
the completion of the resource reservation.
11. The MRFC sends a 200 to the S-CSCF in response to the INVITE.
12. The S-CSCF sends an ACK to the MRFC. Then, the session is set up successfully.
13. The MRFC sends a MOD_Request to the MRFP, instructing the MRFP to start playing.
14. After the MRFP starts playing, the MRFP returns a MOD_Reply to the MRFC.
Stopping Playing
After the playing is completed, the procedure for releasing the session is as follows:
1. The MRFP sends a NOTIFY_Request to inform the MRFC of the completion of the
playing.
2. The MRFC sends a BYE to the S-CSCF, indicating release of the session.
3. The MRFC sends a NOTIFY_Reply to the MRFP.
4. The S-CSCF returns a 200 BYE to the MRFC.
5. The MRFC returns a MOD_Request to the MRFP, informing the MRFP about stopping
the playing.
6. The MRFP returns a MOD_Reply to the MRFC.
7. The MRFC releases its resources and sends a SUB_Request, instructing the MRFP to
release resources.
8. After the MRFP releases resources, the MRFP returns a SUB_Reply to the MRFC.

Enhancement
Table 1-18 lists the release history of the RFC4240-based Playing feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 87

Table 1-18 Release history of the RFC4240-based Playing feature

History Version Details Release Plan

Initial release V100R001 - -

1.4.3 SWP-CSCF-MSR-013202 MSML-Based Playing

Availability
Table 1-19 describes the requirements for implementing the SML-based Playing feature.

Table 1-19 Requirements for implementing the SML-based Playing feature

Required NEs Required Version License Support

MRFC V100R001 or later A license is required for the
implementation of this
feature.
MRFP V100R001 or later A license is required for the
implementation of this
feature.
AS V100R001C02 or later A license is required for the
implementation of this
feature.

Summary
The playing function based on the media server markup language (MSML) refers to the
multimedia playing function that is implemented according to the MSML playing script
carried in the INFO message. This function is performed on the Mr interface (the interface
between the S-CSCF and the MRFC) on the basis of the MSML standard.

Benefits
Table 1-20 describes the benefits of the MSML-Based Playing feature.

Table 1-20 Benefits of the MSML-Based Playing feature

Beneficiary Description
Carriers The MSML-based playing function can be extended
to multiple applications and can be controlled
flexibly. Carriers can gain economic benefits from
the provisioning of these services.
Subscribers The MSML-based playing function can be extended
to multiple applications and can be controlled
flexibly. Subscribers can enjoy rich multimedia

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 88

Beneficiary Description
services.

Description
Introduction to MSML
MSML defines the processing for the interaction between multimedia sessions on the media
server. It is a standard drafted by the Internet Engineering Task Force (IETF). The MSML
script supported by the CSC3300 complies with the standard MSML version:
MOML1_0Ref_95-0089-00-04[1], MSML1_1Ref_95-0088-00-05[1], and
draft-saleem-msml-02.
The MSML script uses a makeup language based on the XML. It uses SIP to set up sessions
and transport loads.
MSML Structure
MSML consists of MSML core package and MSML additional package. The MSML core
package provides the MSML framework only, without involving any services or features. The
MSML additional packages consist of dialog package, conference package, and audit package.
The dialog package and audit package can be extended to multiple application packages.
Figure 1-14 shows the MSML structure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 89

Figure 1-14 MSML structure

Introduction to Dialog Package

Dialog Core Package
The dialog core package defines the framework of sessions and the basic elements. The dialog
core package contains the following elements:
<dialogstart>: defines the basic attributes of a media dialog, such as destination, source,
and conference name.
<dialogend>: terminates an MSML dialog before the dialog completes of its own accord.
<send>: sends an event.
<exit>: terminates the execution of the MSML dialog.
<disconnect>: breaks the connection with the media server.
Dialog Base Package

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 90

The dialog base package is an extension of the dialog core package. It is used to define a
required set of basic functions for the media server. These functional elements consist of the
following:
<play>: generates an audio or video stream.
<dtmfgen>: The DTMF generator originates one or more DTMF digits in sequence.
<tonegen>: The tone generator allows customized tone generation.
<record>: records files.
<dtmf> and <collect>: <dtmf> is the same as <collect>, used to collect DTMF digits and
trigger the required processing based on the received DTMF digits.
Playing Description
The attributes, events, and child elements of the <play>
Media type
Address of the media file to be played
Language to be played
Interval of repeated playing
Number of times for repeated playing
Whether the audio playing process can be disrupted by the DTMF collection
Through the descriptions of <play>, the playing can be fulfilled in the following manner:
The multimedia file with the specified address can be played.
The playing can be stopped and restarted.
The voices with meanings (such as date and number) can be combined dynamically and
played.
Example of MSML-Based Playing Script
Example
Line 1:<?xml version="1.0" encoding="UTF-8"?>
Line 2:<msml version="1.1">
Line 3:<dialogstart target="conn:12345" name="12345">
Line 4:<play>
Line 5:<audio uri="file://clip1.wav"/>
Line 6:<audio uri="http://host1/clip2.wav"/>
Line 7:<var type="date" subtype="mdy" value="20030601"/>
Line 8:</play>
Line 9:<send target="source" event="done" namelist="play.amt play.end"/>
Line 10:</dialogstart>
Line 11: </msml>
Explanation
Line 1: The MSML script is based on XML. The XML version is 1.0, and the encoding format
of the XML file is UTF-8.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 91

Line 2: The version of the MSML script is 1.1.

Line 3: Dialog script starts, with the target "conn:12345" and name "12345".
Line 4: The playing script starts.
Line 5: Audio playing with url as file://clip1.wav.
Line 6: Audio playing with url as http://host1/clip2.wav.
Line 7: The playing time is 2003-06-01.
Line 8: The playing script ends.
Line 9: Report the results of playing by sending events to the initiator of playing.
Line 10: The dialog script ends.
Line 11: The MSML script ends.
MSML-Based Playing Procedure
Figure 1-15 shows the MSML-based playing procedure in the case that the Mp interface
supports H.248.

The MSML-based playing function is triggered and controlled by the AS. The following message flow is
based on the interworking scenario of messages between the AS and the MRF being exchanged through
the S-CSCF. The message exchange between the AS and the S-CSCF is not shown in this figure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 92

Figure 1-15 MSML-based playing procedure

Creating Playing
The procedure for creating MSML-based playing is as follows:
1. The S-CSCF sends an INVITE to the MRFC. The user part in the Request-URI in the
INVITE is MSML.
2. The MRFC changes the INVITE to an H.248 message, ADD_Request, and sends it to
the MRFP, instructing the MRFP to create a termination.
3. After successfully setting up the termination, the MRFP sends an ADD_Reply to the
MRFC.
4. The MRFC sends a 200 to the S-CSCF in response to the INVITE.
5. The S-CSCF sends an ACK to the MRFC. Thus, the playing session is set up
successfully.

The MSML-based playing procedure supports the optional precondition feature, 100rel feature, and
UPDATE procedure, which are omitted in the diagram. For details about the playing procedure, see
RFC4240-based playing procedure.

Starting Playing

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 93

The procedure for starting playing is as follows:

1. The S-CSCF sends an INFO. The message body carries the MSML media play indicator
and play parameters, instructing the MRFC to start playing. An example of the format of
the MSML script in the INFO is given below:
INFO sip:9.9.1.9:5060;Dpt=756a-100;TRC=401-ffffffff SIP/2.0
Via: SIP/2.0/UDP 9.9.3.54:5060;branch=z9hG4bKb8085ea6168617e3003a689d07744189
...
Content-Length: 193
Content-Type:application/msml+xml

<?xml version="1.0"?>
<msml version="1.1">
...
</msml>
2. When the MRFC resolves the MSML script, it changes the play indicator to a
MOD_Request and sends this message to the MRFP.
3. After the MRFC succeeds in resolving the MSML script, it sends a 200 INFO to the
S-CSCF.
4. The MRFP starts playing by utilizing necessary resources and sends a MOD_Reply to
the MRFC.
The INFO procedure can be repeated several times before the session is released. Through the
MSML script carried in the INFO, the playing can be controlled, such as starting and stopping
playing.
Stopping Playing
When the playing is terminated, the procedure for releasing the session is as follows:
1. The MRFP sends a NOTIFY_Request, informing the MRFC about the completion of the
playing. The message carries the results of playing.
2. The MRFC returns a NOTIFY_Reply to the MRFP.
3. The MRFC encodes the results into an MSML script, which is then encapsulated in the
INFO and sent to the S-CSCF.
4. The MRFC sends a MOD_Request to the MRFP, instructing the MRFP to stop playing.
5. The S-CSCF returns a 200 INFO to the MRFC.
6. The MRFP returns a MOD_Reply to the MRFC.
7. The S-CSCF sends a BYE to the MRFC, indicating release of the session.
8. The MRFC sends a SUB_Request to the MRFP, requesting the MRFP to release
resources.
9. After releasing resources, the MRFC returns a 200 BYE to the S-CSCF.
10. After the MRFP releases resources, it returns a SUB_Reply to the MRFC.

Enhancement
Table 1-21 lists the release history of the MSML-based Playing feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 94

Table 1-21 Release history of the MSML-based Playing feature

History Version Details Release Plan

Initial release V100R001 - -

Dependency
This feature does not have any interaction with other features.

1.4.4 SWP-CSCF-MSR-013203 RFC4240-Based IVR

Availability
Table 1-22 describes the requirements for implementing the RFC4240-based IVR function.

Table 1-22 Requirements for implementing the RFC4240-based IVR function

Required NEs Required Version License Support

MRFC V100R001 or later A license is required for the
implementation of the SIP
Signaling Compression
feature.
MRFP V100R001 or later A license is required for the
implementation of this
feature.
AS V100R001C02 or later A license is required for the
implementation of this
feature.

Summary
The RFC4240-based interactive voice response (IVR) function is based on the RFC4240
standard and realized on the Mr interface. It is implemented through the DIALOG indicator
carried in the Request-URI in the INVITE message.
The IVR function is described in the voice extensible markup language (VXML) script.
VXML scripts are stored in the AS (HTTP server). The DIALOG indicator in the INVITE
message indicates only the address of the AS where the to-be-executed VXML script is stored.
Therefore, to obtain the designated VXML script, the MRFC is required to support the Sr
interface (namely, the interface between the MRFC and the AS, which supports the HTTP
protocol).

Benefits
Table 1-23 describes the benefits of the RFC4240-Based IVR feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 95

Table 1-23 Benefits of the RFC4240-Based IVR feature

Beneficiary Description
Carriers The RFC4240-based IVR function can be extended
to various applications. Carriers can gain economic
benefits from the provisioning of these services.
Subscribers The RFC4240-based IVR function can be extended
to various applications. Subscribers can enjoy rich
multimedia services.

Description
Introduction to DIALOG Indicator
The RFC4240-based IVR function is implemented through the DIALOG indicator carried in
the INVITE message. This following introduces the specifications for the DIALOG indicator.

For details on the DIALOG indicator, refer to the RFC4240 protocol.

Specification for DIALOG Indicator

In RFC4240, the specification for the CONF indicator is as follows:
DIALOG-URL = sip-ind dialog-ind "@" hostport dialog-parameters
Where:
sip-ind= "sip:" / "sips:"
dialog -ind= "dialog"
dialog-parameters = ";" dialog-param [vxml-parameters] [uri-parameters]
Description of DIALOG Parameters
Table 1-24 describes the parameters in the DIALOG indicator.

Table 1-24 Description of DIALOG parameters

Parameter Description
dialog Contains vxml-url to specify the location of the VXML script to be
executed.
vxml Specifies the value of VXML keyword. Each keyword must be
assigned a value. Otherwise, an error code is returned.
uri Specifies the value of SIP Request-URI.

Example of DIALOG Indicator

For example, for a dialog, the VXML script to be executed is
http://vxmlserver.example.net/cgi-bin/script.vxml.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 96

sip:[email protected];voicexml=http://vxmlserver.example.net/cgi-bin/script.v
xml
Introduction to DIALOG Indicator
The RFC4240-based IVR function uses the voice extensible markup language (VXML) to
describe the IVR procedure.
VXML is a telephony voice application specification developed by the World Wide Web
Consortium (W3C) in 2000 on the basis of XML.
VXML has become an interface standard widely used in the communications industry. Since
VXML uses a structure similar to the hyper text markup language (HTML), it is also called
voice browser standard. Because of its Web-based development mode, VXML is used to
support IVR applications. It provides functions such as user interaction and voice recognition
for voice synthesis, audio recording prompt, and DTMF input. VXML files are usually
transferred through HTTP, but VXML is independent of the transport layer.

The VXML standard that CSC3300 V100R001 complies with is Voice Extensible Markup Language
(VoiceXML) Version 2.0.

RFC4240-Based IVR Procedure

Figure 1-16 shows the RFC4240-based IVR procedure.

The RFC4240-based IVR function is triggered and controlled by the AS. The following message flow is
based on the interworking scenario of messages between the AS and the MRF being exchanged through
the S-CSCF. The message exchange between the AS and the S-CSCF is not shown in this figure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 97

Figure 1-16 RFC4240-based IVR procedure

Creating IVR
The procedure for creating RFC4240-based IVR is as follows:
1. The S-CSCF sends an INVITE to the MRFC. The Request-URI in the INVITE carries
the DIALOG indicator.
2. The MRFC sends an ADD_Request to the MRFP, instructing the MRFP to create a
termination.
3. The MRFC sends an http_request to the AS to obtain the VXML script in the DIALOG
indicator.
4. After successfully setting up the termination, the MRFP sends an ADD_Reply to the
MRFC.
5. After receiving the request, the AS encapsulates the script into the http_response and
sends the message to the MRFC.

The procedure for obtaining the VXML script must be completed before the S-CSCF returns a 200
INVITE.
6. The MRFC sends a 200 to the S-CSCF in response to the INVITE.
7. The S-CSCF sends an ACK to the MRFC. Thus, the session is set up successfully.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 98

The RFC4240-based IVR procedure supports the optional precondition feature, 100rel feature, and
UPDATE procedure, which are omitted in the figure. For details about the procedure, see
RFC4240-based playing procedure.

Starting IVR
The MRFC resolves the VXML script, breaking down complicated operations into primitive
and basic operations. The MRFP performs these basic operations to complete announcement,
recording, and DTMF collection in sequence. The announcement procedure and recording
procedure are the same as the DTMF collection procedure. Here, only the DTMF collection
procedure is described as follows:
1. The MRFC sends a MOD_request, instructing the MRFP to start DTMF collection.
2. After the MRFP starts DTMF collection, it returns a MOD_Reply to the MRFC.
3. After the DTMF collection is completed, the MRFP sends a NOTIFY_Request to the
MRFC.
4. After the MRFC receives notification for the completion of DTMF collection, it sends a
NOTIFY_Reply to the MRFP.
5. The MRFC sends a MOD_request, instructing the MRFP to stop DTMF collection.
6. After the MRFP stops DTMF collection, it returns a MOD_Reply to the MRFC.
Stopping IVR
After the IVR interaction is completed, the procedure for releasing the session is as follows:
1. The MRFC sends a BYE to the S-CSCF, indicating release of the session.
2. The MRFC sends a SUB_Request to the MRFP, requesting the MRFP to release
resources. In the meantime, the MRFC releases its resources allocated to the session.
3. The S-CSCF returns a 200 BYE to the MRFC.
4. After the MRFP releases resources, it returns a SUB_Reply to the MRFC.

Enhancement
Table 1-25 lists the release history of the RFC4240-based IVR feature.

Table 1-25 Release history of the RFC4240-based IVR feature

History Version Details Release Plan

Initial release V100R001 - -

Dependency
This feature does not have any interaction with other features.

1.4.5 SWP-CSCF-MSR-013204 MSML-Based DTMF Collection

Availability
Table 1-26 describes the requirements for implementing the MSML-based DTMF Collection
function.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 99

Table 1-26 Requirements for implementing the MSML-based DTMF Collection function

Required NEs Required Version License Support

MRFC V100R001 or later This feature does not require
license support.
AS V100R001C02 or later A license is required for the
implementation of this
feature.
MRFP V100R001 or later This feature does not require
license support.

Summary
The MSML-based DTMF collection function is based on the MSML standard and realized on
the Mr interface (the interface between the MRFC and the S-CSCF). It is implemented by
using the MSML-based DTMF collection indication script carried in the INFO message.
The CSC3300 supports two number collection modes: DTMF and 2833.

Benefits
Table 1-27 describes the benefits of the MSML-Based DTMF Collection feature.

Table 1-27 Benefits of the MSML-Based DTMF Collection feature

Beneficiary Description
Carriers The MSML-based DTMF collection function can be
extended to various applications. Carriers can gain
economic benefits from the provisioning of these
services.
Subscribers The MSML-based DTMF collection function can be
extended to various applications. Subscribers can
enjoy rich multimedia services.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 100

MSML consists of MSML core package and MSML additional package. The MSML core
package provides the MSML framework only, without involving any services or features. The
MSML additional packages consist of dialog package, conference package, and audit package.
The dialog package and audit package can be extended to multiple application packages.
Figure 1-17 shows the MSML structure.

Figure 1-17 MSML structure

Introduction to Dialog Package

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 101

<exit>: terminates the execution of the MSML dialog.

<disconnect>: breaks the connection with the media server.
Dialog Base Package
The dialog base package is an extension of the dialog core package. It is used to define a
required set of basic functions for the media server. These functional elements consist of the
following:
<play>: generates an audio or video stream.
<dtmfgen>: The DTMF generator originates one or more DTMF digits in sequence.
<tonegen>: The tone generator allows customized tone generation.
<record>: records files.
<dtmf> and <collect>: <dtmf> is the same as <collect>, used to collect DTMF digits and
trigger the required processing based on the received DTMF digits.
Description of DTMF Collection
DTMF Attribute
The attributes, events, variables, and child elements of the <collect> element can specify the
following DTMF attributes:
Whether the contents in the digit buffer are cleared before the digits are collected.
First-digit timer value. The first-digit timer is started when the DTMF detection is
invoked.
Inter-digit timer value. The inter-digit timer is started when the previous digit is
collected.
Operation to be performed after the first DTMF digit is collected.
DTMF digit pattern that must be matched, such as XXXXX#.
Operations to be performed for matching digits, mismatching digits, or no digits
collected.
DTMF Collection Mode
Through the descriptions of <collect>, the DTMF collection can be fulfilled in the following
mode:
Start DTMF detection timer for digit collection after a prompt is played.
Immediately stop playing a prompt after DTMF digits are collected.
Start the inter-digit timer each time after a DTMF digit is collected, avoiding an
indefinite period of waiting.
If the system detects that the timer of the firt DTMF code expires, it indicates that no
digits are collected. Perform the operation as required in this case.
If the collected digits match the specified DTMF digit pattern, perform the operation as
required in this case.
If the collected digits do not match the specified DTMF digit pattern, perform the
operation as required in this case.
Example of MSML-Based DTMF Collection Script
Example
Line 1:<?xml version="1.0" encoding="UTF-8"?>

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 102

Line 2:<msml version="1.1">

Line 3:<dialogstart target=" conn:user1" type=" application/moml+xml" name="Dialog1">
Line 4:<collect fdt="10s" idt="16s">
Line 5:<play barge="true">
Line 6:<audio uri="file://prompt.wav"/>
Line 7:</play>
Line 8:<pattern digits="xxxxxx|x.#">
Line 9:<send target="source" event="done" namelist="dtmf.digits dtmf.end"/>
Line 10:</pattern>
Line 11:<noinput>
Line 12:<send target="source" event="done" namelist="dtmf.end"/>
Line 13:</noinput>
Line 14:<nomatch>
Line 15:<send target="source" event="done" namelist="dtmf.end"/>
Line 16:</nomatch>
Line 17:</collect>
Line 18:</dialogstart>
Line 19: </msml>
Explanation
Line 1: The MSML script is based on XML. The XML version is 1.0, and the encoding format
of the XML file is UTF-8.
Line 2: The MSML script starts. The MSML version is 1.1.
Line 3: The dialog script starts with the target "conn:user1" and name "Dialog1".
Line 4: The collection script starts with the first-digit timer value set to 10s, and the inter-digit
timer value set to 16s.
Line 5 to line 7: The playing script starts. The file to be played is file://prompt.wav, and the
play procedure can be terminated by DTMF digits.
Line 8 to line 10: The digit pattern is xxxxxx|x.#. If the collected digits match, an event is sent
to the source for result notification.
Line 11 to line 13: If no digits are collected, an event is sent to the source for result
notification.
Line 14 to line 16: If the collected digits do not match, an event is sent to the source for result
notification.
Line 17 to line 19: These three lines indicate the end of collection script, dialog script, and
MSML script respectively.
MSML-Based DTMF Collection Procedure \

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 103

Figure 1-18 shows the MSML-based DTMF collection procedure.

The MSML-based DTMF collection function is triggered and controlled by the AS.The following
message flow is based on the interworking scenario of messages between the AS and the MRF being
exchanged through the S-CSCF. The message exchange between the AS and the S-CSCF is not shown in
this figure.

Figure 1-18 MSML-based DTMF collection procedure

Creating DTMF Collection

The procedure for creating MSML-based DTMF collection is as follows:
1. The S-CSCF sends an INVITE to the MRFC. The user part in the Request-URI in the
INVITE is MSML. No special indicators are carried, such as ANNC indicator, CONF
indicator, DIALOG indicator, or TC indicator.
2. The MRFC changes the INVITE to an H.248 message, ADD_Request, and sends it to
the MRFP, instructing the MRFP to create a termination.
3. After successfully setting up the termination, the MRFP sends an ADD_Reply to the
MRFC.
4. The MRFC sends a 200 to the S-CSCF in response to the INVITE.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 104

5. The S-CSCF sends an ACK to the MRFC. Thus, the DTMF collection session is set up
successfully.

The MSML-based DTMF collection procedure supports the optional precondition feature, 100rel feature,
and UPDATE procedure, which are omitted in the figure. For details about the procedure, see
RFC4240-based playing procedure.

Starting DTMF Collection

The procedure for starting DTMF collection is as follows:
1. The S-CSCF sends an INFO to the MRFC, which carries the MSML script to indicate
the start of DTMF collection.
2. The MRFC sends a MOD_Request to the MRFP, indicating the start of DTMF
collection.
3. After receiving the message, the MRFC resolves the MSML script, and sends a 200
INFO to the S-CSCF.
The MSML script carried in the INFO can indicate mixed operations for DTMF
collection and playing or DTMF collection and recording to implement the IVR function.
The playing procedure and recording procedure are the same as the DTMF collection
procedure. The following steps 4-10 describe only the DTMF collection procedure.
4. After the MRFP starts DTMF collection, it returns a MOD_Reply to the MRFC.
5. After the DTMF collection is completed, the MRFP sends a NOTIFY_Request to the
MRFC.
6. The MRFC returns a NOTIFY_Reply to the MRFP.
7. The MRFC encodes the DTMF collection result into an MSML script, which is then
encapsulated in the INFO and sent to the S-CSCF.
8. The MRFC sends a MOD_Request to the MRFP to indicate the termination of DTMF
collection.
9. The S-CSCF sends a 200 INFO to the MRFC.
10. The MRFP returns a MOD_Reply to the MRFC.
Stopping DTMF Collection
When the DTMF collection is terminated, the procedure for releasing the session is as
follows:
1. The S-CSCF sends a BYE to the MRFC, indicating release of the session.
2. The MRFC sends a SUB_Request to the MRFP, requesting the MRFP to release
resources. In the meantime, the MRFC releases its resources allocated to the session.
3. After releasing resources, the MRFC sends a 200 BYE to the S-CSCF.
4. After the MRFP releases resources, it returns a SUB_Reply to the MRFC.

Enhancement
Table 1-28 lists the release history of the MSML-Based DTMF Collection feature.

Table 1-28 Release history of the MSML-Based DTMF Collection feature

History Version Details Release Plan

Initial release V100R001 - -

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 105

Dependency
This feature does not have any interaction with other features.

1.4.6 SWP-CSCF-MSR-013205 MSML-Based Recording

Availability
Table 1-29 describes the requirements for implementing the MSML-based Recording feature.

Table 1-29 Requirements for implementing the MSML-based Recording feature

Required NEs Required Version License Support

MRFC V100R001 or later This feature requires license
support.
MRFP V100R001 or later A license is required for the
implementation of this
feature.
AS V100R001C02 or later A license is required for the
implementation of this
feature.

Summary
The MSML-based recording function is based on the MSML standard and realized on the Mr
interface. It is implemented on the basis of the MSML recording script carried in the INFO
message.
The MSML-based recording function supports audio recording and video recording.

Benefits
Table 1-30 describes the benefits of the MSML-Based Recording feature.

Table 1-30 Benefits of the MSML-Based Recording feature

Beneficiary Description
Carriers The MSML-based recording function can be
extended to multiple varied applications and can be
controlled flexibly. Carriers can gain economic
benefits from the provisioning of these services.
Subscribers The MSML-based recording function can be
extended to multiple varied applications and can be
controlled flexibly. Subscribers can enjoy rich
multimedia services.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 106

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 107

Figure 1-19 MSML structure

Introduction to Dialog Package

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 108

The dialog base package is an extension of the dialog core package. It is used to define a
required set of basic functions for the media server. These functional elements consist of the
following:
<play>: generates an audio or video stream.
<dtmfgen>: The DTMF generator originates one or more DTMF digits in sequence.
<tonegen>: The tone generator allows customized tone generation.
<record>: records files.
<dtmf> and <collect>: <dtmf> is the same as <collect>, used to collect DTMF digits and
trigger the required processing based on the received DTMF digits.
Description of Recording
To implement the recording function, MSML uses <record> to describe the operations and
attributes relating to the recording.
Recording Attribute
The attributes, events, and child elements of the <record> element can specify the following
attributes for recording:
Target address of a specified recording file
Coding type and file type of a specified recording file
Maximum time of recording
Whether the recording file can be used as an attachment of an existing file
A single DTMF code used to end recording
Recording Mode
Through the descriptions of <record>, the recording can be fulfilled in the following modes:
A prompt is played before the recording starts. The prompt can be terminated by a
DTMF code.
After the recording ends, the recorded file can be deleted.
Example of MSML-Based Recording Script
Example
Line 1: <?xml version="1.0" encoding="UTF-8"?>
Line 2: <msml version="1.1">
Line 3: <dialogstart target="conn:12345" name="12345">
Line 4: <play cvd:barge="false" cvd:cleardb="false">
Line 5: <audio uri="file://provisioned/audio/hello.wav"/>
Line 6: </play>
Line 7: <record dest="http://10.0.0.202/upload/conf1.wav" format="video/wav"
maxtime="5000s">
Line 8: <recordexit>
Line 9: <exit target="source" event="app.recordDone" namelist="record.end record.len"/>
Line 10: </recordexit>

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 109

Line 11: </record>

Line 12: </dialogstart>
Line 13: </msml>
Explanation
Line 1: The MSML is based on XML. The version of XML is 1.0. The coding format of an
XML file is UTF-8.
Line 2: The MSML script starts. The version of the MSML script is 1.1.
Line 3: The dialog script starts, with dialog connection "conn:12345" and dialog name
"12345".
Lines 4 to 6: The prompt is played and cannot be terminated by the DTMF code. The buffer of
the DTMF code need not be cleared. The address of the audio file to be played is
file://provisioned/audio/hello.wav.
Line 7: The recording starts. The recorded file is stored in
http://10.0.0.202/upload/conf1.wav. The recording format can be video or wav. The
maximum recording duration is 5,000 seconds.
Lines 8 to 10: Send an event to the recording originator and report the recording results.
Lines 11 to 13: These three lines indicate that the recording script ends, the dialog script end,
and the MSML script ends respectively.
MSML-Based Recording Procedure
Figure 1-20 shows the MSML-based recording procedure in the case that the Mp interface
supports H.248.

The MSML-based recording function is triggered and controlled by the AS. The following message flow
is based on the interworking scenario of messages between the AS and the MRF being exchanged
through the S-CSCF. The message exchange between the AS and the S-CSCF is not shown in this figure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 110

Figure 1-20 MSML-based recording procedure

Establishing Recording
The procedure for creating MSML-based recording is as follows:
1. The S-CSCF sends an INVITE to the MRFC. The user part in the Request-URI in the
INVITE is MSML. No special indicators are carried, such as ANNC indicator, CONF
indicator, DIALOG indicator, or TC indicator.
2. The MRFC changes the INVITE to an H.248 message, ADD_Request, and sends it to
the MRFP, instructing the MRFP to create a termination.
3. After successfully setting up the termination, the MRFP sends an ADD_Reply to the
MRFC.
4. The MRFC sends a 200 INVITE to the S-CSCF in response to the INVITE.
5. The S-CSCF sends an ACK to the MRFC. Hence, the recording session is set up
successfully.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 111

The MSML-based recording procedure supports the optional precondition feature, 100rel feature, and
UPDATE procedure, which are not covered in the figure. For details about the procedure, see
RFC4240-based playing procedure.

Starting Recording
The procedure for starting recording is as follows:
1. The S-CSCF sends an INFO. The message body carries the MSML multimedia
recording indicator and recording parameters, instructing the MRFC to start recording.
2. The MRFC changes the recording indicator to a MOD_Request and sends the message to
the MRFP.
3. After the MRFC successfully resolves the MSML script, it sends a 200 INFO to the
S-CSCF.
4. The MRFP starts recording and returns a MOD_Reply to the MRFC.
The INFO procedure can be repeated several times before the session is released. Through the
MSML script carried in the INFO, the recording can be controlled, such as playing prompts.
Stopping Recording
When the recording is terminated, the procedure for releasing the session is as follows:
1. When the recording is completed, the MRFP sends a NOTIFY_Request that carries the
recording results to the MRFC, indicating that the recording is completed.
2. The MRFC returns a NOTIFY_Reply to the MRFP.
3. The MRFC sends a MOD_Request to instruct the MRFP to terminate the recording.
4. The MRFC encodes the results into an MSML script, which is then encapsulated in an
INFO and sent to the S-CSCF.
5. The MRFP returns a MOD_Reply to the MRFC.
6. The S-CSCF sends a 200 INFO to the MRFC.
7. The S-CSCF sends a BYE to the MRFC, indicating the release of the session.
8. The MRFC sends a SUB_Request to the MRFP, instructing the MRFP to release
resources. In the meantime, the MRFC releases its resources allocated to the session.
9. The MRFC returns a 200 BYE to the S-CSCF.
10. After the MRFP releases resources, it returns a SUB_Reply to the MRFC.

Enhancement
Table 1-31 lists the release history of the MSML-Based Recording feature.

Table 1-31 Release history of the MSML-Based Recording feature

History Version Details Release Plan

Initial release V100R001 - -

Dependency
This feature does not have any interaction with other features.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 112

2 Optional Features

About This Chapter

2.1 MI2SPCSCSP00 P-CSCF Session Processing
2.2 MI2SSBERSP00 S/B/E-CSCF Session Processing
2.3 MI2SICSCSP00 I-CSCF Session Processing
2.4 MI2SIBCFSP00 IBCF Session Processing
2.5 MI7S00ACCC00 Audio Conference Channels Supported by the MRFC
2.6 MI7SSDVCCC00 Video Conference Channels Supported by the MRFC
2.7 MI7S00ATCC00 MRFC Audio transcoding Channels
2.8 MI7SHDVCCC00 High Definition Video Conference Channels Supported by the
MRFC
2.9 MI2S00TVCC00 Telepresence Conference Channels Supported by the MRFC
2.10 SWP-CSCF-PMS-022300 CSC3300 P-CSCF Message Processing
2.11 SWP-CSCF-SMS-022400 CSC3300 S-CSCF Message Processing
2.12 SWP-CSCF-PPS-022500 CSC3300 P-CSCF Presence Processing
2.13 SWP-CSCF-SPS-022600 CSC3300 S-CSCF Presence Processing
2.14 SWP-CSCF-PC-Rx-022700 Policy Control Support(Rx)
2.15 SWP-CSCF-PC-Gq-022800 Policy Control Support(Gq')
2.16 SWP-CSCF-PC-MM-022900_Policy Control Support (Cable)
2.17 MI2S000NAT00 NAT Traversal
2.18 SWP-CSCF-MCH248-023100 Media Control(H.248) Supported by Boarder Gateway
2.19 MI2S00PASA00 Enhanced Authentication
2.20 SWP-CSCF-HLR-023700 Call Restriction to Hotline Numbers
The CSC3300 supports the Call Restriction to Hotline Numbers feature.
2.21 SWP-CSCF-SigFilter-023800 Filtering of SIP Signaling

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 113

2.22 SWP-CSCF-IPv4&IPv6-023900 Interworking Between IPv4 and IPv6 Networks

2.23 SWP-CSCF-FORK-024100 Forking
2.24 SWP-CSCF-SigCom-024200 SIP Signaling Compression
2.25 SWP-CSCF-InterDNS-024300 Intra-DNS server function
2.26 SWP-CSCF-InterENUM-024400 Intra-Enum server function(S-CSCF)
2.27 SWP-CSCF-OCG-024500 Online Charging
2.28 SWP-CSCF-NP-024700 Number Portability(Number Portability)
2.29 SWP-CSCF-GR-024800 Geographical Redundancy
2.30 SWP-CSCF-MT-024900 Media Transcoding Control
2.31 SWP-IBCF-MT-024900_Trunk-based Call Restriction

2.1 MI2SPCSCSP00 P-CSCF Session Processing

2.1.1 SWP-CSCF-PSP-020100 P-CSCF Session Processing
Availability
This feature is introduced in CSC3300 V100R002.

Summary
When serving as a P-CSCF, the CSC3300 supports all the basic session processing functions,
including session establishment, renegotiation, and release.

Benefits
For subscribers
Subscribers from different access networks can access the IMS network through the
P-CSCF. The P-CSCF provides flexible and reliable security and QoS control for the
sessions of the subscribers.
For carriers
The P-CSCF supports various access modes, including GPRS, DOCSIS, xDSL, WiMAX,
and 3GPP2 and shields the complexity of access for the IMS.
Serving as the first contact point to the IMS network, the P-CSCF provides universal
security and QoS control for the carriers.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 114

Description

Figure 2-1 Basic procedures of session establishment, renegotiation, and release (3GPP R7)

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 115

Figure 2-2 Basic procedures of session establishment, renegotiation, and release (TISPAN R2)

1. The P-CSCF supports the establishment, renegotiation, and release of sessions according to
the specifications of 3GPP or TISPAN.
Initial session establishment
The P-CSCF can start a session establishment procedure when receiving an initial
INVITE request.
Session renegotiation
The P-CSCF can start a session renegotiation procedure when receiving a reINVITE or
UPDATE request after the session is established.
Session release
The P-CSCF can release a session when receiving a BYE request at the end of a session
or an Oxx (3xx/4xx/5xx/6xx) for INVITE during session establishment.
The P-CSCF can actively release a session by sending a CANCEL or BYE request when
the bearer is abnormal.
2. The P-CSCF supports media negotiation through SDP offer/answer exchanges. The specific
negotiation principle is defined in RFC 3264, RFC 3261, RFC 3262, and RFC 3311

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 116

Figure 2-3 Media negotiation principle

Enhancement
When serving as a P-CSCF, CSC3300 V100R002 and later versions support session
processing.

Dependency
None

2.1.2 SWP-CSCF-PSP-020200 Early Session Supported by the

P-CSCF
Availability
This feature is introduced in CSC3300 V100R005.

Summary
The P-CSCF supports early session (two SDP descriptions: session and early-session) in
application server model.

Benefits
For subscribers
Subscribers can enjoy various early media services such as ringback tone service and
multimedia caller identification service.
For carriers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 117

Carriers can deploy various early media services such as ringback tone service and
multimedia caller identification service.

Description
The P-CSCF supports early session and can establish two separate bearer sessions for the two
SDP descriptions carried in a SIP request. That is, the P-CSCF processes the bearer for a
regular session and an early session separately, and requests the bearer device to establish two
bearer sessions.
The P-CSCF recognizes early session, obtains the session SDP and early-session SDP
from the SIP request, and then performs the offer/answer negotiation.
The P-CSCF sends two bearer control requests to the bearer device to establish two
bearer sessions for the regular session and early session separately, to implement NAT
and QoS control.

Figure 2-4 Basic early session procedure supported by the P-CSCF (3GPP R7)

UE PCEF PCRF P-CSCF S-CSCF

INVITE INVITE
(offer) (offer)
AAR INVITE 1xx
RAR (session) (answer/early-offer)
(session)
RAA
AAA
INVITE 1xx
(answer/early-offer)
PRACK
(early-answer)
AAR
RAR (early-session)
(early-session)
RAA
AAA
PRACK
(early-answer)
PRACK 200
PRACK 200
INVITE 2xx
AAR
RAR
(session:open gate) (session:open gate)
RAA
AAA
STR
RAR (early-session)
(early-session)
RAA
STA
INVITE 2xx
ACK
ACK

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 118

Figure 2-5 Basic early session procedure supported by the P-CSCF (TISPAN R2)

Enhancement
When serving as a P-CSCF, CSC3300 V100R005 and later versions support early session.

Dependency
None

2.1.3 SWP-CSCF-PSP-020300 Emergency Call Supported by the

P-CSCF
Availability
This feature is introduced in CSC3300 V100R006.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 119

Summary
The number 911 is the emergency call number used in America and E911 is short for
enhanced 911. The E911 service is applicable to voice communications. It enables a
subscriber to connect to the nearby public safety answering point (PSAP) based on the caller
location by dialing the emergency call number.
The E911 emergency call feature is applicable to North America and complies with the North
America standard Interim VoIP Architecture for E911 Services. With this feature, the
emergency CSCF (E-CSCF) queries the query-LRF (location retrieval function) for
connecting to the PSAP or emergency center (EC) and locating the subscriber precisely.

Benefits
For subscribers
This feature enables subscribers to make E911 emergency calls successfully in the case
of emergency. Subscribers with delinquent accounts or not registered also can make
successful E911 emergency calls.
For carriers
This feature is mandatory for entering the North American market.

Description
On the P-CSCF, the processing of the E911 service is similar to that of the general emergency
call service.
The P-CSCF checks the local configuration to determine whether the current call is an
emergency call. If it is an emergency call, the P-CSCF forwards the call to the
Emergency-CSCF (E-CSCF).
Recognition of emergency calls
From mobile subscribers
The P-CSCF uses the Request-URI and P-Access-Network-Info header fields carried in
the request to query the PEMC (Emergency Call Number of P-CSCF) table to determine
whether the call is an emergency call.
From fixed-line subscribers
The P-CSCF uses the Request-URI header field carried in the request to query the
PGEMC (General Emergency Call Number of P-CSCF) table to determine whether the
call is an emergency call.
No flow control for emergency calls
After recognizing an emergency call, the P-CSCF accepts the call and transfers it to the
E-CSCF even when the system is overloaded.
Retrieving the E-CSCF address
For a registered subscriber of the local domain
The P-CSCF selects the S-CSCF through which the subscriber is registered or the
E-CSCF configured for the access network of the subscriber.
For a registered subscriber of another domain
The P-CSCF selects the E-CSCF configured for the access network of the subscriber.
For an unregistered subscriber
The P-CSCF selects the E-CSCF configured for the access network of the subscriber.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 120

Load balancing and incremental routing of the E-CSCF

The P-CSCF selects the E-CSCFs based on the priority and weight returned by the DNS
server. If several E-CSCFs are of the same priority and weight, the P-CSCF selects them in
turn.
If the selected E-CSCF does not respond or responds with an error, the P-CSCF tries other
E-CSCFs until the emergency call is connected.
Retrieving subscriber location information
The P-CSCF queries the CLF for the location information of a fixed-line subscriber and adds
the obtained location information to the P-Access-Network-info header field. Based on the
location information, the E-CSCF then selects the nearest EC for the subscriber to ensure
timely rescue.
Resource reservation for emergency calls
The P-CSCF includes the Resource-Priority AVP in the Authentication Authorization Request
(AAR) sent to the PDF (or SPDF or PCRF) for bearer control. The Resource-Priority AVP
indicates the priority of the current call. (The value range is 1-7; the value 0 indicates ordinary
calls). If the available resources are insufficient at present, the PDF attempts to release the
resources of the call with a lower Reservation-Priority and sends an Abort Session Request
(ASR) to instruct the P-CSCF to send BYE messages to both parties of the call. After securing
sufficient resources, the PDF returns an Authentication Authorization Answer (AAA) to the
P-CSCF.
ACRs of emergency calls
The P-CSCF uses an extended AVP to indicate emergency calls in the accounting records.
Emergency call procedure

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 121

The emergency call procedure is as follows:

The UE initiates an emergency call by sending an INVITE request to the P-CSCF.
When receiving the INVITE request, the P-CSCF determines whether to query the CLF
based on the local configuration. If a CLF query is required, the P-CSCF retrieves the
source IP address of the INVITE request.
The P-CSCF queries the CLF for the location information of the subscriber. It sends a
User Data request (UDR) to the CLF, carrying the source IP address of the INVITE
request, Subscriber ID, and P-CSCF_ID.
Based on these parameters, the CLF queries the local database. If a record is matched,
the CLF responds with a User Data Answer (UDA) to the P-CSCF. The response carries
parameters such as the cause value, Subscriber ID (optional), location information
(optional), RACS connection point (optional), access network type (optional), and
terminal type (optional).
The P-CSCF adds the location information of the subscriber to the
P-Access-Network-info header field of the INVITE request. The P-CSCF queries the
PGEMC table to determine that the call is an emergency call and thus adds the Priority:
emergency header field to the request. Then, the P-CSCF selects a local S-CSCF that can
process emergency calls and forwards the call to the S-CSCF.
Based on the location information, the S-CSCF queries the local configuration and
selects a nearest EC to process the call.
The EC processes the call according to the location of the subscriber. The subsequent
processing is the same as that of an ordinary call, and thus is not described here.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 122

Enhancement
None

Dependency
None

2.1.4 SWP-CSCF-PSP-020400 Protocol Interfaces Supported by

the P-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The P-CSCF communicates with IMS UEs and other functional entities through the Gm, Mw,
Rf, Gq, Gq', Rx, and e2 interfaces.

Benefits
For subscribers
Subscribers from different access networks can access the IMS network through the
P-CSCF.
For carriers
The P-CSCF supports various access modes, including GPRS, DOCSIS, xDSL, WiMAX,
and 3GPP2, and provides various protocol interfaces to support rich IMS services.

Description

Figure 2-6 Protocol interfaces supported by the P-CSCF

Gm (SIP): The P-CSCF communicates with the UEs through the Gm interface.
Mw (SIP): The P-CSCF communicates with the I-CSCF/S-CSCF through the Mw
interface.
Rf (Diameter): The P-CSCF transfers accounting records to the CCF through the Rf
interface.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 123

e2 (Diameter): The P-CSCF communicate with the CLF through the e2 interface to
obtain the subscriber location information.
Rx/Gq'/Gq (Diameter): The P-CSCF communicates with the PCRF/SPDF/PDF through
the Rx/Gq'/Gq interface for bearer processing.

Enhancement
The Gm, Mw, Rf, e2, Gq, and Gq' interfaces are supported from CSC3300 V100R002
onwards.
The Rx interface is supported from CSC3300 V100R003 onwards.

Dependency
None

2.1.5 SWP-CSCF-PSP-020600 Gq Interface Between CSCF and

PDF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The CSCF supports the Gq interface. In mobile access mode, the CSCF interacts with the
PDF to control the PEP to implement user plane QoS policy enforcement.

Benefits
For subscribers
The media QoS of subscribers is guaranteed.
For carriers
Carriers can provide mobile subscribers with flexible and reliable QoS control

Description
1. Application scope of the Gq interface
The Gq interface is located between the CSCF (AF) and the PDF for exchanging the
application level session information.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 124

2. Basic Gq-related procedures

The CSC3300 supports the following basic QoS procedures according to 3GPP R5/R6:
QoS resource authorization
The P-CSCF sends an AAR to request authorization of QoS bearer resources during the
initial offer/answer exchange.
When receiving the initial SDP offer (for example, INVITE) addressed to the callee, the
P-CSCF on the terminating side sends an AAR to request an authorization token from the
PDF. When receiving the initial SDP answer (for example, 1xx for INVITE) addressed to
the caller at the originating side, the P-CSCF sends an AAR to request an authorization
token from the PDF and then delivers the token to the UE.
QoS resource reservation
The P-CSCF sends a Re-Auth-Request (RAR) to request the PDF to reserve sufficient
resources for the UE.
After successful reservation, if the media are altered (added, modified, or removed)
during subsequent offer/answer renegotiation, the P-CSCF sends an AAR to update the
bearer QoS policies for the UE.
QoS resource release
The P-CSCF sends an STR to release the bearer resources when receiving a BYE request
at the end of a session or an Oxx (3xx/4xx/5xx/6xx) for INVITE during session
establishment.
When receiving an ASR from the PDF, indicating that all bearers of a session are
abnormal, the P-CSCF sends a CANCEL or BYE message to release the session.
Bearer event reporting
The PDF can send RAR messages to the P-CSCF to report bearer plane events such as
SERVICE_INFORMATION_REQUEST, CHARGING_CORRELATION_EXCHANGE,
INDICATION_OF_LOSS_OF_BEARER,
INDICATION_OF_RECOVERY_OF_BEARER,

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 125

INDICATION_OF_RELEASE_OF_BEARER, and
INDICATION_OF_ESTABLISHMENT_OF_BEARER.
Gate processing
If early media is required, the P-CSCF opens the gate for early media when receiving the
1xx for INVITE. If early media is not required, the P-CSCF opens the gate for user
media when receiving the 2xx for INVITE. Later, the P-CSCF updates the gate status in
accordance with the updates in media.
3. Forking over the Gq interface
In the case of forking, the P-CSCF delivers the value SEVERAL_DIALOGUES in the AAR
to indicate forking. When forking is complete, the P-CSCF delivers the value
SINGLE_DIALOGUE to instruct the PDF to update the media information based on the
connected forking leg.
4. Many-to-many relationship over the Gq interface
Multiple P-CSCFs can communicate with multiple PDFs through the Gq interface. The
P-CSCF selects the PDFs in turn. When an AAR to one PDF fails, the P-CSCF selects another
PDF.

Enhancement
The Gq interface supported by CSC3300 V100R002 complies with 3GPP 29209-650.
The Gq interface supported by CSC3300 V100R003 complies with 3GPP 29209-670.

Dependency
None

2.2 MI2SSBERSP00 S/B/E-CSCF Session Processing

2.2.1 SWP-CSCF-SSP-020700 Session Establishment Supported
by the S-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
This feature describes the functions of the S-CSCF for establishing sessions.

Benefits
For subscribers
Powerful session control capabilities and service triggering capabilities guarantee the
reliability of services and rich experience for subscribers.
For carriers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 126

The S-CSCF plays a key control role in the IMS core network. It performs registration
authentication of UEs and session control. A powerful S-CSCF with rich session control
and service triggering capabilities provides enhanced control of session establishment for
the carriers.

Description

On the originating side, the S-CSCF provides the following functions for controlling session
establishment:
Call type recognition
The S-CSCF can distinguish emergency calls from ordinary calls.
CPU-based flow control
The S-CSCF can perform flow control based on the overload levels and does not perform
flow control on calls of high priorities (such as emergency calls) even when overloaded.
License control
The S-CSCF controls the number of registered subscribers according to the license.
Caller or callee discrimination
The S-CSCF can identify whether the subscriber it currently serves is a caller or callee.
Trust domain check
The S-CSCF checks whether the call is from a trust domain. If not, the S-CSCF rejects
the call.
Registration status check
The S-CSCF checks the registration data of subscribers, and returns a 403 response to
reject the call from an unregistered subscriber or a subscriber with call barring enabled.
Media capabilities check
Based on the media capabilities registered by the subscriber and the local policies, the
S-CSCF performs a media capabilities check on the request. For a call that requires
unauthorized media types, the S-CSCF determines whether to accept or reject it
according to the local policy.
Session timer/long call processing
The S-CSCF supports session timer and long call audit.
Legal interception
The S-CSCF supports legal interception of calls and generates X2 event reports and X3
media reports.
iFC assessment

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 127

The S-CSCF assesses the iFCs and contacts proper ASs through the ISC interface for
service triggering.
Key header field processing
Before contacting an AS, the S-CSCF processes the key private headers (P-headers). If
the AS to be contacted is in another domain, the S-CSCF deletes the P-Charging-Vector
and P-Charging-Function-Address header fields. If the AS to be contacted is in a distrust
domain, the S-CSCF deletes the P-Access-Network-Info header field.
Outgoing call processing
After all the required ASs are contacted, the S-CSCF performs related analysis to route
the call out.
− For an emergency call, the S-CSCF queries the address of the EC or the gateway to
the EC.
− For an ordinary call, the S-CSCF performs number analysis (including ENUM/NP
queries) and routes the call to the CS domain or the IMS domain.
Key header field processing for outgoing calls
Before routing a call out, the S-CSCF processes the key private headers (P-headers). If
the next-hop network entity is in another domain, the S-CSCF deletes the
P-Charging-Vector and P-Charging-Function-Address header fields. If the next-hop
network entity is in a distrust domain, the S-CSCF deletes the P-Access-Network-Info
header field.
On the terminating side, the S-CSCF provides the following functions for controlling session
establishment:
CPU-based flow control
The S-CSCF can perform flow control based on the overload levels and does not perform
flow control on calls of higher priorities (such as emergency calls) even when
overloaded.
License control
The S-CSCF controls the number of registered subscribers according to the license.
Caller or callee discrimination
The S-CSCF can identify whether the subscriber it currently serves is a caller or callee.
Trust domain check
The S-CSCF checks whether the call is from a trust domain. If not, the S-CSCF rejects
the call.
User profile check
Based on the check of the user profile, the S-CSCF returns a 404 response to reject the
call to an unregistered subscriber or a subscriber with call barring enabled.
Media capabilities check
Based on the media capabilities registered by the subscriber and the local policies, the
S-CSCF performs a media capabilities check on the request. For the calls that require
unauthorized media types, the S-CSCF determines whether to accept or reject the calls
according to the local policy.
Session timer/long call processing
The S-CSCF supports session timer and long call audit.
Legal interception
The S-CSCF supports legal interception of calls and generates X2 event reports and X3
media reports.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 128

iFC assessment
The S-CSCF assesses the iFCs and contacts proper ASs through the ISC interface for
service triggering.
Key header field processing
Before contacting an AS, the S-CSCF processes the key private headers (P-headers). If
the AS to be contacted is in another domain, the S-CSCF deletes the P-Charging-Vector
and P-Charging-Function-Address header fields. If the AS to be contacted is in a distrust
domain, the S-CSCF deletes the P-Access-Network-Info header field.
Call forwarding identification
The S-CSCF checks the INVITE request returned from the AS to determine whether call
forwarding is required.
Outgoing call processing
− If the call is to be forwarded, the S-CSCF performs number analysis and routes the
call to the forwarded-to network.
− If the call need not be forwarded and there is no other AS to be contacted, the
S-CSCF directly routes the call to the terminating P-CSCF.
Key header field processing for outgoing calls
Before routing a call out, the S-CSCF processes the key private headers (P-headers). If
the next-hop network entity is in another domain, the S-CSCF deletes the
P-Charging-Vector and P-Charging-Function-Address header fields. If the next-hop
network entity is in a distrust domain, the S-CSCF deletes the P-Access-Network-Info
header field.

Enhancement
The session control related features of the S-CSCF are under continuous enhancement from
CSC3300 V100R002 onwards. For details, see the description of each specific feature.

Dependency
None

2.2.2 SWP-CSCF-SSP-020800 Media Negotiation Supported by

the S-CSCF
Availability
The S-CSCF performs only a media capabilities check and does not take part in the SDP
offer/answer negotiation during session establishment.

Summary
None

Benefits
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 129

Description
None

Enhancement
None

Dependency
None

2.2.3 SWP-CSCF-SSP-020900 Session Release Supported by the

S-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
When serving as an S-CSCF, the CSC3300 supports call release in various modes.

Benefits
For subscribers
Subscribers can release calls normally by hanging up.
For carriers
This feature helps the carriers protect network resources without affecting the user
experience.

Description
The S-CSCF supports the following call release modes:
1. Call release initiated by the UE or other network entities
The S-CSCF can release a call at the request of the UE or another network entity. For example,
the UE can send a CANCEL or BYE request to cancel or terminate the call.
2. Call release initiated the S-CSCF itself
The S-CSCF may release a call when the session timer created for the call expires.
When acting as a proxy, the S-CSCF may send a BYE request to both the calling and
called parties to release the call or just release its own resources silently, depending on
the configuration.
The S-CSCF may release a call when excessively long session is detected through long
call audit.
In this case, the S-CSCF sends a BYE request to the calling and called parties to release
call.
The S-CSCF may release a call when the long session alarm is generated for a certain
number of times.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 130

To protect resources, the S-CSCF reports alarms about long sessions and releases calls
when required. When the alarm about over-long session is generated for the maximum
number of times allowed by the system, the S-CSCF sends a BYE request to the calling
and called parties to release the call.
The S-CSCF may release a call due to network-initiated deregistration.
During or after session establishment, the S-CSCF can release the call due to
network-initiated deregistration. For example, when the registration timer expires, the
HSS initiates a deregistration request, or the network administrator initiates a
deregistration request, the S-CSCF must be able to release the current call.
If the call is being established, the S-CSCF sends a CANCEL request to cancel the call.
If the call is already established, the S-CSCF sends a BYE request to the calling and
called parties to release the call.
The S-CSCF can release a call due to network-initiated deregistration by:
− The deregistered IMPU
− The deregistered IMPI
− The deregistered IMPU + IMPI
− The deregistered IMPU + IMPI + contact address (for subscribers with multiple
contact addresses)
The S-CSCF may release a call when it fails to start charging.
The subscriber cannot be properly charged for making calls if the S-CSCF fails to start
charging. In this case, the S-CSCF may release or retain the call, depending on the local
policy.

Enhancement
None

Dependency
None

2.2.4 SWP-CSCF-SSP-021000 iFC-based Service Triggering

Availability
This feature is introduced in CSC3300 V100R002.

Summary
Service provisioning in the IMS is achieved by ASs, which are contacted on the basis of initial
filter criteria (iFC). Filter criteria are stored in the HSS as part of the user profile and are
downloaded to the S-CSCF upon user registration.
iFC of different priorities define the conditions and destination ASs for triggering services.
During call processing, the S-CSCF assesses the iFC and contacts the AS indicated in the
filter criterion that matches. Then, the AS performs the service logic internally defined to
process the service.

Benefits
For subscribers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 131

Subscribers can enjoy rich services.

For carriers
Carriers can provide rich services to the subscribers.

Description
The S-CSCF checks the filter criteria again the Request-URI, SIP method, SIP header, session
case, and session description of the request.

Figure 2-7 Structure of service point trigger

The following initial filter criterion enables the S-CSCF to contact [email protected]
when it receives an INVITE request with the From header field set to [email protected]:
<InitialFilterCriteria>
<Priority>0</Priority>
<TriggerPoint>
<ConditionTypeCNF>0</ConditionTypeCNF>
<SPT>
<ConditionNegated>0</ConditionNegated>
<Group>0</Group>
<Method>INVITE</Method>
</SPT>
<SPT>
<ConditionNegated>1</ConditionNegated>
<Group>2</Group>
<SIPHeader>
<Header>From</Header>
<Content>"[email protected]"</Content>
</SIPHeader>
</SPT>
</TriggerPoint>
<ApplicationServer>
<ServerName>sip:[email protected]</ServerName>
<DefaultHandling index="0">0</DefaultHandling>
</ApplicationServer>
</InitialFilterCriteria>

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 132

The S-CSCF performs the following steps when receiving a request:

1. Select the iFC for a session case (originating, terminating, terminating for an
unregistered subscriber, or originating for an unregistered subscriber)
2. Check whether this request matches the initial filter criterion that has the highest priority
for that subscriber by comparing the service profile with the public user identity that was
used to place this request.
3. If this request matches the initial filter criterion, then S-CSCF will forward this request
to that AS.
4. Check the SIP method received from the previously contacted AS to see whether the
request matches the next following filter criterion of lower priority until one does match.
5. If no more (or none) of the iFC apply, then the S-CSCF will forward this request based
on the route decision.
6. When the S-CSCF realizes that an AS has changed the Request-URI in the case of
terminating iFC, it stops checking and routes the request based on the changed value of
the Request-URI.
7. If the contacted AS does not respond (the timer is configurable), then the S-CSCF
follows the default handling procedure associated with the iFC: that is, either terminate
the session or let the session continue based on the information in the filter criteria.

Enhancement
The timer for contacting the AS is configurable from CSC3300 V100R005 onwards.

Dependency
None

2.2.5 SWP-CSCF-SSP-021100 Different AS Modes Supported by

the S-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The S-CSCF supports the ASs that act in different modes, including originating user agent
(UA), terminating UA, SIP proxy, and back-to-back UA (B2BUA).

Benefits
For subscribers
Subscribers can enjoy rich services.
For carriers
This feature enables the S-CSCF to interwork with the ASs that act in different modes.

Description
After receiving the request from the S-CSCF through the ISC interface, the AS initiates the
actual service. To carry the service out, the AS may act in four different modes:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 133

Terminating UA
The S-CSCF can interwork with an AS acting as a terminating UA. In this mode, the AS
acts as the UE. This mode could be used for providing a voicemail service.
Originating UA
The S-CSCF can interwork with an AS acting as an originating UA. In this mode, the AS
informs the originator about the subscriber's new location or about alternative services
that might be able to satisfy the session. This mode could be used for redirecting the
originator to a particular Web page.
SIP proxy
The S-CSCF can interwork with an AS acting as a SIP proxy. In this mode, the AS
processes the request and then proxies the request back to the S-CSCF. While processing,
the AS complies with the proxy rules specified in RFC 3261.
B2BUA
The S-CSCF can interwork with an AS acting as a B2BUA. The AS generates a new SIP
request for a different SIP dialog, which it sends to the S-CSCF.
− Routing B2BUA: The AS receives a request from the S-CSCF, terminates it, and
generates a new request, which is based on the received request.
− Initiating B2BUA: The AS initiates two requests, which are logically connected
together at the AS.

Enhancement
None

Dependency
None

2.2.6 SWP-CSCF-SSP-021200 Number Analysis Supported by

the S-CSCF
Availability
This feature is introduced in CSC3300 V100R005.

Summary
The called number of a call from the IMS domain to the CS domain is a tel number. Usually,
the called number is a local number, which cannot be used for routing, because unique global
numbers are defined for subscribers in the user profiles. Number analysis performed to
convert a local number into a global number and select a route for the global number. Based
on the basic number analysis functions, the S-CSCF also supports certain extended functions.

Benefits
For subscribers
Flexible dialing manner allows for various terminals that use different dialing rules.
For carriers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 134

This feature provides carriers with enhanced number analysis and routing capabilities on
the IMS network.

Description
The S-CSCF supports the following number analysis functions:
Call source analysis
When receiving a call request, the S-CSCF first performs a call source analysis. The call
sources include location source and home subscription source. The location source is
obtained from the calling access network information carried in the SIP request. The
home subscription source is obtained from the caller URI. The S-CSCF uses the location
source and number source to determine a route selection source code for routing.
Known domain analysis
When receiving a call request, the S-CSCF must check the called URI. The S-CSCF
converts the SIP URI with the user=phone parameter into a tel URI only when the
domain name is known to the local S-CSCF. If the URI is unknown, the S-CSCF
performs an analysis on the domain name in the URI.
If the callee is not in the same domain as the caller, the S-CSCF is not able or authorized
to analyze a number of another domain. In this case, the S-CSCF forwards the request to
the next-hop network entity based on domain name analysis.
URI type analysis
The S-CSCF performs the URI type analysis to recognize the Request-URI in the SIP
requests sent from traditional terminals. The Request-URI from such a terminal may be
presented in SIP URI format without the user=phone parameter, for instance,
sip:+86755123456@domain. To recognize such a Request-URI, the S-CSCF checks the
User-Agent header field in the SIP request.
Number barring
The S-CSCF checks whether the tel number dialed by the subscriber is barred by the
carrier. The number can be either a local number or a global number.
Carriers may forbid subscribers to dial numbers with a certain prefix or some special
numbers.
Dial plan analysis
The S-CSCF can analyze the dial plane based on the prefix or phone-context of the
number dialed by the subscriber. The S-CSCF uses the prefix or phone-context to query
the SDLP (Dial Plan of S-CSCF) table. Two dial plan types can be matched. The
S-CSCF selects one plan type according to the local policy.
After determining the dial plan type, the S-CSCF queries the specific dial plan in the
corresponding data table, that is, SVDLP (Visited Dial Plan of S-CSCF), SHDLP (Home
Dial Plan of S-CSCF), or SDVDLP (Default Visited Dial Plan of S-CSCF).
Number splitting and globalization
− Splitting: The Request-URI carried in the request may include the carrier
identification code (CIC), country/region code (CC), LAC or NDC (LACNDC), and
subscriber number (SC), for example, tel:17951075532256556. In this number,
17951 is the CIC, 755 is the LAC, and 32256556 is the phone number of the
subscriber. Each of these parts can be used as a basis for the carriers to make the
number routing policies. Therefore, the S-CSCF always splits the called number and
then matches each part against the routing policies, if any. This process is called
number splitting.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 135

− Globalization: The number that a subscriber registers with the carrier is always a
global number in the format of +[CC][LACNDC][SC]. Therefore, when receiving a
call request to a local number, the S-CSCF tries to convert the local number into a
global number, and then performs a route analysis on the global number.
After splitting a called number, if the S-CSCF detects that the CC or LACNDC is absent,
the S-CSCF considers that the caller and callee are in the same country or area, and thus
adds the CC or LACNDC of the caller to the called number. Assume that the subscriber
with the number +862156200126 calls the subscriber with the number
tel:17951075532256556. After splitting the called number, the S-CSCF finds that the CC
is not present, and thus adds the CC of the caller, that is, 86, to the called number. Then,
the called number is split into the 17951 (CIC), 86 (CC), 755 (LAC), and 32256556 (SC).
The process of using the caller information to complete the called number into a global
number is called number globalization.
Number conversion
During call processing, the S-CSCF may convert a called number. When serving as an
S-CSCF, the CSC3300 supports the following typical number conversion modes:
− Based on the caller number: The S-CSCF converts the called numbers dialed by the
subscribers of a certain caller number source before performing the number analysis.
− Based on the caller location: The S-CSCF converts the called numbers dialed by the
subscribers of a certain caller location source before performing the number analysis.
− Based on phone-context: The S-CSCF converts the called numbers that carry certain
phone-contexts before performing the number analysis.
− Prefix based: The S-CSCF converts the called numbers with certain prefixes before
performing the number analysis.
Number length control
The originating S-CSCF controls the length of the called number according to the
number length requirements of the country or region, in which the callee resides.
Before forwarding a call request, the S-CSCF checks whether the length of the called
number meets the requirements of the country or region, in which the callee resides.
If the called number is shorter than the minimum number length allowed, the S-CSCF
determines whether to reject or continue with the call according to the carrier's policies.
ENUM/NP query
The S-CSCF may need to query the ENUM server or NP database (NPDB) before
routing the global called number in tel URI format.
Service triggering on the AS
An AS may have special requirements for the format or content of the called numbers
forwarded from the S-CSCF. Therefore, certain number analysis data must be configured
to enable the S-CSCF to send qualified requests to the AS.
Equal access CIC
Equal access is a concept raised in an environment with multiple carriers. It is subject to
the subscriber which carrier's network is selected to connect a toll call. The selection
depends on the service quality and price. This is called equal access because all carriers
share the equal opportunity.
When the carrier selection on call by call (CBC) service is enabled, the AS identifies the
carrier selection code dialed by the subscriber, converts it into a CIC, and delivers the
CIC in a cic parameter to the S-CSCF.
When the carrier pre-selection service (CPS) is enabled, the AS determines the CIC
based on the service profile of the subscriber and adds a cic parameter in the SIP request
sent to the S-CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 136

Route selection analysis

The S-CSCF performs a route selection analysis to obtain the route selection code. The
S-CSCF can use the domain name of a SIP URI, tel URI, or the rn, cic, or phone-context
parameter as the route index to match a route selection code.
Route selection
The S-CSCF uses the route selection source code, route selection attribute code
(obtained by querying the SRTSAC (Route Selection Attribute Code of S-CSCF) table),
and route selection code to match a next-hop route address.
Insertion of the BCS information
The S-CSCF uses the route selection code to match a BCS address and inserts the BCS
address into the Route header field of the request as the next-hop address.

Enhancement
None

Dependency
None

2.2.7 SWP-CSCF-SSP-021300 Early Session Supported by the

S-CSCF
Availability
This feature is introduced in CSC3300 V100R005.

Summary
The early session function is used to establish early media sessions within early dialogs.
Typical applications of this function are ringback tone service and multimedia caller
identification service.
Same as sessions, early sessions adopt the offer/answer model for media negotiation. The only
difference is that the Content-Disposition header field is set to session for regular sessions and
is set to early-session for early sessions. The SDP description for regular session can be
carried in any message during a call procedure, whereas the SDP description for early session
can be carried only in messages before the 200 OK response for INVITE. The
Content-Disposition header field specifies whether the SDP is used for regular media or early
session.

Benefits
For subscribers
Subscribers can enjoy various early media services such as ringback tone service and
multimedia caller identification service.
For carriers
Carriers can deploy various early media services such as ringback tone service and
multimedia caller identification service.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 137

Description
The S-CSCF performs a media capabilities check on early sessions:
The S-CSCF does not take part in the media negotiation. Instead, it only performs a
check on the early media capabilities.
The S-CSCF checks whether the SDP description used for early session fits the local
policies. Only the media types and codecs are checked.
When receiving a request for session establishment, the S-CSCF obtains the SDP
description for early session. If there are multiple message bodies and multiple SDP
descriptions for early session, the S-CSCF checks all the SDP descriptions.
If the media type indicated in an m-line is not allowed, the port number in this m-line is
set to zero. If the codec indicated in an m-line is not allowed, that codec is deleted. If
none of the codecs in an m-line is allowed, the port number in this m-line is set to zero.
The session can be established even when the check on the SDP used for early session
fails. When deleting a codec, the S-CSCF also deletes the attribute lines related to this
codec, such as rtpmap and fmtp.

Enhancement
None

Dependency
None

2.2.8 SWP-CSCF-SSP- 021400 Media Capabilities Check

Supported by the S-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The S-CSCF can check the media capabilities listed in the SDP of a call request based on the
user profile and local policies.

Benefits
For subscribers
Subscribers can access the IMS network through legal media negotiation.
For carriers
Carriers can configure different media capabilities for subscribers on the IMS network to
achieve flexible check of media capabilities during session establishment.

Description
The S-CSCF checks the media capabilities (for session or early session) indicated in a
call request based on the local policies and user profiles.
The S-CSCF checks the media types and codecs during a media capabilities check. The
S-CSCF deletes the codecs that are not allowed and continues with the call connection.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 138

If a media type indicated in the SDP is not allowed, the S-CSCF returns a 488 response
to the UE. The 488 response carries the media types that are allowed for the subscriber
so that the UE can modify the SDP and construct a new request.
When multiple SDP descriptions are carried in the request, the S-CSCF checks the SDP
for regular session and the SDP for early session according to different policies. All the
SDP descriptions, used for regular session or early session, are checked.

Enhancement
Certain extensions to the media capabilities check function of the S-CSCF are provided from
CSC3300 V100R005 onwards. The extensions include media capabilities check based on
local policies, codec check, and processing upon early session check.

Dependency
None

2.2.9 SWP-CSCF-SSP-021500 Interworking Supported by the

S-CSCF /BGCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
When serving as an S-CSCF/BGCF, the CSC3300 can interwork with the legacy networks
and other types of networks.

Benefits
For subscribers
Interworking with legacy networks is critical to the success of the IMS.
For carriers
Interworking with legacy networks is critical to the success of the IMS.

Description
This feature provides the following functions:
Interworking with other IMS networks
The CSC3300 can interwork with other IMS networks.
Interworking with the PSTN
The CSC3300 interworks with the PSTN network through the MGCF and IM-MGW.
When serving as an S-CSCF or a BGCF, the CSC3300 performs number analysis to interwork
with the PSTN network.
Calls from IMS to PSTN
Typical scenarios are local breakout to the PSTN and remote breakout to the PSTN.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 139

− Local breakout to the PSTN: After receiving a call destined for a PSTN subscriber,
the S-CSCF or BGCF in the home domain of the IMS subscriber routes the call to the
MGCF in the visited domain of the subscriber. The call is then routed to the called
PSTN subscriber through the PSTN network in the area where the caller is now
roaming. If it is a toll call, a PSTN toll trunk circuit is occupied. The route model is
as follows:
Caller → P-CSCF → S-CSCF/BGCF → MGCF in the visited domain → ISUP trunk
circuit → callee
− Remote breakout to the PSTN: After receiving a call destined for a PSTN subscriber,
the S-CSCF or BGCF in the home domain of the IMS subscriber routes the call to the
BGCF and MGCF on the IMS network in the area where the callee resides. The call
is then routed to the called PSTN subscriber through the terminating PSTN network.
In this mode, a toll call does not occupy any PSTN toll trunk circuit, and the IP
network resources are fully utilized. The route model is as follows:
Caller → P-CSCF → S-CSCF/BGCF → BGCF on the terminating network →
MGCF on the terminating network → ISUP trunk circuit → callee
Calls from PSTN to IMS
Typical scenarios are local breakout to the IMS and remote breakout to the IMS.
− Local breakout to the IMS: The originating PSTN network routes the call to the
terminating IMS network through a local MGCF. In this mode, a toll call does not
occupy any PSTN toll trunk circuit, and the IP network resources are fully utilized.
However, if the originating PSTN network fails to identify the terminating IMS
network (because IMS subscribers use office numbers and the numbering is not
independent), the call is routed within the PSTN networks most of the time. When the
call reaches the terminating area, and the IMS network to terminate the call is
identified, the MGCF on the terminating network is selected to route the call to the
called IMS subscriber. IMS subscribers may roam to different areas. Therefore, when
the MGCF routes the call to the IMS network, roundabout routes may occur. The
route model is as follows:
Caller → ISUP trunk circuit → MGCF on the originating network → terminating
I-CSCF → S-CSCF → callee
− Remote breakout to the IMS: The originating PSTN network routes the call to the
PSTN network in the terminating area, and then the MGCF on the terminating
network routes the call to the IMS network. If it is a toll call, a PSTN toll trunk
circuit is occupied.
Caller → ISUP trunk circuit → MGCF on the terminating network → terminating
I-CSCF → S-CSCF → callee
Interworking with the NGN (non-IMS SIP, H.323)
The CSC3300 can interwork with the NGN networks, including the NGN networks that do
not use SIP or H.323.
When serving as an S-CSCF or a BGCF, the CSC3300 performs number analysis to select an
MGCF to interwork with the NGN networks.
The softswitches and PSTN switches are numbered in the same way. In addition, some NGN
subscribers and PSTN subscribers on the local network are numbered in a mixed manner.
Therefore, the routing policies for interworking with the NGN are the same as those for
interworking with the PSTN. The route model for a call from an IMS subscriber to an NGN
subscriber is as follows:
Caller → P-CSCF → S-CSCF/BGCF → SoftX3000 → ISUP trunk circuit → callee

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 140

Interworking with the PLMN CS

The CSC3300 can interwork with the GSM/UMTS CS networks through the MGCF and
IM-MGW. The GSM/UMTS CS networks use ISUP or BICC as the control signaling.
Calls from IMS to PLMN
Typical scenarios are local breakout to the PLMN and remote breakout to the PLMN.
− Local breakout to the PLMN: After receiving a call destined for a PLMN subscriber,
the BGCF in the home domain of the IMS subscriber routes the call to the MGCF in
the visited domain of the subscriber. The call is then routed to the called PLMN
subscriber through the PLMN network in the area where the caller is now roaming.
This mode does not cause roundabout routes. However, the BGCF must know the
visited network of the caller and route the call to the BGCF or MGCF on that
network.
− Remote breakout to the PLMN: After receiving a call destined for a PLMN subscriber,
the BGCF in the home domain of the IMS subscriber routes the call to the MGCF on
the terminating network. The call is then routed to the called PLMN subscriber
through the terminating PLMN network. In this mode, if the callee is roaming,
roundabout routes occur. In addition, the BGCF must store the H0 to H3 data of the
entire PLMN network for making route decision. The data configuration is complex.
Calls from PLMN to IMS
Same as PLMN subscribers, IMS subscriber may roam to different areas. Therefore,
local breakout to IMS does not cause roundabout route, whereas remote breakout to IMS
causes roundabout routes when the called IMS subscriber is roaming.
Interworking with IP networks
The CSC3300 can interwork with external IP networks through the Mm interface.

Enhancement
The number analysis functions of the S-CSCF are provided from CSC3300 V100R005
onwards.

Dependency
None

2.2.10 SWP-CSCF-SSP-021600 Protocol Interfaces Supported by

the S-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The S-CSCF supports various reference points and related protocols to interwork with other
IMS network entities.

Benefits
For subscribers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 141

The protocol interfaces are fundamental for the interworking between IMS network
entities.
For carriers
The protocol interfaces are fundamental for the interworking between IMS network
entities.

Description

Mw (CSCF - CSCF)
The Mw interface is located between the CSCFs. It uses the SIP. The procedures in the
Mw interface can be classified into three main categories: registration, session control,
and transaction.
Cx/Dx (CSCF - HSS/CSCF-SLF)
The Cx interface is located between the CSCF and the HSS. It uses the Diameter. The
procedures in the Cx interface can be divided into three main categories: location
management, user data handling, and user authentication.
The Dx interface is located between the CSCF and the SLF. It uses the Diameter. The Dx
interface is always used in conjunction with the Cx interface.
ISC (CSCF - AS)
The IMS service control (ISC) interface is located between the CSCF and the AS. It uses
the SIP.
Mg (CSCF - MGCF)
The Mg interface is located between the CSCF and the MGCF. It uses the SIP. This
interface allows the MGCF to forward the incoming session signaling from the CS
domain to the I-CSCF.
Mr (CSCF - MRFC)
The Mr interface is located between the S-CSCF and the MRFC. It uses SIP. When the
S-CSCF needs to activate bearer-related services, it sends SIP signaling to the MRFC
through the Mr interface.
Mm (CSCF - multimedia IP networks)

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 142

The Mm interface is located between the CSCF and other multimedia IP networks. The
protocol used on this interface is not yet defined.
Mi (CSCF - BGCF)
The Mi interface is located between the CSCF and the BGCF. It uses the SIP. When the
S-CSCF discovers that a session needs to be routed to the CS domain, it uses the Mi
interface to forward the session to BGCF.
Rf (CSCF - CCF)
The Rf interface is located between the IMS entities and the CCF. It uses the Diameter.
The IMS session traverses through various IMS entities and all entities that perform SIP
session control are able to generate offline charging information. The charging
information is sent from the IMS entities to the CCF using Diameter Accounting
Requests (ACRs) through the Rf interface. The CCF then processes the received data.
Ro (CSCF - OCS)
The S-CSCF, AS, and MRFC are the IMS entities that are able to perform online
charging. The AS and MRFC use the Ro interface, whereas the S-CSCF uses the ISC
interface to communicate with the online charging system (OCS).

Enhancement
None

Dependency
None

2.2.11 SWP-CSCF-ESP-022200 Emergency Calls Supported by the

E-CSCF
Availability
This feature is introduced in CSC3300 V100R006.

Summary
The number 911 is the emergency call number of America and E911 is short for enhanced 911.
The E911 emergency call is applicable to voice communications services. It enables an
emergency call to be connected to the nearby public safety answering point (PSAP) based on
the caller location.
The E911 emergency call feature is applicable to North America and complies with the
Interim VoIP Architecture for E911 Services North America standard. With this feature, the
emergency CSCF (E-CSCF) queries the Query-LRF (location retrieval function) for call
connection information of the PSAP or emergency center (EC) and accurate location
information of subscribers.

Benefits
For subscribers
This feature enables subscribers to make E911 emergency calls in the case of an
emergency and be connected to the nearby EC successfully. Then, the EC can obtain the
locations of the subscribers.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 143

For carriers
This is an admittance service for North-American areas, which enhances the capability
of North-American networks in supporting emergency calls. Especially, the E-CSCF has
the capability of detecting the LRF status, reselecting the DNS, and monitoring OPTION
status recovery, which improves the success rate of emergency calls.

Description
Logical networking for E911 emergency calls

E-CSCF: It is responsible for session control of E911 emergency calls. The S-CSCF, serving
as the E-CSCF, processes the emergency call requests from the P-CSCF and routes the
emergency calls to the emergency call server (ECS) or to the emergency service gateway
(ESGW) based on the redirection responses from the ECS.
ECS: It provides the functions of the redirect server, routing proxy, and LRF. The ECS
functions as the Query-LRF. The ECS receives the emergency calls from the E-CSCF, queries
subscriber location information, and instructs the E-CSCF to re-route the emergency calls
through the redirection indications or directly routes the calls to the ESGW.
Redirection: When receiving a call request forwarded by the E-CSCF, the Query-LRF returns
an emergency service routing number (ESRN) to the E-CSCF based on the caller information
and called number. Based on the ESRN, the E-CSCF routes the request to the ESGW where
the request will be forwarded to the PSAP.
Proxy: When receiving a call request forwarded by the E-CSCF, the Query-LRF queries the
ESRN based on the caller information and called number. Based on the obtained ESRN, the
Query-LRF directly routes the request to the ESGW where the request will be forwarded to
the PSAP.
ESGW: It indicates a kind of emergency service gateway, such as the MGCF. It processes the
emergency calls from the E-CSCF or ECS and routes the calls to the PSAP.
PSAP: It is the public safety answering point. In North America, the PSAP functions as a
universal answering point for processing emergency call requests. All emergency call requests
are routed to the PSAP for processing.
Functions of E911 emergency calls
E-CSCF supporting emergency calls in V5 mode
E-CSCF supporting dialog status subscription in emergency calls originated by the LRF
in V5 mode
E-CSCF supporting emergency calls in V6 mode
P-CSCF/E-CSCF supporting the load balancing and route progression of DNS
centralized mode
P-CSCF/E-CSCF supporting the OPTION detection of heuristic mode

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 144

E911 emergency call in V5 mode

When the LRF provides the redirection function, the emergency call mode is V5 mode.

E911 emergency call in V6 mode

When the Query-LRF provides the proxy function, the emergency call mode is V6 mode.

Dialog status subscription in emergency calls originated by the LRF in V5 mode

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 145

Load balancing and route progression of DNS centralized mode and OPTION detection of
heuristic mode
The E-CSCF has the capability of detecting the LRF status, reselecting the DNS, and
monitoring OPTION status recovery. When a certain LRF fails, the E-CSCF selects another
available LRF server, and performs the heuristic OPTION detection on the faulty server. This
greatly improves equipment disaster tolerance capability and call completion success rate of
emergency calls.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 146

Enhancement
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 147

Dependency
None

2.3 MI2SICSCSP00 I-CSCF Session Processing

2.3.1 SWP-CSCF-ISP-021700 Registration Supported by the
I-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
IMS registration is performed to bind an IMPU to an IP address on the CSCF, and thus the UE
can enjoy IMS services.
IMS deregistration is performed to unbind an IMPU with an IP address on the CSCF.
An MON subscriber has multiple IMPUs. These IMPUs together comprise a set. On the
CSC3300, if an IMPU in the set is registered, the other IMPUs are registered automatically.
The I-CSCF supports the registration, re-registration, and deregistration of subscribers.

Benefits
For subscribers
This feature enables subscribers to enjoy IMS services.
For carriers
This feature enables carriers to provide IMS services to subscribers.

Description
This feature provides the following functions:
Initial registration

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 148

1. The P-CSCF receives an initial registration request.

The P-CSCF adds the host name or domain name to the path header field.
The P-CSCF adds Require:path.
The P-CSCF adds P-Visited-Network-ID to identify the visited network where the
P-CSCF is located.
The P-CSCF generates icid and adds P-Charging-Vector for the correlation of CDRs.
The P-CSCF queries the DNS for the home network of the subscriber, and forwards the
registration request to the I-CSCF of the home network.
2. The I-CSCF receives the initial registration request and determines whether the request is
from the trusted domain. For the request from an untrusted domain, the I-CSCF returns a 403
message to reject the request. The I-CSCF obtains impu, impi, and P-Visited-Network-ID of
the subscriber, and sends a user-authorization-request (UAR) to the HSS to check the
subscriber rights. If the HSS returns a roaming restriction, the I-CSCF returns a 403 message
to reject the registration request; if the HSS returns a success response, the I-CSCF selects a
suitable S-CSCF based on the subscriber rights returned by the HSS.
3. The S-CSCF returns a 200 OK message, indicating that the registration is successful. The
P-CSCF records the subscriber registration status and related information (such as impu,
contact address, and service-route) in the database.
Re-registration

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 149

1. The P-CSCF receives a re-registration request.

1. The P-CSCF receives a deregistration request.

The P-CSCF adds the host name or domain name to the path header field.
The P-CSCF adds Require:path.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 150

The P-CSCF adds P-Visited-Network-ID to identify the visited network where the
P-CSCF is located.
The P-CSCF generates icid and adds P-Charging-Vector for the correlation of CDRs.
The P-CSCF queries the DNS for the home network of the subscriber, and forwards the
registration request to the I-CSCF of the home network.
2. The I-CSCF receives the deregistration request. The I-CSCF obtains impu, impi, and
P-Visited-Network-ID of the subscriber, sends a UAR message to the HSS to query the
S-CSCF that serves the subscriber, and then forwards the deregistration request to the
S-CSCF.
3. The S-CSCF returns a 200 OK message, indicating that the deregistration is successful. The
P-CSCF clears the subscriber registration data and related information from the database.

Enhancement
None

Dependency
None

2.3.2 SWP-CSCF-ISP-021800 Session Establishment Supported by

the I-CSCF
Availability
This feature is introduced in CSC3300 V100R002.

Summary
During call establishment, the I-CSCF identifies an S-CSCF that serves the local IMS
subscriber and routes the call to that S-CSCF.

Benefits
For subscribers
This is a basic IMS service.
For carriers
This is a basic IMS service.

Description
Processing the INVITE request (MO procedure)
The I-CSCF obtains the caller number from the P-Asserted-Identity or From (secondary
choice) header field and sends a Location Info Request (LIR) to the HSS to request the
address of the S-CSCF that serves the subscriber. The LIR message must include an
Originating Request AVP to indicate the MO procedure. If the HSS returns the S-CSCF
address, the I-CSCF forwards the INVITE request to the S-CSCF. If the HSS returns a set of
service capabilities, the I-CSCF selects a suitable S-CSCF in the local S-CSCF list based on
the capabilities and forwards the request, which is similar to the registration procedure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 151

Processing the INVITE request (MT procedure)

The I-CSCF obtains the called number from the Request-URI header field and sends an LIR
to the HSS to request the address of the S-CSCF that serves the subscriber. If the HSS returns
the S-CSCF address, the I-CSCF forwards the INVITE request to the S-CSCF. If the HSS
returns a set of service capabilities, the I-CSCF selects a proper S-CSCF in the local S-CSCF
list based on the capabilities and forwards the request, which is similar to the registration
processing.
The 200 OK response for INVITE indicates that the session is successfully established. The
subsequent messages of this session do not pass through the I-CSCF.
During forking, the I-CSCF directly forwards the 200 OK response from each leg.

Enhancement
None

Dependency
None

2.3.3 SWP-CSCF-ISP-021900 Number Analysis Supported by the

I-CSCF
Availability
This feature is introduced in CSC3300 V100R006.

Summary
Number analysis is designed to cater for various dialing characteristics and improve the call
completion rate and customer satisfaction. The number analysis functions supported by the
I-CSCF includes called number conversion of incoming and outgoing calls, number type
recognition, caller number analysis, call source analysis, and route analysis. Based on number
analysis, the I-CSCF normalizes or converts the number and selects a route for the call.

Benefits
For subscribers
Number analysis allows the subscribers to dial numbers in different ways.
For carriers
Number analysis helps the carriers to improve the call completion rate and customer
satisfaction.

Description
The I-CSCF performs number analysis only in an MT procedure or when the I-CSCF transits
calls. It does not perform number analysis in an MO procedure.
Figure 2-11 shows the number analysis process.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 152

Figure 2-8 Number analysis of the I-CSCF

The I-CSCF performs the following steps during a number analysis process:
1. Perform the incoming number change analysis.
By performing this step, the I-CSCF determines whether the carrier has configured an
incoming number change policy for the called number. If the carrier has configured an
incoming number change policy, the I-CSCF converts the called number, and then
analyzes the converted number. The I-CSCF uses the called number to match a record in
the IICC (Incoming Call Configuration of I-CSCF) table. Based on the query result, the
I-CSCF determines whether to convert the called number.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 153

If the query is successful, the I-CSCF obtains the Index of OFC parameter, based on
which the I-CSCF queries the IONF (Outgoing Call Configuration of I-CSCF) table for
the number change policy. Then, the I-CSCF converts the called number according to the
policy.
If the query fails, the I-CSCF does not perform number change on the called number.
2. Analyze the called number.
By performing this step, the I-CSCF obtains the Route selection code parameter, that is,
one of the indexes that determine the route selection policy for the called number. Route
selection code, together with Route selection source code obtained in step 3,
determines the next-hop address of the call.
a. Request-URI type analysis:
Depending on the terminal model and network access device, the called numbers
received by the I-CSCF may be in different formats. That is, the value carried in the
Request-URI header field varies. For example, a subscriber dials a CS domain
number +8675521356235. When the number is routed to the I-CSCF, it may be
presented in the format of sip:[email protected] or
sip:[email protected];user=phone. For such a number, the I-CSCF must
convert it into a tel URI (for example, tel:+8675521356235) based on the data
configuration and select a route for the call based on the tel URI. The I-CSCF
identifies the type of the called number in the Request-URI header field by using the
following methods:
− If the value in the Request-URI header field is a tel URI, then the Request-URI type
is tel URI in the analysis result, and thus the I-CSCF retains the called number.
− If the value in the Request-URI header field is a SIP URI and the user part of the SIP
URI is not in E.164 format, then the Request-URI type is SIP URI in the analysis
result, and thus the I-CSCF retains the called number. For example, the user part in
sip:[email protected] is bob, which is not an E.164 number. After performing the
analysis, the I-CSCF determines that the Request-URI type is SIP URI.
− If the value in the Request-URI header field is a SIP URI and the user part in the SIP
URI is in the E.164 number format, then the result of Request-URI type analysis
depends on the data configuration of the transit feature.
− If the SIP URI includes the user=phone parameter (for example,
sip:[email protected];user=phone), and the domain name part of the SIP
URI is configured, then the result of Request-URI type analysis is tel URI. The
I-CSCF then converts the SIP URI into a tel URI. For example, if the SIP URI is
sip:[email protected];user=phone, the I-CSCF converts it into
tel:+8675523265863.
− If the SIP URI does not include the user=phone parameter (for example,
sip:[email protected]), and the domain name part is configured, then the
result of Request-URI type analysis is tel URI. For example, if the SIP URI is
sip:[email protected], the I-CSCF converts it into tel:+8675523265863.
− If the preceding two conditions are not met, the result of Request-URI type analysis is
SIP URI. In this case, the I-CSCF retains the called number.
b. Querying the HSS:
After Request-URI type analysis, the I-CSCF uses the called number to query the
HSS to determine whether the callee is an IMS subscriber.
− If the query is successful and the callee is an IMS subscriber, the I-CSCF routes the
call to the S-CSCF, through which the subscriber is registered. The number analysis
process on the I-CSCF is complete.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 154

− If the query fails, the I-CSCF processes the call based on the result of Request-URI
type analysis.
c. Number route analysis:
If the Request-URI type is tel URI, the I-CSCF performs a number route analysis to
obtain the route selection code. The I-CSCF uses the number part of the tel URI to
query the INRTANA (Number Route Analysis of I-CSCF) table for a route selection
code.
d. Domain route analysis:
If the Request-URI type is SIP URI, the I-CSCF performs a domain route analysis to
obtain the route selection code. The I-CSCF uses the domain name part of the SIP
URI to query the IDRTANA (Domain Route Analysis of I-CSCF) table for a route
selection code.
3. Perform a call source analysis.
By performing this step, the I-CSCF obtains the Route selection source code parameter,
that is, one of the indexes that determine the route selection policy for the called number.
The caller number, together with the previous hop address, determines a route selection
source code. Route selection source code, together with Route selection code obtained
in step 2, determines the next-hop address of the call.
a. Incoming office direction analysis: The I-CSCF performs this analysis to obtain an
address index, that is, one of the indexes that determine the route selection source
code. The address index, together with the caller number index, determines the route
selection source code.
The I-CSCF uses the previous hop address to query the IICC table for an address
index.
b. Caller number analysis: The I-CSCF performs this analysis to obtain the caller
number index, that is, one of the indexes that determine the route selection source
code. The caller number index, together with the address index, determines the route
selection source code.
The I-CSCF uses the caller number to query the ICLRNA (Caller Number Analysis of
I-CSCF) table for a caller number index.
c. Route selection source code analysis: The I-CSCF performs this analysis to obtain
the route selection source code.
The I-CSCF uses the address index and caller number index to query the IRTSSC
(Route Selection Source Code of I-CSCF) table for a route selection source code. If
either of the two indexes fails to be obtained in the previous step, the I-CSCF can use
only one index to query the IRTSSC table.
4. Perform the route analysis.
By performing this step, the I-CSCF obtains the next-hop address of the call. Based on
the attributes of the next-hop address, the I-CSCF determines whether to convert the
called number before routing the call to the next-hop network entity.
a. Route index analysis: The I-CSCF performs this analysis to obtain Route address ID
of the next-hop address. This parameter can be correlated with the next-hop route
address defined in the IRTADDR (Route Address of I-CSCF) table.
The I-CSCF uses the route selection code and route selection source code obtained in
steps 2 and 3 to query the IRTANA (Route Analysis of I-CSCF) table for the route
address ID. If either of the two codes fails to be obtained, the I-CSCF can use only
one code to query the IRTANA table.
b. Next-hop route analysis: The I-CSCF performs this analysis to obtain the next-hop
route address.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 155

The I-CSCF uses the route address ID to query the IRTADDR table for the next-hop
address and related information.
c. Outgoing number change analysis: The I-CSCF performs this analysis to determine
whether to change the value in the Request-URI header field before routing the call
to the next-hop network entity.
The I-CSCF uses Index of OFC obtained in next-hop route analysis to query the
IONF table for an outgoing number change policy. The I-CSCF then converts the
called number according to the policy and routes the call.

Enhancement
None

Dependency
None

2.3.4 SWP-CSCF-ISP-022000 Topology Hiding Supported by the

I-CSCF
Availability
Table 2-1 describes the requirements for implementing the Topology Hiding feature.

Table 2-1 Requirements for implementing the Topology Hiding feature

Required NEs Required Version License Support

I-CSCF V100R003C02 or later This feature does not require

license support.

Summary
Topology hiding means that a carrier hides the network configuration, capacity, and topology
structure information of its network (for example, accurate IP address of S-CSCF, and
network capacity) from other carriers.
The details of a carrier's network are sensitive commercial secrets. When carriers cooperate
with each other, the internal structure of their networks is prone to be exposed. Topology
hiding delivers a mechanism through which a carrier can decide whether to hide its network
information.
Generally, topology hiding is implemented by the THIG, and the THIG is included in the
I-CSCF. If the I-CSCF includes the THIG, the I-CSCF is capable of encrypting and decrypting
the S-CSCF address and/or P-CSCF address of the local domain in the Via, Record-Route,
Route, and Service-Route headers. The CSCF network entities of an external domain can
receive the encrypted routing information, but do not know how to decrypt the routing
information. As a result, the routing information can be kept confidential.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 156

Benefits
Table 2-2 describes the benefits of the Topology Hiding feature.

Table 2-2 Benefits of the Topology Hiding feature

Beneficiary Description

Carriers Topology hiding enables carriers to protect their

commercial secrets, thus processing various
messages securely.

Description
Description of Implementation Principle
The THIG encrypts or decrypts the route header according to the direction (incoming or
outgoing) of a message.
If a network does not require topology hiding, the system implements the ordinary service
flow.
If a network requires topology hiding, the THIG must implement the following operations:
Decrypt the related route headers of all the incoming messages.
Encrypt the related route headers of all the outgoing messages.
Registration Flow
After receiving a registration request, the I-CSCF of the home domain first determines
whether the subscriber-accessed P-CSCF belongs to the local domain. If not, the I-CSCF adds
the host name of a reachable I-CSCF (THIG) to the top of the path header. After the request
passes the authentication, the S-CSCF returns a 200 OK response, and determines that
topology hiding is required. Then, the I-CSCF obtains the THIG address information from the
top path header field and adds the information to the top of the Service-Route header field.
After receiving the 200 OK response, the I-CSCF of the home domain determines that
topology hiding is required, and then encrypts the address information of the Service-Route
header other than the top-hop route (THIG address).
Flow (a subscriber in an IMS Domain Calls Another Subscriber in an IMS Domain)
After determining that the subscriber-accessed P-CSCF is not in the local domain, the I-CSCF
of the home domain first decrypts the self-encrypted messages, and then forwards the
decrypted messages to the S-CSCF in the local domain.
When the messages are sent from the originating IMS domain to the terminating IMS domain,
the originating I-CSCF first determines whether the messages are outgoing messages. If yes,
the originating I-CSCF implements topology hiding. The originating I-CSCF encrypts the
addresses of the network entities of the local domain carried in the Via and Record-Route
headers.
After receiving the messages, the terminating I-CSCF first determines whether the messages
need to be encrypted or decrypted. If required, the terminating I-CSCF encrypts or decrypts
the messages. Otherwise, the terminating I-CSCF transmits the messages transparently. An
initial request is not encrypted by the terminating I-CSCF. The terminating I-CSCF needs to

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 157

add only the host name of a reachable I-CSCF (THIG) to the Record-Route header so that
subsequent messages can be encrypted and decrypted through the THIG.
Flow (A Subscriber in an IMS Domain Calls Another Subscriber in a CS Domain)
After receiving a message, the originating S-CSCF delivers the message to the BGCF of the
local domain if it finds that the message is destined for a CS domain. If the BGCF of the local
domain determines that topology hiding is required, it routes the message to the I-CSCF. The
I-CSCF implements topology hiding, and then forwards the message to the MGCF of an
external domain.
Routing Implementation of Topology Hiding
During a call, a maximum of four I-CSCFs can implement the topology hiding feature. After
receiving a message, an I-CSCF must implement appropriate encryption or decryption
operations based on its own location.
Assume that a call is initiated from left to right, and PCSCF-A, SCSCF-A, SCSCF-B, and
PCSCF-B are in four different domains respectively. Figure 2-9 shows the routing of
inter-network topology hiding.

Figure 2-9 Routing implementation of inter-network topology hiding

Each I-CSCF processes an initial request as follows:

1. After the message is sent to ICSCF-A1, ICSCF-A1 first decrypts the password added by
itself at the time of registration.
2. After the message is sent to ICSCF-A2, ICSCF-A2 encrypts the information containing
the SCSCF-A route (such as the Via and Record-Route headers).
3. After the message is sent to ICSCF-B1, ICSCF-B1 determines whether it needs to
decrypt the related information because the message is an incoming message to the local
domain. The "token-by" in the Route header indicates that it is not encrypted by the local
domain. Thus, it need not be decrypted. Then, ICSCF-B1 determines whether the callee
is in the local domain. If yes, ICSCF-B1 determines whether the previous-hop network
entity is in the local domain and decides whether to implement route hiding for the
response. If yes, ICSCF-B1 adds the address of the THIG to the Record-Route header.
4. After the message is sent to ICSCF-B2, ICSCF-B2 encrypts the information containing
the SCSCFB route (such as the Via and Record-Route headers).
After reaching each I-CSCF, the response is processed similarly:
1. Each I-CSCF determines whether it is required to encrypt or decrypt the related
information.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 158

2. If decryption is not required, each I-CSCF encrypts the related information for the
purpose of topology hiding after determining that the next hop is not a network entity of
the local domain.
General Flow
Topology Hiding Flow During Registration
Figure 2-10 shows the topology hiding flow during registration.

Figure 2-10 Topology hiding flow during registration

Topology hiding must be implemented when a subscriber is registered. The processing flows
of the I-CSCF and S-CSCF are as follows:
1. R1: After receiving a registration request, the I-CSCF determines that topology hiding is
required and finds that the registration request carries the path header. Then, the I-CSCF
adds the host name of the I-CSCF to the top of the path header, and forwards the request
to the S-CSCF.
2. R2: The S-CSCF returns a 200 OK response. After finding that the path header contains
more than one hop, the S-CSCF determines that topology hiding is required. Then, the
S-CSCF extracts the information on the top hop of the path header, and adds the
information to the top of the Service-Route header.
3. R3: After receiving the response, the I-CSCF determines that topology hiding is required.
Then, the I-CSCF invokes the encryption algorithm to encrypt the route information of

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 159

all the network entities in the local domain carried in the Service-Route header other
than the top-hop route (the I-CSCF itself), and then generates an NAI in the format of
username@realm. "Username" indicates an encrypted character string. "realm" is the
name of the domain where the I-CSCF is located. Then, the I-CSCF addes the
tokenized-by= parameter whose value is the domain name of the I-CSCF.
Topology Hiding Flow on the Caller Side
Figure 2-11 shows the topology hiding flow on the caller side.

Figure 2-11 Topology hiding flow on the caller side

Topology hiding must be implemented during the session. The processing flow of the I-CSCF
on the caller side is as follows:
1. R1: The I-CSCF receives an INVITE message. The token-by of the Route header
indicates that the message is encrypted by the local domain. Then, the I-CSCF invokes
the decryption algorithm to decrypt the Route header, and adds the address of the
I-CSCF to the Record-Route header.
2. R2: For the subsequent 1xx response and 2xx response, the next hop is in an external
domain. Based on the configuration, topology hiding is required. The I-CSCF encrypts
the route information of all the network entities in the local domain carried in the
Record-Route and Via headers other than the address information of the I-CSCF (THIG).
The subsequent requests are processed in the same way as the initial request. Regardless of
whether the messages carry the Record-Route header, the I-CSCF adds its domain name to the
Record-Route header. For the messages of Message or Publish type that do not have
subsequent requests, the I-CSCF implements only the encryption and decryption processing
instead of adding its domain name to the Record-Route header.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 160

Topology Hiding Flow on the Callee Side

Figure 2-12 shows the topology hiding flow on the callee side.

Figure 2-12 Topology hiding flow on the callee side

Topology hiding must be implemented during the session. The processing flow of the I-CSCF
on the callee side is as follows:
1. R1: After receiving an INVITE message, the I-CSCF determines that the message is sent
out of the local domain and that topology hiding is required. Then, the I-CSCF adds its
host name to the Record-Route header, encrypts the Via and Record-Route headers, and
forwards the message.
2. R2: After receiving the response to the initial request, the I-CSCF determines that
decryption for topology hiding is required. Then, the I-CSCF decrypts the Via and
Record-Route header and forwards the response.
The subsequent requests are processed in the same way as the initial request. Regardless of
whether the messages carry the Record-Route header, the I-CSCF adds its domain name to the
Record-Route header.
Topology Hiding Flow When an IMS-domain Subscriber Calls Another IMS-domain
Subscriber
Figure 2-13 shows the topology hiding flow when an IMS-domain subscriber calls another
IMS-domain subscriber.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 161

Figure 2-13 Topology hiding flow when an IMS-domain subscriber calls another IMS-domain
subscriber

Topology hiding must be implemented. When an IMS-domain subscriber calls another

IMS-domain subscriber, the topology hiding flow is as follows:
1. R1: After receiving an INVITE message, the S-CSCF determines that the message is sent
to an external domain and that topology hiding is required. Then, the S-CSCF adds the
configured address of the I-CSCF (THIG) to the Route header, and forwards the
message.
2. R2: After receiving the INVITE request, the I-CSCF in domain A determines whether
topology hiding is required based on the configuration of the topology hiding table. If
yes, the I-CSCF determines whether the next route is available. If not, the I-CSCF
determines whether the called subscriber belongs to the local network. If not, the I-CSCF
adds its host name to the Record-Route header, and encrypts the route information of all

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 162

the network entities in the local domain carried in the Service-Route and Via headers
other than the address information of the I-CSCF (THIG).
3. R3: After receiving an initial INVITE request, the I-CSCF in domain B determines
whether topology hiding is required based on the configuration of the topology hiding
table. If yes, the I-CSCF determines whether the next route is available. If not, the
I-CSCF determines whether the called subscriber belongs to the local network. If yes, the
I-CSCF determines whether the previous-hop network entity belongs to the local domain
and thus determines whether to perform route hiding for the response. If yes, the I-CSCF
adds its host name to the Record-Route header. Then, the I-CSCF queries the HSS for
the address of the terminating S-CSCF, and forwards the message.
4. R4: After receiving the 200 (OK) response, the I-CSCF in domain B determines that
topology hiding is required. Then, the I-CSCF encrypts the Record-Route header, and
forwards the response.
5. R5: After receiving the response, the I-CSCF in domain A determines that decryption for
topology hiding is required. Then, the I-CSCF decrypts the Via and Record-Route
headers.
The subsequent requests are processed in the same way as the initial request. Regardless of
whether the messages carry the Record-Route header, the I-CSCF adds its domain name to the
Record-Route header.
The Route header carried in a subsequent message is generated based on the Record-Route
header of the initial response. When the subsequent message is forwarded to the I-CSCF
network entity in this scenario, a next route is available. Then, the processing flow is the
same as that on the caller side or that on the callee side.
Topology Hiding Flow When an IMS-domain Subscriber Calls a CS-domain Subscriber
Figure 2-14 shows the topology hiding flow when an IMS-domain subscriber calls a
CS-domain subscriber.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 163

Figure 2-14 Topology hiding flow when an IMS-domain subscriber calls a CS-domain subscriber

Topology hiding must be implemented. When an IMS-domain subscriber calls a CS-domain

subscriber, the topology hiding flow is as follows:
1. R1: After receiving an initial INVITE message, the BGCF determines that the message is
sent to the BGCF of an external domain and that topology hiding is required. Then, the
BGCF adds the configured address of the I-CSCF to the Route header, and forwards the
message.
2. R2: After receiving the initial request, the I-CSCF determines that topology hiding is
required. Then, the I-CSCF adds its host name to the Record-Route header, and encrypts
the Via and Record-Route headers.
3. R3: After receiving the response, the I-CSCF determines that the response is an
incoming message to the local domain and that decryption for topology hiding is
required. Then, the I-CSCF decrypts the Record-Route and Via headers, and forwards
the response.
The subsequent requests are processed in the same way as the initial request. Regardless of
whether the messages carry the Record-Route header, the I-CSCF adds its domain name to the
Record-Route header.
Topology Hiding Flow of PSI Service
Figure 2-15 shows the topology hiding flow of the PSI service.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 164

Figure 2-15 Topology hiding flow of PSI service

Topology hiding must be implemented during the session. The processing flow of the PSI
service is as follows:
1. R1: Based on Request-URI, the S-CSCF finds that the domain in Request-URI is the
local domain and thus determines that topology hiding is not required. Then, the S-CSCF
queries the DNS, and forwards the message to the terminating I-CSCF.
2. R2: The I-CSCF finds that subsequent routes are unavailable, and queries the PSI
configured on the OMS2600 OMU client. The I-CSCF matches the PSI. Before
forwarding the message to the AS, the I-CSCF determines whether the AS belongs to the
local domain. If not, the I-CSCF determines whether the previous hop belongs to the
local domain. If yes, the I-CSCF encrypts the message, adds its address to the
Record-Route header, and forwards the message to the AS.
3. R3: The I-CSCF determines that topology hiding is required for the response, and
decrypts the Via and Record-Route headers.
A subsequent message has the next route when forwarded to the I-CSCF. If the I-CSCF finds
that the next-hop route is encrypted by itself, the I-CSCF first decrypts the encrypted route
entries before forwarding the message. Otherwise, the I-CSCF determines whether the next
hop belongs to an external domain. If yes, the I-CSCF first encrypts the related route
information before forwarding the message. For the response to the request, the I-CSCF
performs the contrary processing.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 165

Enhancement
Table 2-3 lists the release history of the Topology Hiding feature.

Table 2-3 Release history of the Topology Hiding feature

History Version Details Release Plan

Initial release V100R003C02 - -

Dependency
The topology hiding feature does not haveany interaction with other features.

2.3.5 SWP-CSCF-ISP-022100 Transit Supported by the I-CSCF

Summary
Transit is a function provided by the I-CSCF which serves as the unified access point of the
CS domain and IMS domain of a carrier.
When receiving a call request, the I-CSCF analyzes the called number. Based on the analysis
result, the I-CSCF forwards the call to the CS domain or the IMS domain.

Benefits
Table 2-4 describes the benefits of the Transit feature.

Table 2-4 Benefits of the Transit feature

Beneficiary Description

Carriers With the transit feature, the I-CSCF can function as

the unified access point of the CS network and IMS
network of carriers. In addition to the DNS/ENUM
function embedded in the CSC3300, the I-CSCF can
provide the transit function to forward incoming
calls to a specified IMS or CS domain, without
interworking with a DNS server.

Availability
Table 2-5 describes the requirements for implementing the Transit feature.

Table 2-5 Requirements for implementing the Transit feature

Required NEs Required Version License Support

I-CSCF V100R006C01 or later This feature does not require
license support.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 166

Dependency
The transit feature does not have any interaction with other features.

Description
Upon receiving a call request, the I-CSCF selects a route for the next hop based on the
information and subscriber data configuration carried in the call request.
Transit Flow
The transit flow also refers to the call request analysis flow on the I-CSCF. Figure 2-16
describes the transit flow.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 167

Figure 2-16 Transit flow

The following part describes in detail, each step in the flow chart.
Called Number Analysis
In this step, the I-CSCF obtains the Route selection name parameter, that is, the called
number is one of the factors that determine the route selection policy of the next hop. Route
selection name and Route selection source name obtained in Call Source Analysis
determine the address of the next hop.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 168

Request-URI type analysis

Due to the terminal type or network access device reason, the number dialed by the
subscriber ay be presented as a different type when the number is routed to the I-CSCF.
That is, the value carried in the Request-URI header changes. For example, the
subscriber dials a CS domain number +86-755-12345678. When the number is routed to
the I-CSCF, it may be presented as sip: [email protected] or sip:
[email protected];user=phone, and so on. For such numbers, the I-CSCF
must convert the called number to a tel URI number based on the data configured by the
carrier. The I-CSCF also selects a route of the next hop based on the tel URI. The
I-CSCF identifies the type of the called number in the Request-URI header by using the
following methods:
− If the value of the Request-URI header is a tel URI number, the I-CSCF determines
that tel URI is the Request-URI type and thus retains the called number.
− If the value of the Request-URI header is a sip URI and the subscriber information
part of the sip URI is not in E.164 format, the I-CSCF determines that the sip URI is
the Request-URI type and thus retains the called number. For example, the subscriber
information in sip:[email protected] is bob, which does not comply with the E.164
number format. After the Request-URI type analysis, the I-CSCF determines that the
number is a sip URI number.
− If the value of the Request-URI header is a sip URI number and the subscriber
information in the sip URI complies with the E.164 number format, the result of
Request-URI type analysis depends on the data configuration of the transit feature.
− If the sip URI number carries the user=phone parameter (for example, sip:
[email protected];user=phone), the result of Request-URI type analysis
is tel URI. The I-CSCF then converts the number to a tel URI number. For example,
if the sip URI is sip: [email protected];user=phone, the I-CSCF
converts it to tel: +86-755-12345678. If the I-CSCF is required to convert it to a SIP
number, run ADD INUADDR to configure the corresponding data.
− If the sip URI number does not carry the user=phone parameter (for example, sip:
[email protected]), and the domain name part of the sip URI number
has been configured by running ADD IURITR, the result of Request-URI type
analysis is tel URI. For example, if the sip URI is sip:
[email protected], the I-CSCF converts it to tel: +86-755-12345678.
− If the sip URI number does not carry the user=phone parameter (for example, sip:
[email protected]), and the domain name part of the sip URI number
has been not configured by running ADD IURITR, the result of Request-URI type
analysis is sip URI. In this case, the I-CSCF retains the called number.
Incoming Number Change Analysis
In this step, the I-CSCF determines whether the carrier has configured an incoming
number change policy for the called number. If the carrier has configured an incoming
number change policy, the I-CSCF converts the called number, and then analyzes the
converted number. The I-CSCF uses the called number to match a record in the IICC
(Incoming Call Configuration of I-CSCF) table. Based on the query result, the I-CSCF
determines whether to convert the called number.
− If the query is successful, the I-CSCF obtains the Name of OFC parameter, based on
which the I-CSCF queries the IONF (Outgoing Call Configuration of I-CSCF) table
for the number change policy. Then, the I-CSCF performs number change on the
called number.
− If the query fails, the I-CSCF does not perform number change on the called number.
The data in the IICC table is configured by running ADD IICC, and the data in the ONF
table is configured by running ADD ONF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 169

Querying the HSS

The I-CSCF uses the called number to match a record in the HSS. In this way, the
I-CSCF determines whether the callee is an IMS subscriber.
− If a matching record is found, the I-CSCF determines that the callee is an IMS
subscriber. Based on the registration information of the callee, the I-CSCF routes the
call request to the S-CSCF that serves the callee. The number analysis process on the
I-CSCF is complete.
− If no matching record is found, the I-CSCF processes the call request based on the
result of Request-URI type analysis.
Number route analysis
If the result of Request-URI type analysis is tel URI, the I-CSCF can obtain the Route
selection name parameter by Request-URI type analysis. The I-CSCF uses the number
part of the tel URI to match a record in the INRTANA (Number Route Analysis of
I-CSCF) table to obtain Route selection name. The data in the INRTANA table can be
configured by running ADD INRTANA.
Domain route analysis
If the result of Request-URI type analysis is sip URI, the I-CSCF can obtain the Route
selection name parameter by Request-URI type analysis. The I-CSCF uses the domain
part of the sip URI to match a record in the IDRTANA (Domain Route Analysis of
I-CSCF) table to obtain Route selection name. The data in the IDRTANA table can be
configured by running ADD IDRTANA.
Call Source Analysis
In this step, the I-CSCF obtains the Route selection source name parameter, that is, the caller
number is one of the factors that determine the route selection policy of the next hop. The
caller number and the previous hop information of the I-CSCF determine the route selection
policy of the next hop. Route selection source name and Route selection name obtained in
Called Number Analysis determine the address of the next hop.
Incoming office direction analysis
In this step, the I-CSCF obtains Name of incoming office routing, that is, the incoming
office direction is one of the factors that determine Route selection source name. Name
of incoming office routing and Caller number routing name obtained in Caller
number analysis determine Route selection source name.
The I-CSCF uses the address of the previous hop to match a record in the IICC table to
obtain Index of incoming office. The data in the IICC table can be configured by
running ADD IICC.
Caller number analysis
In this step, the I-CSCF obtains Caller number routing name, that is, the caller number
is one of the factors determine Route selection source name. Caller number routing
name and Index of incoming office obtained in Incoming office direction analysis
determine Route selection source name.
The I-CSCF uses the caller number to match a record in the ICLRNA (Caller Number
Analysis of I-CSCF) table to obtain Caller number routing name. The data in the
ICLRNA table can be configured by running ADD ICLRNA.
Route selection source name analysis
In this step, the I-CSCF obtains Route selection source name.
The I-CSCF uses Index of incoming office obtained in Incoming office direction
analysis and Caller number routing name obtained in Caller number analysis to match
a record in the IRTSSC (Route Selection Source Code of I-CSCF) table to obtain Route

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 170

selection source name. If Index of incoming office or Caller number routing name
is unavailable, the I-CSCF uses one of the parameters to match a record in the IRTSSC
table. The data in the IRTSSC table can be configured by running ADD IRTSSC.
Route Analysis
In this step, the I-CSCF obtains the address of the next hop. Based on the attributes of the next
hop, the I-CSCF determines to route the call request to the network entity of the next hop or
convert the called number.
Route address name analysis
In this step, the I-CSCF obtains Route address name of the next hop. This parameter
can be associated with the next hop route address in the IRTADDR (Route Address of
I-CSCF) table.
Based on Route selection name obtained in Called Number Analysis and Route
selection source name obtain in Call Source Analysis, the I-CSCF matches a record in
the IRTANA table for Route address name of the next hop. If Route selection name or
Route selection source name is unavailable, the I-CSCF uses another parameter to
match a record. The data in the IRTANA table can be configured by running ADD
IRTANA.
Next hop route analysis
In this step, the I-CSCF obtains Route address name of the next hop. This parameter
can be associated with the next hop route address in the IRTADDR table.
Based on Route address name obtain in Route address index analysis, the I-CSCF
matches a record in the IRTADDR for the information about the route address of the next
hop. The data in the IRTADDR table can be configured by running ADD IRTADDR.
Outgoing number change analysis
In this step, the I-CSCF, based on the requirements of the route address of the next hop,
determines whether to change the value of the Request-URI header before routing the
call request to the next hop.
Based on Name of OFC obtained in Next hop route analysis, the I-CSCF matches a
record in the ONF table for the outgoing number change policy. The I-CSCF then
converts the called number and routes the call request to the next hop. The data in the
ONF table can be configured by running ADD ONF.
Reference Relations Between Tables
Figure 2-17 shows the reference relations between data configuration tables of the transit
feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 171

Figure 2-17 Reference relations between tables

The parameters in the IURITR table and INUADDR table do not reference parameters in other tables.
Therefore, the two tables can be configured before or after other tables.

Enhancement
Table 2-6 lists the release history of the Transit feature.

Table 2-6 Release history of the Transit feature

History Version Details Release Plan

Initial release V100R006C01 - -

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 172

2.4 MI2SIBCFSP00 IBCF Session Processing

2.4.1 SWP-CSCF-IBSP-022300 IBCF Session Processing
Availability
This feature is introduced in CSC3300 V100R006.

Feature Description
The IBCF serves as the border gateway and resides between two IMS networks or
between an IMS network and a SIP-based multimedia network. The IBCF can function
as the entry or exit to a network. When serving as the entry to a network, the IBCF
processes SIP requests from other networks; when serving as the exit to a network, the
IBCF sends SIP requests to other networks. Serving as the interworking point between
networks, the IBCF determines whether SIP requests are sent from or to a trustable
domain and processes the header fields of the SIP messages. The functions of the IBCF
are configured by carriers.
The IBCF provides the following main functions:
− Transport plane control
− Number analysis
− Topology hiding
− Screening SIP signaling

Benefits
For carriers
Transport plane control allows carriers to allocate bandwidths for incoming and outgoing
calls properly.
Number analysis allows carriers to provide stronger routing capabilities.
Topology hiding ensures the privacy of carriers's networks. With the topology hiding
function, the information about the internal network cannot be exposed to the external
network.
The screening SIP signaling function is also called signaling filtering. According to the
filtering policies of carriers, the IBCF accepts, rejects, modifies, or discards SIP
messages based on the header fields and message bodies of the SIP messages.

Description
Networking overview
Tandem networking

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 173

Figure 2-18 Tandem networking

Non-tandem networking

Figure 2-19 Non-tandem networking

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 174

Transport plane control

Transport plane control enables the IBCF to perform NAT and QoS control on interconnected
networks. The IBCF provides the following functions:
Support media NAPT in tandem and non-tandem networking
Support resource admission control in tandem and non-tandem networking
Support QoS control in tandem and non-tandem networking
Support call hold in tandem and non-tandem networking
Number analysis
The IBCF performs number analysis based on the call source, called number, and dialing rule.
The IBCF performs the following functions:
Number completion
Number change
Route analysis
Equal access
Number barring
Topology hiding
Topology hiding enables a carrier to hide the network configuration, capacity, and topology
structure of its network (for example, the accurate IP address of the S-CSCF, the number of
S-CSCFs, the capabilities of the S-CSCF, and network capacity).
The IBCF supports the following encryption modes:
THIG: The THIG encrypts and decrypts the local domain information contained in the
Via, Record-Route, Route, and Service-Route header fields.
B2BUA: In B2BUA mode, the IBCF deletes routes for outgoing calls and adds routes for
incoming calls, thus ensuring information privacy.
Signaling filtering
The signaling filtering function enables the IBCF to accept, discard, reject, and modify
SIP messages based on the header fields, header field values, and parameters in the
header fields of the SIP messages.
The signaling filtering function also enables the IBCF to accept, discard, reject, and
modify SIP messages based on the lengths, characteristics, and contents of the message
bodies of the SIP messages.

Enhancement
None

Dependency
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 175

2.4.2 SWP-CSCF-IBSP-022500 Routing Hiding Supported by the

IBCF
Summary
Detailed information about a carrier's network is a sensitive commercial secret. When carriers
cooperate with each other, the internal structure of their networks is prone to be exposed. The
Routing Hiding Supported by the IBCF service enables the interconnection border control
function (IBCF) to screen routing information such as the Record-Route, Via, and Route
header fields, for calls between subscribers served by different carriers. It then prevents
information about the routing topology of a carrier's network from being exposed to other
carriers or user equipment (UE).

Benefits
Table 2-7 describes the benefits of the Routing Hiding Supported by the IBCF service.

Table 2-7 Benefits of the Routing Hiding Supported by the IBCF service

For... Benefits
Carriers This service enables carriers to prevent commercial
information from being exposed and enhance
network reliability by hiding information about the
routing topology of their networks.
Subscribers None.

Availability
Table 2-8 describes the requirements for implementing the Routing Hiding Supported by the
IBCF service.

Table 2-8 Requirements for implementing the Routing Hiding Supported by the IBCF service

NE Version License Requirements

IBCF V100R008C02 or later A license is not required for
this service.

Description
Figure 2-20 shows the implementation principle of the Routing Hiding Supported by the
IBCF service.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 176

Figure 2-20 Routing hiding

The flow is as follows:

1: An IMS Core subscriber initiates a call to a subscriber in another network.
2: The IBCF receives an INVITE message from the IMS Core subscriber. After performing a
route analysis, the IBCF determines the terminating network. If the local configuration
requires routing information to be hidden from the terminating network, the IBCF saves and
deletes the Via and Record-Route header fields from the INVITE message and adds
information about the IBCF to these two header fields.
3: The IBCF receives a response from the terminating network and restores the Via and
Record-Route header fields that were deleted in 2. The IBCF can also delete information
about the terminating network from the 183 message as required.
4: The IBCF routes the call to the IMS Core.
Subsequently, the IBCF processes the Record-Route and Via header fields in the same way it
processes those header fields in the initial INVITE message except that the IBCF needs to
restore the Route header field based on the Record-Route header field that has been saved.
If the IBCF receives requests from the IMS Core, the IBCF generates the Route header
field using the reversed Record-Route header field values.
If the IBCF receives requests from the terminating network, the IBCF generates the
Route header field using the Record-Route header field values.

Enhancement
Table 2-9 lists the release history of the Routing Hiding Supported by the IBCF service.

Table 2-9 Release history of the Routing Hiding Supported by the IBCF service

Feature Version Release Version Details Release Plan

01 V100R008C02 First release. -

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 177

2.4.3 SWP-CSCF-IBSP-022600 Transit Supported by the IBCF

Summary
The Transit Supported by the IBCF service enables the interconnection border control
function (IBCF) to serve as a unified access point for a carrier's CS and IMS domains. When
receiving a call request, the IBCF analyzes the called number and forwards the call to the CS
or IMS domain based on the analysis result.

Benefits
Table 2-10 describes the benefits of the Transit Supported by the IBCF service.

Table 2-10 Benefits of the Transit Supported by the IBCF service

For... Benefits
Carriers The IBCF functions as a unified access point for a
carrier's CS and IMS domains. With the
DNS/ENUM function embedded in the CSC3300,
the IBCF can provide the transit function for
forwarding incoming calls to a specified CS or IMS
domain without interworking with a DNS server.

Availability
Table 2-11 describes the requirements for implementing the Transit Supported by the IBCF
service.

Table 2-11 Requirements for implementing the Transit Supported by the IBCF service

NE Version License Requirements

IBCF V100R008C02 or later A license is not required for
this service.

Description
When receiving a call request, the IBCF selects a route for the next hop based on the
subscriber data configuration and information carried in the call request.
Transit Flow
The transit flow is the call request analysis flow on the IBCF. Figure 2-21 shows the transit
flow.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 178

Figure 2-21 Transit flow

The following section describes each step in the flow chart:

Called Number Analysis
The IBCF obtains Route selection name. Route selection name and Route selection source
name obtained in Call Source Analysis determine the route address of the next hop.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 179

Request-URI Type Analysis

Depending on the terminal type or network access device type, the dialed number may
be presented in a different format when the number is routed to the IBCF. This means
that the value carried in the Request-URI changes. For example, a subscriber dials CS
domain number +86-755-12345678. When the number is routed to the IBCF, it may be
presented as sip: [email protected] or sip:
[email protected];user=phone. For these numbers, the IBCF must convert
the called number to a tel URI based on the configured data. The IBCF then selects a
route for the next hop based on the tel URI.
The IBCF identifies the type of the called number in the Request-URI using the
following methods:
− If the called number in the Request-URI is a tel URI, the result of the Request-URI
type analysis is a tel URI. The IBCF does not change the called number.
− If the called number in the Request-URI is a SIP URI and the userinfo part of the SIP
URI is not in the E.164 number format, the result of the Request-URI type analysis is
a SIP URI. The IBCF does not change the called number. For example, the userinfo
part in sip:[email protected] is bob, which is not in the E.164 number format. After the
Request-URI type analysis, the IBCF determines that the called number is a SIP URI.
− If the called number in the Request-URI is a SIP URI and the userinfo part of the SIP
URI is in the E.164 number format, the IBCF processes the called number based on
the data configuration of the Transit Supported by the IBCF service.
− If the SIP URI carries user=phone (for example, sip:
[email protected];user=phone), the result of the Request-URI type
analysis is a tel URI. The IBCF converts the called number to a tel URI. For example,
if the SIP URI is sip: [email protected];user=phone, the IBCF converts
it to tel: +86-755-12345678. If the IBCF is required to convert the called number to a
SIP number, run ADD BNUADDR to configure the corresponding data.
− If the SIP URI does not carry user=phone (for example, sip:
[email protected]) and the domain name of the SIP URI has been
configured by running ADD BURITR, the result of the Request-URI type analysis is
a tel URI. For example, if the called number is sip: [email protected],
the IBCF converts the called number to tel: +86-755-12345678.
− If the SIP URI does not carry user=phone (for example, sip:
[email protected]) and the domain name of the SIP URI has not been
configured by running ADD BURITR, the result of the Request-URI type analysis is
a SIP URI. In this case, the IBCF does not change the called number.
Incoming Number Change Analysis
The IBCF determines whether the carrier has configured an incoming number change
policy for the called number. If the carrier has configured such a policy for the called
number, the IBCF converts the called number and then analyzes the new called number.
The IBCF uses the called number to query the SIPTG (SIP Trunk Group) table to
determine whether to convert the called number.
− If the query is successful, the IBCF obtains the change index of the called number
and uses this index to query the ONF (Outgoing Office) table to obtain the number
change policy for the called number. Then the IBCF converts the called number
according to this policy.
− If the query fails, the IBCF does not convert the called number.
The data in the SIPTG table can be configured by running ADD SIPTG, and the data in
the ONF table can be configured by running ADD ONF.
Querying the HSS

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 180

The IBCF uses the called number to query the HSS, and therefore, determines whether
the called party is an IMS subscriber.
− If the IBCF does not need to query the HSS, the IBCF determines the next operation
based on the Request-URI type analysis.
− If the IBCF needs to query the HSS, the IBCF determines the next operation based on
the query result.
− If the query is successful, the IBCF identifies the called party as an IMS subscriber.
Based on the called party's registration information, the IBCF routes the call request
to the S-CSCF with which the called party has registered. The IBCF number analysis
is complete.
− If the query fails, the IBCF determines the next operation based on the Request-URI
type analysis.
Number Route Analysis
If the result of the Request-URI Type Analysis is a tel URI, the IBCF uses the number
part of the tel URI to query the BNRTANA (Number Route Analysis of IBCF) table for
Route selection name. The data in the BNRTANA table can be configured by running
ADD BNRTANA.
Domain Route Analysis
If the result of Request-URI Type Analysis is a SIP URI, the IBCF uses the domain name
part of the SIP URI to query the BDRTANA (Domain Route Analysis of IBCF) table for
Route selection name. The data in the BDRTANA table can be configured by running
ADD BDRTANA.
Call Source Analysis
The IBCF obtains the Route selection source name parameter. The calling number and
previous hop information of the IBCF determine the route selection policy of the next hop.
Route selection source name and Route selection name obtained in Called Number
Analysis determine the route address of the next hop.
Incoming Office Direction Analysis
The IBCF obtains Name of incoming office routing. Name of incoming office routing
and Caller number routing name obtained in Calling Number Analysis determine
Route selection source name. The IBCF performs an incoming office direction analysis.
The data in the SIPTG table can be configured by running ADD SIPTG.
Calling Number Analysis
The IBCF uses the calling number to query the BCLRNA (Caller Number Analysis of
IBCF) table for Caller number routing name. The data in the BCLRNA table can be
configured by running ADD BCLRNA. Caller number routing name and Index of
incoming office obtained in Incoming Office Direction Analysis determine Route
selection source name.
Route Selection Source Name Analysis
The IBCF uses Index of incoming office obtained in Incoming Office Direction
Analysis and Caller number routing name obtained in Calling Number Analysis to
query the BRTSSC (Route Selection Source Code of IBCF) table for Route selection
source name. If Index of incoming office or Caller number routing name is
unavailable, the IBCF uses one of the parameters to query the BRTSSC table. The data in
the BRTSSC table can be configured by running ADD BRTSSC.
Route Analysis

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 181

The IBCF obtains the address of the next hop. Based on the attributes of the next hop, the
IBCF determines whether to route the call request to the next hop or convert the called
number.
Route Address Name Analysis
The IBCF uses Route selection name obtained in Called Number Analysis and Route
selection source name obtained in Call Source Analysis to query the BRTANA (Route
Analysis for BCF) table for Route address name of the next hop. If Route selection
name or Route selection source name is unavailable, the IBCF uses another parameter
to query the BRTANA table. The data in the BRTANA table can be configured by
running ADD BRTANA.
Next Hop Route Analysis
Based on the Route Address Name Analysis result, the IBCF obtains the route index for
the call. Based on this index, the IBCF queries the RT (Route) and SRT (Sub Route)
tables. The data in the RT table can be configured by running ADD RT, and the data in
the SRT table can be configured by running ADD SRT.
Based on the subroute, the IBCF queries the SIPTG table to route the call as an outgoing
call. The data in the SIPTG table can be configured by running ADD SIPTG.
Outgoing Number Change Analysis
Based on the next hop's route address requirements, the IBCF determines whether to
change the value of the Request-URI before routing the call request to the next hop.
Based on Name of OFC obtained in Next Hop Route Analysis, the IBCF queries the
ONF table for an outgoing number change policy. The IBCF then converts the called
number and routes the call request to the next hop. The data in the ONF table can be
configured by running ADD ONF.

Enhancement
Table 2-12 lists the release history of the Transit Supported by the IBCF service.

Table 2-12 Release history of the Transit Supported by the IBCF service

Feature Version Release Version Details Release Plan

01 V100R008C02 First release. -

2.4.4 SWP-CSCF-IBSP-022700 IBCF Trunk Management

Summary
The IBCF Trunk Management service includes the Trunk-based Routing Supported by the
IBCF, Trunk Blocking Supported by the IBCF, Trunk-based Call Restriction by the IBCF, and
Trunk-based Number Conversion Supported by the IBCF services.
For details, see section Summary in Trunk-based Routing Supported by the IBCF, Trunk
Blocking Supported by the IBCF, Trunk-based Call Restriction by the IBCF, and Trunk-based
Number Conversion Supported by the IBCF.

Benefits
Table 2-13 describes the benefits of the IBCF Trunk Management service.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 182

Table 2-13 Benefits of the IBCF Trunk Management service

For... Benefits
Carriers Facilitates management and control of
interworking resources.
Facilitates equipment maintenance and fault
diagnosis.
Enables carriers to plan the SIP trunk traffic
based on the bearer capability to prevent network
congestion.
Enables carriers to meet the interworking
requirements of different devices.
Subscribers None.

Availability
Table 2-14 describes the requirements for implementing the IBCF Trunk Management
service.

Table 2-14 Requirements for implementing the IBCF Trunk Management service

NE Version License Requirements

IBCF V100R008C02 or later A license is not required for
this service.

Description
For details, see section Description in Trunk-based Routing Supported by the IBCF, Trunk
Blocking Supported by the IBCF, Trunk-based Call Restriction by the IBCF, and Trunk-based
Number Conversion Supported by the IBCF.

Enhancement
Table 2-15 lists the release history of the IBCF Trunk Management service.

Table 2-15 Release history of the IBCF Trunk Management service

Feature Version Release Version Details Release Plan

01 V100R008C02 First release. -

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 183

2.4.5 SWP-CSCF-IBSP-022701 Trunk-based Routing Supported by

the IBCF
Summary
The Trunk-based Routing Supported by the IBCF feature allows the IBCF to select a suitable
route based on the service scenario when the IBCF has obtained information about the
destination. The IBCF can select a subroute by order or by weight. With this feature, the IBCF
can manage trunk devices in a differentiated manner to meet interworking requirements of
various carriers and devices.

Benefits
Table 2-16 describes the benefits of the Trunk-based Routing Supported by the IBCF feature.

Table 2-16 Benefits of the Trunk-based Routing Supported by the IBCF feature

For... Benefits
Carriers Carriers can manage and control
interworking resources conveniently.
Subscribers Subscribers experience less call failures
because reliability of route selection is
improved.

Availability
Table 2-17 describes the requirements for implementing the Trunk-based Routing Supported
by the IBCF feature.

Table 2-17 Requirements for implementing the Trunk-based Routing Supported by the IBCF
feature

Required NE Required Version License Support

IBCF CSC3300 V100R008C02 or This feature is a basic

later feature of the IBCF. A
license is not required for
this feature.
CCF V300R002C69 and later Fields are added for filling
the incoming and outgoing
trunk group IDs. A license is
not required for this feature.

Dependency
Table 2-18 describes the interaction between the Trunk-based Routing Supported by the IBCF
feature and other features.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 184

Table 2-18 Interaction between the Trunk-based Routing Supported by the IBCF feature and other
features

Feature Interaction
Trunk Number Conversion After the called number is changed by
implementing the Trunk Number
Conversion feature, trunk selection for the
call may be affected.
Trunk Block If a call is rejected because the incoming
trunk is blocked, the IBCF skips this trunk
and selects another one.
Trunk Call Barring When the number of concurrent calls routed
over the incoming trunk reaches the
maximum value, the IBCF rejects new calls.
When the number of concurrent calls routed
over the outgoing trunk reaches the
maximum value, the IBCF skips this trunk
and selects another one.

Description
Figure 2-22 describes the table query flow of the Trunk-based Routing Supported by the IBCF
feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 185

Figure 2-22 Table query flow of the Trunk-based Routing Supported by the IBCF feature

1. The IBCF performs number analysis and obtains Route selection code, Route selection
source code, and Time section index.
2. The IBCF queries the BRTANA (Route Analysis for BCF) table to obtain Route ID
based on Route selection code, Route selection source code, and Time section index.
3. The IBCF queries the RT (Route) table for an available subroute ID based on Route ID.
4. The IBCF queries the SRT (Sub Route) table for an available trunk group ID based on
the subroute ID.
5. The IBCF queries the SIPTG (SIP Trunk Group) table to obtain Local address ID and
Peer IP address based on the trunk group ID and then routes the call out.

Enhancement
Table 2-19 lists the release history of the Trunk-based Routing Supported by the IBCF feature.

Table 2-19 Release history of the Trunk-based Routing Supported by the IBCF feature

Feature Version Release Version Details Release Plan

01 CSC3300 The Trunk-based None.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 186

Feature Version Release Version Details Release Plan

V100R008C02 Routing Supported
by the IBCF feature
is supported.

2.4.6 SWP-CSCF-IBSP-022702 Trunk-based Number Conversion

Supported by the IBCF
Summary
The Trunk-based Number Conversion Supported by the IBCF feature allows the IBCF to
convert the called number according to interworking rules before routing the call to the peer
device.

Benefits
Table 2-20 describes the benefits of the Trunk-based Number Conversion Supported by the
IBCF feature.

Table 2-20 Benefits of the Trunk-based Number Conversion Supported by the IBCF feature

For... Benefits
Carriers This feature enables carriers to meet
interworking requirements for different
devices.

Availability
Table 2-21 describes the requirements for implementing the Trunk-based Number Conversion
Supported by the IBCF feature.

Table 2-21 Requirements for implementing the Trunk-based Number Conversion Supported by
the IBCF feature

Required NE Required Version License Support

IBCF CSC3300 V100R008C02 or This feature is a basic
later feature of the IBCF. A
license is not required for
this feature.

Dependency
Table 2-22 describes the interaction between the Trunk-based Number Conversion Supported
by the IBCF feature and other features.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 187

Table 2-22 Interaction between the Trunk-based Number Conversion Supported by the IBCF
feature and other features

Feature Interaction
Trunk Selection After the called number is changed by
implementing the Trunk-based Number
Conversion Supported by the IBCF feature,
trunk selection for the call may be affected.

Description
Figure 2-23 shows the table query flow of the Trunk-based Number Conversion Supported by
the IBCF feature for an incoming number.

Figure 2-23 Table query flow of the Trunk-based Number Conversion Supported by the IBCF
feature for an incoming number

Note1: Callee number prefix index, Caller number conversion index, Phone-context
index, or Number conversion index of incoming trunk can identify a called number change
policy. The four parameters can also collectively identify a called number change policy.
The change of an outgoing number includes the change of the Request-URI and the change of
the P-Asserted-Identity header field. Figure 2-24 and Figure 2-25 show the table query flows
for the change of the Request-URI and the change of the P-Asserted-Identity header field,
respectively.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 188

Figure 2-24 Table query flow for the change of the Request-URI

Start

Query the SIPTG table to obtain

Request-URI conversion index
of outgoing trunk

Query the ONF table

No
Are there any results? Do not convert the Request-URI

Yes

Convert the Request-URI based

on Request-URI form type and
Request-URI number form type

Note2
Query the ONPFXF table based on
Is Outgoing No Index of number prefix to obtain
number change type Number prefix change type and
set to ADVANCED? convert the Request-URI based on
Number prefix change type
Yes

Does Non-change No
Note1 expression match the
Request-URI?

Yes
No Does Regular expression Note3
match the Request-URI?

Yes

Convert the Request-URI based on

Do not convert the Request-URI Note4
Replacement expression

End

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 189

Note1: There may be many numbers that match Regular expression. You can configure
Non-change expression so that the IBCF does not change a certain number that matches
Regular expression.
Note2, Note3, and Note4: The operations are performed based on the Request-URI after
change.

Figure 2-25 Table query flow for the change of the P-Asserted-Identity header field

Enhancement
Table 2-23 lists the release history of the Trunk-based Number Conversion Supported by the
IBCF feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 190

Table 2-23 Release history of the Trunk-based Number Conversion Supported by the IBCF
feature

Feature Version Release Version Details Release Plan

01 CSC3300 The Trunk-based None.
V100R008C02 Number Conversion
Supported by the
IBCF feature is
supported.

2.4.7 SWP-CSCF-IBSP-022703 Trunk Blocking Supported by the

IBCF
Summary
The Trunk Blocking Supported by the IBCF feature allows the IBCF to block a trunk when
problems occur in this trunk because of environmental interference, equipment aging, or
transmission device failure. This can temporarily stop the service bearer function of the trunk
or trunk group for problem identification without affecting services. When selecting a trunk,
the IBCF can automatically detect the trunk status and will not select a blocked trunk.

Benefits
Table 2-24 describes the benefits of the Trunk Blocking Supported by the IBCF feature.

Table 2-24 Benefits of the Trunk Blocking Supported by the IBCF feature

For... Benefits
Carriers This feature facilitates equipment
maintenance and fault identification.

Availability
Table 2-25 describes the requirements for implementing the Trunk Blocking Supported by the
IBCF feature.

Table 2-25 Requirements for implementing the Trunk Blocking Supported by the IBCF feature

Required NE Required Version License Support

IBCF CSC3300 V100R008C02 or This feature is a basic
later feature of the IBCF. A
license is not required for
this feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 191

Dependency
Table 2-26 describes the interaction between the Trunk Blocking Supported by the IBCF
feature and other features.

Table 2-26 Interaction between the Trunk Blocking Supported by the IBCF feature and other
features

Feature Interaction
Trunk Selection When a trunk is blocked, the IBCF rejects
all incoming calls over this trunk and selects
another trunk for routing outgoing calls.

Description
Figure 2-26 shows the procedure for implementing the Trunk Blocking Supported by the
IBCF feature for an incoming INVITE request.

Figure 2-26 Procedure for implementing the Trunk Blocking Supported by the IBCF feature for
an incoming INVITE request

1. After receiving an initial INVITE request, the IBCF performs incoming route analysis and
checks the trunk group policies of the incoming trunk.
2. After detecting that the SIP trunk is blocked, the IBCF returns a 403 response to reject the
call.
Figure 2-27 shows the procedure for implementing the Trunk Blocking Supported by the
IBCF feature for an outgoing INVITE request.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 192

Figure 2-27 Procedure for implementing the Trunk Blocking Supported by the IBCF feature for
an outgoing INVITE request

1. After receiving an initial INVITE request, the IBCF performs outgoing route analysis.
2. After detecting that the SIP trunk is blocked, the IBCF skips this trunk and selects another
one to route the INVITE request.

Enhancement
Table 2-27 lists the release history of the Trunk Blocking Supported by the IBCF feature.

Table 2-27 Release history of the Trunk Blocking Supported by the IBCF feature

Feature Version Release Version Details Release Plan

01 CSC3300 The Trunk Blocking None.
V100R008C02 Supported by the
IBCF feature is
supported.

2.4.8 SWP-CSCF-IBSP-022704_PBX Trunk Access Supported by

the IBCF
Summary
The private branch exchange (PBX) makes connections among the internal telephones of an
enterprise and also connects them to the public switched telephone network (PSTN). The
PBX applies to enterprises, companies, and banks. The interconnection border control
function (IBCF), which serves as a border gateway, allows subscribers to connect to the IMS
network using PBX trunks and enables PBX subscribers to use rich IMS services.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 193

Benefits
Table 2-28 describes the benefits of the PBX Trunk Access Supported by the IBCF feature.

Table 2-28 Benefits of the PBX Trunk Access Supported by the IBCF feature

For... Benefits

Carriers Carriers can allow PBX subscribers to

connect to the IMS network, meeting
subscribers' various service requirements.
This feature enhances carrier
competitiveness and provides new revenue
streams for carriers.
Subscribers This feature enables PBX subscribers to
connect to the IMS network, use rich IMS
services, and obtain a better communication
experience.

Availability
Table 2-29 describes the requirements for implementing the PBX Trunk Access Supported by
the IBCF feature.

Table 2-29 Requirements for implementing the PBX Trunk Access Supported by the IBCF feature

NE Version License Function Description

Requirements
IBCF CSC3300 This feature is a basic The IBCF supports registration
V100R008C03 or feature provided by the and basic calls originated by
later CSC3300. A license is using PBX trunks and trunk
not required for this reselection.
feature.

Dependency
Table 2-30 describes the interaction between the PBX Trunk Access Supported by the IBCF
feature and other features.

Table 2-30 Interaction between the PBX Trunk Access Supported by the IBCF feature and other
features

Feature Interaction
Trunk-based Routing Supported by the This feature depends on the IBCF trunk
IBCF selection process. The terminating IBCF
must select the terminating PBX functioning
as an outgoing trunk.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 194

Description
The PBX Trunk Access Supported by the IBCF feature is available to all IMS networks.
Carriers can allow PBX subscribers to connect to the IMS network, meeting subscribers'
various service requirements. This feature enhances carrier competitiveness and provides
new revenue streams for carriers.
This feature enables PBX subscribers to connect to the IMS network, use rich IMS
services, and obtain a better communication experience.

Implementation Principle
Registration Flow
In IBCF access mode, an IP-PBX may or may not register with the IMS domain. If an
IP-PBX registers with the IMS domain, first-party registration is required only for a specified
number (the PBX pilot number is recommended). If an IP-PBX does not register with the IMS
domain, first-party registration is not required for the PBX pilot number or extension numbers.
In IBCF access mode, all PBX subscribers are configured on the AS as voice call continuity
(VCC) subscribers, and third-party registration is not required for any PBX subscribers.
Figure 2-28 shows the registration flow of the PBX pilot number when an IP-PBX registers
with the IMS domain in IBCF access mode.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 195

Figure 2-28 Registration flow

The flow is as follows:

1: The PBX originates a REGISTER message to the IBCF.
2: The IBCF checks the IP address and port number in the REGISTER message and queries
the trunk configuration table for the trunk data. If the PBX access is configured, the IBCF
processes the REGISTER message and processes the message as follows before sending it to
the I-CSCF:
The IBCF adds the Path, Require, P-Visited-Network-ID, and P-Charging-Vector header
fields to the REGISTER message. The rules for constructing these header fields are the
same as the rules used by the P-CSCF for constructing these header fields in the
REGISTER message. The Path and P-Visited-Network-ID header fields are set to the
IBCF host name.
If the REGISTER message contains the Authorization header field, the IBCF adds the
integrity parameter (whose value is yes) to the header field. This ensures that calls are
not authenticated after successful registration.
3-4: The I-CSCF sends a UAR message to the HSS. The UAA message returned by the HSS
contains the Server-Capabilities header field with a preferred S-CSCF address. This address
contains the pbxid parameter. (The S-CSCF capability set is configured by running ADD
HCAPSCSCF.)

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 196

5: The I-CSCF obtains the S-CSCF host name and pbxid parameter value from the preferred
S-CSCF address contained in the UAA message. Then, the I-CSCF selects an S-CSCF address
based on the S-CSCF host name and the locally configured S-CSCF list. Before forwarding
the REGISTER message to the S-CSCF, the I-CSCF includes the pbxid parameter in the
Request-URI of the message.
6-10: The S-CSCF obtains the pbxid parameter from the Request-URI of the REGISTER
message, adds the parameter to the S-CSCF address in an MAR message, and sends the
message to the HSS for registration authentication.
11-12: After receiving the 401 message, the PBX generates registration authentication
information based on the preset authentication algorithm and sends a REGISTER message
again to the IBCF. The IBCF processes the message in the same way as in step 2 of this flow.
13-14: The I-CSCF sends a UAR message to the HSS. The Server-Name header field in a
UAA message returned by the HSS contains a registered S-CSCF address. This address
contains the pbxid parameter.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 197

15: The I-CSCF forwards the REGISTER message to the S-CSCF. In this message, the
Request-URI contains the pbxid parameter.
16-17: The S-CSCF obtains the pbxid parameter from the Request-URI of the REGISTER
message, adds the parameter to the S-CSCF address in an MAR message, and sends the
message to the HSS.
18-19: The S-CSCF returns a 200 message to the IBCF.
20: Upon receiving the 200 message, the IBCF sets the PBX access trunk status to registered,
records the value of the expire parameter, and starts the registration aging timer. The duration
of the timer is set to the value of the expire parameter. If the timer expires, the IBCF sets the
PBX access trunk status to unregistered. After setting the timer, the IBCF sends the 200
message to the PBX.
Originating Call Flow
The following scenario describes the originating call flow when a PBX subscriber originates a
call. The call flow for an unregistered PBX pilot number when the IP-PBX does not support
registration with the IMS domain is different from that for a registered PBX pilot number
when the IP-PBX supports registration with the IMS domain. Figure 2-29 shows the
originating call flow when the IP-PBX does not support registration with the IMS domain.

Figure 2-29 Originating call flow

The flow is as follows:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 198

1: A PBX subscriber originates a call.

2: Upon receiving an INVITE message, the IBCF checks the IP address and port number in
the message and queries the trunk configuration table for the trunk data. If the PBX access is
configured, the IBCF sends an LIR message to the HSS. The IBCF preferentially uses the
P-Preferred-Identity header field value as the calling party's IMPU to be contained in the LIR
message. If the P-Preferred-Identity header field is not present, the IBCF uses the
P-Asserted-Identity header field value. If the P-Asserted-Identity header field is not present,
the IBCF uses the From header field value. The Originating-Request AVP contained in the
LIR message indicates that the LIR message is sent by the originating side.
3: The HSS returns an LIA message to the IBCF.
For a registered number (registered PBX pilot number when the IP-PBX supports
registration with the IMS domain), the LIA message contains the Server-Name header
field. In this header field, the S-CSCF address mapping to the registered number contains
the pbxid parameter.
For an unregistered number (an extension number or unregistered PBX pilot number
when the IP-PBX does not support registration with the IMS domain or an unregistered
extension number when the IP-PBX supports registration with the IMS domain), the LIA
message contains the Server-Capabilities header field. This header field contains the
preferred S-CSCF address with the pbxid parameter.

For an unregistered number, the LIA message returned by the HSS contains the Server-Capabilities
header field only when the iFC contains the Profile part indicator parameter whose value is
UNREGISTERED. In other cases, the HSS returns a failure response.

4: Upon receiving the LIA message, the IBCF processes the LIA message as follows:
The IBCF obtains the S-CSCF address.
− For a registered number, the IBCF obtains the S-CSCF address (containing the pbxid
parameter) mapping to the registered number from the Server-Name header field of
the LIA message. Then, the IBCF routes the call to the corresponding S-CSCF.
− For an unregistered number, the IBCF obtains the preferred S-CSCF address that
contains the pbxid parameter from the Server-Capabilities header field of the LIA
message. Then, the IBCF obtains the host name of the preferred S-CSCF, chooses an
appropriate S-CSCF based on the locally configured S-CSCF list, and routes the call
to the S-CSCF.

If the LIA message returned by the HSS indicates that the subscriber does not exist, the IBCF uses the
calling number (defined in PBX default caller) to send an LIR message to the HSS again. (This
processing mode is recommended and can be configured by running ADD SIPTG with Caller
replacement policy set to REPLACE(Replace by default caller).) The actual processing mode
depends on the data configured by running ADD SIPTG.
The IBCF sends an INVITE message to the S-CSCF.
− The IBCF sends an INVITE message to the S-CSCF. In the message, the Route
header field carries the S-CSCF address with the orig parameter and the pbxid
parameter. The pbxid parameter is set to the value of the pbxid parameter contained
in the LIA message.
− The IBCF adds the P-Asserted-Identity header field to carry information about the
calling party by adhering to the following rules:
− If the previously received INVITE message contains the P-Asserted-Identity header
field but does not contain the P-Preferred-Identity header field, the IBCF retains the
P-Asserted-Identity header field.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 199

− If the previously received INVITE message contains both the P-Asserted-Identity

header field and the P-Preferred-Identity header field, the IBCF uses the
P-Preferred-Identity header field value to construct the P-Asserted-Identity header
field.
− If the previously received INVITE message contains the P-Preferred-Identity header
field but does not contain the P-Asserted-Identity header field, the IBCF uses the
P-Preferred-Identity header field value to construct the P-Asserted-Identity header
field.
− If the previously received INVITE message contains neither the P-Asserted-Identity
header field nor the P-Preferred-Identity header field, the IBCF uses the From header
field value to construct the P-Asserted-Identity header field.
− The IBCF adds the P-Charging-Vector header field to the INVITE message addressed
to the S-CSCF.
The following is an example of the INVITE message:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP
154.16.32.106:5060;branch=z9hG4bKehv6huct7vtwatsssfs7f4vud;Role=3;Dpt=75e8_16;TRC=f
fffffff-a06
Route: <sip:[email protected];lr;pbxid=pbx1.huawei>
Record-Route:
<sip:154.16.32.106;lr;Dpt=75e8_16;Role=3;CxtId=4;spln=X;X-HwB2bUaCookie=140;TRC=fff
fffff-a06>
Call-ID: [email protected]
From: <sip:[email protected];user=phone>;tag=73faaf4240d97fdd1addbfe376e06771
To: <sip:[email protected]>
CSeq: 1 INVITE
Max-Forwards: 69
Supported: 100rel
P-Asserted-Identity: <sip:[email protected]>
Contact: <sip:154.16.32.106:5060;lr;Dpt=75e8_16>
P-Charging-Vector: icid-value="5a57199e81633513591a1f0107f690a4.3523962093.242.11"
Session-Expires: 1800
Min-SE: 600
Served-Party-IP-Address: 154.81.24.21
Content-Length: 0

5-6: The S-CSCF obtains the pbxid parameter from the Route header field of the received
INVITE message, adds the parameter to an SAR message, and sends the message to the HSS.

For a registered number, the HSS has stored the pbxid parameter, and therefore the flow does not
include steps 5-6.
For an unregistered number, the S-CSCF must download subscriber data from the HSS.

7: The S-CSCF obtains the pbxid parameter value from the INVITE message received in 4,
adds the parameter to the first Route header field of an INVITE message, and sends the
INVITE message to the AS.
8-9: The originating AS downloads subscriber data and triggers services.

By default, the SNR message is used to subscribe to and download subscriber data from the HSS. The
processing mode is configured by running MOD SPCFG.

10-12: The subsequent flow is the same as the flow of a basic call.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 200

Terminating Call Flow

The following scenario describes the terminating call flow when a PBX subscriber originates
a call. The call flow for an unregistered PBX pilot number when the IP-PBX does not support
registration with the IMS domain is different from that for a registered PBX pilot number
when the IP-PBX supports registration with the IMS domain. Figure 2-30 shows the
terminating call flow when the IP-PBX does not support registration with the IMS domain.

Figure 2-30 Terminating call flow

The flow is as follows:

1: Upon receiving an INVITE message, the terminating I-CSCF sends an LIR message to the
HSS.
2: The HSS returns an LIA message to the I-CSCF.
For a registered number, the LIA message contains the Server-Name header field. In this
header field, the S-CSCF address mapping to the registered number contains the pbxid
parameter.
For an unregistered number, the LIA message returned by the HSS contains the
Server-Capabilities header field. This header field contains the preferred S-CSCF address
with the pbxid parameter.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 201

3: Upon receiving the LIA message, the I-CSCF processes the LIA message as follows:
For a registered number, the I-CSCF obtains the S-CSCF address (containing the pbxid
parameter) mapping to the registered number from the Server-Name header field of the
LIA message. Then, the I-CSCF routes the call to the corresponding S-CSCF.
For an unregistered number, the IBCF obtains the preferred S-CSCF address. This
address contains the pbxid parameter from the Server-Capabilities header field of the
LIA message. Then, the IBCF obtains the host name of the preferred S-CSCF, chooses an
appropriate S-CSCF based on the locally configured S-CSCF list, and routes the call to
the S-CSCF by sending an INVITE message that contains the pbxid parameter.
4-5: The S-CSCF obtains the pbxid parameter from the Route header field of the received
INVITE message, adds the parameter to an SAR message, and sends the message to the HSS.

For a registered number, the HSS has stored the pbxid parameter, and therefore the flow does not
include steps 4-5.
For an unregistered number, the S-CSCF must download subscriber data from the HSS.

6: The S-CSCF obtains the pbxid parameter value from the Route header field of the INVITE
message received in 3, adds the parameter to an INVITE message, and sends the message to
the terminating AS for triggering services.
7-8: The terminating AS downloads subscriber data and triggers services.

By default, the SNR message is used to subscribe to and download subscriber data from the HSS. The
processing mode is configured by running MOD SPCFG.

9-10: The S-CSCF obtains the pbxid parameter from the Route header field of the INVITE
message received in 3, adds the parameter to an INVITE message, and sends the message to
the IBCF.
11-13: The IBCF obtains the pbxid parameter value from the Route header field of the
INVITE message received from the S-CSCF, checks the route table for an available trunk, and
sends an INVITE message to route the call to the PBX. The subsequent flow is the same as
the flow of a basic call.

Enhancement
Table 2-31 lists the release history of the PBX Trunk Access Supported by the IBCF feature.

Table 2-31 Release history of the PBX Trunk Access Supported by the IBCF feature
Feature Version Release Version Details

01 CSC3300 V100R008C03 First release.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 202

2.4.9 SWP-CSCF-IBSP-022705_ENUM Query Supported by the

IBCF
Definition
The ENUM Query Supported by the IBCF service enables the interconnection border control
function (IBCF) to query the E.164 Number Mapping (ENUM) server and to convert a called
tel uniform resource identifier (URI) into a SIP URI based on the query result. In this way,
URI resources can be connected and used in a call addressed to an E.164 number. The ENUM
server is a distributed database that stores the mapping between tel URIs and SIP URIs.

Benefits
Table 2-32 describes the benefits of the ENUM Query Supported by the IBCF service.

Table 2-32 Benefits of the ENUM Query Supported by the IBCF service

For... Benefits
Carriers This service enables interworking between two IMS networks and
interworking between an IMS network and a non-IMS SIP network.
This enhances carrier competitiveness and provides new revenue
streams for carriers.
Subscribers None.

Availability
Table 2-33 describes the requirements for implementing the ENUM Query Supported by the
IBCF service.

Table 2-33 Requirements for implementing the ENUM Query Supported by the IBCF service

NE Version License Function

Requirements Description

IBCF CSC3300 This service is a The IBCF queries

V100R008C03 or basic service the ENUM server
later provided by the and performs route
CSC3300. A license analysis based on
is not required for the ENUM query
this service. result. Then the
IBCF routes the call
request to the next
hop based on the
route analysis result.

Impact on System
None.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 203

Constraints
None.

Interaction with Other Features

None.

Application
ENUM query is performed for enabling interworking between two IMS networks or
interworking between an IMS network and a non-IMS SIP network. When no device on the
originating network supports the ENUM query, the IBCF can query the ENUM server. It then
performs route analysis based on the ENUM query result and obtains the address of the next
hop.

Principles
Figure 2-31 shows the typical networking for implementing the ENUM Query Supported by
the IBCF service.

Figure 2-31 Typical networking for implementing the ENUM Query Supported by the IBCF
service

After receiving a call request, the IBCF queries the ENUM server and performs route analysis
based on the query result. Then the IBCF routes the call request to SIP network A or SIP
network B based on the route analysis result. In the example provided in Figure 2-31, the
IBCF routes the call request to SIP network A.
Figure 2-32 provides the message flow to illustrate how the IBCF queries the ENUM server
and determines the route for sending the call request.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 204

Figure 2-32 ENUM query flow of the IBCF

The flow is as follows:

1: An IMS subscriber initiates a call to +8675512345678. The IBCF receives an INVITE
message from the IMS network.
2: The IBCF uses the called prefix to query the ENUM/NP Query Policy for BCF table
(defined by running ADD BENUMNP) and detects that Enum or NP query indication is set
to ENUM. The IBCF then queries the ENUM server.
According to the ENUM protocol, the called number in the ENUM query message must be a
number with a domain name. Therefore, the IBCF converts +8675512345678 into a number
with a domain name before querying the ENUM server. In the existing mechanism, the IBCF
reverses digits in the called number, separates each two digits with a dot, and adds the value
of IMS ENUM sub-domain name after the last digit. IMS ENUM sub-domain name is
defined by running MOD BNA. This example assumes that IMS ENUM sub-domain name
is e164.arpa. Therefore, the called number +8675512345678 is converted into
8.7.6.5.4.3.2.1.5.5.7.6.8.e164.arpa.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 205

Main scenario: The ENUM server returns multiple results and the IBCF performs route
analysis based on the result of the highest priority.
3: The ENUM server returns naming authority pointer (NAPTR) records that map to the
called tel URI to the IBCF. Table 2-34 describes key fields in an NAPTR record.

Table 2-34 Key fields in an NAPTR record

Field Name Example Value Description

Order (Order) 1 This field specifies the
priority of the NAPTR
record. A smaller value
indicates a higher priority.
Preference (Priority) 1 This field specifies the
priorities of multiple
NAPTR records for which
the Order field is set to the
same value. A smaller value
indicates a higher priority.
Flag (Query flag) u The IBCF uses only NAPTR
records with this field set to
u. The value means that the
IBCF will match the called
number against the regular
expression and use the
syntax of the replacement
expression to replace the
called number.
Service (Service type) E2U+sip This field specifies the
format of the number into
which the called number
will be converted.
E2U+sip
The called number will
be converted into a SIP
URI.
E2U+tel
The called number will
be converted into a tel
URI.
Exe (Regular expression) (.*) The IBCF matches the
original called number
against the Regular
expression. The value (.*)
indicates that the NAPTR
record matches all called
numbers. For details about
the syntax of the regular
expression, see ADD
DNSE164.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 206

Field Name Example Value Description

RegExp (Replacement sip:+\[email protected] When the called number
expression) matches the syntax of the
regular expression, the IBCF
uses the syntax of the
replacement expression to
replace the called number.
The syntax of the
replacement expression is
similar to that of the regular
expression. For details, see
ADD DNSE164.

The NAPTR records returned by each ENUM server may differ depending on the server manufacturer.
Some ENUM servers return all NAPTR records that map to the called number at the same instant,
whereas others return NAPTR records one by one based on their priorities.

4: The IBCF converts the called number into [email protected] based on the
NAPTR record of the highest priority. Then the IBCF uses the domain name home1.com in
the converted SIP URI to query the domain name server (DNS). The query result indicates
that the call request should be routed to SIP network A. The IBCF sends the INVITE message
to SIP network A.
Branch scenario one: The ENUM server returns multiple NAPTR records. The IBCF
uses the record of the highest priority to perform route analysis but fails to route the
INVITE message accordingly. Then the IBCF uses the NAPTR record of the second
highest priority to perform route analysis and route the call request.
4a: The IBCF converts the called number based on the NAPTR record of the highest priority.
Then the IBCF uses the domain name home1.com in the converted SIP URI to query the
DNS. The query result indicates that the call request should be routed to SIP network A. The
IBCF sends the INVITE message to SIP network A.
5a: SIP network A returns an Oxx message notifying a routing failure.
6a: The IBCF converts the called number based on the NAPTR record of the second highest
priority. Then the IBCF performs route analysis and sends the INVITE message to SIP
network B based on the route analysis result.
Branch scenario two: The ENUM server returns NAPTR records one by one based on
their priorities. The IBCF receives the record of the highest priority, and uses it to
perform route analysis, but fails to route the INVITE message accordingly. Then the
IBCF queries the ENUM server again and routes the INVITE message as in the first
attempt.
4b: The IBCF converts the called number based on the NAPTR record of the highest priority.
Then the IBCF uses the domain name home1.com in the converted SIP URI to query the
DNS. The query result indicates that the call request should be routed to SIP network A. The
IBCF sends the INVITE message to SIP network A.
5b: SIP network A returns an Oxx message notifying a routing failure.
6b: The IBCF queries the ENUM server again.
7b: The ENUM server returns the NAPTR record of the second highest priority.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 207

8b: The IBCF converts the called number based on the received NAPTR record. Then the
IBCF performs route analysis. The IBCF sends the INVITE message to SIP network B based
on the route analysis result.

Billing and CDRs

None.

Software Parameters
None.

Specifications
None.

Compliance
Table 2-35 lists the standards with which the ENUM Query Supported by the IBCF service
complies.

Table 2-35 Standards with which the ENUM Query Supported by the IBCF service complies

Release
Table 2-36 lists the release history of the ENUM Query Supported by the IBCF service.

Table 2-36 Release history of the ENUM Query Supported by the IBCF service

Feature Version Release Version Details

02 IMS V200R008C02 The IBCF implements the ENUM query
function independently, and the I-CSCF
does not provide the IBCF function.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 208

Feature Version Release Version Details

01 IMS V200R006C03 This is the first release. The I-CSCF
provides the IBCF function to implement
ENUM query and routes call requests
based on the ENUM query result.

2.5 MI7S00ACCC00 Audio Conference Channels

Supported by the MRFC
2.5.1 RFC4240-Based Conference
Summary
The RFC4240-based conference function is also called CONF function. According to the
RFC4240 standard, the conference function is implemented on the Mr interface through the
CONF indicator carried in the Request-URI in the INVITE message.
The CSC3300 uses the conf-id carried in the CONF indicator to identify different
conferences.
If the conf-id carried in the CONF indicator is not present in the CSC3300, the CSC3300
applies for conference resources for this new session.
If the conf-id carried in the CONF indicator is already present in the CSC3300, the
CSC3300 adds this new session to the requested resources.
The RFC4240-based conference function supports audio conferences only.

Benefits
Table 2-37 describes the benefits of the RFC4240-Based Conference feature.

Table 2-37 Benefits of the RFC4240-Based Conference feature

Beneficiary Description
Carriers Carries can gain economic benefits from the
provisioning of these services.
Subscribers Subscribers can enjoy wireless audio conference
services.

Availability
Table 2-38 describes the requirements for implementing the RFC4240-Based Conference
feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 209

Table 2-38 Requirements for implementing the RFC4240-based Conference feature

Required NEs Required Version License Support

MRFC V100R001 or later This feature does not require
license support.
MRFP V100R001 or later A license is required for the
implementation of this
feature.
AS V100R001C02 or later A license is required for the
implementation of this
feature.

Dependency
Table 2-39 describes the interaction between the RFC4240-based conference function and
other functions.

Table 2-39 Interaction between the RFC4240-based Conference function and other functions

Related Features Interaction

MSML-based conference Mixing the RFC4240-based conference and the MSML-based
conference is not supported. That is, only one conference mode
is used for one conference.

Table 2-39 lists only the functions that are related to the RFC4240-based conference function.

Description
Introduction to CONF Indicator
The RFC4240-based conference function is implemented through the CONF indicator carried
in the INVITE message.

For details on the CONF indicator, refer to the RFC4240 protocol.

Specification for CONF Indicator

In RFC4240, the specifications for the CONF indicator are as follows:
CONF-URL = sip-ind conf-ind "=" instance-id "@" hostport [ uri-parameters ]
Where:
sip-ind= "sip:"/"sips:"
conf-ind= "conf"
instance-id= token
Example of CONF Indicator

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 210

The following gives an example of creating a conference with the ID "123":

INVITE sip:[email protected]
RFC4240-Based Conference Procedure
Figure 2-33 shows the RFC4240-based conference procedure.

The RFC4240-based conference function is triggered and controlled by the AS. The following message
flow is based on the interworking scenario of messages between the AS and the MRF being exchanged
through the S-CSCF. The message exchange between the AS and the S-CSCF is not shown in this figure.

Figure 2-33 RFC4240-based conference procedure

Creating Conference
The first subscriber is responsible for creating a conference. After the conference is created,
this subscriber joins the conference. The procedure for creating a conference is as follows:
1. The S-CSCF sends an INVITE to the MRFC. The Request-URI in the INVITE carries
the CONF indicator that carries the conference ID.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 211

2. For a new conference, the MRFC knows that the conference ID does not exist and then
performs the following actions:
− Create a conference.
If the conference is a new one, the MRFC records its ID and creates a corresponding
conference.
− Select an MRFP.
If the MRFC manages multiple MRFPs, it selects an MRFP according to the
configured resource allocation policy to serve the conference.
− Allocate conference resources.
The resources that can be used for a conference are restricted by the maximum
number of parties that the MRFP is configured to support. If the actual parties
participating in the conference exceed the limit, the subsequent access requests are
denied.
After resources are allocated, the MRFC sends an ADD_Request to the MRFP,
requesting the MRFP to create the conference and allocate bearer resources.
3. After the MRFP succeeds in performing the requested tasks, it sends an ADD_Reply to
the MRFC. Thus, the conference is created successfully.
4. The MRFC sends an ADD_Request to the MRFP, requesting the MRFP to add the
creator to the conference.
5. After the MRFP adds the creator to the conference, it sends an ADD_Reply to the
MRFC.
6. After receiving the ADD_Reply, the MRFC sends a 200 INVITE to the S-CSCF.
If the MRFC charging for conference service is configured, then, the conference
charging starts. There are two conference charging modes: individual charging and
uniform charging. The MRFC invokes a charging procedure based on the configured
software parameter.
7. The S-CSCF sends an ACK to the MRFC. Thus, the first subscriber succeeds in creating
and joining the conference.

The RFC4240-based conference procedure supports the optional precondition feature, 100rel feature,
and UPDATE procedure, which are omitted in the figure. For details about the procedure, see
RFC4240-based playing procedure.

Joining Conference
During a conference, the procedure for other participants to join the conference is as follows:
1. The S-CSCF sends an INVITE to the MRFC. The Request-URI in the INVITE contains
the CONF indicator that carries the conference ID.
2. Since the conference is already started, the MRFC knows that the conference ID is
present and then performs the following actions:
− Associate the subscriber with the conference.
The MRFC adds the newcomer to the conference with the associated conference ID.
− Select an MRFP.
The same MRFP will be selected to serve one conference according to the MRFP
selection policy.
− Allocate conference resources.
If sufficient resources are reserved when the conference is created, no more resources
need to be allocated.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 212

If the reserved resources are insufficient, a certain amount of conference resources

need to be re-allocated, and the amount depends on the AS or the increment
configured through a software parameter.
The MRFC sends an ADD_Request, instructing the MRFP to add the subscriber to the
conference.
3. After the MRFP adds the subscriber to the conference, it sends an ADD_Reply to the
MRFC.
4. After receiving the ADD_Reply, the MRFC sends a 200 INVITE to the S-CSCF. If the
individual charging mode is used, the procedure for charging this subscriber starts.
5. The S-CSCF sends an ACK to the MRFC. If the uniform charging mode is used, the
interim charging procedure starts.
Leaving Conference
The procedure in the case that the last participant leaves the conference is different from the
one in the case that other participants leave the conference. The two different procedures are
described as follows:
When a participant rather than the last participant leaves the conference, this participant
is deleted, but not the conference.
1. The S-CSCF sends a BYE to the MRFC. After receiving this message, the MRFC
performs the following actions:
− Process the charging.
If the individual charging mode is used, the procedure for charging this subscriber is
stopped. If the uniform charging mode is used, the interim charging procedure
continues.
− Release the MRFP resources.
The MRFP resources allocated to this subscriber are released.
− Delete the node for this subscriber.
The node associated with this subscriber is deleted.
2. The MRFC sends a 200 BYE to the S-CSCF.
3. The MRFC sends a SUB_Request, instructing the MRFP to delete the resources used for
this subscriber.
4. After deleting this subscriber, the MRFP sends a SUB_Reply to the MRFC.
When the last participant leaves the conference, this participant is deleted, and the
conference is also deleted.
1. The S-CSCF sends a BYE to the MRFC. After receiving this message, the MRFC
performs the following actions:
− Process the charging.
If the individual charging mode is used, the procedure for charging this subscriber is
stopped. If the uniform charging mode is used, an interim charging message is sent,
and then a charging termination message is sent to stop the charging procedure for the
conference.
− Release the MRFP resources.
The MRFP resources allocated to this subscriber are released.
− Delete the node for this subscriber.
The node associated with this subscriber is deleted.
− Delete the conference.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 213

The conference is deleted after the last participant leaves.

2. The MRFC sends a SUB_Request, instructing the MRFP to delete the resources used for
this subscriber.
3. The MRFC sends a 200 BYE to the S-CSCF.
4. After deleting this subscriber, the MRFP sends a SUB_Reply to the MRFC.
5. The MRFC sends a SUB_Request, instructing the MRFP to delete the resources used for
this conference.
6. After deleting the conference, the MRFP sends a SUB_Reply to the MRFC.

Enhancement
Table 2-40 lists the release history of the RFC4240-based Conference feature.

Table 2-40 Release history of the RFC4240-based Conference feature

History Version Details Release Plan

Initial release V100R001 - -

2.6 MI7SSDVCCC00 Video Conference Channels

Supported by the MRFC
2.6.1 MSML-Based Conference
Summary
The MSML-based conference function is based on the MSML standard and realized on the
Mr interface. It is implemented on the basis of the MSML conference control script carried in
the INFO message.
The MSML-based conference function supports audio conference and video conference.

Benefits
Table 2-41 describes the benefits of the MSML-Based Conference feature.

Table 2-41 Benefits of the MSML-Based Conference feature

Beneficiary Description
Carriers The MSML-based conference function can be
extended to multiple applications and can be
controlled flexibly. Carriers can gain economic
benefits from the provisioning of these services.
Subscribers The MSML-based conference function can be
extended to multiple applications and can be
controlled flexibly. Subscribers can enjoy rich

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 214

Beneficiary Description
multimedia services.

Availability
Table 2-42 describes the requirements for implementing the MSML-based Conference
function.

Table 2-42 Requirements for implementing the MSML-based Conference function

Required NEs Required Version License Support

Dependency
Table 2-43 describes the interaction between the MSML-based Conference function and other
functions.

Table 2-43 Interaction between the MSML-based conference function and other functions

Related Features Interaction

RFC4240-based Mixing the RFC4240-based conference and the MSML-based
Conference conference is not supported. That is, only one conference mode
is used for one conference.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 215

The MSML script uses a makeup language based on the XML. It uses SIP to set up sessions
and transport loads.
MSML Structure
MSML consists of MSML core package and MSML additional package. The MSML core
package provides the MSML framework only, without involving any services or features. The
MSML additional packages consist of dialog package, conference package, and audit package.
The dialog package and audit package can be extended to multiple application packages.
Figure 2-34 shows the MSML structure.

Figure 2-34 MSML structure

Introduction to Conference Core Package

Mixer
A mixer has multiple inputs that are combined in a media specific way to create a single
output. A conference must have an audio mixer or a video mixer. Each mixer contains a set of
attributes that defines how media streams are mixed in a conference.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 216

The elements that describe the mixer are as follows:

<audiomix>: defines the parameters for mixing audio media.
− It can define how many participants are included in the audio mix. For example, if the
value is 3, it indicates that 3 participants with the loudest voices are included in the
audio mix.
− It also enables notification of active speakers.
<videolayout>: defines the attributes of a video mix.
− It can define the attributes of the displayed window.
− It can define multiple panes for a displayed window.
− It can specify an algorithm for selecting a video stream for automatic playing.
These two elements can be included in the following elements as their contents:
<createconference>: used to define the initial mix attributes of a conference when they
are in the <createconference> element.
<modifyconference>: used to modify the mix attributes of the created conference when
they are in the <modifyconference> element.
<destroyconference>: used to delete a single mixer from a conference when they are in
the <destroyconference> element.
Media Stream
The <stream> element is used to describe media streams, which may be the streams flowing
between the conference and its participants or may be the streams flowing between the main
conference and its sidebar conferences or between sidebar conferences. <stream> is often
used as the child element of the <join> element. <stream> is used to:
Specify the type of the media stream, video stream or audio stream.
Specify the direction of the media stream.
Specify whether the audio streams will be mixed.
Specify the pane for playing the video streams.
Set the volume of audio streams or set the audio streams to "mute".
Conference Construction
Constructing a conference comprises the actions of creating, joining, leaving, modifying, and
deleting a conference. The following elements are used to describe the conference
construction:
<createconference>: used to create a conference.
− Its child element may be <audiomix> or <videolayout>, which is used to describe the
mix attributes of the audio or video conference.
− Its child elements <reserve> and <resource> are used to reserve resources for a
conference.
<join>: used to join a participant to a conference or create a sidebar conference.
− One or more media streams can be established between two independent objects.
− The media stream may be an audio stream or a video stream. It is unidirectional or
bidirectional.
− Its child element is <stream>. If no child element is contained, an audio and
bidirectional stream is established by default.
<unjoin>: used to leave a conference or delete a sidebar conference.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 217

− One or more media streams between two independent objects can be deleted. Its child
element is <stream>.
− If no child element is contained, all the media streams are deleted by default.
<modifyconference>: used to add or modify the attributes of an audio or video mixer
during a conference.
Example of MSML Conference Script
Example
Line 1:<?xml version="1.0" encoding="UTF-8"?>
Line 2: <msml version="1.1">
Line 3:<createconference name="Conf3422778567">
Line 4:<audiomix id="Audiomix11322">
Line 5:<n-loudest n="3"/>
Line 6:</audiomix>
Line 7:<videolayout id="Videolayout11322">
Line 8:<root size="CIF" background="white" />
Line 9:<region id="region1" left="0" top="0" size="1/4"/>
Line 10:<region id="region2" left="50%" top="0" size="1/4"/>
Line 11:<region id="region3" left="0%" top="50%" size="1/4">
Line 12:<region id="region4" left="50%" top="50%" size="1/4"/>
Line 13:</videolayout>
Line 14:</createconference>
Line 15:<join id1="conn:jd87dfg4h" id2="conf: Conf3422778567">
Line 16:<stream media="audio" dir="from-id1"/>
Line 17:<stream media="audio" dir="to-id1"/>
Line 18:<stream media="video" dir="from-id1" display="region2"/>
Line 19:<stream media="video" dir="to-id1"/>
Line 20:</join>
Line 21: </msml>
Explanation
Line 1: The MSML script is based on XML. The XML version is 1.0, and the encoding format
of the XML file is UTF-8.
Line 2: The MSML script starts. The version of the MSML script is 1.1.
Line 3: Create a conference with the name "Conf3422778567".
Line 4 to line 6: Create an audio mixer "Audiomix11322" with three loudest voices mixed.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 218

Line 7 to line 8: Create a video mixer "Videolayout11322" with common intermediate format
(CIF) as the window size and white as the background color.
Line 9 to line 13: Equally divide the window into four regions.
Line 14: Creating a conference script ends.
Line 15: Add a subscriber "jd87dfg4h" to the conference "Conf3422778567".
Line 16: Define audio streams flowing from subscribers to the conference.
Line 17: Define the audio streams flowing from the conference to subscribers.
Line 18: Define video streams flowing from subscribers to the conference, which is displayed
in region 2.
Line 19: Define video streams flowing from the conference to subscribers.
Line 20: Joining a conference script ends.
Line 21: The MSML script ends.
MSML-Based Conference Procedure
Two control modes are available for the MSML-based conference:
MSML-based conference without a control leg
In this mode, operations for controlling the conference (such as creating a conference
and playing an announcement during a conference) are performed through the subscriber
associated session.
Figure 2-34 shows the MSML-based conference procedure without a control leg in the
case that the Mp interface supports H.248.
MSML-based conference with a control leg
In this mode, the AS creates a session for a virtual subscriber, that is, MRFP resources
need not be allocated. Operations for controlling the conference are performed through
the virtual subscriber associated session (that is, conference control leg).
Figure 2-35 shows the MSML-based conference procedure with a control leg in the case
that the Mp interface supports H.248.

The MSML-based conference function is triggered and controlled by the AS. The following message
flow is based on the interworking scenario of messages between the AS and the MRF being exchanged
through the S-CSCF. The message exchange between the AS and the S-CSCF is not shown in this figure.

MSML-Based Conference Without a Control Leg

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 219

Figure 2-35 MSML-based conference procedure without a control leg

Creating Conference

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 220

A conference is created by the first subscriber. The procedure is as follows:

1. The S-CSCF sends an INVITE to the MRFC.
− For an MSML-based audio conference, the conference ID is carried in
msml-audio-confin the INVITE.
− For an MSML-based video conference, the conference ID is carried in
msml-video-conf in the INVITE.
2. The MRFC sends an ADD_Request, instructing the MRFP to set up a termination for the
subscriber.
3. After successfully creating a termination, the MRFP sends an ADD_Reply to the MRFC.
4. The MRFC sends a 200 to the S-CSCF in response to the INVITE.
5. The S-CSCF sends an ACK to the MRFC. Thus, the session is set up successfully.
6. The S-CSCF sends an INFO to the MRFC. This message carries the MSML script,
which indicates that a conference will be created and the first participant will join the
conference.
7. When the MRFC resolves the MSML script, it changes the conference creation indicator
to a ADD_Request and sends this message to the MRFP.
8. After the MRFP creates the conference, it returns an ADD_Reply to the MRFC.
9. The MRFC sends a MOVE_Request to the MRFP, instructing the MRFP to join the first
participant to the conference.
10. The MRFP joins the first participant to the conference and then sends a MOVE_Reply to
the MRFC.
11. The MRFC encodes the results into an MSML script, which is then encapsulated into a
200 INFO and sent to the S-CSCF.
Conference in Progress
When another participant wants to join the conference, similar to the conference creation
procedure, a termination is created for the subscriber through the INVITE procedure, and then
the subscriber is added to the conference through the INFO procedure. The procedure is as
follows:
1. When a subscriber wants to join the conference, the S-CSCF sends an INVITE to the
MRFC. The Request-URI in the INVITE carries the conference ID. This conference ID
is the same as that used for creating the conference.
2. The MRFC sends an ADD_Request, instructing the MRFP to set up a termination for the
subscriber.
3. After successfully creating a termination, the MRFP sends an ADD_Reply to the MRFC.
4. The MRFC sends a 200 to the S-CSCF in response to the INVITE.
5. The S-CSCF sends an ACK to the MRFC.
6. The S-CSCF sends an INFO to the MRFC. This message carries the MSML script,
indicating addition of the subscriber to the conference.
7. When the MRFC resolves the MSML script, it changes the indicator to a
MOVE_Request and sends this message to the MRFP.
8. The MRFP adds the subscriber to the conference and sends a MOVE_Reply to the
MRFC.
9. After receiving the MOVE_Reply, the MRFC encodes the results into an MSML script,
which is then encapsulated into a 200 INFO and sent to the S-CSCF.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 221

During the conference (steps 10 to 13), the S-CSCF, if necessary, can send the INFO several
times to deliver the MSML script to the MRFC. The MRFC resolves the script and sends a
MOD_Request based on the contents of the script to control the MRFP in performing the
following functions:
The announcement and DTMF collection interact in the conference process.
A welcome announcement is played when participants join the conference.
Voices of the participants are recorded.
The mute operation is enabled or disabled for the participants.
The video or audio function is enabled or disabled for a participant in the video
conference.
The video switching mode is changed in the video conference.
Stopping Conference
When all the participants leave the conference, the conference is terminated. The procedure is
as follows:
1. When a subscriber leaves the conference, the S-CSCF sends a BYE to the MRFC.
2. After receiving the BYE, the MRFC releases the resources used for the subscriber. Then
it sends a SUB_Request, requesting deletion of the endpoint for the subscriber.
3. After releasing resources, the MRFC sends a 200 BYE to the S-CSCF.
4. After the MRFP releases resources used for the subscriber, it sends a SUB_Reply to the
MRFC.

The procedure is the same for each participant to leave the conference. The figure only shows the
procedure when one participant leaves the conference.
5. When the last participant leaves the conference, the MRFC judges that no participant is
in the conference and then sends a SUB_Request to the MRFP, requesting deletion of the
conference.
6. After the MRFP deletes the conference, it returns a SUB_Reply to the MRFC.
MSML-Based Conference with a Control Leg

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 222

Figure 2-36 MSML-based conference procedure with a control leg

Creating Conference
A bearer-free conference control leg is first created. Then a conference is created through this
conference control leg. The procedure is as follows:
1. The S-CSCF sends an INVITE to the MRFC.
− For an MSML-based audio conference, the conference ID is carried in
msml-audio-conf in the INVITE.
− For an MSML-based video conference, the conference ID is carried in
msml-video-conf in the INVITE.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 223

2. The MRFC judges that a conference control session is created through the SDP
information in the INVITE and returns a 200 INVITE response to the S-CSCF.
3. The S-CSCF sends an ACK to the MRFC. Thus, a conference control leg is created
successfully.

Offline charging is required for the conference control leg.

4. The S-CSCF sends an INFO through the conference control leg. The INFO carries the
MSML script, instructing the MRFC to create an MSML-based conference. The
conference ID and attribute (audio or video) in the INFO are the same as those in the
INVITE appeared in step 1.
5. The MRFC resolves the MSML script and converts the conference creation indicator to
an ADD_Request, which is then sent to the MRFP.
6. After the conference creation, the MRFP returns an ADD_Reply to the MRFC.
7. The MRFC encodes the results into an MSML script, which is then encapsulated into a
200 INFO and sent to the S-CSCF.
Conference in Progress
After a conference is created, subscribers join the conference successively. The procedure is
the same as that described in step 1 to step 9 in Conference in Progress of "MSML-Based
Conference Without a Control Leg".
During the conference, the AS controls the conference through the conference control leg,
such as playing an announcement. The procedure is described in step 1 to step 10:
1. The S-CSCF sends an INFO through the conference control leg. The message carries the
MSML script, indicating an announcement to the conference.
2. The MRFC resolves the MSML script and converts the announcement indicator to an
MOD_Request, which is then sent to the MRFP.
3. The MRFC returns a 200 INFO to the S-CSCF.
4. The MRFP starts the announcement and returns a MOD_Reply to the MRFC.
5. After the announcement is played, the MRFP sends a NOTIFY_Request to inform the
MRFC of the completion of the announcement.
6. The MRFC encodes the results into an MSML script, which is then encapsulated into an
INFO and sent to the S-CSCF.
7. The MRFC returns a NOTIFY_Reply to the MRFP.
8. The S-CSCF returns a 200 INFO to the MRFC.
9. The MRFC sends a MOD_Request, instructing the MRFP to stop the announcement.
10. The MRFP returns a MOD_Reply to the MRFC.
The procedure for each subscriber leaving the conference is the same as that described in
step 1 to step 4 in Stopping Conference of "MSML-Based Conference Without a Control
Leg".
Different from the MSML-based conference without a control leg, when the last
subscriber leaves the conference, the MRFC does not delete the conference, but sends an
INFO to the AS. The procedure is described in step 11 to step 12:
11. When the MRFC judges that no participants are present in the conference, it sends an
INFO to the S-CSCF through the conference control leg. The message carries the MSML
script to report the msml.conf.nomedia event.
12. The S-CSCF returns a 200 INFO to the MRFC.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 224

In the case that the conference has no participants, but is not deleted, the AS cannot create this
conference again, but can add subscribers to the conference through the control leg. The
procedure for subscribers to join the conference is the same as that described in step 1 to step
9 in Conference in Progress of "MSML-Based Conference Without a Control Leg".
Stopping Conference
When the last subscriber leaves the conference and the AS deletes the conference control leg,
the MRFC will delete the conference.
The procedure for each subscriber leaving the conference is the same as that described in step
1 to step 4 in Stopping Conference of "MSML-Based Conference Without a Control Leg".
The deleting conference procedure is as follows:
1. When the MRFC judges that no participants are present in the conference, it sends an
INFO to the S-CSCF. The message carries the MSML script to report the
msml.conf.nomedia event.
2. The S-CSCF returns a 200 INFO to the MRFC.
3. The S-CSCF sends a BYE, instructing the MRFC to delete the conference control leg.
4. The MRFC sends a SUB_Request, instructing the MRFP to delete the conference.
5. After deleting the conference control leg, the MRFC returns a 200 BYE to the S-CSCF.
6. After deleting the conference, the MRFP returns a SUB_Reply to the MRFC.

Enhancement
Table 2-44 lists the release history of the MSML-based Conference feature.

Table 2-44 Release history of the MSML-based Conference feature

History Version Details Release Plan

Second release V100R008C01 The MSML-based -
conference supports
conference quality
audit.
Initial release V100R001 - -

2.7 MI7S00ATCC00 MRFC Audio transcoding Channels

Availability
Table 2-45 describes the requirements for implementing the Audio Transcoding feature.

Table 2-45 Requirements for implementing the Audio Transcoding feature

Required NEs Required Version License Aupport

MRFC V100R001 or later This feature requires license
support.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 225

Required NEs Required Version License Aupport

MRFP V100R001 or later A license is required for the
implementation of this
feature.
AS V100R001C02 or later A license is required for the
implementation of this
feature.

Summary
The audio transcoding function is implemented on the Mr interface through the TC indicator
carried in the Request-URI in the INVITE message.
The CSC3300 uses the tc-id carried in the TC indicator to identify different sessions.
If the tc-id carried in the TC indicator is not present in the CSC3300, the CSC3300
applies for a transcoding resource for this new session.
If the tc-id carried in the TC indicator is already present in the CSC3300, the CSC3300
adds this session to the requested transcoding resources.

Benefits
Table 2-46 describes the benefits of the Audio Transcoding feature.

Table 2-46 Benefits of the Audio Transcoding feature

Beneficiary Description
Carriers Carriers can use this function to raise the call
completion rate, win high customer satisfaction, and
obtain better proceeds.
Subscribers With the audio transcoding function, a user terminal
is not required to support all codecs to communicate
with other user terminals that support various
codecs.

Description
Introduction to TC Indicator
The audio transcoding function is implemented to associate calling and called parties through
the tc-id carried in the TC indicator.
Specification for TC Indicator
The TC indicator is carried in the Request-URI in the INVITE message. The specifications for
the TC are as follows:
TC-URL = sip-ind tc-ind "=" tc-id"@" hostport [ uri-parameters ]"

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 226

Where:
sip-ind= "sip:"/"sips:"
tc-ind= "tc"
tc-id= token
Example of TC Indicator
To set up a audio transcoding session, the tc-id is 00000001HuaweiImsAsTc3422778567.
INVITE sip:[email protected]
Description of Media Transcoding
The audio transcoding function can enable the subscribers that support different codecs to
communicate.
When a session is set up between subscriber A and subscriber B, they fail to communicate
directly if the codecs supported are different. A audio transcoding resource must exist between
subscriber A and subscriber B, which can implement the transcoding between codec 1
supported by subscriber A and codec 2 supported by subscriber B.Figure 2-37 shows this
transcoding procedure.

Figure 2-37 Media transcoding procedure

During the session setup between subscriber A and subscriber B, the MRFC associates
subscriber A with subscriber B by setting up a audio transcoding resource between them. The
associated is performed based on the TC indicator.
1. When subscriber A calls subscriber B, the TC indicator is carried in the request message
sent by calling subscriber A for setting up a session. The TC indicator carries the tc-id.
When the MRFC determines that the tc-id is new, it applies for a audio transcoding
resource for subscriber A.
2. When the MRFC determines that the tc-id carried in the request message sent by called
subscriber B for setting up a session is the same as that carried for calling subscriber A, it
adds the tc-id to the requested audio transcoding resources. Thus, the relations between
subscriber A, subscriber B, and audio transcoding resources are established.
Media Transcoding Procedure
To implement the audio transcoding function, the Mp interface can support only the H.248
protocol.
Figure 2-38 shows the audio transcoding procedure.

The audio transcoding function is triggered and controlled by the AS. The following message flow is
based on the interworking scenario of messages between the AS and the MRF being exchanged through
the S-CSCF. The message exchange between the AS and the S-CSCF is not shown in this figure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 227

Figure 2-38 Media transcoding Procedure

Calling Party Applying for the TC Resource

To set up a audio transcoding session, the calling party first applies for the TC resource. The
procedure for applying for the TC resource is as follows:
1. The S-CSCF sends an INVITE to the MRFC. The Request-URI in the INVITE contains
the TC indicator that carries the tc-id.
2. When the MRFC finds that the tc-id does not exist, it saves the tc-id. Meanwhile, it
selects an appropriate MRFP based on the codec type carried in the message, sends an
ADD_Request that carries the codec type of the calling party to the MRFP, and indicates
the MRFP to set up a calling termination.
3. After successfully setting up the termination, the MRFP sends an ADD_Reply to the
MRFC.
4. The MRFC sends a 200 INVITE to the S-CSCF in response to the INVITE. Then, the
charging on the calling party starts.
5. The S-CSCF sends an ACK to the MRFC. Hence, requesting resources for the calling
party is successful.
Called Party Applying for the TC Resource
After the calling party applies for the resources, the called party applies for the resources. The
procedure is as follows:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 228

1. The S-CSCF sends an INVITE to the MRFC. The Request-URI in the INVITE contains
the TC indicator that carries the tc-id. The tc-id is the same as that used for requesting
the TC resource for the calling party.
2. When the MRFC finds that the tc-id exist, it sends an ADD_Request that carries the
codec type of the called party to the MRFP, instructing the MRFP to set up a called
termination and associate this termination with the calling termination.
3. After the called termination is successfully set up and the context is successful, the
MRFP sends an ADD_Reply to the MRFC.
4. The MRFC sends a 200 INVITE to the S-CSCF in response to the INVITE. Then, the
charging on the called party starts.
5. The S-CSCF sends an ACK to the MRFC. Hence, requesting resources for the called
party is successful, and the calling and called party are associated.
Releasing the MRFP Resources
The TC resources of the calling and called parties are separately released by the AS through
BYE messages, and their release procedures are the same. When the calling or called party
exits a session, the procedure is as follows:
1. The S-CSCF sends a BYE to the MRFC.
2. The MRFC sends a SUB_Request, instructing the MRFP to delete the associated
terminations. If the MRFC finds that the two sessions associated with the TC are
released, it releases its own resources. Meanwhile, the MRFC indicates the MRFP to
delete this context.
3. After the operation is successful, the MRFP returns a SUB_Reply to the MRFC.
4. The MRFC sends a 200 BYE to the S-CSCF.

Enhancement
Table 2-47 lists the release history of the Audio Transcoding feature.

Table 2-47 Release history of the Audio Transcoding feature

History Version Details Release Plan

Initial release V100R001 - -

Dependency
This feature does not have any interaction with other features.

2.8 MI7SHDVCCC00 High Definition Video Conference

Channels Supported by the MRFC
The MRFC cooperates with the MCU to provide the HD video conference function.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 229

2.8.1 Cooperating with the MCU to Provide the HD Video

Conference Function
Availability
This feature is introduced in CSC3300 V100R006.

Summary
The MRFC controls the MCU to provide the HD video conference function.
The HD video conference features a video resolution of 720 pixels or 1080 pixels, and
supports AAC-LD broadband voices to achieve the CD-level effect.
The HD video conference provides data flow with a resolution of 1280 x 1024 pixels.
The HD video conference function provides split screen in 9 different modes and enables up
to 16 conference parties located at different conference sites to be displayed at the same time
on the screen.

Benefits
By deploying the HD video conference system, carriers can increase sales revenues, expand
valuable customer base, build up service brands, and enlarge business scopes.
Subscribers can enjoy the carrier-class and convergent conference service (voice, data, and
video), save costs on the construction and maintenance of a conference system, and reduce the
expenditure on business trips.

Description
Figure 2-18 shows the interfaces used for interworking between NEs in the IMS-based HD
video conference solution:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 230

Figure 2-39 Interfaces used for interworking between NEs in the IMS-based HD video conference
solution

Interface 1: This is a SIP interface between the conference terminal and the IMS Core.
The conference terminal must provide the basic functions of an IMS terminal, such as
registering with the IMS network and originating/terminating an audio and video call.
Interface 2: This is an ISC interface between the MediaX3600 (a conference AS) and the
S-SCSF. The S-CSCF triggers a conference call to the MediaX3600 according to the IFC
rules.
Interface 3: This is an open SOAP interface provided by the MediaX3600, based on
which the Web Portal is developed. Carriers or the third-parties can also develop their
own Portals and applications based on SOAP.
Interface 4: This is an Mr interface between the MediaX3600 and the MRFC, which
helps the MRFC provide the HD video conference function.
Interface 5: This is a private SIP interface between the MRFC and the MCU for call
control management. Through the SIP interface, the MRFC connects calls to the MCU
for session management of all participants. The operations of attending and exiting a
conference are controlled through the SIP interface.
Interface 6: This is a private TCP interface between the MRFC and the MCU for
conference site control. The TCP interface is used to create, modify, and release a
conference endpoint and a conference.
Figure 2-19 shows the procedure for creating and attending an HD video conference.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 231

Figure 2-40 Creating and attending an HD video conference

The message flow is as follows:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 232

1. The MediaX3600 sends an INVITE message to the MRFC, instructing the MRFC to
create an HD video conference. The MRFC selects a proper MCU, deducts the required
conference resources from the total resources, and sends a conference creation message
to the MCU. Based on the conference resource requirements, the MCU reserves the
resources, creates the HD video conference, and returns a creation success message,
which is finally forwarded to the MediaX3600. Thus, the conference is created
successfully.
2. A subscriber dials the conference access code. Upon receiving the INVITE message
from the subscriber, the MediaX3600 determines that the subscriber needs to be added to
the conference and transparently transmits the INVITE to the MRFC. Based on the SDP
contained in the message, the MRFC instructs the MCU to create an endpoint for the
subscriber, and, after receiving the creation success message, transparently transmits the
INVITE to the MCU. The MCU associates the subscriber call with the endpoint. Thus,
the subscriber attends the conference.
3. After the subscriber attends the conference, the MediaX3600 authenticates the subscriber
in the following manner: The MediaX3600 sends an INFO to the MRFC, instructing the
MRFC to play an announcement to the subscriber and obtain the DTMF digits of the
subscriber. The MRFC delivers the announcement playing and DTMF collection
messages to the MCU through the TCP interface, instructing the MCU to play
announcements and perform DTMF collection. Following the announcement instruction,
the subscriber enters the conference password. The MCU reports the password to the
MRFC. The MRFC encapsulates the password in an INFO and sends the INFO to the
MediaX3600 for authentication. After the authentication is passed, the MediaX3600
instructs the MRFC to add the subscriber to the conference. Through the TCP interface,
the MRFC instructs the MCU to add the subscriber to the conference. After the
subscriber is added to the conference, the MediaX3600 instructs the MRFP to play an
announcement, indicating that the operation is successful.
Figure 2-20 shows the procedure for the HD video conference control.

Figure 2-41 HD video conference control

The message flow is as follows:

1. During the conference, a subscriber can control the conference through the Portal. For
example, the subscriber can mute or unmute other subscribers and change the display
mode. The preceding figure takes the mute procedure as an example. Other conference
control procedures are similar to this procedure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 233

2. When the subscriber selects to mute a terminal, the MediaX3600 sends an INFO to the
MRFC. The MRFC sends a mute request to the MCU through the TCP interface. The
MCU mutes the terminal and reports a mute success message to the MRFC. The MRFC
returns a 200 for INFO to the MediaX3600.The unmute procedure is similar to the mute
procedure.
Figure 2-21 shows the procedure for ending an HD video conference.

Figure 2-42 Ending an HD video conference

The message flow is as follows:

1. The MediaX3600 determines that the end time of the conference is approaching and
sends an INFO to the MRFC.
2. The MCU plays an announcement under the instruction of the MRFC.
3. When the end time is reached, the MediaX3600 sends a BYE to each UE and the MRFC
to release the participants.
4. The MCU releases the participants under the instruction of the MRFC.
5. The MediaX3600 sends a BYE through the control leg. The MRFC determines that the
MediaX3600 ends the conference, sends a conference ending request to the MCU, and
releases all the resources of the conference.
6. The MCU ends the conference and releases all the resources of the conference.

Enhancement
None

Dependency
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 234

2.9 MI2S00TVCC00 Telepresence Conference Channels

Supported by the MRFC
2.9.1 Cooperating with the MCU to Provide the Telepresence
Video Conference Function
Availability
This feature is introduced in CSC3300 V100R008.

Summary
The MRFC controls the MCU to provide the telepresence video conference function.
The telepresence video conference features a video resolution of 720 pixels or 1080 pixels,
and 30 frames.
The telepresence video conference supports AAC-LD broadband voices to achieve the
CD-level effect.
The telepresence video conference provides data flow with a resolution of 1280 x 1024 pixels.
The telepresence video conference function provides split screen in 9 different modes and
enables up to 16 conference parties located at different conference sites to be displayed at the
same time on the screen.

Benefits
For carriers
By deploying the telepresence video conference system, carriers can increase sales
revenues, expand valuable customer base, build up service brands, and enlarge business
scopes.
For subscribers
With this feature, participants of the conference see true-to-life images of each other by
viewing the screen, and thus are able to have eye-ball contact with one another. Gestures
and other indicating activities are beheld. That is, participant attending the conference
are able to discuss with each other as in a face-to-face talk. The luminance, contrast and
saturation are set the same on all display devices. The images displayed on the devices
are explicit and natural with a minimum resolution of 720 pixels (30 frames). This
feature also highlights the explicit desktop data transmission for sound communications.

Description
The interfaces involved in the IMS telepresence video conference solution are the same as
those in the 2.26 .

Enhancement
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 235

Dependency
None

2.10 MI2SSCSCMP00 CSC3300 P-CSCF Message

Processing
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The P-CSCF supports message-related transaction processing and forwarding of the
MESSAGE response.

Benefits
For subscribers
This feature enables subscribers to enjoy the MESSAGE service.
For carriers
This feature enables carriers to provide the MESSAGE service.

Description
Subscribers can send and receive the MESSAGE message only after being successfully
registered.
The P-CSCF supports MESSAGE compression processing.
The P-CSCF supports MESSAGE IPSec feature.
The P-CSCF determines whether to generate event bills for the MESSAGE message
through the MOD PCHP command on the OMU.

Enhancement
None

Dependency
None

2.11 MI2SPCSCMP00 CSC3300 S-CSCF Message

Processing
Availability
This feature is introduced in CSC3300 V100R002.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 236

Summary
The S-CSCF supports transaction processing of the MESSAGE type.

Benefits
For subscribers
This feature enables subscribers to enjoy the SMS service in the IMS network.
For carriers
This feature enables carriers to provide the SMS service in the IMS network.

Description
The IMS message types are classified as follows:
-- Instant message
-- Session-based message
Instant message:
If messages are exchanged between the caller and the callee almost in real time, the messages
are called instant messages. The UE generates a message request and fills the request with
required contents (for example, texts). Then, the IMS network forwards the request (in the
same way of forwarding the INVITE request) till the request reaches the target UE.
During the SMS processing, the S-CSCF triggers the service based on the initial filtering
criterion (iFC), which is similar to the process of setting up a call through the INVITE
message.

Session-based message:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 237

Session-based message refers to the message that is sent during an session. For this type of
message, message contents are mainly short texts. The process is the same as that of sending a
MESSAGE message after the call is set up through the INVITE message; therefore, this
document does not describe the process.

Enhancement
None

Dependency
None

2.12 MI2SPCSCPP00 CSC3300 P-CSCF Presence

Processing
Availability
This feature is introduced in CSC3300 V100R002.

Summary
This feature enables the P-CSCF to support the forwarding of the presence-related messages
such as the PUBLISH, SUBSCRIBE, and NOTIFY.

Benefits
For subscribers
This feature enables subscribers to enjoy the presence service.
For carriers
This feature enables carriers to provide the presence service.

Description
After the successful registration, the subscriber sends a PUBLISH message to the
P-CSCF to publish subscriber status. The P-CSCF forwards the PUBLISH requests and
responses between the terminal and the S-CSCF.
The subscriber sends the SUBSCRIBE message to subscribe presence status of another
subscriber. The P-CSCF forwards the SUBSCRIBE requests and responses between the
terminal and the S-CSCF.
The Presence AS sends the NOTIFY message to notify presence status of the subscriber.
The P-CSCF forwards the NOTIFY requests and responses between the terminal and the
S-CSCF.

Enhancement
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 238

Dependency
None

2.13 MI2SSCSCPP00 CSC3300 S-CSCF Presence

Processing
Availability
This feature is introduced in CSC3300 V100R002.

Summary
The S-CSCF supports the presence service, such as the subscription, publishing, and
notification of subscriber online status.

Benefits
For subscribers
This feature enables subscribers to enjoy the presence service in the IMS network.
For carriers
This feature enables carriers to provide the presence service in the IMS network.

Description
The presence service in the IMS network is implemented as follows:
Subscriber A subscribes the status of subscriber B.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 239

Subscriber B publishes its status to the online server.

The online server notifies subscriber A of the status of subscriber B.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 240

During the subscription and publishing of subscriber status, the S-CSCF triggers the service
based on the iFC, which is similar to the process of setting up a call through the INVITE
message.

Enhancement
None

Dependency
None

2.14 MI2S0PCSRX00 Policy Control Support(Rx)

Availability
This feature is introduced in CSC3300 V100R003.

Summary
When serving as CSCF, the CSC3300 supports the Rx interface. Through the Rx interface, the
CSCF interacts with the Policy and Charging Rules Function (PCRF) to control the Charging
Enforcement Function (PCEF) to achieve user-plane QoS control and charging policy control
in the 3GPP Policy and Charging Control (PCC) architecture.

Benefits
For subscribers
The media QoS of subscribers are guaranteed and the charging policies can be
customized.
For carriers
Carriers can provide diversified, flexible PCC-capable QoS control and charging policies
for different access modes, such as GPRS, DOCSIS, xDSL, WiMAX, and 3GPP2.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 241

Description
Application scope of the Rx interface
The Rx interface is located between the CSCF (AF) and the PCRF for exchanging the
application level session information.

Basic Rx-related procedures

The CSC3300 supports the following basic procedures according to 3GPP PCC:
− Initial session establishment
The P-CSCF sends an AAR to request binding of bearer QoS policies and charging
policies during the initial offer/answer exchange.
Based on the SDP offer, the P-CSCF includes the Service-Info-Status AVP with the
value set to PRELIMINARY SERVICE INFORMATION in the AAR sent to the
PCRF for authentication check. Later, when the SDP answer is received, the P-CSCF
includes the Service-Info-Status AVP set to FINAL_SERVICE_INFORMATION in
the AAR to request the PCRF to authorize the session and provide the PCC rules to
the PCEF.
− Session update
If the media are altered (added, modified, or removed) during subsequent
offer/answer renegotiation, the P-CSCF sends an AAR to update the bearer QoS
policies and charging policies for the UE.
− Session release
The P-CSCF can send an STR message to release the bearer resources when
receiving a BYE request at the end of a session or an Oxx (3xx/4xx/5xx/6xx) for
INVITE during session establishment.
− Bearer event reporting
The PCRF can send RAR messages to the P-CSCF to report bearer plane events such
as SERVICE_INFORMATION_REQUEST,
CHARGING_CORRELATION_EXCHANGE,
INDICATION_OF_LOSS_OF_BEARER,

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 242

INDICATION_OF_RECOVERY_OF_BEARER,
INDICATION_OF_RELEASE_OF_BEARER,
INDICATION_OF_ESTABLISHMENT_OF_BEARER, and IP-CAN_CHANGE.
When receiving an ASR from the PCRF, indicating that all bearers of a session are
abnormal, the P-CSCF sends a BYE message to release the session.
− Gate processing
If early media is required, the P-CSCF opens the gate for early media when receiving
the 1xx for INVITE. If early media is not required, the P-CSCF opens the gate for
user media when receiving the 2xx for INVITE. Later, the P-CSCF updates the gate
status in accordance with the updates in media.
Emergency call
The P-CSCF may include the Service-URN AVP to indicate an emergency call.
Forking over the Rx interface
In the case of forking, the P-CSCF delivers the value SEVERAL_DIALOGUES in the
AAR to indicate forking. When forking is complete, the P-CSCF delivers the value
SINGLE_DIALOGUE to instruct the PCRF to update the media information based on
the connected forking leg.
Many-to-many relationship between the P-CSCF and the PCRF
Multiple P-CSCFs can communicate with multiple PCRFs through the Rx interface. The
P-CSCF selects the PCRFs in turn. When an AAR to one PCRF fails, the P-CSCF selects
another PCRF.

Enhancement
The Rx interface supported by CSC3300 V100R003 complies with 3GPP 29214-110.
The Rx interface supported by CSC3300 V100R006 complies with 3GPP 29214-730.

Dependency
None

2.15 MI2S0PCSGQ00 Policy Control Support(Gq')

Availability
This feature is introduced in CSC3300 V100R002.

Summary
When serving as a CSCF, the CSC3300 supports the Gq' interface. The Gq' interface allows
the CSCF to interact with the Service Policy Decision Function (SPDF) to control the
BGF/RCEF to implement user-plane NAT control, QoS control, and resource and admission
control.

Benefits
For subscribers
The media QoS of subscribers is guaranteed.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 243

For carriers
Carriers allow the subscribers to access the network in different modes (through public
networks, private network, or overlapping addresses) and have the QoS of different
levels (user level/equipment level/network level) under control.

Description
Application scope of the Gq' interface
The Gq' interface is located between the CSCF (AF) and the SPDF for exchanging the
application level session information.

Basic Gq'-related procedures

The CSC3300 supports the following basic Gq'-related procedures according to TISPAN
R2:
− Initial session establishment
The P-CSCF sends an AAR to implement media NAT and QoS processing to
complete the bear mapping and binding during the initial offer/answer exchange.
− Session update
If the media are altered (added, modified, or removed) during subsequent
offer/answer renegotiation, the P-CSCF sends an AAR to update the media NAT and
QoS information for the UE.
− Session release
The P-CSCF can send an STR message to release the bearer resources when
receiving a BYE request at the end of a session or an Oxx (3xx/4xx/5xx/6xx) for
INVITE during session establishment.
− Bearer event reporting
The SPDF can send RAR messages to the P-CSCF to report bearer plane events such
as LOSS_OF_BEARER, RECOVERY_OF_BEARER, RELEASE_OF_BEARER,
SUBSCRIBER_DETACHMENT, and RESERVATION_EXPIRATION.
When receiving an ASR from the SPDF, indicating that all bearers of a session are
abnormal, the P-CSCF sends a BYE message to release the session.
The P-CSCF disables media plane interruption check when a call is placed on hold.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 244

− Gate processing
If early media is supported, the P-CSCF opens the gate for early media when
receiving the 1xx for INVITE. If early media is not required, the P-CSCF opens the
gate for user media when receiving the 2xx for INVITE. Later, the P-CSCF updates
the gate status in accordance with the updates in media.
− Hosted-NAT
On a network with hosted NAT, the P-CSCF delivers a latching/relatching indication
in the AAR to instruct the BGF to latch to the first incoming packet.
− Access from overlapping addresses
To support the media NAT for subscribers using the overlapping addresses, the
P-CSCF uses the combination of domain name and IP address to identify a
subscriber.
Forking over the Gq' interface
In the case of forking, the P-CSCF delivers the value SEVERAL_DIALOGUES in the
AAR to indicate forking. When forking is complete, the P-CSCF delivers the value
SINGLE_DIALOGUE to instruct the SPDF to update the media information based on
the connected forking leg.
Configurable NAT and QoS control
The NAT and QoS control over the Gq' interface can be configured based on the
granularity of access network or P-CSCF.
Many-to-many relationship between the P-CSCF and the SPDF
Multiple P-CSCFs can communicate with multiple SPDFs through the Gq' interface. The
P-CSCF selects the SPDFs in turn. When an AAR to one SPDF fails, the P-CSCF selects
another SPDF.
Equipment resource verification
The P-CSCF supports two resource reservation modes: hard-state and soft-state. In a
soft-state reservation, the P-CSCF includes the Authorization-Lifetime AVP in the AAR
to perform session resource verification.

Enhancement
The Gq' interface supported in CSC3300 V100R002 complies with TISPAN R1 and supports
QoS related processing.
The Gq' interface supported in CSC3300 V100R005 complies with TISPAN R2 and supports
QoS and NAT related processing.
The Gq' interface supports equipment resource verification from CSC3300 V100R006
onwards.

Dependency
None

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 245

2.16 MI2S0PCSMM00 Policy Control Support (Cable)

Definition
A cable network (cable television network) can provide telephony services, cable television
services, and digital and IP-based services (including digital television and Internet broadband
access). End users can access the IP Multimedia Subsystem (IMS) from the cable network.
The Policy Control Support (Cable) service enables IMS to control the cable modem
termination system (CMTS) through the policy and charging rules function (PCRF) to
implement quality of service (QoS) control on cable networks.

Benefits
Table 2-48 describes the benefits of the Policy Control Support (Cable) service.

Table 2-48 Benefits of the Policy Control Support (Cable) service

For... Benefits
Carriers This service enables carriers to optimize the usage of network
resources and improve the QoS.
Subscribers This service enables subscribers to improve quality standards for
data transport and obtain the desired quality for IMS services.

Availability
Table 2-49 describes the requirements for implementing the Policy Control Support (Cable)
service.

Table 2-49 Requirements for implementing the Policy Control Support (Cable) service

NE Version License Requirements Function Description

PCRF CSC3300 A license is required for this The PCRF, which is
V100R008C service. embedded in the P-CSCF,
03 and later The license name is sends bearer control
CSC3300,LMI2SPCMM00, information to the CMTS to
Policy Control implement QoS control.
Support(Cable) (per
BHSA).

In the license name, the busy hour session attempts (BHSA) refer to the number of sessions performed
within the busiest hour. The BHSA is used to measure the processing capability of devices using the
Session Initiation Protocol (SIP). The devices process sessions as well as calls.

Impact on System
None.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 246

Constraints
The Policy Control Support (Cable) service has the following limitations:
The QoS channel can be created only for one call leg when the forking function is
implemented.
− When the forking function is implemented, the QoS channel can be created and
maintained only for the first call leg. If this QoS channel is used for processing the
early media, the media update is performed only for the first call leg in subsequent
messages.
− The number of media lines in SDP information restricts change and difference across
call legs when the forking function is implemented.
The built-in PCRF of P-CSCF does not allow Session Description Protocol (SDP)
information which contains more than three media lines.
The built-in PCRF of P-CSCF does not support the Billing Correlation ID (BCID) and
pkt-mm-4 charging interfaces.
The built-in PCRF of P-CSCF supports the Hosted-NAT function but this function
requires that the CMTS does not set limitations on the port. In addition, the signaling and
media addresses of the UE must be the same when the Hosted-NAT function is
implemented.

Interaction with Other Features

None.

Application
This service applies to scenarios in which dynamic QoS control is required to provide
high-quality audio and video services for cable subscribers.

Principles
Figure 2-43 shows typical networking for implementing the Policy Control Support (Cable)
service.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 247

Figure 2-43 Typical networking for implementing the Policy Control Support (Cable) service

The Policy Control Support (Cable) service includes the following scenarios:
Audio call
This scenario describes how the PCRF implements QoS control during an audio call.
Session release
This scenario describes how the PCRF implements QoS control during session release.
Call hold and call resume
This scenario describes how the PCRF implements QoS control in the following cases:
− During an audio call, the calling party or the called party places the current call on
hold and answers a new incoming call.
− The calling party or the called party releases the new incoming call and resumes the
original audio call.
Video stream enabling or disabling
This scenario describes how the PCRF implements QoS control when video streams are
enabled or disabled.
PCRF supporting event reports by the CMTS
This scenario describes how the PCRF releases a session when the CMTS detects no
media streams within the T3 timer period and reports this event to the PCRF.
Audio Call
Figure 2-44 shows the message flow for an audio call.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 248

The message flow between the P-CSCF and the CMTS is similar on the originating and
terminating sides. The following scenario describes the message flow only on the terminating
side.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 249

Figure 2-44 Message flow for an audio call

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 250

As stipulated in PacketCable 2.0, control resources are unidirectional and IP media resources are
bidirectional during an audio call. Therefore, upstream and downstream media streams must be
created for IP media resources.
In Figure 2-44, Real-Time Transport Protocol (RTP) is used for media streams, Real-Time Transport
Control Protocol (RTCP) is used for controlling media streams, "up" indicates upstream media
streams, and "down" indicates downstream media streams.
In Figure 2-44, the INVITE and 183 messages contain SDP information used for media negotiation.
There are other NEs between the originating P-CSCF and the terminating P-CSCF, which are
independent of QoS control. These NEs are indicated by the ellipsis (...) in Figure 2-44 and are not
described in this scenario.

1: UE_A initiates an audio call. An INVITE message is sent to the originating P-CSCF.
2: The originating P-CSCF forwards the INVITE message to the terminating P-CSCF.
3: The terminating P-CSCF forwards the INVITE message to UE_B.
4: UE_B returns a 183 message to perform media negotiation.
5: When the terminating P-CSCF receives the 183 message, it queries the PACN (P-CSCF
Access Network Information) table to obtain its built-in PCRF and sends an AAR message to
request bearer resources.
6-9: After the PCRF receives the AAR message, it performs the following operations:
Checks the actual IP address and domain name of the UE contained in the AAR message
and queries the CMTSRT (CMTS Route) table for the corresponding CMTS.
Checks the media information contained in the AAR message and sends GateSet
messages to the terminating CMTS to request gate resources.
10-13: The terminating CMTS generates GateIDs and returns GateSetAck messages to the
terminating PCRF based on the CMTS resource bearer capabilities. (Each media stream is
uniquely identified by one GateID.)
14: The terminating PCRF stores each GateID and determines whether a success response has
been received for each GateSet message.
If a success response has been received for each GateSet message, the terminating PCRF
returns a valid AAA message to the terminating P-CSCF.
If one or more failure responses have been received, the terminating PCRF does not
grant the AAR request and returns an invalid AAA message to the terminating P-CSCF.
In addition, the terminating PCRF releases gate resources created by the terminating
CMTS.

In Figure 2-44 assumes that a success response is returned to each GateSet request.

15: After resources are reserved successfully on the terminating side, the terminating P-CSCF
receives a 180 message and forwards the 180 message to the originating P-CSCF.
16: The originating P-CSCF reserves resources and forwards the 180 message to UE_A.
17: UE_A returns a PRACK message to UE_B, in response to the 180 message.
18: UE_B returns a 200 message to UE_A, in response to the PRACK message.
19: UE_B returns a 200 message to the terminating P-CSCF, indicating that the audio call
request from UE_A was granted.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 251

20: The terminating P-CSCF sends an AAR message to request the terminating PCRF to
enable the gate control.
21-24: The terminating PCRF contains each GateID generated by the terminating CMTS in
one GateSet message and sends the messages to request the terminating CMTS to enable the
gate control.
25-28: The terminating CMTS returns GateSetAck messages to the terminating PCRF based
on the CMTS resource bearer capabilities.
29: The terminating PCRF determines whether a success response has been received for each
GateSet message.
If a success response has been received for each GateSet message, the terminating PCRF
returns a valid AAA message to the terminating P-CSCF.
If a failure response has been received for a GateSet message, the terminating PCRF
does not grant the AAR request and returns an invalid AAA.
30: When the terminating P-CSCF receives a valid AAA message, it returns a 200 message to
the originating P-CSCF.
31: The originating P-CSCF reserves resources and forwards the 200 message to UE_A.
32: UE_A returns an ACK message to UE_B. The audio call is established.
Session Release
Figure 2-45 shows the message flow for session release.
The message flow between the P-CSCF and the CMTS is similar on the originating and
terminating sides. The following scenario describes the message flow only on the terminating
side.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 252

Figure 2-45 Message flow for session release

There are other NEs between the originating P-CSCF and the terminating P-CSCF, which are
independent of QoS control. These NEs are indicated by the ellipsis (...) in Figure 2-45 and are not
described in this scenario.

1: During a session, UE_A sends a BYE message to the originating P-CSCF.

2: The originating P-CSCF releases relevant resources and forwards the BYE message to the
terminating P-CSCF.
3: The terminating P-CSCF sends a Session Termination Request (STR) message to request
the terminating PCRF to release relevant resources.
4-7: The terminating PCRF determines whether relevant gate resources exist. If so, the
terminating PCRF constructs GateDelete messages to release these resources.
8-11: The terminating CMTS returns GateDeleteAck messages to the terminating PCRF.
12: The terminating PCRF determines whether a success response has been received for each
GateDelete message.
If a success response has been received for each GateDelete message, the terminating
PCRF releases relevant gate resources and returns a Session Termination Answer (STA)
message to the terminating P-CSCF.
If one or more failure responses have been received, the terminating PCRF releases
relevant gate resources and returns an invalid STA message to the terminating P-CSCF.

In Figure 2-45 assumes that a success response is returned to each GateSet request.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 253

13: When the terminating P-CSCF receives a valid STA message, the terminating P-CSCF
forwards the BYE message to UE_B.
14: UE_B returns a 200 message to UE_A, in response to the BYE message. The session is
released.
Call Hold and Call Resume
Figure 2-46 shows the message flow for call hold and call resume during an audio call.
The message flow between the P-CSCF and the CMTS is similar on the originating and
terminating sides. The following scenario describes the message flow only on the terminating
side.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 254

Figure 2-46 Message flow for call hold and call resume

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 255

There are other NEs between the originating P-CSCF and the terminating P-CSCF, which are
independent of QoS control. These NEs are indicated by the ellipsis (...) in Figure 2-46 and are not
described in this scenario.

1: During an audio call with UE_B, UE_A receives a new incoming call. UE_A sends an
INVITE message to the originating P-CSCF. The message contains a=inactive/sendonly or
c=IN IP4 0.0.0.0 to place the call with UE_B on hold.
2: The originating P-CSCF forwards the INVITE message to the terminating P-CSCF.
3: The terminating P-CSCF forwards the INVITE message to UE_B.
4: UE_B returns a 2xx message to the terminating P-CSCF in response to the INVITE
message.
5: The terminating P-CSCF sends an AAR message to request the terminating PCRF to
change the CMTS Gate status. If UE_B returns a 4xx, 3xx, 5xx, or 6xx message to the
terminating P-CSCF, the terminating P-CSCF does not send this AAR message.
6-7: When the terminating PCRF receives the AAR message from the terminating P-CSCF, it
sends GateSet messages to notify the terminating CMTS that the call is placed on held and
relevant resources do not need to be released.
8-9: The terminating CMTS returns GateSetAck messages to the terminating PCRF based on
the CMTS resource bearer capabilities.
10: The terminating PCRF determines whether a success response has been received for each
GateSet message.
If a success response has been received for each GateSet message, the terminating PCRF
returns a valid AAA message to the terminating P-CSCF, indicating that the call was
placed on hold.
If a failure response has been received for a GateSet message, the terminating PCRF
does not grant the AAR request and returns an invalid AAA, indicating that the call
failed to be placed on hold.

In Figure 2-46 assumes that a success response is returned to each GateSet request.

11: When the terminating P-CSCF receives a valid AAA message, it returns a 2xx message to
the originating P-CSCF.
12: The originating P-CSCF places the call on hold and forwards the 2xx message to UE_A.
13: UE_B sends an ACK message to UE_B, indicating that the call was placed on hold.
14-16: UE_A sends an INVITE message to UE_B. The message contains a=sendrecv or c=IN
IP4 x.x.x.x to resume the call with UE_B.
17: UE_B returns a 2xx message to the terminating P-CSCF in response to the INVITE
message.
18: The terminating P-CSCF sends an AAR message to request the terminating PCRF to
change the CMTS Gate status. The AAR message contains information about call resume.
19-20: The terminating PCRF sends GateSet messages to the terminating CMTS.
21-22: The terminating CMTS returns GateSetAck messages to the terminating PCRF based
on the CMTS resource bearer capabilities.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 256

23: The terminating PCRF determines whether a success response has been received for each
GateSet message.
If a success response has been received for each GateSet message, the terminating PCRF
returns a valid AAA message to the terminating P-CSCF.
If a failure response has been received for a GateSet message, the terminating PCRF
does not grant the AAR request and returns an invalid AAA.
24: The terminating P-CSCF returns a 2xx message to the originating P-CSCF, indicating that
the call was resumed successfully on the terminating side.
25: The originating P-CSCF resumes the call and forwards the 2xx message to UE_A.
26: UE_A returns an ACK message to UE_B. The call is resumed.
Video stream enabling or disabling
Figure 2-47 shows the message flow for media renegotiation during a multimedia call,
including enabling or disabling video streams.
The message flow between the P-CSCF and the CMTS is similar on the originating and
terminating sides. The following scenario describes the message flow only on the terminating
side.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 257

Figure 2-47 Message flow for media renegotiation

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 258

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 259

In Figure 2-47, the INVITE and 2xx messages contain SDP information used for media negotiation.
There are other NEs between the originating P-CSCF and the terminating P-CSCF, which are
independent of QoS control. These NEs are indicated by the ellipsis (...) in Figure 2-47 and are not
described in this scenario.

1: During a session, UE_A sends an INVITE message to the originating P-CSCF to enable
video streams.
2: The originating P-CSCF forwards the INVITE message to the terminating P-CSCF.
3: The terminating P-CSCF forwards the INVITE message to UE_B.
4: UE_B returns a 2xx message to the terminating P-CSCF in response to the INVITE
message.
5: The terminating P-CSCF sends an AAR message to request the terminating PCRF to enable
video streams.
6: The terminating PCRF sends a GateSet message to the terminating CMTS, which contains
an indication to retain audio streams.
7: The terminating CMTS returns a GateSetAck message to the terminating PCRF, indicating
that audio streams were retained.
8-11: The terminating PCRF sends GateSet messages to the terminating CMTS to request
video resources.
12-15: The terminating CMTS generates video GateIDs and returns GateSetAck messages to
the terminating PCRF based on the CMTS resource bearer capabilities.
16: The terminating PCRF determines whether a success response has been received for each
GateSet message.
If a success response has been received for each GateSet message, the terminating PCRF
returns a valid AAA message to the terminating P-CSCF. In addition, the terminating
PCRF stores video GateIDs returned by the terminating CMTS, which will be used for
requesting video resources.
If a failure response has been received for a GateSet message, the terminating PCRF
does not grant the AAR request and returns an invalid AAA.

In Figure 2-47 assumes that a success response is returned to each GateSet request.

17: The terminating P-CSCF returns a 2xx message to the originating P-CSCF, indicating that
video streams were enabled successfully on the terminating side.
18: The originating P-CSCF enables video streams and forwards the 2xx message to UE_A.
19: UE_A returns an ACK message to UE_B. Video streams are enabled.
20-22: During a session, UE_A sends an INVITE message to UE_B to disable video streams.
23: UE_B returns a 2xx message to the terminating P-CSCF in response to the INVITE
message.
24: The terminating P-CSCF sends an AAR message to request the terminating PCRF to
disable video streams.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 260

25: The terminating PCRF sends a GateSet message to request the terminating CMTS to
retain audio streams.
26: The terminating CMTS returns a GateSetAck message to the terminating PCRF,
indicating that audio streams were retained.
27-30: The terminating PCRF sends GateDelete messages to request the terminating CMTS to
delete video GateIDs.
31-34: The terminating CMTS returns GateDeleteAck messages to the terminating PCRF.
35: The terminating PCRF determines whether a success response has been received for each
GateDelete message.
If a success response has been received for each GateDelete message, the terminating
PCRF returns a valid AAA message to the terminating P-CSCF. In addition, the
terminating PCRF deletes video GateIDs returned by the terminating CMTS. This
prevents the terminating PCRF from repeatedly sending GateDeleteAck messages.
If a failure response is returned for some GateDelete messages, the terminating PCRF
can ignore the failure and returns a valid AAA message to the terminating P-CSCF.

If media renegotiation is required later but video streams are still disabled, the terminating
PCRF does not send GateDelete messages. This prevents CMTS GateIDs from being deleted
for a released session.

36: The terminating P-CSCF returns a 2xx message to the originating P-CSCF, indicating that
video streams were disabled on the terminating side.
37: The originating P-CSCF disables video streams and forwards the 2xx message to UE_A.
38: UE_A returns an ACK message to UE_B. Video streams are disabled.
PCRF Supporting Event Reports by the CMTS
Figure 2-48 shows the message flow when the PCRF supports event reports by the CMTS.
The message flow between the P-CSCF and the CMTS is similar on the originating and
terminating sides. The following scenario describes the message flow only on the originating
side.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 261

Figure 2-48 Message flow when the PCRF supports event reports by the CMTS

UE_A CMTS PCRF P-CSCF UE_B

1. INVITE
2. INVITE
3. 2xx
4. AAR
5. GateSet (*4)
6. GateSetAck (*4)
7. AAA
8. 2xx
9. Gate-Report-
State
10. Gate-Report-
State
11. ASR
12. ASA
13. STR
14. STA
15. RAR
16. RAA
17. BYE
18. BYE

Mandatory
Optional

1: UE_A sends an INVITE message to the originating P-CSCF to establish a session with
UE_B.
2: The terminating P-CSCF forwards the INVITE message to UE_B.
3: UE_B returns a 2xx message to the originating P-CSCF in response to the INVITE
message.
4: If the originating P-CSCF supports media interruption detection, it sends an AAR message
to the PCRF, in which Specific-Action is set to
INDICATION_OF_RELEASE_OF_BEARER.
5. After receiving the AAR message, the PCRF checks the value of Specific-Action.
If Specific-Action is set to INDICATION_OF_RELEASE_OF_BEARER, the PCRF
determines that media interruption detection is supported. Then, the PCRF sends a
GateSet message that contains Gate-Spec T3=240s. (The media interruption detection
period is configurable. The period ranges from 1 to 65534 seconds, and the default
period is 240 seconds)
If Specific-Action is set to INDICATION_OF_RELEASE_OF_BEARER, the PCRF
determines that media interruption detection is not supported. Then, the PCRF sends a
GateSet message that contains Gate-Spec T3=0, which disables media interruption
detection.
6: The CMTS returns GateSetAck messages to the PCRF based on the CMTS resource bearer
capabilities.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 262

7: The PCRF determines whether a success response has been received for each GateSet
message.
If a success response has been received for each GateSet message, the PCRF returns a
valid AAA message to the P-CSCF.
If a failure response has been received for a GateSet message, the PCRF does not grant
the AAR request and returns an invalid AAA.

In Figure 2-48 assumes that a success response is returned to each GateSet request.

8: When the P-CSCF receives a valid AAA message, it forwards the 2xx message to UE_A.
The session is established.
9-10: If the CMTS supports media interruption detection but no media streams pass through
the CMTS, the CMTS reports Gate-Report-State (reason code = 5) when the T3 timer expires.
In addition, the CMTS releases relevant gate resources.
11-16: When the PCRF receives the first Gate-Report-State, it does not immediately notify the
P-CSCF of this event. Instead, it starts a timer to wait for the status report of other GateIDs
associated with the session. This prevents the sending of a large number of Re-Auth-Request
(ARA) messages. The PCRF performs the following operations based on the status report of
GateIDs:
If abnormal events are reported for all GateIDs before the timer expires, the PCRF sends
an Abort-Session-Request (ASR) to request the P-CSCF to release the session. In
addition, the PCRF deletes the GateIDs. This prevents the PCRF from repeatedly
releasing the GateIDs when receiving STR messages.
If the timer expires and abnormal events are reported for some GateIDs, the PCRF
constructs an RAR message and sends it to the P-CSCF. Then, the P-CSCF determines
whether to release the session.
17: The P-CSCF sends a BYE message to UE_A to release the session.
18: The P-CSCF sends a BYE message to UE_B to release the session.

Billing and CDRs

None.

Software Parameters
None.

Specifications
The built-in PCRF supports a maximum of one million subscribers.

Compliance
Table 2-50 lists the standards with which the Policy Control Support (Cable) service
complies.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 263

Table 2-50 Standards with which the Policy Control Support (Cable) service complies

Category Purpose Name Remarks

PacketCable 2.0 PKT-SP-QOS-I02-0 Standardizes the Fully complies with
80425, Quality of QoS architecture. the specification.
Service
Specification
PKT-SP-MM-I05-0 Standardizes the Fully complies with
91029, Multimedia pkt-mm2 (COPS) the specification.
Specification interface.
PKT-SP-CODEC-M Standardizes the Fully complies with
EDIA-I04-080425, codec specification. the specification.
Codec and Media
Specification

Release
Table 2-51 lists the release history of the Policy Control Support (Cable) service.

Table 2-51 Release history of the Policy Control Support (Cable) service

Feature Version Release Version Details

01 CSC3300 V100R008C03 First release.

2.17 MI2SMCH24800 Media Control(H.248) Supported by

Boarder Gateway
Availability
This feature is introduced in CSC3300 V100R006.

Feature Description
This feature enables the CSC3300 to perform media NAPT-PT, thus implementing media
public and private network traversal and bearer control.

Benefits
For subscribers
This feature reduces the service flow of the SPDF, and thus the call connection duration
can be reduced.
For carriers

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 264

Carriers are the main beneficiaries of this feature.

With this feature, fewer SPDFs can be deployed, thus simplifying the IMS network and
lowering the deployment costs of the IMS network.

Description
Networking

In this networking, the P-CSCF/IBCF provides the H.248 interface to control the
C-BGF/I-BGF, thus performing media NAPT-PT and implementing media public and private
network traversal and bearer control.
H.248 Interface Specifications
Support ITU-T Recommendation H.248.1 Version 3, Version 2, and Version 1 and
support version negotiation
Support encoding in ABNF (text) and ASN.1 (binary) formats
Support SCTP
Function description
NAPT-PT basic session
During session setup or renegotiation, the P-CSCF/IBCF sends an Add or a Modify
message to the C-BGF/I-BGF through the Ia interface to obtain media mapping. When
the session is complete, the P-CSCF/IBCF releases media resources.
Basic session on a network with hosted NAT
On a network with hosted NAT, the P-CSCF delivers a latching/relatching indication to
instruct the C-BGF to latch to the first incoming packet and perform media NAPT-PT.
Supporting media NAPT-PT when UEs access the C-BGF from the same IP address
The P-CSCF supports media NAPT-PT when UEs access the C-BGF from the same IP
address.
C-BGF/I-BGF reporting events
When the C-BGF/I-BGF releases media resources due to a certain abnormality (for
example, there is no media stream during a long time or there is an extra-long session),
the C-BGF/I-BGF sends a Notify message to the P-CSCF/IBCF to inform the
P-CSCF/IBCF of the abnormal resource release. The P-CSCF/IBCG then releases the
session.
Disabling media stream interruption check when a call is placed on hold
When UE A who has registered the call hold service places UE B on hold during a call,
the P-CSCF/IBCF can identify the call hold operation and send a request to the
C-BGF/I-BGF to place media streams on hold. When the call hold is complete, the
P-CSCF/IBCF sends a request to the C-BGF/I-BGF to restore the media stream
interruption check function of the C-BGF/I-BGF.
Forking

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 265

In the case of forking, the P-CSCF/IBCF maintains the mapping created only by the first
forking during media mapping. If the mapping created by the first forking is required by
early media, the P-CSCF/IBCF updates media information of only the first forking.
When a session is established successfully, the P-CSCF/IBCF instructs the
C-BGF/I-BGF to update the media mapping.
Resource audit
The P-CSCF/IBCF can audit resources of the C-BGF/I-BGF to prevent deadlock of
C-BGF/I-BGF resources.
Troubleshooting the C-BGF/I-BGF
When the P-CSCF/IBCF detects that the C-BGF/I-BGF is abnormal, the P-CSCF/IBCF
releases sessions related to the C-BGF/I-BGF.

Enhancement
The media NAPT-PT function of the SPDF is introduced in CSC3300 V100R005.

Dependency
None

2.18 MI2S00PASA00 Enhanced Authentication

2.18.1 SWP-CSCF-AKAA-023200 IMS AKA Authentication
Availability
This feature is introduced in CSC3300 V100R002.

Summary
Authentication and key agreement (IMS AKA) is a standard authentication mechanism
defined by 3GPP TS 33.203 for the IMS. The IMS subscribers using ISIM cards are
authenticated in this mode.

Benefits
For subscribers
IMS subscribers using ISIM cards can access the IMS network in a secure mode.
For carriers
Using this authentication mechanism, the IMS network authenticates UEs and the UEs
authenticate the IMS network. This authentication mechanism also can be used to set up
security associations (SA) to protect the SIP signaling between the UEs and the P-CSCF,
thus improving the network access security.

Description
IMS AKA is a mechanism for authenticating IMS subscribers. The IMS AKA achieves mutual
authentication between the UE and the IMS network to protect privacy and data integrity of
the IMS network.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 266

On the IMS network, the IMPI is the identity used for authenticating a subscriber. The HSS
and the ISIM share a long-term key (Individual Subscriber Authentication Key) associated
with the IMPI.
The IMS authentication parameters include the authentication vector and related parameter
that are used for generating the authentication vector.

The initial key K is shared between the UE and the HSS.

The UE initiates a REGISTER request.
The S-CSCF sends a Multimedia Authentication Request (MAR) to the HSS to request
the authentication data. Based on the initial key K and the SQN, the HSS generates the
authentication vector and delivers it in a Multimedia Authentication Answer (MAA) to
the S-CSCF. The authentication vector consists of the RAND, AUTN, XRES, IK, and
CK.
The S-CSCF initiates a 4xx response to challenge the UE. The 4xx response carries the
authentication vector excluding the XRES.
The P-CSCF stores the IK and CK and transfers the RAND and AUTN to the UE
through the 4xx response.
Based on the initial key K, SQN, and the AUTN received from the network, the UE
authenticates the network. If the network passes the authentication, the UE generates the
RES based on the RAND and includes the RES in the REGISTER request sent to the
network.
When receiving the REGISTER request, the S-CSCF compares the RES carried in the
request with the XRES it stores. If they are the same, the S-CSCF considers that the UE
is authorized to use the network.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 267

Enhancement
None

Dependency
None

2.18.2 SWP-CSCF-EISA-023300 Early IMS Authentication

Availability
This feature is introduced in CSC3300 V100R002.

Summary
For early IMS subscribers who do not support the IMS AKA authentication, such as 2G
subscribers, the Early IMS authentication applies. This authentication mode authenticates
subscribers by comparing IP addresses.

Benefits
For subscribers
Subscribers from legacy networks can access the IMS network.
For carriers
This feature enables the IMS network to authenticate the subscribers who use cards (for
example, SIM cards) and do not support the IMS AKA authentication defined in 3GPP
TS 33.203.

Description
To implement the early IMS authentication, the HSS binds the IMPI of a subscriber with the
IP address allocated by the GGSN. After receiving the PDP context activation request from
the UE, the GGSN allocates an IP address to the UE and sends the IP address, together with
the MSISDN and IMSI, to the HSS. The HSS then matches an IMPI for the IP address based
on the MSISDN and IMSI and binds the IP address with the IMPI. The PDP context
activation process is complete only when the GGSN receives a success response from the
HSS. If a success response is not received, the activation process fails. When the PDP context
is deactivated or changed, the GGSN signals the HSS to update the IP address it stores.
When receiving a REGISTER or other SIP requests from an IMPU, the S-CSCF checks
whether the IP address carried in the request is the same as that stored in the HSS. If yes, it
accepts the request.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 268

An early IMS subscriber is defined in the HSS. The IMSI and MSISDN are stored in the
UE and the HSS.
The UE sends a PDP context activation request to the GGSN. The GGSN obtains the
IMSI and MSISDN of the UE and allocates an IP address to the UE. Then, the GGSN
reports the IP address to the HSS. The HSS stores the IP address.
When a REGISTER request arrives at the I-CSCF or S-CSCF, the I-CSCF or S-CSCF
deletes sip: from the IMPU to obtain the IMPI and uses the IMPI to query the HSS.
The HSS sends the IP address assigned by the GGSN to the S-CSCF.
The S-CSCF compares the IP address carried in the SIP request with the IP address sent
from the HSS. If they are the same, the authentication is successful.

Enhancement
None

Dependency
None

2.18.3 SWP-CSCF-NASSA-023400 NASS-Bundled

Authentication
Availability
This feature is introduced in CSC3300 V100R003.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 269

Summary
The HSS supports the network attachment subsystem (NASS) bundled authentication (NBA)
to allow early fixed-line subscribers to access the IMS network.

Benefits
For subscribers
Subscribers from legacy fixed networks can access the IMS network.
For carriers
This feature enables the IMS network to authenticate the fixed-line subscribers who do
not support the IMS AKA authentication defined in 3GPP TS 33.203.

Description
The HSS supports the NBA authentication to allow early fixed-line subscribers to access the
IMS network. The authentication parameter used for NBA is Line ID. The Line ID parameter
specifies the location, from which the subscriber accesses the network. Multiple sets of access
location information can be defined in the HSS for one IMPI to allow a subscriber to access
the IMS network from different places.

When a UE accesses the network from a specific line or location, the NASS binds the location
information with the UE. The locations that a subscriber can use to access the network are
defined in the HSS.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 270

When a REGISTER message arrives at the S-CSCF, the S-CSCF sends an MAR to the
HSS to quest the authentication data.
The HSS returns the location information registered by the subscriber. The S-CSCF
compares the location information carried in the REGISTER request with the location
information returned by the HSS. If they are the same, the authentication is successful.

Enhancement
None

Dependency
None

2.18.4 SWP-CSCF-NASSA-023401 e2 Interface to the TISPAN

NASS
Availability
This feature is introduced in CSC3300 V100R002.

Summary
Figure 2-15 e2 interface to the NASS

CLF is short for Connectivity Session Location and Repository Function.

The P-CSCF obtains the user access profile of fixed-line subscribers from the CLF through
the e2 interface. Carriers can perform NBA authentication on subscribers based on the user
access profile or allow the subscribers to access the IMS only from the location defined in the
user profile. When receiving an emergency call request from a fixed-line subscriber, the
S-CSCF can route the call to the nearest EC to shorten the rescue time.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 271

Benefits
For subscribers
This feature enables the IMS network to route emergency calls from fixed-line
subscribers to the nearest EC.
For carriers
With the CLF that provides the location information of fixed-line subscribers, carriers
can allow fixed-line subscribers to access the IMS network only from the locations
defined in the user profile.

Description
When receiving a REGISTER request, if the P-CSCF detects that a CLF query is required for
the access network, in which the subscriber resides, the P-CSCF uses the IP address of the
subscriber to send a UDR message to the CLF, requesting the location information of the
subscriber. The CLF then returns the query result in a UDA message. The P-CSCF inserts an
extended parameter location-info in the P-Access-Network-Info header field of the
REGISTER request. Later, the S-CSCF learns the location information of the subscriber from
this parameter and compares the information with that returned from the HSS. If the CLF
indicates that the subscriber accesses the network from an XDSL, the P-CSCF inserts a
dsl-location parameter in the P-Access-Network-Info header field.
For an emergency call, the E-CSCF obtains the location information of the subscriber based
on the P-Access-Network-Info header field. If the access type is XDSL ("ADSL", "ADSL2",
"ADSL2+", "RADSL", "SDSL", "HDSL", "HDSL2", "G.SHDSL", "VDSL", and "IDSL"), the
E-CSCF obtains the location information from the dsl-location parameter. Then, based on the
location information and the emergency call number, the E-CSCF selects an EC.

Enhancement
None

Dependency
None

2.19 MI2S00CRHN00 Call Restriction to Hotline Numbers

The CSC3300 supports the Call Restriction to Hotline Numbers feature.

Summary
Call Restriction to Hotline Numbers prevents a large number of subscribers from
simultaneously dialing hotline numbers, thus ensuring that ordinary calls can be connected. To
implement call restriction, the CSC3300 controls simultaneous hotline call requests based on
the relevant flow control data configuration on the S-CSCF.

Benefits
Table 2-52 describes the benefits of the Call Restriction to Hotline Numbers feature.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 272

Table 2-52 Benefits of the Call Restriction to Hotline Numbers feature

Beneficiary Description
Carriers This feature enables carriers to ensure the call
completion rate of ordinary calls, thus improving the
image of carriers.
Subscribers This feature ensures that ordinary calls can be
successfully connected. Thus, subscribers' service
right is protected and the service experience is
improved.

Availability
Table 2-53 describes the requirements for implementing the Call Restriction to Hotline
Numbers feature.

Table 2-53 Requirements for implementing the Call Restriction to Hotline Numbers feature

Requi Required Version License Support

red
NEs
S-CSC V100R006C02 or A license is required for the implementation of the SIP
F later Signaling Compression feature.

Dependency
This feature does not have any interaction with other features.

Description
The Call Restriction to Hotline Numbers feature is performed by the S-CSCF in each
detection points (DPs) during number analysis. The S-CSCF performs Call Restriction to
Hotline Numbers in the following ways:
Percentage based flow control: When the percentage of connected calls reaches a
specific value, the subsequent calls are rejected.
CAPS(Call Attempt Per Second) flow control: When the number of call attempts in a
unit time reaches a specific CAPS, the subsequent calls are rejected.
The following section describes the procedure of Call Restriction to Hotline Numbers
performed by the originating S-CSCF. Figure 2-52 shows the procedure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 273

Figure 2-49 DPs of Call Restriction to Hotline Numbers performed by the originating S-CSCF

S-CSCF-O AS-O S-CSCF-T MGCF

INVITE
PAI, orig,
Request-URI Detection point 1

Number convertion

Detection point 2
INVITE
PAI, orig,
Request-URI
INVITE
PAI, orig,
Request-URI

Detection point 3
INVITE
PAI, Request-URI
Detection point 4

Number normalization

Detection point 5
Detection point 6

Call forward
INVITE
PAI, Request-URI

The DPs are described as follows:

DP 1: After receiving an INVITE request, the originating S-CSCF can reject the call
based on the PAI and Request-URI header fields contained in the INVITE request.
DP 2: After performing caller number conversion and called number conversion, the
originating S-CSCF can reject the call based on the converted PAI and Request-URI
header fields.
DP 3: Before sending the INVITE request to the terminating network, the originating
S-CSCF can reject the call based on the PAI and Request-URI header fields based on the
INVITE request.
DP 4: After receiving the INVITE request, the terminating S-CSCF can reject the call
based on the PAI and Request-URI header fields contained in the INVITE request.
DP 5: After performing called number normalization, the terminating S-CSCF can reject
the call based on the normalized PAI and Request-URI header fields.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 274

DP 6: Before forwarding the INVITE request (for example, to the MGCF in the CS
domain), the terminating S-CSCF can reject the call based on the PAI and Request-URI
header fields in the INVITE request.

Enhancement
Table 2-54 lists the release history of the Call Restriction to Hotline Numbers feature.

Table 2-54 Release history of the Call Restriction to Hotline Numbers feature

History Version Details Release Plan

Initial release V100R006C02 - -

2.20 MI2SSIGFLT00 Filtering of SIP Signaling

Availability
Table 2-55 describes the requirements for implementing the SIP Signaling Filtering feature.

Table 2-55 Requirements for implementing the SIP Signaling Filtering feature

Required NEs Required Version License Support

P-CSCF V100R006C02 or later A license is required for the
implementation of the SIP
I-CSCF Signaling Filtering feature.
S-CSCF

Summary
According to the rules for filtering source addresses or destination addresses of SIP messages,
the filtering policy is applied to the first lines, headers, and message bodies of SIP messages.
This feature helps carriers to prevent subscribers from using illegal SIP messages.
The message filtering rule of the CSC3300 is flexible. The conditions for filtering messages
consist of the following elements of a SIP message:
SIP method name
SIP response code
SIP header name
SIP header value
MIME content such as encrypted message bodies
The P-CSCF/S-CSCF filters messages based on the pre-configured Allowed/Disallowed list.
For the messages that meet the specified conditions, the P-CSCF performs the following
filtering operations:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 275

Discards SIP messages

Rejects SIP requests
Deletes the specified header and MIME content
Adds specific headers
Replaces header values

Benefits
Table 2-56 describes the benefits of the SIP Signaling Filtering feature.

Table 2-56 Benefits of SIP Signaling Filtering feature

Beneficiary Description
Carriers The SIP signaling filtering feature provides a
mechanism to enable carriers to prevent users from
using illegal SIP messages. The SIP signaling
filtering feature provides the following advantages:
The function of SIP message discarding prevents
certain DoS attacks.
The function of headers filtering ensures network
security.
During an interworking test, the SIP signaling
filtering feature helps carriers to quickly solve
interworking problems caused by understanding
of protocols.

Description
Description of Implementation Principle
Based on the routing information and content of SIP messages, the P-CSCF/S-CSCF discards
or rejects SIP messages, or deletes or replaces the headers of the SIP messages.
In the SIP protocol stack and at the service layer of the SCU process, the P-CSCF/S-CSCF
implements the function of SIP Signaling Filtering on SIP messages and the content of SIP
message body.
1. After the codec layer of the SIP protocol stack receives SIP messages and decodes the
original SIP messages, it searches for the incoming policies configured on the local
P-CSCF/S-CSCF and obtains the IDs of uplink filtering policies based on the source IP
addresses (or domain names) of the SIP messages. The codec layer performs the filtering
policies based on the method names, Request-URIs, header field types, header values,
and header parameters.
2. After receiving the SIP messages from the SIP protocol stack and before sending bearer
requests, the service layer performs the filtering policies on the types and content of SIP
message body based on the IDs of the uplink filtering policies, which are obtained by the
codec layer of the SIP protocol stack.
3. After receiving the responses and before forwarding SIP messages, the service layer
searches for the outgoing policies configured on the local P-CSCF/S-CSCF and obtains
the IDs of downlink filtering policies based on the next-hop IP addresses (or domain

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 276

names) of the SIP messages. The service layer performs the filtering policies on the type
and content of SIP message body.
4. After receiving the SIP messages processed by the service layer and coding the SIP
messages, the codec layer of the SIP protocol stack performs the filtering policies based
on the IDs of the downlink filtering policies, which are obtained by the service layer.
Table 2-57 lists the filtering functions supported by the current P-CSCF/S-CSCF. The
P-CSCF/S-CSCF sends a response configured by the Response code parameter in the
Response Policy table to reject a message.

Table 2-57 Filtering functions supported by the current P-CSCF/S-CSCF

Filtering Requests/Inco Responses/In Requests/Out Responses/O

Condition ming Policy coming Policy going Policy utgoing
Policy
Method name Discard - Discard -
Reject Customs
Customs
Request-URI Discard - Discard -
Reject Replace
Replace
Response code - Discard - Discard
Replace Replace
Customs Customs
Message body Discard Discard Discard Discard
type Reject Delete Reject Delete
Delete Delete
Message body Discard Discard Discard Discard
content Reject Delete Reject Delete
Delete Delete
Header type Discard Discard Discard Discard
(header name) Reject Delete Delete Delete
Delete Replace Replace Replace
Replace Add Add Add
Add Customs Customs Customs
Customs
Header value Discard Discard Discard Discard
Reject Delete Delete Delete
Delete Replace Replace Replace
Replace
Header Discard Discard Discard Discard
parameter Reject Delete Delete Delete

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 277

Filtering Requests/Inco Responses/In Requests/Out Responses/O

Condition ming Policy coming Policy going Policy utgoing
Policy
Delete Replace Replace Replace
Replace Add Add Add
Add

NOTE
"-" indicates no policy.

Basic Flow
Flow of Filtering Requests
The process of the originating P-CSCF and the terminating P-CSCF filtering an INVITE
request is as follows:
When receiving an INVITE request, the originating P-CSCF implements an incoming
policy for the request originated by the originating UE based on the local configuration.
When forwarding the INVITE request to the originating S-CSCF, the originating
P-CSCF implements an outgoing policy for the request destined for the core network
based on the local configuration.
When receiving an INVITE request, the terminating P-CSCF implements an incoming
policy for the request originated by the core network based on the local configuration.
When forwarding the INVITE request to the terminating UE, the terminating P-CSCF
implements an outgoing policy for the request destined for the terminating UE based on
the local configuration.
The P-CSCF can forward requests only when the filtering policy is not set to "Reject" or
"Discard". The filtering policy is configured on the P-CSCF.
Figure 2-53 shows the flow of filtering a SIP request.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 278

Figure 2-50 Flow of filtering requests

Originating UE Originating P-CSCF Terminating P-CSCF Terminating UE

1.INVITE Request

Based on the address and method name of the

originating UE, the originating P-CSCF implements
an incoming policy for the request message
originated by the originating UE.

Based on the address and method name of the

originating S-CSCF, the originating P-CSCF
implements an outgoing policy for the request
message destined for the core network.

2.INVITE Request

Based on the address and method name of the

terminating S-CSCF, the terminating P-CSCF
implements an incoming policy for the request
message originated by the core network.

Based on the address and method name of the

terminating UE, the terminating P-CSCF
implements an outgoing policy for the request
message destined for the terminating UE.

3.INVITE Request

Flow of Filtering Responses

The process of the originating P-CSCF and the terminating P-CSCF filtering a 200 (OK)
response of an INVITE request is as follows:
When receiving a 200 (OK) response, the terminating P-CSCF implements an incoming
policy for the response originated by the terminating UE based on the local
configuration.
When forwarding the 200 (OK) response to the terminating S-CSCF, the terminating
P-CSCF implements an outgoing policy for the response destined for the core network
based on the local configuration.
When receiving a 200 (OK) response, the originating P-CSCF implements an incoming
policy for the response originated by the core network based on the local configuration.
When forwarding the 200 (OK) response to the originating UE, the originating P-CSCF
implements an outgoing policy for the response destined for the originating UE based on
the local configuration.
The P-CSCF can forward responses only when the filtering policy is not set to Discard. The
filtering policy is configured on the P-CSCF.
Figure 2-54 shows the flow of filtering a SIP response.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 279

Figure 2-51 Flow of filtering responses

Enhancement
Table 2-58 lists the release history of the SIP Signaling Filtering feature.

Table 2-58 Release history of the SIP Signaling Filtering feature

History Version Details Release Plan

Initial release V100R005C01 - -

Dependency
The SIP Signaling Filtering feature does not have any interaction with other features.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 280

2.21 MI2S00IDNS00 Intra-DNS server function

Availability
This feature is introduced in CSC3300 V100R005.

Summary
The CSC3300 provides an embedded DNS server. You can configure the DNS/ENUM data on
the CSC3300 to implement the function of an external DNS/ENUM device.

Benefits
For subscribers
This feature helps to protect the registration and call requests of a subscriber from being
affected by the links between the CSC3300 and the external DNS/ENUM device.
For carriers
For carriers, this feature provides the following benefits:
− The registration or session success ratio is improved, and thus the customer
satisfaction is enhanced.
− The operation expenditures are reduced. If other devices on the network do not
interwork with the DNS/ENUM device, the carriers need not configure an
independent DNS/ENUM device. If other devices must interwork with the external
DNS/ENUM device, the embedded DNS/ENUM device also helps to reduce the
burden of the external DNS/ENUM device, and thus improves the usage of the
external DNS/ENUM device.

Description
Application scope of the embedded DNS
The embedded DNS is an embedded function of Huawei CSC3300. The NEs of the CSC3300
are required to support the embedded DNS function. The P-CSCF, I-CSCF, S-CSCF, BGCF,
and OCG support the embedded DNS.
Features of the embedded DNS
Compared with the external DNS/ENUM device, the embedded DNS/ENUM device has the
following features:
Reliability
When a CSC3300 functional entity uses the embedded DNS/ENUM device, it does not
interact with the external DNS/ENUM device. Even if the link between the functional
entity and the external DNS/ENUM device fails, the current service will not be affected.
High speed
When a CSC3300 NE queries the external DNS/ENUM device, the external
DNS/ENUM device authenticates the NE, and returns query results after the
authentication. For the embedded DNS/ENUM device, the authentication is not required,
and thus the query speed is improved.
DNS SRV query function
DNS SRV query function

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 281

The CSC3300 obtains the DNS name according to the domain name contained in the
message. You can configure priority and weight for the SRV record. The administrator
can use the SRV function to enable several DNSs to serve the same domain, which
implements load sharing.
DNS A/AAAA query function
The CSC3300 returns the IP address of the DNS according to the obtained DNS name.
DNS E164 query function
The CSC3300 supports the ENUM function and enables you to map the subscriber
telephone number on the SIP AOR.

Enhancement
The embedded DNS feature is provided from CSC3300 V100R005.

Dependency
None

2.22 MI2S00ENUM00 Intra-Enum server

function(S-CSCF)
Availability
This feature is introduced in CSC3300 V100R005.

Summary
The CSC3300 provides an Intra-Enum server. You can configure the ENUM data on the
CSC3300 to implement the function of an external ENUM device.

Benefits
For subscribers
This feature helps to protect the registration and call requests of a subscriber from being
affected by the links between the CSC3300 and the external ENUM device.
For carriers
For carriers, this feature provides the following benefits:
− The registration or session success ratio is improved, and thus the customer
satisfaction is enhanced.
− The operation expenditures are reduced. If other devices on the network do not
interwork with the ENUM device, the carriers need not configure an independent
DNS/ENUM device. If other devices must interwork with the external DNS/ENUM
device, the embedded ENUM device also helps to reduce the burden of the external
ENUM device, and thus improves the usage of the external ENUM device.

Description
Application scope of the Intra-Enum

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 282

The Intra-Enum is an embedded function of Huawei CSC3300. The NEs of the CSC3300 are
required to support the Intra-Enum function. The P-CSCF, I-CSCF, S-CSCF, BGCF, and OCG
support the Intra-Enum.
Features of the Intra-Enum
Compared with the external ENUM device, the Intra-Enum device has the following features:
E164 query function
The CSC3300 supports the ENUM function and enables you to map the subscriber
telephone number on the SIP AOR.
High speed
When a CSC3300 NE queries the external ENUM device, the external ENUM device
authenticates the NE, and returns query results after the authentication. For the
Intra-Enum device, the authentication is not required, and thus the query speed is
improved.
Functions of the Intra-Enum
E164 query function
The CSC3300 supports the ENUM function and enables you to map the subscriber telephone
number on the SIP AOR.

Enhancement
The Intra-Enum feature is provided from CSC3300 V100R005.

Dependency
None

2.23 MI2S0CSCNP00 Number Portability(Number

Portability)
Availability
Table 2-65 describes the requirements for implementing the Number Portability feature.

Table 2-59 Requirements for implementing the Number Portability feature

Required NEs Required Version License Support

I-CSCF V100R003C02 or later This service is an optional
service provided by the
S-CSCF CSC3300. A license is
required for this service. The
license is used to control the
number of subscribers who
use this service. When the
number of subscribers who
use this service reaches the
upper limit allowed by the

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 283

Required NEs Required Version License Support

license, the system does not
allow new subscribers use
the service.

When the Number Portability server is not deployed on a network, you can configure the data of the
embedded Number Portability on the OMU to implement the function of the Number Portability server.

Summary
Number Portability allows the subscriber to keep the original number unchanged even if the
subscriber switches over to another carrier. For example, a mobile subscriber chooses A as a
new carrier, but the subscriber retains and uses the number for which the subscriber applied
from the original carrier B.

Benefits
Table 2-66 describes the benefits of the Number Portability feature.

Table 2-60 Benefits of the Number Portability feature

Beneficiary Description

Carriers Carriers can meet the subscribers' demands to switch

over among the carriers without changing the mobile
phone numbers, thus improving subscriber
satisfaction.
Subscribers Subscribers can switch over among the carriers
without changing their mobile phone numbers. In
addition, they can change their family addresses
without changing their fixed-line phone numbers.

Description
Implementation Principle
The originating S-CSCF or the terminating I-CSCF queries the NPDB or the OMU (on which
the embedded Number Portability data has been configured) for the routing number (RN) of
the subscriber. Based on the RN, the originating S-CSCF sends the session to the network that
serves the callee; the terminating I-CSCF can forward the session to the network that serves
the callee or send a response code or cause code to the originating entity and reject the call
request.
The IMS support the following Number Portability query modes:
ACQ query mode
The originating S-CSCF queries the Number Portability data. Based on the query result,
the S-CSCF routes the call request to the new carrier serving the callee.
QoR query mode

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 284

The originating entity does not query the Number Portability data but routes the call
request to the terminating I-CSCF. After successfully obtaining the Number Portability
data, the terminating I-CSCF, based on the local data configuration, determines to return
a mapping response code and cause code to the originating entity and reject the call
request. The previous hop of the I-CSCF queries the Number Portability data or forwards
the call request based on the response code and cause code.
OR query mode
The originating entity does not query the Number Portability data but routes the call
request to the terminating I-CSCF. After successfully obtaining the Number Portability
data, the terminating I-CSCF, based on the Number Portability data, routes the call
request to the new carrier serving the callee.
Based on the P-FNP-Capability header field, the terminating I-CSCF determines whether to
adopt the QoR query mode or OR query mode. If the value of the P-FNP-Capability header
field is none, the terminating I-CSCF adopts the OR query mode; if the value of the
P-FNP-Capability header field is fnp, the terminating I-CSCF adopts the QoR query mode; if
the value of the P-FNP-Capability header field is unknown or this header field does not exist,
the terminating I-CSCF determines whether to adopt the QoR query mode or OR query mode
based on the local data configuration.
This section takes the NPDB as an example to describe the Implementation Principle of the
Number Portability service in all call query (ACQ) mode, as shown in the Figure 2-58.

Before querying the NPDB, the originating S-CSCF or the terminating I-CSCF queries whether the
corresponding service board is configured with the embedded Number Portability data. If yes, the
originating S-CSCF or the terminating I-CSCF obtains the data without querying the NPDB. If not, the
originating S-CSCF or the terminating I-CSCF queries the NPDB.

Figure 2-52 Networking of the Number Portability service in ACQ mode

Assume that a callee applies for a number from the service provider. Then, the callee ends the
service application agreement with the service provider but still uses the number obtained
from the service provider. In addition, the callee subscribes to the Number Portability service
from a new service provider. The call flow is as follows:
1. The originating S-CSCF or the terminating I-CSCF receives a session request. The
S-CSCF/I-CSCF performs an ACQ query according to the local configurations. The
carrier or the country (depending on the application scope of the Number Portability

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 285

service) has a central NPDB that maintains the Number Portability profile of all Number
Portability subscribers.
2. The NPDB returns the RN associated with the callee.
3. Based on the RN, the originating S-CSCF or the terminating I-CSCF routes the call to
the current network that serves the callee.
Number Portability service in QoR mode supported
This section takes the NPDB as an example to describe the Implementation Principle of the
Number Portability service in query on release (QoR) mode, as shown in the Figure 2-59.

Before querying the NPDB, the I-CSCF queries whether the corresponding service board is configured
with the embedded Number Portability data. If yes, the I-CSCF obtains the data without querying the
NPDB. If not, the I-CSCF queries the NPDB.

Figure 2-53 Networking of the Number Portability service in QoR mode

After the I-CSCF successfully obtains the Number Portability data, it returns a mapping response code
(410, by default) and cause code to the originating entity and rejects the call request, or routes the call
request to the new carrier serving the callee based on the Number Portability query result.

Assume that a callee applies for a number from the service provider. Then, the callee ends the
service agreement with the service provider but still uses the number obtained from the
service provider. In addition, the callee subscribes to the Number Portability service from a
new service provider. Before routing the call request to the terminating I-CSCF, the
originating entity does not query the Number Portability data. When the terminating I-CSCF
receives the call request and successfully obtains the Number Portability data, it returns the
response code and cause code to the originating entity and rejects the call request. The call
flow is as follows:
1. The originating S-CSCF initiates a call.
2. The terminating I-CSCF receives the call and performs an QoR query according to the
local configurations.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 286

3. The NPDB returns the RN associated with the callee.

4. Based on the RN, the I-CSCF returns a response in which the Reason header contains the
cause code and rejects the call request.
Basic Flow
This section takes the NPDB as an example to describe the basic flow of the Number
Portability data query of the S-CSCF/I-CSCF. The S-CSCF queries the NPDB for the RN of
the new carrier serving the callee, and then routes the session request to the callee based on
the RN. The I-CSCF queries the NPDB for the RN of the new carrier serving the callee, and
then routes the session request to the callee based on the RN or returns a response to instruct
the originating entity to query the Number Portability data.
Figure 2-60 shows the service flow of the Number Portability service in ACQ mode.

Figure 2-54 Service flow of the Number Portability service in ACQ mode supported by the IMS
network

The flow of the Number Portability service in ACQ mode supported by the IMS network is as
follows:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 287

1. The IMS network receives a call, and the S-CSCF checks that the called number is an
E.164 number.
2. Based on the local configuration, the S-CSCF determines whether to query the ENUM.
By default, the S-CSCF queries the ENUM, and then the NPDB. For certain numbers of
subscribers who do not have the ENUM/Number Portability service active, you can
configure not to query ENUM and NPDB, or configure to query either ENUM or NPDB,
or to query both of them (ENUM takes the precedence for query in this case), through
the SENUMNP (ENUM/Number Portability Query Policy of S-CSCF) table.
This service procedure assumes that both ENUM and NPDB must be queried. Therefore,
the S-CSCF queries ENUM, and then NPDB.
3. The S-CSCF queries the ENUM.
− If the S-CSCF queries the ENUM and obtains the SIP URI of the called number or
the tel URI that carries the CIC parameter, the S-CSCF routes the call to the network
serving the callee based on the SIP URI.
− If the ENUM does not return the SIP URI of the called number or the tel URI that
carries the CIC parameter, the S-CSCF queries the NPDB.
4. The NPDB returns the query result. If the callee has the Number Portability service
active, the NPDB returns the Number Portability information of the callee.
For example, if the original called number is tel:+12-34-567 and the callee has
subscribed to the Number Portability service, the NPDB returns a NAPTR record in the
following format: tel:+12-34-567;npdi;rn=16d1. Then, the originating S-CSCF replaces
the original Request-URI with a new TEL URI, and thus the Request-URI contains the
npdi;rn=16d1 information. The npdi parameter indicates that the NPDB is queried for
this call, and the rn=16d1 parameter indicates that the RN is 16d1.
5. The originating S-CSCF performs number analysis based on the RN and routes the call
to the MGCF that maps this RN.
6. Based on the RN contained in the Request-URI, the MGCF queries the local
configuration table for routing.

The Number Portability service in QoR mode supported by the I-CSCF is similar to the Number
Portability service in ACQ mode. The difference is that the I-CSCF returns a mapping response code
(410, by default) and cause code to the originating entity and rejects the call request, or routes the call
request to the new carrier serving the callee based on the Number Portability query result.

Enhancement
Table 2-67 lists the release history of the Number Portability feature.

Table 2-61 Release history of the Number Portability feature

History Version Details Release Plan
Initial release V100R003C02 - -

Dependency
The Number Portability feature does not have any interaction with other features.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 288

2.24 MI2S0CSCGR00 Geographical Redundancy

Availability
This feature is introduced in CSC3300 V100R006.
This feature requires the coordination of the P-CSCF, I-CSCF, S-CSCF, subscriber terminal,
and SBC/MSAN.

Summary
Affected by uncontrollable factors (such as natural calamities, wars, power failures) or
internal faults of the CSCFs (such as system breakdown caused by software or hardware
faults, active/standby failover failures caused by internal fault detection failure of the CSCF,
and the communication failures between the CSCFs and the interconnected entities and
terminals), the CSCFs in an area may fail to serve the subscribers in that area. Using the
geographical redundancy feature, the CSC3300 can automatically detect the failure of a CSCF
and select another entity in another area that provides the same services to process the
subsequent service requests from subscribers. Thus, subscribers can enjoy complete services
as usual.

Benefits
For subscribers
This feature enables subscribers to enjoy services even under emergency conditions,
such as natural calamities, wars, power failures.
For carriers
This feature improves network reliability, reduces carrier loss, and enhances carrier
credibility.

Description
Logical networking

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 289

Fault detection
The UE/SBC/MSAN periodically sends OPTIONS messages to its peer entity to check
whether the peer end is faulty. The period and fault identifying conditions are configurable,
which balances the detection sensitivity and performance. See the following figure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 290

The CSCF adopts the heuristic OPTION detection mechanism to detect faults on the peer
entity. The detection mechanism is applied only when a fault occurs, and in addition, the
detection traffic is generated. In the heuristic OPTION detection mechanism, an entity (for
example, the P-CSCF) sends messages to the peer entity and enables OPTION detection if the
peer entity does not respond. At the same time, the entity adds the peer entity to the fault list
and periodically checks whether the fault is restored. In a specified detection period, if the
peer entity responds to the OPTION detecting message, it indicates that the peer entity has
recovered. In this case, the P-CSCF stops sending OPTION messages and removes the peer
entity from the fault list. This function is applicable to the fault detection between the CSCF
and various logical NEs. See the following figure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 291

The CSCF detects the HSS: The Diameter message is borne over connection-oriented
protocols; therefore, the CSCF checks whether the HSS is faulty by checking the links. The
method is similar to that of sending OPTION messages periodically, in which the detection
period and fault identifying conditions are configurable. For example, the CSCF sends
handshake messages to the HSS each five seconds, and the CSCF considers that the HSS is
faulty if the HSS does not respond to three consecutive OPTION messages.
Switchover on fault
When detecting that CSCF1 is faulty, the terminal or SBC/MSAN sends a registration or call
setup message to CSCF2. After the successful registration, the registration information is
updated to the HSS. In this case, the subscriber information can be restored from the HSS
during a call. See the following figure.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 292

Changeback on recovery
When CSCF1 is restored, you can manually issue a command to the MSAN to instruct the
MSAN to send subsequent services to CSCF1. In this case, the services on CSCF1 are
recovered, which helps to reduce the load of CSCF2.

Enhancement
The geographical redundancy feature is provided from CSC3300 V100R005. When a disaster
occurs, the CSC3300 sends a 533 response to notify the subscriber to restore data through
re-registration.
The geographical redundancy in full-proxy SBC mode is provided from CSC3300 V100R006,
which supports the call connection even if no subscriber data is configured.
The terminal-based geographical redundancy is provided from CSC3300 V100R006, which
supports subscriber load migration and subscriber changeback on fault recovery.

Dependency
None

2.25 MI2SCSCFMT00 Media Transcoding Control

Summary
The Media Transcoding Control feature enables media streams of the calling party or called
party to be converted to the codec format supported by the other party during multimedia
sessions.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 293

To ensure communication between two terminals, the two terminals must support the same
media codec type. Generally, this requirement is easily satisfied for terminals in the same
network, as terminals in the same network often support same codecs. Terminals in different
networks may not support same codecs. For example, assume that IMS terminal A supports
only the audio codec AMR, and PSTN terminal B supports only the audio codec G.711. If A
attempts to communicate with B, the communication cannot be established. In this case, a
transcoder should be added between A and B. The transcoder converts the codec G.711 sent by
B to the codec AMR supported by A and converts the codec AMR sent by A to the codec
G.711 supported by B, thereby enabling communication between A and B.
In the IMS architecture, the interconnection border control function (IBCF), together with the
interconnection border gateway function (I-BGF), implements the media transcoding
function.

Benefits
Table 2-68 describes the benefits of the Media Transcoding Control feature.

Table 2-62 Benefits of the Media Transcoding Control feature

For... Benefits

Carriers This feature improves the call completion

rate and user satisfaction, thereby increasing
carriers' revenues.
Subscribers This feature enables subscribers whose
terminals support different codecs to
communicate with each other.

Availability
Table 2-69 describes the requirements for implementing the Media Transcoding Control
feature.

Table 2-63 Requirements for implementing the Media Transcoding Control feature

Required NE Required Version License Support

IBCF CSC3300 V100R006C02 or A license is required for the
later implementation of this
feature.
I-BGF MRP6600 V300R002C02 or A license is required for the
later implementation of this
feature.

Dependency
None.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 294

Description
During a SIP session, the calling party and called party use the SDP offer/answer model to
negotiate the media codec to be used.
Assume that UE A in IMS 1 supports only audio codec 1 and UE B in IMS 2 supports only
audio codec 2. When A attempts to communicate with B, the communication cannot be
established. The call flow is as follows:
1. A sends an INVITE message to B, in which the SDP contains audio codec 1.
2. After receiving the INVITE message, B finds that it does not support audio codec 1
contained in the SDP of the INVITE message. Then, B returns a 488 response to A.
3. After receiving the 488 response, A sends an ACK message to B. The session is released.
If the IBCF and I-BGF are deployed between IMS 1 and IMS 2 to support codec transcoding,
the communication between A and B can be established, as shown in Figure 2-61. During the
call, the IBCF and I-BGF implement media transcoding. On the signaling plane, the IBCF
modifies the SDP contents of the calling party and the called party to ensure a successful
media negotiation. On the media plane, the IBCF instructs the I-BGF to convert audio codecs
1 and 2. Figure 2-61 uses an offer/answer model where the INVITE message contains the
offer and the 200 response contains the answer. In practice, other SIP messages can be used to
implement an offer/answer.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 295

Figure 2-55 Media transcoding process

IMS 1 IBCF I-BGF IMS 2

1. INVITE (SDP offer)

Audio (Codec1) 2. Add_Request

3. Add_ Reply

4 . INVITE (SDP offer)

Audio (Codec1 Codec2)

5 . 200 (SDP answer)

Audio (Codec2)
6. Add_ Request

7. Add_Reply

8. Mod_Request

9. Mod_Reply
10. 200 (SDP answer)
Audio (Codec1)

11. ACK
12. ACK

13. Media (Codec1) 14. Media (Codec2)

15. BYE
16. BYE

17. 200
18. 200

19. Sub_Request

20. Sub_Reply

21. Sub_Request

22. Sub_Reply

The detailed process is as follows:

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 296

1. The IBCF receives an INVITE message from UE A in IMS 1, in which the SDP contains
audio codec 1.
2. The IBCF enables the transcoding function and sends an Add_Request message over the Ix
interface to the I-BGF, requesting media resources from IMS 2 for audio codec 1.
3. The I-BGF successfully allocates media resources and sends an Add_Reply message to the
IBCF.
4. The IBCF learns that the I-BGF supports codecs 1 and 2, places audio codec 2 behind audio
codec 1 in the SDP, and forwards the INVITE message to IMS 2.
5. UE B in IMS 2 receives the INVITE message and returns a 200 response, in which the SDP
contains audio codec 2. The IBCF receives the 200 response and learns that audio codec 2
supported by UE B is the codec added by itself.
6. The IBCF sends an Add_Request message to the I-BGF, requesting media resources from
IMS 1 for audio codec 1.
7. The I-BGF successfully allocates media resources and sends an Add_Reply message to the
IBCF.
8. The IBCF sends a Mod_Request message to the I-BGF, requesting the I-BGF to change
media resources from IMS 2, that is, to change the audio codec format to audio codec 2.
9. The I-BGF enables the transcoding function and returns a Mod_Reply response.
10. The IBCF converts audio codec 2 to audio codec 1 in the SDP and forwards the 200
response to IMS 1.
11. UE A receives the 200 response and sends an ACK message to the IBCF.
12. The IBCF forwards the ACK message to IMS 2. The session is established successfully.
13-14: After the media streams are established successfully, the I-BGF changes audio codec 1
sent by UE A to audio codec 2 and sends audio codec 2 to UE B; the I-BGF also changes
audio codec 2 sent by UE B to audio codec 1 and sends audio codec 1 to UE A.
15-18: After the session is completed, the IBCF forwards the BYE request and 200 response.
19-22: The IBCF sends a Sub_Request message over the Ix message, instructing the I-BGF to
release the media transcoding resources. After releasing the media transcoding resources, the
I-BGF returns a Sub_Reply response to the IBCF.

If the codec types of the calling party and the called party are the same but related parameters, such as
Ptime, resolution rate, frame rate, or code rate, are different, the transcoding function is required.

Enhancement
Table 2-70 lists the release history of the Media Transcoding Control feature.

Table 2-64 Release history of the Media Transcoding Control feature

Feature Version Release Version Details Release Plan

01 CSC3300 Initial release. N/A
V100R008C02

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 297

2.26 MI2SIBCFCR00 Trunk-based Call Restriction

Summary
The Trunk-based Call Restriction service allows the interconnection border control function
(IBCF) to limit the maximum number of concurrent calls according to carriers' requirements.
This prevents trunk failures caused by trunk overload.

Benefits
Table 2-71 describes the benefits of the Trunk-based Call Restriction service.

Table 2-65 Benefits of the Trunk-based Call Restriction service

For... Benefits
Carriers Carriers can plan the traffic of SIP trunks
based on their bearer capability to prevent
network congestion.

Availability
Table 2-72 describes the requirements for implementing the Trunk-based Call Restriction
service.

Table 2-66 Requirements for implementing the Trunk-based Call Restriction service

NE Version License Requirements

IBCF CSC3300 V100R008C02 or A license is required for this
later service.

Dependency
Table 2-73 describes the interaction between the Trunk-based Call Restriction service and
other services.

Table 2-67 Interaction between the Trunk-based Call Restriction service and other services
Service Interaction
Trunk Selection When the number of concurrent calls routed
over an incoming trunk reaches the
maximum value, the IBCF rejects new calls.
When the number of concurrent calls routed
over an outgoing trunk reaches the
maximum value, the IBCF selects another
trunk.
Emergency Call For emergency calls, the IBCF does not

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 298

Service Interaction
restrict the number of concurrent calls
routed over incoming trunks or outgoing
trunks.

Description
Figure 2-62 shows the procedure for implementing the Trunk-based Call Restriction service
for an incoming call.

Figure 2-56 Procedure for implementing the Trunk-based Call Restriction service for an incoming
call

The flow works as follows:

1. After receiving an initial INVITE message, the IBCF performs incoming route analysis and
checks the trunk group policies.
2. After detecting that the number of concurrent calls over the current SIP trunk or trunk
group reaches the maximum value, the IBCF returns a 403 message to reject the call.
Figure 2-63 shows the procedure for implementing the Trunk-based Call Restriction service
for an outgoing call.

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 299

Figure 2-57 Procedure for implementing the Trunk-based Call Restriction service for an outgoing
call

The flow works as follows:

1. After receiving an initial INVITE message, the IBCF performs outgoing route analysis.
2. After detecting that the number of concurrent calls over the current SIP trunk or trunk
group reaches the maximum value, the IBCF selects another one.

Enhancement
Table 2-74 lists the release history of the Trunk-based Call Restriction service.

Table 2-68 Release history of the Trunk-based Call Restriction service

Feature Version Release Version Details Release Plan

01 CSC3300 First release. None.
V100R008C02

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 300

Copyright © Huawei Technologies Co., Ltd.
HUAWEI CSC3300 Call Session Controller
Feature Description 3 Acronyms and Abbreviations

3 Acronyms and Abbreviations

Table 3-1 List of acronyms and abbreviations

Acronyms & Abbreviation Expansion

HSS Home Subscriber Server
CSCF Call Session Control Function
I-CSCF Interrogating-CSCF
DNS Domain Name System
AS Application Server
PSTN Public Switched Telephone Network
IMS IP Multimedia Core Network Subsystem
MGCF Media Gateway Control Function
UA User agent
UAC User agent client
UAS User agent server
B2BUA Back-to-Back User Agent

Issue 01 (2012-08-24) Huawei Proprietary and Confidential 301

ADC01-DOC-146 ADVC Protocol Manual DNP3 R15 WEB PDF
No ratings yet
ADC01-DOC-146 ADVC Protocol Manual DNP3 R15 WEB PDF
40 pages
Huawei SPS Convergent Solution For IPSTP and DA v1.0
No ratings yet
Huawei SPS Convergent Solution For IPSTP and DA v1.0
53 pages
Technical White Paper For Huawei SPS Signaling Accounting
No ratings yet
Technical White Paper For Huawei SPS Signaling Accounting
31 pages
EE653 OpenDSS Tutorial and Cases
100% (1)
EE653 OpenDSS Tutorial and Cases
403 pages
ATS9900 Ro Interface Specifications
No ratings yet
ATS9900 Ro Interface Specifications
69 pages
Update Instructions For MMI 3G v1.7
No ratings yet
Update Instructions For MMI 3G v1.7
49 pages
Online Charging Description Document (FMC) : HUAWEI ATS9900 Advanced Telephony Server V100R006C10SPC200
100% (1)
Online Charging Description Document (FMC) : HUAWEI ATS9900 Advanced Telephony Server V100R006C10SPC200
94 pages
7-IPv6 HSI CGN Solution Introduction PDF
No ratings yet
7-IPv6 HSI CGN Solution Introduction PDF
77 pages
Huawei 5671d79a0462d
100% (1)
Huawei 5671d79a0462d
205 pages
Huber-Suhner. 5G Functional Split
No ratings yet
Huber-Suhner. 5G Functional Split
1 page
UMTS CS Protocols and Signaling Analysis
100% (1)
UMTS CS Protocols and Signaling Analysis
446 pages
Huawei
No ratings yet
Huawei
205 pages
CEM Solution Overview - VMB17012017 - For DRT PDF
No ratings yet
CEM Solution Overview - VMB17012017 - For DRT PDF
70 pages
Chapter 07
No ratings yet
Chapter 07
47 pages
Electrical Input Components 326D
No ratings yet
Electrical Input Components 326D
7 pages
SPS V300R007C10 Part II Operation Guide (Special)
No ratings yet
SPS V300R007C10 Part II Operation Guide (Special)
63 pages
Ims 11
No ratings yet
Ims 11
8 pages
SF CRM Cheatsheet Web PDF
No ratings yet
SF CRM Cheatsheet Web PDF
2 pages
01-14 Sip
100% (1)
01-14 Sip
20 pages
Class Diagram
No ratings yet
Class Diagram
47 pages
SPS V300R007C10 Part III Appendix
No ratings yet
SPS V300R007C10 Part III Appendix
7 pages
(IMS 8.2) CSCF H248 Feature Training
100% (1)
(IMS 8.2) CSCF H248 Feature Training
43 pages
HUAWEI UGW9811 Unified Gateway V900R010C00 Feature Description (EPSN Optional Feature)
No ratings yet
HUAWEI UGW9811 Unified Gateway V900R010C00 Feature Description (EPSN Optional Feature)
21 pages
C011206551 Microsoft Antitrust Case
No ratings yet
C011206551 Microsoft Antitrust Case
13 pages
R20 Cns-Lab-Manual-Iii-Cse-Ii-Sem
No ratings yet
R20 Cns-Lab-Manual-Iii-Cse-Ii-Sem
29 pages
ATS9900 V100R006C00 Feature List FT
No ratings yet
ATS9900 V100R006C00 Feature List FT
14 pages
01-Chapter 1 H.248
67% (3)
01-Chapter 1 H.248
22 pages
LTE Cell Planning-HW
0% (1)
LTE Cell Planning-HW
63 pages
Lenovo DS2200 Storage Configuration - NISHANT PANCHAL'S Blogs
No ratings yet
Lenovo DS2200 Storage Configuration - NISHANT PANCHAL'S Blogs
10 pages
MRP6600 V100R005C01 Feature Description
No ratings yet
MRP6600 V100R005C01 Feature Description
206 pages
HUAWEI UGW9811 Unified Gateway V900R010C00 Feature Description (GUL Optional Feature)
No ratings yet
HUAWEI UGW9811 Unified Gateway V900R010C00 Feature Description (GUL Optional Feature)
190 pages
Imanager U2000 Performance Management
No ratings yet
Imanager U2000 Performance Management
55 pages
Account Statement From 1 Jan 2020 To 13 Aug 2020: TXN Date Value Date Description Ref No./Cheque No. Debit Credit Balance
No ratings yet
Account Statement From 1 Jan 2020 To 13 Aug 2020: TXN Date Value Date Description Ref No./Cheque No. Debit Credit Balance
6 pages
OWD090901 (Slide) UGW9811 V900R009C01 System Overview-20120319-B-V1.1
No ratings yet
OWD090901 (Slide) UGW9811 V900R009C01 System Overview-20120319-B-V1.1
51 pages
Water 11 00562 v2
No ratings yet
Water 11 00562 v2
29 pages
தரம் 11 DNA அலகுப்பரீட்சை - வலிகாமம் கல்வி வலயம் Unit
No ratings yet
தரம் 11 DNA அலகுப்பரீட்சை - வலிகாமம் கல்வி வலயம் Unit
7 pages
Legend Update Guide EN IT v11
No ratings yet
Legend Update Guide EN IT v11
20 pages
Mod
No ratings yet
Mod
3 pages
Next Generation Networks (NGN) & The IP Multimedia Subsystem (IMS)
100% (1)
Next Generation Networks (NGN) & The IP Multimedia Subsystem (IMS)
39 pages
IMS Course 1
No ratings yet
IMS Course 1
57 pages
01 - Introduction To Telephony VoIP
No ratings yet
01 - Introduction To Telephony VoIP
42 pages
Credential Hunting - OSCP
No ratings yet
Credential Hunting - OSCP
9 pages
IMS Roaming & Interworking Guidelines
No ratings yet
IMS Roaming & Interworking Guidelines
32 pages
B Ultra Cloud Core CNDP Smi 5g Lab v1
No ratings yet
B Ultra Cloud Core CNDP Smi 5g Lab v1
62 pages
1 - Pdfsam - CX600 V800R007C00 Hardware Description 02 - 1 - 5
100% (1)
1 - Pdfsam - CX600 V800R007C00 Hardware Description 02 - 1 - 5
99 pages
ThinkCentre Neo 50s 11SY004HAC
No ratings yet
ThinkCentre Neo 50s 11SY004HAC
3 pages
1 USN9810 V900R011 Product Description PDF
100% (1)
1 USN9810 V900R011 Product Description PDF
67 pages
SE2900 Product Documentation V500R018C10 - 02 20191030150129
No ratings yet
SE2900 Product Documentation V500R018C10 - 02 20191030150129
7 pages
Next 1
No ratings yet
Next 1
139 pages
Valid 8 SIP Conformance Solution PDF
No ratings yet
Valid 8 SIP Conformance Solution PDF
9 pages
Difference Between NGN and Legacy TDM Network
50% (2)
Difference Between NGN and Legacy TDM Network
18 pages
07-IP QoS Technology Principle-20090724-A
No ratings yet
07-IP QoS Technology Principle-20090724-A
32 pages
Comparison Analysis On Feasible Solutions For LTE Based Next Generation Railway Mobile PDF
No ratings yet
Comparison Analysis On Feasible Solutions For LTE Based Next Generation Railway Mobile PDF
7 pages
UDM Redundancy Switchover Guide in Hybrid Networking
No ratings yet
UDM Redundancy Switchover Guide in Hybrid Networking
37 pages
Service Operations in Telecom Sector
No ratings yet
Service Operations in Telecom Sector
17 pages
IMS Kpi
No ratings yet
IMS Kpi
7 pages
1 - Imanager U2000-R V100R002 System Introduction ISSUE1.00
No ratings yet
1 - Imanager U2000-R V100R002 System Introduction ISSUE1.00
35 pages
CS Lab Manual - Merged
No ratings yet
CS Lab Manual - Merged
49 pages
PS Core
No ratings yet
PS Core
23 pages
Core Network NFV Proposal For Telcel
No ratings yet
Core Network NFV Proposal For Telcel
8 pages
Eudemon 1000E Series Firewall PDF
No ratings yet
Eudemon 1000E Series Firewall PDF
8 pages
Huawei WISP Solution v2.0
No ratings yet
Huawei WISP Solution v2.0
27 pages
Designing Scalable Modular Digital Data Centers FinalRev2
No ratings yet
Designing Scalable Modular Digital Data Centers FinalRev2
18 pages
QoS Requirements For VoIP
No ratings yet
QoS Requirements For VoIP
95 pages
OAX000200 SoftX3000 Data Configuration For h.323 Sip Terminal ISSUE2.0-20041018-A
No ratings yet
OAX000200 SoftX3000 Data Configuration For h.323 Sip Terminal ISSUE2.0-20041018-A
21 pages
CV AlessandroOliveira
No ratings yet
CV AlessandroOliveira
7 pages
Towards Quality and QOS Assessment For VoLTE - IMSWF
No ratings yet
Towards Quality and QOS Assessment For VoLTE - IMSWF
42 pages
GSM System Survey
100% (1)
GSM System Survey
156 pages
ConfigGuide TR 069
No ratings yet
ConfigGuide TR 069
110 pages
NGN Standards
No ratings yet
NGN Standards
30 pages
Specification: Short Message Service Centre External Machine Interface
No ratings yet
Specification: Short Message Service Centre External Machine Interface
68 pages
DVCon Europe 2015 P1 1 Poster
No ratings yet
DVCon Europe 2015 P1 1 Poster
1 page
M1-R5: Information Technology Tools and Network Basics SET - 01
No ratings yet
M1-R5: Information Technology Tools and Network Basics SET - 01
24 pages
OEB913313 USN9810 GTPV2 Singaling Analysis ISSUE1.00
No ratings yet
OEB913313 USN9810 GTPV2 Singaling Analysis ISSUE1.00
79 pages
Probe For Huawei N2000
No ratings yet
Probe For Huawei N2000
32 pages
4g Lte and Ims Network Performance Management PDF
No ratings yet
4g Lte and Ims Network Performance Management PDF
3 pages
##NGN Interconnection and Access
No ratings yet
##NGN Interconnection and Access
62 pages
SEQ Analyst Infomation Gateway 2013 Issue 2 (SEQ Analyst Solution Documentation) PDF
No ratings yet
SEQ Analyst Infomation Gateway 2013 Issue 2 (SEQ Analyst Solution Documentation) PDF
8 pages
WWW Mpirical Com Courses Volte
No ratings yet
WWW Mpirical Com Courses Volte
7 pages
3.09 Security Pillar
No ratings yet
3.09 Security Pillar
63 pages
Sps 7.2 Oas053201 Sps v3 (Dra) Data Configuration Issue 3.00
No ratings yet
Sps 7.2 Oas053201 Sps v3 (Dra) Data Configuration Issue 3.00
155 pages
SAP BP Quick Guide TimeTracking
No ratings yet
SAP BP Quick Guide TimeTracking
22 pages
Mas 6-1
No ratings yet
Mas 6-1
66 pages
Data Drive Test Format - Sep24-1
No ratings yet
Data Drive Test Format - Sep24-1
8 pages
Muhammad Personal Statement
No ratings yet
Muhammad Personal Statement
2 pages
7 Steps To Know IManager M2000 PRS and NetEco V1!0!20111126
No ratings yet
7 Steps To Know IManager M2000 PRS and NetEco V1!0!20111126
43 pages
OTA Product Description
No ratings yet
OTA Product Description
25 pages
Performance Analysis of Mobility Management in WIMAX Networks
No ratings yet
Performance Analysis of Mobility Management in WIMAX Networks
10 pages
A Novel Portable Augmented Reality Surgical Navi - 2024 - International Journal
No ratings yet
A Novel Portable Augmented Reality Surgical Navi - 2024 - International Journal
7 pages
HUAWEI SEQ Analyst Basic KPI Mannual
No ratings yet
HUAWEI SEQ Analyst Basic KPI Mannual
225 pages
IMS Architecture White Paper
No ratings yet
IMS Architecture White Paper
4 pages
Call Flow
No ratings yet
Call Flow
3 pages
IMS Network Architecture
No ratings yet
IMS Network Architecture
64 pages
Acs104 CC QB
No ratings yet
Acs104 CC QB
15 pages
MSWord2016 Tables
No ratings yet
MSWord2016 Tables
2 pages
Roundoff and Truncation Errors
No ratings yet
Roundoff and Truncation Errors
17 pages
Network performance Third Edition
From Everand
Network performance Third Edition
Gerardus Blokdyk
No ratings yet
IP Multimedia Subsystem IMS A Complete Guide
From Everand
IP Multimedia Subsystem IMS A Complete Guide
Gerardus Blokdyk
No ratings yet
Lte and Lte-Advanced Complete Self-Assessment Guide
From Everand
Lte and Lte-Advanced Complete Self-Assessment Guide
Gerardus Blokdyk
No ratings yet
Voice over LTE Standard Requirements
From Everand
Voice over LTE Standard Requirements
Gerardus Blokdyk
3/5 (1)
Diameter Protocol A Complete Guide
From Everand
Diameter Protocol A Complete Guide
Gerardus Blokdyk
No ratings yet
Drive testing The Ultimate Step-By-Step Guide
From Everand
Drive testing The Ultimate Step-By-Step Guide
Gerardus Blokdyk
No ratings yet
Connectivity Prediction in Mobile Ad Hoc Networks for Real-Time Control
From Everand
Connectivity Prediction in Mobile Ad Hoc Networks for Real-Time Control
Sebastian Thelen
5/5 (1)