Cisco IOS Voice Troubleshooting and Monitoring Guide, Release 12.4
Troubleshooting Voice Applications
Downloads: This chapterpdf (PDF - 469.0KB) The complete bookPDF (PDF - 2.89MB) | Feedback

Troubleshooting Voice Applications

Table Of Contents

Troubleshooting Voice Applications

Troubleshooting Tcl IVR

Testing and Debugging Your Script

Loading Your Script

Associating Your Script with an Inbound Dial Peer

Displaying Information About IVR Scripts

Using URLs in IVR Scripts

URLs for Loading the IVR Script

URLs for Loading Audio Files

Tips for Using Your Tcl IVR Script

Media Inactive Call Detection

Prerequisites for Media Inactive Call Detection

Restrictions for Media Inactive Call Detection

Information about Media Inactive Call Detection

Improved Functionality of Media Inactive Call Detection

Modifications to Information Tags and Internal Error Codes

Configuring Media Inactive Call Detection

Output Examples for Media Inactive Call Detection

show call active voice brief Command: Example

show running config Command: Example

Sample Tcl IVR script

Troubleshooting Cisco VoiceXML

Debugging Cisco VoiceXML Applications

Error Events

JavaScript or ECMA Script

Troubleshooting Speech Recognition and Synthesis

Troubleshooting ASR and TTS Server Functionality

MGCP Scripting Overview

Events and Status Codes

Events

Status Codes

Authentication Status

Authorization Status

Digit Collection Status

Consult Response

Consult Status

Disconnect Cause

Facility

Feature Type

Leg Setup Status

Media Status

Transfer Status

VoiceXML Dialog Completion Status


Troubleshooting Voice Applications


Tcl and VoiceXML applications on the Cisco gateway provide Interactive Voice Response (IVR) features and call control capabilities such as call forwarding and voice mail.

The Cisco voice gateway allows voice applications to be used during call processing. Typically, application scripts contain both executable files and audio files that interact with the system software. Tcl scripts and VoiceXML documents can be stored in any of the following locations: TFTP, FTP, or HTTP servers, Flash memory of the gateway, or on the removable disks of the Cisco 3600 series. The audio files that they reference can be stored in any of these locations, and on Real Time Streaming Protocol (RTSP) servers. A Cisco voice gateway can have several voice applications to accommodate many different services, and you can customize the voice applications to present different interfaces to the various callers. IP phones can also originate calls to a gateway running a voice application.

Voice applications on Cisco gateways can be developed using a choice of two scripting languages:

Tcl IVR 2.0—Tcl-based scripting with an API.

VoiceXML—Standards-based markup language for voice browsers.

Applications can also be developed using a hybrid of both Tcl and VoiceXML. The following sections describe troubleshooting Cisco IOS Tcl and VoiceXML applications:

Troubleshooting Tcl IVR

Media Inactive Call Detection

Troubleshooting Cisco VoiceXML

MGCP Scripting Overview

Events and Status Codes

Troubleshooting Tcl IVR

Tcl IVR Version 2.0 uses Tcl scripts to gather data and to process accounting information. For example, a Tcl IVR script can play an audio prompt that asks callers to enter a specific type of information, such as a personal identification number (PIN). After playing the audio prompt, the Tcl IVR application collects the predetermined number of touch tones and sends the collected information to an external server for caller authentication and service authorization.

Figure 43 displays a Tcl IVR application on the gateway.

Figure 43 IVR Control of Tcl Scripts on an IP Call Leg

For information on developing Tcl scripts for voice applications, refer to the TCL IVR API Version 2.0 Programmer's Guide.

Refer to the following sections to troubleshoot a Tcl application:

Testing and Debugging Your Script

Loading Your Script

Associating Your Script with an Inbound Dial Peer

Displaying Information About IVR Scripts

Using URLs in IVR Scripts

Tips for Using Your Tcl IVR Script

Testing and Debugging Your Script

It is important to thoroughly test a script before it is deployed. To test a script, you must place it on a router and place a call to activate the script. When you test your script, make sure that you test every procedure in the script and all variations within each procedure.

You can view debugging information applicable to the Tcl IVR scripts that are running on the router. The debug voip ivr command allows you to specify the type of debug output you want to view. To view debug output, enter the following command in privileged-EXEC mode:

[no] debug voip ivr {states | error | tclcommands | callsetup | digitcollect | script | 
dynamic | applib | settlement | all}

For more information about the debug voip ivr command, see the Cisco IOS Debug Command Reference.

The output of any Tcl puts commands is displayed if script debugging is on.

Possible sources of errors are:

An unknown or misspelled command (for example, if you misspell media play as mediaplay)

A syntax error (such as, specifying an invalid number of arguments)

Executing a command in an invalid state (for example, executing the media pause command when no prompt is playing)

Using an information tag (info-tag) in an invalid scope (for example, specifying evt_dcdigits when not handling the ev_collectdigits_done event).

In most cases, an error such as these causes the underlying infrastructure to disconnect the call legs and clean up.

Loading Your Script

To associate an application with your Tcl IVR script, use the following command:

(config)# call application voice application_name script_url

After you associate an application with your Tcl IVR script, use the following command to configure parameters:

(config)# call application voice application_name script_url [parameter value]

In this command:

application_name specifies the name of the Tcl application that the system is to use for the calls configured on the inbound dial peer. Enter the name to be associated with the Tcl IVR script.

script_url is the pathname where the script is stored. Enter the pathname of the storage location first and then the script filename. Tcl IVR scripts can be stored in Flash memory or on a server that is acceptable using a URL, such as a TFTP server.

parameter value allows you to configure values for specific parameters, such as language or PIN length.

For more information about the call application voice command, refer to the Interactive Voice Response Version 2.0 on Cisco VoIP Gateways document on Cisco.com.

In the following example, the application named "test" is associated with the Tcl IVR script called newapp.tcl, which is located at tftp://keyer/debit_audio/:

(config)# call application voice test tftp://keyer/debit_audio/newapp.tcl

Note If the script cannot be loaded, it is placed in a retry queue and the system periodically retries to load it. If you modify your script, you can reload it using only the script name:(config)# call application voice load script_name


For more information about using the call application voice and call application voice load commands, refer to the Cisco IOS TCL IVR and VoiceXML Application Guide. For more information about these commands, refer to the Cisco IOS Voice Command Reference.

Associating Your Script with an Inbound Dial Peer

To invoke your Tcl IVR script to handle a call, you must associate the application configured with an inbound dial peer. To associate your script with an inbound dial peer, enter the following commands in configuration mode:

(config)# dial-peer voice number voip

(conf-dial-peer)# incoming called-number destination_number

(conf-dial-peer)# application application_name

In these commands:

number uniquely identifies the dial peer. (This number has local significance only.)

destination_number specifies the destination telephone number. Valid entries are any series of digits that specify the E.164 telephone number.

application_name is the abbreviated name that you assigned when you loaded the application.

For example, the following commands indicate that the application called "newapp" should be invoked for calls that come in from an IP network and are destined for the telephone number of 125.

(config)# dial-peer voice 3 voip
(conf-dial-peer)# incoming called-number 125
(conf-dial-peer)# application newapp

For more information about inbound dial peers, refer to Dial Peer Configuration on Voice Gateway Routers and the Cisco IOS TCL IVR and VoiceXML Application Guide.

Displaying Information About IVR Scripts

To view a list of the voice applications that are configured on the router, use the show call application voice command. A one-line summary of each application is displayed.

show call application voice {name | summary}

In this command:

name indicates the name of the desired IVR application. If you enter the name of a specific application, the system supplies information about that application.

summary indicates that you want to view summary information. If you specify the summary keyword, a one-line summary is displayed about each application. If you omit this keyword, a detailed description of the specified application is displayed.

The following is example output of the show call application voice command:

Router# show call application voice session2 
Idle call list has 0 calls on it. 
Application session2 
    The script is read from URL tftp://dirt/sarvi/scripts/tcl/app_session.tcl 
    The uid-len is 10               (Default) 
    The pin-len is 4                (Default) 
    The warning-time is 60          (Default) 
    The retry-count is 3            (Default) 
    It has 0 calls active. 
  
