3rd party VM and message notification

[knightr1der]

Hi Guys,

Looks like its my week for asking the questions

I have a customer who has a TMS VM system connected to the OXE via 4620 ports. Everything seems to work fine except that when a message is left, the TMS off-hooks a channel and sends the relevant prefix for message waiting to a phone.

Once the user has heard the message, the TMS then off-hooks another channel to cancel the message waiting light. But the OXE is not happy with this and the message light continues.

The OXE is only happy if the same channel that set the light is the one that cancels the light.

So for now we have set the TMS VM to use only one channel for all notification tasks. Again, release 8 OXE. Before upgrade, apparently any channel would work for cancelling the light. Any ideas anyone?

[cavagnaro]

Sounds like a patch for me, shouldn't matter which port sends the notification.

[knightr1der]

Sounds like a patch for me, shouldn't matter which port sends the notification.

Something in my mind tells me that it should matter which port sends the notification 'off' message. E.G. if your mistress sends you a message indication, then another mistress can turn her message off on your set It all depends on how you like your bunny cooked? Sorry, I have watched the film 'Fatal Attraction' too many times now

Whilst I appreciate & trust Sr Cavs comment, are there any other Gurus who can give me their opinion before I send a SCUD missile (eSR) to A-L?

[cavagnaro]

For what i remember from like 2 years ago i was testing an external voice mail system, and the only think that put off the lamp was an array of characters (&M7??) can't remember exactly. In no part the port number was involved...
now that is as far as i remember...

[knightr1der]

For what i remember from like 2 years ago i was testing an external voice mail system, and the only think that put off the lamp was an array of characters (&M7??) can't remember exactly. In no part the port number was involved...
now that is as far as i remember...

Hmmmm, interesting. Can you remember if there was a serial link involved?

In my one there is no serial link and you can actually see what the ports are doing (via a diagnostic screen on the Voicemail). So when the message indicator is about to be switch on for a phone, you will see a port go 'off hook' and then dial a prefix (one that has been defined in the OXE as message on'whatever') and its a simple *71XXXX where XXXX is the extension number. After when it is time to turn the lamp off, it goes off hook and dials *72XXXX. Now provided the same port that did the *71XXXX is the one that does the *72XXXX then everything is fine. But if another port tries to do the *72XXXX then the OXE plays VG 'Sorry that feature is not authorised'

I don't have access to a LAB so I am limited for playing with this problem.

[oldboy]

Sorry to knightr1der, yes you need the same port that set MW to turn it off....its like a call back but in a hunt group which gives it an appearence of VM. So if you do a normal callback on a user and then cancel from somewhere else it wont work. Same this with VPS Hunt Group sorry mate.

[knightr1der]

thx 4 replying oldboy - But what is confusing me is that IT DID WORK before the upgrade to Rel8. Previously, when it did work, the system was 4400 running 4.1 Ux

Sorry guys, don't mean to go on and on about a poxy light - But It would be great to hear someone confirm that it has changed from 4.1 to 8.0

[gbroy]

Can't confirm about change to Release 8.0 but I can confirm we are using 7.1 with 20-4620 VPS ports and with an AVST voicemail system and you can use any port to turn on or off the message waiting light. I am interested in your question since we are getting ready to go to 8.0.

[knightr1der]

I am interested in your question since we are getting ready to go to 8.0.

Have you upgraded yet and if so, have you had the same problem as me?

[gbroy]

We have not upgraded as of yet, but I did talk to one of my other contacts and he said they upgraded with no problems.