[asterisk-dev] Second thoughts on proposed MWI behavior change in Asterisk 12

[Mark Michelson]

Hi folks,

Yesterday afternoon, I put up https://reviewboard.asterisk.org/r/3237/ 
for review, and now I'm starting to question if it's a good idea or not. 
I suggest reading the full description of the proposed change, but I'll 
briefly summarize here. res_pjsip_mwi, the module that allows for MWI 
notifications to be sent to SIP devices, currently can misbehave if 
configuration allows for both unsolicited and solicited MWI to be sent 
to an endpoint. Under current Asterisk 12, if an endpoint is configured 
to receive unsolicited MWI for a mailbox, and that endpoint subscribes 
to an MWI-providing AOR that provides state for the same mailbox, the 
result is that the endpoint will receive both solicited and unsolicited 
MWI notifications for the same mailbox. The solution proposed on the 
review was to behave the way that chan_sip does: send unsolicited MWI 
notifications initially, but when a subscription is established to send 
solicited MWI notifications, stop sending the unsolicited notifications. 
When the subscription expires or is otherwise terminated, resume sending 
the unsolicited MWI.

The reasons why I'm starting to doubt this as a proper way to go are the 
following:
* I noted on the review that setting up a full automated test is proving 
quite difficult since I don't know of a proper tool that can be used to 
willfully subscribe and unsubscribe from multiple MWI sources at the 
same time.
* I also noted on the review that this introduces runtime state to 
unsolicited MWI, and this is currently not handled properly when 
res_pjsip_mwi is reloaded.
* I'm not very happy with the lack of efficiency of the new code.
* Most importantly, I question whether the desire to switch between 
unsolicited and solicited MWI exists. Consider an endpoint that wishes 
to receive mailbox state updates. If that endpoint is going to subscribe 
for MWI updates, it likely does not want to be receiving unsolicited MWI 
notifications at all. And if the endpoint is not going to subscribe for 
MWI updates, then the endpoint is likely going to only want to receive 
unsolicited MWI notifications.

With these points in mind (especially the final one), I propose that 
setting up an endpoint to receive both unsolicited and solicited MWI for 
a mailbox is a misconfiguration and should be treated as an error. If an 
endpoint is configured to receive unsolicited MWI notifications for a 
mailbox, and that endpoint later attempts to subscribe to an AOR that 
provides mailbox state for that same mailbox, the subscription request 
should be rejected since the endpoint is already receiving message state 
for the provided mailbox.

What do you folks think? Should the code in the referenced review be the 
proper way to handle things or is the idea proposed in this message a 
better idea?

Mark Michelson