Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

H323 trunking issues between BCM450 R5 and BCM50 R6 units 1

Status
Not open for further replies.

atascoman

Technical User
Oct 10, 2003
868
US
We recently upgraded this customer's BCM50 units to R6. All are patched as of a couple of weeks ago. They are having an intermittent issue where they can't call over the VoIP trunks. If they check the alarm log it shows an error that the trunks are full. However, when they monitor activity with BCM monitor it doesn't show any lines in use, but they still get a busy.

Kind of comes and goes. Sometimes they have to restart the BCM50 to get it working again. As far as I know all of the settings mirror the old R1 units we replaced and those never had this issue even when talking to the newer BCM450.

Are there any known issues with H323 in this scenario?
 

I saw an issue like this before where after a VoIP call the VoIP trunk would release on both ends but the Bcm would still think that the VoIP trunk was in use ending up saying "All VoIP trunk in use" in the alarm log.(Bcm400 4.0 and Bcm50 R3 scenario).
The solution was a patch in one of the two Bcm's(can't recall which one..)

Restarting the FEPS service in service manager would fix the issue(instead of rebooting)until all 8 VoIP licenses would say "in use" again...




 
Found the issue. SU07 has a fix for this, but you have to manually enable it. There is a checkbox under the H323 settings to enable Q.931 status query checking. Enable that and it fixes this problem. This is also a fix with a similiar problem between the BCM and a CS1000 R6.
 
I also found out that there is a built in 10 second delay after a call before a VoIP trunk is released. It's called lazy disconnect and is unchangeable. Avaya says it's to prevent the trunks from being oversubscribed when placing calls on hold and such.

Not sure if this has been around since R1 or not, but it didn't start being an issue until after we upgraded them to R6 units.
 
Looks like the problem is not resolved. They are still having to restart the FEPS to get the trunks back online. The frequency has significantly diminished, but it still happens now and then. I am at a loss. Looks like the Avaya design team is getting involved.
 
OK, we have a new possible fix. We were told to enable H.245 tunneling and to change the CBC limits to match the number of VoIP trunks. again, neither of these were done on the old R1 units and they worked fine.

So far it seems to be working, but we will have to wait and see when they get a round of high call volume and see if the changes work.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top