Contents

1   Understanding Configuration Managementin the CSCF

This User Guide describes how to use the Configuration Management (CM) function in the Call Session Control Function (CSCF).

It also contains the prerequisites for using the CSCF CM function, a set of directives for how to use the CSCF CM function, and some examples of applied directives. The examples and parameter values contained in this document are to be used only as guidance.

1.1   Overview of the IMS Network

The IP Multimedia Subsystem (IMS) network in Figure 1 describes the interfaces of the CSCF in a high logical abstract layer.

1.2   Overview of the Originating and Terminating CSCF

All traffic in an IMS network passes through the CSCF node. Traffic in telecommunications is called a "call", which corresponds to a Session Initiation Protocol (SIP) dialog. A call can be described by a half call model, where a half call divides a call into an originating half and a terminating half. The messages pass through the CSCF node of the operator in the originating side of a call, which serves the calling user. The originating CSCF node then forwards the messages to the matching CSCF node at the terminating side, which serves the called user. The Originating and Terminating CSCF can be the same physical node. There are also cases where only the originating or only the terminating CSCF node is involved, for example, if the call is initiated by, or terminated at, an Application Server (AS).

The CSCF node is divided in Interrogating CSCF (I-CSCF), Serving CSCF (S-CSCF), Emergency CSCF (E-CSCF), and Emergency Access Transfer Function (EATF) separate node types, according to 3GPP® IMS standards. The CSCF also contains the Break-in Control Function (BCF). It is also possible to collocate I-CSCF and S-CSCF in the same physical node. The IS-CSCF is a combined CSCF node type that includes all configuration attribute settings that are used by I-CSCF and S-CSCF together.

1.3   Configuration Methods

The Configuration Management of the CSCF is performed through Managed Objects (MOs). The operations on the MOs can be performed through a Common Operation and Maintenance (COM) Northbound Interface (NBI).

The CM interfaces provided by NBIs are the NETCONF and the Ericsson Command-Line Interface (ECLI). By default, the NETCONF interface and the ECLI are inactive. The activation procedure, Enabling COM, must be executed to be able to use these NBIs.

For more information on ECLI, see Ericsson Command-Line Interface User Guide.

The NETCONF interface is a Machine to Machine (M2M) interface, accessed through a Secure Shell (SSH) client. The default port for NETCONF SSH connection is 830.

The Ericsson Common Information Model (ECIM) compliant Managed Object Model (MOM) is used with NETCONF and ECLI.

For more information about CSCF-related configuration attributes, see Managed Object Model (MOM).

The CSCF ECIM model, which also outlines the top-level MOM and the first-level Managed Object Classes (MOCs), is shown in Figure 2. The CSCF application-specific configuration parameters are structured into the following fragments contained in CscfFunction:

1.4   User Authentication and Management

Only authorized users can configure the system. The user management principles, user administration, user roles, and authentication methods are described in User Management.

2   Operating Procedures

2.1   CSCF General Tasks

2.1.1   Configure Basic CSCF Functionality

2.1.1.1   Configure Common Components

If the CSCF is collocated with other applications on the same physical platform, and they use the same common components, the configuration of these common components is used by all applications.

This document only considers the configuration of common components from a standalone CSCF application point of view.

2.1.1.1.1   Configure DNS/ENUM Client

The DNS client is a user of the DNS system and performs SIP or TEL lookups (ENUM).

The Domain Name System Server (DNS) is used by the DNS client. All queries not stored in the local cache are forwarded to an external name server. The DNS stack uses the protocol to perform DNS lookups to an external DNS server. A name server periodically checks to ensure that its zones are up-to-date, and if not, obtains a new copy of updated zones from master files stored locally or in another name server.

The CSCF periodically monitors the configured DNS servers by sending queries for the domain availability.test according to RFC 6761. If the DNS servers are not compliant with the RFC, the environment variable DNS_SERVER_AVAILABILITY_QUERY_DOMAIN can be set to a domain known to the DNS server.

The DNS is configured using the available NBI with the CscfFunction fragment DNS-Application, see Section 1.3 Configuration Methods.

The settings for DNS are described in Table 1.

(1)  This is an environment variable.

Note:  

When any of these configuration attributes are changed, the DNS reacts to the change. Some entries are discarded if the maximum size of the cache is reduced below the number of currently used cache entries.

In addition to the common component configuration, the CSCF attributes related to ENUM are shown in Table 2.

When the attribute cscfEnumForLocalNumbersEnabled is set to true, even local numbers returned from Number Normalization perform an ENUM query. When it is set to false, the ENUM query is suppressed when a local number is returned from Number Normalization.

The CSCF is configured using the available NBI with the CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

2.1.1.1.2   Configure Number Normalization

The Number Normalization function converts local, national, and international numbers as well as Operator Service Numbers (OSNs) and National Significant Numbers (NSNs), to fully internationalized numbers. This functionality can be applied to any URI.

The Number Normalization provides profiles to cater for large data associated normalization. Profiles can be used to support number plans for more than one country. They can be also used to order Numbering Plans for countries on region or city basis.

The Number Normalization is configured using the available NBI with the CscfFunction fragment NumberNormalisation, see Section 1.3 Configuration Methods.

In addition to the common component configuration, the CSCF attributes that are related to Number Normalization of global (international) telephone numbers are shown in Table 3.

The CSCF is configured using the available NBI with the CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

To enable Number Normalization of global numbers:

1. Configure the phone context to use for normalizing global numbers in cscfGlobalNumberNormalizationPhoneContext.
2. Set cscfEnableGlobalNumberNormalization to true.

For local numbers, the S-CSCF reads the phone context from the phone context attribute in the Request-URI. If the phone context attribute is not received in a SIP URI, the phone context is read from user data received from the Home Subscriber Server (HSS). If this is also empty, the S-CSCF reads the phone context from the configuration of attribute cscfPhoneContext. As a last option, if not configured, the S-CSCF name configured in the scscfDomainNameEntry is used. If the phone context is not received in a tel URI, the request is rejected.

Attribute scscfAddPhoneContext defines the originating S-CSCF handling of the phone context attribute at originating requests including a Request-URI containing a local telephone number in a SIP URI or tel URI form, as follows:

• 0: NO_MODIFICATION_OF_REQUEST_URI, S-CSCF does not modify phone context attribute in the Request-URI.
• 1: ADD_PHONE_CONTEXT_IN_REQUEST_URI, S-CSCF is to add a phone context attribute when receiving a Request-URI containing a local telephone number in a SIP URI without any phone context attribute.
• 2: ADD_OR_OVERWRITE_PHONE_CONTEXT_IN_REQUEST_URI, S-CSCF is to add or overwrite a phone context attribute when receiving a Request-URI containing a local telephone number in a SIP URI. A received tel URI gets its phone context overwritten.

Attribute ecscfEmergencyPhoneContext defines the emergency phone context to be used as input to Number Normalization together with the telephone number received from the Location Retrieval Function (LRF), or if the telephone number received from the LRF is a non-international number.

Attribute scscfEmergencyPhoneContext defines the phone context to be used as input to Number Normalization when handling emergency calls in the S-CSCF.

The CSCF does not use the error correction for missing user=phone provided by the Number Normalization common component. This means that the following attributes are not used by the CSCF:

• numNormProfileUserEqPhoneEr
• numNormProfileDomNameEr

The CSCF does not use the phone context provided by the Number Normalization function for NSN numbers and OSN numbers. Therefore, the first entry of numNormNsnDataNumbers and the first entry of numNormOsnDataContextAndNumbers are not used by the CSCF.

2.1.1.2   Configure Diameter Stack

The Diameter stack is configured using the available NBI with the CscfFunction fragment DIA-CFG-Application, see Section 1.3 Configuration Methods.

For more information about the Diameter_Stack interface, contact next level of support.

The following four CSCF interface container keys appear in the tree on the left panel:

• ManagedElement=1,CscfFunction=1,DIA-CFG-Application=DIA,DIA-CFG-StackContainer=CSCFCX
• ManagedElement=1,CscfFunction=1,DIA-CFG-Application=DIA,DIA-CFG-StackContainer=CSCFRF
• ManagedElement=1,CscfFunction=1,DIA-CFG-Application=DIA,DIA-CFG-StackContainer=CSCFRO

This container interface is created in DiameterInstallerProc when the Diameter_Stack starts.

CSCFCX is used for Cx, Dx, Sh, and Dh interfaces, CSCFRF is used for Rf interface, and CSCFRO is used for Ro interface. These attributes can be configured in the following combinations:

• Combined IS-CSCF (Cx/Dx, Rf, and Ro)
• I-CSCF (only for Cx/Dx)
• S-CSCF (Cx/Dx, Rf, and Ro)
• E-CSCF (Rf and Sh/Dh)
• BCF (only for Cx/Dx)

Stack IDs, port numbers, and example of host IDs for different node types are shown in Table 4.

Note:  

Each interface must have different IP addresses and host IDs.

2.1.1.2.1   Configure SCTP-Only Stack Mode

Note:  

For all Diameter protocol reference points (Cx, Ro, and so on) that use Diameter over SCTP, no configuration changes are needed in the SS7 CAF configuration. The initial configuration of SS7 CAF is sufficient to use Diameter over SCTP.

To configure SS7 CAF to operate in Stream Control Transmission Protocol (SCTP)-Only Stack mode and enable Diameter over SCTP:

1. Do the SCTP-related flow policies and selection policies exist and are they configured in the Evolved Virtual Internet Protocol (eVIP) configuration?

   Yes: Proceed with Step 4.

   No: Continue with the next step.

2. Create the following flow policy entries in the eVIP configuration:

   ipv4: ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=cscf_sig_sp1,EvipFlowPolicies=1, EvipFlowPolicy=4cscf_diacx_sctp

   ipv6: ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=cscf_sig_sp1,EvipFlowPolicies=1, EvipFlowPolicy=6cscf_diacx_sctp

   Note:  

   The value for EvipAlb differs depending on the used eVIP configuration.

   
   
   • For the created flow entries, the attribute addressFamily is modified to ipv4 (4cscf_diacx_sctp) or ipv6 (6cscf_diacx_sctp) depending on the type of own Diameter IP address.
   • For the created flow entries, the attribute dest is modified to own Diameter IP address.
   • For the created flow entries, the attribute protocol is modified to sctp.
   • For the created flow entries, the attribute soGrp is modified to 1011250.
3. Create the following flow selection policy in the eVIP configuration:

   SCTP flow selection policy ManagedElement=1,Transport=1,Evip=1,EvipSelectionPolicies=1,EvipSelectionPolicy=ss7_caf_sctp.

   • For the created policy entry, the attribute alb is modified to cscf_sig_sp1.

     Note:  

     The value of this parameter must be aligned with the assigned value of EvipAlb.

     
     
   • For the created policy entry, the attribute process is modified to fe_sctp.
   • For the created policy entry, the attribute sortorder is modified to 20.000000.
4. For Diameter protocol communication that uses SCTP, make the following CSCF configuration changes:

   Note:  

   <protocolStackId> is CSCFCX for the Cx protocol.

   
   
   1. Configure the settings for own node by editing entry ManagedElement=1,CscfFunction=1,DIA-CFG-Application=DIA,DIA-CFG-StackContainer=<protocolStackId>,DIA-CFG-OwnNodeConfig=<protocolStackId> as follows:
      • Modify attribute SctpAddressesList and assign it the Diameter IP address of own node.
      • Modify attribute maxInboundSctpStreams to 17.
      • Modify attribute maxOutboundSctpStreams to 17.
      • Modify attribute transportLayerType to 3 (both SCTP and TCP).
   2. Configure the settings for each Peer node that uses Diameter over SCTP by editing entry ManagedElement=1,CscfFunction=1,DIA-CFG-Application=DIA,DIA-CFG-StackContainer=<protocolStackId>,DIA-CFG-PeerNodeContainer=<protocolStackID>,DIA-CFG-NeighbourNode=<peerNodeId> as follows:
      • Modify attribute enabled to false.
      • Modify attribute sctpAddressesList and assign it the peer node IP address.
      • Modify transportLayerType to 2 (SCTP only).
      • Modify attribute enabled to true.

For more information about Diameter, contact next level of support.

2.1.1.3   Configure CSCF Common Attributes

The CSCF is configured using the available NBI with the CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

The settings for the CSCF Common Configuration are described in Table 5.

The settings for the CSCF Charging Configuration are described in Table 6.

2.1.1.3.1   cscfAdministrativeState

The cscfAdministrativeState must be set to LOCKED before starting network interface configuration.

2.1.1.3.2   cscfISPBehavior

The cscfISPBehavior attribute determines which of the CSCF applications I-CSCF or S-CSCF that applies.

Note:  

P-CSCF is not supported.

2.1.1.3.3   bcfEnabled

The bcfEnabled attribute determines if the CSCF application BCF applies.

2.1.1.3.4   ecscfEnabled

The ecscfEnabled attribute determines if the CSCF application E-CSCF applies.

