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

Filtering Troubleshooting Output

Table Of Contents

Filtering Troubleshooting Output

Filtering Output from show and more Commands

Voice Call Debug Filtering on Cisco Voice Gateways

Restrictions for Voice Call Debug Filtering

Information About Voice Call Debug Filtering

Debug Commands that Support Voice Call Filtering

Generic Call Filter Module

Calling and Called Number Strings

Exact and Partial Matching

Media and Signaling Streams

Configuring the Voice Call Debug Filter

Configuring Call-Specific Conditions

Enabling Debug for the Set Filtering Conditions

Output Examples for Voice Call Debug Filtering

Exact Match Filtering: Example

Partial Match Filtering: Example

Voice Call Debug Filtering on H.323 Gatekeepers

Restrictions for Voice Call Debug Filtering on Voice Gatekeepers

Information About Voice Call Debug Filtering

Debug Commands that Support Voice Call Filtering on Cisco Voice Gatekeepers

Gatekeeper Filter Module

Calling and Called Number Strings

Exact and Partial Matching Conditions Rules and Information

Configuring the Voice Call Debug Filter for Cisco Gatekeepers

Configuring Call-Specific Conditions for Gatekeepers

Enabling Debug for the Set Filtering Conditions

Prerequisites

Troubleshooting Tips

Examples

SIP Debug Output Filtering Support

Restrictions for SIP Debug Output Filtering Support

Information About SIP Debug Output Filtering Support

Feature Design of SIP Debug Output Filtering Support

Generic Call Filtering Module

SIP Debug Commands that Support Output Filtering

Matching Conditions

Configuring SIP Debug Filtering

Configuring Call Filters

Enabling SIP Debug Output Filtering

Verifying SIP Debug Output Filtering Support

Configuration Examples for SIP Debug Filtering

Configuring Call Filters: Example

Enabling SIP Debug Output Filtering: Example

MGCP Call Centric Debug

Restrictions for MGCP Call Centric Debug

Information About MGCP Call Centric Debug

MGCP Debug Commands that Support Debug Filtering

Match Conditions for MGCP Debug Filtering

Trace Levels for MGCP Debug Output

Tips on Collecting Debug Output

How to Enable MGCP Call Centric Debug

Modifying the Debug Header Format for MGCP Debug Output

Creating Match Lists for MGCP Filtering Conditions

Enabling MGCP Debug Filtering Using Match Lists

Prerequisites

Restrictions

Verifying the MGCP Debug Filtering Configuration

Enabling MGCP Debug Trace Levels

Restrictions

Configuration Examples for MGCP Call Centric Debug

Match-List Configuration for MGCP Debug Filtering: Example

Enabling MGCP Debug Filtering: Example


Filtering Troubleshooting Output


Revised: October 31, 2005

This chapter describes how to filter troubleshooting output. The methods for filtering this output are as follows:

Filtering Output from show and more Commands.

Voice Call Debug Filtering on Cisco Voice Gateways

Voice Call Debug Filtering on H.323 Gatekeepers

SIP Debug Output Filtering Support

MGCP Call Centric Debug

Filtering Output from show and more Commands

In Cisco IOS Release 12.0(1)T and later releases, you can search and filter the output of show and more commands. This functionality is useful if you need to sort through large amounts of output or if you want to exclude output that you need not see.

To use this functionality, enter a show or more command followed by the vertical line character (|); one of the keywords begin, include, or exclude; and a regular expression on which you want to search or filter (the expression is case-sensitive):

command | [begin | include | exclude] regular-expression

The output matches certain lines of information in the configuration file. The following example illustrates how to use output modifiers with the show interface command when you want the output to include only lines in which the expression "protocol" appears:

Router# show interface | include protocol

FastEthernet0/0 is up, line protocol is up
Serial4/0 is up, line protocol is up
Serial4/1 is up, line protocol is up
Serial4/2 is administratively down, line protocol is down
Serial4/3 is administratively down, line protocol is down

For more information on the search and filter functions, see the "Using the Command-Line Interface" chapter in the Cisco IOS Configuration Fundamentals Configuration Guide, Release 12.3.

Voice Call Debug Filtering on Cisco Voice Gateways

Use voice call debug filtering to get selected debugging traces for voice calls. This feature allows you to filter and trace voice call debug messages based on selected filtering criteria, reducing the volume of output for more efficient troubleshooting.

This section contains the following information:

Restrictions for Voice Call Debug Filtering

Information About Voice Call Debug Filtering

Configuring the Voice Call Debug Filter

Output Examples for Voice Call Debug Filtering

Restrictions for Voice Call Debug Filtering

End-to-end filtering between gateways is not supported.

Filtering for CAS, IOS-AAA, IVR Version 1.0, media, and VoiceXML is not supported.

Matching conditions cannot be set for specific signaling protocols.

Matching conditions based on current DSP information are not supported.

Information About Voice Call Debug Filtering

Information from using debug commands for voice calls is crucial for troubleshooting, but the volume of raw data can be very large. In order to isolate the most valuable data, use the Voice Call Debug Filtering feature. This feature allows the debug output for the voice call to be filtered according to a variety of criteria, including:

Calling party number with prefix

Called party number with prefix

Carrier IDs

Dial peers

Local IP address

Remote IP address

Telephony interface or port

Trunk groups


Note Call filtering also works on IP-to-IP gateway connections using H.323.


The selected criteria are set on the gateway, and different sets of criteria can be stored.

To better understand the voice call debug filtering on Cisco voice gateways, see the following sections:

Debug Commands that Support Voice Call Filtering

Generic Call Filter Module

Calling and Called Number Strings

Exact and Partial Matching

Media and Signaling Streams

Debug Commands that Support Voice Call Filtering

When a call filter is applied, the filtering applies to all of the debugs affected by the call filter. Debug commands that support voice call debug filtering include the following:

debug cch323 h225

debug cch323 h245

debug cch323 preauth

debug cch323 session

debug ccsip all

debug ccsip calls

debug ccsip err

debug ccsip events

debug ccsip messages

debug ccsip preauth

debug ccsip states

debug mgcp all

debug mgcp endpoint

debug mgcp endptdb

debug mgcp errors

debug mgcp events

debug mgcp gcfm

debug mgcp inout

debug mgcp media

debug mgcp src

debug mgcp state

debug mgcp voipcac

debug voip aaa

debug voip ccapi error

debug voip ccapi inout

debug voip ipipgw

debug voip ivr all

debug voip ivr applib

debug voip ivr callsetup

debug voip ivr digitcollect

debug voip ivr dynamic

debug voip ivr error

debug voip ivr script

debug voip ivr settlement

debug voip ivr states

debug voip ivr tclcommands

debug voip rawmsg

debug vtsp all

debug vtsp dsp

debug vtsp error

debug vtsp event

debug vtsp port

debug vtsp rtp

debug vtsp send-nse

debug vtsp session

debug vtsp stats

debug vtsp vofr subframe

debug vtsp tone

debug vtsp vofr


Note See the Cisco IOS Debug Command Reference for detailed information about these debug commands.


Generic Call Filter Module

The debug commands described in the "Debug Commands that Support Voice Call Filtering" section support the following voice modules within the voice gateway:

CCAPI

Dial peers

H.323

ISDN

IVR (Version 2.0 only)

MGCP

SIP

SSAPP

TGRAM

Voice AAA

VTSP

The filtering for these modules is managed by the generic call filter module (GCFM). The filtering conditions are configured in the GCFM, and then the individual modules are informed when a call has to be filtered. The GCFM coordinates between multiple modules to handle filtering conditions.

All modules use the global unique identifier (GUID) to identify an individual call to GCFM. Each call is assigned a GUID and retains the same GUID throughout the entire network and over time. Gateway information and time stamp are embedded in the GUID. GUIDs identify an individual call among the multiple filtered-out calls so that the call can be isolated. For more information about GUIDs and the debug header, see the "Voice Debug Concepts" section on page 17.

Activity in the GCFM can be traced using the debug call filter detail and debug call filter inout commands. See the Cisco IOS Debug Command Reference for more information about these debug commands.

Calling and Called Number Strings

The string pattern for calling and called numbers can be either a complete telephone number or a partial telephone number with wildcard digits, represented by a period (.) character. Each "." represents a wildcard for an individual digit that the originating voice gateway expects to match. For example, if the calling and called number strings is defined as "555....", then any dialed string beginning with 555, plus at least four additional digits, matches this calling or called number.

Table 7 shows all of the wildcard symbols that are supported in the calling and called number strings.

Table 7 Symbols Used in Calling and Called Number Strings

Symbol
Description

.

Indicates a single-digit placeholder. For example, 555.... matches any dialed string beginning with 555, plus at least four additional digits.

[ ]

Indicates a range of digits. A consecutive range is indicated with a hyphen (-); for example, [5-7]. A nonconsecutive range is indicated with a comma (,); for example, [5,8]. Hyphens and commas can be used in combination; for example, [5-7,9].

Note Only single-digit ranges are supported. For example, [98-102] is invalid.

( )

Indicates a pattern; for example, 408(555). It is used in conjunction with the symbol ?, %, or +.

?

Indicates that the preceding digit occurred zero or one time. Enter ctrl-v before entering ? from your keyboard.

%

Indicates that the preceding digit occurred zero or more times. This functions the same as the "*" used in regular expression.

+

Indicates that the preceding digit occurred one or more times.

T

Indicates the interdigit timeout. The voice gateway pauses to collect additional dialed digits.



Note The period (.) is the only wildcard character that is supported for dial strings that are configured using the answer-address or incoming called-number command.


Table 8 shows some examples of how these wildcard symbols are applied to the calling and called number strings and the dial string that results when dial string 4085550199 is matched to the calling or called number. The wildcard symbols follow regular expression rules.

Table 8 Number Matching Examples Using Wildcard Symbols 

Destination Pattern
Dial String Translation
String After Stripping 1

408555.+

408555, followed by one or more wildcard digits. This pattern implies that the string must contain at least seven digits starting with 408555.

0199

408555.%

408555, followed by zero or more wildcard digits. This pattern implies that the string must contain at least 408555.

0199

408555+

40855, followed by 5 repeated one or more times.

0199

408555%

40855, followed by 5 repeated zero or more times. Any explicitly matching digit before the % symbol is not stripped off.

50199

408555?

40855, followed by 5 repeated zero or one time. Any explicitly matching digit before the ? symbol is not stripped off.

50199

40855[5-7].+

40855, followed by 5, 6, or 7, plus any digit repeated one or more times.

50199

40855[5-7].%

40855, followed by 5, 6, or 7, plus any digit repeated zero or more times.

50199

40855[5-7]+0199

40855, followed by 5, 6, or 7 repeated one or more times, followed by 0199.

50199

408(555)+0199

408, followed by 555, which may repeat one or more times, followed by 0199.

5550199

1 These examples apply only to one-stage dialing, where DID is enabled on the inbound POTS dial peer. If the voice gateway is using two-stage dialing and collecting digits one at a time as dialed, then the call is routed immediately after a dial peer is matched and any subsequent dialed digits are lost.


In addition to wildcard characters, the following symbols can be used in the calling and called number strings:

