[Home]

Summary:ASTERISK-00098: "Virtual Extensions" for teleworkers and hot desks..
Reporter:wipeout (wipeout)Labels:
Date Opened:2003-08-14 03:43:47Date Closed:2004-09-25 02:54:43
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:A feature that is really needed is the ability to have "Virtual Extensions". What I mean by that is that PBX's since the begining of time have used a static relationship between the extension and the phone, this left the user as the variable..

I guess back in the old days this was fine becasue people didn't really move much.. Now we have Teleworkers who will work at home or in the office, often these workers don't have a permanent desk in the office so they share a desk with others..

So for this model to work with the telecoms system the extension to user mapping needs to be static and the phone needs to be the variable..

So to make this work Asterisk needs an application that will allow the user to "connect" their extension to the phone that they are sitting next to..

This will give then the ability to move between desks or work in the office or at home and still be able to keep their extension without having to call an admin to reconfigure Asterisk..

****** ADDITIONAL INFORMATION ******

My thoughts were that the user would be allocated an extension and then the mapping of that extension to a phone would need to be stored in some kind of database (or text file/s) that is re-read on each call connection to lookup which phone needs to be used..

The applicatin would probably have to pass 3 variables back being the phone to ring, the voicemail box number (probably the same as the extension) and the voicemail context..

So extensions would be defined somthing like..

exten => 2001,1,VirtualExtLookup
; Return variables {phone} {VMbox} {VMcontext}..
exten => 2001,2,Dial(${phone},10)
exten => 2001,3,Voicemail2(u${VMbox}@${VMcontext})
exten => 2001,103,Voicemail2(b${VMbox}@${VMcontext})

I guess there would need to be "VirtualExtSet" and "VirtualExtUnSet" applications as well so the {phone} variable could be set and unset.. Or perhaps logic that automatically unset the old extextion when a new one was set so that only 1 extension would be routed to that phone..

This could probably be done with an AGI script but it would be a valuable application if built into Asterisk..

I am sure I am missing a whole lot of reasons why this would be difficult to impliment, Things like callerID and other things, but thats the point of putting it in here so it can be dicussed.. :)

If I need to disclaim the idea for Digium to considder it as an addition to Asterisk let me know and I will be happy to do that..
Comments:By: Mark Spencer (markster) 2003-08-15 08:31:26

What about using the Agent support, especially with AgentCallBackLogin?
By: Brian West (bkw918) 2003-08-15 08:38:30

AgentCallBackLogin would work flawlessly for his/her needs.

bkw
By: wipeout (wipeout) 2003-08-15 09:42:01

So what you are saying is this.. Bear in mind I havent used the queuing functionality so I may be wrong with this and if I am please correct me... I am just thinking out loud with my ideas.. :)

Firstly to setup the system to support virtual extensions..(assuming SIP phones only)

Queues method..

1. Phone setup.. (sip.conf)

2. Phones are mapped statically to "local extensions".. (extensions.conf)

3. Users are all setup as agents.. (agents.conf)

4. A queue which will be the users "virtual extension" is then setup for each user where that user is the only agent.. (queues.conf)

5. The users "virtual extension" is then mapped to the appropriate queue.. (extensions.conf)

6. Users then has to log into queue everyday or when a call is missed.. Assuming I understand correctly that an agent is automatically logged out when they miss a call..

Versus virtual extension method (With new apps)..

A. Phone setup.. (sip.conf)

B. Extensions are setup as normal with an extra line to the extension definition that will perform the lookup of that users current "local extension".. So all Asterisk functions in the dialplan still apply as normal..(extensions.conf)

C. Add an entry for each user to the virtual extensions file like..
vexten => {extension},{phone},{VMbox},{VMcontext}
optionally with a password..
vexten => {extension},{phone},{VMbox},{VMcontext},{vpassword}
Where {phone} would initially be a default based on which phone is on their desk but would be updated dynamically (similar to how the VM password is updated from VoiceMailMain) when the user dialed the "VirtualExtSet" application..(new file virtualext.conf)

Then when a new user needed to be added..

Using queues an admin would have to go through steps 3, 4 and 5.. and the User would have to perform step 6..
vs
Using "virtual extentions" only steps B and C are required..


Like I said I am thinking out loud here and my logic may be flawed so please feel free to correct me if I have missed something.. Maybe I am underestimating AgentCallbackLogin but the detailed info in it is scarce.. :)

If AgentCallbackLogin already hase some or most of this functionality would it be difficult to adapt to have it perform the VirtualExt set of functions?
By: Brian West (bkw918) 2003-08-15 09:54:19

I think the mailing list is where this need to continue.  You can get feedback and input because what you want can be done without adding more code/apps to *.
By: wipeout (wipeout) 2003-08-15 10:20:02

I realise that the functionality I am after can be created with various self constructed systems or manipulations of other apps/functions to achive this functionality (these are more often than not a PITA to manage), this functionality is currently not supported natively by Asterisk and I felt it would be a valuable addition to the system for the benefit of not just me but many others as well.. This functionality is a standard feature of many modern PBX's seeing as "Hot Desks" are pretty much becomming standard practice and many organisations today..

Hence the reason I added it as a feature request..

I appologise if I was wrong in adding it here.. I just seemed like the appropriate forum..
By: Mark Spencer (markster) 2003-08-16 11:24:08

I think your idea definitely merits further exploration.  I'll move this to "experimental features".  See if you can get some people to play with this
By: wipeout (wipeout) 2003-08-18 04:20:30

Unfortunately I am not a developer so I can't really help on that side.. Hopefully some others who are developers will read this thread and be able to help..

From my thinking an app like VoiceMailMain would probably have a fair amount of the code needed to manage the virtual extensions.. If the .conf file that managed the virtual extensions was structured similar to voicemail.conf then the code that is used to update the pasword in voicemail.conf could be used to update the extension in the virtual extension conf file..

Maybe the same structure that is used in VoiceMailMain could be used for virtual extensions..
e.g. you call VirtualExtMain and get the prompts,
Press 1 to set extension.
Press 2 to cancel currently set extension(this would cause all call to go directly to VM).
Press 3 to change virtual extension password.
By: John Todd (jtodd) 2003-09-08 21:40:49

I suspect this would be best done in a Dialplan first, using the DBPut DBGet routines to store state information.  This doesn't really need it's own application, as you note above.  It would be a neat addition to the contrib directory as a snippet of code for extensions.conf, and I suspect it's not outside of your ability to create if you think about it for a bit.  :-)
By: John Todd (jtodd) 2003-09-09 00:45:30

Changing to "resolved" as this is just waiting for someone to come up with some demo examples of the code.  Otherwise this could become a ticket that stays in here forever...
By: zoa (zoa) 2004-03-04 15:20:25.000-0600

demo code in:
http://bugs.digium.com/bug_view_page.php?bug_id=0001160