By jhawk on Nov 28, 2007
In general.. Sun offers an open platform for Unified Messaging services. The trend in the industry is to use open interfaces into "internet-based" email messaging platforms. As we at Sun are not actually providing voice features, we can however allow companies who have expertise leverage the successes Sun has had in providing massive scalability and manageability. We believe the the customer chooses the messaging platform, and then they choose a Unified Messaging platform to layer on top of it.
Some voice vendors still favor a "locked in" strategy which tie the customer to a proprietary storage mechanism. Today's realities make this less desirable because of the rapid development of voice features based on Web 2.0 cause these vendors to move less rapidly due to the overhead of development on these aging proprietary stores.
Sun enables features on these Voice platforms that come directly from our experience in email. Notification is a clear example of this. Many vendor solutions consist of one of three approaches to sending a notification of a new message:
\* "scan" all the mailboxes for new voicemail (IMAP polls)
\* forward a copy of the message to a notification server
\* maintain two mailboxes for each user
The worse method is the "scan". In this mechanism, a notification server will scan every mailbox of every user to identify new voice messages. The tragic consequences of this method is "timely notifications" versus "loss of performance" of your email platform.
The "copy on delivery" mechanism has a value in that it is supported on nearly every major email platform. The issue with this mechanism is that the forwarded message does not necessarily indicate the true state of the mailbox. A user who is logged into IMAP will still get a new message notification. The technical complexity of clearing a notification also makes this an unreliable mechanism.
The "notification mailbox" mechanism may have some merits. A voice mail message arrives in both the regular email inbox and the voice mail inbox. The two downsides of this approach are that first the email administrator needs to maintain two mailboxes and second that IMAP access does not take into account a message notification reset.
The example below indicates how Sun Java Messaging Server provides a "Universal Notification Service" for Mailbox changes. The notification mechanism is closely tied to the actual Message Store itself. This gives the benefit of matching the notification to the actual state of the mailbox. The new message notification is cleared no matter how the voice mail is actually retrieved; either by IMAP or by Phone.
Read more about how to configure Java Message Queue notifications in the
"Configuring a JMQ Notification Service" in the Sun Java System Messaging Server 6.3 Administration Guide