Outbound calls from 79xx don't work, calls from CUPC/CIPC work (Requested circuit/channel not available)

Answered Question
Dec 14th, 2009


We have a CUCM 7.1 and a 2821 with 2PRI connected to the PSTN.

When calling outbound from an IP Phone 79xx (7911, 7945, etc) to the PSTN we got the following error:

Dec 14 10:18:26.249: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x070D
        Cause i = 0x80AC - Requested circuit/channel not available

When calling from a Softphone (CUPC or CIPC) the call works fine. Also when using "csim start" in the gateway it does work fine.

We tried to change the IP address of a 79xx into the Data Vlan as the Softphones, but the problem remains the same.

Does anyone faced a similar problem? Or do you know how to solve it?

I attach the configs and the debug traces.



Isaac Romero


I have this problem too.
0 votes
Correct Answer by maharris about 7 years 1 month ago

We have run into problems like this lately, go into the Enterprise Parameters and turn off 'advertize g722), and then make sure that you have a voip peer in the gateway that includes the codec that you want to use, and put an 'incoming called number . (dot)" under that peer, to force calls coming into the router to match that peer.

Mary Beth

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (5 ratings)
asandborgh Mon, 12/14/2009 - 06:12


Normally Requested circuit/channel not available means you are experiencing glare on the PRI (about 99% of the time).  Try the command "isdn bchan-number order ascending (or descending) on the serial interface for the PRI - you will need to shutdown/no shut the int and reset it in CCM for the change to take effect.  Your's looks like it is running ascending right now, which is confusing because it does not show in your configuration.  If you can ask your carrier which channel they are selecting for sending incoming calls, high or low, and set yours the opposite.



Isaac Romero Mon, 12/14/2009 - 07:10

Hi Art,

Thanks for your answer.

It is running descending, but when I capture the debug I was testing it with ascending, that's why channel 0 was used.

The carrier is selecting channels in ascending order, and we are selecting them desceding.

This is the output from a working call from CUPC using channel 30:

Dec 14 15:04:30.886: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8  callref = 0x00AD
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech 
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA9839F
                Exclusive, Channel 31
        Progress Ind i = 0x8183 - Origination address is non-ISDN 
        Calling Party Number i = 0x00A1, '1000'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0x80, '608257811'
                Plan:Unknown, Type:Unknown
Dec 14 15:04:30.954: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8  callref = 0x80AD
        Channel ID i = 0xA9839F
                Exclusive, Channel 31
Dec 14 15:04:34.654: ISDN Se0/0/0:15 Q931: RX <- ALERTING pd = 8  callref = 0x80AD
        Progress Ind i = 0x8488 - In-band info or appropriate now available
Dec 14 15:04:37.574: ISDN Se0/0/0:15 Q931: RX <- CONNECT pd = 8  callref = 0x80AD
        Date/Time i = 0x090C0E100425
                Date (yr-mm-dd)   = 09-12-14
                Time (hr:mnt:sec) = 16:04:37
        Connected Number i = '!', 0x83, '608257811'
Dec 14 15:04:37.574: %ISDN-6-CONNECT: Interface Serial0/0/0:30 is now connected to 608257811 N/A
Dec 14 15:04:37.574: ISDN Se0/0/0:15 Q931: TX -> CONNECT_ACK pd = 8  callref = 0x00AD
Dec 14 15:04:43.574: %ISDN-6-CONNECT: Interface Serial0/0/0:30 is now connected to 608257811 N/A
Dec 14 15:04:44.446: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8  callref = 0x80AD
        Cause i = 0x8090 - Normal call clearing
Dec 14 15:04:44.450: %ISDN-6-DISCONNECT: Interface Serial0/0/0:30  disconnected from 608257811 , call lasted 6 seconds
Dec 14 15:04:44.450: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8  callref = 0x00AD
Dec 14 15:04:44.466: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8  callref = 0x80AD

With the 79xx phones we are still facing the same problem.

It is a very strange issue that using the same extension on a CUPC and on a 7945 it only works with the Softphone... isn't it?




asandborgh Mon, 12/14/2009 - 07:41

HI Isaac,

Very odd.  Would  you try a couple things please:

Can you ping the IP phones form the gateway using the gig 0/0 as the source address?

Can you bring up a CIPC call and then press ? twice to see the codec being selected?



asandborgh Mon, 12/14/2009 - 08:38


Whats interesting here (and I think you already noticed since you put the IP phone on the data subnet) is that your gateway is SENDING the message.  That indicates that the gateway can't set up the call with the IP phone.  The gateway is obviously able to communicate with CCM since it is trying to place the call, but something is interferring with the RTP setup (it looks like).

Are these devices in the same physical location?  Any firewall in between that would allow H.323, but not RTP?


