voicemail ports not letting go

[blantonlewis]

We are having a problem with our 406v1 at 3.2(59)... it will periodically hang on to a voicemail/autoattendant call until all 4 ports fill up, then of course it won't accept any more vm/aa calls. Right now CallStatus shows 2 vm lines hung (the call length doesn't reflect reality but they've been hung for an hour or two). We had been recording calls and they filled up much faster that way. Again - a call gets hung maybe once a day or so.

Two times in the past I've rebooted the phone switch to fix the problem & it has wiped out the user/lines/etc info & I've had to reload from a backup config (thanks avaya for creating those) and been fine again... for a while.

Any thoughts on this? Do I need a fresh config?

 

[blantonlewis]

More info... When running Monitor with just printing & Error turned on, I keep getting lines like this:

181259mS PRN: CMReleaseComp: Skip call delete as msg.callid (0 1005 0) <> Bcallid (0 1033 0)
200290mS PRN: CMReleaseComp: Skip call delete as msg.callid (0 1006 0) <> Bcallid (0 1200 0)

 

[Telecomboy]

What type of lines do you have: PRI, T1, Analog POTS Lines?

 

[blantonlewis]

Analog POTS, but right now one of the lines thats hung is from an extension across SCN (I guess checking vm). This started happening when we upgraded to 3.2(59)

 

[franke]

Would be interested in a solution for this as I have a customer experiencing the same problem. IP500, 4 LS POTS lines, SW R4.0, VM PRO

franke

 

[blantonlewis]

update - saw that one of the calls was incoming on an analog pots so I physically disconnected it & now the call is gone. But that doesn't explain the call from across SCN... the user's phone doesn't show that the call is in progress.

 

[Telecomboy]

I've seen this before with analog POTS lines, but never over an scn. Make sure reliable disconnect is checked for each of the analog lines.

 

[blantonlewis]

Thanks for the reply - all a'log lines have "disconnect clear" checked (help file says that's the same as reliable disconnect)

 

[SuperJenks]

Try adjusting the disconnect timer to 300ms instead of 500ms. Most providers will be within that range. U shouldnt get a diconnect of less than 300ms so dont go any lower than that. Also, if the lines are coming off a channel bank, sometime they have to enable the supervision on each channel/line. Try verifying with a test/butt set to see if the line is truely disconnecting or if its the IPO. Goodluck!

 

[blantonlewis]

Disconnect Units are at 500ms.... and that doesn't fix my SCN issue. I've also noticed this in the monitor banner:
VMAIL=1(VER=2 TYP=1)

VMPro is 3.2, does this matter?