2.1.1.3.5   ecscfEatfEnabled

The ecscfEatfEnabled attribute is configured in E-CSCF to trigger the invocation of the EATF. This attribute is not used to activate the EATF role in the network element.

2.1.1.3.6   eatfEnabled

The eatfEnabledattribute determines if the CSCF application EATF applies.

2.1.1.3.7   Cx/Dx/Sh/Dh Diameter Interface

The operator can deploy the HSS/SLF in a few ways, considering load sharing and redundancy aspects.

From a CSCF application point of view, configure the following four attributes for the behavior of the Cx, Dx, Sh, and Dh interfaces:

• cscfCXOriginRealm and cscfCXOriginHost identify the CSCF that sends the Diameter message to the Diameter server (the HSS/SLF). These are always configured in the same way independently of the HSS/SLF behavior.
• cscfCxDestinationRealm and cscfCxDestinationHost specify the HSS/SLF realm and host address, where the Diameter messages are sent. If an SLF or an HSS redundant cluster is used in the network, the cscfCxDestinationHost must be set to NotConfigured. If a single instance HSS is used, the host address of that HSS is to be configured in cscfCxDestinationHost.

Apart from the CSCF application attributes, the HSS/SLF deployment depends on the Diameter configuration.

Some examples are shown in Figure 3, Figure 4, and Figure 5.

One HSS in the network, which has geographical redundancy, is shown in Figure 3. In this case, cscfCxDestinationRealm=HSSrealm.operator.net and cscfCxDestinationHost=PrimaryHSS.operator.net. The Diameter configuration in the CSCF includes a Realm Routing Table for the HSSrealm.operator.net where PrimaryHSS Destination Host is a Peer Node and SecondaryHSS is configured as secondaryNodeIds. In addition, the two HSS nodes are configured with Diameter NetRed, but this is outside the CSCF configuration.

Two HSSs in the network, without any redundancy, are shown in Figure 4. An SLF is used to select which HSS that is used based on which subscriber it concerns. In this case, cscfCxDestinationRealm=HSSrealm.operator.net and cscfCxDestinationHost=NotConfigured. The Diameter configuration in the CSCF includes a Realm Routing Table for the HSSrealm.operator.net where SLF Destination Host is a Peer Node. Both HSS1 and HSS2 are configured as Peer Nodes to the CSCF (outside the Realm Routing Table). The CSCF configuration is independent of whether the SLF runs in a proxy or redirect mode.

The HSS in a layered architecture is shown in Figure 5, where the SLF node is used to load balance between several HSS FEs and the subscription data is stored in a back-end system Centralized User Database (CUDB). In this case cscfCxDestinationRealm=HSSrealm.operator.net and cscfCxDestinationHost=NotConfigured. The Diameter configuration in the CSCF includes a Realm Routing Table for the HSSrealm.operator.net where SLF Destination Host is a Peer Node. None of the HSS FE nodes are configured as Peer Nodes to the CSCF. As a result, the subsequent request falls back to realm routing, that is, routing to the SLF node independent of which HSS FE that responded to the request from the CSCF.

2.1.1.3.8   cscfDomainAlias

cscfDomainAlias is used for the following functionality:

• S-CSCF:

  Originating S-CSCF uses cscfDomainAlias to determine if a SIP URI that contains a telephone number is to be treated as telephone number or if the SIP URI is to be routed normally using the domain part.

  Any application that requires that this type of SIP URI is to be handled as a telephone number must configure the cscfDomainAlias with the relevant domains, for example, domain.com.

cscfDomainAlias can include multiple domains.

2.1.1.3.9   E/I/S-CSCF, BCF, EATF Domain Names

The domain name, in the form of a Fully Qualified Domain Name (FQDN), of each CSCF node type is configured in IcscfDomainNameEntry, ScscfDomainNameEntry, EcscfDomainNameEntry, BcfDomainNameEntry, and eatfDomainNameEntry respectively.

2.1.1.3.10   CSCF Network Interface

The network interface is configured using the available CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

Click CscfNwIfContainerKey=0 in the tree on the left panel.

The following CSCF interface container keys are displayed:

• BcfNwIfContainerKey=0
• IcscfNwIfContainerKey=0
• ScscfNwIfContainerKey=0
• EcscfNwIfContainerKey=0
• eatfNwIfContainerKey=0

These container interfaces are created by the system when the CSCF starts.

It is recommended to have each CSCF node in an own VIP interface. External interface is, for example, DNS, O&M, Cx, and Rf. For more information, see CSCF VNF Network Connectivity Overview.

The node ports in the CSCF are shown in Table 7.

2.1.1.3.11   Enable CSCF

To enable the CSCF:

1. Set the attributes described in the following sections:
   • Section 2.1.1.1.1 Configure DNS/ENUM Client
   • Section 2.1.1.1.2 Configure Number Normalization
   • Section 2.1.1.2 Configure Diameter Stack
   • Section 2.1.1.3 Configure CSCF Common Attributes
   • Section 2.1.1.4 Configure CSCF Charging Attributes

   Note:  

   The Number Normalization configuration attributes and the charging configuration attributes are only set if applicable except cscfChargingInterOpId, which is mandatory for the S-CSCF and E-CSCF.

   
   
2. Connect to the CSCF node using the NBI with CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.
3. Set the cscfISPBehavior to the desired node type.
4. Set the cscfAdministrativeState to UNLOCKED.

When the CSCF node is in unlocked mode, it is ready to receive SIP signaling.

For enabling the E-CSCF and ETAF, see Section 2.4.6.2 Enable Emergency Call with E-CSCF.

For enabling the BCF, see Section 2.4.1 Configure Break-In Control Function.

2.1.1.4   Configure CSCF Charging Attributes

The S-CSCF supports both online and offline charging. The E-CSCF supports offline charging.

The charging configuration consists of the common charging attributes and the charging triggers.

With the CSCF charging trigger functionality, the CSCF is able to define a few conditions that allow the determination of the charging actions.

There are three parts to the charging trigger as follows:

• Charging trigger
• Charging profile
• Charging Attribute-Value Pairs (AVPs)

Figure 6 illustrates the charging configuration components. A charging profile must be configured before it is referenced by the charging trigger.

For more information on common charging triggers, charging triggers, charging profile, and charging AVPs, see Managed Object Model (MOM).

2.1.1.4.1   Common Charging Attributes

The configuration attributes defining the general charging behavior must be defined and are shown in Table 8. These attributes are applicable to both S-CSCF and E-CSCF, unless explicitly indicated.

(1)  This attribute applies only to S-CSCF.

2.1.1.4.2   Charging Triggers

The S-CSCF and the E-CSCF start offline or online charging support, or both, after a successful validation of a set of charging trigger conditions. The charging trigger conditions are validated against the SIP information received and particular conditions of the SIP session.

A set of charging trigger conditions includes the following:

• Trigger attributes
• A group of charging trigger elements

The attribute scscfOfflineChargingTriggerAnalysisOnOutgoingRequest, which only applies to the S-CSCF, configures if the offline charging trigger evaluation is based on the outgoing SIP request or the incoming SIP request.

The possible values are

• Enabled: the content of the outgoing SIP request is used for the offline charging trigger evaluation.
• Disabled: the content of the incoming SIP request is used for the offline charging trigger evaluation.

Table 9 shows the trigger attributes and the trigger elements. For more information, see Managed Object Model (MOM).

(1)  The attributes apply to S-CSCF or E-CSCF with "x" replaced by "s" or "e", respectively.

(2)  This attribute is for future extension to support multiple sets of charging trigger conditions.

(3)  Multiple charging profiles can be available but only one profile can be referenced by a charging trigger.

(4)  Only one trigger group per trigger can be defined.

(5)  This trigger element is for S-CSCF only.

The trigger elements are optional conditions to be evaluated by the S-CSCF and the E-CSCF against the SIP session or SIP event operations. See Table 9 for a summary of the optional trigger elements. Except the trigger element for SIP method (xcscfChargingSipMethod), each of the trigger elements can be configured at most once in a trigger group. For example, at most one regular expression for Request-URI matching can be configured for a Request-URI-based trigger condition (xcscfChargingRequestUri). Multiple unique elements can be configured for a SIP method-based trigger condition. For example, three instances of the SIP method trigger element (xcscfChargingSipMethod) for INVITE, SUBSCRIBE, NOTIFY can be configured as three SIP method-based trigger conditions.

Each trigger element has a negated configuration attribute. If this attribute is set to true, that is, condition negated, the corresponding trigger element is successfully evaluated when the configured condition is not matched. If this attribute is set to false, that is, condition not negated, the corresponding trigger element is successfully evaluated when the configured condition is matched. Otherwise, the evaluation fails.

In Example 1, the trigger element evaluation is successful if the SIP request is not a SUBSCRIBE. The evaluation fails if the SIP request is a SUBSCRIBE.

scscfChargingSipMethod=SUBSCRIBE
scscfChargingSipMethodTriggerConditionNegated=true

In Example 2, the trigger element evaluation is successful if the SIP request is an INVITE. The evaluation fails if the SIP request is not an INVITE.

scscfChargingSipMethod=INVITE
scscfChargingSipMethodTriggerConditionNegated=false

Note:  

re-INVITE, UPDATE, and BYE are SIP methods within a successfully established SIP session. They are not configurable SIP method trigger elements. INVITE is the only configurable SIP method trigger for E-CSCF.

Within the charging trigger group, the charging trigger element evaluation results can be logically linked through AND or OR operators.

Operators configure the trigger attribute xcscfChargingTriggerConditionTypeCNF to combine all the trigger element evaluation results into a logical expression for the final evaluation. If the trigger attribute is set to true, a logical expression is formed to evaluate all trigger element evaluation results within the group with OR operations. The final evaluation is successful if any of the trigger element evaluations is successful. If the trigger attribute is set to false, a logical expression is formed to evaluate all trigger element evaluation results within the group with AND operations. The final evaluation is successful if all trigger element evaluations are successful. Otherwise the final evaluation fails.

In Example 3, the final evaluation is successful and charging is triggered if the SIP method is either an INVITE or a SUBSCRIBE. Charging is not triggered otherwise for other SIP methods.

scscfChargingTriggerConditionTypeCNF=true
scscfChargingSipMethod=INVITE
scscfChargingSipMethodTriggerConditionNegated=false
scscfChargingSipMethod=SUBSCRIBE
scscfChargingSipMethodTriggerConditionNegated=false

In Example 4, the final evaluation is successful and charging is triggered only for an INVITE with a tel URI in the Request-URI. Otherwise charging is not triggered.

scscfChargingTriggerConditionTypeCNF=false
scscfChargingSipMethod=INVITE
scscfChargingSipMethodTriggerConditionNegated=false
scscfChargingRequestUri=/^(.*)tel:(.+)$/
scscfChargingRequestUriTriggerConditionNegated=false

2.1.1.4.3   Charging Profiles

The charging profile contains the charging actions acted upon if charging trigger conditions are met.

Multiple charging profiles can be configured in the S-CSCF while only one charging profile can be configured in the E-CSCF. One charging profile can be referenced by a charging trigger through the charging trigger attribute scscfChargingProfileName or ecscfChargingProfileName for S-CSCF or E-CSCF, respectively. The charging profile is invoked on successful final evaluation of the charging trigger that references the profile.

A charging profile contains configuration information for offline or online charging support, or both.

Each charging profile contains the attribute scscfChargingCase or ecscfChargingCase for S-CSCF or E-CSCF, respectively, for offline or online charging support control, or both. See Table 10 for a summary of the configurable case values.

For S-CSCF, a charging profile can further contain a child profile for offline charging support configuration or a child profile for online charging support configuration, or both.

For E-CSCF, a charging profile can further contain a child profile for offline charging support configuration.

The offline or online child profile, or both, must be configured to specify the desired charging behavior. For more information, see section Section 2.1.1.4.5 Offline Charging Configuration Steps for charging configuration examples.

2.1.1.4.4   Charging AVPs

Charging AVPs are listed within the offline or online child profile, or both, of a charging profile.

S-CSCF and E-CSCF provide two variants of offline charging support. VARIANT_1 supports Diameter and 3GPP AVPs mostly specified in 3GPP specifications before release 7. VARIANT_2 supports offline charging based on 3GPP release 12 specifications. See CSCF Rf Interface for more details.

Offline charging variant is configured through offline charging profile attributes scscfOfflineChargingProfileVariant and ecscfOfflineChargingProfileVariant for S-CSCF and E-CSCF, respectively. The new variant value is applicable to SIP sessions/events established after the configuration switch. Ongoing SIP sessions and events that are established before the switch are subject to the previous variant configuration. The Charging Data Function (CDF) must be able to exchange ACR/ACA messages of the applicable variants with CSCF. Offline charging variant configuration can be switched during live traffic. However, it is recommended that variant switching takes place during low or no traffic period to minimize mixed ACR/ACA messaging from the two variants.

