BCM 400 VOIP Trunk Lock Up 2

[ox8157]

I have a BCM 400 4.0.2 with VOIP trunks locking up and I have to reset the switch to get the trunks back to working order. I get an alarm of 53011 when this happens. I have a smart update patch 005, core patch 158 and an IP patch 138 loaded and none have seemed to work. Does anyone have a suggestion?

 

[ox8157]

The Alarm displays mgs msm proxy mchannel. Does anyone know where to find the alarms in any programming manuals?

 

[hawks]

There may be a newer patch I hope to find out tomorrow.

 

[ox8157]

Have you had this happen in the past?

 

[pccal]

BCM.R400.SU.SYSTEM.007_BCM_4.0: BCM.R400.SmartUpdate.System.007-200801

 

[hawks]

Thanks pccal I thought there was a newer one

 

[ox8157]

Thanks for the input. I did actually find the new patch today. I will give it a try if it gives me more trouble. I think the IP patch might have done the trick.

 

[gberger]

SU6 contains fixes for Voip lockup but i would install SU7 instead, specialy if you have M serie's phone.
By the mean time if you want to release those Voip trunks , you can go to -Administration-general-Service manager and restart the FEPS service.

 

[ox8157]

Yeah,

The trunks locked up again this morning so I guess the IP patch did not do the trick. I will take your advise on using the 007 patch because I am using M series phones. If I have a su005 patch on the system already, does the 007 overide it? Thanks for the Service Manager tip as well, it beats brining the system down.

 

[gberger]

You might want to install SU8 as it has just been released.Also make sure the bcm at the other hand has those patches installed as well.

 

[DBrewsky]

Can you tell us how the VoIP trunks are being used? Explain all the possible ways calls are traversing these trunks? Maybe it's not the trunks, but how they are used.. Had a similar situation where a remote office would forward their calls at night to an auto attendant via VoIP trunksk, they also used centralized voicemail... Since the lines were analog, and they were forwarding to an AA in another location, the caller would dial an extension that resided back on the other side and it would freeze up the trunks.. Found that since the first trunks are "Public" and then the remaining are "Private", it would never release the trunks when the caller hung up. We forced them to use the AA at their local side, then it would transfer to a local extension and forward to the centralized voicemail across those VoIP trunks and it worked well..