We installed a fractional PRI in a site using h323. Everything seems to be working correctly most of the time until some of the users began complaining that they were unable to receive calls inbound on their phones at random parts of the day...
When troubleshooting using 'debug ISDN q931' I found that the calls were being rejected when the controller tried to use the channels 17 - 31 on the serial interface (see output below):
Apr 15 10:46:21 UTC: ISDN Se1/1:15 Q931: Received SETUP callref = 0x809C callID = 0x00F5 switch = primary-net5 interface = User Apr 15 10:46:21 gmt: %ISDN-6-CHAN_UNAVAILABLE: Interface Se1/1:15 Requested Channel 17 is not available Apr 15 10:46:21 UTC: ISDN Se1/1:15 **ERROR**: CCPMSG_InCall: ChannelID IE invalid 44(0x2C) rejecting call Apr 15 10:46:21 UTC: ISDN Se1/1:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x809C Cause i = 0x80AC18 - Requested circuit/channel not available Apr 15 10:46:41 UTC: ISDN Se1/1:15 Q931: RX <- SETUP pd = 8 callref = 0x003E Bearer Capability i = 0x8090A3 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98392 Exclusive, Channel 18 Calling Party Number i = 0x1083, '353879911644' Plan:Unknown, Type:International Called Party Number i = 0x81, '4495' Plan:ISDN, Type:Unknown Sending Complete
when I make another call the controller tries to use the next channel and will fail if it is between 17 and 31. As soon as it goes back down to channel 1 - 16, it works fine again. Can anyone help me out here. Is there a way to stop using the channels 17-31 and just use channels 1-16?
Would appreciate help on this as I dont want to open a TAC case,
Not for incoming calls, as it is your carrier that is selecting and allocating the inbound channel.
The router is rejecting the call as the carrier is selecting a channel number (in this case 17) which it hasn't got configured.
Two solutions for this problem:
1. Get the PRI carrier to change their equipment so that they only use channels 1-16 for calls.
2. Change your pri-group on the T1/E1 controller so that your channels match up with the number of timeslots that are in use.
option 2 is a disruptive change in that you have to shut the controller down and remove the old pri group. if you do this, also back up your voice-port, serial interface and dial-peers as well, as they will all be removed to some extent or other when you remove the old pri-group.
You can't change the "pri-group timeslots" command on the fly; you need to do a "no pri-group timeslots" command and reconfigure it. When you do this, the serial0/x/0:15 interface will be removed. Anything that points to it (e.g. dial-peers) will have their references to it removed.
The dial-peers will still be there, however the "port" command that references the controller interface will be removed from each of them and you'll need to add them back manually.
Try using the Trunkgroup option. There is a new feature in 12.4 code that allows you to define individual timeslots of the PRI and assign them to different trunk groups. These trunk groups can be used instead of a voice port in a POTS dial peer, so you can direct calls to very specific B channels on the PRI.
Since your other end has configured only 1-16 channels, you can also configure only 1-16 channel for the voice calls and your calls will land only to the specific trunkgroup and avoid landing on other channels which are not configured.
Following is a config that demonstrates this feature on E1 interfaces -
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...