For VARIANT_1, different AVPs have different default settings for inclusion to or exclusion from an allowed Accounting-Request (ACR) message (Start, Interim, Stop, or Event, or a combination). Operators can configure if a specific AVP is generated or not in a specific ACR message.

For VARIANT_2, S-CSCF and E-CSCF are to generate an AVP in all allowed ACR messages by default. Operators can configure if a specific AVP is not to be generated. This configuration affects all ACR messages for the AVP.

For S-CSCF online charging, charging AVPs define if an optional AVP must be included in the Credit Control Request (CCR) message. If the charging AVP is not configured, it is not included in the CCR message.

2.1.1.4.5   Offline Charging Configuration Steps

Offline Charging Configuration – VARIANT_1 Example

See Table 8 for example values of the common charging attributes. These values are read by the S-CSCF and the E-CSCF for all charging support. See Table 11 for example values of the E-CSCF charging profile which specifies VARIANT_1 offline charging support.

(1)  This attribute is not applicable to VARIANT_1.

See Table 12 for example values for optional AVP configuration. For illustration purposes, the table shows only configurations of the Calling-Party-Address AVP for ACRs (Start, Interim, and Stop) and the Cause-Code AVP for ACRs (Stop and Event).

See Table 13 for example values of charging trigger attributes. For illustration purposes, only one trigger element is configured within the trigger group. The charging trigger references the charging profile ECSCF-PROF defined in Table 11 with the attribute ecscfChargingProfileName.

Offline Charging Configuration – VARIANT_2 Example

The next example illustrates S-CSCF VARIANT_2 offline charging configuration. See Table 8 for example values of the common charging attributes. See Table 14 for example values of the S-CSCF charging profile which specifies VARIANT_2 offline charging support only.

See Table 15 for example values for VARIANT_2 optional AVP omission configuration. For illustration purposes, the table does not configure to generate the 3GPP Message-Body AVP (Vendor Id=10415, AVP code=889), the Ericsson Event-NTP-Timestamp AVP (Vendor Id=193, AVP code=340), and the Ericsson Dial-Around-Indicator AVP (Vendor Id=193, AVP code=1160).

See Table 16 for example values of charging trigger attributes. Only two trigger elements, that is, SIP methods INVITE and REGISTER, are configured within the trigger group. The charging trigger references the charging profile SCSCF-PROF defined in Table 11 with the attribute scscfChargingProfileName.

2.1.2   Configure Password-Less Logon

Password-less logon is used to log on to the CSCF without entering a pass-phrase or a password. By default, they are required when logging on to the CSCF. Configuring password-less logon is optional.

The logon is configured using the ssh-agent daemon. The ssh-agent is started at a client side from where logon to the CSCF is done. The private key is stored in the client. The public key is deployed in the <user-home>/.ssh directory of the CSCF.

After password-less logon is configured, use SSH with the -A option to log on to the CSCF. The -A option enables the forwarding of the authentication agent connection. The forwarding of the authentication agent connection must be enabled with caution.

Note:  

After logging on to the system, the -A option is needed whenever using SSH inside the CSCF. For example, for logging on to the Payload. If the SSH private key is not recognized by the CSCF, a prompt for entering the password is displayed.

To configure the password-less logon:

1. Generate private and public keys and follow the on-screen instructions to save the keys on the client side:

   ssh-key-gen -t rsa

   Note:  

   Do not set a passphrase. Otherwise, the passphrase is required whenever using the password-less logon.

   
   

   > ssh-keygen -t rsa
   Generating public/private rsa key pair.
   Enter file in which to save the key (/home/cscfoperator/.ssh):
   Enter passphrase (empty for no passphrase): 
   Enter same passphrase again: 
   Your identification has been saved in /home/cscfoperator/.ssh/id_rsa.
   Your public key has been saved in /home/cscfoperator/.ssh/id_rsa.pub.
   

   Result:
   A private file id_rsa and a public file id_rsa.pub are created in the destination of choice on the client.
2. Set up the ssh-agent on the client side:

   ssh-agent bash

   ssh-add <path-to-location-of-private-key>/id_rsa

3. Deploy the public key to the CSCF:
   1. If the .ssh directory does not exist in users home directory on the CSCF, create it:

      mkdir -p $HOME/.ssh -m700

   2. Copy the id_rsa.pub to the .ssh directory:

      scp id_rsa.pub <username>@OAM IP:$HOME/.ssh

4. Log on to the CSCF:

   ssh <username>@<OAM IP>

5. Copy the content of id_rsa.pub to the authorized_keys file:

   cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys

6. Verify that the password-less logon is configured successfully:
   1. Log off from the CSCF:

      exit

   2. Log on to the CSCF again using the -A option:

      ssh -A <username>@<OAM IP>

2.1.3   Configure a Unique Prompt Prefix

A unique custom prompt prefix can be configured to CSCF nodes using Ericsson Command-Line Interface (ECLI).

To configure the unique custom prompt prefix:

1. Log on to the ECLI:

   ssh <oam-user>@<OAM-MIP> -p 2022

2. Check the value of the networkManagedElementId attribute:

   show -v ManagedElement=1

   The following example output shows that the value of networkManagedElementId is an empty string []:

   ManagedElement=1 dateTimeOffset=[] <empty> <read-only> <deprecated> dnPrefix=[] <empty> localDateTime=[] <empty> <read-only> <deprecated> managedElementId="1" managedElementType="vCSCF" <read-only> networkManagedElementId=[] <empty> release="1.8.0-4" <read-only> siteLocation=[] <empty> timeZone=[] <empty> <read-only> <deprecated> userLabel=[] <empty> productIdentity=[] <empty> <deprecated> CscfFunction=1 Equipment=1 SystemFunctions=1 Transport=1

3. Change the value of the networkManagedElementId attribute to give the node a name, such as CSCF:

   (ManagedElement=NODE06ST)> configure

   (config)> networkManagedElementId="<prompt prefix>"

   (config)> commit

4. Verify that the value is changed:

   (config)> show -v

   Result:
   The prompt returns the new value.
5. Enable the LDE configuration to turn on the unique prompt prefix feature:

   lde-config system add --unique-prompt on

6. When the new prompt is enabled, log off and log on, or open a new shell, to use the new prompt.

2.2   CSCF Authentication Tasks

2.2.1   Configure System Authentication

The S-CSCF supports several authentication mechanisms.

The CSCF is configured using the available NBI with CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

2.2.1.1   Configure Trusted Gateway and Trusted AS

2.2.1.1.1   Enable Trusted Gateway

Trusted Gateway authentication is supported by the S-CSCF. At reception of a SIP request (except CANCEL and ACK), the S-CSCF verifies that the IP address from which the SIP message was originated is equal to the configured IP address of trusted gateways. If they match, processing continues without any additional authentication.

To enable this function:

1. Configure the list of trusted SIP gateways in the cscfTrustedGateway.
2. Make sure the cscfOverallAuthenticationPolicyEnabled is set to enabled.

2.2.1.1.2   Enable Trusted AS

Trusted AS authentication is supported by the S-CSCF. At reception of a SIP request from an AS, the S-CSCF verifies that the AS transport address is in the list of trusted ASs (cscfTrustedASEntry). If it is not, the S-CSCF rejects the request with error response 403 (User Agent Not Authorized).

To enable this function:

1. Configure the list of trusted ASs in the cscfTrustedASEntry.

2.2.1.2   Configure NASS Bundled Authentication

NASS Bundled Authentication, see 3GPP TS 24.229, is supported by the S-CSCF. The S-CSCF compares the line identity received in the P-access-network header with the value retrieved from the HSS.

To enable NASS Bundled Authentication:

1. Define at least one access type in the cscfNBAAccessNetworkType.

   For example, the cscfNBAAccessNetworkType = ADSL2

2. Make sure the cscfOverallAuthenticationPolicyEnabled is set to ENABLED.

When the cscfNBAAccessNetworkType contains at least one access type, the function is enabled. When the cscfNBAAccessNetworkType is empty, the function is disabled.

When the function is enabled, the CSCF is able to control that NASS Bundled Authentication is used for all users of the access networks configured in the cscfNBAAccessNetworkType by setting attribute ScscfNbaAuthSchemeUnknownEnabled to false.

Alternatively, if the CSCF allows the HSS to choose between NASS Bundled Authentication or Digest Authentication for those access networks, attribute ScscfNbaAuthSchemeUnknownEnabled is set to true.

2.2.1.3   Configure Digest Authentication

Digest Authentication, see 3GPP TS 24.229, is supported by the S-CSCF. At initial registration, the S-CSCF fetches the Digest Authentication vectors from the HSS and then challenges the user with a 401 (Unauthorized) message. The S-CSCF checks that the result of the challenge is correct.

There is no specific enabling for this function, except making sure the cscfOverallAuthenticationPolicyEnabled is set to enabled.

Digest Authentication is performed by the S-CSCF when IMS AKA, Trusted Gateway authentication, or NASS Bundled Authentication do not apply, and a SIP Authorization header exists in the SIP REGISTER message.

The cscfSipDigestAuthenticationNonceTimeLength can be used to change the validity time of the nonce sent by the S-CSCF to the UE in the 401 (Unauthorized) challenge message.

The cscfSipDigestAuthenticationNonceReusabilityLimit can be used to change the number of times the nonce can be reused.

The cscfAuthenticationPolicyEntry can be used to configure for which subsequent SIP request message authentication is to be performed.

Note:  

Authentication is never performed for SIP messages ACK and CANCEL.

At subsequent SIP request, to perform Digest Authentication, cscfAuthenticationProcedure is to be set to "digest". For Optimized Digest Authentication configuration, see Section 2.2.1.3.3 Configure Optimized Digest Authentication.

The cscfAuthenticationPolicyEntry can be used to configure for which subsequent SIP request message authentication is to be performed.

Note:  

Authentication is never performed for SIP messages ACK and CANCEL.

2.2.1.3.1   Configure Digest Authentication for UEs

Some UEs do not send SIP Authorization header in the first REGISTER message when registering. The S-CSCF performs Digest Authentication by challenging such UEs with a 401 (Unauthorized) message before fetching the Digest Authentication vectors from the HSS.

To enable this function:

1. Set the scscfSipDigestAuthenticationRealm to the same value as in the HSS. For example, "Welcome to the ims.XYZ.net network, insert your username and password.".
2. Make sure the cscfOverallAuthenticationPolicyEnabled is set to enabled.
3. Make sure that Digest Authentication is used for UE access.

Digest Authentication for UEs not sending SIP Authorization header in the first REGISTER cannot be enabled at the same time as GPRS IMS Bundled Authentication (GIBA), for the same access type profile. To enable both functions in the S-CSCF, two different access profiles must be configured, see Section 2.3.1 Configure Access Awareness.

2.2.1.3.2   Configure Blacklist Function

The blacklist function enables blacklisting suspected SIP clients who attempt to pass the Digest Authentication challenge through repeatedly submitting authentication requests with different authentication credentials.

Once a SIP client is blacklisted, all authentication attempts are rejected by the S-CSCF with a 500 (Retry-After) response, for a time period, until the blacklist time period expires.

To enable this function:

1. Set the cscfAuthenticationBlackListEnabled to true.
2. Make sure the cscfOverallAuthenticationPolicyEnabled is set to enabled.
3. Make sure that Digest Authentication is used for UE access.

The cscfBlacklistMaxAuthenticationAttempt can be used to configure the limit of the number of consecutive authentication attempts because of a failed verification of an authentication response, before SIP client is blacklisted by the S-CSCF.

The cscfBlackListTimer can be used to configure the blacklist time period that requests from a blacklisted SIP client is rejected with 500 (Retry-After) response by the S-CSCF.

The cscfBlackListLoggingFrequency can be used to configure the maximum number of blacklist time periods before another log is issued by the S-CSCF.

Note:  

The S-CSCF issues a log in the beginning of the first blacklist time period.

2.2.1.3.3   Configure Optimized Digest Authentication

Optimized Digest is applicable to subsequent SIP requests from Digest authenticated UEs. With Optimized Digest Authentication, the received Via headers are compared to the Via headers stored at initial registration. If comparison is successful, no other checks are performed.

If comparison fails, Digest Authentication is performed.

To enable this function:

1. Set the cscfAuthenticationProcedure attribute to optimized.
2. Make sure the cscfOverallAuthenticationPolicyEnabled is set to enabled.
3. Make sure that Digest Authentication is used for UE access.

2.2.1.4   Configure GPRS IMS Bundled Authentication

GIBA, see 3GPP TS 24.229 and 3GPP TS 33.203, is supported by the S-CSCF. The S-CSCF compares the UE IP address received in the REGISTER message with the value retrieved from the HSS.

To enable GIBA:

1. Set the scscfGibaAuthenticationEnabled to true.
2. Make sure the scscfGibaAuthenticationEnabled is set to enabled.

The cscfAuthenticationPolicyEntry can be used to configure for which subsequent SIP request message authentication is to be performed.

Note:  

Authentication is never performed for SIP messages ACK and CANCEL.

GIBA cannot be enabled at the same time as Digest Authentication for UEs not sending SIP Authorization header in the first REGISTER, for the same access type profile. To enable both features in the S-CSCF, two different access profiles must be used, see Section 2.3.1 Configure Access Awareness.

2.3   CSCF Registration Tasks

2.3.1   Configure Access Awareness

To enable a more flexible configuration, it is possible to allow configuration based on the access type of the user. This makes it possible to configure different authentication and registration policies for users from different access types in the CSCF.

The S-CSCF determines the configuration to apply at reception of an initial register request by extracting the access type from the PANI header.

The access aware configuration affects the configuration of originating S-CSCF, see Section 2.3.1.1 Enable Access Awareness.

The CSCF is configured using the NBI with CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

2.3.1.1   Enable Access Awareness

To enable access awareness:

1. Configure at least one policy group, see Section 2.3.1.1.2 Policies.
2. Configure at least one profile to point to selected policies, see Section 2.3.1.1.3 Profiles.
3. Configure the mapping table to map at least one access type to each profile, see Section 2.3.1.1.4 Mapping Table.

2.3.1.1.1   Access Aware Configuration Example

To configure the access aware:

1. Create two new authentication policy groups, GIBA and Digest. Also create two registration policy groups; the MaxRefresh and the MinRefresh:

   CscfAuthentication=GIBA, CscfAuthenticationGroup=0,
   CscfAuthenticationPolicyEntry: Re-Registration:disabled
   CscfAuthenticationPolicyEntry: INVITE:enabled
   CscfAuthenticationPolicyEntry: NOTIFY:disabled
   CscfAuthenticationPolicyEntry: UPDATE:disabled
   ScscfGibaAuthenticationEnabled: true
   ScscfSipDigestAuthenticationRealm: <empty>
   
   CscfAuthentication=Digest, CscfAuthenticationGroup=0
   CscfAuthenticationPolicyEntry: Re-Registration:disabled
   CscfAuthenticationPolicyEntry: INVITE:enabled
   CscfAuthenticationPolicyEntry: NOTIFY:disabled
   CscfAuthenticationPolicyEntry: UPDATE:disabled
   ScscfGibaAuthenticationEnabled: false

   ScscfSipDigestAuthenticationRealm: set it same as in the HSS.

   CscfRegistration=MaxRefresh, CscfRegistrationGroup=0,
   CscfRegistrationRefreshMin: 60
   CscfRegistrationRefreshMax: 200
   CscfRegistrationRefreshDefault: 100
   CscfRegistration=MinRefresh, CscfRegistrationGroup=0,
   CscfRegistrationRefreshMin: 1
   CscfRegistrationRefreshMax: 60
   CscfRegistrationRefreshDefault: 30

2. Configure profiles and point to the existing policy group. Profiles are GIBAMax and DigestMin.

   CscfProfile=GIBAMax, CscfProfileGroup=0,
   CscfAuthenticationPolicy: GIBA
   CscfRegistrationPolicy: MaxRefresh
   CscfProfile=DigestMin,CscfProfileGroup=0,
   CscfAuthenticationPolicy: Digest
   CscfRegistrationPolicy: MinRefresh

3. Create mapping tables, including the PANI header, and map that to the CscfProfile to use.

   CscfConfigProfileMappingTableEntry: IEEE-802.11-FDD:DigestMin
   CscfConfigProfileMappingTableEntry: 3GPP-UTRAN-FDD:GIBAMax

   A UE that registers with a PANI that contains access-type IEEE-802.11 uses the configuration profile DigestMin and the configuration defined in the Authentication policy group Digest and the Registration policy group MinRefresh. A PANI containing 3GPP-UTRAN-FDD uses the configuration profile GIBAMax. Any other empty, or missing, PANI header uses the configuration from the CscfAuthenticationPolicy=default and CscfRegistrationPolicy=default. The configuration profile is used for all subsequent requests for this particular UE.

2.3.1.1.2   Policies

At initial start, a Registration policy and an Authentication policy are created. These default policy group instances are used if there is no mapping table defined, no profile maps to the received PANI access-type, or no PANI header was present in the request. Attributes that are not access aware can only be modified in the default policies. If so, other policies that have been configured are updated with the new value of those attributes. Attributes that are access aware can have different values in different policies. For more information about which attributes are access aware, see Managed Object Model (MOM).

2.3.1.1.3   Profiles

The profile points to the policies to use. If no policy is specified for a newly created profile, the default Authentication and Registration policies are used.

2.3.1.1.4   Mapping Table

The cscfConfigProfileMappingTableEntry maps one or more PANI access-types to a specific CscfProfile.

2.3.2   Configure IMS Restoration

The Restoration Procedure provides a mechanism to ensure continuous services for users, when the S-CSCF in which they are currently registered is not reachable. The Restoration Procedure is an optional feature which can be enabled by configuration. When enabled, the S-CSCF stores and maintains the restoration information of its users in the HSS. If an S-CSCF is out of service, another S-CSCF does the restoration procedure and provide services to the restored users.

The CSCF is configured using the NBI with CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

2.3.2.1   Enable Restoration Procedure

To enable the Restoration Procedure:

1. Set the scscfRestorationProcedure in the S-CSCF to 1 or 2 as needed. For information on the values of the attribute, see Table 17.
2. If the S-CSCF is planned to disable processing originating non-Register requests, set the scscfRestorationOriginatingNonRegisterAllowed in the S-CSCF to FALSE. For information on the values of the attribute, see Table 17.

2.3.3   Configure Max Number of Contacts

It is possible to configure the limit of number of contacts allowed to be simultaneously registered in the S-CSCF. The behavior when the limit is exceeded can be configured to reject new registrations or to overwrite an existing contact. The feature can be also disabled, meaning that the CSCF is not enforcing any restriction on the number of contacts.

The number of contacts can be restricted based on the combination of an IMS Private Identity (IMPI), Implicit Registration Set (IRS), and the access type. This is configured by the cscfMaxNumberContactsPerUser and cscfMaxContactsBehavior.

A restriction can be also configured for all the contacts within an IRS by using the proprietary AVP Max-No-Of-Contacts sent from the HSS over the Cx interface. The behavior for this restriction is configured by the cscfMaxContactsBehaviorIrs that compares the value of the AVP with the number of contacts registered in the corresponding IRS.

For handling of these attributes by the S-CSCF, see Figure 7.

2.3.4   Configure P-CSCF Restoration Procedure

When the S-CSCF tries to send a terminating request to a P-CSCF and the P-CSCF is blacklisted or responds with a SIP error response code matching an error code in parameter, scscfPcscfRestorationSipErrorCodes, S-CSCF triggers the HSS-based P-CSCF restoration procedure for the terminating user. It forces the affected UE to perform an initial registration and then a working P-CSCF is assigned.

Enabling this feature is beneficial because users registered in a P-CSCF that is not responding properly, can resume the services if a terminating call is received before any invocation of the IMS system.

2.3.4.1   Enable P-CSCF Restoration Procedure

To enable the P-CSCF Restoration Procedure:

1. If it is preferred to trigger P-CSCF Restoration Procedure with SIP error codes, configure the SIP error codes for triggering the P-CSCF restoration in the configuration parameter scscfPcscfRestorationSipErrorCodes.

   Note:  

   Multiple SIP error codes can be defined by configuring multiple scscfPcscfRestorationSipErrorCodes attribute instances.

   
   
2. Enable the P-CSCF Restoration Procedure by setting the configuration parameter scscfPcscfRestorationEnabled to TRUE.

If scscfPcscfRestorationSipErrorCodes is not configured and scscfPcscfRestorationEnabled is enabled, the P-CSCF restoration is triggered only when the P-CSCF is blacklisted for reasons except receiving SIP 503 with or without a Retry-After header.

After enabling, any changes to scscfPcscfRestorationSipErrorCodes will take effect in the next terminating request.

2.3.4.2   P-CSCF Restoration Procedure Configuration Example

This is an example of a possible P-CSCF Restoration Procedure configuration when the P-CSCF Restoration Procedure is to be triggered on multiple SIP error codes, for example 404, 408, 486, 500, 503, and 504. In such cases, multiple instances of scscfPcscfRestorationSipErrorCodes must be configured.

2.3.5   Configure Re-Registration with HSS Bypass

When the re-registration with HSS bypass feature is enabled, I-CSCF routes the request to S-CSCF indicated in the Route header if the HSS inquiry fails because of HSS overloaded, no reply, or the request not sent because of throttling, see Section 2.4.21 Configure Throttling of Diameter Traffic on Cx/Dx Interface. This feature is enabled or disabled by using a parameter cscfReRegWithHssBypass. This parameter must be enabled in both external P-CSCF and I-CSCF if standalone deployment for the feature to work.

The re-registration with Authentication bypass feature allows the S-CSCF to process the re-registration without authentication if the HSS authentication inquiry fails because of HSS overloaded, no reply, or the authentication request not sent because of throttling. This feature is enabled or disabled by using a parameter scscfReRegWithAuthBypass, which is independent of the re-registration With HSS Bypass feature parameter cscfReRegWithHssBypass.

For the CSCF to process the re-registration when HSS inquiry fails because of the reasons listed in this section, the two parameters must be enabled.

2.3.5.1   Enable Re-Registration with HSS Bypass

To enable re-registration with HSS bypass:

1. Set the attribute cscfReRegWithHssBypass to BYPASS_IF_FAILED.

2.3.5.2   Disable Re-Registration with HSS Bypass

To disable re-registration with HSS bypass (default configuration):

1. Set the attribute cscfReRegWithHssBypass to NO_BYPASS.

2.3.5.3   Enable Re-Registration with Authentication Bypass

To enable re-registration with Authentication Bypass:

1. Set the attribute scscfReRegWithAuthBypass to BYPASS_IF_FAILED.

2.3.5.4   Disable Re-Registration with Authentication Bypass

To disable re-registration with Authentication Bypass (default configuration):

1. Set the attribute scscfReRegWithAuthBypass to NO_BYPASS.

2.3.6   Configure Sorting of Registered Public Identities in S-CSCF

The attribute CscfRegistrationGroupClass is used to configure the sorting behavior of the S-CSCF for unbarred public identities (IMPUs) that are listed in the P-Associated-URI (PAU) header that is added to the 2xx response to REGISTER.

The sorting is applied to IMPUs in the Service Profile that belongs to the public identity in the To header at registration.

In the sorting, the first non-barred SIP URI in the Service Profile is added as the first entry in the list of URIs in the PAU header. The first non-barred tel URI in the Service Profile is added as the second entry. Other non-barred public identities in the Service Profile are added to the header in a random way.

The allowed values for CscfRegistrationGroupClass are: 0–2. The default value is 0.

2.3.6.1   Enable IMPU Sorting for Emergency Registration

To sort the emergency registered IMPUs in the Service Profile:

1. Navigate to MOC CscfRegistrationGroupClass.
2. Choose one of the following options:
   • Set scscfPAssociatedUriBehavior to 1 to sort only the emergency registered IMPUs:

     > dn ManagedElement=<node_name>, CscfFunction=1, CSCF-Application=1, CscfRegistrationClass=default, scscfPAssociatedUriBehavior=1

   • Set scscfPAssociatedUriBehavior to 2 to sort the emergency and the normal registered IMPUs:

     > dn ManagedElement=<node_name>, CscfFunction=1, CSCF-Application=1, CscfRegistrationClass=default, scscfPAssociatedUriBehavior=2

2.3.6.2   Enable IMPU Sorting for Normal Registration

To sort the emergency and normal registered IMPUs in the Service Profile:

1. Navigate to MOC CscfRegistrationGroupClass.
2. Set scscfPAssociatedUriBehavior to 2:

   > dn ManagedElement=<node_name>, CscfFunction=1, CSCF-Application=1, CscfRegistrationClass=default, scscfPAssociatedUriBehavior=2

   Result:
   The emergency and normal registered IMPUs in the Service Profile are sorted. The IMPUs that do not belong to the Service Profile are added after those in a random way.

2.3.6.3   Disable IMPU Sorting

To disable the sorting of the IMPUs in the Service Profile:

1. Navigate to MOC CscfRegistrationGroupClass.
2. Set scscfPAssociatedUriBehavior to 0:

   > dn ManagedElement=<node_name>, CscfFunction=1, CSCF-Application=1, CscfRegistrationClass=default, scscfPAssociatedUriBehavior=0

   Result:
   There is no specific sorting for IMPUs within the Service Profile. The default public identity is the first entry of the list in the PAU header followed by all other non-barred public identities in the Implicit Registration Set.

2.4   CSCF SIP Routing and Traffic Tasks

2.4.1   Configure Break-In Control Function

The BCF gives the possibility for users connected to other networks to execute originating IMS services. The BCF supports INVITE messages, and only for registered users.

The BCF is configured using the available NBI with CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

2.4.1.1   Enable BCF

To enable the BCF:

