[asterisk-dev] [Code Review] 3237: PJSIP: Allow for flexibility in configuration of unsolicited and solicited MWI notifications.

Wed Feb 19 16:44:44 CST 2014

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3237/
-----------------------------------------------------------

(Updated Feb. 19, 2014, 10:44 p.m.)

Review request for Asterisk Developers.

Changes
-------

I realized I had a glaring flaw in my change_unsolicited_mwi_activation() calls.

Bugs: ASTERISK-23285
    https://issues.asterisk.org/jira/browse/ASTERISK-23285

Repository: Asterisk

Description
-------

chan_sip's MWI configuration allows for a certain amount of flexibility when it comes to solicited and unsolicited MWI notifications. In chan_sip, a peer can configure a set of associated mailboxes. By default, the peer will receive unsolicited NOTIFYs whenever one of the mailboxes in the set changes state. If the peer subscribes to MWI, then chan_sip will seamlessly switch to sending the MWI notifications on the subscription's dialog. If the peer unsubscribes from MWI, then chan_sip will again seamlessly switch to sending unsolicited MWI notifications again. Configuring a peer in this manner is nice if you are unsure whether the peer will be subscribing to MWI or not. In most cases, chan_sip's default behavior will "just work". For cases where a peer does not react well to unsolicited MWI notifications, the "subscribemwi" option can be enabled so that Asterisk only sends MWI notifications if there is an active SUBSCRIBE dialog with the peer.

With PJSIP, things are a bit different. Endpoints can be configured to receive unsolicited MWI notifications for a set of mailboxes. In addition, AORs can be configured to provide notifications for a set of mailboxes if an endpoint subscribes to MWI at that AOR. This currently implies an either/or situation where we expect strictly unsolicited MWI or strictly solicited MWI. If pjsip.conf is configured in a way such that an endpoint and an AOR have overlapping sets of mailboxes, then it's possible for the endpoint to receive both solicited and unsolicited MWI for the same mailbox when it changes state. No one wants that.

What complicates things with pjsip.conf is that, for all intents and purposes, endpoints and AORs are loosely coupled. There are cases where the set of mailboxes configured for unsolicited MWI on an endpoint may be partially disjoint from the set of mailboxes configured on an AOR to which the same endpoint subscribes. Furthermore, a single AOR may provide mailbox state for multiple endpoints that have subscribed to it, and an endpoint may subscribe to multiple AORs for mailbox state. This means it's not a simple case where an established set of unsolicited MWI can just "switch over" to being solicited. Instead, my approach to this problem is to add the concept of activation/deactivation to unsolicited MWI. When an endpoint subscribes to mailbox state provided by an AOR, if there is an intersection with the mailboxes provided by the AOR and mailboxes being serviced by unsolicited MWI, then the unsolicited MWI is deactivated. Activation/deactivation is represented by a counter so that if an endpoint subscribes to multiple AORs that deactivate the unsolicited MWI, each of the subscriptions adds to the counter. When subscriptions are terminated, then the unsolicited MWI counter is decremented. If the unsolicited MWI activation counter reaches 0, then the unsolicited MWI is resumed.

Have an example! Consider this pjsip.conf:

[alice]
type = endpoint
mailboxes = box_a,box_b

[bob]
type=endpoint
mailboxes = box_a,box_b
aggregate_mwi = no

[aor1]
type=aor
mailboxes = box_a,box_c

[aor2]
type=aor
mailboxes = box_b,box_d

Alice and Bob are the endpoints on this system. They both are configured to receive mailbox state updates for box_a and box_b. The difference between the two endpoints is that Bob has the aggregate_mwi option disabled (the option is enabled by default). This means that Alice has a single unsolicited MWI notification set up that provides the combined state of box_a and box_b. Bob has an unsolicited notification set up for each of box_a and box_b. Given this setup, let's say that Alice and Bob each subscribe to MWI provided by aor1. aor1 provides state for box_a, for which both Alice and Bob receive unsolicited MWI. For Alice, her single unsolicited MWI notification is deactivated. For Bob, only his unsolicited MWI notification for box_a is deactivated. Bob will still received unsolicited notifications when box_b changes states. Now let's say that both Alice and Bob subscribe to MWI provided by aor2. aor2 provides state for box_b, for which Alice and Bob are configured to receive unsolicited MWI. In Alice's case, since her unsolicited MWI notification for box_b is already deactivated, her deactivation count is incremented. In Bob's case, his unsolicited notifications for box_b are now deactivated. At this point, Alice and Bob are no longer receiving any unsolicited MWI notifications. Now Alice and Bob both unsubscribe from MWI notifications provided by aor1. In Alice's case, the unsolicited MWI notifications for box_a have their deactivation count decreased by 1; since the deactivation count is non-zero, it results in Alice still not receiving any unsolicited MWI. In Bob's case, the unsolicited MWI for box_a gets reactivated. Now Alice and Bob both unsubscribe from MWI notifications provided by aor2. This results in the state of both Alice and Bob resetting to what they were at the beginning of the example.

One flaw that I'm aware of in this change is that runtime state has been added to unsolicited MWI notifications, and this runtime state is wiped out if res_pjsip_mwi is reloaded. res_pjsip_mwi's reloading logic needs to be reworked to use sorcery observers. This way, when endpoints or AORs are reloaded, the MWI code can take appropriate action without itself having to be reloaded. When res_pjsip_mwi.c is converted to use sorcery observers, it can be updated to also preserve runtime state when updates occur.

Diffs (updated)
-----

  /branches/12/res/res_pjsip_mwi.c 408442 

Diff: https://reviewboard.asterisk.org/r/3237/diff/

Testing
-------

Well...testing this is problematic. I want to write an automated test that verifies all of the assertions made in the example provided in the description. Unfortunately, none of the tools we currently use are working well for this situation:
* PJSUA's python bindings do not allow for an account to be configured to subscribe to MWI. Even if the account configuration code were altered, it wouldn't allow for me to subscribe and unsubscribe from MWI at will without making larger changes to PJSUA python code and possibly even PJSUA C code.
* Asterisk is not a good fit either. chan_sip allows for outbound MWI subscriptions to be configured, but it does not allow for me to control when the MWI subscriptions are begun or ended. Also, there's no easy way to determine whether details in the MWI notifications received are what is expected.
* SIPp does not fit well either. SIPp can be used for an easy scenario where an unsolicited NOTIFY is received, and then SIPp subscribes for MWI. However, anything more complex than that (such as ending a subscription or trying to have multiple subscriptions) will not work. Even though the simple situation technically works correctly, SIPp re-uses the same Call-ID from the unsolicited NOTIFY when it subscribes for MWI, meaning that simple inspection of the SIP traffic is not enough to easily determine that res_pjsip_mwi.c is actually doing the right thing.

I've done some brief manual tests with SIPp and I've run the MWI tests in the testsuite to ensure that these code changes have not caused issues. But that really doesn't exercise the code changes presented here.

Thanks,

Mark Michelson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140219/c842d641/attachment-0001.html>