The TCL Script is:
------------------ 
# app_session.tcl 
#------------------------------------------------------------------ 
# Copyright (c) 1998, 1999 by cisco Systems, Inc. 
# All rights reserved. 
#------------------------------------------------------------------ 
# 
# This tcl script mimics the default SESSION app 
# 
# 
# If DID is configured, just place the call to the dnis 
# Otherwise, output dial-tone and collect digits from the 
# caller against the dial-plan. 
# 
# Then place the call. If successful, connect it up, otherwise 
# the caller should hear a busy or congested signal. 
  
# The main routine just establishes the state machine and then exits. 
# From then on the system drives the state machine depending on the 
# events it receives and calls the appropriate tcl procedure 
  
  
#--------------------------------- 
#   Example Script 
#--------------------------------- 
  
  
proc init { } { 
    global param 
  
    set param(interruptPrompt) true 
    set param(abortKey) * 
    set param(terminationKey) # 
  
} 
  
proc act_Setup { } { 
    global dest 
    global beep 
  
    set beep 0 
    leg setupack leg_incoming 
  
    if { [infotag get leg_isdid] } { 
        set dest [infotag get leg_dnis] 
        leg proceeding leg_incoming 
        leg setup $dest callInfo leg_incoming 
        fsm setstate PLACECALL 
    } else { 
  
        playtone leg_incoming tn_dial 
  
        set param(dialPlan) true 
        leg collectdigits leg_incoming param 
      } 
  
  
} 
  
proc act_GotDest { } { 
    global dest 
  
    set status [infotag get evt_status] 
  
    if {  $status == "cd_004" } { 
        set dest [infotag get evt_dcdigits] 
        leg proceeding leg_incoming 
        leg setup $dest callInfo leg_incoming 
  
    } else { 
        puts "\nCall [infotag get con_all] got event $status while placing an outgoing 
call" 
        call close 
    } 
} 
  
  
proc act_CallSetupDone { } { 
    global beep 
  
    set status [infotag get evt_status] 
  
    if { $status == "CS_000"} { 
  
        set  creditTimeLeft [infotag get leg_settlement_time leg_outgoing] 
  
        if { ($creditTimeLeft == "unlimited") || 
             ($creditTimeLeft == "uninitialized") } { 
            puts "\n Unlimited Time" 
        } else { 
            # start the timer for ... 
            if { $creditTimeLeft < 10 } { 
                set beep 1 
                set delay $creditTimeLeft 
            } else { 
                set delay [expr $creditTimeLeft - 10] 
            } 
            timer start leg_timer $delay leg_incoming 
        } 
    } else { 
        puts "Call [infotag get con_all] got event $status collecting destination" 
        call close 
    } 
} 
  
proc act_Timer { } { 
    global beep 
    global incoming 
    global outgoing 
  
    set incoming [infotag get leg_incoming] 
    set outgoing [infotag get leg_outgoing] 
  
    if { $beep == 0 } { 
        #insert a beep ...to the caller 
        connection destroy con_all 
        set beep 1 
    } else { 
        media play leg_incoming flash:out_of_time.au 
        fsm setstate CALLDISCONNECTED 
    } 
} 
  
proc act_Destroy { } { 
    media play leg_incoming flash:beep.au 
} 
  
proc act_Beeped { } { 
    global incoming 
    global outgoing 
  
    connection create $incoming $outgoing 
} 
  
proc act_ConnectedAgain { } { 
    timer start leg_timer 10 leg_incoming 
} 
  
proc act_Ignore { } { 
# Dummy 
    puts "Event Capture" 
} 
  
proc act_Cleanup { } { 
    call close 
} 
  
init 
  
#---------------------------------- 
#   State Machine 
#---------------------------------- 
  set TopFSM(any_state,ev_disconnected) "act_Cleanup,same_state" 
  set TopFSM(CALL_INIT,ev_setup_indication) "act_Setup,GETDEST" 
  set TopFSM(GETDEST,ev_digitcollect_done) "act_GotDest,PLACECALL" 
  set TopFSM(PLACECALL,ev_setup_done)  "act_CallSetupDone,CALLACTIVE" 
  set TopFSM(CALLACTIVE,ev_leg_timer) "act_Timer,INSERTBEEP" 
  set TopFSM(INSERTBEEP,ev_destroy_done) "act_Destroy,same_state" 
  set TopFSM(INSERTBEEP,ev_media_done)  "act_Beeped,same_state" 
  set TopFSM(INSERTBEEP,ev_create_done)    "act_ConnectedAgain,CALLACTIVE" 
  set TopFSM(CALLACTIVE,ev_disconnected)   "act_Cleanup,CALLDISCONNECTED" 
  set TopFSM(CALLDISCONNECTED,ev_disconnected) "act_Cleanup,same_state" 
  set TopFSM(CALLDISCONNECTED,ev_media_done)  "act_Cleanup,same_state" 
  set TopFSM(CALLDISCONNECTED,ev_media_done)  "act_Cleanup,same_state" 
  set TopFSM(CALLDISCONNECTED,ev_disconnect_done) "act_Cleanup,same_state" 
  set TopFSM(CALLDISCONNECTED,ev_leg_timer) "act_Cleanup,same_state" 
  
  
  fsm define TopFSM  CALL_INIT 

Using URLs in IVR Scripts

With IVR scripts, you use URLs to call the script and to call the audio files that the script plays. The VoIP system uses Cisco IOS File System (IFS) to read the files, so any IFS-supported URLs can be used, which includes TFTP, FTP, or a pointer to a device on the router.


Note There is a limit of 32 entries in Flash memory, so you may not be able to copy all your audio files into Flash memory.


URLs for Loading the IVR Script

The URL of the IVR script is a standard URL that points to the location of the script. Examples include:

flash:myscript.tcl—The script called myscript.tcl is being loaded from Flash memory on the router.

slot0:myscript.tcl—The script called myscript.tcl is being loaded from a device in slot 0 on the router.

tftp://BigServer/myscripts/betterMouseTrap.tcl—The script called myscript.tcl is being loaded from a server called BigServer in a directory within the tftpboot directory called myscripts.

URLs for Loading Audio Files

URLs for audio files are different from those used to load IVR scripts. With URLs for audio files:

For static prompts, you can use the IFS-supported URLs as described in the "URLs for Loading the IVR Script" section.

For dynamic prompts, the URL is created by the software, using information from the parameters specified for the media play command and the language CLI configuration command.

Tips for Using Your Tcl IVR Script

This section provides some answers to frequently asked questions about using Tcl IVR scripts.

How do I get information from my RADIUS server to the Tcl IVR script?

After you have performed an authentication and authorization, you can use the infotag get command to obtain the credit amount, credit time, and cause codes maintained by the RADIUS server.

What happens if my script encounters an error?

When an error is encountered in the script, the call is cleared with a cause of TEMPORARY_FAILURE (41). If the IVR application has already accepted the incoming call, the caller hears silence. If the script has not accepted the incoming call, the caller might hear a fast busy signal.

If the script exits with an error and IVR debugging is on (as described in the "Testing and Debugging Your Script" section), the location of the error in the script is displayed at the command line.

Media Inactive Call Detection

The Media Inactive Call Detection feature enhances Cisco IOS behavior for disconnecting a call when an inactive condition is detected. The former behavior automatically disconnected inactive calls. The current feature provides more control for managing these calls.

The Media Inactive Call Detection feature detects inactive (silent) H.323 or SIP call-legs on Cisco IOS-based gateways, and reports this situation to the Tcl IVR 2.0 application (which can disconnect the call). When the Media Inactive Call Detection feature is enabled, Cisco IOS software does not automatically disconnect detected inactive calls. Inactivity is defined as no RTP/RTCP packets for a configurable length of time.

The command-line interface enables system administrators to do the following:

Use additional filters to display one or more calls detected and reported as inactive

Manually release a call by entering the called number, the calling number, or the call ID

The Media Inactive Call Detection feature enables a system administrator to view all detected inactive calls that have been reported to the Tcl script. An internal error code (IEC) is generated when an inactive call is requested to be cleared via the CLI command.

