Re: ISDN PRI not overflowing to other PRIs

emorgan · ‎10-22-2004

I have two sites equipped with T1-PRIs. At the first site the PRI is outbound C.O. limited to 15 channels to preserve some channels for incoming call center calls . This PRI is configured in a route-group along with the other site's PRI for overflow.

It is expected that when reaching the maximum number of outbound channels on the first T1, the route-group or route-list will overflow to the next available PSTN circuit.

This is not the behaviour I have encountered neither at the customer site nor in the lab. The PSTN PRI returns a "no channel available" on the 16th call and the CCM stops right there, issuing a busy signal to other callers. No attempt is made by CCM to go through the rest of the route-group.

I have seen this behaviour in both CCM 3.3.3 and 3.3.4. I have 3745 gateways running 12.3.7T2 with MGCP backhaul.

Is there some way of making this work ??

Thanx for your input.

Eric

debug isdn q931 -->

00:28:33: ISDN Se1/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0002

Bearer Capability i = 0x8090A2

Standard = CCITT

Transer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98302

Exclusive, Channel 2

Calling Party Number i = 0x0081, '7782'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x80, '6913500'

Plan:Unknown, Type:Unknown

00:28:33: ISDN Se1/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8002

Channel ID i = 0xA98382

Exclusive, Channel 2

00:28:33: ISDN Se1/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x8002

Cause i = 0x80A2 - No circuit/channel available

00:28:34: ISDN Se1/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x0002

00:28:34: ISDN Se1/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8002

lfulgenzi · ‎10-22-2004

I believe the problem here is that as far as CCM is concerned, the channels are available, it's just that the C.O. is reserving them. The C.O. will simply give you a busy signal as the call is attempted. The best way would be to allow only CCM to use only so many channels on the T1 - but I'm not aware of any way to do that.

That's my educated guess after talking with my carrier about our setup. We have multiple T1s so we simply start at the bottom of our list and they start at the top. We are prepared to run into the same reservation issue, but ours are topped at high numbers at both locations so we should be OK.

If you find a way to resolve this, let the forum know.

rnarayana · ‎10-22-2004

Hello,

If CO is giving you only 15 channels you need to setup only 15 channels in Callmanager too ie you need to busy out the rest of the channels in callmanager so that ccm will not send the calls on these changes.To do this follow below procedure.

Go to CCM service parameter.Choose callmanager and under that choose advanced

Under PRI and MGCP there is one parameter called Channel-b channel maintenance status 1.Againt this parameter configure the following

=000000000000000111111111

gatewaymgcp_name should be the same as the gateway name under gateway page in callmanager.

Also when you do this it is important to check the following parameter on the gateway"enable status poll".This is in the gateway page.

If you do this CCM will not try to send the calls on 16 to 23 channels.

I hope this helps.

Thanks,

Radhika

lfulgenzi · ‎10-22-2004

Ah - yes! I remember that feature now. Never thought about using that for busying out in cases like this.

emorgan · ‎10-23-2004

Thanks Radhika,

The C.O. (DMS-100) is really giving me 23 channels, however only 15 outbound calls are allowed. Inbound, I believe 17 calls are allowed. This is to make sure that outbound calls cannot tie up the full 23 channels thus preventing inbound calls to the IP call center.

For example, if there are currently 17 inbound calls, the next outbound calls will use channels 18 and up.

I don't think I can busyout specific channels as I need the full 23.

I see only two solutions. Either the CCM can understand the q931 message "no channel available" and continue through its route-group/list OR I would need a way to limit outbound calls - and only outbound calls - to a certain number for a specific PRI, after reaching the limit the CCM would coninue through its route-group/list.

Eric

anup.anand · ‎10-23-2004

Check this service parameter for Callmanager Service " Stop Routing On User Busy Flag "

CCM help says "This parameter specifies whether to route the call because the user is busy. When set to True and a call is being routed through a route list, which detects the user busy during the release of the call, the system attempts no re-routing to the next device in the route list, and the call gets released with the associated cause.

When this flag is set to False, the route list reroutes the call if more devices exist in the list."

Default: true.

Try changing this to false and see if it helps. I haven't got a chance to test this. Please post the results, if you are testing this.

Also, if you want to avoid Callmanager to even try sending the 16 th outbound call to the same PRI link, then the suggestion made in one of the earlier posting would help.

Regards,

Anup

rlyons · ‎10-24-2004

Put the gateway in a "Location" that has enough CallManager allocated bandwidth to support only the number of calls you whish to use on that PRI. Use AAR to reroute the calls to the other (remote site’s) PRI when the bandwidth maximum is reached.

I assume you are doing centralized call processing.

emorgan · ‎10-25-2004

lfulgenzi & Radhika:

I can't busyout any channels because I need the full 23. The maximum of 15 outbound is to preserve a minimum of 7 channels for inbound calls to the call center. If I don't put a limit, after 23 outbound calls, the call center would be unreachable.

Unless.... busying out the channels using the "Channel-b channel maintenance status" does not affect inbound calls.

I did try this parameter though, but nothing happenned (I did enable status poll on the gateway and also reset the gateway).

Anup:

I did try the parameter "Stop Routing On User Busy Flag". Same thing. It might be because the DMS-100 is returning an RX_Call_proceeding" message before the RX_Disconnect message. The CallManager maybe thinking that the call has been placed and then cutoff.

rlyons:

The location thing is a excellent suggestion. It is a good work around but I would prefer the call manager re-acting correctly to the ISDN messages. I will use this as a last resort as I don't want to go AAR if there is a simpler solution.

thank you all.

I am also talking to my Cisco SEs and I will keep you posted.

Eric

emorgan · ‎11-02-2004

Works fine with H323.

Just tested H323 in the lab and it seems to recognize the ISDN failure and continue down the route-list.

The exact same setup in MGCP does not work.

Will pursue this with my local SE as most of our sites run MGCP.