[cisco-voip] Requested circuit/channel not available
Amit Kumar
amit3.kum at gmail.com
Thu Apr 3 01:01:27 EDT 2014
Here I would agree with Dan, as if routelist busy condition is hit, we
won't see a SETUP message going out on the wire.
Cucm, will drop the call as soon as it matches with RL, after DA.
On 02-Apr-2014 11:49 pm, "Rajkumar Yadav" <rajkumaryadav at y7mail.com> wrote:
> Can we get the SDI & SDL traces for the failed call.
>
> Also would like to know the CUCM version for the same.
>
> Kind Regards,
> Raaj.
>
> Sent from Yahoo Mail on Android<http://overview.mail.yahoo.com/mobile/?.src=Android>
>
> ------------------------------
> * From: * Daniel Pagan <dpagan at fidelus.com>;
> * To: * Rajkumar Yadav <rajkumaryadav at y7mail.com>; ahj at aber.ac.uk <
> ahj at aber.ac.uk>;
> * Cc: * cisco-voip at puck.nether.net <cisco-voip at puck.nether.net>;
> * Subject: * RE: [cisco-voip] Requested circuit/channel not available
> * Sent: * Wed, Apr 2, 2014 5:30:54 PM
>
> Just for clarification, this defect is unrelated to the issue that was
> described below. The defect you're referring to is related to RouteListCdrc
> detecting the destination gateway/trunk as down when in actuality it is up
> and available. Hefin swapped the patch cables between two T1s and the
> problem followed the swap. If this defect was encountered, I would suspect
> the problem would stay on the endpoint since swapping cables are
> transparent to RouteListControl and RouteListCdrc.
>
>
>
> Hope this helps
>
>
>
> - Dan
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] *On Behalf
> Of *Rajkumar Yadav
> *Sent:* Wednesday, April 02, 2014 12:59 PM
> *To:* ahj at aber.ac.uk
> *Cc:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] Requested circuit/channel not available
>
>
>
> Hi,
>
>
>
> This below issue is BUG and it could be resolved once the Cluster reboot
> is done for all the nodes.
>
>
>
> BUG ID *CSCum85086*
>
>
>
> *Description : **Outbound call failing through the Route Group / Route
> List, with the cause code (41), to RouteListControl because all devices are
> busy/stopped*.
>
>
>
> Yes in the SDL traces you will find the error.
>
>
>
> |RouteListCdrc::terminateCall - Sending CcRejInd, with the cause code
> (41), to RouteListControl because all devices are busy/stopped.
>
>
>
> *Cause : *It may arise at time of provisioning service, where the changes
> are not updated and stuck in the database.
>
>
>
> Workaround :
>
>
>
> From OS administration
>
>
>
> run the utils service list on all the nodes to check which all service are
> running.
>
>
>
> then run the utils system restart starting from PUB and then SUB.
>
>
>
> Make sure you have the backup for safety purpose.
>
>
>
> Trust I tried out doing the ISDN Busy out channel command to find the Bad
> B-channel but it wasn't a Bad B-channel.
>
>
>
>
>
>
>
> Kind Regards,
>
> Raaj.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Message-ID: <vx04xjc1vrvu3kn3ed2cc1qe.1396399061194 at email.android.com>
> Content-Type: text/plain; charset="Windows-1252"
>
> James,
>
> Whats "sh isdn q931 status" showing?.
>
> Do a "show isdn status" this will show which channels are open and which
> ones are out of service. If you have some channels up and its mission
> critical you can always busy out the "bad" channels effectivily making a
> customized fractional pri
>
> And yes do engage the vendor at this point. A shut no shut on the isdn
> interface would not hurt at this point either.
>
> Regards
>
>
> Mehtab Shinwari | CCNP RS/V
> Senior Support Engineer
>
>
>
> -------- Original message --------
> From: "Hefin James [ahj]" <ahj at aber.ac.uk>
> Date:
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] Requested circuit/channel not available
>
>
> Hi,
>
> Started to get this issue this morning with one of our MGCP gateways.
> Incoming calls are working correctly on an ISDN30, but outgoing calls are
> being denied, and re-routed via a backup route.
> Outgoing calls are hitting the gateway, but is getting a ?Requested
> circuit/channel not available? See trace below.
>
> I?ve tried to change the channel selection order, but still the same.
> I?ve checked everything that I can think of, and I?m beginning to think
> that this is a Telco issue, but thought that I?d ask the group to see if
> there is anything else to check before I take it up with BT.
>
> Thanks,
> Hefin
>
> 2014-04-01 22:07:55 local3/7 Apr 1 21:07:54.602: ISDN Se0/0/0:15 Q931:
> TX -> SETUP pd = 8 callref = 0x0004
> 2014-04-01 22:07:55 local3/7 Sending Complete
> 2014-04-01 22:07:55 local3/7 Bearer Capability i = 0x8090A3
> 2014-04-01 22:07:55 local3/7 Standard = CCITT
> 2014-04-01 22:07:55 local3/7 Transfer Capability = Speech
> 2014-04-01 22:07:55 local3/7 Transfer Mode = Circuit
> 2014-04-01 22:07:55 local3/7 Transfer Rate = 64 kbit/s
> 2014-04-01 22:07:55 local3/7 Channel ID i = 0xA9839F
> 2014-04-01 22:07:55 local3/7 Exclusive, Channel 31
> 2014-04-01 22:07:55 local3/7 Calling Party Number i = 0x0081, '2456'
> 2014-04-01 22:07:55 local3/7 Plan:Unknown, Type:Unknown
> 2014-04-01 22:07:55 local3/7 Called Party Number i = 0x80, '622456'
> 2014-04-01 22:07:55 local3/7 Plan:Unknown, Type:Unknown
> 2014-04-01 22:07:55 local3/7 Apr 1 21:07:54.682: ISDN Se0/0/0:15 Q931:
> RX <- RELEASE_COMP pd = 8 callref = 0x8004
> 2014-04-01 22:07:55 local3/7 Cause i = 0x82AC - Requested
> circuit/channel not available
>
>
>
> ------------------------------
>
> Message: 13
> Date: Wed, 2 Apr 2014 06:08:18 +0000
> From: "Hefin James [ahj]" <ahj at aber.ac.uk>
> To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
> Subject: Re: [cisco-voip] Requested circuit/channel not available
> Message-ID: <CBD0BE7FB1306F489E0B3739A256A57007EB4309 at EXMB1.pau.local>
> Content-Type: text/plain; charset="Windows-1252"
>
> I've got 2 isdn cards in the gateway, and before things get busy this
> morning, I'm going to swap connections to see if the fault follows the
> connection, or stay with the PRI card.
>
> Details of the current output shown below.
>
> show isdn status
>
> %Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may
> not apply
> ISDN Serial0/0/0:15 interface
> dsl 0, interface ISDN Switchtype = primary-net5
> L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003
> Layer 1 Status:
> ACTIVE
> Layer 2 Status:
> TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
> Layer 3 Status:
> 0 Active Layer 3 Call(s)
> Active dsl 0 CCBs = 0
> The Free Channel Mask: 0xFFFF7FFF
> Number of L2 Discards = 0, L2 Session ID = 16
>
> show isdn service
>
> %Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 0. Layer 3 output may
> not apply
> ISDN Se0/0/0:15, Channel [1-31]
> Configured Isdn Interface (dsl) 0
> Channel State (0=Idle 1=Proposed 2=Busy 3=Reserved 4=Restart
> 5=Maint_Pend)
> Channel : 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1
> State : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
> Service State (0=Inservice 1=Maint 2=Outofservice 8=MaintPend 9=OOSPend)
> Channel : 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
> 1
> State : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
>
> Thanks,
> Hefin
> ________________________________________
> From: Mehtab Shinwari [mshinwari at fidelus.com]
> Sent: 02 April 2014 01:41
> To: Hefin James [ahj]; cisco-voip at puck.nether.net
> Subject: RE: [cisco-voip] Requested circuit/channel not available
>
> James,
>
> Whats "sh isdn q931 status" showing?.
>
> Do a "show isdn status" this will show which channels are open and which
> ones are out of service. If you have some channels up and its mission
> critical you can always busy out the "bad" channels effectivily making a
> customized fractional pri
>
> And yes do engage the vendor at this point. A shut no shut on the isdn
> interface would not hurt at this point either.
>
> Regards
>
>
> Mehtab Shinwari | CCNP RS/V
> Senior Support Engineer
>
>
>
> -------- Original message --------
> From: "Hefin James [ahj]" <ahj at aber.ac.uk>
> Date:
> To: cisco-voip at puck.nether.net
> Subject: [cisco-voip] Requested circuit/channel not available
>
>
> Hi,
>
> Started to get this issue this morning with one of our MGCP gateways.
> Incoming calls are working correctly on an ISDN30, but outgoing calls are
> being denied, and re-routed via a backup route.
> Outgoing calls are hitting the gateway, but is getting a ?Requested
> circuit/channel not available? See trace below.
>
> I?ve tried to change the channel selection order, but still the same.
> I?ve checked everything that I can think of, and I?m beginning to think
> that this is a Telco issue, but thought that I?d ask the group to see if
> there is anything else to check before I take it up with BT.
>
> Thanks,
> Hefin
>
> 2014-04-01 22:07:55 local3/7 Apr 1 21:07:54.602: ISDN Se0/0/0:15 Q931:
> TX -> SETUP pd = 8 callref = 0x0004
> 2014-04-01 22:07:55 local3/7 Sending Complete
> 2014-04-01 22:07:55 local3/7 Bearer Capability i = 0x8090A3
> 2014-04-01 22:07:55 local3/7 Standard = CCITT
> 2014-04-01 22:07:55 local3/7 Transfer Capability = Speech
> 2014-04-01 22:07:55 local3/7 Transfer Mode = Circuit
> 2014-04-01 22:07:55 local3/7 Transfer Rate = 64 kbit/s
> 2014-04-01 22:07:55 local3/7 Channel ID i = 0xA9839F
> 2014-04-01 22:07:55 local3/7 Exclusive, Channel 31
> 2014-04-01 22:07:55 local3/7 Calling Party Number i = 0x0081, '2456'
> 2014-04-01 22:07:55 local3/7 Plan:Unknown, Type:Unknown
> 2014-04-01 22:07:55 local3/7 Called Party Number i = 0x80, '622456'
> 2014-04-01 22:07:55 local3/7 Plan:Unknown, Type:Unknown
> 2014-04-01 22:07:55 local3/7 Apr 1 21:07:54.682: ISDN Se0/0/0:15 Q931:
> RX <- RELEASE_COMP pd = 8 callref = 0x8004
> 2014-04-01 22:07:55 local3/7 Cause i = 0x82AC - Requested
> circuit/channel not available
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140403/85e89489/attachment.html>
More information about the cisco-voip
mailing list