1. Make sure that the attributes described in the following sections are configured:
   • Section 2.1.1.1.1 Configure DNS/ENUM Client
   • Section 2.1.1.2 Configure Diameter Stack
   • Section 2.1.1.3 Configure CSCF Common Attributes

     Note:  

     Only the CscfCXOriginRealm, CscfCXOriginHost, CscfCxDestinationRealm, and CscfCxDestinationHost are configured.

     
     
2. Add the IP address of the BCF to the cscfTrustedGateway attribute in all the S-CSCF nodes.

   Note:  

   The S-CSCF rejects requests from a BCF if the IP address is not in the cscfTrustedGateway list.

   
   
3. Set the cscfAdministrativeState to LOCKED.
4. Set the bcfEnabled to true and configure the bcfDomainNameEntry.
5. Configure at least one bcfNetworkInterfaceEntry.
6. Set the cscfAdministrativeState to UNLOCKED.

When the BCF node is in unlocked mode, it is ready to receive SIP signaling.

2.4.2   Configure Destination Blacklisting

If a destination host for some reason indicates that it is not available to receive traffic, the host can be blacklisted in the CSCF. The destination host is usually the next hop.

The reason can be any of the following:

• A SIP 503 Response with Retry-After header for all SIP Requests (INVITE or Non- INVITE) is received.
• A SIP 503 Response without Retry-After header for all SIP Requests (INVITE or Non- INVITE) is received.
• A transaction time-out for SIP INVITE.
• Fatal transport errors (socket errors or indicated by the Internet Control Message Protocol (ICMP)) for all SIP Requests are received.

There are five configuration parameters for configuring blacklisting thresholds, one for each blacklisting reason, as follows:

• cscfBlacklistingSipTransactionTimeoutThreshold
• cscfBlacklistingSip503WithRetryAfterThreshold
• cscfBlacklistingSip503WithoutRetryAfterThreshold
• cscfBlacklistingTransportErrorThreshold
• icmpIntermittentTolerance

For more information about the configuration parameters, see Section 2.4.2.2 Configure Blacklisting Threshold.

Depending on the reason, an entire host or individual ports (including its transport protocols) is blacklisted when the number of error events exceeds the configured threshold. A destination can be removed from the blacklist when its timer configuration expires, see Section 2.4.2.1 Configure Timer. There is no specific parameter to enable or disable the blacklisting function. But in practice, it is possible to disable the blacklisting function by configuring the thresholds to high values.

Besides the default configuration for destination blacklisting, the CSCF supports configuring destination blacklisting per FQDN. If one or more FQDNs of destinations are defined by attribute cscfDestinationSipAddress, one or more blacklisting configurations per FQDN can exist. The configuration parameters for configuring blacklisting thresholds and timer per FQDN of destination are as follows:

• cscfDestinationSipAddress
• cscfDestinationUnavailabilityTimerDest
• cscfBlacklistingSipTransactionTimeoutThresholdDest
• cscfBlacklistingSip503WithRetryAfterThresholdDest
• cscfBlacklistingSip503WithoutRetryAfterThresholdDest
• cscfBlacklistingTransportErrorThresholdDest

2.4.2.1   Configure Timer

Attribute icmpBarringTime is used to define the time in seconds to regard destinations as unreachable. This configuration is only used for blacklisting a destination because of ICMP.

Both attributes CscfDestinationUnavailabilityTimer and cscfDestinationUnavailabilityTimerDest are used to define the time in seconds for how long the CSCF blacklists an unavailable destination in the network for the following blacklisting reasons:

• SIP 503 without Retry After header
• Transaction Time-out
• Fatal Transport Error

For the blacklist reason 503 with Retry-After header, the timer is taken directly from the value in the header.

If cscfDestinationUnavailabilityTimerDest is set to default, when the Fully Qualified Domain Names (FQDNs) of destinations are set in attribute cscfDestinationSipAddress, CscfDestinationUnavailabilityTimer is used. Otherwise, cscfDestinationUnavailabilityTimerDest is used.

The attributes cscfBlacklistingThresholdInterval and cscfBlacklistingThresholdIntervalDest are used to define the time, in seconds, for the measurement period for all blacklisting reasons, see Section 2.4.2.2 Configure Blacklisting Threshold. If the values of these attributes are set to 0, CscfDestinationUnavailabilityTimer or cscfDestinationUnavailabilityTimerDest is used.

If cscfBlacklistingThresholdIntervalDest is set to default when the FQDNs of destinations are set in attribute cscfDestinationSipAddress, the attribute cscfBlacklistingThresholdInterval is used. Otherwise, cscfBlacklistingThresholdIntervalDest is used.

2.4.2.2   Configure Blacklisting Threshold

Each blacklisting reason has a configurable threshold that must be exceeded before the destination host becomes blacklisted. Each threshold is counted individually per destination host and reason.

The threshold level is measured during a measurement period. The measurement period starts when the first blacklisting event occurs and is prolonged every time the same blacklisting event occurs within its timer configuration (see Section 2.4.2.1 Configure Timer). The measurement period ends if no additional blacklisting event occurs within its timer configuration (see Section 2.4.2.1 Configure Timer), or when the threshold level is exceeded and the destination host becomes blacklisted. The measurement period is restarted after every new blacklisting event occurs. The counting for threshold is reset when the measurement period is ended.

Attribute cscfBlacklistingSipTransactionTimeoutThreshold is used to configure the threshold for blacklisting destinations because of SIP transaction time-out.

Attribute cscfBlacklistingSip503WithRetryAfterThreshold is used to configure the threshold for blacklisting destinations because of 503 Response with Retry-After.

Attribute cscfBlacklistingSip503WithoutRetryAfterThreshold is used to configure the threshold for blacklisting destinations because of 503 Response without Retry-After.

Attribute cscfBlacklistingTransportErrorThreshold is used to configure the threshold for blacklisting destinations because of fatal transport error (socket error).

Attribute icmpIntermittentTolerance is used to configure the threshold for blacklisting destinations because of ICMP.

If the FQDNs of destinations are set in attribute cscfDestinationSipAddress, the following attributes are used to configure the thresholds for blacklisting destinations per FQDN:

• Attribute cscfBlacklistingSipTransactionTimeoutThresholdDest is used to configure the threshold for blacklisting destinations because of SIP transaction time-out. The value range is 0– 2147483647. The default value is default. When default is used, cscfBlacklistingSipTransactionTimeoutThreshold is used.
• Attribute cscfBlacklistingSip503WithRetryAfterThresholdDest is used to configure the threshold for blacklisting destinations because of 503 Response with Retry-After. The value range is 0– 2147483647. The default value is default. When default is used, cscfBlacklistingSip503WithRetryAfterThreshold is used.
• Attribute cscfBlacklistingSip503WithoutRetryAfterThresholdDest is used to configure the threshold for blacklisting destinations because of 503 Response without Retry-After. The value range is 0– 2147483647. The default value is default. When default is used, cscfBlacklistingSip503WithoutRetryAfterThreshold is used.
• Attribute cscfBlacklistingTransportErrorThresholdDest is used to configure the threshold for blacklisting destinations because of Fatal transport error (socket error). The value range is 0– 2147483647. The default value is default. When default is used, cscfBlacklistingTransportErrorThreshold is used.

2.4.2.3   Configure Blacklisting Bypass

It is possible to configure the CSCF to bypass the blacklisting when all alternative transport addresses toward a destination are blacklisted by setting the following parameters in percentage:

• The parameter cscfBlacklistingSip503WithoutRetryAfterBypassThrottle controls the number of initial SIP requests that are sent to destinations that have been blacklisted because of SIP 503 without Retry-After header.
• The parameter cscfBlacklistingBypassThrottle controls the number of initial SIP requests that are sent to destinations that have been blacklisted because of SIP 503 with Retry-After header.
• The parameter cscfBlacklistingSipTransactionTimeoutBypassThrottle controls the number of initial SIP requests that are sent to destinations that have been blacklisted because of SIP Transaction Time-out.
• The parameter cscfBlacklistingTransportErrorBypassThrottle controls the number of initial SIP requests that are sent to destinations that have been blacklisted because of Fatal Transport Error or ICMP Error.
• The parameter cscfBlacklistingInsideDialogRequestBypassThrottle controls the number of inside dialogue SIP requests that are sent to destinations that have been blacklisted for any reason.

Blacklisting bypass is recommended for the following:

• Destinations that are blacklisted because of SIP 503 with or without Retry-After header.

  This is because the destinations are reachable and may accept a SIP request or reject without any significant delay.

• Inside dialog requests.

  For maintaining ongoing sessions.

Blacklisting bypass is not recommended for the following:

• Destinations that are blacklisted because of SIP Transaction Time-out, Fatal Transport Error, or ICMP Error.

  Because the destinations are not reachable and are to be removed from blacklisting when they become reachable. Delaying the session for bypassing the blacklisting is not worthwhile.

2.4.2.4   Example Configuration of Destination Blacklisting

If cscfBlacklistingSipTransactionTimeoutBypassThrottle = 0, cscfBlacklistingTransportErrorBypassThrottle = 0, cscfBlacklistingSip503WithoutRetryAfterBypassThrottle = 100, and cscfBlacklistingBypassThrottle = 100, the CSCF does not ever send an initial SIP request toward a destination that is blacklisted because of SIP Transaction Time-out, Fatal Transport Error, or ICMP Error, but sends all the initial SIP requests toward destinations blacklisted because of SIP 503 without or with Retry-After header.

If cscfBlacklistingSipTransactionTimeoutBypassThrottle = 0, cscfBlacklistingTransportErrorBypassThrottle = 0, cscfBlacklistingSip503WithoutRetryAfterBypassThrottle = 0, cscfBlacklistingBypassThrottle = 0, and cscfBlacklistingInsideDialogRequestBypassThrottle = 100, the CSCF sends all the inside dialogue requests, except any initial SIP request toward destinations that are blacklisted for any reason.

Table 19 shows an example configuration of destination blacklisting.

In the example, the following blacklisting bypass is set:

• The CSCF does not send initial SIP requests toward a destination that is blacklisted because of SIP Transaction Time-out.
• The CSCF sends all the initial SIP requests toward destinations blacklisted because of SIP 503 with Retry-After header.
• The CSCF sends 70% of the initial SIP requests toward destinations blacklisted because of SIP 503 without Retry-After header or because of Fatal Transport Error or ICMP Error.
• All the inside dialogue requests are sent by the CSCF.

2.4.2.5   Example Configuration of Destination Blacklisting per FQDN

Table 20 shows an example of single configuration of destination blacklisting for one FQDN. In this case, one group of attributes with the key as defined by cscfSipConfigDestProfileId are set and one FQDN is set by cscfDestinationSipAddress.

Table 21 shows an example of single configuration of destination blacklisting for multiple FQDNs. In this case, one group of attributes with the key as defined by cscfSipConfigDestProfileId are set and more than one FQDN (two FQDNs for this example) are set by cscfDestinationSipAddress.

Table 22 shows an example of multiple configurations of destination blacklisting for multiple FQDNs. In this case, more than one group of attributes (two groups for this example) with keys as defined by cscfSipConfigDestProfileId and one FQDN is set by cscfDestinationSipAddress per group.

2.4.3   Configure Domain Routing Function

The Domain Routing Function (DRF) provides DNS-like functionality based on a set of static configuration tables local to the CSCF. DRF is available to all CSCF roles (I-/S-/E-), including BGCF and BCF. When started, DRF attempts to map the next hop address of an SIP request in FQDN format to another next hop addresses, which can be in FQDN, IPv4, or IPv6 format. The SIP request is routed to the new next hop addresses in serial mode on successful DRF table lookups.

If DRF is not started, for example, because of the absence of a SIP request next hop address in FQDN format or that a DRF table lookup fails, the SIP request is routed to the original next hop address.

For more information regarding DRF configuration parameters, see Managed Object Model (MOM).

DRF is configured with CscfFunction fragment cscfDomainRoutingApplication through the NBI, see Section 1.3 Configuration Methods.

2.4.3.1   Configure Domain Routing Function Global Attributes

DRF has one instance of configuration with CscfFunction fragment cscfDomainRoutingApplication. The application can support multiple sets of configuration tables. Each set of configuration tables uses one matching table and one result table. On a successful matching table lookup to the FQDN, the matching table entry references a result table entry which specifies the new next hop addresses to route the SIP request.

The DRF global configuration attributes are listed in Table 23.

AttributecscfDomainRoutingEnabled is an operator configurable attribute to enable or disable DRF. When set to false, DRF is disabled. All SIP requests are routed to the original target addresses. When set to true, DRF is enabled and can be started for CSCF outgoing SIP requests.

Attribute cscfDomainRoutingActiveConfig is a read-only attribute that identifies the set of configuration tables corresponding to the existing runtime data for traffic handling. Attribute cscfDomainRoutingSelectedConfig is an attribute that identifies the set of configuration tables to be converted to runtime data for traffic handling, replacing the existing one.

