Understanding the SARKHD hot desking feature

SARKHD (Hot Desk) is an add-on feature for registered SARK subscribers. It allows for true hot desking on the SARK Platform. SARKHD is, we believe, unique in that it supports MWI, CLID, Caller name and personalised settings, including BLF and custom buttons, in the hotdesk implementation. Up to press, other Asterisk based HD implementations have used redirects or dynamic queue agents to achieve their aims. While there is nothing intrinsically wrong with these techniques, they cannot really be classed as true hot desking because they do not support MWI, CLID or BLF personalization. Perhaps a better term for these implementations would be "follow me".

SARKHD is different because it works a lot like the "big iron" implementations from the telecoms majors. A "Cuckoo" agent effectively "steals" the donor phone's identity during hotdesking. This is done by physically reconfiguring and restarting the phone on-the-fly and bringing it back up with a new identity, albeit a temporary one. The daigram below illustrates how a hotdesk identity is set up and what actually happens during a hot desk session.

SARKHD introduces the notion of "Virtual" extensions. Every hot desk user is allocated a Virtual extension. Under normal circumstances a virtual extension behaves exactly the same as a real hard-phone extension with one difference; it isn't always attached to a real phone. When no phone is attached, the virtual extension can still receive voicemail ot participate in redirects, perhaps forwarding calls to a cellphone or domestic number, perhaps "forking" calls to multiple destinations simultaneously. Additionally, the virtual extension has "real" ;provisioning information stored in the SARK UCS/MVP database. This includes details about how a real phone should be set up for this user; including things like caller-id, extension number, BLF and other button settings.

A virtual user can "hot desk" by "logging in" at a regular phone. The diagram above illustrates what happens. After the virtual extension is defined (steps 1 and 2 in the diagram) the user can log in as a hotdesk user by keying in the hotdesk feature code followed by her virtual extension number. SARK UCS/MVP will challenge for a password (for convenience, we use the voicemail password) and then begin the log-in process.

In step 3, hotdesk user performs a log-in at the donor phone. In Step 4, SARK UCS/MVP saves the donor phone's provisioning file under a temporary name for later retrieval. Next, the donor phone's MAC address is "stolen" by the hotdesk extension. This is accomplished by writing a new provisioning file containing the provisioning information belonging to the hotdesk user, but using the MAC address of the donor phone. The donor phone is then restarted, on-the-fly, by SARK UCS/MVP . When it reboots it will pick up the hotdesk extension's provisioning data and effectively become the hot desk extension. Because the virtual extension has now become "real", the MWI lamp, BLF and other keys will all work correctly for the hotdesk virtual extension.

At the end of the session the hotdesk user enters the logout feature code. SARK UCS/MVP reverses the process by retrieving the saved provisioning file for the donor phone and forcing another on-the-fly restart. We anticipate that oftentimes, the hotdesk user will forget to log out. For this reason, hotdesk entities are given a "lease" time when they are created. At the expiry of the lease (the default is 12 hours but it can be set to any value) the phone will automatically be returned to its default donor extension state.

Additionally, hotdesk functionality will automatically "follow" the hotdesk owner. For example, if a hotdesk user issues a logon request, SARK UCS/MVP will check to see if this user is already logged in at some other donor phone. If this is indeed the case, SARK UCS/MVP will automatically log the user out of the old extension (and return the extension to its donor state) before logging in the new one. In this way, users can simply log-in wherever they are on the campus without worrying about having to log out from some other phone first.

How cool is that?

SARKHD requirements

• SARKHD is available ONLY for SARK-2.3 and higher. Zaptel systems (2.2) will not be supported.
• The SARKHD rpm is available from your SARK reseller or distributor.
• The donor phones MUST be under SARK provisioning control (their MAC addresses must have been identfied to SARK and SARK must be the DHCP 66 named TFTP server)
• The hot desk provisioning definitions MUST match the donor phone type (i.e the provisioning rules must match, although the phones may not have to be of the same model number, e.g. an Aastra 55 and an Aastra 57 is OK)
• The phone types MUST be remotely re-loadable/re-startable. So far we have tested all Snom variants, all Aastra variants. Other phones types such as Polycom, Linksys and Cisco will work but may have to be manually restarted after the log-in.

-- TWikiAdminUser - 22 Jul 2009