Isaac Romero Mon, 12/14/2009 - 08:58

Hi Art,

Yes, both devices are in the same location. In fact, my laptop with the CIPC is connected to the 7945 IP and I have tested with the switch port on dual vlan and also only data vlan (and setting the TFTP manually on the IP phone) and it didn't work neither.

I asked about the firewall to the networking guys, and they told me there is no RTP blocking configured.




asandborgh Mon, 12/14/2009 - 09:19


A couple of things that may help:

Since you are running your laptop off of one of the IP phones with the issue can you enable "Span to PC port" and run a Wireshark session while you are trying to make a call to see the call setup with CCM and the gateway?

Also can you run  a CCM trace on the subscriber that the phone and (hopefully) the gateway are registered with so we can see the interaction from the CCM point of view?



Isaac Romero Mon, 12/14/2009 - 10:23

Hi Art,

I am no longer at the customer facilities, so I can not take the traces right now. I will try to do it on wednesday and will let you know.

Thanks for your help,


Paolo Bevilacqua Mon, 12/14/2009 - 09:05

It would have beens easier if you had included the debugs directly.

However, the router is disconnecting the call:

Dec 14 16:27:19.951: ISDN Se0/0/0:15 Q931: TX -> DISCONNECT pd = 8  callref = 0x00BD
        Cause i = 0x80AC - Requested circuit/channel not available

This means something into you partition config, like codec or device settings are wrong.

Isaac Romero Mon, 12/14/2009 - 10:21

Hi p.bevilacqua,

Both the CUPC and the 79xx are on the same partition, the same DP and the same region, so I think they should use the same codec and the same settings. Is there anything I can check regarding this?


iptuser55 Mon, 07/12/2010 - 09:00


I took the Codec out and it still worked ok. It seems by having a incoming called-number on a VOIP DP for the destination or indeed answer-address to match the incoming orginiating number all seem to work. If there is not other Codec commends it uses the default G729 ???

dial-peer voice 777 pots
destination-pattern 19077xxxxxxxx
port 0/0/0:15
forward-digits 11

dial-peer voice 590 voip
answer-address *1000

if I repeated the test but dialled the number as below from another phone it failed - Rung out but on answer cuts off

dial-peer voice 778 pots
destination-pattern 9077xxxxxxxx
incoming called-number .
port 0/0/0:15
forward-digits 11

One thing you might want to check,  in your setup message your called number is reporting only 9 digits.

Is this correct for your dialing area?

      Calling Party Number i = 0x00A1, '1000'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0x80, '608257811'
                Plan:Unknown, Type:Unknown

Paolo Bevilacqua Mon, 12/14/2009 - 08:37

One thing you might want to check,  in your setup message your called number is reporting only 9 digits.

The OP is not the US, as can be evinced by the E1 interface numbering.

Isaac Romero Mon, 12/14/2009 - 09:02

Hi Ryan, in Spain local and mobile numbers are only 9 digits. Also I tried it with international calls and I got the same error (it works with CIPC/CUPC but not with 79xx phones).

I have a hard time believing that this is actually a problem with the phone type itself.  It seems much more likely that it is a problem with either the rtp stream as others have suggested (perhaps even a codec issue).  Or a problem with the actual call setup itself and dial plan. 

One thing you might want to check ( i have only seen one instance of this ever happening) is whether or not your PSTN provider is filtering outbound calls based on calling number.


Correct Answer
maharris Mon, 12/14/2009 - 09:27

We have run into problems like this lately, go into the Enterprise Parameters and turn off 'advertize g722), and then make sure that you have a voip peer in the gateway that includes the codec that you want to use, and put an 'incoming called number . (dot)" under that peer, to force calls coming into the router to match that peer.

Mary Beth

Isaac Romero Mon, 12/14/2009 - 11:29

Hi Mary Beth,

I have applied both the changes you suggested (disabling g722 advertising and including "incoming called number ." into a voip dial-peer) and now it is working fine!

I really don't know how this can only affect just to IP phones 79xx and not to CIPC/CUPC.... could please provide me some more information?

It's just to understand the problem, and to avoid it again in the future... anyway, thanks a lot!



asandborgh Mon, 12/14/2009 - 11:44


Glad to hear that fixed it.

Just out of curiousity, what version of CIPC are you running (this likely impacted the situation)?



Isaac Romero Mon, 12/14/2009 - 11:53

Hi Art,

CIPC version is and CUPC version is 7.0(2.13496).

I am pretty sure that what solved this was including the "incoming called-numer ." command into a voip dial-peer, because I didn't restart the phones after disabling the g722 advertisement.

I am trying to understand why this was happening only with the 79xx phones, as they should use the same dial-peers that the softphone... I would really appreciate if you could give more information about this, so I could explain it to the customer and also take it into account in the future.

