[Home]

Summary:ASTERISK-04269: [patch] Voicemail server/client MWI notifier + executing diaplan ext. upon IAX2/SIP registering/unregistering
Reporter:x martinp (martinp)Labels:
Date Opened:2005-05-24 21:39:38Date Closed:2011-06-07 14:05:15
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 3-feat-CVS-2005-05-02
( 1) 3-feat-HEAD.diff
Description:This is a patch against CVS HEAD requested by the Chris A. Icide.
1) The voicemail server allows notifing the client of MWI information over IAX2.

The client's sip/iax2 peer entry should have this keyword:
[peer]
mailbox=remote_box:remote_context@[ip_of_remote_voicemail_server | iax2_peer_name_of_remote_voicemail_server]

Then voicemail server has to have in voicemail.conf in general section:
voicemail_server = [ip_of_the_box | iax2_unique_peer_name]

the iax2_peer_name_of_remote_voicemail_server = iax2_unique_peer_name has to be unique and in iax.conf pointing either by host=ip or host=dynamic (then the IP of the box is taken from registrations)

also in voicemail.conf the mailbox has to be configured as follows:

[context]
box:[ip_of_the_client_machine | iax2_unique_peer_name_of_the_client_machine] => pin, etc

2) ChangeMailbox application to change on the fly the mailbox= setting or the mailbox definition in voicemail.conf

3) on register/unregister event of IAX2/SIP executing some extensions in the dialplan

you need to add the

[peer_name]
onregister-context=context_name

in the definition of the peer that has to have that feature

then the dialplan will execute extension peer_name in the context context_name
the unregister event context has "unreg-" keyword prepended to the oregister-context name

I think that's ALL!
Comments:By: twisted (twisted) 2005-05-25 00:10:35

this seems awful complicated from a configuration standpoint.  Is there any way to simplify it?

My suggestion would be:

in voicemail.conf of "server" box:

[context]

<boxnum>:<technology>:<remote ip/peer name> => <pin> etc..

and in voicemail.conf of the "client" box:

[context]

remote:<boxnum>

this way, regardless of the configuration, the following is true:

1) the client knows to look for remote notification pushed to it from a remote source (this way it would be seamless to expand to sip, or other channel drivers).

2) the "server" box will continue to act normally, and push mailbox data via the specified channel driver to the "client" box, as if it would any other user.  

Just a suggestion. Let me know what you think.



By: x martinp (martinp) 2005-05-25 01:18:21

Well it's not me who's going to use it ... let Chris Icide decide :) Besides it should be a straight forward patch when the bug marshall commits it ...

By: Michael Jerris (mikej) 2005-05-25 06:50:40

I'm not liking the syntax either.  You are going to need community support in order to get this into the tree.  Simpler to configure is better.

By: Chris A. Icide (cicide) 2005-05-25 13:53:35

I've been testing a version of this Martin made for me (against May 2, 2005 HEAD) and it's been working very well.

While I agree that the configuration can seem complicated, it's pretty simple once you understand it.

Note that there are three different patches here.

1. Remote voicemail (server to server) notification via iax
2. ChangeMailbox function which allows you to add/change a mailbox pointer through the dialplan (this I think is the most complicated because the change needs to be made both at the voicemail server and remotely if you are using remote voicemail)
3. Registration & expiration causes dialplan entry.

I find these three functions as a whole, immensely valuable.  Using these tools, you can basically allow an end user device (SIP/IAX) to register dynamically to any asterisk server that belongs to a single administrative asterisk cluster.

I support it fully, and while there are some changes I'd like to see, I'm not sure I can continue to fund it's development out of my own pocket right now.

By: Chris A. Icide (cicide) 2005-05-25 14:37:38

Configuration NOTES:


First, the remote voicemail notification configuration:

In voicemail.conf under the general section we need to identify that this voicemail server
is a centralized voicemail server supplying remote notification.  This is done by adding an

entry that points at an iax entry for this server.  Note that you must add an entry for this

server in your IAX configuration.

[general]
voicemail_server=<unique_IAX_peername_of_this_server>

