40 Unified Messaging

With Oracle Communications Messaging Server, Oracle provides back-end software that lets you receive, store, and manage all types of messages--voice, fax, email, video--on one, off-the-shelf, cost-effective system.

The following sections describe Oracle's Unified Messaging solution:

• "Using Messaging Server to Manage Unified Messaging" is a white paper describing Oracle's unified messaging technology.

• "Designing and Coding Your Unified Messaging Application" describes how to design, configure, and code Messaging Server to support a unified messaging solution.

Using Messaging Server to Manage Unified Messaging

This document describes Oracle's solution to receive, store, and manage all types of messages--voice, fax, email, video--on one, off-the-shelf, cost-effective system. This paper is intended for telephony engineers and decision-makers interested in using standard Internet email software to manage voicemail, video, and fax communications.

For implementation details, see "Designing and Coding Your Unified Messaging Application."

What is the Challenge?

As broadband service providers compete to integrate internet communications (email and instant messaging) and voice communications (voice portal, voicemail, fax, and voice conferencing), they must reduce the costs of creating and maintaining those integrated services. To do this, telephone companies and their network equipment manufacturers (NEPs) must adopt open standards and use cost-effective, off-the-shelf storage technologies.

The Oracle Solution

Oracle's leadership in this area allows it to provide, with its partners, a solution that supports the convergence of these communication services, called unified messaging.

Unified messaging provides the following benefits:

• Multi-modal access: the ability to access different types of messaging services using different types of technology. For example, using the phone to access email messages or using the computer to access voices messages.

• A cost-effective, off-the-shelf technology for storing voice, email, video, and fax messages on the same system.

• The ability to manage all types of messages using the same administrative procedures. This includes expiring old messages, setting message space quotas, archiving, logging, usage profiles, and so on.

• Access to technologies like text-to-speech (TTS) and automated speech recognition (ASR).

Using open standards and best practices, Messaging Server offers a single back-end service that receives, stores, manages, and expires messages, no matter what their type.

Open Standards and Regulatory Requirements

In response to the need for open standards, engineering leaders have created the Voice Profile for Internet Mail (VPIM) specification, which defines the interfaces between voice front-ends and IMAP-based message stores. These standards, integrated into and implemented by Messaging Server, provide a substantial savings over traditional proprietary voice storage. Furthermore, unified messaging applications can take advantage of the efficient mailbox operations and system-performance knowledge provided by Messaging Server, leveraging the expertise and technology that have deployed hundreds of millions of Messaging Server mailboxes around the world.

Today's new legal and regulatory realities require an effective and unobtrusive mechanism for legal mail interception (LMI). Messaging Server enables service-provider personnel to apply the same LMI mechanisms already used on email to voice and fax interception and recovery. These mechanisms both capture messages on the network and archive messages stored on disk.

Architectural Overview of a Unified Messaging Application

The following sections define a high-level architecture for a unified messaging application using Messaging Server for communications storage, management, and notifications.

This architectural view follows the lifecycle of the message types (voice, fax, email), divided into the following stages:

1. An incoming message is deposited in the message store, and a message-waiting indicator is turned on.

2. The end user retrieves the message via the Telephone User Interface (TUI). The message-waiting indicator is turned off.

3. Alternatively, the end user retrieves the message via an IMAP messaging client (such as Thunderbird) or Convergence.

4. The Messaging Server message store administrator uses the Messaging Server's Mailbox Administration and Operations Management (MAOM) functions to administer and expire the message.

The sections that follow take snapshots of the communications workflow at each one of these stages.

Message Deposit

The following figure and state diagram show the message flow of a voice message or fax message when it first arrives and is deposited in the message store.

Figure 40-1 Message Deposit Function of Unified Messaging for Telecommunications

Description of ''Figure 40-1 Message Deposit Function of Unified Messaging for Telecommunications''

Figure 40-2 Message Deposit Function--State Diagram

Description of ''Figure 40-2 Message Deposit Function--State Diagram''

1. Receive the call.

   The Public-Switched Telephone Network (PSTN) receives a phone call or FAX intended for the end user and passes it on to the Media Application Server.

   A Media Application Server is a third-party system that services voice and FAX callers. It is similar to a home answering machine in that it picks up calls, plays a pre-recorded message, handles touch-tone interactions, and retrieves and stores voice messages and so on. In many cases, the Media Application Server sits on a voice trunk with many ports; some servers support thousands of ports. A port is equivalent to one telephone line.

