[Devel] Voicemail handling (message waiting indicator)

[Dimo]

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