<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Feb 20, 2014 at 8:29 AM, Mark Michelson <span dir="ltr"><<a href="mailto:mmichelson@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=mmichelson@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">mmichelson@digium.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks,<br>
<br>
Yesterday afternoon, I put up <a href="https://reviewboard.asterisk.org/r/3237/" target="_blank">https://reviewboard.asterisk.<u></u>org/r/3237/</a> 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.<br>

<br>
The reasons why I'm starting to doubt this as a proper way to go are the following:<br>
* 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.<br>

* 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.<br>
* I'm not very happy with the lack of efficiency of the new code.<br>
* 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.<br>

<br>
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.<br>
</blockquote><div><br></div><div>With my "user" hat on, I think this is fair.  What would the subscription rejection look like?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
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?<span class="HOEnZb"><font color="#888888"><br>
<br>
Mark Michelson<br>
<br>
-- <br>
______________________________<u></u>______________________________<u></u>_________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
  <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/<u></u>mailman/listinfo/asterisk-dev</a><br>
</font></span></blockquote></div><br></div></div>