[Asterisk-Dev] [RFE] User interface - login, voicamil etc.

[Fran Boon]

On Sun, 2004-04-18 at 14:55, Chris Lee wrote:
> For a while now I have been trying to get asterisk to provide a single
> user interface for all user related tasks.
> I tried to learn C and after big time brain strain am officially giving
> up, asterisk components are far to big a thing to start with when
> learning to code in C.

hehe, snap ;)

> I know I could probably use and AGI to get at least some of this done in 
> a language I know better, but I feel that it would be smoother if native 
> apps were used.
> Since I have called it a day, but dont want to give up on the idea I
> thought I would explain what I tried to do in case any of you think it
> is worth a go, and in the hope that these features may be implemented
> one day so that I get to use them.

Actually, I think that most of this stuff can be done through scripting
- in fact I have much of this in place already & I've not had to write
any AGIs - just a little PHP & Perl to control config items in a
database which get written out to text files & Asterisk reloaded.
All works very well for me :)
http://voip-info.org/wiki-Asterisk+configuration+from+database
(I'm using item 2)

I am currently enhancing this to use app_dbodbc to allow for greater
flexibility within the dialplan instead of having to write everything
out as text files...
http://voip-info.org/wiki-Asterisk+app_dbodbc

> This is what I had in mind:
> Either make VoicemailMain scriptable and modular to extend features or
> use an extension based menu with simple apps like the following to do
> the work:
> Authenticate
> 	-Get a user to type in their extension number and password
> 	-If user-database confirms then set $Auth to true and $user to
> 	extension number.
> 	-If user-database does not confirm set $Auth to false, $user to
> 	null, and or increase the priority by something appropriate.
> 	Next priority decides to hangup or not.
> 	Can use Voicemail password to allow for backwards compatibility,
> 	Though we do need it stored centrally on a DB where all PBXs can
> 	access the information.

I've not written this myself yet (on the ToDo), but it seems very simple
to do within the dialplan:
http://voip-info.org/wiki-Asterisk+cmd+Authenticate

> LogOntoPhone($user,$PBX)
> 	-Store the device (e.g. SIP/phone1 )and $PBX in the users
> 	user-database record
> 	-$PBX is a URL for the proffered connection method of current
> 	PBX to allow for roaming users, something like:
> 	IAX2/servername:password at id
> 	-A related app called RouteCall(${EXTEN}) will collect
> 	these bits of information from the database and set a variable
> 	called $URL to the correct string for dial to use to send the
> 	call where it needs to go.
> 	-On a remote PBX the URL produced by RouteCall would look
> 	something like this: IAX2/servername:password at id/${EXTEN}
> 	-On the server the user logged onto the URL would look something
> 	like this: SIP/phone1
> 	-RouteCall(${EXTEN}) will either respond with a valid $URL or
> 	jump to priority n+2 thus if dial was next app in line it goes
> 	to where dial goes on unavailable.

I have the ability for user to specify their phone type - which loads
different templates within chan_sip2 or tells the dialplan that they're
on IAX atm (by writing out a file called users-iax.conf which is
#include's into iax.conf & another called iax-phones.conf which is
#include'd into extensions.conf (in a context that gets searched before
the default SIP section)

I like the idea of extending this to select which PBX they're on...I'd
just started wondering how I was going to get this to work :)

> LogOffPhone($user)
> 	-Remove the device data from users database record

Yup, part of the login application...

> DivertCall($user)
> 	-Place a link in users database record so that
> 	RouteCall(${EXTEN}) can put these links together and produce the
> 	correct URL for the dial app.

I have this working already.
My UI writes out a 'calldiversion.conf' which is #include'd into
extensions.conf
I have another for Do Not Disturb (dnd.conf)

> For voicemail interaction we can go one of two ways:
> Either
> VoicemailMain($user)
> 	-Modified version with support for accessing voicmail on users
> 	home PBX if they are using this app on another PBX.
> 	-Activate and deactivate voicemail feature, when user has
> 	deactivated voicemail any callers will not be sent to voicemail.

Deactivate voicemail? Nice - have added to my ToDo - should be pretty
straightforward...

> 	-Listen to voicemail etc.
> 	-Standard voicemail features
> Or
> VMHome($user)
> 	creates a call through to users home PBX VoicemailMain
> 	-So long as when the user exits voicemailMain we are able to
> 	drop the call and remain in the menu this is possibly better as
> 	it keeps the standard apps unaltered.
> 
> There are other things that need to be in here but this was all I was
> after when I started.
> 
> Outside of the user interface menu system a few apps need to be created
> to allow the standard apps to continue to work normally.
> 
> RoutCall(${EXTEN})
> 	Described earlier

I don't believe this needs a C app

> RouteVM(${EXTEN}u|b)
> 	-This will be used to store a dial string in $URL to forward the
> 	call to $EXTEN in the [voicemail] context on the users home PBX.
> 	-May need to use an extra digit to allow for unavailable or busy
> 	recognition.
> 	e.g. caller dialed exten 3000 RouteVM sends call to
> 	13000 for unavailable  or 23000 for busy in the [voicemail]
> 	context on the users home PBX.
> 	So the output for a busy could look like this:
> 	IAX2/servername:password at id/2${EXTEN}@voicemail
> 	and an unavailable like this:
> 	IAX2/servername:password at id/1${EXTEN}@voicemail

I'll have to think more about this one...but I'm pretty sure it wouldn't
need a C app either...

> Thanks for reading this.
> Chris.

My pleasure :)

I hope that you find my comments helpful :)

Fran.