This section discusses the different types of PBX
integrations from the perspective of an end-user. Organizations can
deploy a mix of these scenarios to meet the needs of different users and
don’t have to pick just one path. For example, some users might be
completely using Enterprise Voice, but others want to retain a legacy
phone for use with audio conferencing.
Although users transition to Enterprise Voice, they
might configure call-forwarding settings to simultaneously ring their
legacy PBX phone. Certainly presenting more options to users makes
managing the solution more difficult, but might be necessary. What
scenarios are possible is dependent on the integration methods
referenced previously.
Enterprise Voice
In this scenario, end users have full Enterprise
Voice functionality and use only Lync Server endpoints as their phones.
This state provides the most features and flexibility to the end-users.
This is the state Enterprise Voice users are in for a new deployment
with no existing PBX or when a migration is completed.
Enterprise Voice with Legacy Phone
In
this scenario, end users have full Enterprise Voice functionality, but
also retain a legacy PBX phone on their desks. This scenario is typical
for migrations from a legacy PBX where a period of coexistence is
required while users become accustomed to the new Lync Server endpoints.
Users have the choice of which system to use when placing or receiving
calls through the use of simultaneous ringing. As they grow more
familiar with the Lync Server tools, they rely less on the legacy phone
until it becomes unnecessary and can be removed. As the migration ends
and legacy devices retired, the organization actually ends in the pure
Enterprise Voice state.
Most implementations require a user to have two
extensions during this period of coexistence. One extension is the
user’s primary, or publicly known extension, that other users dial and
is associated with the user’s account in Lync Server. The other is a
secondary, or unpublished extension, that is only associated with the
legacy phone.
When placing calls, users can choose whether to use
Lync or the legacy phone. When calling from Lync, the callees see the
call from the user’s primary, published number in the organization, but
calls coming from the legacy phone appear from the unpublished number. Figure 1 shows what could happen when users dial from either a Lync or PBX phone endpoint.
Tip
This issue can be mitigated slightly with PBXs that
support sending a display name, but the extension might still appear as
unrecognized to the callee. Again, as users begin to leverage the new
tools, this becomes less of an issue.
Receiving calls on both devices in this scenario is
accomplished through the users configuring simultaneous ringing within
Lync. Inbound calls are routed first to the Lync Server account that
determines what should happen to the call. Users generally set their
Lync call-forwarding options to simultaneously ring the secondary
extension associated with their legacy PBX phone. This enables them to
answer incoming calls either with a Lync endpoint or on the legacy phone
without the caller noticing where the call was picked up. As the
migration period goes on, users can adjust their simultaneous ringing to
stop ringing the legacy phone altogether. An example of how
simultaneous ringing happens is shown in Figure 2.
Caution
Depending on the current PBX, the simultaneous
ringing might not scale well. Consider when a media gateway device is
used to bridge a legacy PBX and Lync Server. If inbound calls still flow
through the PBX initially and then are directed through the media
gateway to Lync Server, each call requires one channel on the media
gateway. Although a user configures simultaneous ringing to a legacy
phone, another channel is required on the media gateway and PBX to
support the call.
Tip
Analyze
peak capacity of the PBX and media gateways when planning for
simultaneous ringing. As an example, a media gateway with two T1s
configured to a legacy PBX might support an initial integration with
Lync Server. Now when users have simultaneous ringing, it might be
necessary to use up to twice the number of channels so four T1s might be
required to support the coexistence.
Legacy Phone for Conferencing
Another option for organizations not looking to fully
implement Enterprise Voice features or replace existing handsets is to
leverage the conferencing features of Lync Server with their existing
investments. This enables an organization to migrate away from a legacy
or hosted conferencing system without changing the fundamental way users
function. As shown in Figure 3, users are not enabled for Enterprise Voice, but instead retain their PBX desk phone.
Users in this scenario have full access to the rich
conference scheduling controls within Outlook and Lync, but instead of
using a Lync endpoint to participate in audio conferences they can use
their legacy desk phone. This is accomplished through the use of the
Join audio conferences from setting within Lync. Users can elect to be
called at a number published within Active Directory or enter a number
manually. To join an audio conference through Lync, the user just
answers the desk phone. A screenshot of configuring this dial-out
ability is shown in Figure 4.
Legacy Phone Presence and Click-to-Call
A
more limited set of features can be deployed to users that gives
Click-to-Call functionality. This enables the end users to click a user
within their Lync contact list and have it dial the user’s number from
their legacy PBX phone. Additionally, presence messages are integrated
so that when a user places a call from the legacy phone, his or her
presence in Lync automatically updates to In a Call. This is the
scenario Remote Call Control provides to end-users.
Caution
This is one of the most basic integration options and
does not provide a significant amount of flexibility or features to the
end user. In this state, call-forwarding settings, delegation of calls,
and advanced call control features are not available. The Click-to-Call
features also do not work well for remote users because even if they
initiate a call, it places the call from a desk phone inside the office,
attached to the local PBX.
PBX Software Plugin
The final end-user scenario is where the PBX vendor
uses the Lync Server APIs to develop add-on software for the desktop to
integrate with Lync. Examples of this are Cisco’s UC Integration for
Lync (CUCI-Lync) and Avaya’s Application Enablement Server (AES)
products, which must be installed and managed separately from the Lync
client.
Caution
These solutions might seem appealing to some
organizations, but the plugins can introduce a layer of complexity in
troubleshooting voice issues. The plugins do not give the end user
Enterprise Voice functionality and are not much of an advantage over
remote call control feature set.
Voice calls and traffic are still done entirely
through the existing PBX and not through Lync Server. Instead of the
native call controls provided by Lync, users will see a UI developed by
the PBX vendor, which might confuse end users.
The main difference with these solutions over Remote
Call Control is that the presence and phone control features are
client-side as opposed to server-side. Instead of Lync Server
integrating with a PBX for presence updates and phone control, the
software plugin handles the call control and user presence updates,
which means that no CSTA gateway is required.