2. Profile the call with LDAP data.

   Using the end user's phone number, the Media Application Server looks up the LDAP entry for that number in Directory Server. Directory Server returns the LDAP profile to the Front-end Server.

   The types of profile information retrieved can include:

   • Status of the mailbox: Available, Disabled, Vacation

   • Allowed services

   • Current greeting for the user.

3. Retrieve and play voicemail greeting.

   The Media Application Server retrieves the greeting voice file from the message store and plays it to the caller. For example: "Hello, you've reached..." It prompts the caller to leave a message.

4. Record the message and release caller.

   The Media Application Server records the caller's message in binary file format, usually WAV format for voice and TIFF for FAX data. The caller hangs up.

5. Encode the voice/FAX message.

   The Media Application Server creates a email message, attaches the caller's encoded message file to it, and addresses it to the user's mailbox.

   • It creates an RFC2822 email message.

   • It attaches the voice message file as a binary attachment (base64). This format conforms to the Voice Profile for Internet Mail (VPIM) standard.

   • It addresses the message to the user's mailbox, using a standard email address--for example, [e-mail].

     The voice message is now an email message with a large attachment.

6. Send email to message store.

   The Media Application Server sends the email message via SMTP to the Messaging Server. The Messaging Server Message-Transfer Agent (MTA) accepts the email and routes it to the user's mailbox in the message store.

   The message store, a component of Messaging Server, stores and manages user mailboxes.

7. Generate a new-message event notification.

   This is to notify the system that a new message has arrived for this mailbox and is available for retrieval. The notification, and the actions taken in response to the notification--for example, turning on the message wait indicator--must be implemented by the customer.

   Message Queue provides the infrastructure for producing and distributing event notifications.

Message Retrieval via Telephone User Interface

The following figures show the message flow and data states of a voice or fax message as the end user picks it up (listens to it or has the fax machine print it).

Figure 40-3 Message Retrieval via Telephone User Interface

Description of ''Figure 40-3 Message Retrieval via Telephone User Interface''

Figure 40-4 Message Access and Retrieval via Telephone User Interface--State Diagram

Description of ''Figure 40-4 Message Access and Retrieval via Telephone User Interface--State Diagram''

These diagrams illustrate the following actions:

1. User dials in and system profiles user mailbox.

   In this implementation of the Media Application Server, the end user dials into the voice mail system. Using the end user's phone number, the Telephone/FAX Media Application Server looks up the LDAP entry for that number in Directory Server. Directory Server with Access Manager authenticates the user.

   After the authentication, the Media Application Server then looks at the user's Message Store server from the user's LDAP mailHost attribute. The system prompts the user for the password.

2. User enters password.

3. System retrieves new mailbox summary.

   The Media Application Server performs an IMAP connection to the mailbox owner's Message Store. The IMAP connection may pass through a component called the Messaging Multiplexor (MMP) which routes connection requests to the appropriate message store. It then opens the user's folders to check for number of new messages (for example, number of new voicemail, fax and email messages). The Media Application Server then plays the number of new messages of each type to the user over the phone.

   Note:

   Steps 3 and 4 are separate procedures that are executed at the same time.

4. System retrieves and plays messages.

   The mailbox caller selects either voicemail or fax mailbox. Using IMAP, the Media Application Server retrieves the message from its message store The Media Application Server then plays each Message header. For voicemail, it plays the message.

   • To play the voice message, the Media Application Server retrieves the RFC822 message. It decodes the attachment and plays the audio file (typically .WAV or mp3) over the phone line.

   • To play fax messages, the Media Application Server sends information about the fax (for example, date/time, caller number, number of pages, urgency, etc.). Typically, mailbox owners will forward these fax messages to fax machines nearby to them.

   • To play email messages, the Media Application Server sends info about the email (e.g. sender, subject, time/date, urgency). If text-to-speech has been implemented, the server will attempt to "read" the message to the caller. Some implementations allow the caller to forward the fax and the attachments to a nearby fax machine. After playing the message, the caller can delete, replay or forward the message.

   The message itself remains in the user's mailbox in the message store, but the status of the message flag is changed to "seen/read."

5. User replays, deletes, forwards or archives the message.

6. System generates a message-read or message-deleted event notification.

   This is to notify the system that the message has been read or deleted. The notification, and the actions taken in response to the notification--for example, turning off the message wait indicator--must be implemented by the customer.

   Message Queue provides the infrastructure for producing and distributing event notifications.

Message Retrieval via PC

Messaging Server provides two ways to access messages through a PC: through an IMAP client such as Thunderbird or Outlook (with Connector) and through the , a web-based communication client, which uses an HTTP connection.

These will be described in separate sections.

Message Retrieval Through an IMAP Client

The following figure shows the message flow and data state of a voice or fax message as it is retrieved through an IMAP client.

Figure 40-5 IMAP Client Message Retrieval--Component and State Diagram

Description of ''Figure 40-5 IMAP Client Message Retrieval--Component and State Diagram''

This diagram illustrates the following actions:

1. User opens IMAP Client which connects to Messaging Server.

2. User enters the password and is authenticated by the MMP.

   The MMP finds the appropriate message store and sets up a direct connection between the store and the client.

3. Message store sends message header information to the IMAP client.

4. User clicks the message header to open.

   Client issues an IMAP FETCH command and the message store returns the RFC822 email message with the MIME attachment containing the voice/FAX data. The format of the data could be in .WAV, MP3, TIFF or JPEG.

5. User clicks the attachment.

   IMAP client launches the media player on the PC, then strips off the wrappers and encoding in the attachment, and sends the resulting binary file to the media player.

6. User deletes, forwards, or archives the message.

   IMAP client sends command to the message store to delete, forward or archive the message.

7. Message store generates an event notification indicating the changed status (deleted/forwarded/archived) of the message.

Message Retrieval Through Convergence

The following figure shows the message flow and data state of a voice or fax message as it is retrieved through the Convergence client.

Figure 40-6 Convergence Message Retrieval--Component and State Diagram

Description of ''Figure 40-6 Convergence Message Retrieval--Component and State Diagram''

This diagram illustrates the following actions:

1. User logs in with password to the Convergence Server through a browser and retrieves the message headers.

   Convergence Server makes a HTTP request to the Webmail Server for the message headers. The Webmail Server requests and retrieves the headers via IMAP and returns it to Convergence in HTTP where the user can view it.

   The Webmail Server translates HTTP commands to IMAP, and IMAP commands to HTTP. Note that the message store stores data in 7-bit format, and that http transfers data in 8-bit binary format.

2. User clicks the message header to open.

   Again, Convergence Server makes a HTTP request to the Webmail Server for the message. The Webmail Server requests and retrieves the message via IMAP and returns it to Convergence in HTTP where the user can view it. The message does not contain the MIME attachment, but contains a link to the attachment.

3. User clicks the attachment.

   Again, an HTTP request is made to the Webmail Server, which translates the request to IMAP and sends it to the message store.

4. Retrieve the MIME attachment.

   The Webmail Server retrieves the MIME attachment, strips off the wrappers and encoding in the attachment, and sends the resulting base64 binary file via Convergence to the browser which launches media player.

5. The media player plays and displays the attachment.

6. User deletes, forwards, or archives the message.

   Convergence sends command to the message store to delete, forward or archive the message.

7. Message store generates an event notification indicating the changed status of the message (deleted/forwarded/archived).

Designing and Coding Your Unified Messaging Application

This document describes how to design and configure Messaging Server to implement a unified messaging application.

For a high-level description of how Messaging Server features can integrate and support a unified messaging solution, see the following white paper:

• Using Messaging Server to Manage Unified Messaging

The following sections point out key areas you'll need to design and code to integrate the Messaging Server back-end with your UM application:

• Planning the Message-Type Configuration

• Coding and Configuring Your UM System

• Mailbox Administration and Operations

• Delivering Notifications for Message Types

• Additional Unified Messaging Support Features

Planning the Message-Type Configuration

To administer messages of different types, all components of the UM system must use the same message-type definitions and the same header fields to identify the messages.

Before you configure Messaging Server to support message types, you must

• Plan which message types you intend to use

• Decide on the definition for each message type

• Decide which header field to use

For example, if the application includes phone messages, you can define this message type as "multipart/voice-message" and use the Content-Type header field to identify message types.

You would then configure the Media Application Server to add the following header information to each phone message to be delivered to the message store:

Content-Type: multipart/voice-message

Next, you would configure the MTA and/or message store to recognize the multipart/voice-message message type.

Coding and Configuring Your UM System

This section takes a closer look at the message life cycle described in earlier sections. Here we focus on the stages in the life cycle where you must design, code, and configure components of the UM system. We give you an idea of the Media Server coding and Messaging Server configuration that you will perform to implement your UM system.

1. Unanswered call is routed to the Media Server.

   Before the Media Server sends a message to Messaging Server, it must check the status of the user's mailbox to ensure that the user's mailbox is not full or busy.

   The Media Server must be coded to check the mailuserstatus attribute in the user's entry in the directory server to see, for example, if the user's mailbox is full or not. You also must configure quota enforcement on the Message Store to enable this feature.

   For an introduction to quota enforcement by message type, see "Administering Quotas for Message Types." For details about configuring quotas for the message store, see "Managing Message Store Quotas."