Thanks for your help.



asandborgh Mon, 12/14/2009 - 12:05


CIPC did not support G.722 until version 7  so it was not coming up in the negotiation (I'm not sure about CUPC - if it can handle G.722).  I'm willing to bet that during the codec negotiation CCM was advertising and selecting G.722 for the IP phones and the gateway could not handle it.  By turning off advertisements of 722 and making sure a DP was matched with a legitimate codec they could then agree.

If anyone else have a better explanation, please share - I'm just making an eduacted guess.....

I've had issues with G.722 before but had not seen this one - good to know!



maharris Mon, 12/14/2009 - 12:34

Your guess is a good one, when we ran into it, I saw the bad codec requested in the debug voip ccapi inout output.  It is easy to get thrown off by what looks like a PRI problem, too - because of the requested circuit/channel error - Cisco has a special language, I guess - and that G722 has been nothing but trouble, I don't know why they have it on by default!  I am glad that worked!

Mary Beth

maharris Mon, 12/14/2009 - 12:38

We have found that you really want to force your incoming calls to a voip peer that has all of the characteristics that you require, like no vad, dtmf

relay, codecs, etc - we always try to use the incoming called number . to do that, since the list of decision making points for dial peers gets weird, and you  can have strange problems if you are matching the wrong one for some obscure reason, or worse, matching dial peer 0, which is extremely limited.

Mary Beth

Isaac Romero Mon, 12/14/2009 - 10:38

Hi Ryan,

I also though on this, and tried to change the calling number but it didn't make any changes. I tried to change it on the route pattern, on the gateway options setting it to external phone number mask, to default, to restricted, but the problems persists. Also I tried to share the same DN both on the CIPC and on the 7945 so the partition/css is the same, and it only works with the softphone.


asandborgh Mon, 12/14/2009 - 10:58


I think Mary Beth has probably pointed you in the correct direction - try her fix first when you have a chance.

Mary - kudos - five points to you!


iptuser55 Thu, 07/08/2010 - 06:04

I know this was a while ago but I also had the same type of problem today - "Channel request not available" on the debugs . Every device uses the same CSS and the same H323 GW however if you dial using a 7937 phone you fail,  dial using a 7942 it works. Replicated in my office using a 7962 works,  used a 7937 failed- Nothing to do with the network as my office is remote from where the original issue is- Reassigned another CSS to route it out on a different GW - MGCP it works, changed it back to the CSS so to route via H323 - fails. By adding the incoming called-number .  to a specific test DP it works- I did no other changes. We also had a incoming called-number . DP as below so that should solved the problem before getting to the normal 9T dial-peers for routing

dial-peer voice 1 pots
incoming called-number .

Did anyone get any answers


iptuser55 Thu, 07/08/2010 - 08:10

Further testing was that if I only added the "incoming called number .  " to an outgoing POTS DP  - the call the rung ok - previously it would cut

off as before answering however now on answer it disconnects. By adding

Dial-peer voice z voip

incoming caled-number .

codec g711alaw

Everything worked. In our System we did not advertise G722 either

It works but why??

asandborgh Thu, 07/08/2010 - 08:24

Hi there,

Try taking out the explicit codec assignment line:

codec g711alaw

and see if it fails. If so it tells you it is definitely still a codec selection issue, because it will likely default to G729.  Then the question becomes why won't the phone and gateway work with that codec.

Happy Trails,


maharris Fri, 07/16/2010 - 09:28

The only way to see exactly what it is doing is to do a debug voiip ccapi inout, and see what peer is being matched, what characteristics are being requested, etc.  I suppose different phone types could request different codecs, and I think the default on a dial peer is g729, so if you don't have a codec specified, or a codec class applied, it will use that.  G729 might be a problem because of regions config, or something like that.  I have also seen problems with g729 with silence suppression, had to go into service parameters and turn it off  - Strip G.729 Annex B(Silence Suppression) from Capabilities, set to true (that was a TAC case, for problems out an MGCP gateway after router upgrade, some phones worked, some did not)

Mary Beth

iptuser55 Fri, 07/16/2010 - 09:36

I got it working but had to anchor the call on a voip dia-peer first by either incoming called-number.  - whic I will do in produciton or for testing by answer-address xxxx  No Codec`s are assigned to the DP`s so the  codec must be G729???. Again the problem only effected 7937 no other phones

asandborgh Fri, 07/16/2010 - 09:48

From the IOS 12.4 command reference for the dial-peer codec


Command Default

g729r8, 30-byte payload for VoFR and VoATM.
g729r8, 20-byte payload for VoIP.
See Table 12 for valid entries and default values for codecs.


This Discussion

Related Content