On Thu, Feb 20, 2014 at 8:29 AM, Mark Michelson <mmichel...@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 >
-- _____________________________________________________________________ -- 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
