BCM450 Message Forwarding (.wav to e-mail)

[IronChancellor]

I have a BCM450 6.0 system whereas the users are utilizing the Message Forwarding feature. The main part of the feature is working fine in the sense that the users are getting the .wav files delivered to their e-mail address without issue. The problem is that the MWI/red light is not turning off on the phone once the users have listened to the message via e-mail. I/they do have the setting to "Mark as read when received by recipient..." enabled within the Message Forwarding configuration.

What is the trick to getting the red light to go out on the phone once it has been delivered or opened by the recipient?

Thanks in advance.

 

[SIRMcD]

That is more complicated then just vm to email. Would require actual unified messaging keycode. setting up imap on exchange for the servers to communicate etc.

 

[IronChancellor]

Maybe I wasn't clear in my first post. I already have Unified Messaging keycodes for everyone on the system and they are getting the .wav files delivered to their e-mail via the built-in SMTP server on the 450.

The issue I'm having is that once the users receive or open the message, it is not going back and turning off the red light on the phone.

I found this note in the latest 6.0 patch, which was release on July 5th. It seems as though this patch will fix it. That's my next step, anyway.


Software update BCM450.R600.VOICEMAIL-73
----------------------------------------
1. Messages forwarding original message not being deleted on Read/Delivery
Message forwarding has been configured to delete/read messages from the user's
mailbox when opened by the recipient. The message are being delivered and we
can see the read receipt being returned to the BCM. But the BCM does not
delete/read the original message. The problem is with delivery and disposition
notification status. While parsing the last message mime file it does not match
with the disposition notification status and the message will not marked/deleted
on opened and delivered. This update now handles the DSN properly to make sure
it's not NULL.
wi00973812

 

[snd1234]

He already has the UM keycode. How else would he know the forwarding is working?

I had a similar problem when I rolled out message forwarding.

Read this thread and see if it helps:

http://www.tek-tips.com/viewthread.cfm?qid=1687485