There are a number of ways to integrate Lync Server
with an existing PBX to support a period of coexistence either while
evaluating Enterprise Voice or performing a complete migration to
Enterprise Voice. A new Greenfield deployment is rare to come across,
which is why many deployments require this coexistence situation for
some time. This section discusses the options available to organizations
looking to integrate Lync Server with their existing voice
infrastructure.
Direct SIP
The easiest and generally most cost-effective way of
integrating Lync Server with an existing PBX is if the PBX supports SIP
trunks. Many IP PBXs support this functionality, and many other hybrid
PBXs support SIP trunks with additional hardware and software upgrades.
In Direct SIP scenarios, the Mediation Server role
(which can now be collocated with a Front End Server) serves as the
conversion point between the two systems. The signaling on both sides of
the server is SIP, but the Mediation role translates the media stream
between G.711 on the PBX side and RTAudio on the Lync Server side. A
logical overview of a Direct SIP connection is displayed in Figure 1.
Direct SIP integration allows for a number of
different end-user scenarios.
What usually happens is specific extensions, or a range of extensions,
will configure to be “owned” by Lync Server instead of the PBX. These
extensions are configured on the old PBX to route across the SIP trunk
to let Lync Server handle the call. It is the PBX’s way of saying it is
not responsible for these numbers, but it knows where they can be
reached.
Media Gateways
If Direct SIP is not an option because the PBX does
not support the feature or has no IP PBX capabilities, a third-party
device called a media gateway can be
used to complete the integration. Media gateways act as an intermediary
between the PBX and Lync Server to help translate traditional PBX
protocols to SIP traffic, which Lync Server understands. Media gateways
are produced by many vendors today and provide a wide array of
integration options for businesses looking to implement the voice
features of Lync Server. They typically have traditional telephony
connections for T1/E1 systems on the PBX side along with network
adapters to communicate with Lync Server. This type of scenario is
depicted in Figure 2.
Also, as when configuring a Direct SIP trunk link,
configuration of the old PBX is necessary so that it knows to route
calls for specific extensions to the media gateway, which delivers the
calls to Lync Server.
Note
An additional layer of complexity is involved because
the media gateway must also be configured to route calls appropriately.
On the other hand, the media gateway provides a degree of flexibility
in call manipulation that sometimes is not possible natively with a PBX
or Lync Server.
Depending on the media gateway and business
requirements, it might be necessary to place the media gateway in front
of the old PBX. This can potentially have a bigger impact on the
organization, but can greatly simplify some of the routing
configuration.
Some gateway vendors have software that can detect
whether a user’s extension is Enterprise Voice or a legacy phone by
reading specific Active Directory attributes. This might
not seem like a big advantage up front, but as users are migrated to
Enterprise Voice it becomes advantageous not to have to constantly
change routing rules on the PBX to indicate where an extension exists.
This type of integration scenario is shown in Figure 3 where the media gateway becomes the link to the PSTN.
No matter where the media gateway is located, it can
provide a great deal of flexibility for organizations looking to move to
or test Lync Server Enterprise Voice.
Remote Call Control
Remote call control was the original form of PBX
integration introduced with Live Communications Server 2005 and allows
for users to control their legacy desk phone from Lync by clicking a
contact in their contact list to dial. It also allows for their presence
to be automatically updated to “In a call” when using the legacy phone.
Note
Support for new Remote Call Control implementations
was originally going to be dropped in Lync Server, but the product team
has adjusted its stance and will support new deployments. That said, it
is a legacy technology and unlikely to be supported in future releases.
Remote
call control does not give users the Enterprise Voice features for
controlling calls, assigning delegates, or configuring call-forwarding
settings. It also does not work remotely, so it can be used only inside
the network, which limits its usefulness for remote workers.
Computer Supported Telecommunications Applications Gateway
A Computer Supported Telecommunications Applications
(CSTA) Gateway was required to translate between older versions
Communications Server and the PBX presence information. This gateway
software usually involved an additional server component from the PBX
vendor and additional user licensing. Lync Server instead uses the Get
and Put verbs over SIP to control presence that can help to remove the
dependency on the CSTA gateway, but a CSTA gateway might still be
required depending on the PBX vendor. How the PBX and CSTA gateway
integrate with Lync Server is shown in Figure 4.
Dual Forking
Dual forking is mentioned here only for clarity, but
it is no longer a supported deployment option in Lync Server. The only
IP PBX ever qualified for dual forking with Communications Server 2007
R2 was the Nortel CS 1000. Dual forking allowed a user to have the same
extension in both the legacy PBX and Communications Server, and incoming
calls always rang both systems. Figure 5 walks through the basic steps that occurred with dual forking. Again, this feature is not available in Lync Server 2010.
Note
It is
still technically possible with some PBX vendors to maintain the same
extension in both systems, but this configuration is not supported by
Microsoft. It requires complex translation patterns and dialing tricks
in both systems, making it not a very scalable solution. It is generally
much simpler to use two different extensions in migration or
coexistence scenarios.
SIP Provider Trunking
The final integration method isn’t so much
integration with an existing PBX as it is a way to provide voice
services between the end users without one of the other methods. SIP
provider trunking involves using an ITSP (Internet Telephony Service
Provider) to deliver voice services across the Internet to a Lync Server
organization, similar to a service provider provisioning Internet
access. If integration with an existing PBX is not possible with any of
the other means, or if an organization wants to move away from the
legacy PBX services and provider, an ITSP can replace those services. Figure 6 shows how a Lync user could call a PBX user using SIP trunking and the PSTN.
In this situation, Enterprise Voice users can communicate with users still hosted on the PBX, but only by traversing the PSTN.
Caution
This is not an optimal call path for users who are
physically sitting next to each other on different systems, but does
provide a connectivity option if no others exist. In a migration
scenario, as fewer users remain on the legacy PBX, this becomes less of
an issue.
