Distinguishing Modem and Voice Calls on Cisco AS5xxx Gateways

Available Languages

Download Options

PDF (36.8 KB)
View with Adobe Reader on a variety of devices

Updated:February 2, 2006

Document ID:9374

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

Prerequisites

Requirements

Components Used

Conventions

Problem

Solution

Call Flow for Incoming Calls on Telephony Interfaces

Example 1: PSTN through ISDN Signaling

Example 2: PSTN through E&M-Immediate CAS Signaling

Related Information

Introduction

Access servers (Cisco AS5350, AS5400, and AS5850) use the same Digital Signal Processor (DSP) for both modem and voice services. Cisco Any Service, Any Port (ASAP) architecture enables the Cisco AS5xxx to operate simultaneously as a network access server (NAS) and a voice gateway that delivers universal services on any port at any time. These gateways depend on the dial plan to differentiate when the router engages a modem or voice service for a specific call. This document describes how to configure the gateway to distinguish between voice and modem calls (necessary when the NAS supports both modem dialup and VoIP users on the same plain old telephone service [POTS] interface).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

Components Used

The information in this document is based on these software and hardware versions:

Cisco AS5xxx gateways
Cisco IOS Software Release 12.2(11)T and 12.3(1a)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Problem

The universal gateways have problems distinguishing modem calls from voice calls. The Cisco AS5350, AS5400, and AS5850 gateways use only dial peer matching to tell the router that the call is a voice call. Any other calls that do not have an inbound POTS dial peer match are considered a modem call.

For example, if you have the gateway configured as an originating and terminating gateway, then even when you use an incoming called number for voice calls, the router can still have a POTS match from a caller who calls the modem number. This is because their calling number is a match to the destination pattern of the POTS dial peer. Therefore, the call is still considered a voice call.

Solution

A TCL application called data_dialpeer was first introduced in Cisco IOS Software Release 12.2(2)XB and later integrated to Cisco IOS Software Release 12.2(11)T that could be configured under a POTS dial peer. Refer to Fine-Grain Address Segmentation in Dial Peers for more information about this application. This application enables any call that has an inbound match for that POTS dial peer to be considered a modem call, and helps when using the incoming called number method to match for modem calls. This output shows an example.

dial peer voice 3 POTS
 application data_dialpeer

!--- TCL application that supports data/modem calls.

incoming called-number 83103
!
dial peer voice 4 POTS
 application data_dialpeer
 incoming called-number 83104
!
dial peer voice 10 POTS
 incoming called-number XXXXX
 direct-inward-dial
!

This example output shows that calls with called numbers (83103 and 83104) are treated as modem calls, and all other calls are treated as voice.

Note: The data_dialpeer application is hidden in the sense that you cannot see it if you issue the command show call application voice data_dialpeer. However, if the router reloads, you do not lose the application configuration as long as you save it to memory.

Note: This is a temporary workaround for the AS5x00 router introduced in Cisco IOS Software Release 12.2(11)T. A permanent solution is introduced in Cisco IOS Software Release 12.2(13)T that allows for the creation of dial peers for Data/Modem calls.

Refer to Dial-Peer Support for Data Calls for more information about the Dial Peer Data feature.

Call Flow for Incoming Calls on Telephony Interfaces

The gateway creates an incoming Telephony leg for that call before it routes it to its destination. The gateway specifies what type of application or features to use for that call based on matching that incoming leg with a valid POTS dial peer. Whatever the application or features configured under that matched POTS dial peer, the router uses them for that call. Examples of such applications and features are Interactive Voice Response (IVR) and direct inward dial (DID).

A valid POTS dial peer needs to meet at least one of these conditions:

The POTS dial peer has a destination pattern and a port configured.
The POTS dial peer has an incoming called number configured.
The POTS dial peer has an answer address configured.

These are the steps that the router completes in order to perform the inbound matching for that call:

The router tries to match the called number (DNIS) to any dial peer that has incoming called number.

First, the router or gateway attempts to match the called number of the call set-up request with the configured incoming called-number of each dial-peer. Since call setups always include DNIS information, Cisco recommends you use the incoming called-number command for inbound dial peer matching. This attribute has matching priority over answer-address and destination-pattern.
The router tries to match the calling number (ANI) to any POTS dial peer that has answer address.

If no match is found in step 1, the router or gateway attempts to match the calling number of the call set-up request with the answer-address of each dial-peers. This attribute can be useful in situations where you want to match calls based on the calling number (originating).
The router tries to match the calling number (ANI) to the destination pattern of the POTS dial peer.

If no match is found in step 2, the router or gateway attempts to match the calling number of the call set-up request to the destination-pattern of each dial-peer.
The router tries to find a valid dial peer that has the port that the call came in on.

If no match is found in the step 3, the router or gateway attempts to match the configured dial-peer port to the voice-port associated with the incoming call. If multiple dial-peers have the same port configured, the dial-peer first added in the configuration is matched.
If none of the methods in steps 1 through 4 produces a match, the router matches the incoming call to the default POTS dial peer that has a peer tag = 0.

Note: Step 4 is not applicable to voice or dial platforms such as AS5300, AS5350, AS5400, AS5800 and AS5850. If any one of the first three steps are not used, then match dial-peer 0. The call is then treated as a dial modem call. This means that customers can get modem tones as opposed to dial tones for inbound calls.

The Cisco IOS router or gateway matches only one of these conditions. It is not necessary for all the attributes to be configured in the dial-peer or that every attribute match the call set-up information. Only one condition must be met for the router or gateway to select a dial-peer. The router or gateway stop to search as soon as one dial peer is matched.

After the applications or features are determined and used, the gateway matches the called number to an outbound dial peer and sends it to its destination.

Example 1: PSTN through ISDN Signaling

A gateway receives and terminates voice and modem calls from/to PSTN through ISDN signaling. If a user dials one of the two numbers (408-526-4800 and 408-526-4801) the call should be treated as a modem. If the user dials any other number (408-525-50xx) to that gateway, the call should be treated as voice. Because the router is used to terminate calls to the public switched telephone network (PSTN), it has a POTS dial peer as:

dial peer voice 1 POTS
 incoming called-number 52550..
 destination pattern 9.....
 direct-inward-dial
 port 2/0:D

The digit "9" is used as an access code to go out to the PSTN from the IP side.

In the setup message from PSTN, the calling number can be any number in the US, and the called number can be any of the previously mentioned numbers without the area code 408.

Because you configured incoming called number 52550.., users who call 408-525-50xx numbers have their call treated as voice. The problem is that if a caller with a calling number of 919-254-5566 calls one of the modem service numbers, then that call is still treated as a voice call. This is because the calling number is a match for the destination pattern of the previously mentioned POTS dial peer.

The solution is to use Cisco IOS Software Release 12.2(2)XB and apply it to another POTS dial peer with the data_dialpeer application and incoming called number as this output shows:

!
dial peer voice 1 POTS
 incoming called-number 52550..
 destination pattern 9.....
 direct-inward-dial
 port 2/0:D
!
dial peer voice 3 POTS
 application data_dialpeer
 incoming called number 5264800
!
dial peer voice 4 POTS
 application data_dialpeer
 incoming called number 5264801
!

In this example, the use of ISDN PRI makes it easy, since the calling and called numbers are both in the setup message. E&M-FGB or FGD channel associated signaling (CAS) (e&m-fgb, e&m-fgd) work the same way, as long as Digital Number Identification Service (DNIS) or ANI digits are provided.

Example 2: PSTN through E&M-Immediate CAS Signaling

In this example, the gateway is configured for CAS signaling e&m-immediate. The same numbers are used as in Example 1 for modem and voice calls. Because there are no calling and called numbers enblock for such signaling, the only way the router matches the incoming call to an inbound POTS dial peer is by using the port. The problem is that all the calls are a match for that POTS dial peer since the same port is used. Complete these steps to resolve the issue:

Create a separate voice port or ports by configuring ds0-group for certain time slots that you assign to receive only modem calls. All other timeslots are in another voice port.

The primary issue is that you want to avoid terminating calls on the voice ports assigned for receiving modem calls. However, you can still create a valid dial peer that has the voice port configured without having the destination pattern. In order to do this, use the incoming called number or answer address statement for that dial peer, and configure the port under it. There is no need to be concerned about the match with the incoming called number or the answer address, because there are no enblock calling or called numbers when the call hits the gateway. In such cases, the router uses only the port to do the matching. This is what the configuration looks like:
```
!
dial peer voice 1 POTS
 incoming called number 52550..
 destination pattern 9.....
 port 2/0:0
!
dial peer voice 3 POTS
 application data_dialpeer
 incoming called number 5264800
 port 2/0:1
!
dial peer voice 4 POTS
 application data_dialpeer
 incoming called number 5264801
 port 2/0:2
!
```
If you cannot assign certain time slots for modem calls, change your signaling to e&m-fgb, e&m-fgd, or ISDN signaling, where the calling or called numbers are sent in the setup message. See Example 1 for more information.