BCM450 Toll-bypass with PRI malfunction

[franlebl]

Hi,

My client has quite a few BCM connected together through VOiP trunks and use tandem switching. Many sites have toll-bypass configured.

One of them was upgraded from a 0x32 with copper lines to a BCM450 with PRI. Toll-bypass worked before the switch but won't now that the new system is up. I compared programming toroughly with other systems in the network and nothing seems to be wrongly programmed. The only difference between the system that does not work and systems that work are that systems that work are all BCM50s with copper lines while the system with which you cannot dial out is a BCM450 with a PRI (DMS-100 protocol). Apart from that, everything else is exactly the same (routing, destination codes, remote access, etc...)

What happens when you use the dial out code is that nothing is heard and then the line is cut; no dial-tone, no fast-busy, no message from the public network.

I'm running out of options... does anyone have any idea what's happening? I'll be monitoring this thread, in case you need further info on the system to help... this is a hot case.

Thanks a lot,
François.

 

[oldestgeek]

Toll bypass can be accomplished in a lot of different ways. You'll need to provide a lot more detail before anyone can help you.

 

[franlebl]

BCMs talk to each other via VOiP gateways. Destination codes are programmed with the ip adress of each system in the network. A remote access package has been assigned to physical lines (when it applies) and active target lines. Destination codes span all available digits (2, 23, 41, 42, 5, 6, 71, 72, etc...) which proved to be quite a hassle when I had to program the PRI in the new BCM450 because the incoming digits of the target lines conflicted with destination code 8; received number have been reduced to 9 to avoid conflicts (first number of received digits is now 1).

All of the BCM are programmed in tandem switch, meaning that when you're in node X calling node Y you simply have to dial the 4 digit extensions. When people want to dial out to toll bypass, they dial the corresponding code of the system located in the city they need to call(4x), wait for the dial tone (if the remote system uses copper lines) and then dial locally.

As above stated, 8 out of 9 systems are working. 7 of those systems are BCM50, and all of them have copper lines. Apart from that difference, everything is programmed exatcly the same (destination codes, remote access, dialing plan, everything else... if you've ever peeked at the Planning and Engineering manual you know it means a lot of programming in different places)

If you need more specific information please point it out, because it could be quite long to find and type here everything involved in this programming.

 

[cook1082]

On a PRI you will not get a dial tone unless you use the 2nd dial tone programming. Have you used the BCM monitors? Open up the one your calling out of and the 450's to see if it's grabing a channel.

 

[oldestgeek]

Turn on BCM Monitor and make a test call to see if you're actually sending the digits as required by the tandem switch. Also, the fact that some are analog and one is PRI is a red herring as you're only concerned with the VoIP trunks.

 

[franlebl]

Well, it might not be such a red herring as incoming calls for local DNs are accepted by the BCM, so there's no problem with the VOiP links per se.

BCM monitor was a very good idea. I see that the BCM receives the call with the destination code (which is 43). The incoming VOiP line is red and says 'Alerting'. The PRI channel opens and say 'Active', but the VOiP line stays on 'Alerting'. I looked at another BCM that is working and when the PSTN channels opens, the VOiP line should switch to 'Connected' and give up the call to the PSTN for out dial. It's as if the PRI does not pick up.

PRI says that OUTWATS is not applicable (N/A) Is there any meaning mayber related to my issue?

 

[oldestgeek]

Do you have a route with a destination code of 43 programmed in the BCM450 to route to the PRI? Are you absorbing two digits on that route? Also, remember that by default PRI won't give you a dial tone. You have to go to the "second dial tone" tab and add the 43 there if your users are expecting to hear dial tone. I don't belive the VoIP trunks will indicate "connected" until the PRI d-channel returns a "connect" message.

 

[franlebl]

I already had a destination code 43 with absorbed lenght at: all, using route 002 wich uses pool:BlocB (my PRI) and a SDT added with code 43. There must be a small something i forgot, but i can't find it. Unless it's something about the Pri itself? Bell is the provider of the PRi. But it works fine if i do the reverse (calling from that BCM another code to get an outside line on one of the other BCMs that all have copper lines) In that network, it's the only BCM trying to give an outside line with a PRi instead of copper lines...

 

[franlebl]

Well, I found the answer this morning. I just got back my access to patches on the new Avaya website and found out that a new SUsystem patch was out, dated at New Year's day. One of the point describes exactly my problem, saying that VOiP tandem switching with a PRI does not work on the BCM450; BCM monitor shows you that the VOiP channel stays on 'Alerting' even though the PRI channel opens. Exactly my issue.

Therefore it was indeed because it was a BCM450 with a PRI... but it wasn't the PRI's fault as I thought and everything was indeed well programmed. Thanks a lot for your help thinking this through!

 

[oldestgeek]

Thanks for letting us know what it was. The problem didn't affect all BCM450s though as I have several with tandem trunking working on a VoIP to PRI basis and that patch hasn't been applied to them.