Asterisk (*) and pound sign (#)—These symbols on standard touchtone dial pads can be used anywhere in the pattern. They can be used as the leading character (for example, *650), except on the Cisco 3600 series.

Dollar sign ($)—Disables variable-length matching. It must be used at the end of the dial string.

Exact and Partial Matching

The conditions under each set of call filters are inclusive, so if multiple conditions are specified under a filter, they are all matched. To compare different conditions, create additional filters.

Matching conditions are as follows:

Exact match—All related debug output is filtered until all conditions in the match list are explicitly met. This is the best choice for most situations because the output is the most concise.

Partial match—No related debug output is filtered until there is a single explicit match failure. As long as zero or more conditions are met, debug output is not filtered. This choice is useful in debugging call startup problems like digit collection, but is not ideal for many situations because of the large amount of debug output that might be generated before matches explicitly fail.

Media and Signaling Streams

Media streams carry voice, video, fax, and data. Examples of media streams are G.711 or G.723 encoded voice streams or fax data. With the voice call debug filter, the media streams are traced for the voice gateway receiving the media stream. Some traces associated with media streams can be filtered, such as SPI-level traces associated with opening and closing the media channels. However, media RTP/RTCP packet-level traces are not filtered.

Signaling streams include both address signaling and supervisory signaling. Examples of signaling streams include H.323 and SIP protocol streams. With the voice call debug filter, the signaling streams are traced for the gateway or endpoint for the signaling stream.

Configuring the Voice Call Debug Filter

To configure the voice call debug filter, perform the following tasks:

Configuring Call-Specific Conditions (required)

Enabling Debug for the Set Filtering Conditions (required)

Configuring Call-Specific Conditions

Configure call-specific conditions to set the attributes that are filtered for voice calls.

SUMMARY STEPS

1. enable

2. configure terminal

3. call filter match-list number voice

4. incoming calling-number string

5. incoming called-number string

6. incoming secondary-called-number string

7. incoming port string

8. incoming signaling {local | remote} ipv4 ip_address

9. incoming media {local | remote} ipv4 ip_address

10. incoming dialpeer tag

11. source carrier-id string

12. source trunk-group-label group-number

13. outgoing calling-number string

14. outgoing called-number string

15. outgoing secondary-called-number string

16. outgoing port string

17. outgoing signaling {local | remote} ipv4 ip_address

18. outgoing media {local | remote} ipv4 ip_address

19. outgoing dialpeer tag

20. target carrier-id string

21. target trunk-group-label group-number

22. end

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

call filter match-list number voice

Example:

Router(config)# call filter match-list 1 voice

Enters call filter match list configuration mode to define the filter conditions.

number—Numeric label that uniquely identifies the match list. Range is 1 to 16.

Note At least one of the following optional parameters (Step 4 to Step 21) for call filtering must be configured.

Step 4 

incoming calling-number string

Example:

Router(conf-call-filter-mlist)# incoming calling-number 408555

(Optional) Specifies the incoming calling number to be filtered.

string—Numeric string that identifies all or part of the incoming calling number.

Step 5 

incoming called-number string

Example:

Router(conf-call-filter-mlist)# incoming called-number 408555

(Optional) Specifies the incoming called number to be filtered.

string—Numeric string that identifies all or part of the incoming called number.

Step 6 

incoming secondary-called-number string

Example:

Router(conf-call-filter-mlist)# incoming secondary-called-number 408555

(Optional) Specifies the incoming secondary called number to be filtered.

The secondary called number is the number from the second stage in a two-stage scenario.

string—Numeric string that identifies all or part of the incoming secondary called number.

Step 7 

incoming port string

Example:

Router(conf-call-filter-mlist)# incoming port 1/0/0

(Optional) Specifies the incoming port to be filtered.

The telephony interfaces are defined for calls from the PSTN. The string value varies depending on the voice gateway.

string—Identifies the incoming port number. This value is platform-specific and varies between platforms.

Step 8 

incoming signaling {local | remote} ipv4 ip-address

Example:
Router(conf-call-filter-mlist)# incoming 
signaling local ipv4 192.168.10.255

(Optional) Specifies the incoming signaling IPv4 address.

local—Local voice gateway

remote—Remote IP device

ip-address—IP address of the local voice gateway.

Step 9 

incoming media {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# incoming media local ipv4 192.168.10.255

(Optional) Specifies the incoming media IPv4 address.

local—Local voice gateway

remote—Remote IP device

ip-address—IP address of the local voice gateway.

Step 10 

incoming dialpeer tag

Example:

Router(conf-call-filter-mlist)# incoming dialpeer 14

(Optional) Specifies the incoming dial peer to be filtered.

tag—Digits that define a specific dial peer. Valid entries are 1 to 2147483647.

Step 11 

source carrier-id string

Example:

Router(conf-call-filter-mlist)# source carrier-id 4321

(Optional) Specifies the source carrier ID to be filtered.

string—Alphanumeric identifier for the carrier ID.

Step 12 

source trunk-group-label group-number

Example:

Router(conf-call-filter-mlist)# source trunk-group-label 20

(Optional) Specifies the source trunk group to be filtered.

group-number—A value from 0 to 23 that identifies the trunk group.

Step 13 

outgoing calling-number string

Example:

Router(conf-call-filter-mlist)# outgoing calling-number 408525

(Optional) Specifies the outgoing calling number to be filtered.

This number goes out after number translation and expansion are complete.

string—Numeric string that identifies all or part of the outgoing calling number.

Step 14 

outgoing called-number string

Example:

Router(conf-call-filter-mlist)# outgoing called-number 408525

(Optional) Specifies the outgoing called number to be filtered.

This number goes out after number translation and expansion are complete.

string—Numeric string that identifies all or part of the outgoing called number.

Step 15 

outgoing secondary-called-number string

Example:
Router(conf-call-filter-mlist)# outgoing 
secondary-called-number 408525

(Optional) Specifies the outgoing secondary called number to be filtered.

The secondary called number is the number from the second stage in a two-stage scenario.

string—Numeric string that identifies all or part of the outgoing secondary called number.

Step 16 

outgoing port string

Example:

Router(conf-call-filter-mlist)# outgoing port 1/0/0

(Optional) Specifies the outgoing port to be filtered.

The telephony interfaces are defined for calls from PSTN. The string value varies, depending on different voice gateways.

string—Identifies the outgoing port number. This value is voice gateway-specific and varies between voice gateways.

Step 17 

outgoing signaling {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# outgoing signaling local ipv4 192.168.10.255

(Optional) Specifies the outgoing signaling IPv4 address for the gatekeeper managing the signaling.

local—Local voice gateway

remote—Remote IP device

ip-address—IP address of the local voice gateway.

Step 18 

outgoing media {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# outgoing media local ipv4 192.168.10.255

(Optional) Specifies the outgoing media IPv4 address for the voice gateway receiving the media stream.

local—Local voice gateway

remote—Remote IP device

ip-address—IP address of the local voice gateway.

Step 19 

outgoing dialpeer tag

Example:

Router(conf-call-filter-mlist)# outgoing dialpeer 14

(Optional) Specifies the outgoing dial peer to be filtered.

tag—Digits that define a specific dial peer. Valid entries are 1 to 2147483647.

Step 20 

target carrier-id string

Example:

Router(conf-call-filter-mlist)# target carrier-id 4321

(Optional) Specifies the target carrier ID to be filtered.

string—Alphanumeric identifier for the carrier ID.

Step 21 

target trunk-group-label group-number

Example:

Router(conf-call-filter-mlist)# target trunk-group-label 20

(Optional) Specifies the target trunk group to be filtered.

group-number—A value from 0 to 23 that identifies the trunk group.

Step 22 

end

Example:

Router(conf-call-filter-mlist)# end

Exits to privileged EXEC mode.

Troubleshooting Tips

To verify the conditions that you have set, use the show call filter match-list command. This command displays the criteria set for the specified match list.

What to Do Next

After the conditions are set for the voice call debug, debug commands can be enabled. Proceed to the "Enabling Debug for the Set Filtering Conditions" section.

Enabling Debug for the Set Filtering Conditions

Use the debug command to enable the set conditions to get the filtered output.

Prerequisites

The conditions for the voice call debug filter must be set as described in the "Configuring Call-Specific Conditions" section.

SUMMARY STEPS

1. enable

2. debug condition match-list tag {exact-match | partial-match}

3. debug cch323 {capacity | h225 | h245 | preauth | ras | rawmsg | session}

or

debug ccsip {all | calls | err | events | messages | preauth | states}

or

debug isdn q931

or

debug voip aaa

or

debug voip ccapi {error | inout}

or

debug voip ipipgw

or

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

or

debug voip rawmsg

or

debug vtsp {all | dsp | error | event | port | rtp | send-nse | session | stats | vofr subframe | tone | vofr}

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

debug condition match-list tag {exact-match | partial-match}

Example:

Router# debug condition match-list 1 exact-match

Enables the filter match list for the set conditions.

tag—Numeric label that uniquely identifies the match list. Range is 1 to 16. The number for the match list is set using the call filter match-list command.

exact-match—All related debug output is filtered until all conditions in the match list are explicitly met. This is the best choice for most situations because the output is the most concise.

partial- match—No related debug output is filtered until there is a single explicit match failure. As long as zero or more conditions are met, debug output is not filtered. This choice is useful in debugging call startup problems like digit collection, but is not ideal for many situations because a large amount of debug output is generated before matches explicitly fail.

Step 3 

debug cch323 {capacity | h225 | h245 | preauth | ras | rawmsg | session}

or

debug ccsip {all | calls | err | events | messages | preauth | states}

or

debug isdn q931

or

debug voip aaa

or

debug voip ccapi {error | inout}

or

debug voip ipipgw

or

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

or

debug voip rawmsg

or

debug vtsp {all | dsp | error | event | port | rtp | send-nse | session | stats | vofr subframe | tone | vofr}

Example:

Router# debug cch323 h225

Router# debug ccsip events

Router# debug isdn q931

Router# debug voip aaa

Router# debug voip ccapi inout

Router# debug voip ipipgw

Router# debug voip ivr all

Router# debug voip rawmsg

Router# debug vtsp dsp

Enables the appropriate voice call debug commands.

See the Cisco IOS Debug Command Reference for detailed descriptions of these debug commands.

The debug output commences at this point.

Troubleshooting Tips

To verify debug conditions, use the following commands:

show debug

This command displays the debugs that are enabled.

show call filter components

This command displays the components that register internally with the filtering module. This command shows which components are registered with the GCFM, which is the internal module that controls which components are filtered.

show call filter match-list

This command displays the criteria set for the specified match list. It shows a list of all the match lists, shows which ones are enabled, and shows whether they are enabled for partial or exact matching.

Output Examples for Voice Call Debug Filtering

This section provides configuration examples to match the identified configuration tasks in the previous section:

Exact Match Filtering: Example

Partial Match Filtering: Example

Exact Match Filtering: Example

When the exact match condition is used for voice call debug filtering, all related debug output is filtered until all conditions in the match list are explicitly met. In the following example, the configuration, enabled debugs, and debug output for a Cisco AS5400 universal gateway are shown.

Dial-Peer Configuration for Exact Match Filtering

dial-peer voice 501 pots
 preference 1
 incoming called-number 50200
 destination-pattern 50201
 direct-inward-dial
 port 6/0:D
 prefix 50201
!
dial-peer voice 502 voip
 preference 1
 incoming called-number 50201
 destination-pattern 50200
 session target ipv4:172.16.101.21
 dtmf-relay h245-alphanumeric
 fax-relay ecm disable
 fax rate disable
!

Debug Output for Exact Match Filtering

Router# show debug

The following ISDN debugs are enabled on all DSLs:

debug isdn error is             ON.
debug isdn q931 is              ON.   (filter is ON)
Voice Telephony session debugging is on (filter is ON)
Voice Telephony dsp debugging is on (filter is ON)
Voice Telephony error debugging is on (filter is ON)
voip ccAPI function enter/exit debugging is on (filter is ON)

In the following output, the show call filter match-list command is used to show which conditions have been set for the specified call filter:

Router# show call filter match-list 
 
********************************************* 
call filter match-list 9 voice 
*********************************************
  incoming calling-number 50200
  incoming called-number 50201
  incoming signal local ipv4 172.16.101.22
  incoming signal remote ipv4  172.16.101.21
  incoming media local ipv4  172.16.101.22
  incoming media remote ipv4  172.16.101.21
  incoming dialpeer 502
  outgoing calling-number 50200
  outgoing called-number 50201
  outgoing port 6/0:D
  outgoing dialpeer 501
 debug condition match-list is set to EXACT_MATCH 
********************************************* 
call filter match-list 10 voice 
*********************************************
  incoming calling-number 50300
  incoming called-number 50301
  incoming signal local ipv4 172.16.101.22
  incoming signal remote ipv4  172.16.101.21
  incoming media local ipv4  172.16.101.22
  incoming media remote ipv4  172.16.101.21
  incoming dialpeer 504
  outgoing calling-number 50300
  outgoing called-number 50301
  outgoing port 6/1:D
  outgoing dialpeer 503
 debug condition match-list is set to EXACT_MATCH 

The following debug output contains the exact match for the configured conditions. Some of the matching conditions are highlighted in bold text.

Feb  6 11:13:30.799: digit_strip:1, pcn:50201, poa:50201
Feb  6 11:13:30.799: pcn:, poa:
Feb  6 11:13:30.799: Final pcn:, poa:, dial_string:50201
Feb  6 11:13:30.803: 
//6/CFD853DE8004/VTSP:(6/0:D):-1:0:0/vtsp_gcfm_percall_status_callback: found cdb and 
update
Feb  6 11:13:30.803: 
//6/CFD853DE8004/VTSP:(6/0:D):-1:0:0/vtsp_update_dsm_stream_mgr_filter_flag: update 
dsp_stream_mgr_t  debug flag
Feb  6 11:13:30.803: //5/CFD853DE8004/CCAPI/ccapi_gcfm_percall_status_callback: found 
callEntry and update
Feb  6 11:13:30.803: //6/CFD853DE8004/CCAPI/ccapi_gcfm_percall_status_callback: found 
callEntry and update
Feb  6 11:13:30.803: //5/CFD853DE8004/SSAPP:502:-1/ssaTraceSct: 
cid(5)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_REPORT_DIGITS_DONE)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(1)
Feb  6 11:13:30.803: //5/CFD853DE8004/SSAPP:502:-1/ssaTraceSct: 
-cid2(6)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_MAPPING)
Feb  6 11:13:30.803: //5/CFD853DE8004/SSAPP:502:-1/ssaDebugPeers: ssaReportDigitsDone 
cid(5) peer list: tag(2501) called number (50201) 
Feb  6 11:13:30.803: //5/CFD853DE8004/SSAPP:502:-1/ssaReportDigitsDone: callid=5 Reporting 
disabled.
Feb  6 11:13:31.007: ISDN Se6/0:23 Q931: callid 0x800B, callref 0x0003, 
                guid CFD853DE8004
Feb  6 11:13:31.007: ISDN Se6/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x8003 
        Channel ID i = 0xA98397 
                Exclusive, Channel 23
Feb  6 11:13:31.007: ISDN Se6/0:23 Q931: callid 0x800B, callref 0x0003, 
                guid CFD853DE8004
Feb  6 11:13:31.007: ISDN Se6/0:23 Q931: RX <- ALERTING pd = 8  callref = 0x8003
Feb  6 11:13:31.011: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/vtsp_process_event: vtsp:[6/0:D 
(6), S_SETUP_REQUEST, E_TSP_PROCEEDING]
Feb  6 11:13:31.011: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/act_setup_pend_proceeding: .
Feb  6 11:13:31.011: 
//6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/dsp_stream_mgr_reinit_platform_info: .
Feb  6 11:13:31.011: //6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/dsm_open_voice_and_set_params: 
.
Feb  6 11:13:31.011: //6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/set_playout_dmgr: playout 
default 

Feb  6 11:13:31.011: 
//6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/dsm_dsp_echo_canceller_control: echo_cancel: 1
Feb  6 11:13:31.011: ISDN Se6/0:23 Q931: callid 0x800B, callref 0x0003, 
                guid CFD853DE8004
Feb  6 11:13:31.011: ISDN Se6/0:23 Q931: RX <- CONNECT pd = 8  callref = 0x8003
Feb  6 11:13:31.011: //6/CFD853DE8004/SSAPP:0:-1/ssaTraceSct: 
cid(6)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_PROCEEDING)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(0)fDest(0)
Feb  6 11:13:31.011: //6/CFD853DE8004/SSAPP:0:-1/ssaTraceSct: 
-cid2(5)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)
Feb  6 11:13:31.011: //6/CFD853DE8004/SSAPP:0:-1/ssaCallProc: 
Feb  6 11:13:31.011: //6/CFD853DE8004/SSAPP:0:-1/ssaIgnore: cid(6), 
st(SSA_CS_CALL_SETTING),oldst(1), ev(21)
Feb  6 11:13:31.011: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/vtsp_process_event: vtsp:[6/0:D 
(6), S_SETUP_REQ_PROC, E_TSP_ALERT]
Feb  6 11:13:31.011: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/act_setup_pend_alert: .
Feb  6 11:13:31.011: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/vtsp_ring_noan_timer_start: 
371381
Feb  6 11:13:31.015: ISDN Se6/0:23 Q931: callid 0x800B, callref 0x0003, 
                guid CFD853DE8004