The following sections provide configuration information for Media Inactive Call Detection:

Prerequisites for Media Inactive Call Detection

Restrictions for Media Inactive Call Detection

Information about Media Inactive Call Detection

Configuring Media Inactive Call Detection

Output Examples for Media Inactive Call Detection

Prerequisites for Media Inactive Call Detection


Note Before the following step is done, you should set the inactive timer. This can be done using the timer receive-rtcp command in the CLI or it can be set in the script itself using infotag set media_timer_factor.


The Media Inactive Call Detection feature requires Cisco IOS Release 12.3(4)T or later.

To enable the Media Inactive Call Detection feature, set the information tag evt_feature_report using media_inactivity type. For example:

infotag set evt_feature_report media inactivity

Restrictions for Media Inactive Call Detection

The Media Inactive Call Detection feature does not change the existing behavior for the default session application and Tcl IVR 1.0 or the existing Tcl IVR 2.0 script behavior that does not request the new feature.

This feature does not support MGCP call legs.

The Media Inactive Call Detection feature works in IP only. This feature does not include PSTN inactive call detection.

This feature supports RTP/RTCP media inactivity detection and notification only on H.323 and SIP basic calls.

Information about Media Inactive Call Detection

This section provides information about the configuration of Media Inactive Call Detection.

Improved Functionality of Media Inactive Call Detection

Modifications to Information Tags and Internal Error Codes

Improved Functionality of Media Inactive Call Detection

Legacy Functionality

This functionality is an enhancement to the pre-existing Media Inactivity Timer feature, which enables gateways to monitor and disconnect VoIP calls if no RTCP packets are received within a configurable time period.

The Media Inactivity Timer feature requires the configuration of the Cisco IOS ip rtcp report interval command and the timer receive-rtcp command to enable detection of RTCP packets by the gateway. When these commands are configured, the gateway uses RTCP report detection, rather than RTP packet detection, to determine whether calls on the gateway are still active or should be disconnected.

If no RTCP packets are received in the resulting time period, the call is disconnected.

The ip rtcp report interval command configures the RTCP reporting interval in milliseconds in the range of 1 to 65535. The timer receive-rtcp command configures the multiplier in the range of 2 to 1000. These values can be adjusted depending on network traffic conditions. Under normal conditions, a value of 5000 for the ip rtcp report interval and a value of 5 for the timer receive-rtcp are typical.

Current Functionality

The Media Inactive Call Detection feature offers the following:

The show call active command indicates that a call has no RTP or RTCP inactivity.

The clear call command offers options so that an inactive call can be released using the called number or calling number. The clear call command has also been enhanced to configure the Q.850 release cause code to be used when the call is released.

Modifications to Information Tags and Internal Error Codes

This feature includes modifications to two information tags, the addition of two information tags, and an internal error code:

evt_feature_report

evt_feature_type

evt_feature_param

media_timer_factor

media_inactivity_err

For more detailed information, refer to the Cisco IOS TCL and VoiceXML Application Guide and the Cisco IOS TCL Programming Guide.

evt_feature_report

This existing tag has a new event name (media_inactivity) added for the Tcl script to request notification of media inactivity detection.

Description

To enable/disable certain feature events to be intercepted by the script

Syntax

Infotag set evt_feature_report {["no_"]event_names}

Where event_name is a list of application event names that define what events should or should not be reported to application when call is active (connected). An event name with "no_" prefix means not to report it.

Mode

Write

Scope

ev_feature

Return Type

None

Direct Mapping

None

Event Names:

fax

modem

modem_phase

hookflash

onhook

offhook

media_inactivity

Example

The following example enables hookflash and disable fax and modem feature events to be received by the script:

infotag set evt_feature_report hookflash nofax no modem

The following example enables media_inactivity event to be received by the script:

infotag set evt_feature_report media_inactivity

evt_feature_type

This existing information tag adds two new event feature types representing media inactivity notification and media activity notification. Note that the script only needs to request for report type media_inactivity. However, after media inactivity is reported and the VoIP RTP starts receiving RTP/RTCP packets again, the event with type media_activity is automatically notified, indicating that the call is back alive.

Description

To return the feature type string when a feature event is received

Syntax

infotag get evt_feature_type

Mode

Read

Scope

ev_feature

Return Type

String

Direct Mapping

None

Event Names

fax

modem

modem_phase

hookflash

onhook

offhook

media_inactivity

media_activity

evt_feature_param

This is a new information tag added so that the Tcl application can pass along parameters related to the feature back to the script. The Media Inactive Call Detection feature uses this new tag to pass the information on whether RTCP packet has been received before the media inactive condition is met.

Description

To return a parameter related to a specific feature event

Syntax

infotag get evt_feature_param parameter_name

Mode

Read

Scope

ev_feature

Return Type

String

Direct Mapping

None

Event Parameter

media_inactivity_type—This parameter belongs to feature media_inactivity. The return string is:

no media received—Media inactivity detected (no RTP or RTCP packets have been received for a configured amount of time). RTCP packet has been received before media inactivity condition is met.

no control info received—Media inactivity detected (no RTP or RTCP packets have been received for a configured amount of time). No RTCP packet has been received before media inactivity condition is met.

Example

infotag get evt_feature_param media_inactivity_type

media_timer_factor

This new information tag gives the Tcl script the ability to overwrite the configured gateway receive-rtcp timer. This value is used to calculate the timeout value used to detect media inactivity.

Description

To set the timer receive-rtcp timer. This new value is used within the scope of the script. It does not change the gateway configuration.

Syntax:

infotag set media_timer_factor timer_factor

Mode

Write

Scope

None

Return Type

None

Direct Mapping

None

Timer factor:

An integer between 2 and 1000. This value is the multiple of RTCP report transmission interval—a value of 5 is recommended.

Example:

infotag set media_timer_factor 6


Note If the value specified is not between 2 and 1000, the script generates an error message.


media_inactivity_err

