Voice Call Flow Overview

Voice Call Flow Overview
Voice Call Flow Overview
To troubleshoot problems with voice networks, you must follow the call both inside the router and
outside on the network in order to isolate the problem. You must understand the relationship of dial peers
and call legs to follow the calls. For detailed information on dial peers and call legs, refer to Dial Peer
Configuration on Voice Gateway Routers.
The following sections contain information about call flow:
•
Call Setup, page 1
•
Call Flow Through Router Components, page 12
For information about voice network design, refer to Troubleshooting and Debugging VoIP Call Basics,
document ID 14081.
Call Setup
A voice call over a packet network is segmented into discrete call legs. Each call leg is associated with
a dial peer. A call leg is a logical connection between two voice gateways or between a gateway and an
IP telephony device (for example, Cisco CallManager or a session initiation protocol (SIP) server).
An example of POTS and VoIP call legs is shown in Figure 1.
Figure 1
Dial Peer Call Legs
Source
Destination
Call leg 1
(POTS dial peer)
Call leg 2
(VoIP dial peer)
Call leg 3
(VoIP dial peer)
V
35950
IP network
V
Call leg 4
(POTS dial peer)
Details for the call setup are described in the following sections:
•
Call Setup Elements, page 2
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Voice Call Flow Overview
Call Setup
•
Call Setup Process, page 3
•
Dial Peer Matching, page 5
Troubleshooting and debugging should focus first on each leg independently and then on the VoIP call
as a whole.
Call Setup Elements
You can isolate where a problem is occurring by determining which dial peer or call leg is having the
problem, as described in the following sections:
•
Source and Destination POTS Dial Peers, page 2
•
Voice Network Dial Peers, page 2
•
Inbound and Outbound Call Legs, page 3
Source and Destination POTS Dial Peers
POTS dial peers define the characteristics of a traditional telephony network connection. The POTS dial
peer maps a dial string to a specific voice port on the local gateway. Normally the voice port connects
the gateway to the local public switched telephone network (PSTN), PBX, or analog telephone.
Voice Network Dial Peers
Voice network dial peers define the attributes of a packet voice network connection. Voice network dial
peers map a dial string to a remote network device. Some examples of these remote network devices are
as follows:
•
Destination gateway
•
Cisco CallManager
•
SIP server
•
Open Settlements Protocol (OSP) server (for VoIP using settlement)
•
H.323 gatekeeper
•
Mail Transfer Agent (MTA) server (for Multimedia Mail over IP scenarios)
The specific type of voice-network dial peer used depends on the packet network technology. Different
technologies supported on voice dial peers are as follows:
2
•
Voice over IP (VoIP)—The dial peer is mapped to the IP address, Domain Name System (DNS)
name, or server-type of the destination VoIP device that terminates the call. This mapping applies to
all VoIP protocols such as H.323, SIP, and Media Gateway Control Protocol (MGCP).
•
Voice over Frame Relay (VoFR)—The dial peer is mapped to the data-link connection identifier
(DLCI) of the interface from which the call exits the router.
•
Voice over ATM (VoATM)—The dial peer is mapped to the ATM virtual circuit for the interface
from which the call exits the router.
•
Multimedia Mail over IP (MMoIP)—The dial peer is mapped to the e-mail address of the Simple
Mail Transfer Protocol (SMTP) server. This type of dial peer is used for store-and-forward fax
(on-ramp and off-ramp faxing).
Voice Call Flow Overview
Call Setup
The voice-network dial peer also sets the attributes of the network connection, such as which codec to
use, the capability to do voice activity detection (VAD), and dual-tone multifrequency (DTMF) relay
configuration. A voice network dial peer can point to any device that is compatible with skinny protocol
(SCCP), H.323, or SIP. MGCP configuration on a Cisco IOS gateway does not use voice network dial
peers.
Voice and Billing Application Call Leg
An IP call leg can go to an external application server. An example of a Cisco IOS VoiceXML application
is shown in Figure 2. This call leg is used for voice and billing applications, such as interactive voice
response (IVR).
Figure 2
Cisco IOS VoiceXML Application Components
HTTP server
SMTP server
PSTN
V
IP
network
TFTP server
IP
V
Cisco voice gateway
RTSP server
PSTN
37888
Cisco
VoiceXML-enabled
Gateway
Inbound and Outbound Call Legs
Each call leg can be either an inbound or outbound call leg, depending on the call’s direction. For a call
from an IP phone to the PSTN, the VoIP call leg is the inbound call leg, and the POTS leg is the outbound
call leg. The opposite is true for a call from the PSTN to the IP phone. Every call has an associated
inbound and outbound call leg.
Call Setup Process
A call is segmented into call legs with a dial peer associated with each call leg. See Figure 1.
The process has eight main steps:
1.
Note
The POTS call arrives at the originating gateway, and an inbound POTS dial peer is matched.
At this stage, if configured on the inbound POTS dial-peer, nondefault inbound POTS services or Tool
Command Language (Tcl) applications are used. When you use such services or applications, be certain
that the correct inbound POTS dial peer is matched. Examples of services or applications include:
•
Direct inward dialing (DID)
3
Voice Call Flow Overview
Call Setup
•
Tcl-based applications such as IVR, VoIP SIP transfer, or on-ramp faxing for store-and-forward fax.
2.
After the incoming call is associated with an inbound POTS dial peer, the originating gateway
creates an inbound POTS call leg and assigns it a CallEntry ID and global unique identifier (GUID).
For more information about these identifiers, see the “Debug Header Format” section on page 18.
3.
The originating gateway uses the dialed string to match an outbound voice-network dial peer.
4.
After the dialed string are associated with an outbound voice network dial peer, the originating
gateway creates an outbound voice-network call leg and assigns it a call ID for the second call leg.
The preceding process is illustrated in Figure 3.
Figure 3
Call Legs from the Perspective of the Originating Router
Source
Destination
IP network
Inbound
POTS call leg
V
Outbound
VoIP call leg
35946
V
5.
The voice network call request arrives at the terminating gateway and an inbound voice network dial
peer is matched.
6.
After the terminating gateway associates the incoming call to an inbound voice-network dial peer,
the terminating gateway creates the inbound voice-network call leg and assigns it a call ID for the
third call leg.
At this point, both gateways negotiate voice-network capabilities and applications (if required).
Default capabilities are not displayed in the gateway Cisco IOS configuration output. Use the show
dial-peer voice command to display the configured capabilities, services, and applications on POTS
and voice-network dial peers:
– Default capabilities include codec g729r8, vad enable, dtmf-relay disable, fax-relay disable,
req-qos best-effort, acc-qos best-effort, and session protocol cisco (for H.323).
– Examples of Tcl applications include remote IP authentication and off-ramp faxing.
When nondefault capabilities or applications are requested by the originating gateway, the
terminating gateways needs to match an inbound voice network dial peer that is configured for these
capabilities or applications.
7.
The terminating gateway uses the dialed string to match an outbound POTS dial peer.
8.
After associating the incoming call setup to an outbound POTS dial peer, the terminating
gatewaycreates an outbound POTS call leg, assigns it a call ID, and terminates the call.
The preceding steps are illustrated in Figure 4.
4
Voice Call Flow Overview
Call Setup
Figure 4
Call Legs from the Perspective of the Terminating Router
Source
Destination
IP network
V
Inbound
VoIP call leg
Outbound
POTS call leg
36849
V
In scenarios where Cisco CallManager is present with a Cisco IOS gateway, the following assumptions
apply:
•
For inbound calls to Cisco CallManager through a Cisco IOS gateway, the gateway behaves as an
originating device. (See Steps 1 to 4.)
•
For outbound calls from Cisco CallManager through a Cisco IOS gateway, the gateway behaves as
a terminating device. (See Steps 5 to 8.)
Dial Peer Matching
In order for a call to be routed, the attributes set in the dial peers must be matched. Each dial peer can
contain a variety of parameters. Some parameters are valid only for voice network or POTS dial peers,
and others apply to all dial peers. This section covers the following topics:
•
Inbound Dial Peer Matching, page 6
•
Outbound Dial Peer Matching, page 9
•
Voice Network Dial Peer Matching, page 11
•
POTS Dial Peer Matching, page 11
The destination-pattern parameter on the dial peer command controls call routing. For inbound dial
peers, the destination-pattern parameter is matched against the calling number, or automatic number
identifier (ANI) string. For outbound dial peers, the destination-pattern parameter is matched against
the called number, or dialed number identification service (DNIS) string. A dial peer with the
destination-pattern parameter works for both outbound and inbound matching.
Multiple dial peers can match a specific digit string. The gateway usually attempts to perform
longest-match routing. For example, if you have two patterns, 555.... and 55501.., and the called party
number is 5550123, the gateway matches the peer with 55501..; however, if the call to that peer fails, the
gateway attempts to use the other matching peer. If more than one peer has the same destination pattern
configured, the preference parameter on the dial peer can resolve the priority. The peer with the lowest
preference number has the highest priority.
The operational status for a dial peer must be administratively up and valid for it to be matched. To be
considered operational, dial peers must meet one of the following conditions:
•
destination-pattern is configured and a voice-port or session target is also configured.
•
incoming called-number is configured.
•
answer-address is configured.
Matching the called party number with the destination-pattern parameter is always used to match an
outbound dial peer. The inbound dial peer does not affect where the call is routed, but it does determine
all of the call properties for the voice network side of the call, regardless of where the outbound peer
5
Voice Call Flow Overview
Call Setup
terminates.The incoming called-number and answer-address commands are used only to match
inbound dial peers. They are not used for call routing or choosing an outbound dial peer. The incoming
called-number command matches based on the called party number but does not play a role in where
the call is routed. It is used only to select the inbound dial peer. If this match is unsuccessful, the
answer-address command tries for a match using the calling party number information rather than the
called party number. If both of these matches fail, the calling party information is matched against the
destination-pattern command configured on the dial peers. On POTS ports, the inbound dial peer can
be matched based on port configuration. If no match can be made, the dial peer 0 attribute is used. See
the “Dial Peer 0” section on page 7 for more information about dial peer 0.
For more information about the operational status of dial peers, refer to Understanding the Operational
Status of Dial Peers on Cisco IOS Platforms, document ID 12426.
For more detailed information on dial peer matching, configuration steps, and information about
parameters, refer to “Dial Peer Features and Configuration” in the Dial Peer Configuration on Voice
Gateway Routers document.
For additional information about dial peer matching, refer to Understanding Inbound and Outbound Dial
Peers Matching on IOS Platforms, document ID 14074.
Inbound Dial Peer Matching
The inbound dial peer determines all of the call properties for the voice network side of the call. Inbound
POTS dial peers are associated to incoming POTS call legs on the originating gateways. Inbound
voice-network dial peers are associated to incoming voice-network call legs of the terminating gateway.
To match inbound call legs to dial peers, the router uses three information elements in the call setup
message and five configurable dial peer attributes. The three call setup elements are:
•
Called number or DNIS—A set of numbers representing the destination, which is derived from the
ISDN setup message or channel associated-signaling (CAS) DNIS.
•
Calling number or ANI—A set of numbers representing the origin, which is derived from the ISDN
setup message or CAS ANI.
•
Voice port—The voice port carrying the call.
The five configurable dial peer attributes are:
•
Incoming called number—A string representing the called number or DNIS. It is configured by
using the incoming called-number dial-peer voice configuration command in POTS or MMoIP dial
peers.
•
Answer address—A string representing the calling number or ANI. It is configured by using the
answer-address dial-peer voice configuration command in POTS or VoIP dial peers and is used
only for inbound calls from the IP network.
•
Destination pattern—A string representing the calling number or ANI. It is configured by using the
destination-pattern dial-peer voice configuration command in POTS or voice-network dial peers.
•
Application—A string representing the predefined application that you enable on the dial peer. It is
configured by using the application dial-peer voice configuration command on inbound POTS dial
peers.
•
Port—The voice port through which calls to this dial peer are placed.
When the gateway receives a call setup request, a dial-peer match is made for the incoming call to
facilitate routing the call to different session applications. The gateway does not perform digit-by-digit
matching. Instead, the full digit string received in the setup request is used for matching against
configured dial peers.
6
Voice Call Flow Overview
Call Setup
The gateway selects an inbound dial peer by matching the information elements in the setup message
with the dial peer attributes. The gateway matches these items in the following order:
1.
Called number or DNIS with incoming called-number
First, the gateway attempts to match the called number of the call setup request with the configured
incoming called-number parameter of each dial peer. Because call setups always include DNIS
information, Cisco recommends using the incoming called-number command for inbound dial peer
matching. This attribute has matching priority over the answer-address and destination-pattern
parameter.
2.
Calling number or ANI with answer-address
If no match is found in Step 1, the gateway attempts to match the calling number of the call setup
request with the answer-address of each dial peer. This attribute may be useful in situations where
you want to match calls based on the calling number (originating).
3.
Calling number (ANI) with destination-pattern
If no match is found in step 2, the gateway attempts to match the calling number of the call setup
request to the destination-pattern of each dial peer.
4.
Voice port (associated with the incoming call setup request) with the configured dial peer port
parameter (applicable for inbound POTS call legs).
If no match is found in Step 3, the gateway attempts to match the configured dial-peer port
parameter 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 no match is found using these steps, then dial peer 0 is used. See the “Dial Peer 0” section on page 7
for more information about dial peer 0.
Note
Step 4 is not applicable to voice or dial platforms such as the Cisco AS5300 access server, Cisco AS5350
universal gateway, Cisco AS5400 universal gateway, Cisco AS5800 universal gateway, and Cisco
AS5850 universal gateway. If any one of first three steps are not used, then dial-peer 0 is matched and
the call is treated as a dial modem call. This call treatment can result in getting modem tones as opposed
to dial tone for inbound calls.
Only one condition must be met for the gateway to select a dial peer. The gateway stops searching as
soon as one dial peer is matched. It is not necessary for all the attributes to be configured in the dial peer
or that every attribute match the call setup information.
The longest prefix matching criteria applies while each step is performed. At each step, if multiple
matches are found, the one with the longest explicit match is chosen.
For more information on dial-peer matching, configuration steps, and information about parameters,
refer to “Dial Peer Features and Configuration” in the Dial Peer Configuration on Voice Gateway
Routers document.
Dial Peer 0
If no inbound peer can be matched by the defined criteria, the inbound peer is set to dial peer 0, which
sometimes appears as pid:0. The characteristics of dial peer 0 cannot be changed.
Note
Cisco universal gateways, such as the Cisco AS5350, Cisco AS5400, Cisco AS5800, and Cisco AS5850,
require configured inbound dial peers to match incoming POTS calls in order to be accepted as a voice
call. If there is no inbound dial peer match, the call is treated and processed as a dialup (modem) call.
7
Voice Call Flow Overview
Call Setup
For an inbound voice network call, dial peer 0 has the following characteristics:
•
Supports any codec
•
No DTMF relay
•
IP precedence 0
•
VAD-enabled
•
No RSVP support
•
Fax-rate voice
Dial peer 0 fails to negotiate nondefault capabilities, services, and applications, such as DTMF relay or
disabled VAD.
For an incoming POTS call, dial peer 0 has the following characteristics:
Note
•
No applications
•
No DID
Avoid using dial peer 0. Having the incoming called-number parameter configured correctly ensures
that the dial peer is always matched with the parameters you want when placing outbound calls through
a gateway. Many problems with calling out through a Cisco IOS gateway are due to codec, VAD, and
DTMF-relay misconfigurations when dial peer 0 is being matched. To display which dial peers are being
matched for an active call, use the show call active voice brief command.
Inbound Dial Peer Configuration Tips
For inbound dial peers, the following configuration tips apply to certain configurations:
Session Target Command
For inbound dial peers, the session target command is ignored.
ISDN Overlap Configuration
When the timer (T) character is included at the end of the destination pattern, the router collects dialed
digits until the interdigit timer expires (10 seconds, by default) or until you dial the termination character
(the default is #). The timer character must be an uppercase T. In most cases, you must configure the T
indicator only when the router uses two-stage dialing. If DID is configured in the inbound POTS dial
peer, the router uses one-stage dialing, which means that the full dialed string is used to match outbound
dial peers. The only exception is when the isdn overlap-receiving command is configured; the ISDN
overlap-receiving feature requires the T indicator.
When the isdn overlap-receiving command is configured on ISDN interfaces, dial peers are checked for
matches after every digit is received at the ISDN layer. If a full match is made, the call is routed
immediately without waiting for additional digits. The T indicator can be used to suspend this
digit-by-digit matching and force the gateway to wait until all digits are received. The T refers to the
T302 interdigit timer at the ISDN level, configurable under the serial interface associated with the ISDN
interface. ISDN also provides other mechanisms to indicate the end of digits, such as setting the Sending
Complete Information Element (IE) in a Q.931 information message.
Empty Calling Field with Variable-Length Dial Plans
In some voice network configurations, variable-length dial plans are required, especially if the network
connects two or more countries where telephone number strings could be different lengths. However, this
configuration can result in the calling number field being replaced with an empty number.
8
Voice Call Flow Overview
Call Setup
If you enter the T character in the destination-pattern parameter for your dial peer, the router can be
configured to accept a fixed-length dial string, and then wait for additional dialed digits. For example,
the following dial peer configuration shows how the T character can be set to allow variable-length dial
strings:
dial-peer voice 1 pots
destination-pattern 9T
port 1/0:1
If an incoming call arrives with no calling number information and is matched with the POTS dial peer
shown based on the destination-pattern 9T, the gateway uses the “9” digit as the calling number and
forwards the call to the corresponding device. To eliminate this behavior of replacing the empty calling
number field, create a dummy POTS dial peer with just the incoming called-number command
configured. Because the incoming called-number statement has higher priority than the
destination-pattern parameter for inbound POTS matching, dial-peer voice 2 is the POTS dial peer that
is used:
dial-peer voice 1 pots
destination-pattern 9T
port 1/0:1
!
dial-peer voice 2 pots
incoming called-number .
Outbound Dial Peer Matching
The method a router uses to select an outbound dial peer depends on whether DID is configured in the
inbound POTS dial peer. If DID is not configured in the inbound POTS dial peer, the router collects the
incoming dialed string digit by digit. When one dial peer is matched, the router immediately places the
call using the configured attributes in the matching dial peer.
If DID is configured in the inbound POTS dial peer, the router uses the full incoming dial string to match
the destination pattern in the outbound dial peer. With DID, the setup message contains all the digits
necessary to route the call; no additional digit collection is required. If more than one dial peer matches
the dial string, all of the matching dial peers are used to form a rotary group. The router attempts to place
the outbound call leg using all of the dial peers in the rotary group until one is successful.
For matching outbound dial peers, the gateway uses the destination-pattern dial peer command.
•
On POTS dial peers, the port command is used to forward the call.
•
On voice network dial peers, the session target command is used to forward the call.
DID Configuration
An example of incoming dial-peer configured with DID follows:
dial-peer voice 1 pots
incoming called-number 81690
voice-port 0:D
direct-inward-dial
On DID calls, also referred to as one-stage dialing, the setup message contains all digits necessary to
route the call, and the gateway should not do subsequent digit collection. When the gateway searches for
an outbound dial peer, it uses the entire incoming dial string. This matching is by default variable-length.
It is not done digit by digit because by DID definition all digits have been received. The following
example helps clarify this concept:
9
Voice Call Flow Overview
Call Setup
If the DID dial-string is “81690,” the router matches dial peer 4 and forwards the complete dial-string
“81690.”
dial-peer voice 3 voip
destination-pattern 816
session target ipv4:172.22.10.1
!
dial-peer voice 4 voip
destination-pattern 81690
session target ipv4:172.22.10.1
Two-Stage Dialing Configuration
If DID is not configured on the matched incoming dial peer, the gateway enters digit collection mode,
called two-stage dialing. Digits are collected inband. Outbound dial peer matching is done on a
digit-by-digit basis. The gateway checks for dial peer matches after receiving each digit and then routes
the call when a full match is made.
In this example, the dial string is “81690.” Immediately after the router receives the digit “6,” it matches
dial peer 3 and routes the call, forwarding only the digits “816.”
dial-peer voice 3 voip
destination-pattern 816
session target ipv4:172.22.10.1
!
dial-peer voice 4 voip
destination-pattern 81690
session target ipv4:172.22.10.1
In this example, dial-peer 3 is configured for wild card matching:
dial-peer voice 3 voip
destination-pattern 816..
session target ipv4:172.22.10.1
!
dial-peer voice 4 voip
destination-pattern 81690
session target ipv4:172.22.10.1
In this case, the longest-prefix rule applies and dial peer 4 is matched for the outbound call leg.
Variable-Length Dial Plans
There are situations where expected dial strings do not have a set number of digits. In such cases, it is
usually best to use variable-length dial peers by configuring the T terminator on the dial-peer
destination-pattern command.
The T terminator forces the gateway to wait until the full dial string is received by doing the following:
•
Waiting for a specified interdigit timeout before routing the call.
•
Routing the call once it receives the # termination character in the dial string. For example, if you
dialed 5550112#, the # would indicate to the router that you dialed all the digits and that all digits
before the # should be used to match a dial peer.
In the following example, the router receives a call setup from the network with dial string “95550112.”
Dial peer 2 then forwards the digits “5550112” to the PSTN.
dial-peer voice 2 pots
destination-pattern 9T
port 2/0:23
10
Voice Call Flow Overview
Call Setup
In the following example, the dial string from an inbound POTS interface is “81690”:
dial-peer voice 3 voip
destination-pattern 8T
session target ipv4:172.22.10.1
!
dial-peer voice 4 voip
destination-pattern 81690T
session target ipv4:172.22.10.1
In this case, the longest-prefix rule applies, and dial peer 4 is matched for the outbound call leg.
Note
The default interdigit timeout is set for 10 seconds. To modify this value, use the timeouts interdigit
voice-port command.
Anytime the T is used with destination-pattern parameter, it must be preceded by a . or digits (.T or
555T, for example). Using T on its own causes the dial peers to act improperly and affects how calls are
handled by the router.
Voice Network Dial Peer Matching
When a call comes in through VoIP, the voice gateway searches for an inbound peer by looking through
all the configured voice network dial peers. Using regular digit matching rules, it tries to match the peer
in the following order:
1.
Match the called number with the incoming called number.
2.
Match the calling number with the answer-address parameter.
3.
Match the calling number with the destination pattern.
4.
Otherwise, use dial peer 0. See the “Dial Peer 0” section on page 7 for more information.
POTS Dial Peer Matching
When a call comes in through POTS, the voice gateway searches for an inbound peer by looking through
all the configured POTS dial peers. Using regular digit-matching rules, it tries to match the peer in the
following order:
1.
Match the called number with the incoming called number.
2.
Match the calling number with the answer-address parameter.
3.
Match the calling number with the destination pattern.
If the inbound interface is not PRI or BRI, or if a PRI or BRI interface does not match a dial peer using
the preceding three rules, the voice gateway matches a POTS dial peer that has the inbound port
configured if any of the following parameters are configured:
•
destination-pattern
•
answer-address
•
incoming called-number
The answer-address parameter overwrites the call’s calling-party number or ANI.
11
Voice Call Flow Overview
Call Flow Through Router Components
Call Flow Through Router Components
You need to understand the call path through the router in order to determine where a problem is
occurring. The call path through a router is shown in Figure 5.
Router Call Flow
CLI
Session
application
SNMP
Call control API
Telephony
SPI
VoIP
SPI
VoFR
SPI
Dial plan
manner
Dial peer
table
Call
table
Interface
table
88970
Figure 5
The following definitions explain the function of the main components displayed in the router call flow
diagram:
•
Call control application programming interface (CCAPI)—Three clients make use of the
CCAPI: command-line interface (CLI), Simple Network Management Protocol (SNMP) agent and
Session Application. The CCAPI main functions are:
– Identify the call legs (Which dial peer is it? Where did it come from?).
– Decide which session application takes the call (Who handles it?).
– Invoke the packet handler.
– Conference the call legs together.
– Start recording call statistics.
12
•
Session application and dial plan mapper—The session application uses the dial plan mapper to
map a number to a dial peer (local POTS or remote VoIP). The dial plan mapper uses the dial peer
table to find active dial peers.
•
Telephony and VoIP service provider interface (SPI)—The telephony SPI communicates with the
POTS dial peers. The VoIP SPI is the specific interface to the VoIP peers. Telephony or digital signal
processor (DSP) drivers deliver services to the Telephony SPI; the VoIP SPI relies on session
protocols.
Voice Call Flow Overview
Call Flow Through Router Components
Telephony Interface Architecture
Figure 6 shows the architecture of Cisco router telephony building blocks and how they interact with
each other.
Figure 6
Telephony Interface Call Flow
CCAPI
Application
request
FXO SSM
FXS SSM
Setup/release
ind/response
E&M SSM
Voice telephony
service provider
(VTSP)
DSP resource manager
DSP
88971
Setup/release request
Voice processor
module
Application
response
The elements in Figure 6 have the following functions and definitions:
•
CCAPI—Software entity that establishes, terminates, and bridges call legs.
•
Voice telephony service provider (VTSP)—Cisco IOS process that services requests from the
CCAPI and formulates the appropriate requests to the DSPs or the voice processor module (VPM).
•
Voice processor module (VPM )— The VPM is in charge of bridging and coordinating signaling
processes between the telephony port signaling state machine (SSM), the DSP resource manager,
and the VTSP.
•
DSP resource manager (DSPRM)—The DSPRM provides interfaces by which the VTSP can send
and receive messages to and from the DSPs.
•
Packet handler—The packet handler forwards packets between the DSPs and the peer call legs.
•
Call peer—The call peer can be another telephony voice connection (POTS), VoFR, VoATM, or a
VoIP connection.
13
Voice Call Flow Overview
Call Flow Through Router Components
Voice Application Interface
For voice applications, the router interacts with an application server. In the example in Figure 7, the call
from the router is routed through the application module to the AAA server.
Figure 7
Voice Application Interface
Application-TCL
Session control
Call control API
Telephony SPI
Dial peer table
AAA RADIUS
Signaling
IP network
88988
TCP/UDP
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the
Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient,
and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (0710R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and
figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and
coincidental.
© 2007 Cisco Systems, Inc. All rights reserved.
14
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising