-
Cisco IOS Voice Troubleshooting and Monitoring Guide
-
About Cisco IOS Software Documentation
-
Guide to Cisco IOS Voice Troubleshooting and Monitoring Features
- Troubleshooting Voice Overview
- Troubleshooting Voice Telephony
- Troubleshooting Voice Technologies
- Troubleshooting Telephony Applications
-
Troubleshooting Fax
- Monitoring the Voice Network
-
Cause Codes and Debug Values
-
Index
-
Table Of Contents
Troubleshooting H.323 Interfaces to the IP Network
Troubleshooting H.323 Gateway Call Routing and Dial Peers
Verifying Digits Received and Sent on the POTS Call Leg
Verifying End-to-End VoIP Signaling on the VoIP Call Leg
Troubleshooting H.323 Gateway Dial Tone
Troubleshooting H.323 Gateway Busy Tone
No DTMF Digits or Audio Passed on VoIP Calls to PSTN or PBX
No Busy Tone or Announcement Message Received When Placing VoIP Outbound Calls
Troubleshooting H.323 Gateway Ringback
No Ringback Tone on VoIP Toll-Bypass Calls
Troubleshooting H.323 Gateway One-Way or No Audio
Ensuring IP Routing Is Enabled on Cisco IOS Gateways
Binding the H.323 Signaling to a Specific IP Address
Checking That Answer Supervision Is Being Sent and Received Correctly From the Telco or Switch
Using the voice rtp send-recv Command to Establish Early Two-Way Audio
Checking cRTP Settings on a Link-by-Link Basis
Verifying Minimum Software Level for NAT on Cisco IOS Gateways
Disabling voice-fastpath on Cisco AS5350 and Cisco AS5400 Universal Gateways
Configurinng the VPN IP Address with SoftPhone
Using the Test Call Feature to Verify Voice Path
Information About the Test Call Feature
Test Call Command-Line Interface
Troubleshooting H.323 Gatekeeper Registration
Troubleshooting H.323 Gatekeeper Call Routing and Dial Peers
Troubleshooting H.323 Gatekeeper Bandwidth
Bandwidth Management Operation Overview
Configuring the Bandwidth Management Feature on the Cisco Gatekeeper
Using Gatekeeper show Commands to Display Bandwidth Information
Bandwidth-Related RAS Messages (BRQ, BCF, and BRJ)
Checking Cisco Gateway Failover to Alternate Gatekeeper
Troubleshooting Issues with Alternate Endpoints
Troubleshooting Gatekeeper Endpoint Call Admission Issues
Gateway-to-Gateway and Gatekeeper-to-Gateway Security
Troubleshooting H.323 Interfaces to the IP Network
This chapter provides troubleshooting information for the H.323 standard from the International Telecommunication Union Telecommunication Standardization Sector (ITU-T), of the following:
•
Cisco H.323-compliant gatekeeper
•
•
Cisco IOS software complies with the mandatory requirements and several of the optional features of the H.323 Version 2 specification. The chapter contains the following sections:
•
H.323 is a peer-to-peer protocol. H.323 uses messages similar to Q.931 messages to communicate between endpoints. Q.931 cause codes can be found in "Cause Codes and Debug Values".
Figure 38 shows a typical H.323 network. For detailed information on H.323, refer to Cisco IOS Call Control Technologies (H.323, SIP, and xGCP).
Figure 38 Gatekeeper in an H.323 Network
H.323-Related Standards
Because several standards are involved with setting up a call through an H.323 device, it is important to understand the role each protocol plays to be able to effectively troubleshoot such a call. The following sections describe these standards:
Figure 39 shows the basic call flow for an H.323 call.
Figure 39 H.323 Call Flow
H.225 Signaling
H.225 is used for call control functions. H.225 is very similar to Q.931. H.225 signaling is carried over a TCP connection. H.323 devices listen to port 1720 for incoming connections and show messages that might be used in an H.225 call setup, such as those shown in Table 47. Each message can contain one or more information element (IE). Each IE carries a specific piece of information within an H.225 message. For a complete list of IEs and the coding for each, refer to the ITU-T Q.931 specification.
H.245 Signaling
H.225 is responsible only for setting up the call and routing it to the proper destination. H.225 does not have any mechanism for exchanging capabilities or setting up and tearing down media streams. The called H.323 device is responsible for sending the IP address and port number that are used to establish the TCP connections for H.245 signaling. This information can be sent by the called device in either the Alerting or Connect message.
When the originating H.323 device receives the IP address and port number for H.245 negotiations, it initiates a second TCP connection to carry out the necessary capabilities exchange and logical channel negotiations. This TCP session is primarily used to do four things:
•
•
•
•
Troubleshooting Gateways
An H.323 gateway is an endpoint on the LAN that provides real-time communications between H.323 terminals on the LAN and other ITU terminals on a WAN or to other H.323 gateways.
Gateways allow H.323 terminals to communicate with devices that are running other protocols. They provide protocol conversion between the devices that are running different types of protocols. For example, Figure 40 shows a gateway between an H.323 terminal and a non-H.323 terminal.
Figure 40 Gateway Between an H.323 Terminal and an H.320 Terminal
This section contains the following information:
•
•
•
•
•
•
Troubleshooting H.323 Gateway Call Routing and Dial Peers
To troubleshoot H.323 call routing, see the following sections:
•
•
Verifying Digits Received and Sent on the POTS Call Leg
Once the on-hook and off-hook signaling are verified to be working correctly, the next step in troubleshooting and debugging a VoIP call is to verify that the correct digits are being received or sent on the voice-port (digital or analog). A dial peer is not matched or the switch (CO or PBX) is not able to ring the correct station if incomplete or incorrect digits are being sent or received. Some commands that can be used to verify the digits received/sent are:
•
•
•
•
show dialplan number
The show dialplan number digit_string command displays the dial peer that is matched by a string of digits. If multiple dial peers can be matched, they are all shown in the order in which they are matched. The output of this command looks like this:
Router# show dialplan number 5000Macro Exp.: 5000VoiceOverIpPeer2information type = voice,tag = 2, destination-pattern = `5000',answer-address = `', preference=0,group = 2, Admin state is up, Operationstate is up,incoming called-number = `',connections/maximum = 0/unlimited,application associated:type = voip, session-target =`ipv4:192.168.10.2',technology prefix:ip precedence = 5, UDP checksum =disabled, session-protocol = cisco,req-qos = best-effort,acc-qos = best-effort,dtmf-relay = cisco-rtp,fax-rate = voice,payload size = 20 bytescodec = g729r8,payload size = 20 bytes,Expect factor = 10, Icpif = 30,signaling-type = cas,VAD = enabled, Poor QOV Trap = disabled,Connect Time = 25630, Charged Units = 0,Successful Calls = 25, Failed Calls = 0,Accepted Calls = 25, Refused Calls = 0,Last Disconnect Cause is "10 ",Last Disconnect Text is "normal callclearing.",Last Setup Time = 84427934.Matched: 5000 Digits: 4Target: ipv4:192.168.10.2debug vtsp dsp
debug vtsp dsp shows the digits as they are received by the voice port. The following output example shows the collection of DTMF digits from the DSP:
Router# debug vtsp dspVoice telephony call control dsp debugging is on!-- ACTION: Caller picked up handset and dialed!-- digits 5000.!-- The DSP detects DTMF digits. Digit 5 was!-- detected with ON time of 130msec.*Mar 10 17:57:08.505: vtsp_process_dsp_message:MSG_TX_DTMF_DIGIT_BEGIN: digit=5,*Mar 10 17:57:08.585: vtsp_process_dsp_message:MSG_TX_DTMF_DIGIT_OFF: digit=5,duration=130*Mar 10 17:57:09.385: vtsp_process_dsp_message:MSG_TX_DTMF_DIGIT_BEGIN: digit=0*Mar 10 17:57:09.485: vtsp_process_dsp_message:MSG_TX_DTMF_DIGIT_OFF: digit=0,duration=150*Mar 10 17:57:10.697: vtsp_process_dsp_message:MSG_TX_DTMF_DIGIT_BEGIN: digit=0*Mar 10 17:57:10.825: vtsp_process_dsp_message:MSG_TX_DTMF_DIGIT_OFF: digit=0,duration=180*Mar 10 17:57:12.865: vtsp_process_dsp_message:MSG_TX_DTMF_DIGIT_BEGIN: digit=0*Mar 10 17:57:12.917: vtsp_process_dsp_message:MSG_TX_DTMF_DIGIT_OFF: digit=0,duration=100debug vtsp session
debug vtsp session shows the activity on the voice port. The following output example shows the handset being picked up and dial tone generated:
Router# debug vtsp sessionVoice telephony call control session debugging is on!--- <some output have been omitted>!-- ACTION: Caller picked up handset.!-- The DSP is allocated, jitter buffers, VAD!-- thresholds, and signal levels are set.*Mar 10 18:14:22.865: dsp_set_playout: [1/0/0 (69)]packet_len=18 channel_id=1 packet_id=76 mode=1initial=60 min=4 max=200 fax_nom=300*Mar 10 18:14:22.865: dsp_echo_canceller_control:[1/0/0 (69)] packet_len=10 channel_id=1 packet_id=66flags=0x0*Mar 10 18:14:22.865: dsp_set_gains: [1/0/0 (69)]packet_len=12 channel_id=1 packet_id=91in_gain=0 out_gain=65506*Mar 10 18:14:22.865: dsp_vad_enable: [1/0/0 (69)]packet_len=10 channel_id=1 packet_id=78thresh=-38act_setup_ind_ack*Mar 10 18:14:22.869: dsp_voice_mode: [1/0/0 (69)]packet_len=24 channel_id=1 packet_id=73 coding_type=1voice_field_size=80VAD_flag=0 echo_length=64 comfort_noise=1inband_detect=1 digit_relay=2AGC_flag=0act_setup_ind_ack(): dsp_dtmf_mode()act_setup_ind_ack: passthru_mode = 0,no_auto_switchover = 0dsp_dtmf_mode(VTSP_TONE_DTMF_MODE)!-- The DSP is put into "voice mode" and dial-tone is!-- generated.*Mar 10 18:14:22.873: dsp_cp_tone_on: [1/0/0 (69)]packet_len=30 channel_id=1 packet_id=72 tone_id=4n_freq=2 freq_of_first=350 freq_of_second=440 amp_of_first=4000 amp_of_second=4000 direction=1 on_time_first=65535off_time_first=0 on_time_second=65535 off_time_second=0If you find that the digits are not being sent or received properly, you might need to use either a digit-grabber (test tool) or T1 tester to verify the digits are being sent at the correct frequency and timing interval. If they are being sent incorrectly for the switch (CO or PBX), some values on the router or switch (CO or PBX) might need to be adjusted so that they match and can interoperate. These are usually digit duration and interdigit duration values. If the digits appear to be sent correctly you might want to examine any number translation tables in the switch (CO or PBX) that might add or remove digits.
Verifying End-to-End VoIP Signaling on the VoIP Call Leg
After verifying that voice-port signaling is working properly and the correct digits have been received, verify that the end-to-end VoIP signaling is set up on the VoIP call leg.VoIP signaling involves call control. The following factors explain why call control debugging can become a complex job:
•
•
•
debug voip ccapi inout
The primary command to debug end-to-end VoIP calls is debug voip ccapi inout. The output from a sample call debug is shown below.
Router# debug voip ccapi inout*Mar 1 15:35:53.588: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructTDUsrContainer: usrContainer[0x638C1BF0], magic[FACE0FFF]*Mar 1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x638C1BF0, tagID=6, dataSize=16, instID=-1,modifier=1*Mar 1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: tdObject[0x638BC1AC], nxtElem[0x0], magic[0xFACE0FFF] tagID[6], dataLen[16], modif[1]*Mar 1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding tdObject[0x638BC1AC] instID[-1] into container[0x638C1BF0]*Mar 1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDUtilAddDataToUsrContainer: container=0x638C1BF0, tagID=5, dataSize=276, instID=-1,modifier=1*Mar 1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructInstanceTDObject: tdObject[0x63401148], nxtElem[0x0], magic[0xFACE0FFF] tagID[5], dataLen[276], modif[1]*Mar 1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToContainer: Adding tdObject[0x63401148] instID[-1] into container[0x638C1BF0]In the following lines, the call control API (CCAPI) receives the call setup. The called number is 34999, and the calling number is 55555. The calling number matches dial peer 10002.
*Mar 1 15:35:53.592: //-1/xxxxxxxxxxxx/CCAPI/cc_api_display_ie_subfields:*Mar 1 15:35:53.592: cc_api_call_setup_ind:*Mar 1 15:35:53.592: cisco-username=*Mar 1 15:35:53.596: ----- ccCallInfo IE subfields -----*Mar 1 15:35:53.596: cisco-ani=55555*Mar 1 15:35:53.596: cisco-anitype=0*Mar 1 15:35:53.596: cisco-aniplan=0*Mar 1 15:35:53.596: cisco-anipi=0*Mar 1 15:35:53.596: cisco-anisi=0*Mar 1 15:35:53.596: dest=34999*Mar 1 15:35:53.596: cisco-desttype=0*Mar 1 15:35:53.596: cisco-destplan=0*Mar 1 15:35:53.596: cisco-rdn=*Mar 1 15:35:53.596: cisco-rdntype=-1*Mar 1 15:35:53.596: cisco-rdnplan=-1*Mar 1 15:35:53.596: cisco-rdnpi=-1*Mar 1 15:35:53.596: cisco-rdnsi=-1*Mar 1 15:35:53.596: cisco-redirectreason=-1*Mar 1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: (vdbPtr=0x637EC1E0, callInfo={called=34999,called_oct3=0x80,calling=55555,calling_oct3=0x80,calling_oct3a=0x0,calling_xlated=false,subscriber_type_str=RegularLine,fdest=1,peer_tag=10002, prog_ind=0,callingIE_present 1, src_route_label=, tgt_route_label= clid_transparent=0},callID=0x637B4278)*Mar 1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind:*Mar 1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/cc_api_call_setup_ind: type 13 , prot 0*Mar 1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:*Mar 1 15:35:53.596: ccCheckClipClir: calling number is: "55555", calling oct3ais: 0x0*Mar 1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:*Mar 1 15:35:53.596: Calling Party number is User Provided*Mar 1 15:35:53.596: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:*Mar 1 15:35:53.596: Leaving ccCheckClipClircalling number is: "55555"calling oct3 is: 0x80calling oct3a is: 0x0In the next line, 44 is the CallEntry ID.
*Mar 1 15:35:53.600: //44/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: Increment call volume: 0*Mar 1 15:35:53.600: //44/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: current callvolume: 1*Mar 1 15:35:53.600: //44/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: entry's incoming TRUE.*Mar 1 15:35:53.600: //44/xxxxxxxxxxxx/CCAPI/cc_insert_call_entry: is_incomingis TRUE*Mar 1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDConstructHashProfileTab: profileTable[0x6380E11C], numBuckets[11], numEntries[0]*Mar 1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager: Invoking necessary profileTable updaters...*Mar 1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: Updating profileTable[0x6380E11C] with objects in container[0x638C1BF0]*Mar 1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: obtained key[5] for the tag[6]*Mar 1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: profileTable[0x6380E11C], tdObject[0x638BC1AC]*Mar 1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtUpdateProfileTabFromContainer: obtained key[0] for the tag[5]*Mar 1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtAddObjectToProfileBucket: profileTable[0x6380E11C], tdObject[0x63401148]*Mar 1 15:35:53.600: //-1/xxxxxxxxxxxx/CCAPI/ccTDPvtProfileTableBuildManager:*Mar 1 15:35:53.600: ccTDUtilDumpAllElemInProfileTab: profileTable[0x6380E11C],numBuckets[11], numEntries[2]*Mar 1 15:35:53.600: Bucket { 0 } ------>0x63401148[0x0,t-5,l-276,d-0x63401168,m-1,u-56153,g-FACE0FFF]*Mar 1 15:35:53.604:*Mar 1 15:35:53.604: Bucket { 5 } ------>0x638BC1AC[0x0,t-6,l-16,d-0x638BC1CC,m-1,u-56153,g-FACE0FFF]*Mar 1 15:35:53.604:*Mar 1 15:35:53.604: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDUsrContainer: Container[0x638C1BF0]*Mar 1 15:35:53.604: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: not the VoIP or MMoIP*Mar 1 15:35:53.608: //-1/xxxxxxxxxxxx/CCAPI/cc_process_call_setup_ind: (event=0x63073AA0)In the next line, 45F2AAE28044 is the GUID. The tag 10002 entry shows that the incoming dial-peer matched the CallEntry ID.
*Mar 1 15:35:53.608: //44/45F2AAE28044/CCAPI/cc_process_call_setup_ind: >>>>CCAPI handed cid 44 with tag 10002 to app "DEFAULT"*Mar 1 15:35:53.608: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(44), disp(0)*Mar 1 15:35:53.608: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(44), disp(0)*Mar 1 15:35:53.608: //44/xxxxxxxxxxxx/SSAPP:-1:-1/ssaCallSetupInd:The next line shows CallEntry ID in hexadecimal form, 0x2C (44 in decimal). The CallID and GUID numbers have been identified. The incoming dial-peer is 10002.
*Mar 1 15:35:53.608: //44/xxxxxxxxxxxx/CCAPI/ccCallSetContext: (callID=0x2C, context=0x634A430C)*Mar 1 15:35:53.608: //44/45F2AAE28044/SSAPP:10002:-1/ssaCallSetupInd: cid(44),st(SSA_CS_MAPPING),oldst(0), ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag= 1*Mar 1 15:35:53.608: //44/45F2AAE28044/SSAPP:10002:-1/ssaCallSetupInd: src route label=, tgt route label= tg_label_flag 0x0*Mar 1 15:35:53.608: //44/45F2AAE28044/SSAPP:10002:-1/ssaCallSetupInd: finalDest cllng(55555), clled(34999) tgt_route_label()tg_label_flag 0x0*Mar 1 15:35:53.612: //44/45F2AAE28044/SSAPP:10002:-1/ssaCallSetupInd: cid(44),st(SSA_CS_CALL_SETTING),oldst(0), ev(24)dpMatchPeersMoreArg result= 0For CallEntry ID 44, two dial-peer tags (10001 and 20002) were matched with called number 34999.
*Mar 1 15:35:53.612: //44/45F2AAE28044/SSAPP:10002:-1/ssaDebugPeers: ssaSetupPeer cid(44) peer list: tag(10001) called number (34999) tag(20002) called number(34999)*Mar 1 15:35:53.612: //44/45F2AAE28044/SSAPP:10002:-1/ssaSetupPeer: dialpeer tags in rotary= 10001 20002The next line shows that 5 digits were matched for this dial-peer and no prefix was added. The encapType (2) entry indicates a VoIP call.
*Mar 1 15:35:53.612: //44/45F2AAE28044/SSAPP:10002:-1/ssaSetupPeer: cid(44), destPat(34999), matched(5), prefix(), peer(637B0984), peer->encapType (2)*Mar 1 15:35:53.612: //-1/xxxxxxxxxxxx/CCAPI/cc_can_gateway: Call legs: In=6, Out=1The next line shows the voice gateway sending out a call-proceeding message to the incoming call leg with progress indicator of 0x0.
*Mar 1 15:35:53.612: //44/xxxxxxxxxxxx/CCAPI/ccCallProceeding: (callID=0x2C, prog_ind=0x0)The next line shows the voice gateway sending out the call-setup request to the outgoing call leg. The dial-peer is 10001 with the incoming CallEntry ID being 0x2C.
*Mar 1 15:35:53.612: //44/xxxxxxxxxxxx/CCAPI/ccCallSetupRequest: (Inbound call= 0x2C, outbound peer =10001, dest=,params=0x63085D80 mode=0, *callID=0x63086314, prog_ind = 0callingIE_present 1)*Mar 1 15:35:53.612: //44/45F2AAE28044/CCAPI/ccCallSetupRequest:*Mar 1 15:35:53.612: ccCallSetupRequest numbering_type 0x80*Mar 1 15:35:53.612: //44/45F2AAE28044/CCAPI/ccCallSetupRequest:*Mar 1 15:35:53.616: ccCallSetupRequest: calling number is:55555*Mar 1 15:35:53.616: //44/45F2AAE28044/CCAPI/ccCallSetupRequest: calling oct3ais:0x0*Mar 1 15:35:53.616: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:*Mar 1 15:35:53.616: ccCheckClipClir: calling number is: "55555", calling oct3ais: 0x0*Mar 1 15:35:53.616: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:*Mar 1 15:35:53.616: Calling Party number is User Provided*Mar 1 15:35:53.616: //-1/xxxxxxxxxxxx/CCAPI/ccCheckClipClir:*Mar 1 15:35:53.616: Leaving ccCheckClipClircalling number is: "55555"calling oct3 is: 0x80calling oct3a is: 0x0*Mar 1 15:35:53.616: //44/45F2AAE28044/CCAPI/ccCallSetupRequest: after ccCheckClipClir - calling oct3a is:0x0The next line shows that all digits are passed.
*Mar 1 15:35:53.616: //44/45F2AAE28044/CCAPI/ccCallSetupRequest: dest pattern 34999, called 34999, digit_strip 0*Mar 1 15:35:53.616: //44/45F2AAE28044/CCAPI/ccCallSetupRequest:*Mar 1 15:35:53.616: callingNumber=55555, calledNumber=34999, redirectNumber= display_info= calling_oct3a=0*Mar 1 15:35:53.616: accountNumber=, finalDestFlag=1,guid=45f2.aae2.1571.11cc.8044.95f5.fabb.6b0f*Mar 1 15:35:53.616: peer_tag=10001*Mar 1 15:35:53.616: //-1/xxxxxxxxxxxx/CCAPI/cc_api_display_ie_subfields:*Mar 1 15:35:53.616: ccCallSetupRequest:*Mar 1 15:35:53.616: cisco-username=*Mar 1 15:35:53.616: ----- ccCallInfo IE subfields -----*Mar 1 15:35:53.616: cisco-ani=55555*Mar 1 15:35:53.616: cisco-anitype=0*Mar 1 15:35:53.616: cisco-aniplan=0*Mar 1 15:35:53.616: cisco-anipi=0*Mar 1 15:35:53.616: cisco-anisi=0*Mar 1 15:35:53.620: dest=34999*Mar 1 15:35:53.620: cisco-desttype=0*Mar 1 15:35:53.620: cisco-destplan=0*Mar 1 15:35:53.620: cisco-rdn=*Mar 1 15:35:53.620: cisco-rdntype=-1*Mar 1 15:35:53.620: cisco-rdnplan=-1*Mar 1 15:35:53.620: cisco-rdnpi=-1*Mar 1 15:35:53.620: cisco-rdnsi=-1*Mar 1 15:35:53.620: cisco-redirectreason=-1*Mar 1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: (vdbPtr=0x62EC61A4, dest=, callParams={called=34999,called_oct3=0x80, calling=55555,calling_oct3=0x80, calling_oct3a= 0x0, calling_xlated=false, subscriber_type_str=RegularLine, fdest=1, voice_peer_tag=10001},mode=0x0)*Mar 1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:*Mar 1 15:35:53.620: ccIFCallSetupRequestPrivate: src route label tgt route label tg_label_flag 0x0*Mar 1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: vdbPtr type = 1*Mar 1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:*Mar 1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate: (vdbPtr=0x62EC61A4, dest=, callParams={called=34999, called_oct3 0x80, calling=55555,calling_oct3 0x80, calling_oct3a 0x0, calling_xlated=false, fdest=1, voice_peer_tag=10001}, mode=0x0, xltrc=-5)*Mar 1 15:35:53.620: //-1/xxxxxxxxxxxx/CCAPI/ccIFCallSetupRequestPrivate:In the next line, outgoing CallEntry ID 45 is bound to the same GUID 45F2AAE28044.
*Mar 1 15:35:53.620: //45/45F2AAE28044/CCAPI/cc_insert_call_entry: not incomingentry*Mar 1 15:35:53.620: //45/45F2AAE28044/CCAPI/cc_insert_call_entry: entry's incoming FALSE.*Mar 1 15:35:53.620: //45/45F2AAE28044/CCAPI/cc_insert_call_entry: is_incomingis FALSE*Mar 1 15:35:53.624: //44/xxxxxxxxxxxx/CCAPI/ccSaveDialpeerTag: (callID=0x2C, dialpeer_tag=10001)*Mar 1 15:35:53.624: //45/xxxxxxxxxxxx/CCAPI/ccCallSetContext: (callID=0x2D, context=0x634A537C) 0x2D (decimal 45 is the second call leg ID).*Mar 1 15:35:53.624: //44/xxxxxxxxxxxx/CCAPI/ccCallReportDigits: (callID=0x2C,enable=0x0)The voice gateway informs the incoming call leg that digits were forwarded.
*Mar 1 15:35:53.624: //44/xxxxxxxxxxxx/CCAPI/cc_api_call_report_digits_done: (vdbPtr=0x637EC1E0, callID=0x2C, disp=0)*Mar 1 15:35:53.624: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(54=CC_EV_CALL_REPORT_DIGITS_DONE), cid(44), disp(0)*Mar 1 15:35:53.624: //44/45F2AAE28044/SSRouter#APP:10002:-1/ssaTraceSct: cid(44)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_REPORT_DIGITS_DONE)oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(1)*Mar 1 15:35:53.624: //44/45F2AAE28044/SSAPP:10002:-1/ssaTraceSct: -cid2(45)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_MAPPING)*Mar 1 15:35:53.624: //44/45F2AAE28044/SSAPP:10002:-1/ssaDebugPeers: ssaReportDigitsDone cid(44) peer list: tag(20002) called number (34999)*Mar 1 15:35:53.624: //44/45F2AAE28044/SSAPP:10002:-1/ssaReportDigitsDone: callid=44 Reporting disabled.*Mar 1 15:35:53.628: //-1/xxxxxxxxxxxx/CCAPI/cc_api_supported_data: data_mode=0x10082*Mar 1 15:35:53.628: //45/xxxxxxxxxxxx/CCAPI/cc_api_get_ic_leg_obtained_numbers: callID=0x2DThe next two lines show the IP address of the terminating gateway and indicate that the terminating gateway is reached through Ethernet port 0/0.
*Mar 1 15:35:53.628: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: remote IPis 171.69.85.111*Mar 1 15:35:53.632: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: hwidb is Ethernet0/0*Mar 1 15:35:53.632: //-1/xxxxxxxxxxxx/CCAPI/cc_incr_if_call_volume: create entry in list: 1*Mar 1 15:35:53.636: //45/xxxxxxxxxxxx/CCAPI/ccTDUtilGetInstanceCount: For tagID[1] of callID[45]*Mar 1 15:35:53.636: //45/45F2AAE28044/CCAPI/ccTDPvtProfileTableObjectAccessManager: No profileTable set for callID[45]*Mar 1 15:35:53.636: //45/xxxxxxxxxxxx/CCAPI/ccTDUtilGetInstanceCount: For tagID[2] of callID[45]*Mar 1 15:35:53.636: //45/45F2AAE28044/CCAPI/ccTDPvtProfileTableObjectAccessManager: No profileTable set for callID[45]The next line shows that the voice gateway received a call proceeding message from the terminating gateway. The line after that shows that the voice gateway received a call alert from the terminating gateway.
*Mar 1 15:35:53.740: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_proceeding: (vdbPtr=0x62EC61A4, callID=0x2D,prog_ind=0x0)*Mar 1 15:35:53.740: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_alert: (vdbPtr=0x62EC61A4, callID=0x2D, prog_ind=0x0, sig_ind=0x1)*Mar 1 15:35:53.744: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(21=CC_EV_CALL_PROCEEDING), cid(45), disp(0)*Mar 1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: cid(45)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_PROCEEDING)oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(0)fDest(0)*Mar 1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: -cid2(44)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)*Mar 1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaCallProc:*Mar 1 15:35:53.744: //44/xxxxxxxxxxxx/CCAPI/ccGetDialpeerTag: (callID=0x2C)*Mar 1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaIgnore: cid(45), st(SSA_CS_CALL_SETTING),oldst(1), ev(21)*Mar 1 15:35:53.744: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(7=CC_EV_CALL_ALERT), cid(45), disp(0)*Mar 1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: cid(45)st(SSA_CS_CALL_SETTING)ev(SSA_EV_CALL_ALERT)oldst(SSA_CS_CALL_SETTING)cfid(-1)csize(0)in(0)fDest(0)*Mar 1 15:35:53.744: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: -cid2(44)st2(SSA_CS_CALL_SETTING)oldst2(SSA_CS_CALL_SETTING)*Mar 1 15:35:53.744: //44/45F2AAE28044/SSAPP:10002:-1/ssaAlert:*Mar 1 15:35:53.744: //44/xxxxxxxxxxxx/CCAPI/ccGetDialpeerTag: (callID=0x2C)Router#The voice gateway forwarded a call alert to the originating gateway.
*Mar 1 15:35:53.744: //44/xxxxxxxxxxxx/CCAPI/ccCallAlert: (callID=0x2C, prog_ind=0x0, sig_ind=0x1)Router#The phone is answered at the called number.
Router#!call answeredRouter#The voice gateway receives a connect message from the terminating gateway.
*Mar 1 15:36:05.016: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_connected: (vdbPtr=0x62EC61A4, callID=0x2D), prog_ind = 0*Mar 1 15:36:05.016: //45/45F2AAE28044/CCAPI/cc_api_call_connected: setting callEntry->connected to TRUEThe next line shows that the call accounting starts. The leg_type=False message means that message is for an outgoing call. The line that follows shows that AAA accounting is not configured.
*Mar 1 15:36:05.016: //45/45F2AAE28044/CCAPI/cc_api_call_connected: calling accounting start for callID=45 leg_type=0*Mar 1 15:36:05.020: //45/xxxxxxxxxxxx/CCAPI/ccCallSetAAA_Accounting: callID=0x2D, accounting=0*Mar 1 15:36:05.020: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(8=CC_EV_CALL_CONNECTED), cid(45), disp(0)*Mar 1 15:36:05.020: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: cid(45)st(SSA_CS_ALERT_RCVD)ev(SSA_EV_CALL_CONNECTED)oldst(SSA_CS_CALL_SETTING)cfid(-1)csize(0)in(0)fDest(0)*Mar 1 15:36:05.020: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: -cid2(44)st2(SSA_CS_ALERT_RCVD)oldst2(SSA_CS_CALL_SETTING)*Mar 1 15:36:05.020: //45/45F2AAE28044/SSAPP:0:-1/ssaConnect:*Mar 1 15:36:05.020: //44/xxxxxxxxxxxx/CCAPI/ccGetDialpeerTag: (callID=0x2C)The next lines show a conference being set up between the two call legs 0x2C and 0x2D. Bridge complete messages are sent to both the terminating and originating gateways.
*Mar 1 15:36:05.020: //44/xxxxxxxxxxxx/CCAPI/ccConferenceCreate: (confID=0x63086424, callID1=0x2C, callID2=0x2D, tag=0x0)*Mar 1 15:36:05.020: //45/xxxxxxxxxxxx/CCAPI/cc_api_bridge_done: (confID=0x15,srcIF=0x62EC61A4, srcCallID=0x2D, dstCallID=0x2C, disposition=0, tag=0x0)*Mar 1 15:36:05.024: //44/xxxxxxxxxxxx/CCAPI/cc_api_bridge_done: (confID=0x15,srcIF=0x637EC1E0, srcCallID=0x2C, dstCallID=0x2D, disposition=0, tag=0x0)Here, the voice gateway sets up negotiating capability with the originating telephony leg.
*Mar 1 15:36:05.024: //44/xxxxxxxxxxxx/CCAPI/cc_api_caps_ind: (dstVdbPtr=0x62EC61A4, dstCallId=0x2D, srcCallId=0x2C,caps={codec=0x2887F, fax_rate=0xBF, vad=0x3, modem=0x2codec_bytes=0, signal_type=3})*Mar 1 15:36:05.024: //44/xxxxxxxxxxxx/CCAPI/cc_api_caps_ind: (Playout: mode 0,initial 60,min 40, max 300)*Mar 1 15:36:05.024: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(29=CC_EV_CONF_CREATE_DONE), cid(44), disp(0)*Mar 1 15:36:05.024: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: cid(44)st(SSA_CS_CONFERENCING)ev(SSA_EV_CONF_CREATE_DONE)oldst(SSA_CS_CALL_SETTING)cfid(21)csize(2)in(1)fDest(1)*Mar 1 15:36:05.024: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: -cid2(45)st2(SSA_CS_CONFERENCING)oldst2(SSA_CS_ALERT_RCVD)*Mar 1 15:36:05.024: //44/45F2AAE28044/SSAPP:10002:21/ssaConfCreateDone:*Mar 1 15:36:05.024: //44/xxxxxxxxxxxx/CCAPI/ccCallConnect: (callID=0x2C), prog_ind = 0*Mar 1 15:36:05.024: //44/45F2AAE28044/CCAPI/ccCallConnect: setting callEntry->connected to TRUE*Mar 1 15:36:05.024: //44/45F2AAE28044/SSAPP:10002:21/ssaDebugPeers: ssaFlushPeerTagQueue cid(44) peer list: tag(20002) called number (34999)*Mar 1 15:36:05.028: //-1/xxxxxxxxxxxx/CCAPI/cc_process_notify_bridge_done: (event=0x63067FC0)The voice gateway sets up negotiating capability with the terminating VoIP leg.
*Mar 1 15:36:05.028: //45/xxxxxxxxxxxx/CCAPI/cc_api_caps_ind: (dstVdbPtr=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x0codec_bytes=20, signal_type=2})*Mar 1 15:36:05.028: //45/xxxxxxxxxxxx/CCAPI/cc_api_caps_ind: (Playout: mode 0,initial 60,min 40, max 300)The capabilities are acknowledged for both call legs.
*Mar 1 15:36:05.028: //45/xxxxxxxxxxxx/CCAPI/cc_api_caps_ack: (dstVdbPtr=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x0codec_bytes=20, signal_type=2, seq_num_start=2944})*Mar 1 15:36:05.028: //44/xxxxxxxxxxxx/CCAPI/cc_api_caps_ack: (dstVdbPtr=0x62EC61A4, dstCallId=0x2D, srcCallId=0x2C,caps={codec=0x4, fax_rate=0x2, vad=0x2, modem=0x0codec_bytes=20, signal_type=2, seq_num_start=2944})*Mar 1 15:36:05.032: //44/xxxxxxxxxxxx/CCAPI/cc_api_voice_mode_event: callID=0x2C*Mar 1 15:36:05.032: //44/45F2AAE28044/CCAPI/cc_api_voice_mode_event: Call Pointer =634A430C*Mar 1 15:36:05.032: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(52=CC_EV_VOICE_MODE_DONE), cid(44), disp(0)*Mar 1 15:36:05.032: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct:Router#Router#cid(44)st(SSA_CS_ACTIVE)ev(SSA_EV_VOICE_MODE_DONE)oldst(SSA_CS_CONFERENCING)cfid(21)csize(2)in(1)fDest(1)*Mar 1 15:36:05.032: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: -cid2(45)st2(SSA_CS_ACTIVE)oldst2(SSA_CS_ALERT_RCVD)*Mar 1 15:36:05.032: //44/45F2AAE28044/SSAPP:10002:21/ssaIgnore: cid(44), st(SSA_CS_ACTIVE),oldst(5), ev(52)Router#Router#! digit punchedRouter#The phone at the terminating gateway enters digit 1.
*Mar 1 15:36:11.204: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPtr=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,digit=1, digit_begin_flags=0x0, rtp_timestamp=0x0rtp_expiration=0x0, dest_mask=0x2)*Mar 1 15:36:11.504: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,digit=1,duration=300,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x2), digit_tone_mode=0The phone at the terminating gateway enters digit 2.
*Mar 1 15:36:11.604: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin: (dstVdbPtr=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,digit=2, digit_begin_flags=0x0, rtp_timestamp=0x0rtp_expiration=0x0, dest_mask=0x2)*Mar 1 15:36:11.904: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end: (dstVdbPtr=0x637EC1E0, dstCallId=0x2C, srcCallId=0x2D,digit=2,duration=300,xruleCallingTag=0,xruleCalledTag=0, dest_mask=0x2), digit_tone_mode=0Router#Router#*Mar 1 15:36:14.476: //-1/xxxxxxxxxxxx/CCAPI/cc_handle_periodic_timer: Callingthe callback, ccTimerctx - 0x628B6330*Mar 1 15:36:14.476: //-1/xxxxxxxxxxxx/CCAPI/ccTimerStart: ccTimerctx - 0x628B6330Router#Router#!call hung up The user at the terminating gateway hangs up the call.Router#The voice gateway receives a disconnect message from the terminating gateway. The cause code is 0x10 which is normal call clearing.
*Mar 1 15:36:22.916: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnected: (vdbPtr=0x62EC61A4, callID=0x2D, cause=0x10)*Mar 1 15:36:22.920: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(11=CC_EV_CALL_DISCONNECTED), cid(45), disp(0)*Mar 1 15:36:22.920: //45/45F2AAE28044/SSAPP:0:21/ssaTraceSct: cid(45)st(SSA_CS_ACTIVE)ev(SSA_EV_CALL_DISCONNECTED)oldst(SSA_CS_ALERT_RCVD)cfid(21)csize(2)in(0)fDest(0)*Mar 1 15:36:22.920: //45/45F2AAE28044/SSAPP:0:21/ssaTraceSct: -cid2(44)st2(SSA_CS_ACTIVE)oldst2(SSA_CS_ACTIVE)*Mar 1 15:36:22.920: ssa: Disconnected cid(45) state(5) cause(0x10)The voice gateway begins tearing down the conference and dropping the bridge.
*Mar 1 15:36:22.920: //-1/xxxxxxxxxxxx/CCAPI/ccConferenceDestroy: (confID=0x15,tag=0x0)*Mar 1 15:36:22.920: //45/xxxxxxxxxxxx/CCAPI/cc_api_bridge_drop_done: (confID=0x15, srcIF=0x62EC61A4, srcCallID=0x2D, dstCallID=0x2C, disposition=0 tag=0x0)*Mar 1 15:36:22.920: //44/xxxxxxxxxxxx/CCAPI/cc_api_bridge_drop_done: (confID=0x15, srcIF=0x637EC1E0, srcCallID=0x2C, dstCallID=0x2D, disposition=0 tag=0x0)*Mar 1 15:36:22.924: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(30=CC_EV_CONF_DESTROY_DONE), cid(44), disp(0)*Mar 1 15:36:22.924: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: cid(44)st(SSA_CS_CONF_DESTROYING)ev(SSA_EV_CONF_DESTROY_DONE)oldst(SSA_CS_ACTIVE)cfid(21)csize(2)in(1)fDest(1)*Mar 1 15:36:22.924: //44/45F2AAE28044/SSAPP:10002:21/ssaTraceSct: -cid2(45)st2(SSA_CS_CONF_DESTROYING)oldst2(SSA_CS_ACTIVE)*Mar 1 15:36:22.924: //45/45F2AAE28044/SSAPP:0:-1/ssaConfDestroyDone:*Mar 1 15:36:22.924: //44/xxxxxxxxxxxx/CCAPI/ccCallDisconnect: (callID=0x2C, cause=0x10 tag=0x0)The voice gateway stops call accounting on the incoming call, indicated by the leg_type=True message. The cause code is then set for the originating leg.
*Mar 1 15:36:22.924: //44/45F2AAE28044/CCAPI/ccCallDisconnect: calling accounting start for callID=44 leg_type=1*Mar 1 15:36:22.924: //44/45F2AAE28044/CCAPI/ccCallDisconnect: existing_cause =0x0, new_cause = 0x10*Mar 1 15:36:22.924: //44/xxxxxxxxxxxx/CCAPI/cc_api_get_transfer_info: (callID=0x2C)*Mar 1 15:36:22.924: //45/xxxxxxxxxxxx/CCAPI/ccCallDisconnect: (callID=0x2D, cause=0x10 tag=0x0)The voice gateway stops call accounting for the outgoing call, indicated by the leg_type=False message. The cause code is verified for the terminating leg.
*Mar 1 15:36:22.924: //45/45F2AAE28044/CCAPI/ccCallDisconnect: calling accounting start for callID=45 leg_type=0*Mar 1 15:36:22.924: //45/45F2AAE28044/CCAPI/ccCallDisconnect: existing_cause =0x10, new_cause = 0x10*Mar 1 15:36:22.924: //45/45F2AAE28044/CCAPI/ccCallDisconnect: using the existing_cause 0x10*Mar 1 15:36:22.928: //45/xxxxxxxxxxxx/CCAPI/cc_api_get_transfer_info: (callID=0x2D)*Mar 1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_api_icpif: expect factor = 0*Mar 1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/g113_calculate_impairment: (delay=79,loss=0), Io=0 Iq=0 Idte=0 Idd=0 Ie=10 Itot=10*Mar 1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: the remoteIP is 171.69.85.111*Mar 1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: hwidb is Ethernet0/0*Mar 1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: reduce callnum of entry: 0, voip: 0, mmoip: 0*Mar 1 15:36:22.932: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: remove anentry*Mar 1 15:36:22.932: //45/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnect_done: (vdbPtr=0x62EC61A4, callID=0x2D, disp=0, tag=0x0)*Mar 1 15:36:22.932: //45/45F2AAE28044/CCAPI/ccTDPvtProfileTableObjectAccessManager: No profileTable set for callID[45]*Mar 1 15:36:22.936: //45/xxxxxxxxxxxx/CCAPI/ccTDUtilGetDataByRef: No tdObjectfound in profileTable for tagID[6] of callID[45]*Mar 1 15:36:22.936: //45/45F2AAE28044/CCAPI/cc_delete_call_entry: not incomingentry*Mar 1 15:36:22.936: //45/45F2AAE28044/CCAPI/cc_delete_call_entry: entry's incoming FALSE.*Mar 1 15:36:22.936: //45/45F2AAE28044/CCAPI/cc_delete_call_entry: is_incomingis FALSE*Mar 1 15:36:22.940: //45/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(12=CC_EV_CALL_DISCONNECT_DONE), cid(45), disp(0)*Mar 1 15:36:22.940: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: cid(45)st(SSA_CS_DISCONNECTING)ev(SSA_EV_CALL_DISCONNECT_DONE)oldst(SSA_CS_ACTIVE)cfid(-1)csize(2)in(0)fDest(0)*Mar 1 15:36:22.940: //45/45F2AAE28044/SSAPP:0:-1/ssaTraceSct: -cid2(44)st2(SSA_CS_DISCONNECTING)oldst2(SSA_CS_CONF_DESTROYING)*Mar 1 15:36:22.940: //45/45F2AAE28044/SSAPP:0:-1/ssaDisconnectDone:*Mar 1 15:36:22.940: //45/45F2AAE28044/SSAPP:0:-1/ssaAAA_CheckAccounting: accounting generation enabled*Mar 1 15:36:22.940: //45/xxxxxxxxxxxx/CCAPI/ccCallSetAAA_Accounting: callID=0x2D, accounting=0*Mar 1 15:36:22.944: //-1/xxxxxxxxxxxx/CCAPI/cc_decr_if_call_volume: not the VoIP or MMoIP*Mar 1 15:36:22.948: //44/xxxxxxxxxxxx/CCAPI/cc_api_call_disconnect_done: (vdbPtr=0x637EC1E0, callID=0x2C, disp=0, tag=0x0)*Mar 1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: ccFreeRawMsgInfo(0x6307595C)*Mar 1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: Decrement call volume counter 1*Mar 1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: current callvolume: 0*Mar 1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: entry's incoming TRUE.*Mar 1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: is_incomingis TRUE*Mar 1 15:36:22.948: //44/45F2AAE28044/CCAPI/cc_delete_call_entry: Deleting profileTable[0x6380E11C]*Mar 1 15:36:22.948: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructTDHashProfileTab: Destructor Profile Table (0x6380E11C)*Mar 1 15:36:22.948: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructInstanceTDObject: tdObject[0x63401148] tagID[5]*Mar 1 15:36:22.948: //-1/xxxxxxxxxxxx/CCAPI/ccTDDestructInstanceTDObject: tdObject[0x638BC1AC] tagID[6]*Mar 1 15:36:22.956: //44/xxxxxxxxxxxx/SSAPP:-1:-1/sess_appl: ev(12=CC_EV_CALL_DISCONNECT_DONE), cid(44), disp(0)*Mar 1 15:36:22.956: //44/45F2AAE28044/SSAPP:10002:-1/ssaTraceSct: cid(44)st(SSA_CS_DISCONNECTING)ev(SSA_EV_CALL_DISCONNECT_DONE)oldst(SSA_CS_CONF_DESTROYING)cfid(-1)csize(1)in(1)fDest(1)Router#*Mar 1 15:36:22.956: //44/45F2AAE28044/SSAPP:10002:-1/ssaDisconnectDone:If the call is failing and the cause appears to be in the VoIP portion of the call setup, you might need to look at the H.225 or H.245 TCP part of the call setup, as opposed to just the UDP portion of the H.323 setup. The commands that can be used to debug the H.225 or H.245 call setup are:
•
•
•
For more information about voice troubleshooting, refer to Troubleshooting and Debugging VoIP Call Basics, document 14081.
Troubleshooting H.323 Gateway Dial Tone
A common problem encountered in a VoIP network is being unable to break dial tone. The router puts a seizure on the local PBX but when digits are dialed, the dial tone stays. The calling party is unable to pass the DTMF tones or digits to the terminating device, resulting in callers being unable to dial the desired extension or interact with the device that needs DTMF tones such as a voice mail or interactive voice response (IVR) application. This problem can result from a number of reasons such as:
•
•
•
•
In the case of a VoIP call from an originating gateway (OGW) to a terminating gateway (TGW), terminating the call to a telephony device might not be understood. When you are passing DTMF tones through a compressed VoIP audio path, some or part of the dual-tones could become slightly distorted because DSP codecs are designed to interpret human speech, not machine tones. Usually, this does not occur with lesser compression codecs such as G.732 or G.711. But the higher compression codecs might result in distortion of in-band tones. However, Cisco IOS allows the DTMF tones to be passed out-of-band between VoIP gateways using three different techniques. All of these techniques use the H.245 capabilities-exchange (part of H.323v2) to signal to the remote VoIP gateway that a DTMF-tone has been received and the remote VoIP gateway should regenerate it.
Make sure the dtmf-relay command is configured under the VoIP dial-peer on both sides. Three different types of DTMF relays can be configured.
Router(config-dial-peer)#dtmf-relay ?cisco-rtp Cisco Proprietary RTPh245-alphanumeric DTMF Relay via H245 Alphanumeric IEh245-signal DTMF Relay via H245 Signal IEIf the problem persists, try a different setting of the dtmf-relay command.
For more information, refer to Inability To Break Dialtone in a Voice over IP Network, document 22376.
Troubleshooting H.323 Gateway Busy Tone
This section addresses call progress in-band related issues that arise when you are interworking ISDN and H.323 signaling between VoIP and the PSTN. Challenges arise when Cisco VoIP gateways exchange signaling capabilities with the telco switch. The following are some common problem scenarios and symptoms:
•
•
•
These scenarios are described in the following sections.
No DTMF Digits or Audio Passed on VoIP Calls to PSTN or PBX
Symptom
Caller makes a call, hears announcement messages (for example "enter your account number...") but cannot pass DTMF digits. This symptom applies for both VoIP toll-bypass and Cisco IP phone calls to PSTN/PBX calls.
Problem Description
A Cisco IP phone (using Cisco CallManager) or POTS phone (VoIP) call leaves through a Cisco IOS gateway, where the called number is usually an interactive voice response (IVR). The IVR system sends back an ISDN progress message but does not connect until some account information is entered. By default, the audio path is cut through in the backward direction (toward the Cisco IP phone or originating gateway), but not in the forward direction, until the terminating gateway receives a connect message. Therefore, there is no voice path for the transmission of DTMF tones or speech towards the terminating switch.
Solution
Configure the Cisco IOS global configuration command voice rtp send-recv to establish (cut through) the audio path in both directions prior to receiving an ISDN connect message from the PSTN. For more information on this command refer to the Cisco IOS Voice Command Reference, Release 12.3.
No Busy Tone or Announcement Message Received When Placing VoIP Outbound Calls
Symptom
A Cisco IP phone (using CallManager) or POTS phone (VoIP) does not hear a busy tone or announcement message from the PSTN.
Solution
Configure the voice call convert-discpi-to-prog command. This command converts an inbound ISDN disconnect message with a progress indicator (PI) to an H.225 progress message with the same progress indicator (PI) value. This command can help when an announcement is played on the terminating PSTN side, but the calling party does not hear the response. In the VoIP toll-bypass scenario, most of these issues are resolved by upgrading the gateways to Cisco IOS Release 12.2(1) or later. However, if the originating device or originating ISDN switch does not keep the call active when an H.225/ISDN disconnect message is received, try using the voice call convert-discpi-to-prog command.
This might come up when the announcement in-band is a busy tone, as well. Beyond that, the busy signal should be provided by either the terminating device, the originating device, or the network. Some aspects of this can be controlled.
No Busy Tone on Inbound Call from Telephony (ISDN) to Cisco CallManager IP Phone, Cisco IOS Gateway, or Third-Party H.323 Device
Symptom
You cannot hear busy tone on a call from PSTN through a gateway to a Cisco CallManager IP phone, Cisco IOS gateway, or third-party H.323 device when running either an application or two-stage dialing on the originating gateway.
Solution
This can occur when the originating gateway is either running a voice application such as debit-card, or is running two-stage dialing. The latter refers to the calling party dialing the number to the gateway first, receiving the dial tone and then dialing the called party. In either case, the call has connected in terms of the PSTN network once it terminates on the originating gateway. If the IP call leg comes back with a release with the cause user-busy, the busy state cannot be indicated back towards the telephony session that is in connect state.
This problem has been addressed by having the originating gateway generate a busy tone when the release from the IP call leg is received with a cause code of user busy. The telephony leg is released either by the calling party or by the gateway after several minutes, with the cause code of normal call clearing.
For more information, refer to Troubleshooting No Busy Tone and No Announcement Messages on ISDN-VoIP (H.323) Calls, document 14066.
Troubleshooting H.323 Gateway Ringback
This section addresses call progress in-band related issues when you are interworking ISDN and H.323 signaling between VoIP and PSTN networks. Challenges arise when Cisco VoIP gateways exchange signaling capabilities with the telco switch. The following are common problem symptoms:
•
•
•
•
No Ringback Tone on VoIP Toll-Bypass Calls
Symptom
A POTS user (from the PSTN or a PBX) places a call through a Cisco gateway and does not hear ringback tone before the call is answered.
Problem Description
The call terminating switch is sending the ringback tone, and signals a PI=8 to the terminating Cisco gateway. The PI information is then forwarded to the originating gateway via an H.225 progress message. The originating gateway is unable to decode the progress message and does not cut through the backward audio path to permit the transmission of the ringback tones. Some common scenarios for this problem are as follows:
•
•
•
•
Solutions
Try the following solutions:
1.
For more information on this command refer to the Cisco IOS Voice Command Reference, Release 12.3.
2.
3.
For more information on this command refer to the Cisco IOS Voice Command Reference, Release 12.3.
Note
No Ringback Tone on VoIP Inbound Calls to Cisco CallManager (or Third-Party VoIP Devices) Through Cisco IOS Gateway
Symptom
A POTS user (on the PSTN or PBX) places a call to an IP phone through a Cisco gateway and does not hear ringback tone before the call is answered.
Problem Description
This commonly occurs when the inbound call does not come in to the Cisco gateway/ router with a PI=3. ISDN switches send a PI=3 in the setup message to inform the gateway that the originating call is non-ISDN and that in-band messages are expected.
Solutions
Use one of the following solutions:
•
For more information on this command refer to the Cisco IOS Voice Command Reference, Release 12.3.
Note
•
No Ringback Tone on VoIP Outbound Calls from Cisco CallManager (or Third-Party Device) Through Cisco IOS Gateway
Symptom
A user makes an outbound call from a Cisco IP phone to the PSTN through a Cisco IOS gateway and does not hear ringback tone.
Problem Description
In this situation, the originating device expects in-band ringback tones, but either of the following might be happening:
•
•
If the PSTN is providing in-band ringback, but the Q.931 alert message is not providing a PI indicating that there is in-band information, the gateway does not cut through the audio until the call is connected.
Solutions
Follow one of the solutions below:
•
Note
•
•
No Ringback to PSTN When IP Phones Initiate a Call Transfer (Cisco CallManager or Cisco Unity Voice Mail)
Symptom
When a call to an IP phone is answered and then transferred, the caller does not hear ringback. When the transferred call is answered, both parties are able to hear each other.
Problem Description
From the perspective of the Cisco IOS gateway, the call is completed once the call is answered by an IP phone through Cisco CallManager or Unity Voice Mail system. Any further progress tones (in case of a call transfer) should be generated by the terminating device. However, Cisco CallManager and Unity are not capable of generating the in-band progress tones.
Solution for Cisco CallManager 3.0
To solve this problem you can either check the following conditions, or configure the Cisco IOS gateway as an MGCP gateway, instead of an H.323 gateway.
•
•
–
–
–
–
This problem is documented in DDTS software bug CSCds11354.
Note
For more information, refer to Troubleshooting No Ringback Tone on ISDN-VoIP (H.323) Calls, document 22983.
Solution for Cisco CallManager 3.3 or Newer
To solve this problem for Cisco CallManager 3.3 or newer, perform the following steps:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Troubleshooting H.323 Gateway One-Way or No Audio
One-way audio and no audio are problems that are fairly common during a new VoIP network installation. Most of these problems are caused by misconfigurations. This section addresses some of the common issues that are known to result in IP telephony one-way audio conversations involving Cisco gateways.
This section provides scenarios and solutions to the following problems:
•
•
The causes for one-way audio or no audio in IP telephony can be varied, however the root of the problem is usually related to IP routing issues. For one-way audio, pay attention to which direction is experiencing the audio loss. Check the following topics if you are experiencing this issue:
•
•
•
•
•
•
•
•
Ensuring IP Routing Is Enabled on Cisco IOS Gateways
Some Cisco IOS gateways, such as the VG200, have IP routing disabled by default. This leads to one-way voice problems. To enable IP routing, simply type the following global configuration command in your Cisco IOS gateway:
Router(config)#ip routingChecking Basic IP Routing
Basic IP reachability should always be checked first. Because Real-Time Protocol (RTP) streams are connectionless (transported over UDP), traffic might travel successfully in one direction, but get lost in the opposite direction.
Once a call is established, an RTP stream carrying audio needs to flow in both directions between the endpoints. It could be that subnet A can be reached from subnet B, but subnet B cannot be reached from subnet A, so the audio stream from A to B always gets lost.
This is a basic routing issue, so use IP routing troubleshooting methods to get to the stage at which you can successfully ping phone A from gateway B. Bear in mind that ping is a bidirectional verification.
Check the following IP routing issues:
•
•
Verify the default gateway configuration on various Cisco IP phones:
•
•
•
Note
Note
Binding the H.323 Signaling to a Specific IP Address
When the Cisco IOS gateway has multiple active IP interfaces, some of the H.323 signaling might be sourced from one IP address and other parts of it might reference different source addresses. This can generate various kinds of problems, one of them being one-way audio.
To get around this problem, the H.323 signaling can be bound to a specific source address, which can belong to a physical or virtual interface (loopback). The command syntax to use under interface configuration mode is h323-gateway voip bind srcaddr ip_address. Configure this command under the interface by using the IP address that Cisco CallManager points to.
Caution
Checking That Answer Supervision Is Being Sent and Received Correctly From the Telco or Switch
In an implementation that has a Cisco IOS gateway connected to a telco or switch, verify that answer supervision is being sent correctly when the called device answers the call from behind the switch. Failure to receive answer supervision causes the Cisco IOS gateway to fail cut through (open) the audio path in a forward direction, causing a one-way voice. A workaround is to configure voice rtp send-recv on.
For more information, see the next section, "Using the voice rtp send-recv Command to Establish Early Two-Way Audio".
Using the voice rtp send-recv Command to Establish Early Two-Way Audio
The voice path is established in the backward direction as soon as the RTP stream is started. The forward audio path is not cut through until the Cisco IOS gateway receives a connect message from the remote end.
In some cases it is necessary to establish a two-way audio path as soon as the RTP channel is opened, before the connect message is received. To achieve this, use the voice rtp send-recv global configuration command.
Checking cRTP Settings on a Link-by-Link Basis
This issue applies to scenarios, such as toll-bypass, where more than one Cisco IOS gateway is involved in the voice path and compressed RTP (cRTP) is used. cRTP, or RTP header compression, is a method for making the VoIP packet headers smaller to regain bandwidth. cRTP takes the 40-byte IP/UDP/RTP header on a VoIP packet and compresses it to 2-4 bytes per packet, yielding approximately 12 KB of bandwidth for a G.729 encoded call with cRTP. For more information on cRTP, refer to Voice Over IP - Per Call Bandwidth Consumption, document ID 7934.
cRTP is done on a hop-by-hop basis with decompression and recompression on every hop. Each packet header needs to be examined for routing, therefore cRTP needs to be enabled on both sides of an IP link.
It is also important to verify that cRTP is working as expected on both ends of the link. Cisco IOS levels vary in terms of switching paths and concurrent cRTP support.
In summary, the history of cRTP support on Cisco IOS is:
•
•
•
If you are running cRTP using Cisco IOS Release 12.1, verify that bug CSCds08210 does not affect your Cisco IOS version (VoIP and fax not working with RTP header compression on).
Verifying Minimum Software Level for NAT on Cisco IOS Gateways
If you are using Network Address Translation (NAT), the minimum software level requirements must be met. Earlier versions of NAT do not support skinny protocol translation and leads to one-way voice issues.
The minimum software levels required for using NAT and skinny simultaneously are Cisco IOS® Software 12.1(5)T for IOS gateways to support skinny and H.323v2 with NAT.
Note
The minimum software level required for using NAT and skinny simultaneously on a PIX firewall is Release 6.0.
Note
Disabling voice-fastpath on Cisco AS5350 and Cisco AS5400 Universal Gateways
The Cisco IOS command voice-fastpath enable is a hidden global configuration command for the Cisco AS5350 and Cisco AS5400. This command is enabled by default. To disable it, use the no voice-fastpath enable global configuration command.
When enabled, this command caches the IP address and UDP port number information for the logical channel opened for a specific call and prevents the RTP stream from getting to the application layer, but rather forwards the packets at a lower layer, which helps reduce CPU utilization marginally in high call volume scenarios.
When supplementary services, such as hold or transfer are used, the voice-fastpath command causes the router to stream the audio to the cached IP address and UDP port, disregarding the new logical channel information generated after a call on hold is resumed or a transfer is completed. To get around this problem, traffic should go to the application layer constantly so that redefinition of the logical channel is taken into account and audio is streamed to the new IP address/UDP port pair. That is why you should disable voice-fastpath to support supplementary services.
Configurinng the VPN IP Address with SoftPhone
Cisco IP SoftPhone enables you to make a PC work like a Cisco IP Phone 7900 Series phone. Remote users who connect back to their company network through VPN need to configure some additional settings in order to avoid a one-way voice problem. This is a result of the media stream needing to have the endpoint of the connection specified.
The solution is to configure the VPN IP address, instead of the IP address of the network adapter, under the Network Audio Settings.
Verifying One-Way Audio
A useful command to verify packet flow is debug cch323 rtp. This command displays packets transmitted (X) and received (R) by the router. An uppercase character indicates successful transmission/reception, and a lowercase character indicates a dropped packet.
Router# debug cch323 rtpRTP packet tracing is enabledRouter#!--- This is an unanswered outgoing call.!--- Notice that voice path only cuts through in forward!--- direction and that packets are dropped. Indeed,!--- received packets are traffic from the IP phone to the PSTN!--- phone. These will be dropped until the call is answered.Mar 3 23:46:23.690: ****** cut through in FORWARD direction *****XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrRouter#Router#!--- This is an example of an answered call:Router#Router#*Mar 3 23:53:26.570: ****** cut through in FORWARD direction *****XXXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXrXXrrrrrXrXrXrXrXrXrXrXrXrXrXrXrrXXrrXrXrXrXrXrXXXXXXXXXXXXXXXXrXXXXXXXXrXrXrXXrrXrXrXrXrXrXrXrXrXrXXrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr!-- At this point the remote end picks up the phone.*Mar 3 23:53:30.378: ****** cut through in BOTH direction *****XRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXXRRXRXRXXRRXRXRXRXRXXRXRXRXRXRXRRXRXXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRRXXRXRXRXRXRXRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRRRRRRRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXRXXRRRXR!-- End of conversation.Using the Test Call Feature to Verify Voice Path
The Test Call feature provides the ability for a remote station or gateway to establish a call to any destination address from a Test Call station located at a network operations center and to audibly verify the voice path:
•
•
•
•
Information About the Test Call Feature
This section provides summary information about the test call feature. This section also describes some of the restrictions and limitations that should be taken into account when you are enabling and activating the test call feature.
Route Server
•
•
•
•
•
TCL Script
•
•
The configured value may be changed using the application, service, and paramspace command structure shown in the "Sample Tasks" section.
•
•
Limitations
•
•
•
Test Mode Limitations
•
•
•
•
clear call voice causecode cause id callID
•
Feature Limitations
•
•
•
Test Call Command-Line Interface
To enable the test call feature, use a new CLI to place specific CIC or DS0s of a trunk group in test mode. The normal circuit selection algorithm would not select this DS0 or CIC number for nontest calls.
gateway# test trunkgroup tg-label [set-tgCic | reset-tgCic] cic-number [cpc test cpc value]In the syntax, the set-tgCic keyword is used to set the test mode, and the reset-tgCic is used to reset from test mode.
To display the mapping of trunk groups to sequential CIC numbers, use the modified show trunk group command. A new keyword cic has been added:
gateway# show trunk group tg-label [cic]In the syntax, the new cic keyword displays the mapping of trunk group DS0 numbers to sequential CIC numbers. A sample output follows:
gateway# show trunk group 1 cictrunk group: 1Description:trunk group label: 1
gateway# show trunk grouptrunk group: 1Description:trunk group label: 1Translation profile (Incoming):Translation profile (Outgoing):Hunt Scheme is least-usedMax Calls (Incoming): NOT-SET (Any) 50 (Voice) NOT-SET (Data)Max Calls (Outgoing): NOT-SET (Any) 50 (Voice) NOT-SET (Data)Retries: 0Trunk Se3/0:23 Preference DEFAULTMember Timeslots : 1-24Total channels available : 12Data = 0, Voice = 0, Modem = 0, Pending = 0, Free = 12Trunk Se5/1:23 Preference DEFAULTMember Timeslots : 1-24Total channels available : 23Data = 0, Voice = 0, Modem = 0, Pending = 0, Free = 23Test mode = 1 <---- newTestmode Timeslot(s) : 19 <---- newTotal calls for trunk group: Data = 0, Voice = 0, Modem = 0Pend = 0, Free = 35advertise_flag 0x00000040, capacity timer 25 sec tripl_config_mask 0x00000000AC_curr 35, FD_curr 0, SD_curr 0succ_curr 7 tot_curr 7succ_report 7 tot_report 7changed 1 replacement position 0Sample Tasks
The following is a sample set of tasks, showing the existing and new or modified CLI that enables the test call feature. This sample is provided for reference purposes only.
Originating Analog Gateway Configuration
Step 1
!trunk group 41001max-retry 1hunt-scheme sequential both up!Step 2
voice-port 1/0/0trunk-group 41001!Step 3
applicationservice mkyuss flash:app_kyuss.3_0_1.tclparamspace english language enparamspace english index 1paramspace english location tftp://<tftp-server-ip>/prompts/enparamspace english prefix enparam test_call_CPC 10param test_call_src_tg 41001!Step 4
dial-peer voice 1025 potstrunkgroup 41001service mkyussdestination-pattern 2015550100trunk-group-label source 41001dial-peer voice 1000 voipdestination-pattern 2015550...session target rasincoming called-number 2015551...dtmf-relay h245-alphanumericcodec g711ulawno vad======= Terminating side ===============
Step 1
trunk group 41001max-retry 1hunt-scheme sequential both up!!!controller E1 3/0ds0-group 0 timeslots 1-15,17-31 type e&m-immediate-startcas-custom 0trunk-group 41001!dial-peer voice 1025 potstrunkgroup 41001service mkyussdestination-pattern 2015550100!dial-peer voice 1000 voipdestination-pattern 2015550...session target rasincoming called-number 2015551...dtmf-relay h245-alphanumericcodec g711ulawno vadStep 2
test trunkgroup 41001 reset_tgCic 21 cpc 10Step 3
Dialed string from orig gw analog phone : <dest_phone_num>*<cic>#Troubleshooting Gatekeepers
An H.323 gatekeeper is an H.323 entity on the LAN that provides address translation and controls access to the LAN for H.323 terminals, gateways, and MCUs.
Gatekeepers are optional nodes that manage endpoints in an H.323 network. The endpoints communicate with the gatekeeper using the RAS protocol.
Endpoints attempt to register with a gatekeeper on startup. When an endpoint wishes to communicate with another endpoint, it requests admission to initiate a call using a symbolic alias for the endpoint, such as an E.164 address or an e-mail address. If the gatekeeper decides that the call can proceed, it returns a destination IP address to the originating endpoint. This IP address might not be the actual address of the destination endpoint; it might be an intermediate address, such as the address of a proxy or a gatekeeper that routes call signaling.
Note
The following topics are addressed:
•
•
•
•
•
•
•
For more information about H.323 gatekeepers, refer to Understanding H.323 Gatekeepers, document 5244.
Troubleshooting H.323 Gatekeeper Registration
Some of the common issues that are known to result in endpoints not registering with Cisco gatekeepers are described in the following section. This section also explains how to check if the endpoints or gateways are registered with the gatekeeper and suggests some debug commands for troubleshooting the issue. It is assumed here that the reader understands the basic concept of Registration, Admission, and Status (RAS) signaling and the functionality of the Cisco gatekeeper.
When you use a Cisco gatekeeper to route a call between Cisco gateways, the gateways do not register with the gatekeeper.
Related Commands
This section describes some show and debug commands to assist you while troubleshooting the issue.
show gatekeeper endpoint
Use the show gatekeeper endpoints command to verify the endpoints registration status to the gatekeeper.
The following example shows normal output of this command if an endpoint is registered.
gatekeeper# show gatekeeper endpoint GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags -------------- ----- ------------- ---- --------- ---- ----- 172.16.13.35 1720 172.16.13.35 50890 gk VOIP-GW E164-ID: 2073418 E164-ID: 5251212 H323-ID: Router Total number of active registrations = 1The following example shows normal output of this command if an endpoint is not registered.
gatekeeper# show gatekeeper endpoint GATEKEEPER ENDPOINT REGISTRATION ================================ CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags -------------- ----- ------------- ---- --------- ---- ----- Total number of active registrations = 0show gateway
Use this gateway command to verify the registration status of the gateway to a gatekeeper.
The following example shows the common output of this command if the gateway is registered to a gatekeeper.
Router# show gateway Gateway Router/ww is registered to Gatekeeper gkAlias list (CLI configured) E164-ID 2073418 E164-ID 5251212 H323-ID Router Alias list (last RCF) E164-ID 2073418 E164-ID 5251212 H323-ID RouterH323 resource thresholding is DisabledThe following example shows the common output of this command if the gateway is not registered to a gatekeeper.
Router#show gateway Gateway Router is not registered to any gatekeeperAlias list (CLI configured) E164-ID 2073418 E164-ID 5251212 H323-ID Router/ww Alias list (last RCF)H323 resource thresholding is Disableddebug h225 asn1
This is a gatekeeper and gateway debug command. In this document, we are looking only for the registration reject (RRJ) field and searching for the rejection reason. The following examples show the RRJ field output.
Output from Gateway
*Mar 8 06:03:53.629: RAS INCOMING PDU ::=value RasMessage ::= registrationReject : { requestSeqNum 2829 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason securityDenial : NULL gatekeeperIdentifier {"gk"} }Output from Gatekeeper
*Mar 1 06:49:32.699: RAS OUTGOING PDU ::=value RasMessage ::= registrationReject : { requestSeqNum 3055 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason securityDenial : NULL gatekeeperIdentifier {"gk"} }Reject Reasons
When a gatekeeper is not performing registration correctly, reject reasons (RRJs) can appear in debug commands. This section describes some common reject reasons.
Before running the debugs, verify that the gatekeeper is enabled:
gatekeeper zone local gk cisco.com no shutdownThe gateway is not registered if there are no debug ras and debug h225 ans1 outputs from the gateway.
The show gatekeeper endpoint and show gateway commands indicate that no gateway is registered. Check the gateway for the following:
•
Router(config)# gateway•
RRJ: rejectReason duplicateAlias
The following output from the debug h225 asn1 command shows a registration reject reason of duplicateAlias.
RAS INCOMING PDU ::= value RasMessage ::= registrationReject : { requestSeqNum 24 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason duplicateAlias: { } gatekeeperIdentifier {"gk"} }This is usually the result of the gateway registering a duplicate of an E164-ID or H323-ID—another gateway has already been registered to the gatekeeper. If it is a duplicated E164-ID, change the destination pattern configured under a POTS dial-peer associated with an FXS port. If it is a duplicated H323-ID, change the gateway's H.323 ID under the H.323 VoIP interface.
RRJ: rejectReason terminalExcluded
*Mar 1 09:48:09.553: RAS OUTGOING PDU ::=value RasMessage ::= gatekeeperReject : { requestSeqNum 3421 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason terminalExcluded : NULL }This is the result of the gateway subnet being disabled in the gatekeeper. Check the gatekeeper configuration. The following configuration likely appears. If so, removing the no zone subnet gk command resolves the issue. To remove the command completely, remove the zone local gk command.
gatekeeper zone local gk cisco.com no zone subnet gk 172.16.13.0/27 enable zone prefix gk 5* gw-type-prefix 510#* default-technology no shutdownRRJ: rejectReason securityDenial
*Mar 1 09:54:32.372: RAS OUTGOING PDU ::=value RasMessage ::= registrationReject : { requestSeqNum 3010 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason securityDenial : NULL gatekeeperIdentifier {"gk"} }This RRJ is the result of the security commands being enabled in the gatekeeper, and the inability of the gateway to match the H.323-ID, E.164-ID, passwords, or security token that the gatekeeper requires. To resolve the issue, check the securiy configuration in the gatekeeper. For further information on security, refer to Understanding H.323 Gatekeepers, document 5244.
If the security h323-id command is enabled, make sure the gatekeeper has been configured as follows:
username Router password 0 wwgatekeeper zone local gk cisco.com no zone subnet gk 172.16.13.0/27 enable zone prefix gk 5* security h323-id security password separator / gw-type-prefix 510#* default-technology no shutdownAlso, make sure the gateway has been configured as follows:
interface Ethernet0/0 ip address 172.16.13.35 255.255.255.224 half-duplex h323-gateway voip interface h323-gateway voip id gk ipaddr 172.16.13.14 1718 h323-gateway voip h323-id Router/ww
Note
gateway security password 010411 level endpointIf security E164 is enabled, make sure the gatekeeper has been configured as follows:
username 5551212 ß- E164 address the gateway tries to registered to gatekeepergatekeeper zone local gk cisco.com no zone subnet gk 172.16.13.0/27 enable zone prefix gk 5* security E164 gw-type-prefix 510#* default-technology no shutdownIf security token is enabled, make sure the gatekeeper has been configured as follows:
gatekeeper zone local gk cisco.com no zone subnet gk 172.16.13.0/27 enable zone prefix gk 5* security token required-for registration gw-type-prefix 510#* default-technology no shutdownAlso, make sure the gateway has the following configuration:
gateway security password 010411 level endpoint
Note
RRJ: rejectReason invalidAlias
*Mar 1 22:03:28.929: RAS OUTGOING PDU ::=value RasMessage ::= registrationReject : { requestSeqNum 2994 protocolIdentifier { 0 0 8 2250 0 3 } rejectReason invalidAlias : NULL gatekeeperIdentifier {"gk-A"} }The RRJ is the result of a no-zone prefix defined in the gatekeeper. Check the configuration on the gatekeeper and add the zone prefix with the proper E.164 address. You should check the following Cisco IOS defects in CSCdu78917.
Configure the gatekeeper as follows:
! gatekeeper zone local gk-A cisco.com zone prefix gk-A 2000* zone prefix gk-A 3000* zone prefix gk-A 4000* no shutdown !For more information, refer to Troubleshooting Gatekeeper Registration Issues, document 22378.
Troubleshooting H.323 Gatekeeper Call Routing and Dial Peers
Cisco gatekeepers are used to group gateways into logical zones and perform call routing between them. Gateways are responsible for edge routing decisions between the PSTN and the H.323 network. Cisco gatekeepers handle the core call routing among devices in the H.323 network and provide centralized dial plan admistration. Without a Cisco gatekeeper, explicit IP addresses for each terminating gateway would have to be configured at the originating gateway and matched to a VoIP dial peer. With a Cisco gatekeeper, gateways query the gatekeeper when trying to establish VoIP calls with remote VoIP gateways.
For example, when presented with a call, the gateway determines whether to send it to the telephony leg or to the IP leg according to its dial plan. In the case of the IP leg, the gateway queries the Cisco gatekeeper to select the best endpoint. The Cisco gatekeeper determines if the called endpoint is within its local zone or is located at a remote zone controlled by a remote Cisco gatekeeper.
The following is a list of useful show and debug commands used to verify and troubleshoot gatekeeper and gateway call routing issues.
Certain show commands are supported by the Output Interpreter (registered customers only) tool, which allows you to view an analysis of show command output.
•
•
•
•
•
•
•
For detailed information about troubleshooting gateway dial peer issues, refer to Understanding Cisco IOS Gatekeeper Call Routing, document 24462.
Troubleshooting H.323 Gatekeeper Bandwidth
According to the H.323 recommendation, Cisco IOS gatekeepers should support the following H.225 RAS bandwidth management messages:
•
•
•
Note
The need to support these messages is based on bandwidth management. The gatekeepers can also use a null function that accepts all requests for bandwidth changes. In other words, the gatekeeper can either use these messages to manage bandwidth (by allowing or rejecting requests) or just ignore them.
Bandwidth Management Operation Overview
The Cisco gatekeeper might reject calls from a terminal due to bandwidth limitations. This can occur if the gatekeeper determines that there is not sufficient bandwidth available on the network to support the call. Bandwidth determination also operates during an active call when a terminal requests additional bandwidth or reports a change in bandwidth used for the call.
The Cisco gatekeeper maintains a record of all active calls so that it can manage the bandwidth resources in its zone. In a cluster configuration, the Gatekeeper Update Protocol (GUP) announcement indication message is exchanged at set intervals and carries information about the bandwidth utilization for the zone. This GUP message exchange allows the alternate gatekeepers to properly manage the bandwidth for a single zone, even though the gatekeepers are in separate physical devices.
When deciding whether there is enough bandwidth to accept a call Admission Request (ARQ), the Cisco gatekeeper calculates the available bandwidth with the following formula:
Available bandwidth = (total allocated bandwidth) - (bandwidth used locally) - (bandwidth used by all alternates).
If the available bandwidth is sufficient for the call, an Admission Confirmation (ACF) is returned, otherwise an Admission Rejection (ARJ) is returned.
Voice gateways should consider codec, Layer 2 encapsulation, and compression features (such as cRTP) when requesting bandwidth from the Cisco gatekeeper. Sometimes these features are not defined at the time of call setup, in which case a bandwidth change request can be issued to the gatekeeper after call setup to adjust the amount of bandwidth used by the call.
Configuring the Bandwidth Management Feature on the Cisco Gatekeeper
The following types of zone bandwidth limitations can be configured on the Cisco gatekeeper:
•
•
•
To configure Cisco gatekeeper zone bandwidth, use the following commands:
•
•
These configured values are used for processing ARQs and BRQs.
For an ARQ, the Cisco gatekeeper deducts the bandwidth specified in the message from the appropriate zone counters and/or remote counters. If this causes any counter to go negative, then the call is denied and an ARJ response is sent with the reason ARJ_REQ_DENIED. If the request is for a zone that has a maximum session bandwidth specified, then the request is validated against this value. If the call request exceeds this bandwidth, then the Cisco gatekeeper returns an ACF with the bandwidth set to the maximum session bandwidth. It is up the endpoint to continue or reject the call.
For a BRQ requesting a bandwidth increase, the Cisco gatekeeper validates the request against the zone and/or remote. If the validation fails, then a BRJ response is sent with a reason of BRJ_INSUFFICIENT_RSC and a specification of the maximum amount of bandwidth allowed.
Using Gatekeeper show Commands to Display Bandwidth Information
Enter the show gatekeeper zone status command to display the bandwidth information for all zones.
Router# show gatekeeper zone statusGATEKEEPER ZONES================GK name Domain Name RAS Address PORT FLAGS------- ----------- ----------- ----- -----Router domainB.com 172.16.13.41 1719 LSBANDWIDTH INFORMATION (kbps) :Maximum total bandwidth : 512Current total bandwidth : 128Current total bandwidth (w/ Alt GKs) : 128Maximum interzone bandwidth : 512Current interzone bandwidth : 128Current interzone bandwidth (w/ Alt GKs) : 128Maximum session bandwidth : 512SUBNET ATTRIBUTES :All Other Subnets : (Enabled)PROXY USAGE CONFIGURATION :Inbound Calls from all other zones :to terminals in local zone Router : use proxyto gateways in local zone Router : do not use proxyto MCUs in local zone Router : do not use proxyOutbound Calls to all other zones :from terminals in local zone Router : use proxyfrom gateways in local zone Router : do not use proxyfrom MCUs in local zone Router : do not use proxygka-1 domainA.com 172.16.13.35 1719 RSEnter the show gatekeeper zone cluster command to display the bandwidth information, in case the gatekeeper is part of a cluster.
Router# show gatekeeper zone clusterLOCAL CLUSTER INFORMATION=========================TOT BW INT BW REM BW LAST ALT GKLOCAL GK NAME ALT GK NAME PRI (kbps) (kbps) (kbps) ANNOUNCE STATUS------------- ----------- --- ------ ------ ------ -------- ------Router gkb-2 0 0 0 0 22s CONNECTEDEnter the show gatekeeper calls command to display the active calls permitted by that gatekeeper and how much bandwidth each call is using.
Router# show gatekeeper callsTotal number of active calls = 1.GATEKEEPER CALL INFO====================LocalCallID Age(secs) BW3-63466 9 128(Kbps)Endpt(s): Alias E.164Addrsrc EP: gwa-1 4085272923Endpt(s): Alias E.164Addrdst EP: gwb-1 3653CallSignalAddr Port RASSignalAddr Port172.16.13.23 1720 172.16.13.23 54670Bandwidth-Related RAS Messages (BRQ, BCF, and BRJ)
The BRQ message is used to request a change in bandwidth from the Cisco gatekeeper. The procedure is as follows:
1.
2.
3.
4.
RAS Messages Used to Report Bandwidth Status
The Information Request Response (IRR) Non-Standard Data field also carries information about the currently used bandwidth on a gateway or proxy.
How BRQ Is Triggered from the Gateway to Notify the Gatekeeper to Reduce Call Bandwidth
With unidirectional bandwidth, calls were always reported to require a bandwidth of 64 kbps, which is the unidirectional bandwidth for a Cisco G.711 codec. If the endpoints in the call chose to use a more efficient codec, this was not reported to the Cisco gatekeeper. In the version of the Cisco H.323 gateway in Cisco IOS Release 12.2(2)XA or later (which conforms with H.323 version 3), the reported bandwidth is bidirectional. Initially, 128 kbps is reserved. If the endpoints in the call select a more efficient codec, the Cisco gatekeeper is notified of the bandwidth change.
To use the reported bandwidth behavior used prior to Cisco IOS Release 12.2(2)XA for zone bandwidth management, configure the Cisco H.323 gateway with the following command in global configuration mode:
Router(config-gateway)# emulate cisco h323 bandwidth}For more information about gatekeeper bandwidth management, refer to Troubleshooting and Understanding Cisco Gatekeeper Bandwidth Management, document 18731.
Checking Cisco Gateway Failover to Alternate Gatekeeper
Prior to Cisco H.323 version 2, each zone was only controlled by only a single gatekeeper. Cisco H.323 version 2 introduces the alternate gatekeeper to provide gatekeeper redundancy. Implementing the alternate gatekeeper feature allows multiple gatekeepers to control one zone. When an endpoint registers with a gatekeeper, it is provided with a list of alternate gatekeepers for the zone in which the endpoint registers, and for which alternates were specified using the CLI. If the gatekeeper fails, the endpoint may use the alternate gatekeepers in order to continue operation.
The alternate gatekeeper list is provided to the Cisco gatekeeper through the CLI for each zone and is transmitted to endpoints through the RCF (including lightweight) and GRQ messages. This list might also be transmitted in other messages, such as ARJ or URQ, to facilitate a controlled gatekeeper shutdown.
Alternate gatekeepers learn about existing calls through an Interrupt Request (IRQ) and Information Request Response (IRR) exchange between the gateways and the gatekeepers, and they keep track of these calls.
An endpoint that detects the failure of its gatekeeper can safely recover from that failure by utilizing an alternate gatekeeper for future requests, including requests for existing calls. Alternate gatekeepers have to be configured in a cluster. They share the information about the endpoints and active calls using the GUP that runs on TCP.
By default, Cisco gateways send a lightweight RRQ every 45 seconds. In case the gatekeeper did not send any URQ to the gateway (due to a broken routing issue, for example), the gateway (upon not hearing an RCF or RRJ for its lightweight RRQ) tries twice with 5 seconds between attempts. If the third attempt fails, the gateway immediately considers the gatekeeper dead and registers with the alternate gatekeeper using RRQ. In a scenario where the gateway starts the initial registration process with the gatekeeper, it sends out the GRQ to locate the gatekeeper IP address. If there is a GCF reply, the gateway sends the RRQ to the primary gatekeeper specified. If for any reason the gatekeeper rejects the registration request, the gateway does not try to contact its alternate gatekeeper. It starts this process (GRQ, GCF, and RRQ) over again with the primary gatekeeper.
The gateway contacts the alternate gatekeeper only when the connectivity to the primary gatekeeper is lost and there is no reply. If the primary gatekeeper does not reply to the GRQ message when the gateway first sends it out to discover the gatekeeper, then after three failed attempts (approximately 5 minutes per attempt), the gateway contacts the alternate gatekeeper. In a situation where the primary gatekeeper goes down after the gateway has registered with it, the gateway loses keepalive messages from the primary gatekeeper. After missing three consecutive keepalive messages, the gateway declares the primary gatekeeper down, and it starts the registration process again.
Gatekeeper Update Protocol
Here are some major GUP considerations that should also help with troubleshooting.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
For more information, refer to Troubleshooting GUP, Alternate Endpoint and Load Balancing, document 18730.
Troubleshooting Issues with Alternate Endpoints
A calling endpoint can recover from a call setup failure by sending a setup message to one of the alternate endpoints. The call can fail for many reasons:
•
•
•
Note
The gatekeeper learns about the alternate for a certain endpoint either by manual configuration using the gatekeeper endpoint alt-ep command or from any received RAS messages. Cisco supports a maximum of 20 alternates for each endpoint, no matter how the gatekeeper learns about them.
Here are some issues you need to consider:
•
•
•
Use the following commands to verify alternate endpoints:
•
•
•
For more information, refer to Troubleshooting GUP, Alternate Endpoint and Load Balancing, document 18730.
Troubleshooting Gatekeeper Endpoint Call Admission Issues
This section addresses some of the common issues that are known to result in endpoints not being able to make calls involving Cisco gateways or third-party gateways and terminals, and Cisco gatekeepers.
When there is a problem with gatekeeper endpoint call admission, after configuring an H.323 endpoint to register to a Cisco gatekeeper, the endpoints are not able to make calls. When this occurs, check the show gatekeeper endpoint command to make sure the endpoints are all registered to the gatekeeper.
Admission Confirmed (Busy Tone Back)
If the Admission Confirmed (ACF) message has been sent by the gatekeeper and arrived at the endpoint side, but the call still received a busy signal, check to see if the terminating IP address in the ACF is an expected valid endpoint IP.
value RasMessage ::= admissionConfirm :{requestSeqNum 18bandWidth 5120callModel direct : NULLdestCallSignalAddress ipAddress :{ip '0AAAC80A'H!--- The hex for IP, 0A AA C8 0A== 10.170.200.10.port 1720port 1720}irrFrequency 240willRespondToIRR FALSEuuiesRequested{setup FALSEcallProceeding FALSEconnect FALSEalerting FALSEinformation FALSEreleaseComplete FALSEfacility FALSEprogress FALSEempty FALSE}}If the ACF has an IP address of the terminating endpoint, remove the gatekeeper and make a direct endpoint-to-endpoint call to see if a call can be established.
Admission Reject (ARJ) rejectReason calledPartyNotRegistered
The following debug h225 asn1 command shows calledPartyNotRegistered.
*Mar 15 06:49:19.685: RAS OUTGOING PDU ::=value RasMessage ::= admissionReject :{requestSeqNum 34rejectReason calledPartyNotRegistered : NULL}This is a common reason for rejection. It is captured from the local or originating gatekeeper when the gatekeeper has no information on where the called number should be terminated. There are two ways this problem can occur. One reason is that the call terminates at a gateway, and the gateway is not registered with the E.164 address or with a tech-prefix. To resolve this, make sure the gateway is registered with a tech-prefix to the gatekeeper.
The following is a corrected gateway configuration example.
interface Ethernet0/0ip address 172.16.13.16 255.255.255.224half-duplexh323-gateway voip interfaceh323-gateway voip id hwei-gk ipaddr 172.16.13.14 1718h323-gateway voip h323-id gw2h323-gateway voip tech-prefix 2....!voice-port 2/0/0!voice-port 2/0/1!voice-port 2/1/0station-id name BLARGcaller-id enable!voice-port 2/1/1!dial-peer cor custom!dial-peer voice 456 potsdestination-pattern 456port 2/1/0!dial-peer voice 123 potsdestination-pattern 2415...port 2/1/1!gateway"show gatekeeper gw" from gatekeeperGATEWAY TYPE PREFIX TABLE=========================Prefix: 1*Zone hwei-gk master gateway list:172.16.13.35:1720 gw1Prefix: 2*Zone hwei-gk master gateway list:172.16.13.16:1720 456A second possible explanation for this error message arises if the called party is a terminal in a remote zone. It might be that the terminal does not have a proxy enabled in the same gatekeeper zone where it is registered. By default, a Cisco IOS gatekeeper uses a proxy for inter-zone terminal calls. Issue the show gatekeeper zone status command to view the proxy. Either configure a proxy register to the same local zone as the terminal or issue the no use-proxy hwei-gk default inbound-to terminal command or the no use-proxy hwei-gk default outbound-from terminal command to disable the use of a proxy for terminal calls.
Note
ARJ "rejectReason requestDenied"
*Mar 1 10:34:46.093: RAS OUTGOING PDU ::=value RasMessage ::= admissionReject :{requestSeqNum 11084rejectReason requestDenied : NULL}The rejection shown here comes about because the endpoint-requested bandwidth exceeds the limit configured in the gatekeeper. To resolve this, increase the bandwidth in the gatekeeper using the bandwidth command under the gatekeeper mode, or lower the bandwidth request from the endpoint.
The following example shows a call that failed because the bandwidth request exceeded the configured limit:
Value RasMessage ::= admissionRequest :{requestSeqNum 11084callType pointToPoint : NULLcallModel gatekeeperRouted : NULLendpointIdentifier {"6284945400000058"}destinationInfo{e164 : "415525",e164 : "415525"}srcInfo{e164 : "415526",h323-ID : {"hwei-term"}}srcCallSignalAddress ipAddress :{ip '0AAAC837'Hport 1720}bandwidth 102400!--- Requested bandwidth was 10240 K.callReferenceValue 1022conferenceID '37CE425F850A41468B40D72F145C5C14'HactiveMC FALSEanswerCall TRUEcanMapAlias FALSEcallIdentifier{guid '4138E0D40EF0D14C9DB84E54F5190BF4'H}gatekeeperIdentifier {"hwei-gk"}willSupplyUUIEs FALSE}*Mar 1 10:34:46.093: ARQ (seq# 11084) rcvd*Mar 1 10:34:46.093: gk_rassrv_arq: arqp=0x62905E20, crv=0x3FE,answerCall=1*Mar 1 10:34:46.093: RAS OUTGOING PDU ::=value RasMessage ::= admissionReject :{requestSeqNum 11084rejectReason requestDenied : NULL}!--- The show gatekeeper zone status command is issued and it shows the!--- bandwidth limit is much smaller then the requested bandwidth.GATEKEEPER ZONES================HWEI-GK name Domain Name RAS Address PORT FLAGS------- ----------- ----------- ----- -----hwei-gk cisco.com 172.16.13.14 1719 LSBANDWIDTH INFORMATION (kbps) :Maximum total bandwidth :Current total bandwidth : 0Maximum interzone bandwidth : 4000 _-----limit was 4000KCurrent interzone bandwidth : 0Maximum session bandwidth :........hwei-gk1 cisco.com 172.16.13.37 1719 RSFor more information about VoIP bandwidth consumption, refer to Voice Over IP - Per Call Bandwidth Consumption, document ID 7934.
If this rejection reason is offer but there is no bandwidth issue, see if the called party is a terminal and if there is a proxy registered to the local zone. Issue the show gatekeeper zone status command to do that. Either configure a proxy register to the same local zone as the terminal or issue the no use-proxy hwei-gk default inbound-to terminal or no use-proxy hwei-gk default outbound-from terminal command to disable the use of a proxy for terminal calls.
Verification Commands
This section describes a few show commands and debugs that can help you verify the configuration required on the gatekeeper and the gateway. Sample show command outputs are included.
Certain show commands are supported by the Output Interpreter tool, which allows you to view an analysis of show command output; a link to this tool can be found in the "Troubleshooting Resources" chapter.
show gatekeeper endpoint Command
The show gatekeeper endpoint command is used to verify the endpoint's registration status with the gatekeeper. The normal outputs of this command are shown in the following example.
gatekeeper# show gatekeeper endpointGATEKEEPER ENDPOINT REGISTRATION================================CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags--------------- ----- --------------- ----- --------- ---- -----172.16.13.35 1720 172.16.13.35 50890 hwei-gk VOIP-GWE164-ID: 2073418E164-ID: 5251212H323-ID: RouterTotal number of active registrations = 1!--- The endpoint is registered.Gatekeeper# show gatekeeper endpointGATEKEEPER ENDPOINT REGISTRATION================================CallSignalAddr Port RASSignalAddr Port Zone Name Type Flags--------------- ----- --------------- ----- --------- ---- -----Total number of active registrations = 0!--- The endpoint is not registered.show gatekeeper gw Command
The show gatekeeper gw command is used to verify the endpoints registration status for the tech prefix. The common outputs of this command are shown in the following example.
Gatekeeper# show gatekeeper gwGATEWAY TYPE PREFIX TABLE=========================Prefix: 1*Zone hwei-gk master gateway list:172.16.13.35:1720 gw1show gatekeeper zone status Command
The show gatekeeper zone status command is used to display the local zone status and the remote zone information, as shown in the following example.
2611-3# show gatekeeper zone statusGATEKEEPER ZONES================HWEI-GK name Domain Name RAS Address PORT FLAGS------- ----------- ----------- ----- -----hwei-gk cisco.com 172.16.13.14 1719 LSBANDWIDTH INFORMATION (kbps) :Maximum total bandwidth :Current total bandwidth : 0Maximum interzone bandwidth : 4000Current interzone bandwidth : 0Maximum session bandwidth :SUBNET ATTRIBUTES :All Other Subnets : (Enabled)PROXY USAGE CONFIGURATION :Inbound Calls from all other zones :to terminals in local zone hwei-gk : use proxyto gateways in local zone hwei-gk : do not use proxyto MCUs in local zone hwei-gk : do not use proxyOutbound Calls to all other zones :from terminals in local zone hwei-gk : use proxyfrom gateways in local zone hwei-gk : do not use proxyfrom MCUs in local zone hwei-gk : do not use proxyhwei-gk1 cisco.com 172.16.13.37 1719 RSshow gateway Command
The show gateway command is used to verify the registration status with a gatekeeper. The common outputs of this command are shown in the following example:
Router# show gatewayGateway Router/ww is registered to Gatekeeper hwei-gkAlias list (CLI configured)E164-ID 2073418E164-ID 5251212H323-ID RouterAlias list (last RCF)E164-ID 2073418E164-ID 5251212H323-ID RouterH323 resource thresholding is Disabled!--- The gateway is registered to gatekeeper (hwei-gk).Router# show gatewayGateway Router is not registered to any gatekeeperAlias list (CLI configured)E164-ID 2073418E164-ID 5251212H323-ID Router/WWAlias list (last RCF)H323 resource thresholding is Disabled!--- The gateway is not registered to the gatekeeper.debug h225 asn1 Command
The debug h225 asn1 command is the gatekeeper and Cisco gateway debug command. In this document, you are looking only for the ARJ field and searching for the rejection reason. The following example is a sample output showing the ARJ field.
Output from gateway:
*Mar 26 04:12:38.508: RAS INCOMING PDU ::=value RasMessage ::= admissionReject :{requestSeqNum 34rejectReason calledPartyNotRegistered : NULL}Output from gatekeeper:
*Mar 15 06:49:19.685: RAS OUTGOING PDU ::=value RasMessage ::= admissionReject :{requestSeqNum 34rejectReason calledPartyNotRegistered : NULL}Troubleshoot Load Balancing
With the Load Balance feature, you can set the gatekeeper with a certain threshold for the number of calls, memory, CPU, and number of registered endpoints. Once that threshold is reached, the gatekeeper moves registered Cisco H.323 endpoints to an alternate gatekeeper or rejects new calls and registrations. Load balancing is enabled by use of the following gatekeeper CLI command:
Router(config-gk)#load-balance {endpoints max-endpoints} {calls max-calls} {cpu max-%cpu}{memory max-%mem-used}When the threshold is met, the gatekeeper uses the RRJ RAS message to inform the endpoint about the alternate gatekeepers and the reject reason. Upon receiving that message, the endpoint sends a new RRQ to the alternate gatekeeper. Once the endpoint is registered with the alternate gatekeeper, it uses the GUP message to inform all gatekeepers in the cluster about the new registered endpoint.
When troubleshooting, check the configuration on the gatekeeper and make sure that alternate gatekeepers and load balancing are functional. To debug the load balancing feature, use debug gatekeeper load and debug h225 asn1 to see how the gatekeeper reacts when the threshold is met.
For more information, refer to Troubleshooting GUP, Alternate Endpoint and Load Balancing, document 18730.
Gateway-to-Gateway and Gatekeeper-to-Gateway Security
H.323 networks have different kinds of configurations and call flows. See the Cisco Gateway to Gatekeeper (H.235) and Gatekeeper to Gatekeeper (IZCT) Security Troubleshooting Guide, document 18729 to get information about the following features:
•
•
