Hotdesk

similar ideas have been bounced around, but there's a lot of con's to them. This concept is where REALTIME for the sip.conf was born. However, not being able to have MWI and sip subscriptions (presence) were among several deal-killers. It seems well suited for a simple residential situation like vonage (except for the MWI part) but horribly suited for fully featured unified communications depolyments.

Let's introduce two new extension types: roaming extension and native extension. Actually the native extension is just the usual ordinary extension which is glued to a device. The roaming extension is the one that - well - roams and can be assigned to an arbitrary phone in the tenant.

Say you have a roaming extension 123 and a featurecode to activate it *666. So when you dial *666123 from any phone, TL will mangle the provisioning files and issue a reboot request to the phone. When the phone has restarted, the phone will have two line appearances: The native and the roaming. Log off by simply dialing *666 from your roaming line. Optionally a check should be made that the roaming extensionsn't already configured on another device.

With some handles and triggers, I could write my own custom scripts to move around directory.xml and custom.xml suitable for my setup (polycom). Similar to the existing provisioning stuff.

And it gets even better (somebody stop me!) with roaming huntlists! When a roaming extension is assigned to a roaming huntlist, the native extension where the roaming one logs in will be activated in a real hunt list and receive calls. Now - you have of course turned off 'missed call' on the native extension on the phone. No more absurd amounts of missed calls from busy hunt lists.

Am I totally nuts? (I know - but I'm only referring to the txt above)

/Ole

well you cant put sip.conf in a database and expect to feature-code a phone activation since the phone itself does not work until the phone logs in with a credible entry in sip.conf... its the cart before the horse.

90% of the extension-based code parses the extension from the channel name of the sip channel. Its important that they do match.

It also means a lot of mucking with that damn chan_local.so module which is responsible for most of the dialplan quirks we deal with. Its best to eliminate this middle man entirely versus empower him. You wouldn't actually be able to rename directory.xml as easily as you think since the mac address of the new phone is not something sent as a channel variable or anything in layers 3 - 7. Assuming an MTE environment your phone isnt even somewhere you could match ip with 'show arp'; and lets not forget about how multiple phones behind nat all have the same ip.

do you actually have a real-life example of where someone would move around this much but not take his phone with him? This seems to be less liberating of a MAC (move add change) than just plugging your phone into a new ethernet drop. The #MOVE and *MOVE feature has been in lucent/avaya since the 90s but it was never as flexible as just plugging in your phone and it working w/o user action.

In your scenario you'd probably just want a webpage that lets you put in the mac address and declare what extension it registers as... but thats already there under tools / auto-provisioning.

however, something you CAN do to some extent (keep in mind you're going to miss out on some features) ..

you can create feature extensions and use some form of customized extension handler that calls a queue.

then with the queue application and the dynamic AddQueueMember application you could put or remove yourself from a queue. If your queue names were the floating extension number you could even streamline the *666123 process to a simple pattern.

What you would lose are the features that depend on ASTDB entries: callerid overrides, call forwarding (CFB, CFA), find-me/follow-me, call block, call screening, etc.

This seems rather circular and complex means to avoid moving a phone or re-assigning the mac to a new extension. This also means dealing with chan_local layers that are prone to problems to work around some but not all lost features.

if you want to be even more convoluted you could possibly work around the ASTDB features by creating a bullshit SIP extension under extensions that will never have a phone register to it and create a custom script for it that uses Queue() instead of Dial() so that there still exists a user portal for setting all those options. The shitty/convoluted part is all the uknown channels in sip.conf that will never have devices registering.

One other downfall is that PLACED calls parse extension number from sip channel so even though you selected 'record all calls' outbound calls are never going to lookup extension 1213 since SIP/301 just made the call. Im sure you might come up with some sort of DB entry/translation map for that using customized outbound dialing patterns, but all these DB lookups and layers are going to have one significant impact on your system.. you will likely drastically reduce the scalability and capacity of the system. 100 extensions / 25 concurrent calls might just be the limit without noticeable call setup delays given all the disk i/o and lookups just to do other lookups.