I have a BCM400 v3.6 build 3.1a which fronts a small tech support call centre. I'm suffering from a no-chan error on outgoing calls.
Our PRI configuration is a little complicated, but I'll do my best to describe it. I searched for "no chan" and only got one hit, I checked the recommendation in that posting (B channel selection order). The Telco is supply me ascending sequential, and my BCM is set for decending sequential. BCM monitor doesn't give any indication that the inbound and outbound traffic is hitting in the middle.
Our PRI is oversubscribed, and configured with a number of RTM "pools". All 23 B channels are provisioned, but 26 PSTN are actually configured in three pools.
RTM1 is an inbound pool (size 10) for our 800 numbers
RTM2 is an inbound/outbound pool (size 8) for local calls
RTM3 is an outwats pool (size 8) for our outbound long distance
Maximum call concurrency is 23 calls combined from all three RTM's.
When we purchased this solution I was assured that the DMS100 would "route" the calls properly to these RTM pools and no special programming changes were needed on the BCM ... I should have known better!
Initially unconvinced, I played "what if" games with the sales rep and the DMS programmer she had on the phone and put forth some basic scenarios
Q. Lets say I've got 8 outbound long distance calls, now I dial a long distance call, what happens?
A. The switch (DMS100) would use one of your bidirectional PSTN (RTM2 above) to place the call and your local call capability (in and out) will be reduced by 1 call until that 9th call you just placed disconnects.
Q. Lets say I've got 10 people on incoming 800 calls and an 11th customer calls an 800 number, what happens?
A. The switch (DMS100) would use one of your bidirectional PSTN (RTM2 above) to place the call and your local call capability (in and out) will be reduced by 1 call until that 11th call you just received disconnects.
I had NO problem with either of the above statements. I should have known the problems I was in for when I get a call from a DMS programming 2 days before my PRI cutover and he tells me he doesn't understand what they asked him to program!
What I ended up with (after spending hours on the phone with the PRI repair dept)
1. None of my outbound long distance calls were using RTM3, all calls were using RTM2. RTM3 was completely idle.
2. My inbound 800 calls are using RTM1, but the 11th caller gets "busy"
After much screaming and tearing of hair and despite the assurances from my BCM supplier that "it's a Bell problem" and the instance of Bell that "it's a Nortel problem" I read enough of the documentation to create a new route
Route 000 - Pool A (my analog emergency lines)
Route 001 - PRI-A, Service Type: Public
Route 002 - PRI-A, Service Type: Outwats, ServiceID 1
Destination Code 91 uses Route 002, Absorb 1
Destination code 9A uses Route 001, Absorb 1
Magically my outbound LD calls started using RTM3, my outbound local calls RTM2 and the everything in the world was once again serene. Of course, this was too good to last...
Call volume has increased, and I've started to receive "busy signals" on inbound 800 calls, and "no chan" errors on outbound LD calls. After much watching of BCM monitor I determined:
1. RTM1 was giving busy signals to the callers after 10 concurrent incoming calls
2. RTM3 was giving no-chan errors after 8 concurrent outbound LD calls
More screaming at Bell and my BCM provider resulted in the normal responses... the BCM provider telling me it's a Bell problem, and Bell telling me that it's the responsibility of the BCM to choose a different route if RTM3 is full. Back into the BCM docs I dove in a panic, looking again for a solution.
Here's what I came up with:
A. I created a new Scheduled Service->Routing Service called "OutDial", active from 0100-0100 (24 hour) with overflow Yes.
B. In the Destination Code->91->Schedules->Outdial I added First: Route 002 (my outwats RTM3 route) Second: Route 001 (my normal PRI local dial route) Third: Route 000 (my emergency two analog lines in Pool A)
My hope was that, upon getting a "no chan" when trying to place the call on Route002 (outwats) that the BCM would fall back to Route 001 (my bidirectional pool) and place the call. NO SUCH LUCK :< My control sets all show that the schedule is active, but the 9th concurrent outbound calls still yields "no chan" on the set.
Can anyone shed some light on this as my BCM provider seems to be over their head on this, they escalated a ticket to Nortel (went all the way to a 2nd level tech) only to get a "Bell sets that up in the DMS" response. Bell is adamant that it's a BCM problem and they can't do anything about it.
We paid $500 for a traffic study that was all but useless (of course, the week that Bell was able to schedule the study we had lower then normal traffic). Until I get this call routing problem fixed I can't say for sure whether or not I'm hitting the 23 call concurrency limit or not. All my testing says I'm not and that it's only a routing problem. I'm not about to spend $4000+ on an expansion chassis and PRI card unless I can be satisfied that it's necessary.
Has anyone encountered and slain this particular beast, I'd greatly love to hear your solution(s). Thanks.
Our PRI configuration is a little complicated, but I'll do my best to describe it. I searched for "no chan" and only got one hit, I checked the recommendation in that posting (B channel selection order). The Telco is supply me ascending sequential, and my BCM is set for decending sequential. BCM monitor doesn't give any indication that the inbound and outbound traffic is hitting in the middle.
Our PRI is oversubscribed, and configured with a number of RTM "pools". All 23 B channels are provisioned, but 26 PSTN are actually configured in three pools.
RTM1 is an inbound pool (size 10) for our 800 numbers
RTM2 is an inbound/outbound pool (size 8) for local calls
RTM3 is an outwats pool (size 8) for our outbound long distance
Maximum call concurrency is 23 calls combined from all three RTM's.
When we purchased this solution I was assured that the DMS100 would "route" the calls properly to these RTM pools and no special programming changes were needed on the BCM ... I should have known better!
Initially unconvinced, I played "what if" games with the sales rep and the DMS programmer she had on the phone and put forth some basic scenarios
Q. Lets say I've got 8 outbound long distance calls, now I dial a long distance call, what happens?
A. The switch (DMS100) would use one of your bidirectional PSTN (RTM2 above) to place the call and your local call capability (in and out) will be reduced by 1 call until that 9th call you just placed disconnects.
Q. Lets say I've got 10 people on incoming 800 calls and an 11th customer calls an 800 number, what happens?
A. The switch (DMS100) would use one of your bidirectional PSTN (RTM2 above) to place the call and your local call capability (in and out) will be reduced by 1 call until that 11th call you just received disconnects.
I had NO problem with either of the above statements. I should have known the problems I was in for when I get a call from a DMS programming 2 days before my PRI cutover and he tells me he doesn't understand what they asked him to program!
What I ended up with (after spending hours on the phone with the PRI repair dept)
1. None of my outbound long distance calls were using RTM3, all calls were using RTM2. RTM3 was completely idle.
2. My inbound 800 calls are using RTM1, but the 11th caller gets "busy"
After much screaming and tearing of hair and despite the assurances from my BCM supplier that "it's a Bell problem" and the instance of Bell that "it's a Nortel problem" I read enough of the documentation to create a new route
Route 000 - Pool A (my analog emergency lines)
Route 001 - PRI-A, Service Type: Public
Route 002 - PRI-A, Service Type: Outwats, ServiceID 1
Destination Code 91 uses Route 002, Absorb 1
Destination code 9A uses Route 001, Absorb 1
Magically my outbound LD calls started using RTM3, my outbound local calls RTM2 and the everything in the world was once again serene. Of course, this was too good to last...
Call volume has increased, and I've started to receive "busy signals" on inbound 800 calls, and "no chan" errors on outbound LD calls. After much watching of BCM monitor I determined:
1. RTM1 was giving busy signals to the callers after 10 concurrent incoming calls
2. RTM3 was giving no-chan errors after 8 concurrent outbound LD calls
More screaming at Bell and my BCM provider resulted in the normal responses... the BCM provider telling me it's a Bell problem, and Bell telling me that it's the responsibility of the BCM to choose a different route if RTM3 is full. Back into the BCM docs I dove in a panic, looking again for a solution.
Here's what I came up with:
A. I created a new Scheduled Service->Routing Service called "OutDial", active from 0100-0100 (24 hour) with overflow Yes.
B. In the Destination Code->91->Schedules->Outdial I added First: Route 002 (my outwats RTM3 route) Second: Route 001 (my normal PRI local dial route) Third: Route 000 (my emergency two analog lines in Pool A)
My hope was that, upon getting a "no chan" when trying to place the call on Route002 (outwats) that the BCM would fall back to Route 001 (my bidirectional pool) and place the call. NO SUCH LUCK :< My control sets all show that the schedule is active, but the 9th concurrent outbound calls still yields "no chan" on the set.
Can anyone shed some light on this as my BCM provider seems to be over their head on this, they escalated a ticket to Nortel (went all the way to a 2nd level tech) only to get a "Bell sets that up in the DMS" response. Bell is adamant that it's a BCM problem and they can't do anything about it.
We paid $500 for a traffic study that was all but useless (of course, the week that Bell was able to schedule the study we had lower then normal traffic). Until I get this call routing problem fixed I can't say for sure whether or not I'm hitting the 23 call concurrency limit or not. All my testing says I'm not and that it's only a routing problem. I'm not about to spend $4000+ on an expansion chassis and PRI card unless I can be satisfied that it's necessary.
Has anyone encountered and slain this particular beast, I'd greatly love to hear your solution(s). Thanks.
