There's not enough information to provide a definitive answer, but it does sound like a media negotiation issue to me as well, especially since you received the same error when using MGCP control. ALERTING is one of a few ISDN messages that trigger an audio connection attempt via various internal processes to CCM; it's at this point that media capabilities are shared, compared, and negotiated. My suggestion would be to debug h245 asn1 at the gateway and review detailed CCM traces off the CUCM node - focus on the TCS and MSD sessions.
The last entry in the output you provided below shows the router began waiting for the master/slave determination to occur, but I have a feeling the rest of the output was simply cut off so I won't focus on that. Off the top of my head... make sure the capabilities being advertised and matched are equal to or below the configured bitrate on the associated region relationship - in traces, you'll see an attempt at region capabilities matching after the exchange of TCS - I'd also check for any capabilities mismatch, transcoder or MTP allocation attempts, etc. after the TCS exchange (assuming you keep it a H.323 gateway). Hope you find this helpful. - Daniel From: ccie_voice-boun...@onlinestudylist.com [mailto:ccie_voice-boun...@onlinestudylist.com] On Behalf Of Samson Kareem Sent: Monday, October 21, 2013 1:33 PM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Outbound PSTN call drops Hi All, I am hitting an issue where outbound PSTN calls are failing after the call initially seems to setup ok. Then the H323 gateway sends a disconnect to the PSTN and the call drops as per below. Oct 21 16:42:59.876: ISDN Se0/3/0:15 Q931: TX -> SETUP pd = 8 callref = 0x008C Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98383 Exclusive, Channel 3 Display i = 'Tobias Funke' Calling Party Number i = 0x1181, '17707022001' Plan:ISDN, Type:International Called Party Number i = 0x91, '97148037333' Plan:ISDN, Type:International Oct 21 16:42:59.908: ISDN Se0/3/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x808C Channel ID i = 0xA98383 Exclusive, Channel 3 Oct 21 16:42:59.916: ISDN Se0/3/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x808C Progress Ind i = 0x8188 - In-band info or appropriate now available Oct 21 16:42:59.944: ISDN Se0/3/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x008C <<========== Cause i = 0x80AF - Resource unavailable, unspecified Oct 21 16:42:59.952: ISDN Se0/3/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x808C Oct 21 16:42:59.956: ISDN Se0/3/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x008C I first thought it was a DSP resource issue as the disconnect cause is Cause i = 0x80AF - Resource unavailable, unspecified but I checked the status of DSPs using #show voice dsp group all and no problems there. I found an old post from OSL Nov 2011 where someone suggested a codec mismatch with the H245 negotiation which causes the call to drop immediately after the alerting message. The thing is I have a voice class codec configured and in any case, the gateway was originally an MGCP gateway and calls were failing with the same ISDN disconnect cause (I only changed it to a H323 g/w for troubleshooting purposes). I tried using debug cch323 h245 and have pasted the output received after the ISDN alerting message below. I believe this is when codec negotiation takes place on the voip leg of the call between CUCM and the g/w. Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_channel_established_ind: Using fd=4 to send msgs Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_send_event_to_h245_connection_sm: Changing to new event H245_ESTABLISHED_EVENT Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_connection_sm: H245_LISTEN: Received event H245_ESTABLISHED_EVENT while at H245_WAITING state Oct 21 16:25:16.653: //51/8043215D0100/H323/cch323_h245_set_new_state: Changing from H245_WAITING state to H245_CONNECTED state Oct 21 16:25:16.653: //51/8043215D0100/H323/run_h245_iwf_sm: received IWF_EV_H245_CONNECTED while at state IWF_IDLE Oct 21 16:25:16.653: //51/8043215D0100/H323/h245_iwf_set_new_state: changing from IWF_IDLE state to IWF_AWAIT_CAP_MSD_RESP state Oct 21 16:25:16.657: //51/8043215D0100/H323/cch323_run_h245_cap_out_sm: Received H245_EVENT_CAP_REQ while at state IDLE Oct 21 16:25:16.657: //51/8043215D0100/H323/h245_cap_out_set_new_state: changing from IDLE state to AWAITING_RESPONSE state Oct 21 16:25:16.657: //51/8043215D0100/H323/cch323_run_h245_ms_sm: Received event H245_EVENT_MSD while at state H245_MS_NONE Oct 21 16:25:16.657: //51/8043215D0100/H323/cch323_run_h245_ms_sm: Sent MSD Request Oct 21 16:25:16.657: //51/8043215D0100/H323/h245_ms_set_new_state: Changing from H245_MS_NONE state to H245_MS_OUTGOING_WAIT state does anyone have any pointers? thanks Samson
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