The internal error code used by the Tcl script for this feature is media_inactivity_err (common IEC error #8). This IEC is used to disconnect a call where media inactivity is detected and reported.

Configuring Media Inactive Call Detection

This feature is enabled using Tcl IVR 2.0.

This section describes the use of this feature to set parameters for determining call inactive status and then clearing specific calls. These new options are designed to work as filters.

SUMMARY STEPS

1. enable

2. Make a call using the Tcl IVR 2.0 script application. While the call is going, the commands in steps 3 and 4 can be used.

3. show call active voice [brief] [called-number number | calling-number number | compact | echo-canceller | id | media-inactive {called-number number | calling-number number}]

4. clear call voice causecode <1-127> {id <1-FFFF> | media-inactive}

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

Make a call using the TCL IVR script application

Starts a call. While the call is going, the commands in steps 3 and 4 can be used.

Step 3 

show call active voice [brief] [called-number number | calling-number number | compact | echo-canceller | id | media-inactive {called-number number | calling-number number}]

Example:

Router# show call active voice media-inactive calling-number 4085551234


Router# show call active voice brief media-inactive called-number 4085554321

Displays calls that have no RTP or RTCP activity.

The brief keyword shows the brief version of active voice calls.

The called-number keyword shows only the call with the specified called number pattern.

The calling-number keyword shows only the call with the specified calling number pattern.

The compact keyword shows a compact version of the active voice calls.

The echo-canceller keyword shows echo canceller data for an active voice call.

The id keyword shows only the call with the specified ID.

The media-inactive keyword shows only the calls with media inactive being detected and notified.

The number argument is a sequence of digits representing a full, recognizable telephone number.

Step 4 

clear call voice causecode <1-127> {id <1-FFFF> | media-inactive}

Example:

Router# clear call voice causecode id 112B

Clears calls that show media inactive and can clear a specific call.

The causecode keyword is a Q.850 disconnect cause code. The cause code can be specified as a number 1 through 127.

The id keyword can be used so that only the voice call with the specified ID is disconnected.

The 1-FFFF range is a call identifier as shown in brief format.

The media-inactive keyword clears only calls with media inactivity detected and notified.


Output Examples for Media Inactive Call Detection

The examples provided in this section include the following:

show call active voice brief Command: Example

show running config Command: Example

Sample Tcl IVR script

show call active voice brief Command: Example

The existing show call active voice brief command has additional media inactive detection data in the IP call leg information.

router# show call active voice brief
<ID>: <start>hs.<index> +<connect> pid:<peer_id> <dir> <addr> <state>
  dur hh:mm:ss tx:<packets>/<bytes> rx:<packets>/<bytes>
 IP <ip>:<udp> rtt:<time>ms pl:<play>/<gap>ms lost:<lost>/<early>/<late>
  delay:<last>/<min>/<max>ms <codec>
 media inactive detected:<y/n> media cntrl rcvd:<y/n> timestamp:<time>
  			<----------- the above line is new --------------
   MODEMPASS <method> buf:<fills>/<drains> loss <overall%> <multipkt>/<corrected>
   last <buf event time>s dur:<Min>/<Max>s
 FR <protocol> [int dlci cid] vad:<y/n> dtmf:<y/n> seq:<y/n>
  <codec> (payload size)
 ATM <protocol> [int vpi/vci cid] vad:<y/n> dtmf:<y/n> seq:<y/n>
  <codec> (payload size)
 Tele <int>: tx:<tot>/<v>/<fax>ms <codec> noise:<l> acom:<l> i/o:<l>/<l> dBm
  MODEMRELAY info:<rcvd>/<sent>/<resent> xid:<rcvd>/<sent> total:<rcvd>/<sent>/<drops>
         speeds(bps): local <rx>/<tx> remote <rx>/<tx>
 Proxy <ip>:<audio udp>,<video udp>,<tcp0>,<tcp1>,<tcp2>,<tcp3> endpt: <type>/<manf>
 bw: <req>/<act> codec: <audio>/<video>
  tx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes>
 rx: <audio pkts>/<audio bytes>,<video pkts>/<video bytes>,<t120 pkts>/<t120 bytes>


Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Total call-legs: 2

11DF : 239062hs.1 +2 pid:1 Answer 4085254616 active
 dur 00:01:04 tx:2383/89775 rx:1187/23318
 Tele 3:D:13: tx:45900/2110/0ms g729r8 noise:-69 acom:45  i/0:-71/-29 dBm

11DF : 239684hs.1 +830 pid:1800877 Originate 18008770519 active
 dur 00:00:49 tx:1066/20965 rx:2378/47215
 IP 1.9.57.5:17750 rtt:5ms pl:38190/0ms lost:0/1/0 delay:50/50/70ms g729r8
 media inactive detected:y media cntrl recv:y timestamp: 12595
 		<------------------ the above line is new ------------------
Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Total call-legs: 2


Note For calls without media inactivity being detected, the display looks like the following:


...
11DF : 239062hs.1 +2 pid:1 Answer 4085254616 active
 dur 00:01:04 tx:2383/89775 rx:1187/23318
 Tele 3:D:13: tx:45900/2110/0ms g729r8 noise:-69 acom:45  i/0:-71/-29 dBm

11DF : 239684hs.1 +830 pid:1800877 Originate 18008770519 active
 dur 00:00:49 tx:1066/20965 rx:2378/47215
 IP 1.9.57.5:17750 rtt:5ms pl:38190/0ms lost:0/1/0 delay:50/50/70ms g729r8
 media inactive detected:y media cntrl recv:n/a timestamp: n/a
 		<------------------ the above line is new ------------------
Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Total call-legs: 2

The long display form of active call records generated by the show call active voice command is also modified to add the media inactive detected information.


Router_5300# show call active voice
Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Total call-legs: 2

 GENERIC:
SetupTime=239062 ms
Index=1
PeerAddress=4085254616
PeerSubAddress=
PeerId=1
...
TELE:
ConnectionId=[0xB21F398F 0x1DA111D4 0x800B85CB 0x3E43F332]
IncomingConnectionId=[0xB21F398F 0x1DA111D4 0x800B85CB 0x3E43F332]
TxDuration=51250 ms
VoiceTxDuration=2110 ms
...
 GENERIC:
SetupTime=239684 ms
Index=1
PeerAddress=18008770519
PeerSubAddress=
...
VOIP:
ConnectionId[0xB21F398F 0x1DA111D4 0x800B85CB 0x3E43F332]
IncomingConnectionId[0xB21F398F 0x1DA111D4 0x800B85CB 0x3E43F332]
RemoteIPAddress=1.9.57.5
...
TranslatedRedirectCalledNumber=
TranslatedRedirectCalledOctet=0x7F
MediaInactiveDetected=yes                 <---- new
MediaInactiveTimestamp=12595              <---- new
MediaControlReceived=yes                  <---- new
Username=Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Total call-legs: 2


Note For calls where no media inactivity is detected and notified, the above three fields are displayed as follows:


TranslatedRedirectCalledNumber=
TranslatedRedirectCalledOctet=0x7F
MediaInactiveDetected=no                  <---- new
MediaInactiveTimestamp=                   <---- new
MediaControlReceived=                     <---- new
Username=Telephony call-legs: 1
SIP call-legs: 0
H323 call-legs: 1
Total call-legs: 2

show running config Command: Example

router# show running config
Building configuration...
This command has no effect on this line; use modem AT commands instead
This command has no effect on this line; use modem AT commands instead

Current configuration : 13850 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname "jc5400"
!
no boot startup-test
logging buffered 2000000 debugging
no logging console
enable secret 5 $1$afrj$LWwkVSLZ3cKak3OkHsAMt/
enable password lab
!
username 1111
username 2222 password 0 2222
username 123001 password 0 1001
username cisco
!
!
resource-pool disable
clock timezone GMT -8
tdm clock priority 1 6/0
spe default-firmware spe-firmware-1
aaa new-model
!
!
aaa authentication login h323 local group radius
aaa authentication login telnet none
aaa authorization exec h323 local group radius 
aaa authorization exec telnet none 
aaa accounting connection h323 start-stop group radius
aaa session-id common
ip subnet-zero
ip cef
ip ftp username dump
ip ftp password dump123
no ip domain lookup
ip host tftp-server1 10.1.1.211
ip host rtsp-server1 10.1.1.211
ip host radius-server1 10.1.1.211
ip host gwip-server1 10.1.1.211
ip host dump-server1 10.1.1.211
!
isdn switch-type primary-5ess
isdn voice-call-failure 0
!
voice call carrier capacity active
!
!
!
voice cause-code 
!
no voice hpi capture buffer
no voice hpi capture destination
!
!
ivr prompt memory 16384
!
fax interface-type fax-mail
mta receive maximum-recipients 600
!
!
!
controller T1 6/0
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
 no yellow generation
 no yellow detection
!
controller T1 6/1
 shutdown
 framing sf
 linecode ami
 no yellow generation
 no yellow detection
!
controller T1 6/2
 shutdown
 framing sf
 linecode ami
 no yellow generation
 no yellow detection
!
controller T1 6/3
 shutdown
 framing sf
 linecode ami
 no yellow generation
 no yellow detection
!
controller T1 6/4
 shutdown
 framing sf
 linecode ami
 no yellow generation
 no yellow detection
!
controller T1 6/5
 shutdown
 framing sf
 linecode ami
 no yellow generation
 no yellow detection
!
controller T1 6/6
 shutdown
 framing sf
 linecode ami
 no yellow generation
 no yellow detection
!
controller T1 6/7
 shutdown
 framing sf
 linecode ami
 no yellow generation
 no yellow detection
gw-accounting aaa
!
!
!
interface FastEthernet0/0
 ip address 10.1.1.212 255.255.0.0
 no ip redirects
 no ip mroute-cache
 duplex auto
 speed auto
 no cdp enable
!
interface FastEthernet0/1
 no ip address
 no ip redirects
 no ip mroute-cache
 shutdown
 duplex auto
 speed auto
 no cdp enable
!
interface Serial0/0
 no ip address
 no ip mroute-cache
shutdown
 clockrate 2000000
 no cdp enable
!
interface Serial6/0
 no ip address
 shutdown
!
interface Serial0/1
 no ip address
 no ip mroute-cache
 shutdown
 clockrate 2000000
 no cdp enable
!
interface Serial6/0:23
 no ip address
 isdn switch-type primary-5ess
 isdn incoming-voice modem
 isdn bchan-number-order ascending
 no keepalive
 no cdp enable
!
interface Group-Async0
 no ip address
 no ip mroute-cache
 group-range 1/00 1/107
!
ip classless
ip route 10.1.0.0 255.255.0.0 10.1.1.211
ip http server
!
ip pim bidir-enable
ip rtcp report interval 5000
!
!
no logging trap
dialer-list 1 protocol ip permit
dialer-list 1 protocol ipx permit
!
!
radius-server host 10.1.1.211 auth-port 1645 acct-port 1646
radius-server key cisco
radius-server authorization permit missing Service-Type
radius-server vsa send accounting
radius-server vsa send authentication
!
call application voice testapp_JC tftp://10.1.1.211/Scripts/JC_app1.tcl
call rsvp-sync
!
voice-port 6/0:D
!
!
mgcp profile default
!
dial-peer cor custom
!
!
!
dial-peer voice 1000 pots
 application testapp_JC
 incoming called-number 5551001
 direct-inward-dial
 port 6/0:D
!
!
dial-peer voice 3000 voip
 destination-pattern 5551001
 session target ipv4:10.1.1.213
 dtmf-relay h245-signal
codec g711ulaw
!
!
gateway 
 timer receive-rtcp 5
!
sip-ua 
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
 logging synchronous
line vty 0 4
 password lab
 authorization exec telnet
 login authentication telnet
line 1/00 1/107
 no flush-at-activation
 modem InOut
!
exception core-file jc5400_core
exception protocol ftp
exception dump 10.1.1.211
scheduler allocate 10000 400
end

Sample Tcl IVR script

The following is a sample script that is provided for reference purposes only.

silence_detect_demo.tcl 
#------------------------------------------------------------------
# Copyright (c) 2003 by cisco Systems, Inc.
# All rights reserved.
#------------------------------------------------------------------
#
# This tcl demo script monitors Media Inactive Call. The Media Inactive Call
# Detection feature detects inactive (silent)H.323 or Sip call-legs on Cisco
# IOS based gateways, and reports this situation to the TCL IVR 2.0 application
# and TCL IVR application checks for the events and logs those events. 
#
# This script is designed to place a call to the dnis if DID is configured.
# Otherwise, output dial-tone and collects digits from the caller against
# the dial-plan. If an inactive condition 'ev_feature' is detected then script
# begins to log the inactivity events.  However, if the VOIP RTP starts receiving
# RTP/RTCP packets again, then event with media_activity type will be automatically
# notified, indicating that the call is back alive.                          
#
#---------------------------------
#   Example Script
#---------------------------------

proc init { } {
    global param
    global timerFactor

    set param(interruptPrompt) true
    set param(abortKey) *
    set param(terminationKey) #
    set timerFactor 6
}
  
proc act_Setup { } {
    global dest

    if { [infotag get leg_isdid] } {
        set dest [infotag get leg_dnis]

        leg proceeding leg_incoming
        leg setup $dest callInfo leg_incoming
        fsm setstate PLACECALL
    } else {
        leg setupack leg_incoming
        playtone leg_incoming tn_dial  

        set param(dialPlan) true
        leg collectdigits leg_incoming param
    }
    
}

proc act_GotDest { } {
     global dest

    set status [infotag get evt_status]   
    if {  $status == "cd_004" } {
        set dest [infotag get evt_dcdigits]
        leg proceeding leg_incoming
        leg setup $dest callInfo leg_incoming
    } else {
        call close
    }
}
        
proc act_CallSetupDone { } {
    
    infotag set evt_feature_report media_inactivity
    infotag set media_timer_factor $timerFactor

    set status [infotag get evt_status]

    if { $status == "ls_000"} {

    } else {
        call close
    }
}

proc act_EvFeatureReceived { } {
   global timerFactor

   set featureType [infotag get evt_feature_type]

   if {  $featureType == "media_inactivity" } {
       log -s "media inactivity or silence is detected" 
   
       set inactivity_type [infotag get evt_feature_param media_inactivity_type]
       if {  $inactivity_type == "no media received" } {       
           log -s "media inactivity, RTCP packet was previously received"
       }
       if {  $inactivity_type == "no control info received" } {
           log -s "media inactivity, no RTCP packet was previously received "
       }

   } elseif { $featureType == "media_activity" } {
       log -s "media activity detected and call is back alive, VOIP RTP starts receiving 
RTP/RTCP packets"
       
   } else {
       log -s "other Events have been detected"
   }
}

proc act_Cleanup { } {
    
    call close
}

init

#----------------------------------
#   State Machine
#----------------------------------
  set fsm(any_state,ev_disconnected)         "act_Cleanup          same_state"
  set fsm(CALL_INIT,ev_setup_indication)     "act_Setup            GETDEST"
  set fsm(GETDEST,ev_collectdigits_done)     "act_GotDest          PLACECALL"

  set fsm(PLACECALL,ev_setup_done)           "act_CallSetupDone    CALLACTIVE"
  set fsm(CALLACTIVE,ev_feature)             "act_EvFeatureReceived same_state"
 
  set fsm(CALLACTIVE,ev_disconnected)        "act_Cleanup          CALLDISCONNECT"
  set fsm(CALLDISCONNECT,ev_disconnected)    "act_Cleanup          same_state"
  set fsm(CALLDISCONNECT,ev_disconnect_done) "act_Cleanup          same_state"
 
  fsm define fsm CALL_INIT

# End the application

Troubleshooting Cisco VoiceXML

Applications written in Voice eXtensible Markup Language (VoiceXML) provide access through a voice browser to content and services over the telephone, just as Hypertext Markup Language (HTML) provides access through a web browser running on a PC. The universal accessibility of the telephone and its ease of use makes VoiceXML applications a powerful alternative to HTML for accessing the information and services of the World Wide Web.

The Cisco IOS VoiceXML feature provides a platform for interpreting VoiceXML documents. When a telephone call is made to the Cisco VoiceXML-enabled gateway, VoiceXML documents are downloaded from web servers, providing content and services to the caller, typically in the form of pre-recorded audio in an IVR application. Customers can access online business applications over the telephone, providing for example, stock quotes, sports scores, or bank balances.

VoiceXML brings the advantages of web-based development and content delivery to voice applications. It is similar to HTML in its simplicity and in its presentation of information. The Cisco IOS VoiceXML feature is based on the W3C VoiceXML 2.0 Working Draft and is designed to provide web developers great flexibility and ease in implementing VoiceXML applications.

Figure 44 shows components that can be configured as a part of a VoiceXML application installed on a Cisco voice gateway:

Figure 44 Cisco IOS VoiceXML Application Components

For information on developing a VoiceXML document for implementing an application on the Cisco voice gateway, refer to the Cisco VoiceXML Programmer's Guide.

This section describes some of the troubleshooting techniques for the Cisco VoiceXML features.

Debugging Cisco VoiceXML Applications

Error Events

JavaScript or ECMA Script

Troubleshooting Speech Recognition and Synthesis

Troubleshooting ASR and TTS Server Functionality

For a list of the latest troubleshooting FAQs, go to the developer support website here:

http://www.cisco.com/cgi-bin/dev_support/access_level/products.cgi?product=VOICE_XML_GATEWAY

Debugging Cisco VoiceXML Applications

To debug Cisco VoiceXML applications at the gateway level, refer to the Cisco IOS TCL and VoiceXML Application Guide.

This section describes troubleshooting at the script level. To troubleshoot Cisco VoiceXML scripts, enable the debug vxml error and debug vxml puts commands on the gateway.The debug vxml error command displays all errors on the console, and the debug vxml puts command prints debugging statements used with the <log> element in the VoiceXML document.

<cisco-debug>

<cisco-debug> is used to debug only a specific application. To disable debugging messages for all VoiceXML applications except the specific VoiceXML application you wish to debug, use the <cisco-debug> element in the VoiceXML document in conjunction with the debug condition application voice command.

Refer to the Cisco IOS TCL and VoiceXML Application Guide for information on debug commands.


Note Before you use Cisco IOS debug commands to debug a specific application, add <cisco-debug> to the VoiceXML document for the application you want to debug, .


For example:

SUMMARY STEPS

1. Turn on global debug.

2. Add the <cisco-debug enabled = "true"/> and <cisco-debug enabled = "false"/> elements around the specific part of the VoiceXML document where you want to see debugging messages.

3. Add conditional debugging to the specific application.

DETAILED STEPS


Step 1 Turn on global debug for the areas you want to debug. For example:

debug vxml application
debug vxml trace 


Note If you do not proceed with step 2 and end your task with step 1, you see error messages for all the applications, irrespective of conditional debug being turned on or off.



Note The debug condition application voice command filters debugging output for only the debug vxml and debug http client commands. However, it does not filter output for the debug vxml error, debug vxml background, debug http client error, or debug http client background commands.


Step 2 Add the <cisco-debug enabled = "true"/> and <cisco-debug enabled = "false"/> elements around the specific part of the VoiceXML document where you want to see debugging messages. For example:

<?xml version="1.0"?>
                <vxml version="1.0" application="root.vxml">
                    <form>
                        <block>
                            <cisco-debug enabled = "true"/>
                            <prompt>
                                <audio src="welcome.au" caching="fast"/>
                            </prompt>
                            <cisco-debug enabled = "false"/>
                            <goto next="getExtension.vxml?"/>
                        </block>
                    </form>
                </vxml>

Step 3 Add conditional debugging to the specific application you want to debug. For example:

Three applications named myapp1, myapp2, and myapp3, all of which can be loaded by using the call application voice command are shown below:

call application voice myapp1 http://server1/vxml/test1.vxml
call application voice myapp2 http://server2/vxml/test2.vxml
call application voice myapp3 http://server3/vxml/test3.vxml

To debug only one of the applications, for example myapp1, use the debug condition application voice command to disable debug messages for the other applications, myapp2 and myapp3.

debug condition application voice myapp1 

Note Debugging for myapp1 is performed for only those debug areas that have been enabled in step 1 above. Debugging for the specific session must be enabled through the <cisco-debug> tag as shown in step 2 above.



Error Events

Enabling the debug vxml error command displays a list of possible error events on the console. For a list of error events, see the Events and Status Codes section.

Some of the possible errors generated with the debug vxml error command enabled are:

error.badfetch

Possible Causes
Suggested Actions

The VoiceXML interpreter throws this event when there is a failure in retrieving external components in the application. These external components can be VoiceXML documents, prerecorded files, or grammar files.

A badfetch error usually occurs when there is an error in fetching an external document.

Verify that the external documents, audio prompts, or grammar files are available at the specified location mentioned in the URL.

If the external components are stored on a HTTP server, enable the debug http client error command.

If the external components are stored on a RTSP server, search for error.badfetch.rtsp.xxx, where xxx is a RTSP response code. For values of RTSP response codes, refer to RFC 2326 available on the IETF website at http://www.ietf.org/.


error.semantic

Possible Causes
Suggested Actions

Logical errors such as referencing an undefined variable.

Verify that all variables referenced in the script are valid and defined.

Defining different grammar types in the same scope in the VoiceXML application.

Verify that only one grammar type is used at the time of recognizing user input.

Failure to define mandatory parameters in Cisco objects. For example, failure to define the account parameter in the authorize object results in a semantic error.

Verify that all mandatory parameters are defined in Cisco objects used in the script.


error.unsupported.format

Possible Causes
Suggested Actions

A resource format is not supported by the platform.

Verify that all formats used in the script are supported by the specific platforms being used.


JavaScript or ECMA Script

When the <script> element or ECMA expression is used in a VoiceXML document, enable the debug java command for debugging.

debug java ? 
apm2- JavaScript APM2 Utility Debugging
error- JavaScript Error Debugging
interpreter- JavaScript Interpreter Debugging

Troubleshooting Speech Recognition and Synthesis

Cisco IOS Release 12.2(11)T and later support automatic speech recognition (ASR) and text-to-speech (TTS) capabilities for VoiceXML and Tcl applications on Cisco voice gateways.

The Speech Recognition and Synthesis feature provides interfaces to ASR and TTS media servers by using Media Resource Control Protocol (MRCP), an application-level protocol developed by Cisco and its ASR and TTS media server partners, Nuance Communications and SpeechWorks International. Client devices that are processing audio or video streams use MRCP to control media resources on external media servers, such as speech synthesizers for TTS and speech recognizers for ASR. The Cisco gateway, running a voice application, and the media servers providing speech recognition and speech synthesis, maintain a client/server relationship through an RTSP connection; the gateway is the RTSP client and the RTSP server is the streaming media server providing speech recognition and speech synthesis.

While doing speech recognition, the gateway creates a separate G.711 u-law RTP stream to the media server, enabling the gateway to simultaneously perform speech synthesis or play audio files using a different codec.

If speech recognition or synthesis is not working, Table 54 lists some possible causes and the actions that you can take.

Table 54 Speech Recognition or Synthesis Fails

Possible Causes
Suggested Actions

Server is not configured either on the Cisco gateway or in the VoiceXML document.

Verify that the server location is configured by using at least one of these methods:

Globally on the gateway by using the ivr asr-server or ivr tts-server command. Refer to the Cisco IOS TCL and VoiceXML Application Guide.

With the com.cisco.asr-server or com.cisco.tts-server property in the VoiceXML document. Refer to the Cisco VoiceXML Programmer's Guide.

Gateway cannot access external ASR or TTS server or server is not running.

Ping the external server to make sure that the gateway has connectivity.

RTSP or MRCP errors are occurring between the gateway and the media server.

See the "Troubleshooting ASR and TTS Server Functionality" section.


Troubleshooting ASR and TTS Server Functionality

SUMMARY STEPS

1. debug vxml error and debug vxml event

2. debug mrcp error

3. debug rtsp error, debug rtsp session, and debug rtsp socket

DETAILED STEPS


Step 1 Use the debug vxml error and debug vxml event commands to verify that the external media server is reachable and its location is configured on the gateway or in the VoiceXML document. In the following example, the application failed because the media server is not configured on the gateway or in the VoiceXML document.:

Router# debug vxml error
Router# debug vxml event

*Jan  5 18:24:19.507: //62/36CA25A68036/VXML:/vxml_vapp_tts: 
tftp://demo/sample/banking.vxml at line 17: vapp_tts() fail with vapp error 1
**Jan  5 18:24:19.507: //62/36CA25A68036/VXML:/vxml_event_proc: 
*Jan  5 18:24:19.507:    <event>: event=error.badfetch status=0
*Jan  5 18:24:19.507: //62/36CA25A68036/VXML:/vxml_default_event_handler:  use default 
event handler
*Jan  5 18:24:19.507: //62/36CA25A68036/VAPP:/vapp_session_exit_event_name: Exit Event 
error.badfetch
*Jan  5 18:24:19.507: //62/36CA25A68036/VAPP:/vapp_session_exit_event_name: Exit Event 
error.badfetch
*Jan  5 18:24:19.507: //62/36CA25A68036/VAPP:/vapp_session_exit_event_name: Exit Event 
Name already set to error.badfetch
*Jan  5 18:24:19.507: //62/36CA25A68036/VXML:/vxml_vapp_terminate: vapp_status=0 ref_count 
0
*Jan  5 18:24:19.507: //62/36CA25A68036/VXML:/vxml_vapp_terminate: vxml session 
terminating with code=ERROR

     vapp status=VAPP_SUCCESS  vxml async status=VXML_ERROR_BAD_FETCH 

In the following example, the application failed because the media server is either unreachable or is not running.

*Jan  5 18:36:44.451: //83/ECD9B163804B/VXML:/vxml_media_done: : media play failed to 
setup with VAPP error=31, 
                 protocol_status_code=0
**Jan  5 18:36:44.451:   <event>: event=error.com.cisco.media.resource.unavailable 
status=0
*Jan  5 18:36:44.451: //83/ECD9B163804B/VXML:/vxml_default_event_handler:  use default 
event handler
*Jan  5 18:36:44.451: //83/ECD9B163804B/VAPP:/vapp_session_exit_event_name: Exit Event 
error.com.cisco.media.resource.unavailable
*Jan  5 18:36:44.451: //83/ECD9B163804B/VAPP:/vapp_session_exit_event_name: Exit Event 
error.com.cisco.media.resource.unavailable
*Jan  5 18:36:44.451: //83/ECD9B163804B/VAPP:/vapp_session_exit_event_name: Exit Event 
Name already set to error.com.cisco.media.resource.unavailable
*Jan  5 18:36:44.451: //83/ECD9B163804B/VXML:/vxml_vapp_terminate: vapp_status=0 ref_count 
0

Step 2 Use the debug mrcp error command to verify the connection between the gateway and the server. The following example shows the error when the RTSP connection to the server fails:

Router# debug mrcp error

*May  9 20:29:09.936:Connecting to 10.1.2.58:554 failed

The following error occurs when the response from the server is incorrect:

*May  9 20:29:09.936:Response from 10.1.2.58:554 failed
*May  9 20:29:09.936:MRCP/1.0 71 422 COMPLETE

The following error occurs when the recognize request comes out of sequence:

*May  9 20:29:09.936:act_idle_recognize:ignoring old recognize request

Step 3 Use the debug rtsp error, debug rtsp session, and debug rtsp socket commands to verify the RTSP connection with the media server, for example:

The following message displays if the RTSP connection fails:

*Sep 25 15:02:32.052: //-1//RTSP:/rtsplib_connect_to_svr: Socket Connect failed: 
172.19.140.31:554

The following message displays if the RTSP client receives an incorrect response from the server:

*Sep 25 15:03:35.062: //-1//RTSP:/rtsp_process_single_svr_resp: Parse Server Response 
failed, 172.19.140.31:554

The following message displays if the codec configured on the IP side is not G.711:

*Sep 25 15:05:15.765: //-1//RTSP:/rtsplib_rtp_associate_done: Association mismatch


MGCP Scripting Overview

MGCP scripting allows external call agents (CAs) to instruct the Cisco gateway to run a voice application on a PSTN or VoIP call leg. For example, you can request and collect the PIN and account number from a caller. These applications can be written in Tcl 2.0 or VoiceXML.

Figure 45 shows the MGCP CA controlling the application scripts.

Figure 45 MGCP Control of Voice Application Scripts

In the figure above, the RTSP server is configured to interact with gateways that have voice applications installed and running. The RADIUS server also interacts with the gateways to provide authentication, authorization, and accounting (AAA).

For instructions on how to configure your gateway for MGCP, refer to the MGCP and Related Protocols Configuration Guide.

Events and Status Codes

This section describes events received and status codes returned by Tcl IVR scripts. This chapter includes the following topics:

Events

Status Codes

Events

The following events can be received by the Tcl IVR script. Any events received that are not included below are ignored.

Event
Description

ev_address_resolved

List of endpoint addresses.

ev_alert

An intermediate event generated by the leg setup or leg setup_continue commands to set up a call. If specified in the callinfo parameter, notifyEvents, the script receives an ev_alert message once the destination endpoint is successfully alerted. The script running in the transferee gateway could then disconnect the leg towards the transferring endpoint.

If this event is an intercepted event, the application needs to use the leg setup_continue command to allow the system to continue with the setup.

ev_any_event

A special wildcard event that can be used in the state machine to represent any event that might be received by the script.

ev_authorize_done

Confirms the completion of the aaa authorize command. You can use the evt_status info-tag to determine the authorization status (whether it succeeded or failed).

ev_authenticate_done

Confirms the completion of the authentication command. You can use the evt_status info-tag to determine the authentication status (whether it succeeded or failed).

ev_call_timer0

Indicates that the call-level timer expired.

ev_collectdigits_done

Confirms the completion of the leg collectdigits command on the call leg. You can then use the evt_status info-tag to determine the status of the command completion. You can use the evt_dcdigits info-tag to retrieve the collected digits.

ev_connected

An intermediate event generated by the leg setup or leg setup_continue commands to set up a call.

If the callinfo paramater, notifyEvents, is specified, the script receives an ev_connected message when the system receives a connect event from the destination switch.

If this event is an intercepted event, the application needs to use the leg setup_continue command to allow the system to continue with the setup.

ev_consult_request

Indicates a call-transfer consultation-id request from an endpoint.

ev_consult_response

Indicates a response to the leg consult request command. For return codes, see Consult Status under Status Codes.

ev_consultation_done

Indicated the completion of a leg consult response command. For return codes, see Consult Response under Status Codes.

ev_create_done

Confirms the completion of the connection create command. You can use the evt_connection info-tag to determine the ID of the completed connection.

ev_destroy_done

Confirms the completion of the connection destroy command. You can use the evt_connection info-tag to determine the ID of the connection that was destroyed.

ev_digit_end

Indicates that a digit key is pressed and released. You can use the evt_digit info-tag to determine which digit was pressed. You can use the evt_digit_duration info-tag to determine how long (in seconds) the digit was pressed and to detect long pounds or long digits.

ev_disconnect_done

Indicates that the call leg has been cleared.

ev_disconnected

Indicates that one of the call legs needs to disconnect. On receiving this event, the script must issue a leg disconnect on that call leg. You can use the evt_legs info-tag to determine which call leg disconnected.

ev_disc_prog_ind

Indicates that a DISC/PI message is received at a call leg.

ev_facility

Indicates a response to a leg facility command.

ev_grab

Indicates that an application that called this script is requesting that the script return the call leg. The script receiving this event can clean up and return the leg with a handoff return command. Whether this is done is at the discretion of the script receiving the ev_grab event.

ev_hookflash

Indicates a hook flash (such as a quick onhook-offhook in the middle of a call), assuming that the underlying platform or interface supports hook flash detection.

ev_handoff

Indicates that the script received one or more call legs from another application. When the script receives this event, you can use the evt_legs and the evt_connections info-tags to obtain a list of the call legs and connection IDs that accompanied the ev_handoff event.

ev_leg_timer

Indicates that the leg timer expired. You can use the evt_legs info-tag to determine which leg timer expired.

ev_media_done

Indicates that the prompt playout either completed or failed. You can use the evt_status info-tag to determine the completion status.

ev_proceeding

An intermediate event generated by the leg setup or leg setup_continue commands to set up a call.

If the callinfo paramater, notifyEvents, is specified, the script receives an ev_proceeding message when the system receives a proceeding event from the remote end.

If this event is an intercepted event, the application needs to use the leg setup_continue command to allow the system to continue with the setup.

ev_progress

An intermediate event generated by the leg setup or leg setup_continue commands to set up a call.

If the callinfo paramater, notifyEvents, is specified, the script receives an ev_progress message when the system receives a progress event from the destination switch.

If this event is an intercepted event, the application needs to use the leg setup_continue command to allow the system to continue with the setup.

ev_returned

Indicates that a call leg that was sent to another application (using handoff callappl) has been returned. This event can be accompanied by one or more call legs that were created by the called application. When the script receives this event, you can use the evt_legs and the evt_connections info-tags to obtain a list of the call legs and connection IDs that accompanied the ev_returned event. You can use the evt_iscommand_done info-tag to verify that all of the call legs sent have been accounted for, meaning that the handoff callappl command is complete.

ev_setup_done

Indicates that the leg setup command has finished. You can then use the evt_status info-tag to determine the status of the command completion (whether the call was successfully set up or failed for some reason).

ev_setup_indication

Indicates that the system received a call. This event and the ev_handoff event are the events that initiate an execution instance of a script.

ev_transfer_request

Indicates a call transfer from an endpoint to the application.

ev_transfer_status

An intermediate event generated by the leg setup command. If specified in the callinfo parameter, notifyEvents, the script receives an ev_trasfer_status message. The ev_status information tag would then contain the status value of the call transfer.

ev_vxmldialog_done

Received when the VXML dialog completes. This could be because of a VXML dialog executing an <exit/> tag or interpretation completing the current document without a transition to another document. The dialog could also complete due to an interpretation failure or a document error. This completion status is also available through the evt_status info-tag.

ev_vxmldialog_event

Received by the Tcl IVR application when the VXML dialog initiated on a leg executes a sendevent object tag. The VXML subevent name is available through the evt_vxmlevent info-tag. All events thrown from the dialog markup are of the form vxml.dialog.*. All events generated by the system—perhaps as an indirect reaction to the VXML document executing a certain tag or throwing a certain event like the dialog completion event— are of the form vxml.session.*.


Status Codes

The evt_status info-tag returns a status code for the event received. This sections lists the possible status codes and their meaning.

Status codes are grouped according to function. The first two characters of the status code indicate the grouping.

au—Authentication status

ao—Authorization status

cd—Digit collection status

cr—Consult response

cs—Consult status

di— Disconnect cause

fa—Facility

ft—Feature type

ls—Leg setup status

ms—Media status

ts—Transfer status

vd—Voice dialog completion status

Authentication Status

Authentication status is reported in au_xxx format:

Value for xxx
Description

000

Authorization was successful.

001

Authorization error.

002

Authorization failed.


Authorization Status

Authorization status is reported in ao_xxx format:

Value for xxx
Description

000

Authorization was successful.

001

Authorization error.

002

Authorization failed.


Digit Collection Status

Digit collection status is reported in cd_xxx format:

Value for xxx
Description

001

The digit collection timed out, because no digits were pressed and not enough digits were collected for a match.

002

The digit collection was aborted, because the user pressed an abort key.

003

The digit collection failed, because the buffer overflowed and not enough digits were collected for a match.

004

The digit collection succeeded with a match to the dial plan.

005

The digit collection succeeded with a match to one of the patterns.

006

The digit collection failed because the number collected was invalid.

007

The digit collection was terminated because an ev_disconnected event was received on the call leg.

008

The digit collection was terminated because an ev_grab event was received on the call leg.

009

The digit collection successfully turned on digit reporting to the script.

010

The digit collection was terminated because of an unsupported or unknown feature or event.


Consult Response

Feature type is reported in cr_xxx format:

Value for xxx
Description

000

Success

001

Failed, invalid state

002

Failed, timeout

003

Failed, abandon

004

Failed, protocol error


Consult Status

Feature type is reported in cs_xxx format:

Value for xxx
Description

000

Consultation success, consult-id available

001

Consultation failed, request timeout

002

Consultation failed

003

Consultation failed, request rejected

004

Consultation failed, leg disconnected

005

Consultation failed, operation unsupported


Disconnect Cause

Disconnect causes use the format di_xxx where xxx is the Q931 cause code. Possible values are:

Value for xxx
Description

000

Uninitialized

001

Unassigned number

002

No route to the transit network

003

No route to the destination

004

Send information tone

005

Misdialed trunk prefix

006

Unacceptable channel

007

Call awarded

008

Preemption

009

Preemption reserved

016

Normal

017

Busy

018

No response from the user

019

No answer from the user

020

Subscriber is absent

021

Call rejected

022

Number has changed

026

Selected user is clearing

027

Destination is out of order

028

Invalid number

029

Facility rejected

030

Response to status inquiry

034

No circuit available

035

Requested VPCI VCI is not available

036

VPCI VCI assignment failure

037

Cell rate is not available

038

Network is out of order

039

Permanent frame mode is out of service

040

Permanent frame mode is operational

041

Temporary failure

042

Switch is congested

043

Access information has been discarded

044

No required circuit

045

No VPCI VCI is available

046

Precedence call blocked

047

No resource available

048

DSP error

049

QoS is not available

050

Facility is not subscribed

053

Outgoing calls barred

055

Incoming calls barred

057

Bearer capability is not authorized

058

Bearer capability is not available

062

Inconsistency in the information and class

063

Service or option not available

065

Bearer capability is not implemented

066

Change type is not implemented

069

Facility is not implemented

070

Restricted digital information only

079

Service is not implemented

081

Invalid call reference value

082

Channel does not exist

083

Call exists and call ID in use

084

Call ID in use

085

No call suspended

086

Call cleared

087

User is not in CUG

088

Incompatible destination

090

CUG does not exist

091

Invalid transit network

093

AAL parameters not supported

095

Invalid message

096

Mandatory information element (IE) is missing

097

Message type is not implemented

098

Message type is not compatible

099

IE is not implemented

100

Invalid IE contents

101

Message in incomplete call state

102

Recovery on timer expiration

103

Nonimplemented parameter was passed on

110

Unrecognized parameter message discarded

111

Protocol error

127

Internetworking error

128

Next node is unreachable

129

Holst Telephony Service Provider Module (HTSPM) is out of service

160

DTL transit is not my node ID


Facility

Leg setup requesting address resolution status is reported in fa_xxx format:

Value for xxx
Description

000

supplementary service request succeeded

003

supplementary service request unavailable

007

supplementary service was invoked in an invalid call state

009

supplementary service was invokes in a non-incoming call leg

010

supplementary service interaction is not allowed

050

MCID service is not subscribed

051

MCID request timed out

052

MCID is not configured for this interface


Feature Type

Feature type is reported in ft_xxx format:

Value for xxx
Description

001

Fax

002

Modem

003

Modem_phase

004

Hookflash

005

OnHook

006

OffHook


Leg Setup Status

Leg setup status is reported in ls_xxx format:

Value for xxx
Description

000

The call is active or was successful.

001

The outgoing call leg was looped.

002

The call setup timed out (meaning that the destination phone was alerting, but no one answered). The limit of this timeout can be specified in the leg setup command.

003

The call setup failed because of a lack of resources in the network.

004

The call setup failed because of an invalid number.

005

The call setup failed for reasons other than a lack of resources or an invalid number.

006

Unused; setup failure.

007

The destination was busy.

008

The incoming side of the call disconnected.

009

The outgoing side of the call disconnected.

010

The conferencing or connecting of the two call legs failed.

011

Supplementary services internal failure

012

Supplementary services failure

013

Supplementary services failure. Inbound call leg was disconnected.

014

The call was handed off to another application.

015

The call setup was terminated by an application request.

016

The outgoing called number was blocked.

026

Leg redirected

031

Transfer request acknowledge

032

Transfer target alerting (future SIP use)

033

Transfer target trying (future SIP use)

040

Transfer success

041

Transfer success with transfer-to party connected (SIP only)

042

Transfer success unacknowledged (SIP only)

050

Transfer fail

051

Transfer failed, bad request (SIP only)

052

Transfer failed, destination busy

053

Transfer failed, request cancelled

054

Transfer failed, internal error

055

Transfer failed, not implemented (SIP only)

056

Transfer failed, service unavailable or unsupported

057

Transfer failed, leg disconnected

058

Transfer failed, multiple choices (SIP only)

059

Transfer failed, timeout; no response to transfer request


Media Status

Media status is reported in ms_xyy format:

x indicates the command
yy indicates the status of the command
Value for x
Description
Value for yy
Description

0

Status for a media play command.

00

The command was successful and the prompt finished.1

1

Status for a media record command.

01

Failure

2

Status for a media stop command.

02

Unsupported feature or request

3

Status for a media pause command.

03

Invalid host or URL specified

4

Status for a media resume command.

04

Received disconnected

5

Status for a media seek command to forward.

05

The prompt was interrupted by a key press.

6

Status for a media seek command to rewind.

   

1 Valid for the media play command only, because media_done events are not received for successful completion of other media commands.


Transfer Status

Transfer status is reported in ts_xxx format:

Value for xxx
Description

000

Generic transfer success

001

Transfer success, transfer-to party is alerting

002

Transfer success, transfer-to party is answered

003

Transfer finished; however, the result of the transfer is not guaranteed

004

Transfer request is accepted

005

Transferee is trying to reach transfer-to party

006

Transfer request is rejected by transferee

007

Invalid transfer number

008

Transfer-to party unreachable

009

Transfer-to party is busy


VoiceXML Dialog Completion Status

VoiceXML dialog completion status is reported in vd_xxx format:

Value for xxx
Description

000

Normal completion because of the <exit> tag or execution reaching the end of the document.

001

Termination because of the default VXML event handling requiring VXML termination.

002

Terminated by the Tcl IVR application.

003

Internal failure.