I received the following email from Polycom about the relation between
MWI and Shared Lines on the Polycom sets (they do not SUBSCRIBE to
message-summary for shared lines, so MWI does not work).  I'd appreciate
some input on his last question:
 
Is the intent to have all users of the shared line share and affect the
same voicemail box?
 
I think the answer is "yes": that shared lines would access the same
mailbox, and should be treated exactly the same as not-shared ones for
the purpose of MWI (i.e. we set the msg.mwi.x.subscribe parameter and it
uses credentials for that user when you invoke the MWI callback (to 101)
from that line on the set).
 
It never occured to me to have different sets access different mailboxes
for a shared line...  I think this is what he's asking, and I think that
is NOT what we want.
 
But I wonder if we would want some sets, e.g. the admin's, NOT to
subscribe for MWI for a shared line, while the boss's set does?  This is
configurable, though buried a bit under the phone / Lines / Messaging.
Maybe we could make this more obvious, or just put instructions on the
wiki.
 
Carolyn
 
 


________________________________

        From: Marusiak, Brad
        Sent: Thursday, August 27, 2009 7:58 PM
        To: Beeton, Carolyn (CAR:9D60)
        Cc: Mossman, Paul (CAR:9D30)
        Subject: RE: Question about shared lines on Polycom and MWI
        
        

        Hi Carolyn,

         

        So after some more investigation into this it turns out that its
not so much a bug as I had originally thought, its actually been
intentionally coded like this from day 1. Whereas the original
requirements docs don't seem to be available its clear that from the
code that we are doing this intentionally. Both Sylantro and Broadsoft,
our major partners at that time having shared lines both used
unsolicited notifications to indicate MWI status based on the
registration of the phone and apparently in regard to BLA voice mail was
not shared between the admin/boss model.

         

        Since this is the case I'm moving this issue from a defect to an
enhancement request and its pretty much new territory. 

        I imagine that the SUBSCRIBE goes out as the AoR configured by
our msg.mwi.x.subscribe parameter and any challenges would be
authenticated using the userID and password linked to that user in the
reg.x parameters.

        Is the intent to have all users of the shared line share and
affect the same voicemailbox and MWI of the other or would the
authentication information be enough to allow independent VM and MWI?

         

        Any thoughts on this?

         

        Cheers,

        _________________________

        Brad Marusiak
        Field Application Specialist 
             
        
        Suite 200 - 3605 Gilmore Way

        Burnaby, BC, Canada V5G 4X5
        Direct:  604.453-9404
        FAX: 604-453-9449
        www.polycom.com <http://www.polycom.com/> 

         

         Please consider your environmental responsibility before
printing this e-mail

        
        This communication (including any attachments) may contain
privileged or confidential information of Polycom and is intended for a
specific individual.  If you are not the intended recipient, you should
delete this communication, including any attachments without reading or
saving them in any manner, and you are hereby notified that any
disclosure, copying, or distribution of this communication, or the
taking of any action based on it, is strictly prohibited. 

         

        From: Carolyn Beeton [mailto:[email protected]] 
        Sent: Friday, August 07, 2009 10:35 AM
        To: Marusiak, Brad
        Cc: Paul Mossman
        Subject: Question about shared lines on Polycom and MWI

         

        Brad, 

        We have an early implementation of "shared lines" in sipx now,
and we have discovered that the MWI feature stops working for sets with
shared lines.  It appears that the set does not subscribe to
message-summary events if the line is "shared".  Is this expected
behaviour?  Is there a way to have both?

        Thanks, 
        Carolyn 

<<image001.jpg>>

<<image002.jpg>>

<<image003.jpg>>

_______________________________________________
sipx-dev mailing list [email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
sipXecs IP PBX -- http://www.sipfoundry.org/

Reply via email to