Contents
1 Introduction
This document describes how to configure the Short Number Dialing (SND) service in the MTAS.
1.1 Prerequisites
It is assumed that the user of this document is familiar with the O&M area, in general.
1.1.1 Licenses
To enable the SND service, the SND license must be installed.
For more information about the SND license, refer to MTAS Licenses.
1.1.2 Documents
Before starting any procedure in this document, ensure that the following documents are available:
1.1.3 Conditions
The following condition must apply:
An Ericsson Command-Line Interface (ECLI) session in Exec mode is in progress.
2 Overview
The SND service provides the members in a group the possibility to call each other through short numbers common to all members of the group. Other services, such as CDIV and Conference, can be used together with this service.
The SND service affects presentation, charging, and routing, for example, to route a call from the caller to the receiver of the call based on the SND identity in the Request-URI, see Figure 1.
2.1 SND Domain and SND Number
An SND call is based on two concepts, SND domain and SND number. To recognize an SND domain, a list of possible SND domains must be configured in the MTAS. All the configured domains and their subdomains are considered as the SND domains.
To recognize an SND number, the Number Normalization (NN) service must be configured for the purpose. NN adds prefix "EF" to the destination number to indicate that the number is an SND number.
For more information about the NN service, refer to MTAS Number Normalization Management Guide.
2.2 Originating MTAS
The main task for the SND service in the originating MTAS is to recognize an SND call by checking the Req URI and the caller’s SND identity. A valid SND call is then tagged by adding the P-Private-Network-Indication (P-P-N-I) header in the outgoing INVITE. If the check fails, the request continues with the normal MTAS originating procedure. The SND service in the originating MTAS never rejects a call.
2.3 Terminating MTAS
The main task for the SND service in the terminating MTAS is to recognize an SND call by checking the Req URI and the P-P-N-I header. If the call is a valid SND call, the SND service removes the P-P-N-I header and passes the request forward. Otherwise, the call is rejected by 403 forbidden. Before rejecting the call, the SND service can also play announcement in the backward direction to the caller according to the configuration.
2.4 Convert SND Number to SND Identity
An SND call is routed in the network by its SND identity, but not the SND number. Therefore, the SND service in the originating MTAS must convert an SND number in the incoming INVITE to the corresponding SND identity in the outgoing INVITE. The conversion is triggered by NN, which tags an SND number with an "EF" prefix. The SND then converts the SND number in as follows, depending on if the number is carried by a tel URI or a SIP URI:
- Convert tel URI
Incoming: tel: 5687
Outgoing: sip:5687@village.snd.domain.com
All other parameters in the tel URI are copied. - Convert embedded tel
Incoming: tel: 5687@xxx; user=phone
Outgoing: sip:5687@village.snd.domain.com
Parameter user=phone is removed, and all other parameters in the embedded tel are copied.
2.5 Charging
The originating MTAS adds two Attribute-Value Pairs (AVPs) for indicating SND call in charging, as follows:
- The Supplementary-Service-Identity is added with the value "Short Number Dialing"
- The Supplementary-Service-Action is added with the value "Use of Service"
For more information about the charging protocols, refer to the following documents:
2.6 Subfunctions
The subfunctions included in the SND service are described in this section.
2.6.1 SND Call
This subfunction provides the basic call establishment between two SND users inside the same SND domain.
2.6.2 Announcements
This subfunction plays audio, video, or audio-video announcement when the SND service is active.
For more information about announcement handling and attributes for the SND service, refer to MTAS Announcement Management Guide.
2.7 Interaction with Other Services
This section describes the SND interaction with other services.
2.7.1 Communication Diversion
The SND service is started after the CDIV, and it adds the P-P-N-I header to the outgoing INVITE if it is an SND case. In other cases, the P-P-N-I header is not added.
For more information about the Communication Diversion (CDIV) service, refer to MTAS Communication Diversion Management Guide.
2.7.2 Conference
The SND service is only triggered when an SND user invites another SND user to the conference by REFER. The P-P-N-I header is added to indicate the SND call. The conference server (focus) is required to copy the P-P-N-I header from the Refer-To header in the incoming REFER to the INVITE sent to the conference participant.
For more information about the conference services, refer to the following documents:
2.7.3 Call Admission Control
The Call Admission Control (CAC) service consists of User CAC (UCAC) and Group CAC (GCAC). UCAC has no interaction with the SND service since it does not need the remote identity in a call for its function. The GCAC can use either XML specified limits, or Profile specified limits. For the XML specified limits, there is not any interaction with the SND service owing to the same reason as for the UCAC. For the Profile specified limits, there can be interaction with SND service as the remote identity is needed. For the originating calls, the Req URI is needed for GCAC Profile specified limits. Since the SND service is started before the GCAC, the Req URI is already converted to the SND identity when GCAC is started. Therefore, a limit for originating SND calls can be configured. For the terminating calls, the P-A-I is needed for GCAC Profile specified limits. As the P-A-I does not carry any SND information, it is not possible to configure a limit for terminating SND calls.
For more information about the Call Admission Control (CAC) service, refer to MTAS Call Admission Control Management Guide.
2.7.4 Flexible Communication Distribution
The SND service is started after the Flexible Communication Distribution (FCD), and it adds the P-P-N-I header to the outgoing INVITE if it is an SND case. In other cases, the P-P-N-I header is not added.
For more information about the FCD service, refer to MTAS Flexible Communication Distribution Management Guide.
2.7.5 Communication Barring
The Communication Barring (CB) service consists of Outgoing Communication Barring (OCB) and Incoming Communication Barring (ICB). For INVITE and REFER messages, both OCB and ICB have interaction with the SND service. The OCB uses the Req URI for controlling INVITE, and the Refer-To for controlling REFER. Since the SND service is started before the OCB for the originating calls, the Req URI or Refer-To is already converted to the SND identity when OCB is started. Therefore, SND-related OCB can be performed. ICB does not control REFER, but it controls INVITE. For INVITE without Referred-By, the ICB can control both P-A-I and From depending on the configuration. For SND-related ICB, the control is to be on From which carries the SND identity. For INVITE with Referred-By, the ICB only controls the header. As Referred-By carries an SND identity for SND call, SND-related ICB can therefore be performed.
For more information about the CB service, refer to MTAS Barring and Dial Plan Services Management Guide.
2.7.6 Carrier Select
Carrier Select (CS) is depending on the Dialed String Analysis (DSA) for analyzing and fetching the Carrier Identity Code (CIC) which is the prefix to the dialed number. Carrier Select Rn (CS Rn) is depended on the Dialed String Analysis (DSA) for analyzing and fetching the Carrier Select Code (CSC) which is the prefix to the dialed number. Since the DSA is started before the NN, the CIC/CSC prefix is removed before the NN.
Since the SND service is started after the NN but before the CS/CS Rn, a Req URI with an SND number is already converted to a SIP URI by the SND service when the CS/CS Rn is started. Since the CS/CS Rn only applies on tel URI and embedded Tel, it does not apply on SIP URI with an SND identity. Therefore, when the dialed number is an SND number with CIC or CSC prefix, only the SND service is triggered and not the CS/CS Rn.
For more information about the CS services, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.
2.7.7 Carrier Pre-Select
Since the SND service is started before the Carrier Pre-Select (CPS) and Carrier Pre-Select Rn (CPS Rn), the Req URI with an SND number is already converted to a SIP URI by the SND service when the CPS/CPS Rn is started. Since the CS/CS Rn only applies on tel URI and embedded tel, it does not apply on SND identity. Therefore, when the dialed number is an SND number with CPS/CPS Rn configured, only the SND service is triggered and not the CPS/CPS Rn.
For more information about the Carrier Pre-Select (CPS) services, refer to MTAS Carrier Select and Carrier Pre-Select Management Guide.
2.7.8 Communication Completion
Communication Completion (CC) allows a caller who has attempted to call a subscriber who is not available, to activate a CC request against that subscriber. Later on when the receiver of the call is available, a recall is initiated by the originating MTAS by sending INVITE both to the caller and to the receiver of the call.
For the recall to the original caller, the caller’s default identity is used as the Req URI in the recall. Since the original caller is controlled by the originating MTAS, the recall is straight forward.
For the recall to the original receiver of the call, the select of the Req URI for the recall can be different. It can be in the NOTIFY from the terminating MTAS or in the original call. The recall can fail or be successful depending on if the Req URI is an SND identity or not. If the Req URI is an SND identity, the recall is rejected by the terminating MTAS owing to the lack of P-P-N-I. The reason is that the SND service is not involved in the recall, and the P-P-N-I is not added. If the Req URI is not an SND identity (for example, the default PUI of UE-B is used), the recall is routed to the receiver of the call as a non-SND call.
For more information about the CC service, refer to MTAS Communication Completion Management Guide.
2.7.9 Identity Presentation
The SND service only interacts with the Dynamic ad-hoc Identity Presentation, where the Supplementary Service Codes (SSCs) are dialed as a prefix to the destination number.
Since the preanalysis is performed by the SSC before the SND service, any received SSCs prefix are removed from the Req URI before the SND is started. If the Req URI contains an SND number, the SND service operates as if the identity had been provided by the calling user.
For more information about the Identity Presentation service, refer to MTAS Identity Presentation Management Guide.
2.7.10 Abbreviated Dialing
Since the Abbreviated Dialing is started before the SND service, any received Abbreviated Dialing code has been replaced with the stored target URI before the SND service is started. If the stored Abbreviated Dialing target is an SND identity, the SND service operates as if the identity had been provided by the calling user.
For more information about the Abbreviated Dialing service, refer to MTAS Abbreviated Dialing Management Guide.
2.7.11 Dialed Number Mapping
There is no interaction between the SND service and the Dialed Number Mapping (DNM) service. However, the SND service is dependent on the DNM service. The SND service must not be activated if the DNM service is provisioned.
For more information about the Dialed Number Mapping service, refer to MTAS Dialed Number Mapping Management Guide.
3 SND Configuration
The MO structure of the SND service is illustrated in Figure 2. The MtasSnd MO is the child to the MtasMmt MO. The MtasSnd MO contains attributes that control the SND service.
Configurable MOs and attributes related to the SND service are defined in Managed Object Model (MOM).
3.1 Announcement Configuration
Announcement is played to a caller when the SND service is activated.
Announcement handling and SND announcement attributes are described in MTAS Announcement Management Guide.
3.2 Number Normalization Configuration
The normalization data must be configured for the NN to recognize the SND number, in the following order:
- Profile
- Context
- Rule
An example configuration of the NN for recognizing all number with 3–5 digits as SND number is shown in the following tables:
|
Profile Name: numNormProfileName |
Profile Context: numNormProfileContext |
|---|---|
|
sweden |
se |
|
Configured Context: |
Substitution Expression Index: |
|---|---|
|
+46 |
Snd_Index1 |
|
se |
|
Index: numNormSubstitutionRuleIndex |
Substitution Expression |
|---|---|
|
Snd_Index1 |
0:/^([0-9]{3,5})$/EF\1/:TRUE(1) |
(1) [0-9] matches a short
telephone number consisting of digits. {3,5} matches a short number
with the range of three to five digits (up to the operator). EF is
an internal code used by the SND service.
For more information about the NN service, refer to MTAS Number Normalization Management Guide.
3.3 Configuration Activities
The extra configuration activity is listed in the following table:
|
Activity |
Attribute |
|---|---|
|
Specifying the SND domains. All subdomains of the specified domains are treated as SND domains. |
mtasSndDomains |
It is not allowed to remove the last SND domain if the SND administrative state is unlocked. For more information about the SND attributes, refer to Managed Object Model (MOM).
3.4 SND Administrative State Configuration
The SND service is enabled by setting the mtasSndAdministrativeState attribute in the MtasSnd MO to 1 (Unlocked). If the mtasSndAdministrativeState is set to 0 (Locked), no SND service is provided by the MTAS.
The SND service must not be unlocked if mtasIdPresFromHeaderScreening is set to 1 (enabled). The SND service must not be unlocked if mtasIdPresFromHeaderDenorm is set to 1 (enabled). The SND service must not be unlocked if no SND domain has been defined.
The SND service must not be unlocked if mtasDnmAdministrativeState is set to 1 (unlocked).
3.5 Wholesale for SND Configuration
The SND service supports Wholesale. SND is configurable on Virtual Telephony Provider (VTP) level.
Wholesale for SND is activated when the following attributes are set to 1 (Unlocked):
- The vtasSndAdministrativeState attribute in the VtasSnd MO
- The mtasSndAdministrativeState attribute in the MtasSnd MO
For more information about the Wholesale service, refer to MTAS Wholesale Support Management Guide.
3.6 Service Data Management
No service data for the SND service is configured for the subscriber data.
4 Performance Management
Measurements related to the SND service are detailed in Managed Object Model (MOM).
5 Fault Management
Alarms related to the SND service are listed in MTAS Alarm List.