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

[George Joseph]

On Thu, Feb 20, 2014 at 8:29 AM, Mark Michelson <mmichelson at digium.com>wrote:

> 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.
>

With my "user" hat on, I think this is fair.  What would the subscription
rejection look like?


>
> 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
>
> --
> _____________________________________________________________________
> -- 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140220/10c41625/attachment.html>