BCM 50 IP Trunk calls getting rejected 1

[QueBall780]

We have 3 BCM50 units in branch offices.

We are having problems with extensions becoming locked out and cannot be called on those BCM50 units.

Majority of calls are happening as VOIP calls on the IP Trunks in some way. The inbound calls to the branch get forwarded to our central office to be answered and then transferred back to the people in the branch from there.

This particular problem started with the update to SU29. (Was on SU26 before)

When we call them, I can see the call alerting in the BCM monitor but it gets rejected. If I turn on logging in the UIP tab of BCM monitor I can see the Call Setup and then it shows Disconnect Reject and the caller gets a fast busy signal.
If one extension in the branch tries to call the one that rejects the call it also fails with a busy signal. The user at the extension that cannot be called is able to make outbound calls but cannot call any other extension. Basically all internal calls will fail with these extensions. Nothing is showing on the display of the phone, the Intercom buttons do not show the triangle indicating they are in use. We tried power cycling the BCM50's completely pulling the power cord but the problem has returned.

I have a temporary fix when it happens. I can go into Element manager, set the number of Intercom keys to 0 and then raise it back up to 2 again which seems to reset the problem from that extension but the problem will return.

When it happens it seems to only happen to the same users, though that may be because these are people who use the phone the most.

Pretty frustrated, we updated to SU29 to fix a bug we had in SU26 that was fixed with that update but now we get this new issue.

 

[telcodog]

Have a look under your IP trunks in your resources tab and make sure that your payload sizes for each of the codecs are the same at both ends otherwise you will get exactly that scenario. I've had patches reset those settings to default on me and took some real head scrathching to figure it out (because everything was working fine beforehand). In most cases, the default settings work but not all carriers work at those settings. Even if they are the same, they may still not work if you applied the patch to all 3 systems. Try setting them to 20msecs instead of the default 30 and see if that corrects it.

Good Luck.

 

[QueBall780]

Thanks for the suggestion. Everything was set to 30 before, I have tried lowering all sites to 20ms as you suggest.

the question is will this prevent the sets from getting to that locked out state from now on? I usually won't have to wait too long during the day to find out. Seems to happen to someone somewhere about every few hours.

My trick of removing the intercom keys at least means I do not have to reboot the entire site to fix a phone but it usually means we lost a customer call because a transfer failed before we found out the extension has crashed.

These last few years with Nortel have been hard. Way more stupid glitches than I can ever remember that just never seem to get fixed. Hoping that before October comes they put out some decent firmware we can live with until it's time to replace everything.

Otherwise I'm eye balling the spare BCM50 r1 I have sitting on the shelf for a possible retrofit to that E-Metro Tel UCx gateway system. Still waiting to hear if anyone can share real world experience with that system with us.

 

[telcodog]

Forgot to mention, make sure you set your ip phones the same way as well.

 

[morenot]

Check this:

When making a VoIP call from BCM to BCM caller gets busy tone


Document Id: KB98870700
Last Modified Date: 07-15-2010
Support Goal(s): Business Communications Manager 50
Access Level: External Entitled


Description (Problem Clarification)


When making a call from BCM50 to BCM400, get busy tone.

The BCM50 has 2 IP trunks, the BCM400 has 4 IP trunks. They are connected by an IP connection using Cisco routers in both sites:

BCM400--------------- VoIP trunks --------------------------eth1BCM50

Checking BCM monitor at BCM50, a trunk is seized but any packet of VoIP is going out the BCM50.
There is a ping response between BCMs.

From BCM Monitor, the trunk is being seized but the call cannot connect. It means that BCM takes a trunk and FEPS makes the initial process to establish connection, due a filter FEPS cannot send out signals to establish the trunk connection.


Resolution Plan

Network configuration
When the IP network is using NVPN circuits, there is a default configuration of 0% for QOS. Actually, the QOS does not need to be configured at all and that 0% needs to be removed from both sites. If QOS is being used, then the QOS config needs to be in both routers. So, as soon it is removed, the IP Trunk calls go through.

Saludos..

JLMT//

 

[QueBall780]

Well, does not look like either of these suggestions has helped.

Extensions are still getting locked out like crazy. I checked the network and QOS settings. Did a little bit of packet sniffing too. All the VOIP traffic is getting through and nothing is prioritizing the traffic in a bad way.

I made sure every office was set to 20ms and I also had changed all the settings for the voip handsets to 20ms to match when I made the change on the trunks down to 20ms. So I didn't forget to do that.

Any other suggestions before I decide to make an expensive phone call to Avaya?

 

[morenot]

what release has BCM50..

 

[QueBall780]

The BCM50 is running System SU266 December 2011
BCM050.R300.SU.System-266.201112

 

[morenot]

check this:

VoIP: TAT is not working between two or more networked BCMs.


Document Id: KB99722952
Last Modified Date: 07-15-2010
Support Goal(s): Business Communications Manager 1000, Business Communications Manager 200, Business Communications Manager 400, Business Communications Manager 50
Access Level: External Entitled


Description (Problem Clarification)


Scenario:
PSTN(CO)----->BCM-A (AA), select option x---VoIP--->BCM-B (Hunt Group or Telephone DN)
BCM-B Hunt Group Member or Telephone Answers the Phone and transfers the call back to BCM-A (Telephone DN)
TAT (Trunk Anti-Tromboning) is not being invoked
In the above scenario, a VoIP trunk is used in each leg of the call between BCMs. Hence two trunks are held up during the duration of the call. TAT optimizes the use of these trunks by optimizing (disconnecting) one of the VoIP trunks after the call is established.

In BCM 3.6, BCM 3.7, and BCM50 Release 1, TAT is not supported on CTI-based calls (eg. calls using BCM AutoAttendant functionality). However there is a solution for the above call scenario that can be implemented on networked BCM 3.7 and/or BCM50 Release 1 systems.

Note: BCM 4.0 and BCM50R2 have enhanced the BCM TAT implementation to enable TAT support on CTI-based calls (eg. calls using BCM AutoAttendant functionality). In these software levels, this solution is not required.

Resolution Plan


The following is the required configuration for TAT to be invoked in the above call scenario:
Two BCMs (3.7 and or BCM50 Rls1) are configured with a remote route (Direct Signaling) using CSE protocol
Both BCMs have MCDN enabled (keycode applied)
Both BCMs have TAT and TRO Enabled (also works if only TAT is enabled)
Forward redirected OLI (required in the call scenario)

Definition of Forward redirected OLI:
If the box is selected, the OLI of an internal telephone is forwarded over the VoIP trunk when a call is transferred to an external number over the private VoIP network. If the box is cleared, only the CLID of the transferred call is forwarded.

Why is Forward redirected OLI required in the scenario?
In BCM 3.6, 3.7, and BCM50 Rls1, TAT and TRO rely on the Called and Calling numbers. If the Called and Calling numbers on the two legs of the call do not match, then the TAT does not invoke. This prevents wrong connections that can occur because of false TAT optimization when Call References assigned by different Gateways across the network randomly matched for unrelated calls. Since the Auto Attendant in BCM-A cannot forward the originating CLID to BCM-B, we enable forward redirected OLI in order to pass the internal OLI between BCMs. Hence the internal called and calling numbers are retained between BCMs and TAT invoke as required.

Note: Forward redirected OLI is not available in BCM 3.6 software.

Saludos...

JLMT//

 

[QueBall780]

Thanks.

Does not apply to our situation. BCM400 is Release 4 and BCM50 is Release 3. TAT works as it should in these releases and I can guarantee you that it's working as it's simple to see in the BCM monitor.


It is not a situation where the VOIP trunks are being exhaused because Anti Tromboning is not kicking in.

More and more this appears to be some kind of bug in the latest SU for the BCM50.

Anyone else have SU 266 Installed? Do we need to put it on the naughty list?

 

[telcodog]

I know it's a pain to do but you might want to check every setting in your IP trunking parameters (especially if they're H.323). If it was working fine before the last patch was applied, then it's likely something got reset to default. I've had it happen more than once, the last time on an SRG It was a release 5 but the patch still screwed it up. Was getting the same scenario you describe.

 

[QueBall780]

Did check all those. Everything short of deleting them and adding them back again. Which I will actually go do just in case there is some kind of internal inconsistency with what the user interface and what the internal configurations may be using.



So, anyone know if Avaya will refund their incident fees if this turns out to be a bug in their software?

Any reports, good or bad from anyone who has updated to the same System Update? (266)

 

[morenot]

Come back to basic..
is the problem in one o all BCM50
are targets line set up to DN´s
are the trunks as private
is ticketed the OLI box
does the digit amount in private configuration appropiate to DN´s

Saludos..

JLMT//

 

[morenot]

Check this one..

BCM 4.0 & BCM50 PSTN inbound tandem calls without Calling line Identification (CLID ) fail to complete via H323 or Session Initiation Protocol (SIP) to networked system


Document Id: KB93366903
Last Modified Date: 07-15-2010
Support Goal(s): Business Communications Manager, Business Communications Manager 1000, Business Communications Manager 200, Business Communications Manager 400, Business Communications Manager 50, Survivable Remote Gateway 200/400, Survivable Remote Gateway 50
Access Level: External Entitled


Description (Problem Clarification)


BCM 4.0 and BCM50 PSTN inbound tandem calls without CLID fail to complete via H323 or SIP to networked system.

BCM 4.0 and BCM50 systems may experience issues with an inability to complete a tandem call scenario for an inbound PSTN originated call with no CLID provided when using H323 or SIP to a networked BCM, BCM50, or Communication Server 1000 (CS1K) destination system.



Resolution Plan


The following updates contain corrective content for this issue and should be applied to the PSTN facing BCM 4.0 or BCM50 system as VoIP call setup is being performed by the CORE of the BCM 4.0 or BCM50 that tandems the PSTN originated call:

BCM 4.0: BCM.R400.215-CORE

BCM50 R1: BCM050.203-CORE

BCM50 R2: BCM050.R200.140-CORE

BCM50 R3: BCM050.R300.CORE-TELEPHONY-95


Saludos,,

JLMT//

 

[QueBall780]

We kicked it upstairs.
Had an Avaya partner double check the programming was correct.

Avaya has our case now.

 

[QueBall780]

Cause has been determined to be a bug in the software.

Unfortunately Avaya is not doing any Engineering work on Release 3 for this kind of thing except for critical voice level issues. We either have to reset the hard drive back to a factory load, patch to an earlier system update and restore data from backup or upgrade to release 6. Likely going to upgrade to R6 since it's cheaper than paying contractors to go do the work of resetting the systems after hours.

So, beware. From what we can tell there is a bug lurking in the code of System SU266 December 2011
BCM050.R300.SU.System-266.201112

It appears to be an earlier bug that has come back, or is nearly identical to this issue.

[tt]BCM050.R300.CORE-TELEPHONY-DSP-219
----------------------------------
1. Intercom keys locking up
Intercom keys on digital sets appear in a connected state with no actual connection. Keys will not function when depressed. No message is displayed on the set and it appears the lines are busy.
Q02071504[/tt]

To trigger, it seems to require a relatively heavy volume of calls going through VOIP trunks and heavy use of the TAT (Trunk Anti Tromboning) feature. The inbound call gets answered on an analog line on the BCM50, transferred via VOIP to another BCM system and then transferred back to the original BCM50 where it is picked up as a local call and all the VOIP trunk traffic gets released by TAT. Some interaction between the internal Norstar voice code and the VOIP code is not releasing the Intercom resources on the phones after the call is released eventually exhausing the ability to use the Intercom feature. If the set has dedicated line buttons they can make external calls on the local analog lines but no internal calls can be made using the intercom key or by pressing intercom and dialling 9 to get an outside line.

I suggest to others that if you make use of BCM50 on Release 3 with VOIP trunks to answer and transfer calls coming in on the analog ports of the BCM50 to another separate BCM system you might need to avoid installing SU266. In this centralized reception configuration it will increase the likelyhood of encountering the bug. If the bulk of your calls are mostly handled without using VOIP trunks you are much less likely to encounter this problem.