Re: [OSL | CCIE_Voice] Outbound PSTN call drops
Thanks for sharing the link.. In the end I reconfigured the gateway from scratch as MGCP after a reload and this time calls complete ok.. Date: Wed, 23 Oct 2013 11:14:27 -0400 From: ising...@gmail.com To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] Outbound PSTN call drops You may want to look into Bug ID: CSCsx67255...link below. http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsx67255&from=summary Inder Singh CCIE™ Voice #38235 Sr. Network Engineer, Unified Communications ___ 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 ___ 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
[OSL | CCIE_Voice] Outbound PSTN call drops
You may want to look into Bug ID: CSCsx67255...link below. http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsx67255&from=summary *Inder Singh* CCIE™ Voice #38235 Sr. Network Engineer, Unified Communications ___ 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
Re: [OSL | CCIE_Voice] Outbound PSTN call drops
Hi, What is the settings in your gateway CUCM configuration. Have you checked early offer option. Please send debug of following command. debug voip ccapi inout debug h225 q931 debug h245 asn1 Thanks, Ramcharan Arya CCIE # 28926 (Voice/R&S) On Mon, Oct 21, 2013 at 12:32 PM, Samson Kareem wrote: > 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 > ___ 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
Re: [OSL | CCIE_Voice] Outbound PSTN call drops
Hi Sandeep, ios is 12.4 22 T Thanks Samson From: samson_kar...@hotmail.com To: ccie_voice@onlinestudylist.com Date: Mon, 21 Oct 2013 22:14:24 + Subject: Re: [OSL | CCIE_Voice] Outbound PSTN call drops Hi Daniel, Viki Thanks for the tips..I'll look a bit deeper into the H245 capabilities exchange next time I lab. If I figure it out, I'll let you know. @ Viki - yes I tried the channel negotiation command, no joy and no slip errors or anything on the controller.. Thanks Samson From: dpa...@fidelus.com To: samson_kar...@hotmail.com; ccie_voice@onlinestudylist.com Subject: RE: [OSL | CCIE_Voice] Outbound PSTN call drops Date: Mon, 21 Oct 2013 21:52:49 + 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/8043215D
Re: [OSL | CCIE_Voice] Outbound PSTN call drops
Hi Daniel, Viki Thanks for the tips..I'll look a bit deeper into the H245 capabilities exchange next time I lab. If I figure it out, I'll let you know. @ Viki - yes I tried the channel negotiation command, no joy and no slip errors or anything on the controller.. Thanks Samson From: dpa...@fidelus.com To: samson_kar...@hotmail.com; ccie_voice@onlinestudylist.com Subject: RE: [OSL | CCIE_Voice] Outbound PSTN call drops Date: Mon, 21 Oct 2013 21:52:49 + 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 Oc
Re: [OSL | CCIE_Voice] Outbound PSTN call drops
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/80432
Re: [OSL | CCIE_Voice] Outbound PSTN call drops
Hi Samson, Have you hard coded the isdn channel to ascending or descending. If so try to remove that and check. Did you try isdn bchan-negotiate? Did you see any errors on the output of show controllers t1/e1, and show isdn status Thanks, Viki On Monday, October 21, 2013, Samson Kareem wrote: > 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 > > -- Sent from IPhone ___ 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
[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
