12-14-2009 03:44 AM - edited 03-15-2019 08:47 PM
Hi,
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.
Thanks.
Regards,
Isaac Romero
Unitronics
Solved! Go to Solution.
12-14-2009 09:27 AM
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
12-14-2009 06:12 AM
Isaac,
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.
HTH,
Art
12-14-2009 07:10 AM
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?
Thanks.
Regards,
Isaac.
12-14-2009 07:41 AM
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?
Thanks,
Art
12-14-2009 07:54 AM
12-14-2009 08:38 AM
Isaac,
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?
Art
12-14-2009 08:58 AM
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.
Thanks.
Regards,
Isaac.
12-14-2009 09:19 AM
Isaac,
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?
Thanks,
Art
12-14-2009 10:23 AM
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,
Isaac.
12-14-2009 08:19 AM
Take debug isdn q931 for both a wrorking and non-working call.
12-14-2009 08:30 AM
12-14-2009 09:05 AM
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.
12-14-2009 10:21 AM
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?
Thanks.
07-12-2010 09:00 AM
Update
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
12-14-2009 08:31 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide