[asterisk-dev] MWI expectations

[Mark Michelson]

Hi devs,

I'm in the process of defining an API in the new SIP work for SIP SUBSCRIBE/NOTIFY events. As a proof of concept, I'm implementing MWI support. I'm writing to the list right now because I'm interested in what expectations are with regards to MWI.

I'll begin by describing the behavior in chan_sip.

In chan_sip, a peer configures mailboxes using the "mailbox" option in configuration. The option is a comma-separated list of mailboxes defined in voicemail.conf. In addition, there is an option called "subscribemwi" that determines whether we send MWI unsolicited or whether we require a SUBSCRIBE to be sent from the peer before we start sending MWI NOTIFYs.

For unsolicited MWI, any time one of the configured mailboxes changes state, we create an MWI NOTIFY to send out. This MWI NOTIFY contains the combined number of new and old messages for all of the configured mailboxes for the SIP peer. What this means is that there is a many-to-one relationship between configured mailboxes and SIP MWI subscriptions.

If using solicited MWI, then we first require a SUBSCRIBE for the "message-summary" event to arrive from the peer. When such a SUBSCRIBE arrives, we then exhibit the same behavior as for unsolicited MWI. That is, we send a NOTIFY with combined mailbox state of all configured mailboxes when any of the configured mailboxes changes state. If we receive a subsequent SUBSCRIBE from the same peer intending to start a new dialog, then we end the old dialog and use the new SUBSCRIBE as the basis for sending MWI NOTIFYs to the peer.

This process works for many scenarios, but there are some limitations:

* It assumes that the peer in question is a phone with a single MWI indicator. Combining all mailboxes' states into a single MWI NOTIFY makes sense when communicating with such a device, but it may not make as much sense for other types of endpoints.
* If a SUBSCRIBE request arrives, there is no attempt to look at the request URI in order to try to determine if there is a specific resource that is desired. It is just assumed that configured mailboxes for the peer are what is wanted.
* If multiple SUBSCRIBEs arrive, then the subsequent ones replace the previous ones as opposed to allowing multiple subscriptions to be active.

For MWI in the new SIP work, I'd like to know what expectations are for its behavior. If the current chan_sip behavior is fine, then I can mirror its behavior. I suspect, though, that this is not what is desired, so I have a tentative idea for how MWI will function:

Like with peers in chan_sip, we will allow for endpoints to configure mailboxes. Any mailboxes listed on an endpoint will be assumed to be unsolicited MWI. The directive on whether to combine the mailbox states into a single NOTIFY will be determined by a configuration option (e.g. "aggregate_mwi"). Thus if you had an endpoint configured like so:

[alice]
type=endpoint
mailboxes=alice at vmcontext,tech-support at vmcontext
aggregate_mwi=yes

Then alice will be sent a NOTIFY with the aggregated voicemail state of alice at vmcontext and tech-support at vmcontext any time that either of the mailboxes changes state. If the aggregate_mwi option had been set to "no" then alice would be sent individual NOTIFYs with each individual mailbox's state when the mailbox in question changes state.

For solicited MWI, the request-URI of the SUBSCRIBE will determine what mailbox(es) to subscribe to. The request-URI will map to a configured address of record in res_sip.conf. Mailbox options on that AOR will determine what mailboxes' states are reported. If you had an aor configured like so:

[sales]
type=aor
mailboxes=jim at vmcontext,bob at vmcontext,lucius at vmcontext

Then if a SUBSCRIBE arrives that wishes to subscribe to "sales" then the result would be a subscription that relays the combined state of the three configured mailboxes in the "sales" aor. Unlike with endpoints, there is no need for an aggregate_mwi option since the mailboxes have been explicitly grouped under the banner of a single aor. If non-aggregated state were desired, then the mailboxes can be placed into separate aors, and individual subscriptions can be made to each aor in order to subscribe to the individual state of each mailbox.

With this method in place, it allows for an endpoint to use a combination of solicited and unsolicited MWI if desired, and it allows for multiple MWI subscriptions, which is currently missing from chan_sip. It also allows for central definitions of arbitrary groups of related mailboxes.

Let me know what you think. Is the current scheme used by chan_sip exactly what should be done for the new SIP work? Are my ideas for configuration in the new SIP work great/okay/awful or in need of further explanation? Are there any shortcomings of MWI support in chan_sip that I have not touched upon that should be addressed in the new SIP work?

Thanks in advance for your feedback,
Mark Michelson