Attribute cscfDomainRoutingActiveMatchingTable is an operator configurable attribute which identifies the matching table within a configuration table set for DRF table lookup.

In the current delivery, DRF supports only one set of configuration tables and one matching table within the configuration set. The value of attribute cscfDomainRoutingSelectedConfig is hard-coded to default, and the value of cscfDomainRoutingActiveConfig equals default only. The value of attribute cscfDomainRoutingActiveMatchingTable is also hard-coded to 0. Modifications are allowed to the configuration table set default and matching table 0 only for runtime data update.

Operators set attribute cscfDomainRoutingSyncConfig to true to initiate the synchronization process for runtime data update based on the configuration table set identified by attribute cscfDomainRoutingSelectedConfig. The attribute value is reset to false automatically when synchronization terminates.

Attribute cscfDomainRoutingSyncState is a read-only attribute showing the result of the synchronization process. It can have one of three values: synchronized, not_synchronized, and synchronization_failed.

On a successful synchronization, the existing runtime data is replaced with the newly generated runtime data for traffic handling. On a synchronization failure, synchronization is ended and traffic handling is resumed with the existing runtime data.

Update to the configuration tables can be made without traffic disturbances. Minor traffic disturbances can be present during synchronization of a configuration table set.

(1)  This attribute is not user configurable.

2.4.3.2   Domain Routing Function Table Configuration Examples

Each set of configuration tables consists of a Domain Routing matching table and a Domain Routing result table.

When configuring DRF tables, the tables must be created last one first to ensure that a table exists before it is referenced. Domain Routing result table cscfDomainRoutingResultTableId must therefore be created first before Domain Routing matching table cscfDomainRoutingMatchingTableId.

DRF is started for Domain Routing matching table lookup to the original address in FQDN format. If a SIP request is not to be routed originally to an address in FQDN format or the table lookup fails, the SIP request is routed to the original address.

When specified as part of a next hop target address, the port and transport protocol information is used to route the request to the address. Otherwise, the default port and transport protocol values are used.

Each next hop target address within a result table entry must be assigned a unique priority value. On a successful FQDN match resulting in multiple next hop target addresses, the SIP request is routed to the addresses in serial mode according to the priority setting. The next hop address with the highest priority value is attempted first and the address with the lowest priority value is attempted last.

Table 24 shows a Domain Routing matching table configuration example and Table 25 shows a Domain Routing result table configuration example.

Match result: match to “one.xyz.net”
Next hop address list: (In Mode-1, the original FQDN is not included.)
abc.xyz.net ; priority = 1
def.xyz.net :5062 ; transport=UDP ; priority = 2

Match result: match to “two.xyz.net”
Next hop address list: (In Mode-2, the original FQDN is included ⇒
with the lowest priority, 0 in this example)
	123.123.123.123 ; transport = TCP ; priority = 1
two.xyz.net ; priority = 0

Match result: Original FQDN does not match any configured domain name ⇒
entries in the matching table. The SIP request is routed to the ⇒
original FQDN, one.xyz.com.
Next hop address list: 
	one.xyz.com

2.4.3.3   Manage Domain Routing Function

To update the DRF:

1. Update the configuration tables with the new changes.
2. Set cscfDomainRoutingSyncConfig to true.
3. Wait until cscfDomainRoutingSyncConfig has been set to False and make sure that cscfDomainRoutingSyncState has taken the value synchronized.

Attribute cscfDomainRoutingSyncState is set to synchronized if the configuration is successfully converted to runtime data. The runtime data is used to handle traffic when the attribute assumes the value synchronized.

If synchronization fails, the value is set to synchronization_failed and an alarm is raised identifying the reason for the failure. After the cause of the failure is corrected, cscfDomainRoutingSyncConfig can be set to True again to synchronize the data.

Users do not set the value of cscfDomainRoutingSyncConfig to false. It is set to false automatically when synchronization is completed.

2.4.4   Configure DSCP in CSCF

The Differentiated Services Code Point (DSCP) provides Quality of Service (QoS) and classifies the network traffic. Therefore, DSCP can be used to prioritize different traffic types in the IP Multimedia Subsystem (IMS) system. The recommended DSCP values per traffic type are listed in Table 26. For more information about DSCP, see RFC 2474.

To set the DSCP configuration permanently, a cluster reboot is needed. When the DSCP settings need to be changed but a reboot is unsuitable then, the DSCP settings can be also set temporarily at first.

To update the DSCP settings:

1. Change one DSCP setting at a time in a Linux® shell for each payload or controller, using this iptables command example:

   iptables control -t mangle -A OUTPUT -p TCP --sport 162 -s 10.50.41.50 -j DSCP --set-dscp-class cs4

   This command adds one DSCP configuration based on the IP address of the interface.

   Result:
   The DSCP settings are now set temporarily and do not require a cluster reboot before taking effect.
2. Open the file /cluster/etc/cluster.conf.
3. Add the suitable iptables commands to the cluster.conf file, using this iptables command example:

   iptables control -t mangle -A OUTPUT -p TCP --sport 162 -s 10.50.41.50 -j DSCP --set-dscp-class cs4

   This command adds one DSCP configuration based on the IP address of the interface.

4. Reload the configuration:

   cluster config -r –a

5. Reboot the cluster:

   cluster reboot -a

   Note:  

   The cluster reboot can be done at any time after configuring the cluster.conf file. The new DSCP configuration settings take effect after the cluster reboot.

   
   
   Result:
   The DSCP settings are now set permanently.

2.4.5   Configure Dynamic User Identity Support

Dynamic User Identity Support (DUIS) is used to support external users who do not have an IMS identity. These external users belong to a partner of the IMS operator. DUIS is enabled using configurations.

The external user identity is converted to an IMS identity when the following conditions are true:

• DUIS is enabled.
• One of the following conditions is true:
  • The terminating request contains a global telephone number.

    For example: tel:+1-555-9175.

  • The external domain of the terminating user of the terminating request matches a domain in the set of preconfigured partner domains.

    For example: alice@partner.com.

To convert an external user identity to an IMS user identity, the Dynamic User Association Router (DUA-R) function of the I-CSCF sends an LDAP SEARCH request to the Dynamic User Association Database (DUA-DB). The DUA-DB returns the specific IMS Public Identity (IMPU) of a Wildcarded Public Identity (wIMPU). The wIMPU is used as the IMS identity of the external user within the IMS network.

2.4.5.1   Prerequisites for DUIS

The following prerequisites are required for DUIS to perform properly:

• The support of wIMPU is required. It is enabled by configuration parameter, scscfwImpuEnabled.
• The support of Enhanced Caller Preferences is required. It is enabled by configuration parameter, scscfEnhancedCallerPreferencesEnabled.
• With DUIS, a given wIMPU can represent many external users that can generate multiple sessions in parallel. To ensure that all requests are processed, it is recommended that the number of sessions allowed per related wIMPU is configured to be unlimited. This is done by setting the value of the MaxNoSimultaneousSessions element in the User-Data AVP of the related wIMPU to the maximum value of xFFFF (decimal 65535). The User-Data AVP is provisioned in the HSS.

2.4.5.2   Configure DUA-DB Server

Before enabling DUIS, at least one DUA-DB server must be configured.

To configure a DUA-DB server:

1. Configure the DUA-DB servers in terms of IPv4 address in parameter ldapServerEntryId, for example, 192.168.28.1:7323. The first DUA-DB server configured in ldapServerEntryId is the primary DUA-DB server and is connected first. Unless it is unavailable, the primary server is always the first one to use when the current server becomes unavailable.
2. Configure the Distinguished username, the administrative password, the Root DN, and the LDAP version of the DUA-DB respectively in parameters ldapServerAdminDn, for example, administratorName=telcooptr,dc=o,dc=com, ldapServerAdminPassword, ldapServerRootDn, for example, dc=o,dc=com, and ldapServerVersion respectively.

   Note:  

   The DN used in the LDAP SEARCH request is the concatenation of dc=duaExtId,ou=identities,o=DuaDb and value of ldapServerRootDn.

   
   
3. Set the time for the DUA-R to consider a DUA-DB server unavailable after the maximum number of retries has failed. Within this time, the DUA-R is not connected to the unavailable DUA-DB server. If the default value of 30 seconds is not suitable, configure the DUA-DB server unavailable time in parameter ldapServerUnavailableTime.
4. Set the maximum time that the DUA-R waits for the response to an LDAP request. When this time expires, the DUA-R resends the request to the DUA-DB server up to the maximum number of retries defined. If the default value of 500 milliseconds is not suitable, configure the maximum response time in parameter ldapServerResponseTime.

   Note:  

   The product of the parameter values in ldapServerEntryId, ldapServerResponseTime, and ldapServerMaxNumberofRetries must not exceed the SIP timers.

   
   
5. Set the maximum number of the resending of an LDAP request until declaring the DUA-DB server unavailable. If the default value of three retries is not suitable, configure the maximum number of retries for LDAP requests using parameter ldapServerMaxNumberofRetries.

2.4.5.3   Enable DUIS

To enable DUIS, after the DUA-DB servers are configured:

1. Define the External Network domains by configuring parameter icscfDynamicUserIdentitySupportDomainEntry, for example, as /partner.com/i,ericsson.com, in the I-CSCF.
2. Enable DUIS by setting configuration parameter icscfDynamicUserIdentitySupportEnabled to TRUE in the I-CSCF.

2.4.5.4   Modify DUA-DB Server Configuration

Modifications to the configuration parameters ldapServerAdminUsername, ldapServerAdminPassword, ldapServerRootDn, and ldapServerVersion are possible and the changes take effect immediately. Changes to these parameters trigger a disconnection (UNBIND) and a reconnection (BIND) to the DUA-DB server.

Modifications to the configuration parameters ldapServerUnavailableTime, ldapServerResponseTime, and ldapServerMaxNumberofRetries are possible and the changes take effect immediately. Disconnection and reconnection to the DUA-DB is not triggered.

Modification to the address of a DUA-DB server listed in parameter ldapServerEntryId is not supported. To modify the address of a DUA-DB, it is required to delete the DUA-DB with the old address (which triggers an UNBIND request to be sent to the old DUA-DB) and create a DUA-DB with the new address (which triggers a BIND request to be sent to the new DUA-DB).

2.4.6   Configure Emergency Call

If the E-CSCF is used to provide the emergency function, it allows a user to perform emergency calls, which are prioritized and routed to the correct emergency center, that is, Public Safety Answering Point (PSAP). The emergency center is selected depending on the dialed emergency number, for example, 112, and the location or the IP address of the user (dependent on configuration).

There are two options if the E-CSCF is not deployed in the network, as follows:

• The IMS network handles emergency calls. This means that the emergency call is handled as an ordinary call, except that the emergency call is prioritized in the network, using the normal call path for a call (external P-CSCF, S-CSCF, terminating network) and thus the external P-CSCF only allows emergency calls for registered users.
• The IMS network does not handle emergency calls. This means that emergency calls are rejected with a redirect message by the external P-CSCF.

There are two options if the E-CSCF is deployed in the network, as follows:

• The emergency call is routed directly from the external P-CSCF to E-CSCF. If so, the external P-CSCF allows emergency calls from both unregistered and registered users.
• The emergency call is routed through the S-CSCF to E-CSCF. If so, the external P-CSCF only allows emergency calls from registered users.

Callbacks from an emergency center to the user that performed the emergency call are handled as a normal call, apart from priority handling if the priority indication is set to emergency.

The E-CSCF is not aware of registration or barring state, and does not trigger any services for the user. Furthermore, no authentication of the user is performed. If authentication is required, the emergency call must be routed through the S-CSCF where the authentication is performed.

For Voice over LTE (VoLTE) emergency call, emergency registration is required. EATF can optionally be enabled to anchor the VoLTE emergency call and perform access transfer, if necessary. When EATF is enabled, optional redundant EATFs support can be enabled through configuration.

The E-CSCF is configured using the available NBI with CscfFunction fragment CSCF-Application, see Section 1.3 Configuration Methods.

2.4.6.1   Emergency Attributes

The settings for the emergency attributes within the E-CSCF are described in Table 27.

The settings for the emergency attributes within the EATF are described in Table 28.

The settings for the emergency attributes within the S-CSCF are described in Table 29.

2.4.6.2   Enable Emergency Call with E-CSCF

To enable the emergency call with the E-CSCF:

