[Devel] Voicemail handling (message waiting indicator)

Mike Williams mike at mikebwilliams.com
Fri Jan 26 15:30:04 CET 2007


Dimo,

Sounds like useful functionality, but could part of this be done by extending 
the silo module? I think it stores messages for offline users and then 
forwards them when they come online. Perhaps it wouldn't be too hard to have 
it handle the MWI NOTIFY messages.

Mike


On Friday 26 January 2007 03:02, 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



More information about the Devel mailing list