On the same server we will configure the voicemail boxes.  There is one new entry required

over the normal user configuration and that is the remote asterisk server hosting the client

device to which we will be sending voicemail indication.  This is included as an IAX entry

(must also exist in your IAX config) as shown here

[default]
<vmbox>@<iax_peer> => <pin>,<name>,etc..

or if we have voicemail box 1000 being served for a client device attached to IAX peer

'sip-reg-srv-001' as defined in your iax.conf file, the line would look like this:

[default]
1000@sip-reg-srv-001 => 1000,John Doe,jdoe@john.doe....

All servers (both central voicemail and remote client) must have iax entries for each other

(and the central server must include an entry for itself in it's own iax.conf file).  Servers

can be dyanmic (host=dynamic) as well as static.

In the sip.conf or iax.conf for each device there is a change to the mailbox= argument.  Note that the mailbox=<user> still works for locally served mailboxes.  For remote mailboxes the format is this:

mailbox=<user>:<vm_context>@<iax_peername_of_VMserver>

so in the example above, it would look like this

sip.conf
[1000]
type=friend
host=dynamic
mailbox=1000:default@vm-srv-001

where 'vm-srv-001' is the entry in the iax.conf for the central voicemail server

This configuration does not include automatic routing of voicemail commands (voicemail and voicemailmain).  You must still route calls to voicemail to the central voicemail server through your dialplan.  If you try and call a voicemailbox directly on a remote client you will get a no such voicemailbox error.  So when you want to leave voicemail or retrieve it, the call needs to be sent to the central voicemail server where you would then execute the VoiceMail or VoiceMailMain functions.


Second, the ChangeMailbox function


There is an application that you can change the mailbox= definition in either iax.conf/sip.conf or voicemail.conf (changes are NOT reflected in the configuration files, they are not updated by this command)

ChangeMailbox(tech,name=newsetting)

On the central voicemail server, you can change both the voicemail entry as well as the sip or iax entry.  On the remote client servers you can only change the sip/iax entries.

To change the remote server in which a client's voicemail status is sent, you would use the Voicemail keyword for technology in the following structure:

1) Voicemail
ChangeMailbox(Voicemail,<mailbox>@<iax_peername>)

On the system which hosts the UA device, you would use the following structure, with SIP or IAX as the technology:

2) IAX/SIP/etc
ChangeMailbox(IAX,<user-123>=<mailbox>:<vm-context>@<iax_peername-central_vmserver>)

To completely change the location a voicemail indication is being sent, you may need to exectute this command on both the central vm server as well as the remote client server.  The entry on the voicemail server tells the vm server what remote asterisk server to send the notification to.  The entry on the remote client server tells the local asterisk system which device to notify.  So in the case that the device only changes (you want to send or add vmail indication to another device on the same server) only the SIP or IAX entry need be changed.  However if the device moves to a different remote client server, you will also need to tell the central VM server to change where it's sending notification as well.


Now the 3rd feature ...
in iax.conf or sip.conf for each user define the keyword 'onregister-context'

syntax:

[user]
type=friend
onregister-context=regcontext
etc

then upon registry, (context,exten) = (<onregister-context>,<user>,1) will be invoked and on unregister the (unreg-<onregister-context>,<user>,1) is invoked

So on unregister 'unreg-' is prefixed to the onregister_context

The variable ${DEVICETECH} contains the technology of the device registering.

To rebuild the unique channel, you would use ${DEVICETECH}/${EXTEN} which for example would return SIP/1000 in the case of that device registering



By: Chris A. Icide (cicide) 2005-05-25 22:55:15

Added patch for CVS HEAD on 2005-05-02 for people who want to test with pre-function changes

By: Chris A. Icide (cicide) 2005-05-31 11:35:46

Re: Twisted's recommended configuration format

So basically, in the UA configuration, you are recommending we stick with the basic mailbox=boxnum configuration and move the remote intelligence to the voicemail configuration?

So in the centralized voicemail server(s) you would have an entry under the specific context for the boxnum that would look like:

[context]

<boxnum>@<tech>:<remote ip/peer name> => <pin>,etc.

or you could have it as an option field

<boxnum> => <pin>,.......|remote=<tech>:<remote ip/peer name>

Then on the remote box (hosting the client UA), in the voicemail.conf file


[context]

remote:<boxnum>


-----

It seems to me this would be simpler.  I'll check with Martin to see what the issues might be  I don't think this kills any of the features I had in mind for the function.

By: gkloepfer (gkloepfer) 2005-06-02 22:27:35

(cicide requested I look at this re: my patch 0004236 ... my apologies for being completely out of touch on this issue since I suggested my patch -- I got dragged away from Asterisk again for something else at work ... argh!)

Some of the syntax of this, as others have said, is really confusing.  I'm still not entirely sure if this solves my issue or not in 0004236, although it SEEMS like it does.

Let me try to set-up the scenario I was trying to solve, quickly:

You have Asterisk server "A" which is the centralized voicemail server, and server "B" which is servicing extensions with voicemail boxes on server "A".  For SIP phones, this may seem a little redundant, but for Zap channels, it definitely isn't (we're going to have a remote PBX at another location).

That said:
I think I get the mailbox= syntax change in the physical extension entries in {iax,sip,zapata}.conf on server "B".  What would need to be added to iax.conf on server "B" (aside from having the normal IAX options in iax.conf)?  I think this is where the voicemail_server=peer goes into [general] ... but I have no idea what else goes there.

What I really don't understand is what goes on server "A".

If someone could summarize this a little better, I'd probably say "Ah ha!" and realize it does everything I ever wanted including make lemonade in the summertime! :-)

Here's an example of what I'm looking for, and how I understand how this works (as best as I can):

Assuming I have a mailbox "200" in VOICEMAIL context "default" on server A (using my description of server A and B above)

--- Server A ---
voicemail.conf:
[default]
200@server-a-b-link => 12345,Gil Kloepfer,no@spam.com

iax.conf:
[server-a-b-link]
type=friend
host=serverb
context=serverb-incoming
(blah blah blah)

--- Server B ---
iax.conf:
[general]
voicemail_server=server-a-b-link

[server-a-b-link]
type=friend
host=servera
context=servera-incoming
(blah blah blah)

zapata.conf:
signalling=fxo_ks
usecallerid=yes
context=extensions-incoming
callerid="My Phone" <200>
voicemail=200:default@server-a-b-link
channel => 1

---------------------------------

Is this correct?

Something seems wrong with the voicemail.conf on servera...but I don't think I'd want this on serverb, or I'd have to keep track of voicemail.conf entries on two systems rather than one.

By: Olle Johansson (oej) 2005-06-05 03:55:50

You have too many different functions in one mantis issue. Please split this up so we can separate discussion on remote voicemail (stays in this report) and the other functions. Thank you!

By: Olle Johansson (oej) 2005-06-05 04:02:51

What is the idea behind the simple channel? Please tell us more about it, it lacks documentation :-)

By: Chris A. Icide (cicide) 2005-06-05 22:18:35

I sent an email to martin asking him to drop by and answer Olle's question.

As for the config questions, to understand the config better I think you need to understand how the system works in general.

Currently modifications are required to the config files on both the voicemail server as well as the remote asterisk server which hosts the device that we will be providing MWI signalling to.

You need to tell the voicemail server which remote server to send the MWI updates to (it pushes them out).  This is done via the voicemail.conf file on the voicemail server.

You need to tell the remote asterisk system that it should be checking it's remote MWI table for pushed updates for certain client devices.  This is done via the mailbox= parameter in the client configuration file (sip.conf, iax.conf, etc.)


I spoke with Martin about changing the configuration to one like twisted recommended where you would leave the device configuration file alone (sip.conf...) but modify the local (on the non-voicemail server system) voicemail.conf file to indicate that voicemail for a particular voicemail user is served remotely.  He will get to making that change as soon as he can, but currently doesn't have the time.

By: Michael Jerris (mikej) 2005-06-26 18:35:01

Suspended due to 3 weeks no response.  I would really like to see this work continued.  If you are still interested in this bug, please reopen with the responses to oej as requested.  Thanks.