1. Ensure that the attributes described in the following sections are configured:
   • Section 2.1.1.1.1 Configure DNS/ENUM Client
   • Section 2.1.1.1.2 Configure Number Normalization
   • Section 2.1.1.2 Configure Diameter Stack
   • Section 2.1.1.3 Configure CSCF Common Attributes

     Note:  

     Only attributes cscfCXOriginRealm, cscfCXOriginHost, cscfCxDestinationRealm, cscfCxDestinationHost, cscfDomainAlias, and cscfChargingInterOpId are configured.

     
     
   • Section 2.1.1.4 Configure CSCF Charging Attributes
   • Section 2.4.9 Configure External Network Selection

   The Number Normalization configuration attributes (for the emergency phone context), the Diameter, the Cx, the External Network Selection (ENS), and the charging configuration attributes are only set if applicable.

   The ENS tables can be configured to route the emergency call to a PSAP, based on the received telephone number from LRF, or a default PSAP in various error situations. For example, when no PSAP number has been received from the LRF. If ecscfDefaultPsapBehavior is configured to USE_DEFAULT_CONFIG, the ENS tables route the emergency call to the default PSAP, based on the telephone number configured in ecscfDefaultPSAPNumber. If ecscfDefaultPsapBehavior is configured to INVOKE_BGCF_FOR_TEL_NUMBER, the ENS tables route the emergency call to the default PSAP, based on the telephone number found in the original Request URI. See the example in Section 2.4.9.2 External Network Selection Table Configuration Examples.

2. If applicable, set the configuration attributes in Table 27.
3. Set the cscfAdministrativeState to LOCKED.
4. Set the ecscfEnabled to TRUE and configure the ecscfDomainNameEntry.
5. Configure at least one ecscfNetworkInterfaceEntry.
6. Set the cscfAdministrativeState to UNLOCKED.

   When the E-CSCF node is in unlocked mode, it is ready to receive SIP signaling.

7. If the emergency call is to be routed through the S-CSCF to E-CSCF, the S-CSCF sees E-CSCF as an AS, Trigger data is to be provisioned in the HSS to accomplish the triggering of E-CSCF from S-CSCF. The trigger data can, for example, be set up to trigger on the priority header emergency, or on the dialed number.

2.4.6.3   Enable Emergency Call without E-CSCF

Routing emergency calls through the S-CSCF instead of the E-CSCF is determined by the external P-CSCF.

To enable multiple destinations in priority order from the ENS analysis, see Table 52. In this case, S-CSCF sends the requests one by one so that if the current request returns any negative response code or time-out, S-CSCF sends the request to the next extNetSelPoolURI found in the extNetSelPoolTableEntry.

It is possible to configure a common destination to be used when none of the configured gateways in the ENS analysis is reachable.

To enable emergency call without E-CSCF:

1. Configure the attributes in Table 29 to the following values:
   • cscfEmergencyCallFailureRoute = SIP URI to be put into the Route header (this scenario always uses loose routing, so if no "lr" attribute provided, the CSCF automatically adds it)
   • cscfEmergencyCallFailureDestination = Optionally set to a SIP or tel URI to be used as Request-URI in the INVITE to the destination.

2.4.6.4   Enable Emergency Access Transfer Function

For VoLTE emergency Single Radio Voice Call Continuity (SRVCC), it is necessary to enable the invocation of EATF from the E-CSCF.

To enable the invocation of EATF:

1. Enable EATF by setting eatfEnabled to true and configure the eatfDomainNameEntry.
2. Define the SIP interface for EATF by configuration parameter eatfNetworkInterfaceEntryId.
3. Verify that EATF is operational by ensuring that the value of eatfOperationalState is 1. If it is not 1, ensure that eatfNetworkInterfaceEntryId is configured properly.
4. Define the EATF address in E-CSCF by configuration parameter ecscfEatfAddress.
5. Enable EATF in E-CSCF by configuration parameter ecscfEatfEnabled.
6. Verify the administrative state of the EATF, if it is locked (CscfAdministrativeState=0) unlock it by setting CscfAdministrativeState to 1.

Optionally, redirection to redundant EATFs during access transfer request handling can be configured. When an EATF cannot handle the access transfer request, because the related session is not anchored there, EATF responds with a 305 Use Proxy response including the redundant EATF addresses. The I-CSCF redirects the access transfer request to an address with the highest q-value found in the 305 Use Proxy response.

To enable redundant EATF:

1. Configure eatfRedundantEatfEntry with redundant EATF addresses and priorities.

2.4.7   Configure End-Of-Selection Analysis

To configure End-Of-Selection (EOS) Analysis to allow for one potential rerouting request:

1. Configure the maximum number of times EOS Analysis is allowed to be started per call or session, see Section 2.4.7.2 Maximum EOS Attempts.
2. Configure at least one Match Profile Table, see Section 2.4.7.3 Match Profiles.
3. Configure at least one Routing Alternative, see Section 2.4.7.4 Routing Alternatives.
4. Configure the EOS Case, see Section 2.4.7.5 EOS Cases.

For more information about the EOS parameters and attributes, see Managed Object Model (MOM).

2.4.7.1   EOS Overview

A basic overview of the EOS functionality when started from a CSCF Application, is shown in Figure 8.

2.4.7.2   Maximum EOS Attempts

Configure the maximum number of times EOS Analysis is allowed to be started per call or session as shown in Table 30.

2.4.7.3   Match Profiles

Configure few Match Profiles, as shown in Table 31, Table 32, and Table 33, to determine which SIP error codes and which SIP Reason Headers must be received to allow EOS Analysis to continue.

The Match Profile is referenced from one or more EOS Case Table entries.

There are no preconditions to defining Match Profiles.

If a started EOS Case references Match Profile noSipPath, the received SIP error response must contain a Status-Line with 500 or 503 and a Reason Header containing protocol=SIP, cause=500 or protocol=SIP, cause=503. If no Reason Header is received in the response, the comparison with the profile results in a non-match.

If a started EOS Case references Match Profile noIsupPath, the received SIP error response (including any internally generated error response) must contain a Status-Line between 300 and 699 and a Reason Header containing protocol=Q.850, cause=31. If no Reason Header is received in the response, the comparison with the profile results in a match.

If a started EOS Case references Match Profile anyErrorResponse, the received SIP error response (including any internally generated error response) can contain any Status-Line and any protocol, and cause, combination in the Reason Header. If no Reason Header is received in the response, the comparison with the profile results in a match.

2.4.7.4   Routing Alternatives

Configure few Routing Alternatives as shown in Table 34, Table 35, Table 36, and Table 37 specifying which SIP Route to use if the Matching of the SIP error codes and SIP Reason Headers has been successful.

The Route Table is referenced from one or more EOS Case Table entries.

There are no preconditions to defining Routing Alternatives.

If an EOS Case references Routing Alternative node2node3mgcA, the SIP request to be rerouted is amended to include the following Route Headers:

• Route: sip:node2.net:5060;lr
• Route: sip:10.50.10.3;lr
• Route: sip:mgcA.net:5060;lr

Assuming the target (cscfEosRouteUri) can be resolved by DNS, the SIP request is routed onwards and supervised using the specified cscfEosRouteFailoverTimer.

If an EOS Case references Routing Alternative "node1mgcB", the SIP request to be rerouted is amended to include the following Route Headers:

• Route: sip:node1.net;lr
• Route: sip:10.50.10.5;lr

Assuming the target (cscfEosRouteUri) can be resolved by DNS, the SIP request is routed onwards and supervised using the specified cscfEosRouteFailoverTimer.

If an EOS Case references Routing Alternative node2node3mgcB, the SIP request to be rerouted is amended to include the following Route Headers:

• Route: sip:node2.net:5060;lr
• Route: sip:node3.net;lr
• Route: sip:mgcB.net:5060;lr

Assuming the target (cscfEosRouteUri) can be resolved by DNS, the SIP request is routed onwards. The SIP request is supervised by cscfSipDefaultFailoverTimer as cscfEosRouteFailoverTimer is set to 0.

If an EOS Case references Routing Alternative node1mgcA, the SIP request to be rerouted is amended to include the following Route Header:

• Route: sip:mgcA.net;lr

The Route-URI specified in cscfEosRouteUri is not included as a Route Header as "lr" is not specified.

Assuming the target (cscfEosRouteUri) can be resolved by DNS, the SIP request is routed onwards and supervised using the specified cscfEosRouteFailoverTimer.

The use of different Routing Alternatives, including configured Route-URIs and additional Route-URIs influence the routing of SIP requests, as shown in Figure 11.

2.4.7.5   EOS Cases

The EOS Case is the first point of entry to EOS Analysis. The EOS Case consists of entries for the Match Profile to be used to compare against the received SIP error response, the routing alternative to use (if not exit) if the profile matching is successful and the next EOS Case to use (if not exit) if the profile matching fails or the specified routing alternative fails.

Configure the EOS Cases as shown in Table 38, Table 39, Table 40, Table 41, and Table 42, specifying the EOS Case Names, of which one or more corresponds to the one configured in the application that is starting EOS Analysis.

In this case, EOS Cases node1mgcAFail and node2node3mgcBFail have been configured in ENS. EOS Cases node2node3mgcAFail, node1mgcBFail, and defaultFail are started from within EOS.

The preconditions to defining an EOS Case are as follows:

• The required Match Profile must exist in the Match Profile Table.
• The required Routing Alternative must exist in the Routing Alternative Table if the keyword exit is not used.

2.4.7.6   Call Flow Example

The following subsections show examples of the use of EOS Analysis. As described in the examples, configuration can affect rerouting.

2.4.7.6.1   Successful Rerouting of SIP Request Example

An EOS analysis resulting in successful rerouting of a SIP request, is shown in Figure 9.

The following happens in this EOS analysis that successfully reroutes a SIP Request:

• At invocation of ENS (A), pool node2node3mgcB is used to route the request. EOS Case node2node3mgcBFail is started if a SIP failure response is received.
• At reception of SIP:500, EOS Analysis (B) is started.
• As cscfEosMaxEosAttempts (see Table 32) is not zero, EOS Analysis continues.
• EOS Case node2node3mgcB is found (see Table 39).
• The Match Profile noSipPath (see Table 31) is used to compare against the received SIP error response.
• A match is found so Routing Alternative node1mgcB is started.
• Routing Alternative node1mgcB is found (see Table 35).
• The failed SIP request is rerouted based on the data in Table 35 following the path CSCF – node1 – mgcB.
• The SIP request is successful and EOS Analysis is not started again for this session.

2.4.7.6.2   Rerouting Not Possible – Example

An EOS analysis where rerouting is not possible is shown in Figure 10.

The following happens in this EOS analysis that results in that it is not possible to reroute the SIP request:

• At invocation of ENS (A), pool node1mgcA is used to route the request. EOS Case node1mgcAFail is started if a SIP failure response is received.
• At reception of SIP:408, EOS Analysis (B) is started.
• As cscfEosMaxEosAttempts (see Table 32) is not zero, EOS Analysis continues.
• The EOS Case node1mgcAFail is found (see Table 38).
• The Match Profile noSipPath (see Table 31) is used to compare against the received SIP error response.
• No match is found so Next EOS Case node2node3mgcAFail is started.
• EOS Case node2node3mgcAFail is found (see Table 40).
• The Match Profile noIsupPath (see Table 32) is used to compare against the received SIP error response.
• No match is found so Next EOS Case defaultFail is started.
• EOS Case defaultFail is found (see Table 42).
• A match is found so Routing Option exit is started.
• EOS Analysis is exited and SIP:408 is proxied backwards.

2.4.8   Configure eVIP FE-HA

The Evolved Virtual Internet Protocol (eVIP) Front-End High Availability (FE-HA) enables the operator to use a network configuration that does not use Bidirectional Forwarding Detection (BFD) or Open Shortest Path First (OSPF) from the Cloud Edge switch toward the Virtual Network Function (VNF). This limits the requirements that the VNF has on the infrastructure and makes it possible to deploy the VNF when BFD is not supported.

When using eVIP FE-HA, the eVIP Front-End Elements (FEEs) are always available. If one Virtual Machine (VM) that hosts an FEE fails, this Front-End Element is relocated automatically to another VM without an FEE. If no VM without an FEE exists, the Front-End Element is moved to a VM that already hosts an FEE. When the move is complete, it is announced through graceful Address Resolution Protocol (ARP).

The eVIP FE-HA can only be used for configurations with static routing without BFD. Therefore, the Front-End Elements included in an Abstract Load Balancer (ALB) must be reconfigured to use static routing. Also, a first hop redundancy protocol, such as Virtual Router Redundancy Protocol (VRRP), is required in the Cloud Edge switch for redundancy.

2.4.8.1   Modify eVIP Configuration for eVIP FE-HA

The default eVIP is configured during the CSCF installation. Modify the configuration using ECLI or NETCONF.

Note:  

In the following procedure, the eVIP configuration is modified through ECLI as an example.

If the CSCF is upgraded from versions older than CSCF 1.11.0, the ALBs are named as ln_sig_sc (Signaling network), ln_cha_sc (Charging network), and ln_li_sc (Confidential network). In CSCF 1.11.0 and later, the ALBs are named as cscf_sig_sp1 (Signaling network), cscf_chr_sp1 (Charging network), cscf_conf_sp1 (Confidential network).

To modify the eVIP configuration for eVIP FE-HA:

1. Create a backup, see Create Backup.
2. Update the default eVIP configuration for eVIP FE-HA through ECLI:
   1. Log on to the ECLI:

      # ssh <oam-user>@<OAM-MIP> -p 2022

   2. Copy the following command lines to the console for deleting current eVIP FEEs:

      configure
      ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=cscf_sig_sp1,EvipFees=1
      no EvipFee=fee_sig_3
      no EvipFee=fee_sig_4
      no EvipFee=fee_sig_5
      no EvipFee=fee_sig_6
      ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=cscf_chr_sp1,EvipFees=1
      no EvipFee=fee_cha_3
      no EvipFee=fee_cha_4
      no EvipFee=fee_cha_5
      no EvipFee=fee_cha_6
      ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=cscf_conf_sp1,EvipFees=1
      no EvipFee=fee_conf_3
      no EvipFee=fee_conf_4
      no EvipFee=fee_conf_5
      no EvipFee=fee_conf_6
      commit

   3. Copy the following command lines to the console for adding and configuring new HA Signaling FEEs:

      Note:  

      EvipParam=gateway, value=192.168.216.252 is the Virtual Router Redundancy Protocol (VRRP) for signaling in the Cloud Edge switches to provide redundancy.

      
      

      configure
      ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=cscf_sig_sp1
      EvipFees=1
      EvipFee=fee_sig_3
      externalInterface=eth1
      extIfBridging="0"
      node=3
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.216.252
      up
      EvipParam=local_address
      value=192.168.216.3/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d225::252
      up
      EvipParam=local_address
      value=fd44:e781:d225::3/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_sig_4
      externalInterface=eth1
      extIfBridging="0"
      node=4
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.216.252
      up
      EvipParam=local_address
      value=192.168.216.4/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d225::252
      up
      EvipParam=local_address
      value=fd44:e781:d225::4/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_sig_5
      externalInterface=eth1
      extIfBridging="0"
      node=5
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.216.252
      up
      EvipParam=local_address
      value=192.168.216.5/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d225::252
      up
      EvipParam=local_address
      value=fd44:e781:d225::5/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_sig_6
      externalInterface=eth1
      extIfBridging="0"
      node=6
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.216.252
      up
      EvipParam=local_address
      value=192.168.216.6/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d225::252
      up
      EvipParam=local_address
      value=fd44:e781:d225::6/64
      commit

   4. Copy the following command lines to the console for adding and configuring new HA Charging Fees:

      Note:  

      EvipParam=gateway, value=192.168.217.252 is the VRRP for charging in the Cloud Edge switches to provide redundancy.

      
      

      configure
      ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=cscf_chr_sp1
      EvipFees=1
      EvipFee=fee_cha_3
      externalInterface=eth2
      extIfBridging="0"
      node=3
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.217.252
      up
      EvipParam=local_address
      value=192.168.217.3/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d226::252
      up
      EvipParam=local_address
      value=fd44:e781:d226::3/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_cha_4
      externalInterface=eth2
      extIfBridging="0"
      node=4
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.217.252
      up
      EvipParam=local_address
      value=192.168.217.4/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d226::252
      up
      EvipParam=local_address
      value=fd44:e781:d226::4/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_cha_5
      externalInterface=eth2
      extIfBridging="0"
      node=5
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.217.252
      up
      EvipParam=local_address
      value=192.168.217.5/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d226::252
      up
      EvipParam=local_address
      value=fd44:e781:d226::5/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_cha_6
      externalInterface=eth2
      extIfBridging="0"
      node=6
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.217.252
      up
      EvipParam=local_address
      value=192.168.217.6/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d226::252
      up
      EvipParam=local_address
      value=fd44:e781:d226::6/64
      commit

   5. Copy the following command lines to the console for adding and configuring new HA Confidental Fees

      Note:  

      EvipParam=gateway, value=192.168.219.252 is the VRRP for charging in the Cloud Edge switches to provide redundancy.

      
      

      configure
      ManagedElement=1,Transport=1,Evip=1,EvipAlbs=1,EvipAlb=cscf_conf_sp1
      EvipFees=1
      EvipFee=fee_conf_3
      externalInterface=eth3
      extIfBridging="0"
      node=3
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.219.252
      up
      EvipParam=local_address
      value=192.168.219.3/24
      up
      
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d228::252
      up
      EvipParam=local_address
      value=fd44:e781:d228::3/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_conf_4
      externalInterface=eth3
      extIfBridging="0"
      node=4
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.219.252
      up
      EvipParam=local_address
      value=192.168.219.4/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d228::252
      up
      EvipParam=local_address
      value=fd44:e781:d228::4/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_conf_5
      externalInterface=eth3
      extIfBridging="0"
      node=5
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.219.252
      up
      EvipParam=local_address
      value=192.168.219.5/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d228::252
      up
      
      EvipParam=local_address
      value=fd44:e781:d228::5/64
      commit
      up
      up
      up
      configure
      EvipFee=fee_conf_6
      externalInterface=eth3
      extIfBridging="0"
      node=6
      EvipRoutingSetup=static
      EvipParam=gateway
      value=192.168.219.252
      up
      EvipParam=local_address
      value=192.168.219.6/24
      up
      up
      EvipRoutingSetup=static6
      EvipParam=gateway
      value=fd44:e781:d228::252
      up
      EvipParam=local_address
      value=fd44:e781:d228::6/64
      commit

3. Create a backup, see Create Backup.
4. Log off from the ECLI:

   > exit

2.4.9   Configure External Network Selection

The CSCF starts the ENS analysis in the Breakout Gateway Control Function (BGCF) when the Request-URI contains a telephone number. The telephone number is either included in a tel URI or a SIP URI with a known domain (known domains are configured in the cscfDomainAlias). Selection of a routing destination can be based on few selection criteria, for example, Calling Party Domain, Calling Party Number, CIC, RN, Called Party Number, request Media Type, SIP Method, Request-URI, SIP headers, UTC time and date information, and weight-based selection. It is possible to modify the Request-URI by defining optional trunk-context and trunk group fields in the selected pool, or by regular expressions. It is also possible per pool, to specify up to four Route-URIs to be included in the outgoing request as additional Route headers. The modified Request-URI is used in further ENS analysis and sent out to the external gateway.

For more information regarding the configuration, see Managed Object Model (MOM).

The ENS is configured using the available NBI with CscfFunction fragment extNetSel-Application , see Section 1.3 Configuration Methods.

2.4.9.1   Configure Global External Network Selection

It is possible to use either one or two instances of the ENS configuration, with CscfFunction fragment extNetSel-Application. Both instances have the same set of classes and attributes. ENS runs in the single configuration mode if attribute extNetSelectionInitialTableName is set to not_configured in either of the applications. Setting extNetSelectionInitialTableName to not_configured in both applications is not allowed. An example of how to configure the global ENS configuration to enable single configuration mode is shown in Table 43.

ENS runs in the dual configuration mode if both applications have extNetSelectionInitialTableName set to a valid table instance. For an example of how to configure the global ENS configuration to enable dual configuration mode, see Table 44.

Attribute extNetSelectionMaxTables specifies the maximum number of navigation and matching tables allowed to be started for routing analyses. This attribute is used for ENS loop detection to avoid infinite table looping. When the number of navigation and matching tables started in an ENS session exceeds this limit, an alarm is raised and the SIP request is routed to the default network pool table entry. If the default network pool table entry is not defined, the SIP request is rejected with a SIP 500 (PSTN Gateway Unreachable) response. This attribute is included in both ENS applications. A change of the value in one application is mirrored in the attribute in the other application.

Attribute extNetSelectionActiveConfiguration specifies the active application (ExtNetSelection or ExtNetSelection2) when running in dual configuration mode and the other application is implicitly passive. Configuration updates are only allowed in the passive application and traffic always uses the active application. In the example shown in Table 44, all configuration updates are made in application extNetSelection2 and traffic uses application ExtNetSelection. It is run in dual configuration mode so that updates to the configuration can be made without traffic disturbances.

Single configuration mode implies that the configuration instance with extNetSelectionInitialTableName set to not_configured is not to be used. Configuration changes can thus only be made on the active configuration, which is also used for traffic handling. In the example shown in Table 43, all configuration changes are made in application ExtNetSelection. Single configuration mode must be avoided when having many tables configured. Configuration changes in single configuration mode must be avoided in peak traffic hours. Configuration changes made during peak traffic hours while having large number of tables defined can result in delayed or, in worst case, failed breakout sessions.

Attribute extNetSelectionDefaultPoolName identifies the default network pool table entry to use when the selection algorithm does not end up in a specific entry in the network pool table. It is also used if a configuration fault has been detected in single configuration mode. For example, a configuration fault can be having an initial table without any table entries.

Attribute extNetSelectionTablesSynchronization is used to signal that the modifications to the ENS configuration have been completed and that it is prepared to be put in service.

Read-only attribute extNetSelectionSynchronizationState contains one of the values synchronized, not_synchronized, and synchronization_failed. The value synchronized indicates that the ENS configuration data has been successfully read and that it is prepared for traffic handling. Value not_synchronized indicates that the ENS configuration data has been updated without a consecutive synchronization. Value synchronization_failed indicates that a synchronization attempt of the ENS configuration data has failed.

2.4.9.2   External Network Selection Table Configuration Examples

The following sections provide examples of how the configuration tables can be populated.

Note:  

When the + sign is used, it must be escaped with a "\" and "+" is replaced with "2B" or "2b". For example, default:+021 is configured as default:\2B021 or default:\2b021.

2.4.9.2.1   Configuration Example 1

This section provides an example of how the configuration tables can be populated, as shown in Table 45 through Table 58. CIC and RN tables are omitted from the example for simplicity.

Configuration tables in this example are either placed in the active configuration instance if single configuration is used, or in the passive configuration instance if dual configuration is used, see Section 2.4.9.1 Configure Global External Network Selection. The global configuration is shown in Table 43 for single configuration and in Table 44 for dual configuration. The configuration changes are in this example made to ExtNetSelection if single configuration and to ExtNetSelection2 if dual configuration. The configuration is made active by following the procedure described in Section 2.4.9.4 Manage External Network Selection in Single Configuration Mode (single configuration) or Section 2.4.9.5 Manage External Network Selection in Dual Configuration Mode (dual configuration).

When configuring the ENS, the tables must be created last one first to ensure that a table exists before it is referenced. For example; to create table sdp-media:multimedia, the following tables must be created first; pool:mgcD and P-Asserted-Identity:sweden.

In this configuration example, the selection process starts with the sdp-media:multimedia table ( Table 45). To create this table, pool mgcD ( Table 52) and the P-Asserted-Identity:sweden table ( Table 46) must be created first.

In this configuration example, the selection process starts with the sdp-media:multimedia table as defined by attribute ExtNetSelectionInitialTableName ( Table 43 or Table 44).

The 500PstnGatewayUnreachable entry is defined as the default network pool to use if there is a configuration error. This refers to an unallocated number pool. If selected, this leads to a SIP 500 PSTN Gateway Unreachable response.

All sessions requiring video or audio media use mgcD. For calls requiring other media types, the selection continues using the P-Asserted-Identity:sweden table. All calls initiated by users from the telia.com domain are sent to the mgcD pool. For calls from other users, the selection continues using the default Calling Party Number table ( Table 47). The RN and CIC table names are not specified in this example. This means that a potential CIC or RN input parameter is not used in this table.

For calling users from the +468719 area, the selection continues using the Ericsson Called Party Number table ( Table 49). The Ericsson Called Party Number table leads to mgcC if the user dialed a number starting with 852, otherwise it uses the ericsson:default entry, which leads to node2node3mgcB.

For all other callers, the default Called Party Number table ( Table 48) is used, which leads to mgcCDE if the dialed number starts with +10065 and to a SIP-method table ( Table 53) for all other numbers (except 112).

If the called number is 112, a Routing Number is to be added to route the call to a PSAP. This is achieved by letting 112 lead to Request-URI:addRnPsap:default ( Table 50), which refers to regexAddRnPsap ( Table 51) that modifies the Request-URI by adding an RN before leading to mgcCDE. The mgcCDE entry contains a prioritized list of ExtNetSelPoolURIs. The alternative Pool URIs are used by the S-CSCF when doing emergency call routing.

The SIP-Method:sweden table ( Table 53) is started for calling users not from the +468719 area and the dialed number not starting with +10065 or not being 112. In this case table navigation goes through the SIP-Method:sweden table ( Table 53), the Event:sweden table ( Table 54), the P-Access-Network-Info:sweden table ( Table 55), the Request-URI-Match:pub table ( Table 56) and the Request-URI-Match:non-pub table ( Table 57) using the ExtNetSelRegexMTbl supporting table ( Table 58). Table navigation leads to mgcC if the SIP request is a SUBSCRIBE from an xDSL caller to a dialog event, and the Request-URI contains domain string one.net (except pub.one.net). Otherwise, the navigation result in node1mgcA.

Note:  

Each Request-URI-Match table can be configured with at most one explicit match entry only to enforce ordered domain string matches such as in this example.

(1)  The + sign is escaped as \2B.

(1)  The + sign is escaped as \2B.