Determining the MSISDN

The first step is to determine where to find the MSISDN of the subscriber whose voice mail is being accessed.

How the MSISDN is determined is dependent on the type of VM call that is made.Voice mail calls can be made in two ways:

• Redirected call to a VMS by the MSC
• Direct call to VMS using standard VMS number used by the MSC

When a call is redirected (indicated by the RDI parameter in the IDP), the MSISDN is identified by one of the following:

• Check for MSISDN in Re-Directing Number (RDN)
• If there is no MSISDN in RDN, get MSISDN from Original Called Number (OCN)

For a direct VMS call, the MSISDN is identified by checking for a VM prefix in the INAP CalledPartyNumber or the CAP CalledPartyBCDNumber resulting in one of the following options:

Determining the VMS ID

The second step is to find the VMS ID assigned to the subscriber (MSISDN). For this, V-Flex extracts the MSISDN from the appropriate parameter and uses it to search the Eagle Real-time Database (RTDB) to find the VMS ID assigned to that subscriber. A match may be found on a specific DN, or within a DN Block.

Determining the VMRN

The third step is to determine the VMRN. The VMRN is determined based on the following call conditions (combination of parameters in the Call Decision Table):

Voice Mail Number or Voice Mail Prefix (from the INAP/CAP CdPN or CdPBCDN parameter)

For redirect by the MSC, the Voice Mail Number is used.

For a direct dial by the subscriber, the Voice Mail Prefix is used if it is available ( VMPrefix + MSISDN in the INAP CdPN). When the VMPrefix is not available, the CdPN is used.

Different voice mail numbers correspond to different call scenarios and can be used to determine which VMS routing number should be used.

Redirection Indicator (INAP/CAP RDI parameter)

Indicates whether the call has been redirected (redirection signifies a voice mail deposit). If the call has not been redirected, the call is either a voice mail retrieval or a direct dialed VM deposit (as determined by the INAP/CAP CdPN).

Bearer Capabilities (INAP/CAP)

Determines the type of mail – for example voice, video, multimedia, etc.

Note:

Bearer Capabilities is a set of up to 32 values (0-31) configured by the network provider.

MSISDN found or not found in the EPAP RTDB

Indicates authorized versus unauthorized retrieval.

Based on the parameter values in the Call Decision Table, V-Flex determines the appropriate VMRN and returns it in a connect response to the MSC. The MSC uses the VMRN supplied by V-Flex to route the Voice Mail call.

Multiple Local Subsystems

Messages for Local Subsystems

MTP and SCCP Management to Support V-Flex

The EAGLE supports more than one local subsystem, allowing local subsystem for two or more EPAP-related features to operate at the same time. For example, local subsystems for V-Flex and EIR can coexist in the system.

The message arrives on the V-Flex subsystem on rt-on-ssn or rt-on-gt. If the message arrives rt-on-ssn, it must contain either the EAGLE true point code or the V-Flex capability point code in the DPC field of the message, and EAGLE V-Flex Subsystem number in the Called Party Subsystem field of the message. If V-Flex queries has the EAGLE capability point code for the DPC, then the EAGLE processes the message, but is not able to divert this message in the event of subsystem failure.

If a rt-on-gt message arrives at the EAGLE, it must either contain a CdPA address that translates to the V-Flex subsystem or match SCCP Service Selectors that have been provisioned to select V-Flex. These messages also should contain one of EAGLE capability point codes in the DPC field. The EAGLE also processes the message if it has the EAGLE’s true point code for the DPC, but it is not able to divert these messages in the event of subsystem failure.

If the V-Flex local subsystem is offline and the mated subsystem is available, the routing indicator is used to determine whether to reroute:

• If the message arrived route-on-ssn, the message is not rerouted to the mate. In this case, EAGLE is acting as an end node, and end nodes do not reroute. If the return on error option is set, the EAGLE generates a UDTS, otherwise it will discard the message.
• If the message arrived on route-on-gt, the message is rerouted to the mated subsystem. In this case, EAGLE is acting as both STP and SCP, and STPs do reroute messages.

If the V-Flex subsystem is offline, the EAGLE sends SSPs that causes the rt-on-ssn message to be diverted to the mate subsystem. These do not cause the rt-on-gt messages to be diverted. In order to make other nodes divert rt-on-gt traffic to the mate, the EAGLE will send response method TFPs to the APC of the message, when messages arrive rt-on-gt for one of the V-Flex Capability Point Codes and the result of translation is the EAGLE V-Flex subsystem. This TFP should cause the APC to divert traffic to the mate. If a message arrives rt-on-gt for the EAGLE True Point Code, the EAGLE will not generate a TFP. Therefore, nodes that send rt-on-gt traffic to the EAGLE should use a V-Flex capability point code, not the EAGLE True Point Code.

If the EAGLE receives an RSP (Route Set Test Message - Prohibited) for a V-Flex capability point code, and the V-Flex subsystem is offline, the EAGLE does not reply. If the EAGLE receives an RSR (Route Set Test Message - Restricted) for V-Flex capability point code, and the V-Flex subsystem is offline, the EAGLE replies with a TFP concerning the capability point code. When the V-Flex subsystem is online, RSRT replies to both RSRs and RSPs for the V-Flex capability point code with a TFA.

EPAP-related features that perform an RTDB lookup require Service Module cards (E5-SM4G, E5-SM8G-B, or SLIC cards) running the SCCPHC application. The EAGLE can be equipped with up to 32 (31+1) Service Module cards.

Features that do not perform an RTDB lookup require Service Module cards only for GTT processing that might be performed for the feature. These features can coexist in systems with EPAP, but do not require an EPAP connection.