MWI not working on CM3 after upgrade to CallExpress VM with SIP integration 5

[avayastrongman79]

Customer that has a CM6.0.1 using direct SIP integration to AVST CallExpress 8.1 voicemail platform. All phones on the Core CM work properly, but there is a standalone CM3.1 that is using h.323 tie trunk back to CM6 core, MWI is not working on those stations after the upgrade to SIP integration. Phones in that CM3.1 are primarily digital sets, ie 24xx and we have changed the MWI server type on station form as well as part of the troubleshooting.

We've tried utilizing qsig/h.323 and dcs/qsig as well on the tie trunks, and we can route calls over the trunks but no MWI is being sent to the far end. I'm just curious if anybody has any feedback, or has seen a similar config? We currently have repair tickets open with Avaya ad AVST, but kind of at a standstill currently. I appreciate any and all feedback in advance, thank you.

 

[Toni269]

This might sound obvious, but have you had the voice mail user clear out their messages so the MWI is turned off? If the system thinks MWI is already on, it won't send another signal to turn it on again. Once they clear out their voice mail messages, do a command: clear amw all xxxx [xxxx=extension]. Then leave a test voice mail and see if the light turns on.

 

[mattKnight]

Not that I'd recommend fiddling with your integration without talking to AVST...

but - on the CM 3.1 how is the message centre type set - I think it should be QSIG-MWI

You shoudl be able to set clear MWI for a local station using the subscriber mailbox settings (clear/set MWI tick box) Run a list tra trunk and see what you get

Then repeat for the CM3.1, but run a trace at the 3CM 3.,1 end too


Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[marcuspb]

You may be limited by only having one field for an IP address/FQDN within AVST in regards to how to reach out and touch the phone system, as far as MWI.

 

[montyzummer]

have you got virtual extension assigned on pg8(cm6.2) system parameters features.

The two fields are QSIG/ETSI TSC Extension & Qsig Path replacement extension.

I know that with AAM you need as mentioned "virtual ,that is a spare number in the dial plan not a Virtual station" assigning to each of these fields for MWI.

APSS (SME)
ACSS (SME)
ACIS (UC)

 

[avayastrongman79]

Thanks for all of the feedback everyone. Quick update, we now have correct integration going from CM3 back to CM6 over SIP trunk to CallExpress voicemail. Our last hurdle is just getting the MWI working over the QSIG/h.323 trunk. We've got the CM3 message center hunt group set up as qsig-mwi. One thing I do know for sure, is that the customer doesn't have the virtual extension designated in sys-par features. That is something else I will investigate as well. I'll send an update if/when we can get the message waiting indication working.

 

[Armstrong2012]

I had a similar problem where the MWI lights stopped working after resetting our CM server. If you go under Configuration > Database, there is a "Fixup" button. It rebuilds all the index files and solved the problem for me.

 

[avayastrongman79]

Hi all, wanted to provide a quick summary of our resolution.

So in the end, we did have to add QSiG/H.323 tie trunk to the CM3. So CM6 core is now QSIG tie trunked to the CM3. Once we had 4-5 test stations' MWI working (I had to put these individual ext entries in UDP/AAR), then we knew we had the potential fix. I then put the whole 5xxx range into UDP/AAR of the CM6 core to route properly over QSIG trunks.
On the CM3 side, I recreated message center hunt group with qsig-mwi and AAR route back to the SIP trunk (integration to CallExpress VM), then change message waiting indicator served on each station to qsig-mwi to match the HG.
Lastly, they did have to make some programming changes as well on the Voicemail side, each subscriber with an extension in the CM3 had to tick a "device" checkbox I believe in the CallExpress. (Forgive me, I don't know the AVST platforms), might be a bad description.

But anyway, in a nutshell that was our resolution and a lot of testing, tracing, monitoring as well. Thanks to each of you folks' for input, each piece of technical advice on this post was put to good use.