-----------------------------------------------------------
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 unsol
icited 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
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