2. The Media Server encodes the voicemail as a binary attachment to an email message, which it sends to the MTA. The message is labeled by type.

   (Of course, you must code the Media Server to perform the voicemail-to-email state transformation.)

   When a message comes into the MTA via the Media Server, the first thing that must be done is to add a Content-type header to the message. The value of this header identifies the message type.

   In this way, the messages can be managed according to their type. For example, voicemail types may have different quotas than text types.

   You must define each message type with a unique identifier such as multipart/voice-message.

   Content-type headers can be inserted in the message by the Media Server or by the MTA.

   Typing by Media Server. When the Media Server constructs the email message to send to the MTA, it can be coded to add the Content-type header with the appropriate message-type value. For example, a voicemail message could require that Content-type: multipart/voice-message be added to the message.

   Typing by MTA. The alternative is to set up your system so that the MTA adds the Content-type header. This can be done by configuring separate, non-standard ports for the various message types.

   Typically, email comes into the MTA via port 25. Thus, for example, you can configure text email to go to the standard port 25, voicemail to port 225, FAX to port 325. You need to configure the Media Server to send the message to the appropriate port. Also, you need to configure the MTA to append the appropriate Content-type header to messages arriving at each port.

3. The MTA deposits the message in the message store, and an IMAP flag identifying the message type is appended to the message.

   The message store reads the Content-type header to identify the message type.

   You can configure the MTA or the message store to append a message-type flag to the message. You must define unique values for each message-type flag.

   Messaging Server presents the message-type flag as a user flag to IMAP clients. (This flag cannot be modified by end users.)

   Mapping the message type to a user flag allows mail clients to use simple IMAP commands to manipulate messages by message type.

4. Client retrieves mailbox status and displays the message together with its type.

   From the user's perspective, the client email software may display an icon indicating the type of each message (if the client supports this feature). For example, a phone icon appears next to a voicemail message.

   The IMAP SEARCH command, using the message-type flag as a keyword, retrieves a count of each type of message. The IMAP FETCH command retrieves the message headers with the message status and message-type flag name.

   For examples, see "Sample IMAP Sessions Using Message-Type Flags."

5. User clicks on the voicemail attachment, and the voicemail is played by a media player on the PC.

   For details, see steps 2 and 3 in "Message Retrieval Through Convergence."

6. Message store generates a notification indicating the changed status of the message.

   If the status of a messages changes, the message store can generate a notification that can be retrieved by the email client or the Media Server. A notification can deliver a count of the messages in a user's mailbox for each message type and for each change in message status.

   For example, a notification can deliver a count of all new (unread) voicemail messages and all new text messages in a user's mailbox. When the user listens to a voicemail, another notification can be generated indicating all voicemail messages that have been read and all text messages that have been read. In this case, the number of new voicemail messages is reduced by one.

   You need to configure Messaging Server to determine how and when to generate notifications. Also, you need to write Media Server code to retrieve the notification and take appropriate action. For example, when a new message arrives in the store, you may wish to send an indicator to the customer's phone. For details, see "Delivering Notifications for Message Types."

Mailbox Administration and Operations

The Messaging Server message store can be configured to identify and manage message types.

The customer does not have to maintain different message types in individual mailbox folders. The message store can identify a message type, no matter where the message is stored. Thus, you can store heterogeneous message types in the same folder.

The following figure illustrates how an incoming message is identified by its type:

Figure 40-7 Message Management by the Messaging Server Message Store

Description of ''Figure 40-7 Message Management by the Messaging Server Message Store''

In this diagram, the message store identifies the message type of an incoming message by reading the Content-type header. In addition, the message store appends an IMAP flag identifying the message type (if the IMAP flag has not already been appended by the MTA).

Once message types have been configured, the message store lets you

• Set flags that allow IMAP commands to fetch and search for information about message types

• Configure quota roots that apply to each message type

• Write expire rules to expire and purge messages according to message type

The rest of this section describes the following topics:

• Sample IMAP Sessions Using Message-Type Flags

• Administering Quotas for Message Types

• Expiring Messages by Message Type

Sample IMAP Sessions Using Message-Type Flags

This section describes sample IMAP sessions using IMAP FETCH and IMAP SEARCH.

Example 1: IMAP FETCH Session

The following IMAP session fetches messages for the currently selected mailbox:

2 fetch 1:2 (flags rfc822)
* 1 FETCH (FLAGS (\Seen text) RFC822 {164}

Date: Wed, 8 July 2006 03:39:57 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Subject: Hello
Content-Type: TEXT/plain; charset=us-ascii

* 2 FETCH (FLAGS (\Seen voice_message) RFC822 {164}

Date: Wed, 8 July 2006 04:17:22 -0700 (PDT)
From: [e-mail]
To: [e-mail]
Subject: Our Meeting
Content-Type: MULTIPART/voice-message; ver=2.0

2 OK COMPLETED

In the preceding example, two messages are fetched, one text message and one voice mail.

The Content-type header fields identify the message types. The message-type names are displayed as they were received in the incoming messages.

Example 2: IMAP SEARCH Session

The following IMAP session searches for voice messages for the currently selected mailbox:

3 search keyword voice_message
* SEARCH 2 4 6
3 OK COMPLETED

In the preceding example, messages 2, 4, and 6 are voice messages. The keyword used in the search, voice_message, is the flag name defined for voice messages.

Administering Quotas for Message Types

When you set a quota for a message type, you include that value in a quota root. A quota root specifies quotas for a user.

You can specify the following quotas for a user's mailbox tree:

• Quota values for specific folders in the user's mailbox

• Quota values for specific message types such as voice mail or text messages. A message type quota applies to messages of that type in all folders in the user's mailbox.

• A default quota value that applies to all folders and message types in the user's mailbox that are not explicitly assigned quotas.

Quotas can be configured for the number of messages allowed and for the maximum amount of disk storage used.

Example of a Message-Type Quota Root

Suppose a customer wants to configure separate quotas for text messages and voice messages in each user's mailbox. Yet another quota is to be set for the user's Archive folder.

The following figure illustrates this example:

Figure 40-8 Administering Quotas in the Message Store

Description of ''Figure 40-8 Administering Quotas in the Message Store''

This example sets the following quotas for a user:

• The storage quota for the Archive folder is 100M

• The storage quota for text message types is 10M

• The message quota for text message types is 2000

• The storage quota for voice message types is 10M

• The message quota for voice message types is 200

• The default mailbox storage quota is 40M

• The default mailbox message quota is 5000

This quota root permits greater storage in the Archive folder (100 M) than in all the other folders and message types combined (60 M). Also, no message limit is set for the Archive folder; in this example, only storage limits matter for archiving. The message types have both storage and number-of-message quotas.

The message-type quotas apply to the sum of all messages of those types, whether they are stored in the Archive folder or in any other folder.

The default mailbox quotas apply to all messages that are not text or voice message types and are not stored in the Archive folder. That is, the message-type quotas and Archive quota are not counted as part of the default mailbox quotas.

For example, the default mailbox quota would apply to a message that arrives in the user's INBOX without a Content-Type header and message-type definition. When that message is archived, the Archive folder storage quota would apply.

Guidelines for Specifying Multiple Quota Values

The following guidelines apply when you assign multiple quota values for a user:

• Quotas do not overlap. For example, when there is a quota for a particular message type or folder, messages of that type or messages in that folder are not counted toward the default quota. Each message counts toward one and only one quota.

• The total quota for the whole user mailbox equals the sum of the values of all the quotas specified by default, type, and folder.

• Message-type quotas take precedence over folder quotas. For example, suppose one quota is specified for a user's memos folder and another quota is specified for voice messages. Now suppose the user stores eight voice messages in the memos folder. The eight messages are counted toward the voice-mail quota and excluded from the memos folder quota.

Sample IMAP Session Returning Quota Root Values

When you run the getquotaroot IMAP command, the resulting IMAP session displays all quota roots for the user's mailbox, as shown here:

1 getquotaroot INBOX
* QUOTAROOT INBOXuser/joe user/joe/#text user/joe/#voice
* QUOTA user/joe (STORAGE 12340 20480 MESSAGE 148 5000)
* QUOTA user/joe/#text (STORAGE 1966 10240 MESSAGE 92 2000)
* QUOTA user/joe/#voice (STORAGE 7050 10240 MESSAGE 24 200)

2 getquotaroot Archive
* QUOTAROOT user/joe/Archive user/joe/#text user/joe/#voice
* QUOTA user/joe/Archive (STORAGE 35424 102400)
* QUOTA user/joe/#text (STORAGE 1966 10240 MESSAGE 92 2000)
* QUOTA user/joe/#voice (STORAGE 7050 10240 MESSAGE 24 200)

Expiring Messages by Message Type

The expire and purge feature allows the customer to move messages from one folder to another, archive messages, and remove messages from the message store, according to criteria the customer defines in expire rules. These tasks are performed with the imexpire utility.

Because the imexpire utility is run by the administrator, it bypasses quota enforcement.

The customer can write expire rules so that messages of different types are expired according to different criteria.

The expire feature is extremely flexible, offering many choices for setting expire criteria. This section describes one example in which text and voice messages are expired according to different criteria.

The following figure illustrates an example of expiring messages by type:

Figure 40-9 Expiring Messages by Message Type

Description of ''Figure 40-9 Expiring Messages by Message Type''

In this example, text messages and voice mail are expired in different ways, and they follow different schedules, as follows:

• Text messages are moved from a user's inbox to the user's Archive folder one year after they arrive in the message store.

• Voice mail is moved from the inbox to the OldMail folder after two weeks. If the user saves a voice message, the saved date is reset, and the message is moved two weeks after the new date.

• Voice mail is moved from the OldMail folder to the Trash folder after 30 days. The user also can save a voice message in the OldMail folder, which postpones the removal of the message for another 30 days after the new saved date.

• Messages of all types are discarded seven days after they are moved to the Trash folder.

The expire rules move voice mail to Trash automatically. Text messages are moved to Trash when a user deletes them.

Sample Rules for Expiring Different Message Types

You can implement the example described in this section by writing the following expire rules:

TextInbox.folderpattern: user/%/INBOX
TextInbox.messageheader.Content-Type: text/plain
TextInbox.messagedays: 365
TextInbox.action: fileinto:Archive

VoiceInbox.folderpattern: user/%/INBOX
VoiceInbox.messageheader.Content-Type: multipart/voice-message
VoiceInbox.savedays: 14
VoiceInbox.action: fileinto:OldMail

VoiceOldMail.folderpattern: user/%/OldMail
VoiceOldMail.messageheader.Content-Type: multipart/voice-message
VoiceOldMail.savedays: 30
VoiceOldMail.action: fileinto:Trash

Trash.folderpattern: user/%/Trash
Trash.savedays: 7
Trash.action: discard

Delivering Notifications for Message Types

Messaging Server, together with Message Queue, can produce notifications that deliver status information about messages of different types, such as voice mail, text messages, fax data, and image data.

For example, suppose a new phone message arrives in a user's mailbox, as described in "Message Deposit."

You can configure Messaging Server to generate a new-message notification for the Message Queue service. You can also configure Messaging Server to identify particular message types, including voice mail.

Now, when the voicemail is deposited in the user's mailbox, the message store triggers a notification that says, essentially:

• "This user has a new message."

• "The new message is voicemail."

After Messaging Server delivers the new-message notification to the Message Queue service, Message Queue sends it to a consumer (client interface), which filters and delivers the message to its destination.

You can write your Message Queue client program to interpret notification messages by message type and deliver status information about each type. In this example, the client program, recognizing the new message is voice mail, could trigger the Message Wait Indicator to turn on the "New Messages" light on the end-user's phone.

Now suppose new messages of different types--say, voice messages and email--arrive in the user's mailbox.

Once you have configured message types, a new-message notification carries data that counts the number of each type--in this case, the number of new voice messages and new email (text) messages. Your Message Queue client program can deliver the count by message type to the Media Application Server, which would notify the user that there are, for example, seven new voice mail messages and four new text messages in the user's cell phone inbox.

Notifications for Particular Message States

The following notifications can be generated when a message changes state. For example, when a user reads a message or listens to voicemail, a ReadMsg notification can be generated. These notifications can carry information that tracks particular message types:

Table 40-1 Notification Message Descriptions

Notification Message	Description
NewMsg	New message was received by the system into the user's mailbox. Can contain message headers and body.
UpdateMsg	Message was appended to the mailbox by an IMAP operation. For example, the user copied an email message to the mailbox. Can contain message headers and body.
ReadMsg	Message in the mailbox was read. (In the IMAP protocol, the message was marked Seen.)
TrashMsg	Message was marked for deletion by IMAP or HTTP. The user may still see the message in the folder, depending on the mail client's configuration. The messages are to be removed from the folder when an expunge is performed.
DeleteMsg	Messages marked as Deleted are removed from the mailbox. This is the equivalent to IMAP expunge
PurgeMsg	Message expunged (as a result of an expired date) from the mailbox by the server process imexpire. This is a server side expunge, whereas {{DeleteMsg} is a client side expunge. This is not a purge in the true sense of the word.
OverQuota	Operation failed because the user's mailbox exceeded one of the quotas (diskquota, msgquota). The MTA channel holds the message until the quota changes or the user's mailbox count goes below the quota. If the message expires while it is being held by the MTA, it will be expunged.
UnderQuota	Quota went back to normal from OverQuota state.

How Do You Implement Notifications for Message Types?

To implement notifications that count by message type, you need to do these things:

• Configure the message store to identify message types

• Configure a Messaging Server component, the JMQ notification plug-in, to produce notifications that identify message types

• Write a Message Queue client that retrieves, filters, and delivers the notification

• Design/write your Unified Messaging system (for example, the Media Application Server) to receive the notification and deliver it to the end user or other destination

Configuration Details

So far, you've seen the changes in message state that can trigger notifications. But how do the notifications carry information about message types?

We need to explain a few configuration details to show how these components work together. The following sections discuss the first two items listed above--the Messaging Server components.

Configuring the Message Store to Recognize Message Types

You use the Messaging Server msconfig or configutil utility to configure two options that enable the message store to identify message types:

• store.messagetype.enable (same for both Unified Configuration and legacy configuration)

• store.messagetype.mtindex:x.contenttype (Unified Configuration)

  or

  store.messagetype.x (legacy configuration)

First, you set the store.messagetype.enable option to on (-v 1) to enable message types.

Next, you define one store.messagetype.mtindex:x.contenttype(Unified Configuration) or store.messagetype.x (legacy configuration) option for each message type. For example, to identify four message types, you define four iterations of this option with four different values. You do these things:

• Set an integer value for variable x.

• Specify a text string that is the value of the message type used in your Unified Messaging system with the Content-Type header.

For example, to define a text message, you can enter:

configutil -o store.messagetype.1 -v text/plain

To define a voicemail type, you can enter:

configutil -o store.messagetype.2 -v multipart/voice-message

Now the message store can identify any message type with a Content-Type header value of text/plain or voice-message.

Also, the message store will identify messagetype.1 with text messages and messagetype.2 with voicemail. (You'll need to know this when you see how notification properties carry information about message types.)

Note:

You can configure other configutil options to define IMAP flag names, quota root names, and even an alternate message header name (other than Content-Type).

For details, see the discussion on managing message types in the Sun Java System Messaging Server Administration Guide.

Configuring the JMQ Notification Plug-In to Generate Messages

You use the configutil utility to define options that configure the Messaging Server JMQ notification plug-in. The plug-in can produces a notification whenever a message changes state.

For each state change that should trigger a notification, you define a configutil option. For example, to enable notifications for new messages, you enter:

configutil -o local.store.notifyplugin.jmqnotify.NewMsg.enable -v 1

where jmqnotify is the name of the plug-in and -v 1 enables notifications for this message.

To generate notifications for messages that the end user has read, you define this option:

local.store.notifyplugin.jmqnotify.ReadMsg.enable

and so on.

Note:

To fully configure a JMQ notification plug-in, you must define several other configutil options. For details, see the discussion on configuring the JMQ Notification Plug-in to produce message for message queue in the Sun Java System Messaging Server Administration Guide.

How the Message Store and JMQ Notification Plug-in Work Together

Once you configure the message store's message-type feature and the JMQ notification plug-in, both components recognize and carry information about message types.

We've already discussed how the message store can enforce quotas and expire messages by message type.

Now, when a message changes state, the message store can generate a notification and the JMQ notification plug-in can automatically recognize the message type as well as the changed state.

Notification Properties for Message Types

Every notification carries additional information defined in properties. Different properties are present for different messages. For example, a NewMsg notification indicates the IMAP uid of the new message.

If message types are configured, the following properties are carried with notifications. These properties deliver a count of the messages in a particular state for each message type you have defined:

• numMsgsnn

• numSeennn

• numDeletednn

• numSeenDeletednn

Suppose a new-message (NewMsg) notification is generated.

The Messaging Server JMQ notification function counts the number of new messages currently in the mailbox, by message type. Instead of sending one count with the NewMsg notification, an array specifying the count for each message type is sent.

The message-specific count is carried in the numMsgsnn property and delivered with the notification.

The message-type number (nn) identifies a particular type. For example, you can configure message type 2 (store.messagetype.2) to identify voice messages, message type 3 (store.messagetype.3) to identify text messages, and so on.

For ReadMsg and TrashMsg notifications, the number of messages seen (numSeennn and the number marked as deleted (numDeletednn) are also counted by message type.

Table 40-2 describes these properties:

Table 40-2 Notification Properties for Message Types

Property	Data Type	Description
NumMsgsnn	MQInt32	The total number of messages now in the mailbox, specified for each message type. If message types are configured, a numMsgsnn property carries a count for each message type nn. The numMsgs property is always sent; it counts the total number of all messages in the mailbox, including all types. For example, if 20 messages are currently in the mailbox, 10 are of type 3, 7 are of type 16, and the rest are not of any recognized type, the following properties and counts are carried with the notification: numMsgs=20 numMsgs3=10 numMsgs16=7
NumSeennn	MQInt32	The total number of messages in the mailbox marked as seen (read), specified for each message type. If message types are configured, a numSeennn property carries a count for each message type nn. The numSeen property is always sent; it counts the total number of all messages marked as seen, including all types. For example, if 20 messages are marked as seen, 10 are of type 3,7 are of type 16, and the rest are not of any recognized type, the following properties and counts are carried with the notification: numSeen=20 numSeen3=10 numSeen16=7
NumDeletednn	MQInt32	The total number of messages in the mailbox marked as deleted, specified for each message type. If message types are configured, a numDeletednn property carries a count for each message type nn. The numDeleted property is always sent; it counts the total number of all messages marked as deleted, including all types. For example, if 20 messages are marked as deleted, 10 are of type 3, 7 are of type 16, and the rest are not of any recognized type, the following properties and counts are carried with the notification: numDeleted=20 numDeleted3=10 numDeleted16=7
NumSeen Deletednn	MQInt32	The total number of messages in the mailbox marked as seen (read) and marked as deleted, specified for each message type. If message types are configured, a numSeenDeletednn property carries a count for each message type nn. The numSeenDeleted property is always sent; it counts the total number of all messages marked as seen and deleted, including all types. For example, if 20 messages are marked as seen and deleted, 10 are of type 3, 7 are of type 16, and the rest are not of any recognized type, the following properties and counts are carried with the notification: numSeenDeleted=20 numSeenDeleted3=10 numSeenDeleted16=7

Additional Unified Messaging Support Features

The following features have been added to Messaging Server 7.0 and may provide additional support for implementing Unified Messaging Solutions.

Set IMAP Flag Based on Header Value at Delivery

The IMAP flag setting is done through the imap4flags sieve extension. (Testing header values is, of course, a basic sieve capability.) This feature is fully specified in RFC 5232. The goal is to be able to represent compound message context states, such as URGENT. VOICEMAIL, BROADCAST FAX and so on via numeric IMAP Flags.

To apply these actions to multiple users, you probably want to make use of system, source channel, and destination channel, or perhaps domain sieve rather than user sieves.

Implementation Description: The LMTP and SMTP processes allow IMAP flags to be set upon delivery based on header value. Upon insertion of a message into the message store, a sieve rule in conformance with SIEVE-IMAPFLAGS- 05 will modify the IMAP flag to represent the context of the message with an integer value from 1 to 32. The JMS will publish a notification event consequent to this event to the message queue.

In deployment, a SIEVE rule will perform a logical AND operation resulting in an IMAP flag and X-HEADER numeric value which would represent a context via a particular compound operation (for example,17 to represent URGENT and EMAIL and so on). EDITHEADER-09 is supported, which, with configuration changes, will allow this to be used during SMTP delivery to allow devices without the capability to construct an RFC3458 header to construct one via an ADDHEADER rule, which in turn will allow preprocessing of message type identification prior to arrival in the final mailbox.

Modifications to IMAP Commands to Provide Message Counts

Messaging Server provides quick message counts and message states to clients for improving response time.The IMAP STATUS and SEARCH commands have been modified to provide return value data representing counts for [RFC3458] message types.

IMAP Unauthenticate

The IMAP command UNAUTHENTICATE is supported. This will be advertised by the XUNAUTHENTICATE CAPABILITY and response. When invoked, the command will return the connection to an unauthenticated state, where AUTHENTICATE can be invoked without creating another connection to enable its reuse. This provides more effective use of IMAP pooling techniques via reuse of Network Sockets. The requirements of the IMAP AUTHENTICATE mechanism to create a new connection is bypassed and thereby enables connection reuse.

Modify IMAP APPEND to bypass quotas

Administrative users with appropriate privileges shall be able to bypass quota enforcement when they append messages to mailboxes with the IMAP APPEND command. The configuration option is local.imap.adminbypassquota which, when enabled, will bypass quota enforcement. Messages will be added to quota usage. Messages will not be rejected when the mailbox has exceeded its quota. Over quota warnings will still be delivered.

SMTP Future Release

Mail clients can indicate a future time for a message to be released for delivery up to one calendar year in advance of the current date. This support for RFC4865 has been added. The maximum values specified in the RFC for the option HOLDFOR shall be supported ([phone] seconds). Equivalent HOLDUNTIL timestamp values shall be supported. This support will be enabled by placing the futurerelease channel option on the source channel used for initial message submission. The keyword shall take a single integer argument: the maximum number of seconds a message can be held.

Care should be used when enabling future release since it allows messages to be in effect stored in the MTA's queues. Future release should only be used for channels handling initial message submission and authentication should be required.