Feb  6 11:13:31.015: ISDN Se6/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x0003
Feb  6 11:13:31.015: //6/CFD853DE8004/SSAPP:0:-1/ssaTraceSct: 
cid(6)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_ALERT)
oldst(SSA_CS_CALL_SETTING)cfid(-1)csize(0)in(0)fDest(0)
Feb  6 11:13:31.015: //6/CFD853DE8004/SSAPP:0:-1/ssaTraceSct: 
-cid2(5)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)
Feb  6 11:13:31.015: //5/CFD853DE8004/SSAPP:502:-1/ssaAlert: 
Feb  6 11:13:31.015: //6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/dsm_exec: [Feat SM: S:NONE B 
SM: S:S_DSM_INIT E:E_DSM_CC_BRIDGE]
Feb  6 11:13:31.015: //6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/dsm_act_bridge: .
Feb  6 11:13:31.015: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/vtsp_dsm_bridge_status_cb: .
Feb  6 11:13:31.015: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/vtsp_dsm_set_fax_feat_param:  
Fax relay is ENABLED,  Primary Fax protocol is T38_FAX_RELAY, Fallback Fax protocol is 
CISCO_FAX_RELAY
Feb  6 11:13:31.015: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/vtsp_dsm_peer_event_cb: 
E_DSM_CC_CAPS_IND
Feb  6 11:13:31.015: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/vtsp_process_event: vtsp:[6/0:D 
(6), S_SETUP_REQ_PROC, E_TSP_CONNECT]
Feb  6 11:13:31.015: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/act_setup_pend_connect: .
Feb  6 11:13:31.015: //6/CFD853DE8004/VTSP:(6/0:D):22:0:0/vtsp_ring_noan_timer_stop: 
371382
Feb  6 11:13:31.015: //6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/dsp_stream_mgr_play_tone: .
Feb  6 11:13:31.015: //6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/dsm_exec: [Feat SM: S:NONE B 
SM: S:S_DSM_BRIDGING E:E_DSM_CC_GEN_TONE]
Feb  6 11:13:31.015: //6/CFD853DE8004/DSM:(6/0:D):-1:0:4098/dsm_act_gen_tone: Tone is not 
on, ignoring
Feb  6 11:13:31.015: //6/CFD853DE8004/CCAPI/cc_api_call_connected: setting 
callEntry->connected to TRUE

Partial Match Filtering: Example

When the partial match condition is used for voice call debug filtering, no related debug output is filtered until there is a single explicit match failure. In the following example, the configuration, enabled debugs, and debug output for a Cisco 3745 modular access router are shown. Because partial match is set, the router displays the ISDN debug messages on all calls and displays only the debug vtsp event messages on the specified dial peer, dial peer 1.

Debug Output for Partial Match Filtering

Router# show debug

The following ISDN debugs are enabled on all DSLs:

debug isdn error is             ON.
debug isdn q931 is              ON.   (filter is ON)
Voice Telephony event debugging is on (filter is ON)

In the following output, the show call filter match-list command is used to show which conditions are set for the specified call filter:

Router# show call filter match-list 4
  incoming calling-number 10..
  incoming called-number 50..
  incoming dialpeer 1
 debug condition match-list is set to PARTIAL_MATCH

The following debug output shows ISDN debug messages on all calls, but displays only the debug vtsp event messages on dial peer 1. The VTSP messages are highlighted with bold text.

*Mar  3 16:21:52.024: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01E6, 
                guid 06ED7A20-170A-11CC-81E7-000B465B86B0
*Mar  3 16:21:52.024: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01E6 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808381 
                Exclusive, Interface 0, Channel 1 
        Calling Party Number i = 0x00, 0x80, '1000' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5000' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:21:52.028: 
//1270/06ED7A20-170A-11CC-81E7-000B465B86B0/VTSP:(2/0:23):0:0:0/vtsp_process_event: 
[state:S_SETUP_INDICATED,  event: E_CC_PROCEEDING]
*Mar  3 16:21:52.032: ISDN Se2/0:23 Q931: callid 0x01EA, callref 0x01E6, 
                guid 06ED7A20-170A-11CC-81E7-000B465B86B0
*Mar  3 16:21:52.036: ISDN Se2/0:23 Q931: TX -> CALL_PROC pd = 8  callref = 0x81E6 
        Channel ID i = 0xA98381 
                Exclusive, Channel 1
*Mar  3 16:21:52.080: 
//1270/06ED7A20-170A-11CC-81E7-000B465B86B0/VTSP:(2/0:23):0:0:0/vtsp_process_event: 
[state:S_PROCEEDING,  event: E_CC_ALERT]
*Mar  3 16:21:52.084: ISDN Se2/0:23 Q931: callid 0x01EA, callref 0x01E6, 
                guid 06ED7A20-170A-11CC-81E7-000B465B86B0
*Mar  3 16:21:52.084: ISDN Se2/0:23 Q931: TX -> ALERTING pd = 8  callref = 0x81E6 
        Progress Ind i = 0x8088 - In-band info or appropriate now available 
*Mar  3 16:21:52.084: 
//1270/06ED7A20-170A-11CC-81E7-000B465B86B0/VTSP:(2/0:23):0:0:0/vtsp_process_event: 
[state:S_ALERTING,  event: E_CC_CONNECT]
*Mar  3 16:21:52.088: ISDN Se2/0:23 Q931: callid 0x01EA, callref 0x01E6, 
                guid 06ED7A20-170A-11CC-81E7-000B465B86B0
*Mar  3 16:21:52.088: ISDN Se2/0:23 Q931: TX -> CONNECT pd = 8  callref = 0x81E6
*Mar  3 16:21:52.392: ISDN Se2/0:23 Q931: callid 0x01EA, callref 0x01E6, 
                guid 06ED7A20-170A-11CC-81E7-000B465B86B0
*Mar  3 16:21:52.392: ISDN Se2/0:23 Q931: RX <- CONNECT_ACK pd = 8  callref = 0x01E6
*Mar  3 16:21:57.024: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01E7, 
                guid 09E86AA0-170A-11CC-81E8-000B465B86B0
*Mar  3 16:21:57.024: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01E7 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808382 
                Exclusive, Interface 0, Channel 2 
        Calling Party Number i = 0x00, 0x80, '1001' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5001' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:02.032: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01E8, 
                guid 0CE49409-170A-11CC-81E9-000B465B86B0
*Mar  3 16:22:02.032: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01E8 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808383 
                Exclusive, Interface 0, Channel 3 
        Calling Party Number i = 0x00, 0x80, '1002' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5002' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:07.032: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01E9, 
                guid 0FDF8489-170A-11CC-81EA-000B465B86B0
*Mar  3 16:22:07.032: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01E9 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808384 
                Exclusive, Interface 0, Channel 4 
        Calling Party Number i = 0x00, 0x80, '1003' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5003' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:12.032: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01EA, 
                guid 12DA7509-170A-11CC-81EB-000B465B86B0
*Mar  3 16:22:12.032: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01EA 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808385 
                Exclusive, Interface 0, Channel 5 
        Calling Party Number i = 0x00, 0x80, '1004' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5004' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:17.036: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01EB, 
                guid 15D601B1-170A-11CC-81EC-000B465B86B0
*Mar  3 16:22:17.036: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01EB 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808386 
                Exclusive, Interface 0, Channel 6 
        Calling Party Number i = 0x00, 0x80, '1005' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5005' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:22.040: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01EC, 
                guid 18D18E59-170A-11CC-81ED-000B465B86B0
*Mar  3 16:22:22.040: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01EC 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808387 
                Exclusive, Interface 0, Channel 7 
        Calling Party Number i = 0x00, 0x80, '1006' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5006' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:27.040: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01ED, 
                guid 1BCC7ED9-170A-11CC-81EE-000B465B86B0
*Mar  3 16:22:27.040: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01ED 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808388 
                Exclusive, Interface 0, Channel 8 
        Calling Party Number i = 0x00, 0x80, '1007' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5007' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:32.048: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01EE, 
                guid 1EC8A7A9-170A-11CC-81EF-000B465B86B0
*Mar  3 16:22:32.048: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01EE 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808382 
                Exclusive, Interface 0, Channel 2 
        Calling Party Number i = 0x00, 0x80, '1008' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5008' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:34.688: ISDN Se2/0:23 Q931: callid 0x01EA, callref 0x01E6, 
                guid 06ED7A20-170A-11CC-81E7-000B465B86B0
*Mar  3 16:22:34.688: ISDN Se2/0:23 Q931: RX <- DISCONNECT pd = 8  callref = 0x01E6 
        Cause i = 0x8290 - Normal call clearing
*Mar  3 16:22:34.688: ISDN Se2/0:23 Q931: callid 0x01EA, callref 0x01E6, 
                guid 06ED7A20-170A-11CC-81E7-000B465B86B0
*Mar  3 16:22:34.688: ISDN Se2/0:23 Q931: TX -> RELEASE pd = 8  callref = 0x81E6
*Mar  3 16:22:34.688: 
//1270/06ED7A20-170A-11CC-81E7-000B465B86B0/VTSP:(2/0:23):0:0:0/vtsp_process_event: 
[state:S_CONNECT,  event: E_TSP_DISCONNECT_IND]
*Mar  3 16:22:34.688: 
//1270/06ED7A20-170A-11CC-81E7-000B465B86B0/VTSP:(2/0:23):0:0:0/vtsp_process_event: 
[state:S_CONNECT,  event: E_CC_DISCONNECT]
*Mar  3 16:22:34.692: 
//1270/06ED7A20-170A-11CC-81E7-000B465B86B0/VTSP:(2/0:23):0:0:0/vtsp_process_event: 
[state:S_WAIT_STATS,  event: E_VTSP_DSM_STATS_COMPLETE]
*Mar  3 16:22:34.692: 
//1270/06ED7A20-170A-11CC-81E7-000B465B86B0/VTSP:(2/0:23):0:0:0/vtsp_process_event: 
[state:S_WAIT_RELEASE,  event: E_TSP_DISCONNECT_CONF]
*Mar  3 16:22:34.692: 
//1270/06ED7A20-170A-11CC-81E7-000B465B86B0/VTSP:(2/0:23):0:0:0/vtsp_process_event: 
[state:S_CLOSE_DSPRM,  event: E_VTSP_DSM_CLOSE_COMPLETE]
*Mar  3 16:22:34.812: ISDN Se2/0:23 Q931: callid 0x01EA, callref 0x01E6, 
                guid 06ED7A20-170A-11CC-81E7-000B465B86B0
*Mar  3 16:22:34.812: ISDN Se2/0:23 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x01E6
*Mar  3 16:22:37.048: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01EF, 
                guid 21C39829-170A-11CC-81F0-000B465B86B0
*Mar  3 16:22:37.048: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01EF 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808381 
                Exclusive, Interface 0, Channel 1 
        Calling Party Number i = 0x00, 0x80, '1009' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5009' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:42.052: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01F0, 
                guid 24BF24D1-170A-11CC-81F1-000B465B86B0
*Mar  3 16:22:42.052: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01F0 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808383 
                Exclusive, Interface 0, Channel 3 
        Calling Party Number i = 0x00, 0x80, '1010' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5010' 
                Plan:Unknown, Type:Unknown
*Mar  3 16:22:47.056: ISDN Se2/0:23 Q931: callid 0x0000, callref 0x01F1, 
                guid 27BAB179-170A-11CC-81F2-000B465B86B0
*Mar  3 16:22:47.056: ISDN Se2/0:23 Q931: RX <- SETUP pd = 8  callref = 0x01F1 
        Bearer Capability i = 0x8090A2 
                Standard = CCITT 
                Transer Capability = Speech  
                Transfer Mode = Circuit 
                Transfer Rate = 64 kbit/s 
        Channel ID i = 0xE9808384 
                Exclusive, Interface 0, Channel 4 
        Calling Party Number i = 0x00, 0x80, '1011' 
                Plan:Unknown, Type:Unknown 
        Called Party Number i = 0x80, '5011' 
                Plan:Unknown, Type:Unknown

Voice Call Debug Filtering on H.323 Gatekeepers

Use voice call debug filtering on Cisco voice gatekeepers to get selected debugging traces for voice calls. This feature allows you to filter and trace voice call debug messages based on selected filtering criteria, reducing the volume of output for more efficient troubleshooting.

This section describes the capability added in Cisco IOS Release 12.4(4)T to filter troubleshooting output on H.323 gatekeepers and contains the following sections:

Restrictions for Voice Call Debug Filtering on Voice Gatekeepers

Information About Voice Call Debug Filtering

Configuring the Voice Call Debug Filter for Cisco Gatekeepers

Examples

Restrictions for Voice Call Debug Filtering on Voice Gatekeepers

The following restrictions apply to the Cisco voice gatekeepers:

Voice call debug filtering on gatekeepers is available only if you have a Cisco IOS image that contains the gatekeeper functionality or joint functionality (for both gateways and gatekeepers).

Filtering of debugs in the gatekeeper DNS process is not supported.

Filtering of ASN and GUP messages is not supported.

The following are not supported by call filtering:

If debug messages are printed in non-ARQ path, the path will not support call filtering.

H.323V1, H323 proxy, and DGK are not supported.

Calls transferred from primary gatekeeper to the secondary gatekeeper will not be filtered in the secondary gatekeeper, but new calls in secondary gatekeeper will apply filtering.

All error, incorrect, and delayed GKTMP messages are not printed in call filtering because the gatekeeper ignores the message at a lower level and the messages are not printed.

GKTMP messages that are not related to calls are not supported by call filtering (registration, unregistration, and resource messages).

Information About Voice Call Debug Filtering

Information from using debug commands for voice calls is crucial for troubleshooting, but the volume of raw data can be very large. In order to isolate the most valuable data, you can use the Voice Call Debug Filtering feature on gatekeepers. Debug output for the voice gatekeepers can be filtered according to the following criteria:

Incoming called number

Incoming calling number

Gatekeeper resolved final destination endpoint (IPv4) address


Note In addition to working on voice gatekeepers, call filtering works on IP-to-IP gateway connections using H.323.


The selected criteria are set on the gatekeeper, and different sets of criteria can be stored.

To better understand the voice call debug filtering on Cisco voice gatekeepers, see the following sections:

Debug Commands that Support Voice Call Filtering on Cisco Voice Gatekeepers

Gatekeeper Filter Module

Calling and Called Number Strings

Exact and Partial Matching Conditions Rules and Information

Debug Commands that Support Voice Call Filtering on Cisco Voice Gatekeepers

When a call filter is applied, the filtering applies to all of the debugs affected by the call filter. Debug commands that support voice call debug filtering on gatekeepers are the following:

debug gatekeeper call level

debug gatekeeper main level

debug gatekeeper servers


Note In the syntax, the level argument can be a number from 1 through 10. Refer to the Cisco IOS Debug Command Reference for detailed information about these debug commands.


Gatekeeper Filter Module

The filtering for these modules is managed by the gatekeeper filter module (GKFM). The filtering conditions are configured in the GKFM, and then the individual modules are informed when a call has to be filtered. The GKFM coordinates between multiple modules to handle filtering conditions.

The GKFM provides the core infrastructure for the gatekeeper module to use for providing call tracing capabilities. This module is part of the GCFM subsystem (sub_gcfm) and provides all the necessary implementations for the command-line interface (CLI) functions, conditions matching logics for the gatekeeper.

The gatekeeper debug subsystem uses the GKFM infrastructure to implement standard style header formats.

Activity in the GKFM can be traced using the debug call filter detail and debug call filter inout commands. Refer to the Cisco IOS Debug Command Reference for more information about these debug commands.

The GKFM functionalities are summarized as follows:

Maintain a set of matching lists that are activated through the CLI interface for filtering out desired calls.

Provide an interface to the gatekeeper modules for filter query for exact and partial matches.

Implement an algorithm to execute the matching logic by examining the activated filter tags provisioned through the CLI interface. The algorithm is optimized in a way that the logic is executed only when there is a new call parameter populated in the context or there is a change in the CLI provisioned data.

Employ a filter rules engine to prevent activation of illegal and conflicting filter tags (that is, filter tags having conflicting conditions provisioned across them).

Calling and Called Number Strings

The string pattern for calling and called numbers can be either a complete telephone number or a partial telephone number with wildcard digits, represented by a period (.) character. Each "." represents a wildcard for an individual digit that the originating voice gateway expects to match. For example, if the calling and called number strings is defined as "555....", then any dialed string beginning with 555, plus at least four additional digits, matches this calling or called number.

Table 9 shows all of the wildcard symbols that are supported in the calling and called number strings.

Table 9 Wild CardSymbols Supported in Calling and Called Number Strings

Symbol
Description

.

Indicates a single-digit placeholder. For example, 555.... matches any dialed string beginning with 555, plus at least four additional digits.

[ ]

Indicates a range of digits. A consecutive range is indicated with a hyphen (-); for example, [5-7]. A nonconsecutive range is indicated with a comma (,); for example, [5,8]. Hyphens and commas can be used in combination; for example, [5-7,9].

Note Only single-digit ranges are supported. For example, [98-102] is invalid.

( )

Indicates a pattern; for example, 408(555). It is used in conjunction with the symbol ?, %, or +.

?

Indicates that the preceding digit occurred zero or one time. Press ctrl-v before entering ? from your keyboard.

%

Indicates that the preceding digit occurred zero or more times. This functions the same as the "*" used in regular expression.

+

Indicates that the preceding digit occurred one or more times.

T

Indicates the interdigit timeout. The voice gateway pauses to collect additional dialed digits.



Note The wildcard symbols follow regular expression rules, and whatever wildcard applies to the gateway applies to the gatekeeper as well. The period (.) is the only wildcard character that is supported for dial strings that are configured using the answer-address or incoming called-number command.


Exact and Partial Matching Conditions Rules and Information

To filter out desired calls, you must define a list of matching conditions. There must be separate filters defined for VoIP gateways and VoIP gatekeepers, because both the gateway and gatekeeper can exist on the same box.

Multiple filter tags could be provisioned for the gatekeeper, each with one or all three different conditions under them. But the GKFM provides a rules engine to validate while activating thefilter tags when one or more filter tags are contradictory or conflicting with each other. Matching conditions are as follows:

Exact match—All related debug output is filtered and shown when all conditions in the match list are explicitly met. This is the best choice for most situations because the output is the most concise.

Partial match—Related debug output is filtered and shown when even only one condition matches. This choice is useful in debugging call startup problems like digit collection, but is not ideal for many situations because of the large amount of debug output that might be generated before matches explicitly fail.

To filter out the desired calls, you must define a list of matching conditions. Separate filters need to be defined for VoIP gateways and VoIP gatekeepers, because both the gateway and gatekeeper can exist on the same box.

The following global CLI is used to define the conditions on the gatekeeper. The gatekeeper keyword appears in the CLI only if you have a Cisco IOS image that contains gatekeeper debug filter functionality or a combination of gateway and gatekeeper debug filter functionality.

call filter match-list number voice gatekeeper

Then, under the submode, a set of conditions can be defined. Only the following will be valid for filtering calls on the gatekeeper:

incoming calling-number string

incoming called-number string

One new match condition is added that is valid for gatekeeper filtering only:

gatekeeper resolved ipv4 ipaddress

For applying the match filters configured, the CLI for gatekeepers is the same as that used for gateways:

debug condition match-list <1-16> exact-match | partial-match

Table 10 summarizes the rules applied while you are executing the exact and partial match logic.

Table 10 Rules Applied for Executing Exact and Partial Matching Logic 

Number
Decription

1

The exact match is an AND logic across all the provisioned conditions. For example:

call filter match-list 2 gatekeeper
incoming called-number 9876
incoming calling-number 2345
resolved destination ipv4 1.2.3.4

The debugs are emitted only when all the callp provided input matches.

IC Called Number && IC Calling Number && Resolved destination IP address

2

The partial match is a logical OR across all the provisioned conditions. For example:

call filter match-list 2 gatekeeper
incoming called-number 9876
incoming calling-number 2345
resolved destination ipv4 1.2.3.4

The debugs are emitted only when any one of the callp-provided inputs matches.

IC Called Number || IC Calling Number || Resolved destination IP address

3

When the admin provisions a set of conditions under a filter tag that may not contain all three (supported) conditions, then the rules are applied only on that subset of conditions. The non-provisioned conditions are considered as wildcard or don't care. For example:

call filter match-list 2 gatekeeper
incoming called-number 9876
resolved destination ipv4 1.2.3.4

Because incoming calling number was not provided, it is taken as a don't care condition and excluded when the GKFM is executing the matching logic. This tag shall be an exact match for all calls with called number 9876, resolved destination 1.2.3.4, and any calling number xxxx.

4

When the admin provisions only the resolved destination address under a filter tag, then all debugs (for which filtering is employed) shall be throwing the outputs until the callp learns the resolved destination address (that is, until the RAS-LCF message was obtained or the route server provides the resolved address during a later part of the call). This scenario should be well understood before such a filter tag is activated. For example:

call filter match-list 1 gatekeeper
resolved destination ipv4 1.2.3.4

Then debugs for all the calls with any IC called/calling numbers shall be thrown until the resolved destination address is known. When the resolved destination address happens to be 1.2.3.4, then the debug outputs would continue—if not, it would stop at that point.

5

If the admin provisions a filter tag with no matching conditions under it, such a tag cannot be activated. For example:

!
call filter match-list 3 gatekeeper
!
#deb condition match-list 3 exact

Failed: Activation of tag with no filter condition is not allowed.

6

If an activated filter tag condition is modified, that tag needs to be explicitly reactivated after any changes. For example:

!
call filter match-list 2 gatekeeper
incoming called-number 9876
incoming calling-number 2345
resolved destination ipv4 1.2.3.4
!
# show call filter match-list
*********************************************
call filter match-list 2 gatekeeper
*********************************************

