Traditionally the most common and most popular way to create an
attendant console for a given platform was to use a standard like CTI or
SIP. The program would emulate a CTI route point, or SIP endpoint and
answer an incoming call much like a phone on the system. This approach
has several advantages. Almost every modern phone system today can talk
either SIP or CTI, so you immediately have compatibility on almost any
phone system. Since you are essentially becoming a phone or phone
server at this point, the features you develop would likely work
universally from system to system. To start the developer would develop
some sort of user interface that an operator/receptionist could
understand. From there it was up to the developer to create the basic
functions, answer, hang-up, hold, resume, transfer, etc. From here you
could expand your feature set to combine a myriad of SIP functions to
create things like call parking, some sort of queue, etc. This approach
does have a few drawbacks too. Since you are in possession of the
call, you have the ability to drop or lose it if your software
misbehaves and you don't have a proper fallback mechanism in the phone
system. You are also responsible for music on hold, and dealing with
whatever queue related functions you have created. In Microsoft Lync
you are left with another, rather large disadvantage to using this
approach. To say Lync is just a phone system is like comparing your car
to a chair. Yes you can sit in/on both with a similar result. It's
fairly obvious that your car has many features your chair does not.
Lync is no different, while it does the telephony end of a typical
phone system, it brings many more collaboration features with it, and on
almost any device you would be using.
As a developer Lync comes with 4 major SDKs at your disposal, giving
you complete control on the front end client and the back end server.
This is a HUGE difference compared to what developers typically see on
other UC platforms. So it begs the question,
"Does the traditional UC development model fit Lync?"
I believe the answer is no. Does a receptionist do the same job on a
Lync system as she would on a traditional pbx? The answer may largely
be yes, but would said operator not benefit from being able to
seamlessly use instant messaging, audio conferencing, call park (orbit),
native response group (queue) monitoring, recording, transfer to
voicemail, calendar visibility, and a whole host of other Lync specific
call control and look up functions? I whole heartedly believe the
answer to this question is YES, and that answer of yes fundamentally
requires a different approach be taken to the attendant console in
regards to Microsoft Lync.
SDK Links
http://msdn.microsoft.com/library/office/jj162980.aspx
Doug Routledge, C# Lync, SQL, Exchange, UC Developer
