[Devel] Voicemail handling (message waiting indicator)

[Christian Schlatter]

Dimo,

Could you list some example SIP UA products that do only accept MWI 
NOTIFYs with the caller-id from the initial registration?

The endpoints I've seen so far do all accept so called unsolicited MWI 
NOTIFYs, so they don't care about the caller-id at all. Examples are 
Polycom, Snom, Cisco, or Linksys SIP phones.

Christian

Dimo wrote:
> Hello guys,
> I want to start a discussion on the possibility to make openser
> voicemail aware and enable it to handle messages from voice mail
> servers correctly. Please anyone feel free to jump in with suggestions
> or corrections. Here is my understanding of how voicemail and message
> waiting indicator works:
> In the below openser is proxy between the UA and voicemail (VM) server
> scenario I:
> 1 - someone leaves a voice message on VM server for a registered UA
> 2. VM -----(notify-with old/new msgs)---->openser------->UA /with
> branching to all UAs/
>  2.a - UA receiving the notify activates the Message Waiting
> Indicator (MWI) showing there is a voicemail message(s) waiting
> 3. UA -----(-OK)------>openser---->VM server
> 
> scenario II:
> 1 - someone leaves a voice message to VM server, but the UA it is for
> is not registered.
> 2. VM--->(notify-old/new)--->openser (lookup fails)
> 3. VM <-----( 404 not found)<--openser
> 4. After some time a UA registeres and we want to be able upon
> registration to tell it how many messages it has with a notify. The VM
> server however will not send a new notify until a new voicemail
> arrives, and has no way of knowing that the UA is online and should
> receive another notify.
> 
> Here is how i think it should happen in openser.
> For scenario I: a great number of UAs will ignore a voicemail notify
> message as not for them if it does not contain the call-id the UA used
> upon registration. To address this, I propose 2 functions
> - one will overwrite the call-id in the initial notify (scenario I
> step2) with the call-id from the UA registration (available in
> location table) and save the original call-id in record-route. This
> function will have to be available from branch route too, as there may
> be more than one UA registered. It can be even an extension to lookup,
> to avoid duplicate db queries.
> - a second function that is able to reverse the process from above -
> rewrite the call-ID of the reply (OK) with the one saved previously in
> RR, so that the relayed reply to VM is for the original call-id and is
> understood by the VM server.
> 
> For scenario II:
> The subscriber table could be expanded with a "voicemail params"
> field, and again 2 functions for the script could be implemented:
> - the first will take the info from a notify about old/new msgs and
> store it in the subscriber db upon receipt of a notify (scenario II
> step2)
> - the second (maybe done in uac module?) will have to be able to
> generate a generic notify to a location which will be lookup()-ed by
> getting this extra info from the subscriber table and the call-id of
> the register request.
> 
> The problems I see with this are that for some messages there are too
> much store and retreive functions done several times, so I think it
> will be even better if the lookup function can be extended with a
> parameter so it will extract the call-id with the one of location DB
> and retreive the VM info in some avp - in this way it will save db
> queries over the same table (location) done by different functions.
> 
> This is getting longer than I wanted so I will just add that I know
> Voicemail can be handled by subscribe and openser will probably work
> without change then, but the scenarios I propose are aimed at the vast
> majority of UAs that do not support subscribe methods. All UAs i have
> met untill now, however, support the Message Waiting Indicator, which
> is activated upon receiving the correct Notify message, even without
> subscription.
> 
> Please make any corrections or suggestions you may have to this request.
> 
> Best,
> Dimo
> 
> _______________________________________________
> Devel mailing list
> Devel at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/devel