incoming called-number 9876
incoming calling-number 2345
gatekeeper resolved destination address 1.2.3.4
debug condition match-list is set to EXACT_MATCH
!
# conf t
(config)# call filter match-list 2 gatekeeper
(conf-call-filter-mlist)# incoming calling-number 4089
(conf-call-filter-mlist)# end
# # show call filter match-list
*********************************************
call filter match-list 2 gatekeeper
*********************************************
incoming called-number 9876
incoming calling-number 2345
gatekeeper resolved destination address 1.2.3.4
debug condition match-list is not ARMED

7

A call for which the GKFM decides failed match (suppress) does not result in any debugs or reexecution of matching logic during the lifespan of that call, even though the CLI admin modifies the provisioned conditions during the lifespan of that call.


GKFM Debug Filter Rules Engine

The following are the rules employed by the filter activation rules engine in order to avoid the conflicts between one or more activated filter tags.

Y- indicates configured

X- indicates not configured (don't care)

1. New condition pattern to be activated—CDN:Y, CGN:X, RES_IPV4:X

Existing activated filter patterns

Activated CDN

Activated CGN

Activated IPV4

Employed Rules

Y

X

X

Compare CDN only.
Reject - if same
Allow - if different

X

X

Y

Reject always.

X

Y

X

Reject always.

X

Y

Y

Reject always.

Y

X

Y

Compare CDN only.
Reject - if same
Allow - if different

Y

Y

X

Compare CDN only.
Reject - if same
Allow - if different

Y

Y

Y

Compare CDN only.
Reject - if same
Allow - if different


2. New condition pattern to be activated—CDN:X, CGN:Y, RES_IPV4:X

Existing activated filter patterns

Activated CDN

Activated CGN

Activated IPV4

Employed Rules

X

Y

X

Compare CGN only.
Reject - if same
Allow - if different

X

Y

Y

Compare CGN only.
Reject - if same
Allow - if different

Y

Y

X

Compare CGN only.
Reject - if same
Allow - if different

Y

Y

Y

Compare CGN only.
Reject - if same
Allow - if different

X

X

Y

Reject always.

Y

X

X

Reject always.

Y

X

Y

Reject always.


3. New condition pattern to be activated—CDN:Y, CGN:Y, RES_IPV4:X

Existing activated filter patterns

Activated CDN

Activated CGN

Activated IPV4

Employed Rules

Y

Y

X

Compare CDN and CGN.
Reject - if both are same
Allow - if anyone different

Y

Y

Y

Compare CDN and CGN only.
Reject - if both are same
Allow - if anyone different

X

Y

X

Compare CGN only.
Reject - if same
Allow - if different

Y

X

X

Compare CDN only.
Reject - if same
Allow - if different

X

X

Y

Reject always.

X

Y

Y

Compare CGN only.
Reject - if same
Allow - if different

Y

X

Y

Compare CDN only.
Reject - if same
Allow if different


4. New condition pattern to be activated—CDN:X, CGN:X, RES_IPV4:Y

Existing activated filter patterns

Activated CDN

Activated CGN

Activated IPV4

Employed Rules

X

X

Y

Compare Res. IPv4 only.
Reject - if same
Allow - if different

Y

X

Y

Compare Res. IPv4 only.
Reject - if same
Allow - if different

X

Y

Y

Compare Res. IPv4 only.
Reject - if same
Allow - if different

Y

Y

Y

Compare Res. IPv4 only.
Reject - if same
Allow - if different

X

Y

X

Reject always.

Y

X

X

Reject always.

Y

Y

X

Reject always.


5. New condition pattern to be activated—CDN:Y, CGN:X, RES_IPV4:Y

Existing activated filter patterns

Activated CDN

Activated CGN

Activated IPV4

Employed rules

Y

X

Y

Compare CDN and Res. IPv4.
Reject - if both are same
Allow - if anyone different

Y

Y

Y

Compare CDN and Res. IPv4.
Reject - if both are same
Allow - if anyone different.

Y

X

X

Compare CDN only.
Reject - if same
Allow - if different

Y

Y

X

Compare CDN only.
Reject - if same
Allow - if different

X

X

Y

Compare IPv4 only.
Reject - if same
Allow - if different

X

Y

Y

Compare IPv4 only.
Reject - if same
Allow - if different

X

Y

X

Reject always.


6. New condition pattern to be activated—CDN:X, CGN:Y, RES_IPV4:Y

Existing activated filter patterns

Activated CDN

Activated CGN

Activated IPV4

Employed Rules

X

Y

Y

Compare CGN and Res. IPv4.
Reject - if both are same
Allow - if anyone different

Y

Y

Y

Compare CGN and Res. IPv4.
Reject - if both are same
Allow - if anyone different.

X

X

Y

Compare Res. IPv4 only.
Reject - if same
Allow - if different

Y

X

Y

Compare Res. IPv4 only.
Reject - if same
Allow - if different

X

Y

X

Compare CGN only.
Reject - if same
Allow - if different

Y

Y

X

Compare CGN only.
Reject - if same
Allow - if different

Y

X

X

Reject always.


7. New condition pattern to be activated—CDN:Y, CGN:Y, RES_IPV4:Y

Existing activated filter patterns

Activated CDN

Activated CGN

Activated IPV4

Employed Rules

Y

Y

Y

Compare CDN, CGN and Res. IPv4. Reject - if all are same.
Allow - if any one different

X

X

Y

Compare Res. IPv4 only.
Reject - if same
Allow - if different.

X

Y

X

Compare CGN only.
Rejectect - if same
Allow - if different

X

Y

Y

Compare CGN & Res. IPv4.
Rejectect - if both are same
Allow - if any one different

Y

X

X

Compare CDN only.
Reject - if same
Allow - if different

Y

X

Y

Compare CDN and Res. IPv4 only.
Reject - if both are same
Allow - if any one different

Y

Y

X

Compare CDN and CGN only.
Reject - if both are same
Allow - if any one different.


Configuring the Voice Call Debug Filter for Cisco Gatekeepers

To configure the voice call debug filter on Cisco gatekeepers, perform the following tasks:

Configuring Call-Specific Conditions for Gatekeepers (required)

Enabling Debug for the Set Filtering Conditions (required)

Configuring Call-Specific Conditions for Gatekeepers

Configure call-specific conditions to set the attributes that are filtered for voice calls.

SUMMARY STEPS

1. enable

2. configure terminal

3. call filter match-list number gatekeeper

4. incoming calling-number string

5. incoming called-number string

6. gatekeeper resolved ipv4 ipaddress

7. exit

8. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

call filter match-list number gatekeeper

Example:
Router(config)# call filter match-list 1 
gatekeeper

Enters call filter match list configuration mode to define the filter conditions on the gatekeeper.

number—Numeric label that uniquely identifies the match list. Range is 1 to 16.

Note At least one of the following optional parameters (Step 4 to Step 7) for call filtering must be configured.

Step 4 

incoming calling-number string

Example:
Router(conf-call-filter-mlist)# incoming 
calling-number 408525

(Optional) Specifies the incoming calling number to be filtered.

string—Numeric string that identifies all or part of the incoming calling number.

Step 5 

incoming called-number string

Example:
Router(conf-call-filter-mlist)# incoming 
called-number 408525

(Optional) Specifies the incoming called number to be filtered.

string—Numeric string that identifies all or part of the incoming called number.

Step 6 

gatekeeper resolved ipv4 ipaddress

Example:

Router(conf-call-filter-mlist)# gatekeeper resolved ipv4 10.1.1.1

(Optional) Specifies the gatekeeper-resolved destination IP address to be filtered.

ipaddress—IP address that identifies the destination.

Step 7 

exit

Example:

Router(conf-call-filter-mlist)# exit

Exits to global configuration mode.

Step 8 

exit

Example:

Router(config)# exit

Exits to privileged EXEC mode.

Enabling Debug for the Set Filtering Conditions

Use the debug commands to enable the set conditions to get the filtered output.

Prerequisites

The conditions for the voice call debug filter must be set as described in the "Configuring Call-Specific Conditions for Gatekeepers" section.

SUMMARY STEPS

1. enable

2. debug condition match-list tag {exact-match | partial-match}

3. debug gatekeeper call level

or

debug gatekeeper main level

or

debug gatekeeper servers

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

debug condition match-list tag {exact-match | partial-match}

Example:

Router# debug condition match-list 1 exact-match

Enables the filter match list for the set conditions.

tag—Numeric label that uniquely identifies the match list. Range is 1 to 16. The number for the match list is set using the call filter match-list command.

exact-match—All related debug output is filtered until all conditions in the match list are explicitly met. This is the best choice for most situations because the output is the most concise.

partial-match—No related debug output is filtered until there is a single explicit match failure. As long as zero or more conditions are met, debug output is not filtered. This choice is useful in debugging call startup problems like digit collection, but is not ideal for many situations because a large amount of debug output is generated before matches explicitly fail.

Step 3 

debug gatekeeper call level

or

debug gatekeeper main level

or

debug gatekeeper servers

Example:

Router# debug gatekeeper call 5

Example:

Router# debug gatekeeper main 3

Example:

Router# debug gatekeeper servers

Enables the appropriate gatekeeper call debug commands.

level—Specifies a level for the debug message. Entries can be 1 through 10.

Refer to the Cisco IOS Debug Command Reference for detailed descriptions of these debug commands.

The debug output commences at this point.

Troubleshooting Tips

To verify debug conditions, use the following commands:

show debug

This command displays the debugs that are enabled.

show call filter components

This command displays the components that register internally with the filtering module. This command shows which components are registered with the GKFM, which is the internal module that controls which components are filtered.

show call filter match-list

This command displays the criteria set for the specified match list. It shows a list of all the match lists, shows which ones are enabled, and shows whether they are enabled for partial or exact matching.

Examples

This section provides sample output and a typical debug listing:

Sample Output for show call filter and show debug: Example

Sample Output for show debug: Example

Sample Output for show call filter and show debug: Example

When the exact match condition is used for gatekeeper voice call debug filtering, all related debug output is filtered until all conditions in the match list are explicitly met:

Router# show call filter match-list 

********************************************* 
call filter match-list 1 gatekeeper 
*********************************************
gatekeeper resolved destination address 10.77.154.91
incoming called-number 444
debug condition match-list is not armed
********************************************* 
call filter match-list 2 gatekeeper 
*********************************************
incoming called-number 204
debug condition match-list is set to EXACT_MATCH
Router#
################################ 
Router# show debug
Gatekeeper:
Gatekeeper Server Messages debugging is on (filter is ON)
gk call debug level = 10 (filter is ON)
gk zone debug level = 10
c2691-1-OGK#

Sample Output for show debug: Example

Following is a sample output resulting from the show debug command:

*Mar 2 03:12:04.259: //C1989D10805C/C1989D10805D/GK/rassrv_arq_select_viazone: matched 
zone is GK-A, and z_invianamelen=0
*Mar 2 03:12:04.259: //C1989D10805C/C1989D10805D/GK/rassrv_arq_select_viazone: about to 
check the destination side, dst_zonep=0x6293721C
*Mar 2 03:12:04.259: //C1989D10805C/C1989D10805D/GK/rassrv_arq_select_viazone: matched 
zone is GK-A, and z_outvianamelen=0
*Mar 2 03:12:04.259: //C1989D10805C/C1989D10805D/GK/rassrv_get_addrinfo: No tech prefix 
*Mar 2 03:12:04.259: //C1989D10805C/C1989D10805D/GK/rassrv_get_addrinfo: Alias not found 

*Mar 2 03:12:04.259: //C1989D10805C/C1989D10805D/GK/rassrv_get_addrinfo: (203) unknown address and no default technology defined.

SIP Debug Output Filtering Support

The SIP Debug Output Filtering Support feature provides the capability for SIP-related debug output to be filtered based on a set of user-defined matching conditions. This section contains the following information:

Restrictions for SIP Debug Output Filtering Support

Information About SIP Debug Output Filtering Support

Configuring SIP Debug Filtering

Configuration Examples for SIP Debug Filtering

Restrictions for SIP Debug Output Filtering Support

The SIP Debug Output Filtering Support feature filters all enabled bugs, not just SIP bugs.

Information About SIP Debug Output Filtering Support

To configure the SIP Debug Output Filtering Support feature, you should understand the following concepts:

Feature Design of SIP Debug Output Filtering Support

Generic Call Filtering Module

SIP Debug Commands that Support Output Filtering

Matching Conditions

Feature Design of SIP Debug Output Filtering Support

Prior to the SIP Debug Output Filtering Support feature, debugging and troubleshooting on the VoIP gateway was made more challenging by the extensive amounts of raw data generated by debug output. This feature allows the debug output for a SIP call to be filtered according to a variety of criteria. The SIP Debug Output Filtering Support feature provides a generic call filtering mechanism that does the following:

Allows you to define a set of matching conditions for filtering calls.

Identifies the desired calls based on the configured matching conditions inside VoIP gateways.

Coordinates the filtering effort on traced calls between multiple modules inside VoIP gateways.

Displays the debugging trace for calls that match the specified conditions.

The SIP Debug Output Filtering Support feature document provides SIP-specific information on the debug filtering design in Cisco IOS gateways implemented by the voice call debug filtering feature. See the "Voice Call Debug Filtering on Cisco Voice Gateways" section for more information.

Generic Call Filtering Module

Cisco implements the SIP Debug Output Filtering Support feature using the GCFM to identify and track calls based on configured parameters. You can use the command-line interface (CLI) to turn the GCFM on and off. When the GCFM is turned on, only the debug messages for calls that match the filtering conditions are displayed.

The GCFM manages the set of matching condition lists and coordination and tracking of calls between multiple modules within the voice gateway architecture. The SIP module uses the GCFM function to create GUIDs to track individual inbound and outbound SIP calls. Activity in the GCFM can be traced using the debug call filter detail and debug call filter inout commands. See the Cisco IOS Debug Command Reference for more information about these debug commands.

SIP Debug Commands that Support Output Filtering

debug ccsip all

debug ccsip calls

debug ccsip events

debug ccsip messages

debug ccsip preauth

debug ccsip states

See the Cisco IOS Debug Command Reference for more information about SIP debug commands.


Note Because of the importance of the messages associated with the debug ccsip err command, this debug output is not filterable.


Matching Conditions

To filter calls, define a list of matching conditions. The SIP Debug Output Filtering Support feature supports matches based on the following conditions:

Incoming calling-number string

Incoming called-number string

Incoming signaling IPv4 local address

Incoming signaling IPv4 remote address

Incoming media IPv4 local address

Incoming media IPv4 remote address

Incoming dial peer

Outgoing calling-number string

Outgoing called-number string

Outgoing signaling IPv4 local address

Outgoing signaling IPv4 remote address

Outgoing media IPv4 local address

Outgoing media IPv4 remote address

Outgoing dial peer

The string pattern for calling and called numbers can be either a complete telephone number or a partial telephone number with wildcard digits, represented by a period (.) character.

You can define matching conditions as follows:

Exact match—All related debug output is filtered until all conditions in the match list are explicitly met. This option is the best choice for most situations because it produces the most concise output.

Partial match—No related debug output is filtered until there is a single explicit match failure. As long as zero or more conditions are met, debug output is not filtered. This choice is useful in debugging call startup problems like digit collection, but is not ideal for many situations because of the large amount of debug output until matches explicitly fail.

See the "Exact and Partial Matching" section for more information on matching conditions and filtering voice calls.

Configuring SIP Debug Filtering

This section contains the following procedures:

Configuring Call Filters (required)

Enabling SIP Debug Output Filtering (required)

Verifying SIP Debug Output Filtering Support (optional)

Configuring Call Filters

This task configures the conditions for filtering SIP calls.

SUMMARY STEPS

1. enable

2. configure terminal

3. call filter match-list number voice

4. incoming calling-number string

5. incoming called-number string

6. incoming signaling {local | remote} ipv4 ip-address

7. incoming media {local | remote} ipv4 ip-address

8. incoming dialpeer tag

9. outgoing calling-number string

10. outgoing called-number string

11. outgoing signaling {local | remote} ipv4 ip-address

12. outgoing media {local | remote} ipv4 ip-address

13. outgoing dialpeer tag

14. end

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

call filter match-list number voice

Example:

Router(config)# call filter match-list 1 voice

Enters call filter match list configuration mode to define the filter conditions.

number—Numeric label that uniquely identifies the match list. Range is 1 to 16.

Note At least one of the following optional parameters (Step 4 to Step 13) for call filtering must be configured.

Step 4 

incoming calling-number string

Example:

Router(conf-call-filter-mlist)# incoming calling-number 408555

(Optional) Specifies the incoming calling number to be filtered.

string—Numeric string that identifies all or part of the incoming calling number.

Step 5 

incoming called-number string

Example:

Router(conf-call-filter-mlist)# incoming called-number 408555

(Optional) Specifies the incoming called number to be filtered.

string—Numeric string that identifies all or part of the incoming called number.

Step 6 

incoming signaling {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# incoming signaling local ipv4 192.168.10.255

(Optional) Specifies the incoming signaling IPv4 address.

local—Local voice gateway

remote—Remote IP device

ip-address—IP address of the local voice gateway.

Step 7 

incoming media {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# incoming media local ipv4 192.168.10.255

(Optional) Specifies the incoming media IPv4 address for the voice gateway receiving the media stream.

local—Local voice gateway

remote—Remote IP device

ip-address—IP address of the local voice gateway.

Step 8 

incoming dialpeer tag

Example:

Router(conf-call-filter-mlist)# incoming dialpeer 14

(Optional) Specifies the incoming dial peer to be filtered.

tag—Digits that define a specific dial peer. Valid entries are 1 to 2147483647.

Step 9 

outgoing calling-number string

Example:

Router(conf-call-filter-mlist)# outgoing calling-number 408555

(Optional) Specifies the outgoing calling number to be filtered; this number goes out after number translation and expansion are complete.

string—Numeric string that identifies all or part of the outgoing calling number.

Step 10 

outgoing called-number string

Example:

Router(conf-call-filter-mlist)# outgoing called-number 408555

(Optional) Specifies the outgoing called number to be filtered; this number goes out after number translation and expansion are complete.

string—Numeric string that identifies all or part of the outgoing called number.

Step 11 

outgoing signaling {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# outgoing signaling local ipv4 192.168.10.255

(Optional) Specifies the outgoing signaling IPv4 address for the gatekeeper managing the signaling.

local—Local voice gateway

remote—Remote IP device

ip-address—IP address of the local voice gateway.

Step 12 

outgoing media {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# outgoing media local ipv4 192.168.10.255

(Optional) Specifies the outgoing media IPv4 address for the voice gateway receiving the media stream.

local—Local voice gateway

remote—Remote IP device

ip-address—IP address of the local voice gateway.

Step 13 

outgoing dialpeer tag

Example:

Router(conf-call-filter-mlist)# outgoing dialpeer 14

(Optional) Specifies the outgoing dial peer to be filtered.

tag—Digits that define a specific dial peer. Valid entries range from1 to 2147483647.

Step 14 

end

Example:

Router(conf-call-filter-mlist)# end

Exits to privileged EXEC mode.

What to Do Next

After the conditions are set for filtering the SIP call debug output, debug commands can be enabled. Proceed to the "Enabling SIP Debug Output Filtering" section.

Enabling SIP Debug Output Filtering

This task enables debug filtering for SIP-related output.

Prerequisites

The conditions for the SIP call debug filter must be set as described in the "Configuring Call Filters" section.

SUMMARY STEPS

1. enable

2. debug condition match-list number {exact-match | partial-match}

3. debug ccsip {all | calls | events | messages | preauth | states}

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

debug condition match-list number {exact-match | partial-match)

Example:

Router# debug condition match-list 1 exact-match

Enables the filter match list for the set conditions.

number—Numeric label that uniquely identifies the match list. Range is 1 to 16.

exact-match—All related debug output is filtered until all conditions in the match list are explicitly met. This is the best choice for most situations because the output is the most concise.

partial-match—No related debug output is filtered until there is a single explicit match failure. As long as zero or more conditions are met, debug output is not filtered. This choice is useful in debugging call startup problems like digit collection, but is not ideal for many situations because a large amount of debug output is generated before matches explicitly fail.

Step 3 

debug ccsip {all | calls | events | messages | preauth | states}

Example:

Router# debug ccsip all

Enables the appropriate SIP call debug commands.

See the Cisco IOS Debug Command Reference for detailed descriptions of these debug commands.

The debug output begins at this point.

Verifying SIP Debug Output Filtering Support

Perform this task to verify debug output filtering.

SUMMARY STEPS

1. show debug

2. show call filter components

3. show call filter match-list

DETAILED STEPS


Step 1 show debug

Use this command to display the debugs that are enabled, for example:

Router# show debug

CCSIP SPI:SIP Call Statistics tracing is enabled       (filter is ON)
CCSIP SPI:SIP Call Message tracing is enabled  (filter is ON)
CCSIP SPI:SIP Call State Machine tracing is enabled    (filter is ON)
CCSIP SPI:SIP Call Events tracing is enabled   (filter is ON)
CCSIP SPI:SIP error debug tracing is enabled   (filter is ON)
CCSIP SPI:SIP info debug tracing is enabled    (filter is ON)
CCSIP SPI:SIP media debug tracing is enabled   (filter is ON)
CCSIP SPI:SIP Call preauth tracing is enabled (filter is ON)

Step 2 show call filter components

Use this command to display which components are registered with the GCFM, the internal module that controls which components are filtered:

Router# show call filter components

 The following components registered in GCFM:
     ISDN
     VTSP
     CCAPI
     TGRM
     DIAL-PEER
     NUMBER-TRANSLATION
     SSAPP
     VOICE-IVR-V2
     H323
     SIP
     CRM

Step 3 show call filter match-list

Use this command to display the criteria set for the specified match list. The command shows a list of all the match lists, shows which ones are enabled, and shows whether they are enabled for partial or exact matching.

Router# show call filter match-list

*********************************************
call filter match-list 1 voice
*********************************************
  incoming called-number 5551200

Configuration Examples for SIP Debug Filtering

This section provides the following configuration examples:

Configuring Call Filters: Example

Enabling SIP Debug Output Filtering: Example

Configuring Call Filters: Example

The following example shows how to configure call filters. In the example, the Cisco AS5300 configuration defining a match list and specifying the incoming called number to be filtered is shown.

Router# show running-config

Building configuration...

Current configuration :3944 bytes
!
! Last configuration change at 13:07:08 EST Tue Sep 2 2003
!
version 12.3
no service pad
service timestamps debug datetime msec localtime
service timestamps log datetime msec localtime
no service password-encryption
service internal
!
hostname Router-1
!
logging buffered 500000 debugging
enable password lab
!
!
!
resource-pool disable
clock timezone EST -5
clock summer-time EST recurring
!
no aaa new-model
ip subnet-zero
ip domain name cisco.com
ip host CALLGEN-SECURITY-V2 10.73.75.86 8.52.0.0
ip name-server 10.44.11.21
!
!
isdn switch-type primary-dms100
no scripting tcl init
no scripting tcl encdir
!
!
voice call carrier capacity active
!
voice service voip 
 no supplementary-service h450.12
 sip
!
!
voice class codec 1
 codec preference 1 g711ulaw
 codec preference 2 g729r8
!
!
voice hpi capture buffer 10000
no voice hpi capture destination 
!
!
fax interface-type modem
call-history-mib retain-timer 500
call-history-mib max-size 500
!
!
controller T1 0
 framing esf
 clock source line primary
 linecode b8zs
 pri-group timeslots 1-24
!
controller T1 1
 framing esf
clock source line secondary 1
 linecode b8zs
 pri-group timeslots 1-24
!
controller T1 2
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
!
controller T1 3
 framing esf
 linecode b8zs
 pri-group timeslots 1-24
!
!
interface Ethernet0
 no ip route-cache
 no ip mroute-cache
 shutdown
 no cdp enable
!
interface Serial0:23
 no logging event link-status
isdn switch-type primary-dms100
 isdn incoming-voice modem
 no cdp enable
!
interface Serial1:23
 no logging event link-status
 isdn switch-type primary-dms100
 isdn incoming-voice modem
 no cdp enable
!
interface Serial2:23
 no logging event link-status
 isdn switch-type primary-dms100
 isdn incoming-voice modem
 no cdp enable
!
interface Serial3:23
 isdn switch-type primary-dms100
 no cdp enable
!
interface FastEthernet0
 ip address 172.18.195.43 255.255.0.0
 no ip route-cache
no ip mroute-cache
 duplex auto
 speed auto
 fair-queue 64 256 235
 no cdp enable
!
ip classless
ip route 0.0.0.0 0.0.0.0 FastEthernet0
ip route 10.0.0.0 255.0.0.0 172.18.193.3
ip route 10.0.0.0 255.0.0.0 172.18.195.1
ip route 172.18.0.0 255.255.0.0 172.18.193.1
ip http server
!
!
!
control-plane
!
!
!
call filter match-list 1 voice
incoming called-number 4085559876
!
voice-port 0:D
!
voice-port 1:D
!
voice-port 2:D
!
voice-port 3:D
!
!
dial-peer cor custom
!
!
!
dial-peer voice 1100 pots
 destination-pattern 55511..
 direct-inward-dial
 port 0:D
 prefix 55511
!
dial-peer voice 1200 pots
 destination-pattern 55512..
direct-inward-dial
 port 1:D
 prefix 55512
!
dial-peer voice 444 pots
 destination-pattern 444....
 direct-inward-dial
 port 2:D
 prefix 444
!
dial-peer voice 5100 voip
 destination-pattern 55551..
 session protocol sipv2
 session target ipv4:172.18.207.10:5060
 dtmf-relay rtp-nte
 codec g711ulaw
!
dial-peer voice 5200 voip
 destination-pattern 55552..
 session protocol sipv2
 session target ipv4:172.18.207.10:5060
 dtmf-relay rtp-nte
!
dial-peer voice 5300 voip
 destination-pattern 55553..
 session protocol sipv2
 session target ipv4:10.0.0.5
 dtmf-relay rtp-nte
!
dial-peer voice 5400 voip
 destination-pattern 55554..
 session protocol sipv2
 session target ipv4:10.0.0.5
 dtmf-relay rtp-nte
!
dial-peer voice 2100 voip
 destination-pattern 55521..
 session protocol sipv2
 session target ipv4:172.18.193.88
 dtmf-relay rtp-nte
 codec g711ulaw
!
dial-peer voice 2200 voip
 destination-pattern 55522..
 session protocol sipv2
 session target ipv4:172.18.207.10:5060
dtmf-relay rtp-nte
!
gateway 
!
sip-ua 
 retry invite 3
 retry response 3
 retry bye 3
 retry cancel 3
 retry prack 3
 retry comet 3
 retry rel1xx 3
 retry notify 3
 timers trying 750
!
!
line con 0
 exec-timeout 0 0
 transport preferred none
line aux 0
line vty 0 4
 exec-timeout 0 0
 password lab
login
 transport preferred none
!
ntp clock-period 17180086
ntp server 172.68.10.150 prefer
!
end

Enabling SIP Debug Output Filtering: Example

The following example shows how to enable SIP debug output filtering. In the following example, the match-list configuration, enabled debugs, and debug output for a Cisco AS5300 are shown.


Note When the exact match condition is used for SIP call debug filtering, all related debug output is filtered until all conditions in the match list are explicitly met.


Router# debug condition match-list 1 exact-match
Router# debug ccsip all

Router# show debug

CCSIP SPI:SIP Call Statistics tracing is enabled       (filter is ON)
CCSIP SPI:SIP Call Message tracing is enabled  (filter is ON)
CCSIP SPI:SIP Call State Machine tracing is enabled    (filter is ON)
CCSIP SPI:SIP Call Events tracing is enabled   (filter is ON)
CCSIP SPI:SIP error debug tracing is enabled   (filter is ON)
CCSIP SPI:SIP info debug tracing is enabled    (filter is ON)
CCSIP SPI:SIP media debug tracing is enabled   (filter is ON)
CCSIP SPI:SIP Call preauth tracing is enabled  (filter is ON)

Router# Debug filtering is now on
Building configuration...
!
!
!
call filter match-list 1 voice
incoming called-number 4085551221
!
end

The following lines show partial debug output with the filter on. Some debug output generated during a call may not have GUID information. These debugs, represented by /xxxxxxxxxxxx/ characters in the debug header, are not filtered and always appear.

Sep  2 13:11:05.395://-1/xxxxxxxxxxxx/SIP/Error/httpish_msg_process_network_msg:Content 
Length 222, Bytes Remaining 233
Sep  2 13:11:05.395://-1/xxxxxxxxxxxx/SIP/Info/HandleUdpSocketReads:Msg enqueued for SPI 
with IP addr:10.102.16.214:56587
Sep  2 13:11:05.395://-1/xxxxxxxxxxxx/SIP/Info/sipSPISetDateHeader:Converting TimeZone EST 
to SIP default timezone = GMT
Sep  2 13:11:05.399://-1/xxxxxxxxxxxx/SIP/Error/sipSPI_validate_own_ip_addr:ReqLine IP 
addr does not match with host IP addr
Sep  2 13:11:05.399://-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:Queued event from SIP SPI 
:SIPSPI_EV_SEND_MESSAGE

The next lines show the debug filtering turned off.

Router# no debug condition match-list 1
Router# show debug

CCSIP SPI:SIP Call Statistics tracing is enabled       (filter is OFF)
CCSIP SPI:SIP Call Message tracing is enabled  (filter is OFF)
CCSIP SPI:SIP Call State Machine tracing is enabled    (filter is OFF)
CCSIP SPI:SIP Call Events tracing is enabled   (filter is OFF)
CCSIP SPI:SIP error debug tracing is enabled   (filter is OFF)
CCSIP SPI:SIP info debug tracing is enabled    (filter is OFF)
CCSIP SPI:SIP media debug tracing is enabled   (filter is OFF)
CCSIP SPI:SIP Call preauth tracing is enabled  (filter is OFF)

With filtering turned off, all the debug output is displayed.

Sep  2 13:12:31.112://-1/xxxxxxxxxxxx/SIP/Info/HandleUdpSocketReads:Msg enqueued for SPI 
with IP addr:10.102.16.214:56589
Sep  2 13:12:31.112://-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SUBSCRIBE sip:3100802@172.18.193.99:5060 SIP/2.0
Via:SIP/2.0/UDP  172.18.193.100:5060;branch=z9hG4bK1348
From:"3100801" <sip:3100801@172.18.193.100>;tag=19AE8-A6C
To:<sip:3100802@172.18.193.99>;tag=19AE8-A6C
Date:Mon, 30 Oct 2000 04:47:31 GMT
Call-ID:96ACB04F-AD5611D4-800894FA-5B905DB@172.18.193.100
Supported:timer,100rel
Min-SE: 1800
Cisco-Guid:2496939846-2908099028-2147680272-2073165500
User-Agent:Cisco-SIPGateway/IOS-12.x
Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, 
UPDATE
CSeq:101 SUBSCRIBE
Max-Forwards:6
Remote-Party-ID:<sip:3100801@172.18.193.100>;party=calling;screen=no;privacy=off
Timestamp:972881251
Contact:<sip:3100801@172.18.193.100:5060>
Expires:60
Allow-Events:telephone-event
Content-Type:application/sdp
Content-Length:233

v=0
o=CiscoSystemsSIP-GW-UserAgent 2904 6070 IN IP4 172.18.193.100
s=SIP Call
c=IN IP4 172.18.193.100
t=0 0
m=audio 18862 RTP/AVP 18 19
c=IN IP4 172.18.193.100
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:19 CN/8000
a=ptime:20

Sep  2 13:12:31.112://-1/94D447468003/SIP/State/sipSPIChangeState:0x631570C8 :State change 
from (STATE_NONE, SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
Sep  2 13:12:31.112://-1/xxxxxxxxxxxx/SIP/Info/sipSPISetDateHeader:Converting TimeZone EST 
to SIP default timezone = GMT
Sep  2 13:12:31.116://-1/xxxxxxxxxxxx/SIP/Error/sipSPI_validate_own_ip_addr:ReqLine IP 
addr does not match with host IP addr
Sep  2 13:12:31.116://-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:Queued event from SIP SPI 
:SIPSPI_EV_SEND_MESSAGE
Sep  2 13:12:31.116://-1/94D447468003/SIP/Info/sipmwiEventCleanup:Removing CCB with mwi 
clientID(3100802)
Sep  2 13:12:31.116://-1/94D447468003/SIP/State/sipSPIChangeState:0x631570C8 :State change 
from (STATE_IDLE, SUBSTATE_NONE)  to (STATE_DEAD, SUBSTATE_NONE)
Sep  2 13:12:31.116://-1/94D447468003/SIP/Info/ccsip_deregister_call_filter:Deregistering 
call from GCFM
Sep  2 13:12:31.120://-1/94D447468003/SIP/Info/sipSPIFlushEventBufferQueue:There are 0 
events on the internal queue that are going to be free'd
Sep  2 13:12:31.120://-1/94D447468003/SIP/Info/sipSPIUfreeOneCCB:Freeing ccb 631570C8
Sep  2 13:12:31.120://-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 489 Bad Event - 'Missing Event:field'

Via:SIP/2.0/UDP  
172.18.193.100:5060;branch=z9hG4bK1348;received=10.102.16.214

From:"3100801" <sip:3100801@172.18.193.100>;tag=19AE8-A6C

To:<sip:3100802@172.18.193.99>;tag=19AE8-A6C

Call-ID:96ACB04F-AD5611D4-800894FA-5B905DB@172.18.193.100

CSeq:101 SUBSCRIBE

Timestamp:972881251

Content-Length:0

MGCP Call Centric Debug

The MGCP Call Centric Debug feature enables the filtering of debug output based on selected criteria and this feature also standardizes the format of the MGCP debug header. By sharing a common header format all MGCP debug information for a single call can be identified and correlated across the various layers in Cisco IOS software. Filtering debug output reduces extraneous information displayed on the console port, making it easier to locate the correct information and reducing the impact to platform performance, while mitigating lost data because of buffer limits.

This section contains the following information:

Restrictions for MGCP Call Centric Debug

Information About MGCP Call Centric Debug

How to Enable MGCP Call Centric Debug

Configuration Examples for MGCP Call Centric Debug

Restrictions for MGCP Call Centric Debug

Filtering conditions that are set for other Cisco IOS modules also impact the debug output for the MGCP module.

Information About MGCP Call Centric Debug

To use the MGCP Call Centric Debug feature, you should understand the following concepts:

Generic Call Filter Module

MGCP Debug Commands that Support Debug Filtering

Match Conditions for MGCP Debug Filtering

Trace Levels for MGCP Debug Output

Tips on Collecting Debug Output

MGCP Debug Commands that Support Debug Filtering

debug mgcp all

debug mgcp endpoint

debug mgcp endptdb

debug mgcp errors

debug mgcp events

debug mgcp gcfm

debug mgcp inout

debug mgcp media

debug mgcp src

debug mgcp state

debug mgcp voipcac


Note Debug filtering is not supported for the debug mgcp nas, debug mgcp packets, or debug mgcp parser commands.


See the Cisco IOS Debug Command Reference, Release 12.4T for more information about MGCP debug commands.

Match Conditions for MGCP Debug Filtering

To filter calls, you must first define a list of conditions on which to match. The attributes associated with a call are compared to the configured list of match conditions. Debug output that matches all or some of the conditions in the list is displayed, depending on whether the match criteria is set to either exact or partial match.

The MGCP Call Centric Debug feature supports filtering based on the following conditions:

Incoming signaling IPv4 local address

Incoming signaling IPv4 remote address

Incoming media IPv4 local address

Incoming media IPv4 remote address

Incoming dial peer

Outgoing signaling IPv4 local address

Outgoing signaling IPv4 remote address

Outgoing media IPv4 local address

Outgoing media IPv4 remote address

See the "Creating Match Lists for MGCP Filtering Conditions" section for information on configuring match conditions for filtering MGCP calls.

Trace Levels for MGCP Debug Output

The MGCP Call Centric Debug feature introduces trace levels for MGCP debug output. Trace levels allow you to control the amount of information that is displayed by debug commands based on the importance of the content. Trace levels are associated with priority levels that categorize MGCP debug output depending on the information it contains. The output for each debug command is categorized within three priority levels: high, medium, and low.

The following trace levels can be selected to indicate the priority of the information that is displayed:

Critical—Displays only MGCP debug information marked as high priority.

Moderate—Displays MGCP debug information marked as medium or high priority.

Verbose—Displays all MGCP debug information. This is the default level.


Note The debug mgcp errors and debug mgcp packets commands do not support trace levels. Their debug output is set to the highest priority and is displayed for all trace level values.


You can set the desired trace level for an MGCP debug session by using the tracelevel keyword in individual MGCP debug commands or by setting a global trace level using the debug mgcp tracelevel-default command.


Note Setting the trace level for an endpoint using the mgcp debug endpoint command is independent of the global trace level. The endpoint level takes precedence over the global level. For example, the debug mgcp event tracelevel moderate command used with the debug mgcp endpoint aaln/S2/SU0/0 event tracelevel verbose command sets the trace level to verbose for that specific endpoint while all of the other endpoints have event debugs set at a moderate level. If the global debug is disabled, the per-endpoint debug remains enabled and vice versa.


Tips on Collecting Debug Output

Logging debug output to the console has disadvantages such as being slower and dropping data more easily than logging to a buffer. Collecting debug information by logging output to a buffer instead of the console reduces the impact to gateway performance and decreases the incidence of dropped data.

To log debug output to a buffer instead of the console, use the no logging console and logging buffered commands. These commands can only be used, however, if there is enough memory available on the gateway to create a large enough buffer to collect the debug output. To display debug output that was collected and sent to the configured buffer, use the show logging command.

Logging debug output to the console may also consume an excessive amount of CPU resources if the logging console guaranteed command is enabled, which is the default setting. It is recommended that you disable this functionality by using the no logging console guaranteed command when sending debug output to the console.

You may also want to use the service timestamps debug and service timestamps log commands to control how the timestamps are displayed in the debug output.

How to Enable MGCP Call Centric Debug

This section contains the following procedures:

Modifying the Debug Header Format for MGCP Debug Output (optional)

Creating Match Lists for MGCP Filtering Conditions (required)

Enabling MGCP Debug Filtering Using Match Lists (required)

Verifying the MGCP Debug Filtering Configuration (optional)

Enabling MGCP Debug Trace Levels (optional)

Modifying the Debug Header Format for MGCP Debug Output

Perform this procedure to modify the standardized header format for MGCP debug output. Debug output is correlated based on this unique header which is common to all debugs belonging to the same call.

SUMMARY STEPS

1. enable

2. configure terminal

3. voice call debug {full-guid | short-header}

4. mgcp debug-header

5. exit

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

voice call debug {full-guid | short-header}

Example:

Router(config)# voice call debug full-guid

(Optional) Specifies the full GUID or short header for debug output.

full-guid—Displays the GUID in a 16-byte header.

Note Using the no voice call debug full-guid command displays the short 6-byte header.

short-header—Displays the CallEntry ID in the header without displaying the GUID or module-specific parameters. This is the default.

Note For more information, see the "Debug Header Format" section on page 18.

Step 4 

mgcp debug-header

Example:

Router(config)# mgcp debug-header

(Optional) Enables the MGCP module-dependent information in the debug header.

Note This command is enabled by default. This step is included to illustrate how to enable the command if it was previously disabled.

Step 5 

exit

Example:

Router(config)# exit

Exits to privileged EXEC mode.

Creating Match Lists for MGCP Filtering Conditions

Perform this procedure to define match conditions that are used for filtering MGCP calls.

SUMMARY STEPS

1. enable

2. configure terminal

3. call filter match-list number voice

4. incoming signaling {local | remote} ipv4 ip-address

5. incoming media {local | remote} ipv4 ip-address

6. incoming dialpeer tag

7. outgoing signaling {local | remote} ipv4 ip-address

8. outgoing media {local | remote} ipv4 ip-address

9. end

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

configure terminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3 

call filter match-list number voice

Example:

Router(config)# call filter match-list 1 voice

Enters call filter match list configuration mode to define the filter conditions.

number—Numeric label that uniquely identifies the match list. Range is 1 to 16.

Note At least one of the following optional parameters for call filtering (Step 4 to Step 8) must be configured.

Step 4 

incoming signaling {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# incoming signaling local ipv4 192.168.10.255

(Optional) Specifies the incoming signaling IPv4 address.

local—Local voice gateway.

remote—MGCP call agent.

ip-address—IP address of the local voice gateway or remote call agent.

Step 5 

incoming media {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# incoming media local ipv4 192.168.10.255

(Optional) Specifies the incoming media IPv4 address for the voice gateway receiving the media stream.

local—Local voice gateway.

remote—Remote voice gateway.

ip-address—IP address of the local or remote voice gateway.

Step 6 

incoming dialpeer tag

Example:

Router(conf-call-filter-mlist)# incoming dialpeer 14

(Optional) Specifies the incoming telephony dial peer to be filtered.

tag—Digits that define a specific dial peer. Range is 1 to 2147483647.

Note Telephony dial peers are configured using the dial-peer voice command.

Step 7 

outgoing signaling {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# outgoing signaling local ipv4 192.168.10.255

(Optional) Specifies the outgoing signaling IPv4 address for the gatekeeper managing the signaling.

local—Local voice gateway.

remote—MGCP call agent.

ip-address—IP address of the local gateway or remote call agent.

Step 8 

outgoing media {local | remote} ipv4 ip-address

Example:

Router(conf-call-filter-mlist)# outgoing media local ipv4 192.168.10.255

(Optional) Specifies the outgoing media IPv4 address for the voice gateway receiving the media stream.

local—Local voice gateway.

remote—Remote voice gateway.

ip-address—IP address of the local or remote voice gateway.

Step 9 

end

Example:

Router(conf-call-filter-mlist)# end

Exits to privileged EXEC mode.

Enabling MGCP Debug Filtering Using Match Lists

Perform this procedure to enable the match conditions for filtering MGCP debug output.

Prerequisites

The filtering conditions for the debug output must be set as described in the "Creating Match Lists for MGCP Filtering Conditions" section.

Restrictions

The debug mgcp nas, debug mgcp packets, and debug mgcp parser commands do not support debug filtering.

Debug output that is outside the context of a call, for example, RSIP, audit, and some endpoint database information does not support filtering.

SUMMARY STEPS

1. enable

2. debug condition match-list number {exact-match | partial-match}

3. debug mgcp {all | endpoint | endptdb | errors | events | gcfm | media | src | state | voipcac}

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

debug condition match-list number {exact-match | partial-match}

Example:

Router# debug condition match-list 1 exact-match

Enables the filter match list for the set conditions.

number—Numeric label that uniquely identifies the match list. Range is 1 to 16. This number is set using the call filter match-list command.

exact-match—All related debug output is filtered until all conditions in the match list are explicitly met. This is the best choice for most situations because the output is the most concise.

partial-match—No related debug output is filtered until there is a single explicit match failure. As long as zero or more conditions are met, debug output is not filtered. This choice is useful in debugging call startup problems like digit collection, but is not ideal for many situations because a large amount of debug output is generated before matches explicitly fail.

Note This command impacts all enabled debug commands that support call filtering.

Step 3 

debug mgcp {all | endpoint | endptdb | errors | events | gcfm | inout | media | src | state | voipcac}

Example:

Router# debug mgcp errors

Router# debug mgcp events

Router# debug mgcp endpoint aaln/s2/su0/1/1/10

Router# debug mgcp media

Enables the appropriate MGCP debug commands.

See the Cisco IOS Debug Command Reference for detailed descriptions of these debug commands.

Note When enabling MGCP debug commands, you can also set a trace level to further filter output based on the importance of the information. For information, see the "Enabling MGCP Debug Trace Levels" section.

Verifying the MGCP Debug Filtering Configuration

To verify debug filtering conditions, use the following commands:

show debug—Displays the debugs that are enabled.

show call filter components—Displays the components that register internally with the filtering module. This command shows which components are registered with the GCFM, which is the internal module that controls which components are filtered.

show call filter match-list—Displays the criteria set for the specified match list. It shows a list of all the match lists, shows which ones are enabled, and shows whether they are enabled for partial or exact matching.

See the Cisco IOS Voice Command Reference for more information about these commands.

Enabling MGCP Debug Trace Levels

Perform this procedure to enable trace levels for restricting MGCP debug output based on the priority of the information.

Restrictions

Trace levels are not supported for MGCP errors or packets debugging because all of the output from these commands is set to high priority.

SUMMARY STEPS

1. enable

2. debug mgcp tracelevel-default {critical | moderate | verbose}

3. debug mgcp endpoint endpoint-name {{all | events | media} [tracelevel {critical | moderate | verbose}] | {errors | packets}}

4. debug mgcp {all | endptdb | events | gcfm | inout | media | nas | parser | src | state | voipcac} [tracelevel {critical | moderate | verbose}]

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

enable

Example:

Router> enable

Enables privileged EXEC mode.

Enter your password if prompted.

Step 2 

debug mgcp tracelevel-default {critical | moderate | verbose}

Example:

Router# debug mgcp tracelevel-default critical

(Optional) Enables the trace level globally for all MGCP debug commands and endpoints.

critical—Only high priority debug information is displayed.

moderate—Medium and high priority debug information is displayed.

verbose—All debug information is displayed. This is the default trace level.

Step 3 

debug mgcp endpoint endpoint-name {{all | events | media} [tracelevel {critical | moderate | verbose}] | {errors | packets}}

Example:

Router# debug mgcp endpoint aaln/s2/su0/1/1/10

(Optional) Enables the trace level for a specific endpoint for events or media debug commands.

endpoint-name—Name of the MGCP endpoint for which to enable debugging. Must be a fully specified and supported endpoint.

Step 4 

debug mgcp {all | endptdb | events | gcfm | inout | media | nas | parser | src | state | voipcac} [tracelevel {critical | moderate | verbose}]

Example:

Router# debug mgcp events tracelevel critical

Router# debug mgcp state tracelevel moderate

Router# debug mgcp media moderate

(Optional) Enables the trace level for a specific MGCP debug command.

Configuration Examples for MGCP Call Centric Debug

This section contains the following examples:

Match-List Configuration for MGCP Debug Filtering: Example

Enabling MGCP Debug Filtering: Example

Match-List Configuration for MGCP Debug Filtering: Example

The following example shows a configuration with a match list defined to filter MGCP debug output.

Router# show running-config

Building configuration...

Current configuration : 2068 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
service internal
!
hostname Router
!
boot-start-marker
boot system flash:Router.ios.bin
boot-end-marker
!
logging buffered 10000000 debugging
enable secret 5 $1$abcd
enable password sample
!
no aaa new-model
!
resource policy
!
no network-clock-participate slot 1 
no network-clock-participate slot 2 
ip cef
!
!
!
no ip domain lookup
ip host callagenthost 192.168.1.200
voice-card 1
 no dspfarm
!
voice-card 2
 dspfarm
!
!
!
!
!
!
!
controller T1 1/0
 framing esf
 clock source internal
 linecode b8zs
 ds0-group 0 timeslots 1-24 type none service mgcp
!
controller T1 1/1
 shutdown
 framing esf
 clock source internal
 linecode b8zs
 ds0-group 0 timeslots 1-24 type none service mgcp
!
!
!
!
interface FastEthernet0/0
 ip address 192.168.1.79 255.255.255.0
 no ip mroute-cache
 speed auto
 half-duplex
 no cdp enable
!
interface FastEthernet0/1
 no ip address
 no ip mroute-cache
 shutdown
 duplex auto
 speed auto
 no cdp enable
!
!
ip http server
!
snmp-server community public RO
snmp-server enable traps tty
!
!
!
control-plane
!
!
!
call filter match-list 1 voice
 incoming media local ipv4 192.168.1.12
 outgoing media local ipv4 192.168.1.11
!
voice-port 1/0:0
!
voice-port 1/1:0
!
voice-port 2/0/0
!
voice-port 2/0/1
!
voice-port 2/0/2
!
voice-port 2/0/3
!
voice-port 2/1/0
!
voice-port 2/1/1
!
voice-port 2/1/2
!
voice-port 2/1/3
!
!
mgcp
mgcp call-agent callagenthost 7979 service-type mgcp version 1.0
mgcp package-capability mf-package
mgcp package-capability rtp-package
mgcp package-capability script-package
mgcp sdp simple
!
mgcp profile default
!
!
!
dial-peer voice 211 pots
 service mgcpapp
 port 2/1/1
!
dial-peer voice 213 pots
 service mgcpapp
 port 2/1/3
!
dial-peer voice 210 pots
 service mgcpapp
 port 2/1/0
!
dial-peer voice 200 pots
 service mgcpapp
 port 2/0/0
!
dial-peer voice 212 pots
 service mgcpapp
 port 2/1/2
!
!
line con 0
 exec-timeout 0 0
line aux 0
line vty 0 4
 password temp
 login
!
!
end

Enabling MGCP Debug Filtering: Example

The following example shows how to enable filtering and trace levels for MGCP debug output.

Router# debug condition match-list 1 exact-match
Router# debug mgcp tracelevel-default critical
Router# debug mgcp errors
Media Gateway Control Protocol errors debugging for all endpoints is on

Router# debug mgcp media
Media Gateway Control Protocol media events debugging for all endpoints is on, trace-level 
Critical

Router# debug mgcp state tracelevel verbose
Media Gateway Control Protocol state transition debugging for all endpoints is on, 
trace-level Verbose

Router# debug mgcp endpoint S1/ds1-0/1 events tracelevel moderate
Media Gateway Control Protocol events debugging for endpoint s1/ds1-0/1 is on, trace-level 
Moderate

Router# show debug

MGCP:
  Media Gateway Control Protocol media events debugging is on, trace level Critical
  Media Gateway Control Protocol errors debugging is on
  Media Gateway Control Protocol state transition debugging is on, trace level Verbose
MGCP: Event debugging for endpoint S1/DS1-0/1 is on, tracelevel is Moderate

Router# show call filter match-list
 
********************************************* 
call filter match-list 1 voice 
*********************************************
  incoming media local ipv4  192.168.1.12
  outgoing media local ipv4  192.168.1.11
debug condition match-list is set to EXACT_MATCH