[cisco-voip] Requested circuit/channel not available

Hefin James [ahj] ahj at aber.ac.uk
Wed Apr 2 14:20:06 EDT 2014


Restarting the cluster is the only thing I haven't done yet. I do that tomorrow morning before the Telco engineer arrives on site.
Its definitely a circuit issue, as it followed onto another PRI interface.

I'll report back if/when I get a resolution.

Thanks everyone,
Hefin

On 2 Apr 2014 18:32, Daniel Pagan <dpagan at fidelus.com> wrote:
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<mailto: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<mailto:ahj at aber.ac.uk>>
Date:
To: cisco-voip at puck.nether.net<mailto: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<mailto:ahj at aber.ac.uk>>
To: "cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>" <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: Re: [cisco-voip] Requested circuit/channel not available
Message-ID: <CBD0BE7FB1306F489E0B3739A256A57007EB4309 at EXMB1.pau.local<mailto: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<mailto:mshinwari at fidelus.com>]
Sent: 02 April 2014 01:41
To: Hefin James [ahj]; cisco-voip at puck.nether.net<mailto: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<mailto:ahj at aber.ac.uk>>
Date:
To: cisco-voip at puck.nether.net<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140402/74e967de/attachment.html>


More information about the cisco-voip mailing list