Chapter 8: Enterprise Voice
[pic]
This document is provided “as-is”. Information and views expressed in this document, including URL and other Internet Web site references, may change without notice.
Some examples depicted herein are provided for illustration only and are fictitious. No real association or connection is intended or should be inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may copy and use this document for your internal, reference purposes.
Copyright © 2011 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, Lync, Windows, and Windows PowerShell are trademarks of the Microsoft group of companies. All other trademarks are property of their respective owners.
This chapter is part of the Microsoft Lync Server 2010 Resource Kit book that is currently being developed. Chapters will be available for download while this book is being completed. To help us improve it, we need your feedback. You can contact us at nexthop@. Please include the chapter name.
For information about the continuing release of chapters, check the DrRez blog at .
Contributors
Project Manager: Susan S. Bradley
Content Architect: Rui Maximo
Chapter Lead: Andreas Strebel
Writers: Mahendra Sekaran, Radu Constantinescu, Roy Kuntz
Technical Reviewers: Abdul Waraich, Ken Araujo, Ling (Lingzhi) Cao, Oscar Antezana Chavez, Robbie Bikdash, Subbu Chandrasekaran, Tony Bell, Vassili Kaplan
Lead Editor: Janet Lowen
Contributing Editors: Jim Bradley, Kelly Fuller Blue
Art Manager: Jim Bradley
Production Editor: Kelly Fuller Blue
Substantive Changes
|Change |Location |
|Additions made to Figure 15 based on reader feedback. |Page 28 |
| | |
|New call admission control (CAC) content. | |
| |Pages 9-11 and 19-25 |
Table of Contents
Contributors 4
Substantive Changes 5
What Is New in Enterprise Voice? 8
Scenarios for Enterprise Voice 8
Private Line 8
Call Admission Control 9
Call Park Application 11
Call Park and Retrieve 11
Ringback 12
Transfer to Fallback Destination 12
E9-1-1 12
Publishing Location to Contacts 12
Providing Location with Emergency Calls 15
Routing Enhancements 15
Support for Multiple Gateways per Mediation Server 15
Pre-Routing Number Translations 17
Caller ID Management 18
Analog Devices 18
Internals for Enterprise Voice 18
Private Line 18
Understanding Private Line Characteristics 19
Understanding Private Line Configuration 19
Understanding Private Line Routing 19
Call Admission Control 19
Bandwidth Policy Service Synchronization 22
Voice Applications Overview 25
Routing Requests to Voice Applications 26
Call Park Application 26
Understanding the Call Flow for Call Park 29
Understanding the Retrieve Call Flow 29
Understanding the Call Flow for Ringback and Transfer to a Fallback Destination 30
Orbit Management 31
E9-1-1 Locations 32
Enabling E9-1-1 39
E9-1-1 Routing 45
Routing Enhancements 48
Supporting Multiple Gateways per Mediation Server 50
Number Translations Prior to Routing 50
Caller ID Controls 51
Analog Devices Routing 52
Summary 54
Additional Resources 54
What Is New in Enterprise Voice?
Microsoft® Office Communications Server 2007 and Communications Server 2007 R2 introduced some of the core features needed to address Enterprise Voice requirements. Microsoft® Lync™ Server 2010 builds on those solid investments and introduces several features that are required by an enterprise to consider Lync Server 2010 as a viable replacement option for their telephony infrastructure. The following list highlights new voice features introduced in Lync Server:
• Call park and retrieve
• Call admission control
• Enhanced 9-1-1 (E9-1-1)
• Private line
• Routing enhancements
Scenarios for Enterprise Voice
For each feature listed in the previous section, the following sections describe one or several scenarios that illustrate the behavior of the feature. The scenarios provide the context for how a feature is often used. The “Internals for Enterprise Voice” section later in this chapter gets into the details about how the features work.
Private Line
The private line feature enables users to override delegation and other redirection features so they can be reached directly on a private line. For example, Marco is an executive at Contoso, Ltd. His IT administrator has configured the delegation feature on Marco’s phone line so all his incoming calls go to his assistant. Marco also has an additional “secret” number. This is the number Marco shares with Mike, an executive at Fabrikam Inc. Whenever Mike calls Marco’s private number, Marco’s delegation feature is overridden and he is able to see that the incoming call is on his private line (Figures 1 and 2). If Marco does not answer the call, the call is redirected to his unified voice mail box.
[pic]
Figure 1. Marco receiving a private call from Mike
[pic]
Figure 2. Marco in a private call with Mike
Call Admission Control
Lync Server supports highly adaptable audio (RTAudio) and video (RTVideo) codecs that adjust to meet fluctuating network conditions. To prevent degradation of audio and video call quality when the network link is oversubscribed, Lync Server introduced a new feature, the call admission control (CAC) service. CAC prevents users from establishing calls that might degrade the call quality of the network. CAC helps prevent unexpected call spikes from adversely affecting the entire network, line of business applications, and quality of current calls. CAC prevents call quality degradation by limiting the number of concurrent calls over limited bandwidth links, such as wide area networks (WAN).
When establishing a new call that will oversubscribe a WAN link, CAC re-routes the call through the public switched telephone network (PSTN) gateway or offloads the media portion of the call over the Internet. This approach offers greater flexibility for handling traffic spikes that can oversubscribe the network. When re-routing calls, CAC first attempts to redirect the audio through the Internet. If this fails, CAC attempts to re-route the call through the PSTN gateway. If PSTN gateway re-routing is not possible, the call is forwarded to voicemail. Calls sent to voicemail are not subject to bandwidth checks, because voicemail sessions are not subject to CAC.
For a description of how CAC works, see the article, “Call Admission Control in Lync Server 2010,” at . When a user attempts to join a conferencing session or begin application sharing, the Lync Server Audio/Video Conferencing service or Lync Server Application Sharing service, performs a bandwidth check before the media traffic connection is established. If there is sufficient bandwidth, the media traffic is allowed; otherwise, the Audio/Video Conferencing service blocks it. In the case of application sharing, traffic is always allowed and bandwidth checks always succeed.
Figure 3 shows the scenario where a PSTN gateway user joins a conference.
[pic]
Figure 3. CAC and Lync Server 2010 A/V Conferencing Server
Here’s what occurs:
1. The caller (PSTN gateway phone) initiates a request to join a conference. Call signaling traffic reaches the Lync Server 2010, Mediation Server.
2. The Mediation Server performs a bandwidth check by contacting the Lync Server 2010, Edge Server.
3. The Edge Server forwards the bandwidth request to the Bandwidth Policy Service, which performs the bandwidth check. The result of this check is sent back to the Mediation Server through the Edge Server.
4. If sufficient bandwidth is available, the call signaling traffic is directed to the Lync Server Conferencing Attendant.
5. The Conferencing Attendant checks for sufficient bandwidth by contacting the Edge Server.
6. The Edge Server forwards the request to the Bandwidth Policy Service, which performs the bandwidth check. The Bandwidth Policy Service then sends the results back to the Conferencing Attendant through the Edge Server.
7. The call is connected and joined to the conference.
8. The Audio/Video Conferencing service performs the final bandwidth check. It contacts the Bandwidth Policy Service through the Edge Server (segments 8 and 9).
TIP: Even if the connection (legs 1 and 4) between the PSTN gateway phone and the Lync Server Conferencing Attendant is successful, joining the conference can still fail if there is insufficient bandwidth between the Mediation Server and the Audio/Video Conferencing service (leg 7). The bandwidth used by the leg between the Mediation Server and the Conferencing Attendant (leg 4) is released after the PSTN gateway phone successfully connects to the Audio/Video Conferencing service.
TIP: If Lync Server, Audio/Video Conferencing Server is deployed as a standalone server, bandwidth reservations can be made by a Lync Server Conferencing Announcement service, located in a different network site. For every PSTN gateway user joining the conference, there will be at least one connection made to the Audio/Video Conferencing Server by the Lync Server Conferencing Announcement service, which might require a bandwidth reservation.
Call Park Application
Call park and retrieve is a common feature available in most private branch exchange (PBX) systems. The Call Park application in Lync Server provides call park functionality. Typical park and retrieve deployment scenarios are warehouses, hospitals, or factory floors.
Call Park and Retrieve
In the following example, a receptionist answers an incoming call from Michele intended for Bob. The receptionist parks the call by selecting the park action from their client or device. After the call is parked successfully, the orbit for the parked call is displayed as shown in Figure 4.
[pic]
Figure 4. Call parked on orbit 138
The caller being parked is transferred to the Call Park application and optionally listens to music while on hold until the call is either retrieved or the Call Park application ends the call.
The receptionist uses an overhead paging system, for example, to page Bob, and then communicates the orbit that the call is parked on. Bob walks to the nearest phone and retrieves the call by dialing the orbit. An orbit identifies the parked call on the Call Park application and usually consists of a sequence of digits similar to a phone extension (for example, 12345). The Call Park application looks up the orbit to retrieve the parked call, and transfers the call to the retriever, Bob.
Safe-retrieve is an alternative method for retrieving a call. Because orbits are reused over time, safe-retrieval prevents retrieving the wrong call. The wrong call can be retrieved when an old retrieve button is clicked after the corresponding call has already been retrieved. A safe-retrieval fails if a user attempts to retrieve a call that was previously parked at the same orbit, which now holds a new call.
Ringback
The Call Park application offers a ringback feature. If the parked call is not retrieved before a configurable timeout expires, the Call Park application transfers the call back to the person who parked the call. In our earlier example with Bob, the call would ring back to the receptionist. Because this is a safe transfer, the call will not be routed to voice mail or be forwarded. The ringback can be declined or timed out. Both cases are considered ringback failures. You can configure the Call Park application for one or multiple ringback attempts.
Transfer to Fallback Destination
The Call Park application provides the ability to transfer a call to a fallback destination. If a parked call is not retrieved and one or several ringback attempts fail, Call Park application transfers the call to the fallback destination. Because a fallback is a normal transfer, the forwarding rules of the destination apply. The fallback destination is a URI that is configured in the Call Park application. Typical destinations are operators, team leads, or a response group. The same fallback destination is used for all parked calls when ringback is unsuccessful. If the transfer to the fallback destination fails, the Call Park application disconnects the parked call to release the orbit and associated resources.
E9-1-1
Lync Server clients—Microsoft® Lync™ 2010, Lync 2010 Attendee, and Lync Web App—are designed to automatically acquire a location from the Location Information Server (LIS). This is not a configurable setting. Immediately after the Lync Server client registration process or when the operating system detects a network connection change, each Lync Server client will submit a request for a location to the LIS. If the LIS is able to resolve a location address for the client request, it returns the address in a location response. Each client then caches this information. Location information is used for two main purposes:
• Publishing location to contacts
• Providing location to emergency calls
Publishing Location to Contacts
Location information can be published to contacts who are in the user’s favorite category. The location presented to the user is a combination of the location and city fields for a location. For example, Figure 5 shows the whole location that is received by the client. Figure 6 shows the summarized view that appears in the Lync 2010 user interface and in the user’s presence information. Figure 7 shows the subscriber’s view.
[pic]
Figure 5. Lync 2010 Edit Location dialog box
[pic]
Figure 6. Summarized location information in the Lync 2010 user interface
[pic]
Figure 7. Subscriber's view of location information in a user’s presence information
Providing Location with Emergency Calls
When a client is enabled for E9-1-1, the location that is cached on the client is sent during an emergency call. An indication that it is an emergency call is also provided as shown in Figure 8.
[pic]
Figure 8. Emergency call with the same location
Routing Enhancements
Lync Server introduces several enhancements that enrich the routing capabilities. The following sections describe the features and the scenarios that are enabled with improved routing.
Support for Multiple Gateways per Mediation Server
Office Communications Server 2007 R2 supports only one gateway instance per Mediation Server. Given that gateways are available in different port densities and because the scale characteristics of a gateway are different from a Mediation Server, Lync Server now has the capability to have a Mediation Server connect to multiple gateways. Some core scenarios that are improved by this capability are as follows:
• More flexible routing, for example, least cost routing, is now possible. The issue of Mediation Server scaling characteristics differing from gateway scaling characteristics has also been addressed. For example, a Mediation Server may be able to handle 300 concurrent calls, and the same Mediation Server can be used to connect to multiple 16-port gateways. In Figure 9, gateways Gateway 1 and Gateway 2 are connected to Mediation Server Mediation Server 1, and Gateway 3 is connected to Mediation Server 2. For a particular destination number, it is possible to route to Gateway 2 via Mediation Server 1 or to Gateway 1 via Mediation Server 1 or to Gateway 3 via Mediation Server 2.
[pic]
Figure 9. More flexible routing scenarios possible in Lync Server
• Figure 10 illustrates a failover routing scenario. Gateways 1 and 2 are connected to Mediation Server 1. Based on the routing configuration, it is possible to do failover to Gateway 1 (via Mediation Server 1) if Gateway 2 returns a failure response (for example, connectivity issues between Gateway 2 and PSTN gateway Provider 1).
[pic]
Figure 10. Failover routing
• The Mediation Server sends periodic SIP Options requests to a gateway. If the request fails five times, the Mediation Server detects that the gateway is down. This results in the Mediation Server reporting a Key Health Indicator (KHI). Until an Options request is successful, a call cannot be routed through this particular gateway.
• Multiple gateways enables better load balancing. Gateways 1 and 2 are connected to Mediation Server 1, and both are configured as valid routes for +14255550100. Calls to this destination number are distributed uniformly between Gateway 1 and Gateway 2. In the direction from Lync to the Mediation Server, the outbound routing logic is responsible for distributing the calls to multiple gateways. Basically, equal weight is given to all gateways in a route.
Pre-Routing Number Translations
When a user dials a phone number, the dialed number is normalized to RFC 3966 (E.164) format to facilitate the lookup of the user. However, if the call is routed to the PSTN gateway, for example, through a gateway or PBX, another set of translations may be performed to ensure that the dialed number adheres to the local dialing rules. This translation capability is available in Lync Server and addresses the difficulties usually associated with configuring these translations rules in gateways. The translation rules are set per trunk and can either have policy at the global, site, or service/gateway level. The following scenarios illustrate these capabilities:
• Bob dials +14255550100 (or a number that normalizes to this number). The call is configured to route to a gateway in Redmond. The matching translation rule removes the prefix “+1” from the number to conform with the local PSTN gateway dialing rules required by the gateway. The dialed number is translated to 4255550100 prior to sending the call to the gateway.
• Bob dials +914412345678, and the call is configured to route through a gateway in Redmond as a primary route. In this case, the number matches the translation rule for international calls and is translated to 011914412345678 prior to sending the call to the gateway. The ‘+’ is replaced with the international dialing prefix, 011.
• Bob dials +914412345678 again. This time the primary gateway returns an error, and Lync Server sends the call to the secondary route through a gateway in Madras. The Madras gateway has different translation rules and the number is changed to 12345678 prior to the call being routed. The ‘+’, country code (91) and city code (44) are stripped because the call is egressing from a local gateway to the destination.
Caller ID Management
Lync Server enables you to alter the Caller ID for certain groups of users when they make calls to the PSTN gateway. You can change the Caller ID based on the user and on whom the user is calling. The following scenario illustrates this feature.
Alice is in the finance department and her Direct Inward Dialing (DID) number is +14255550112. When Alice calls an internal enterprise user, the person receiving the call sees that Alice is calling. Later, Alice places a call to an external PSTN gateway number. Because the company policy is to display the main line number for outbound calls from the finance department, the administrator configured Caller ID for all finance department employees to display the company’s main line number (+14255550100) for outbound calls. Alice’s Caller ID is presented as +14255550100 in this case.
Analog Devices
Because enterprises need to continue to support analog devices for a variety of scenarios (for example, elevator phones, door openers, and security hotlines), Lync Server gives IT administrators the ability to manage these devices more effectively. The physical connectivity to these devices are through analog ports or analog telephone adapters (ATAs) on the partner gateways. However Lync Server can now manage these devices in its infrastructure.
Internals for Enterprise Voice
After describing various new Enterprise Voice scenarios, this section focuses on how those features work. Call flows, sample SIP messages, and configuration examples illustrate the internals.
Private Line
You can configure each user to have an additional private phone line. The following sections describe the private line feature in terms of its characteristics, configuration, and impact on call routing.
Understanding Private Line Characteristics
The following are some of the characteristics of a private line:
• A user can have only one private telephone line in addition to their regular phone line.
• A user that has a private telephone line has only one voice mailbox and receives missed call notifications at a single e-mail address.
• A user that has a private telephone line does not have a second SIP address, and a private telephone line does not give a user a second presence on the network (such as a second instant messaging identity).
• Private telephone lines are inbound only and cannot be used to make outgoing calls. When a user that has a private telephone line makes a call, the call originates from the user’s primary telephone line and does not hide the user’s name or the user’s primary telephone number from the person called.
Understanding Private Line Configuration
To preserve the privacy of private lines, they do not appear in telephone directories or contacts lists derived from Active Directory® Domain Services.
Accounts for new users who need private telephone lines are created in the same manner as accounts without private telephone lines, using Lync Server Control Panel or Lync Server Management Shell.
Use the Set-CsUser cmdlet in the Lync Server Management Shell to assign a telephone number to a private telephone line for a user, for example.
Set-CsUser -Identity “sip:joe@” -PrivateLine “Tel:+14255550146”
Telephone numbers for private telephone lines can be between 3 and 15 numbers in length and must be preceded with the "TEL:" prefix. They can have any area code and any country code as long as your organization has direct inward dialing for that number. The private line is stored as an additional user property in the Central Management store.
After the private line is configured, the administrator communicates this number out of band to the user (for example, sends the user an e-mail message).
Understanding Private Line Routing
After a user is configured to have a private line, the association between the user and the private line along with the primary phone number is created and maintained in the database. When Lync Server routes a private line number, Lync Server looks up the corresponding user’s SIP URI, and then directs the call to the user’s registered endpoints. As part of this call flow, Lync Server tags the call as a private line and adds a History-Info header to ensure that the endpoints can reflect that in the UI. For example, when Mike calls Marco on his private line, the following header is added to the INVITE sent to Marco.
History-Info: ;index=1;ms-line-type=private.
Call Admission Control
The Lync 2010 client endpoint that receives a call is the entity responsible for initiating the bandwidth check. Figure 11 illustrates the message workflow when a Lync 2010 client in site 1 calls a Lync 2010 client in Site 2. The solid lines represent SIP traffic. The dashed lines represent the bandwidth management traffic.
[pic]
Figure 11. CAC message workflow
Bandwidth management traffic is an extension of the [MS-TURN] protocol called [MS-TURNBWM]. For details on this protocol see: “[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions” at (office.12).aspx. When a client receives a call, it contacts the Bandwidth Policy Service or the bandwidth management traffic is proxied to the Bandwidth Policy Service by Lync Server Audio/Video Edge service.
Figure 12 illustrates the message sequence when a call is established. When Client 2 receives the call, it queries for available bandwidth by sending an allocate request to the Bandwidth Policy Service. This request specifies the bandwidth range requested (a minimum and a maximum), the IP addresses of the caller and callee, and the media type requested (for example audio, video, or data).
TIP: In the current version of Lync Server, only audio and video traffic are subject to CAC. Data traffic is always allowed without restrictions.
The Bandwidth Policy Service replies with the amount of bandwidth available and the IP addresses the client endpoints should use for connecting the call (message 3).
After completing connectivity checks, the call receiving endpoint sends a message to the Bandwidth Policy Service to commit the bandwidth. The message contains the IP addresses, used to exchange media, and the required bandwidth range (message 6).
[pic]
Figure 12. Message sequence to connect a call
The response includes the amount of bandwidth reserved and a bandwidth reservation identifier. This identifier is used in subsequent communications with the Bandwidth Policy Service (message 7).
The bandwidth reservation is renewed through periodic updates or else it expires (message 9). Lync clients send keep-alives every 19 seconds. If no keep-alives are sent, the bandwidth reservation is released after a maximum time of three minutes.
When a call is made in a deployment that includes an Edge Server, the recipient endpoint contacts the Edge Server to reserve media ports on its public interface. These media ports are included in the response to the call initiator’s SIP INVITE (message 1.) These media ports are used when the only available media path between the clients is through the Edge Server.
When the CAC solution is enabled, the recipient endpoint checks for available bandwidth with the Bandwidth Policy Service through the Edge Server. The request includes the bandwidth reservation amount needed for the call. When the Edge Server receives the request, it performs two tasks:
1. Allocates a media port for the call.
2. Verifies available bandwidth with the Bandwidth Policy Service.
The Bandwidth Policy Service replies back to the Edge Server with the amount of bandwidth available for each of the possible segments between the recipient endpoints. These segments are:
• Call initiator (( call recipient direct connection.
• Call initiator (( call initiator’s Edge Server.
• Call recipient (( call recipient’s Edge Server.
When bandwidth for a segment is unavailable, the segment is marked as invalid. The results of the bandwidth check, along with the allocated media port, are returned to the recipient endpoint (message 4). If all segments are invalid, the call fails, and the call is rerouted to the PSTN gateway. If rerouting to the PSTN gateway fails, the call is forwarded to voicemail. If any call segment is valid, the call goes through. The answer sent by the call receiving endpoint to the call initiating endpoint only contains media ports that belong to the valid segments. In other words, the recipient endpoint filters out the media paths that cannot be used due to the bandwidth restrictions.
When the call initiating endpoint receives a SIP response, it initiates connectivity checks with the recipient endpoint. When the checks are completed, it selects a media path for the call. When the path is known, the recipient endpoint sends a commit message to the Edge Server to commit the bandwidth needed for the call. The Edge Server forwards this information to Bandwidth Policy Service. The Bandwidth Policy Service updates its internal database by charging the corresponding WAN links with the amount of committed bandwidth.
TIP: There is a delta, usually in the range of milliseconds, between the time when the bandwidth check is initiated and when the bandwidth commit takes place. During this interval, the needed bandwidth can become unavailable. This occurs when new calls that were placed in parallel, secure the bandwidth first. However, the Bandwidth Policy Service does not re-check for available bandwidth once it receives the commit. The Bandwidth Policy Service charges the links, which may result in over-committing.
Bandwidth needs can change during a call. To adjust to changes, the recipient endpoint sends a bandwidth update message to the Edge Server. The Edge Server forwards the message to the Bandwidth Policy Service, which updates its internal database. The Bandwidth Policy Service responds with a confirmation back to the Edge Server. This response is forwarded to the recipient endpoint. If the request is for additional bandwidth, and additional bandwidth is unavailable, the request is rejected and the client receives an error response. For more information, see “[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions” at (office.12).aspx.
Bandwidth Policy Service Synchronization
When the Bandwidth Policy Service starts, it scans the Lync topology definition stored in the Central Management store to identify all Edge Servers in the Lync deployment. The Bandwidth Policy Service then attempts to connect to every Edge Server. This establishes permanent CAC channels between the Edge Servers and the Bandwidth Policy Service. This ensures that CAC-related traffic sent to an Edge Server can be forwarded to the Bandwidth Policy Service. To establish these connections, the Bandwidth Policy Service obtains a media token from the Media Relay Authentication Service of each Edge Server. Using the media token issued by Media Relay Authentication Service, the Bandwidth Policy Service establishes a CAC channel with each corresponding Edge Server. For more information about how a media token is obtained, see “[MS-AVEDGEA]: Audio Video Edge Authentication Protocol Specification” at (office.12).aspx.
Each Bandwidth Policy Service maintains a database record of the state of every network link in the network topology. Because the Bandwidth Policy Service runs on all Lync Server 2010, Front End Servers within a pool, all Bandwidth Policy Services are interconnected within a pool. These intra-pool connections synchronize data in real-time. In addition to synchronizing with each Bandwidth Policy Service running on every Front End Server in the same pool, each Bandwidth Policy Service synchronizes with a Bandwidth Policy Service running on a randomly selected Front End Server from every remote pool. This inter-pool connection synchronizes data at 30 seconds intervals. This mesh connection is illustrated in Figure 13.
[pic]
Figure 13. Bandwidth Policy Service CAC channel mesh
When Bandwidth Policy Services connect to each other, they establish a CAC channel. This CAC channel is used for receiving status updates from the remote Bandwidth Policy Service by periodically broadcasting its internal database status. In order to establish a CAC channel, a media token is required. This token allows the Bandwidth Policy Service initiating the connection to be authenticated. The Bandwidth Policy Service obtains this media token from the Bandwidth Policy Service (Authentication) similar to the Media Relay Authentication Service that runs on the Edge Server. The Bandwidth Policy Service (Authentication), as with the Bandwidth Policy Service, runs on the Front End Server.
TIP: It is possible that Bandwidth Policy Services may be out of sync between status synchronization cycles. When this occurs, a bandwidth check can succeed when it should fail. This means that a server may be unaware of bandwidth reservations made by a peer server. As a result, network links can be over-committed. Over-committing results in too much traffic on the network links, which leads to network congestion. Network congestion has a negative impact on call quality. See “Planning for Voice” at for guidance on defining the capacity of a network link.
When a client endpoint sends a request for a bandwidth check to an Edge Server, the Edge Server uses a round-robin process to select from the list of Bandwidth Policy Services. First, the Edge Server looks for Bandwidth Policy Services within the same central site to process the request. If no Bandwidth Policy Services are available within the same central site, the Edge Server picks a Bandwidth Policy Service associated with a different central site.
TIP: In every Lync Server central site, there is only one pool with an active Bandwidth Policy Service. Edge Server will always prefer a Bandwidth Policy Service from the pool that belongs to the same central site.
After a Bandwidth Policy Service is selected, all subsequent bandwidth policy traffic for that session is directed to the same Bandwidth Policy Service.
When calls are placed over WAN links, owned by different Bandwidth Policy Service pools, it is possible for a Bandwidth Policy Service to receive a bandwidth commit or update message about a WAN link owned by a peer pool. When this occurs, the Bandwidth Policy Service utilizes the CAC channel used for inter-pool status updates to forward the commit and update messages, in real time, to the right owner. As a result, the owning Bandwidth Policy Service database is always up-to-date. Figure 14 illustrates the full connection mesh established between Bandwidth Policy Services in the deployment.
[pic]
Figure 14. CAC Bandwidth Policy Services connection mesh
Voice Applications Overview
Lync Server 2010 ships with several voice applications that run under the Unified Communications Application Services (UCAS) server role. Some of these include Response Group application, Dial-in Conferencing, Call Park application, and Audio Test service.
Key properties of a voice application are:
• Each application is a separate Windows® service.
• Each application is identified by (at least) one Contact Object in Active Directory Domain Services for routing purpose.
• Each application has a common hosting framework. The purpose of the hosting framework is to provide and manage shared resources such as IP ports and common tasks like starting or stopping the voice application and preventing new client connections.
• Each application has the same logging infrastructure as other Lync Server components.
• Each application is built on top of UCMA. UCMA enables any independent software vendor to build additional voice applications, which can benefit from these properties just as voice applications that are shipped with Lync Server 2010 do.
• Each voice application terminates media. Based on the features offered by the application, audio flows in both directions (incoming and outgoing). For example, Dial-in Conferencing plays prompts to the callers and records their names.
Routing Requests to Voice Applications
The mechanism that routes SIP INVITE requests establishes new SIP dialogs for voice applications is very similar to routing requests to users. For an incoming request, Lync Server 2010 does the following:
1. Attempts to find the application Contact object (in Active Directory Domain Services). The Contact object identifies the destination pool and voice application where it is hosted.
For standard voice applications the phone number is used as the key to find the application’s Contact object (see Example 1 following this list. Certain applications require additional translation on the Lync Server to identify the application Contact object and the pool that handles the particular request (see Example 2 following this list.
2. Sends the request to the corresponding pool that is identified by the application’s Globally Routable User Agent URI (GRUU). The GRUU is an attribute of the application’s Contact object.
3. Selects a specific server from the pool by using the load-balancing logic.
Example 1: The response group for the Human Resources Team has the phone number (425) 555-0150. When the administrator creates the response group, a Contact object is created automatically in Active Directory Domain Services to represent this response group. This Contact object’s attributes are configured to have a SIP URI (hrteam@), a phone number (+14255550150), and other properties that are specific to the response group. The application ID is set to ‘urn:application:Rgs’.
For incoming requests to (425) 555-0150 or hrteam@, Lync Server 2010 finds the corresponding application’s Contact object, and then routes the request to the destination pool that hosts the Response Group application.
Example 2: The administrator configured the Call Park application and assigned an orbit range from 1100 to 1199 to the Redmond-1 pool that hosts the Call Park application. This information is stored in the “orbit range/CPS pool” table and is later used to look up the Call Park application for an orbit that is in a retrieve request.
A call was parked on orbit 1122, and the intended person attempts to retrieve it. The incoming request to retrieve a parked call contains the orbit 1122. Lync Server 2010 first looks up the pool for the matching orbit range in the “orbit range/CPS pool” table. In our example, the orbit 1122 is part of the 1100-1199 range and Lync Server 2010 sends the retrieve request to the Call Park application on the Redmond-1 pool by using the corresponding GRUU.
Call Park Application
In the following sections four different users are distinguished:
• Alice: The user who attempts to park the call (with Bob)
• Bob: The user who is being parked
• Ted: The user retrieving the parked call
• Fallback destination: The user who manages all calls that have not been retrieved. You can configure a different fallback destination on each Call Park application pool (for example, Carol the receptionist).
The call flow in Figure 15 illustrates the park, retrieve, and unpark notification actions. For sample messages, see .
[pic]
Figure 15. Park/retrieve call flow
Understanding the Call Flow for Call Park
The Call Park feature is based on the ms-call-park protocol extension. For details about this extension, see . The park request and associated responses and notification messages are carried in a dedicated SIP dialog between Alice and the Call Park application:
1. Park request: The park request is initiated by Alice sending a SIP INVITE message (INVITE - 2) to the Call Park application.
2. The SIP dialog ID of the call between Alice and Bob and the address-of-record for Bob are included in the XML body.
4. Park success response: After the call is successfully parked, the Call Park application sends back a 200 OK message to Alice.
Call Park sends back the orbit and the SIP dialog ID of the parked call in the XML body.
5. Unpark notification: After the call was successfully retrieved, the Call Park application sends a SIP INFO message to Alice.
After the parked call is dispatched, Call Park sends an INFO message in the existing SIP dialog with Alice. The XML body contains the reason (retrieval, hang-up, ringback, fallback, or drop) and in the case of retrieval or fallback, the destination address-of-record for the person who answered the parked call.
The Session Description Protocol (SDP) payload is XML-based, and the content type for all messages, including ms-call-park XML bodies, is Application/ms-call-park+xml.
Note. No unpark notification will be sent by the Call Park application if Alice closes the SIP dialog with Call Park before the call was released from Call Park (for example, the Conversation window with the parked call is closed).
If the park operation fails, no XML body is added to the error response. In most cases, an ms-diagnostic header is included in the error response that indicates why the action failed (for example, 35007: Park request failed. Cannot establish a connection between the Call Park application and the parkee or 35002: no free orbits available).
Understanding the Retrieve Call Flow
The parked call is retrieved by dialing the orbit. Ted, the call retriever, sends a regular audio INVITE request (INVITE – 4) that is addressed to the orbit. This request is routed to the Call Park application (for routing details, see Example 2 in the section “Routing Requests to Voice Applications” earlier in this chapter. The following is an example INVITE request.
INVITE sip:1561;phone-context=defaultprofile@;user=phone SIP/2.0
From: ;tag=7c4136f3b6;epid=c9a8219cde
To:
CALL-ID: a19e7ff9ec9243bb9416276afe7bc707
From a call flow perspective, the retrieve operation is very similar to supervised transfer. After accepting the INVITE request, the Call Park application determines whether a call is parked for the given orbit. If a parked call exists for the given orbit, Call Park connects Ted with Bob by sending a standard REFER request with Replaces encoded in the Refer-To header to Ted as shown in the following example. The Replaces parameter identifies the SIP dialog between Bob and the Call Park application.
REFER sip:172.24.32.147:53243;transport=tls;ms-opaque=9ef8a0c1a7;ms-received-cid=93AD00;grid SIP/2.0
From: ;epid=9FC09D8ABF;tag=3840f02e1
To: ;epid=c9a8219cde;tag=7c4136f3b6
CALL-ID: a19e7ff9ec9243bb9416276afe7bc707
REFER-TO:
REFERRED-BY:
This triggers Ted’s user agent to send an INVITE message (INVITE – 5) that has a Replaces header to Bob. Bob’s user agent automatically accepts the call request. This is similar to a call transfer. This completes the retrieve action, and Call Park application notifies Alice if the corresponding SIP dialog between Alice and Call Park created earlier in Figure 15 still exists.
If the retrieve operation fails, the call stays parked unless Bob ends the call. If no call is parked under the given orbit, the Call Park application responds with a 404 error message and includes an ms-diagnostic header that has a value of 35000.
A variation of retrieve is safe retrieval: The INVITE request from Ted includes the additional header ms-parked-call with the SIP dialog ID of the parked call. CPS compares the value of the ms-parked-call header with the one associated with the orbit in the database. Only if they match CPS will proceed with the retrieve operation. Otherwise CPS rejects the retrieve with a 404 error response, and includes the ms-diagnostic header with a value 35010.
Understanding the Call Flow for Ringback and Transfer to a Fallback Destination
Parked calls might not always be retrieved. For example, an employee leaves the office for an unplanned errand, and the receptionist isn’t aware of it. In this case, the Call Park application attempts to transfer the call to somebody else. First, to the person who parked the call (ringback action). Second, to a fallback destination if one has been configured. The call flows for ringback and for transfer to a fallback destination are the same and are based on the blind transfer call flow. The only differences between the ringback action and the transfer to a fallback destination action are the transfer target and the type of transfer. For a ringback, the call is a safe transfer to Alice (the user who parked the call). For a transfer to a fallback destination, the preconfigured destination applies to all parked calls and is a regular transfer (for example, Carol the receptionist).
When the park timeout expires, the Call Park application sends a REFER to Bob with a Refer-To header that is set to Alice’s address-of-record. For transfer to a fallback destination, the Refer-To header contains the address-of-record of the configured fallback destination.
If the ringback operation fails, the call stays parked. For transfer to a fallback destination failures, the call is eventually disconnected. Figure 16 illustrates this flow.
[pic]
Figure 16. Call flow for a ringback or transfer to a fallback destination
Orbit Management
Orbits are globally unique in a Lync Server topology. Retrieving a parked call is transparent for the user from any location because orbits can be dialed from anywhere inside the company. To enable users to retrieve calls from PBX phones, you might have to configure the PBX or gateway to route the orbit ranges to Lync Server 2010. After the request reaches Lync Server 2010, the logic described in Example 2 in the section “Routing Requests to Voice Applications” earlier in this chapter applies.
For a transparent and efficient integration of orbits into the enterprise dial plans, follow the following guidelines:
• Review normalization rules: Orbits must not be normalized. Check existing normalization rules and either update existing rules or create rules to exclude the orbit ranges. Dial plans from any site can be impacted. For example, if the Call Park application is deployed in site-1 and calls also need to be retrieved from site-2, you must ensure that the normalization rules from site-1 and site-2 dial plans do not modify the orbit.
If an orbit is normalized, Lync Server is unable to route it to the Call Park application and the retrieve request fails.
• Retrieve parked calls from PBX phones: To limit reconfiguring the PBX system, the orbit length must align with the phone extension length. If an extension range that is assigned to Lync Server contains a free block of numbers, this block of numbers can be used for orbits to avoid changing the routing from PBX to Lync Server. For example, the range 4000 to 4999 is routed from the PBX to Lync Server but only 4000 through 4899 are used for phone extensions. In this case, an orbit range from 4900 to 4999 can be used as orbits.
• Orbit ranges are globally unique: Conflicts might be mitigated by using the orbit prefix * or #.
• Size of orbit ranges: Keep orbit ranges small and easy to remember for employees who need to retrieve calls. However, orbit ranges should not be too small to avoid a park request being rejected because no free orbit is available.
Note. Make sure orbit ranges do not overlap with extension blocks from the Announcement application. If these numbers overlap, users might not be able to retrieve calls.
E9-1-1 Locations
When implementing E9-1-1, the administrator needs to consider the architecture of the Location Information Server (LIS), administration of the location database, validation of civic addresses, managing location policies, and how to resolve the user’s location when they run multiple clients with multiple points of presence. The following sections provide detailed information about how locations work in E9-1-1 in Lync Server.
Location Information Server Architecture
The LIS is a service that is part of the Lync Server Web Services components in a pool. It is a web service that contains the locations that have been published from the central location database. The location database is part of the Central Management store and is global in scope because each LIS has a full copy of all locations. The LIS enables clients to automatically have location information populated. The LIS receives location requests from clients, matches a location based on the contents of the location request, and then renders the location to the requesting client.
The publishing of locations to each LIS is required whenever location management occurs, for example, adding, deleting, or editing information. This is a manual step that is accomplished by using the Windows PowerShell® command-line interface cmdlet publish-cslisconfiguration. This step is manual because it is expected that the location database will be relatively static.
Windows PowerShell export and import commands for the LIS provide global backup and restore capability of the location information.
Administration Guidance
Management of the location database such as adding the network identifiers and their locations is available only by using Windows PowerShell. However, the ability to create location records by importing them from CSV files is available to streamline initial configuration.
Also of note is that there are no “new” Windows PowerShell verbs for doing location management. You must create any new component, such as a location or network identifier, by using the “set” verbs instead. This is because any location and network identifier are unique; therefore, if any component of either is modified by using a set command, a new record will actually be created rather than the existing one modified. As a result, using “new” verbs would be redundant.
The location database contains two types of data:
• Location: The civic address, which can include contextual in-building and company identification information.
• Network identifiers: An element of the data network that can be used as a reference point when identifying the location of a unified communications (UC) client.
Both of these elements can be defined separately in the LIS. The association of a location with a network identifier is what creates a LIS location record. This is an important concept to remember when managing the location records because the association of network identifier to location provides the location of the user’s client or clients. Also, each data set can be managed separately. For example, the same location record can be associated with many different network identifiers. Therefore, changing the location record updates this information for every network identifier.
There are two general methods for managing location data:
• Manage location data offline in CSV files, and then periodically import it into the location database.
• Manage the location information by using Windows PowerShell.
Managing the records offline with CSV files and then periodically importing the CSV files can be an easy and less error prone method of location management. Because it is likely that records are initially created by using this method, you can keep them up to date by editing them using your preferred editor (for example, Excel, Vim, Emacs, or notepad). However, there are the following drawbacks to this method:
• If some of the network elements, such as a wireless access point, are re-deployed and given a new location, the old location records must be deleted or there will be “stale” (outdated) locations in the LIS.
• If all location records are deleted prior to importing new records, the addresses will have to be revalidated.
Editing location records by using Windows PowerShell has the drawback of requiring that administrators have more advanced Windows PowerShell skills.
A best practice is a hybrid method where CSV files are used for creating new records but Windows PowerShell is used to manage records thereafter. For example, after subnet and location data is in a CSV file, you can import it into the location database by using the following Windows PowerShell commands.
import-csv 'Y:\E911 Data\Subnets.csv'| Set-CsLisSubnet
After the subnet and location data is loaded into the location database, it can be manipulated using Windows PowerShell. For example, consider a case where the StreetName attribute is incorrect and needs to be changed from 132 to 131. You can use the following Windows PowerShell cmdlet to do this easily.
Get-CsLisSubnet | where {$_.streetname -like "*132*"} | Set-CsLisSubnet –streetname “131”
The previous cmdlet does not actually remove the location records that have 132 in the streetname attribute. It creates a new location record that has the StreetName attribute set to 131 while the remaining values stay the same. The location records that have StreetName equal to 132 will remain in the database. This is because the location records associated with the subnet that matches the 132 parameter are being changed to the new updated location and not the location itself.
To modify the location record directly rather than create a new one, change the Windows PowerShell cmdlet, set-CsListSubnet, to set-CsListLocation as shown in the following example.
Get-CsLisLocation | where {$_.streetname -like "*132*"} | Set-CsLisLocation –streetname “131”
Automatically Acquiring a Location
UC clients can acquire a location automatically or manually without being enabled for E9-1-1. The requirement for automatic location is to populate the LIS. When a client completes its registration process during sign-in, it acquires the URL of the LIS from its pool by using in-band provisioning. The client then automatically submits a location request to the LIS. The location request is a web service request in which the UC client inserts its network connectivity information. If a client is installed on a computer configured with multiple network interfaces, it always selects the network interface used to register the user with Lync Server.
The following network identifiers will always be present in a location request:
• IPv4 subnet
• Media Access Control (MAC)
The following network identifiers can be included in a location request based on network connectivity and configuration:
• Wireless access point (WAP) Basic Service Set Identifier (BSSID)
• Link Layer Discovery Protocol-Media Endpoint Discovery (LLDP-MED) chassis ID and port ID
The following is an example of a location request that includes a MAC and subnet.
sip:voip_911_ @
0
12-22-22-22-22-22
192.168.0.0
192.168.0.244
The received signal strength indication (RSSI) and IP network identifiers are not currently used. The client will initiate a Location Request under the following circumstances:
• Immediately after startup and registering the user with Lync Server
• Approximately every 4 hours after initial registration
• Whenever a network connection change is detected (like roaming to a new WAP)
When the LIS receives the request, it parses the network information that is contained in the request and proceeds with checking the network identifiers stored for a match. The matching order is as follows:
• WAP BSSID
• LLDP switch/port
• LLDP switch
• Subnet
• MAC
The logic is meant to ensure that for any client that is connected by a wireless connection, a match is first attempted based on the hardware address of its connected access point. The logic is for the match to be based on the most detailed location. The subnet generally provides the least detail. If no match is found in the LIS for WAP BSSID, LLDP switch/port, LLDP switch, or subnet, the LIS proxies the MAC address to an integrated Simple Network Management Protocol (SNMP) scanning application. The following is an example of a (fictitious) location response.
200
US
WA
Spokane
1234th
Ave
NE
3910
147/9351
Fabrikam Inc
99517
Note. As a general rule, subnets that resolve to corporate VPN connections should generally not be included in the LIS for E9-1-1 automatic dispatch purposes. This is because typically there is not a civic address that can be assigned to the subnets that correlates to where the users are located. It is possible to associate a generic location with VPN-based subnets and not attempt to validate the civic address. However, this will flag every emergency call that originates as a manually entered address, and then screen the call to ensure the caller is connected to the correct Public Safety Answering Point (PSAP).
When Lync 2010 displays an address, it does not display the whole address due to usability issues. Instead, the location and city values are concatenated and presented in the UI.
Manually Entering a Location
Lync 2010 provides an interface for end users to enter locations. These locations are stored with an association to the default gateway’s MAC address in addition to a counter for each location for up to 10 addresses. This capability provides a “personal Location Information Server”. After a location is populated, it is automatically acquired when the user reconnects to that same network. Every time the same user connects to a network that is part of the personal, the counter is incremented by 1. When an 11th location (meaning network) is added, the record with the least amount of use is removed.
Some UC devices allow the user to enter a location but the device doesn’t cache previous locations. Other UC devices, such as Lync 2010 Attendant console, do not allow a user to enter a location.
Multiple Points of Presence
Each UC client acquires and caches the active location, so it is possible that a single user can have many current active locations. Sharing presence location follows the same model as active state. The location of the most active endpoint is published in presence.
Address Validation
The LIS provides a web service interface for address validation. Address validation is for E9-1-1 use only and serves the following purposes:
• Ensures that the civic address is valid as an official address for dispatch of emergency services. This includes having all fields for the address with the correct identifiers such as Street Name or Post Directional.
• Ensures that when an emergency call is placed with a validated address, the call is automatically routed to the PSAP servicing that address. Emergency calls with an address that has not been validated are screened by a call center before connecting to the PSAP.
Address validation is available only in the United States and requires that you obtain E9-1-1 routing from one of the approved E9-1-1 service providers for Lync Server located at . As part of obtaining the service, the service provider supplies a client certificate that you must provision on the LIS in your organization for address validation requests to be processed.
The LIS will render non-validated addresses to UC clients. However, if you plan to use the addresses for E9-1-1 purposes, we recommended that you validate them. Use the command, test-csliscivicaddress, to validate the civic address. Before explaining the details about how address validation works, it is helpful to understand the difference between location and civic address. Civic addresses are locations without the Location and Name fields. The Location and Name fields are not part of a civic address. They refer to in-building location and the identity of the company at the address. If locations in the LIS are defined by using Location and Name values, then, in general, the number of civic addresses will be less than the number of locations. This is because for locations the same civic address can be used for multiple locations.
When validating addresses, only the unique civic addresses are validated. The easiest way to validate civic addresses is to query for all civic addresses that have not been validated and request validation as demonstrated in the following command.
Get-CSLiscivicaddress |where { $_.MSAGValid -match $false } | test-csliscivicaddress -updatevalidationstatus
The previous command sends all civic addresses that are not marked as valid for validation. If they are returned as valid, the database will be updated to reflect this status.
If you want to send only civic addresses from the Unite States that have not been validated, the following command can be used:
Get-CSLiscivicaddress | where { $_.MSAGValid -match $false -and $_.country -like "*US*" }
The updatevalidationstatus flag triggers a location database update in Lync Server. If you just want to ensure that an address is valid without updating the database, leave this flag off as shown in the following example.
Get-CSLiscivicaddress |where { $_.MSAGValid -match $false | test-csliscivicaddress
Errors returned are contextually specific to each address.
SNMP
The LIS provides a web service interface to SNMP application. The SNMP applications must be certified by Microsoft. The SNMP application is configured by using a Windows PowerShell cmdlet that sets the URL of the SNMP web service. The SNMP application must adhere to the Lync Server LIS protocol to interoperate. This interface uses SSL security.
This interface enables UC clients to get a more detailed network-based location than they would get from subnets and provides an alternative to LLDP. This benefits some organizations for the following reasons:
• LLDP is not supported by Lync 2010 so this provides a mechanism for soft phones to acquire detailed location information.
• Installed layer 2 switches may not support LLDP.
The process of acquiring a location by an SNMP application is as follows:
1. A location request from a UC client is not matched to a BSSID, LLDP switch/port, LLDP switch, or subnet.
2. An SNMP interface is defined so the MAC address from the location request is passed to the SNMP application URL.
3. The SNMP application queries its database for the MAC address (not likely to be a real-time network scan) and finds a match for the MAC.
4. The SNMP application doesn’t actually return the location; it returns the switch/port or switch information. The switch/port or switch information must match the LLDP switch and port definitions that are contained on the Location Information Server (the format is generally a MAC address also).
5. The LIS then takes the switch/port information and matches a location that is associated with it and returns it to the UC client in the location response.
The main disadvantage of leveraging SNMP for locations is the timeliness of the information. The database of MAC or port information is not likely to be real time, so the more mobile the clients are the more likely it is that they will have an incorrect location. This approach is sufficient for clients that are mostly stationary, such as IP phones and desktop computers. However, for Lync 2010 running on laptops that move a lot, this approach is not optimum.
A hybrid approach where the WAP BSSIDs are defined in the LIS and the wired ports are rendered by using an SNMP application is preferable in these types of deployments.
Secondary Location Source—Multiple Addresses Versus Single Address
The LIS provides a web service interface to third-party Location Information Servers or what is being termed as Secondary Location Sources (SLSs). An SLS is configured by specifying the URL of the external Location Information Server web service. The external Location Information Server must adhere to the Lync Server Location Information Server protocol to interoperate. The interface supports SSL security.
The purpose of this interface is to enable UC clients to take advantage of alternative wire maps. Some enterprises may choose to continue to use their existing wire map infrastructure rather than support multiple databases and platforms.
The process of a UC client acquiring a location from a SLS is similar to that of the SNMP flow:
1. A location request is not matched to a BSSID, LLDP Switch/Port, LLDP Switch, Subnet, or the SNMP interface.
2. A SLS interface is defined so the entire content of the location request is passed to the SLS interface.
3. The SLS queries its database for a match to the network identifiers.
4. The SLS sends a location response back to the Location Information Server with one or more locations that match.
5. The Location Information Server then proxies the location response back to the client.
One key differentiator of locations that are rendered from the SLS is that the SLS can return more than one location in the location response. The LIS returns only a single location. One of the key scenarios enabled by use of the SLS is that the SLS can be a database of addresses that are defined by or for each user. The location request contains the SIP URI of the user that is signed in so the SLS can do a location match based on the SIP URI. Multiple locations are supported on all UC endpoints. In each case, the end user is required to select the location that should be currently associated with the client.
Enabling E9-1-1
When enabling E9-1-1 in your organization, it is important to understand the difference between 9-1-1 and E9-1-1. Configuring E9-1-1 requires that you consider the following issues:
• Location policies: A location policy can be assigned to users explicitly or implicitly, implicitly by recognizing the network subnet that the user is connected to and assigning the location policy that is assigned to that network site. (For details, see the Network Settings section later in this chapter.)
• Network settings: It is important to assign network sites based on network subnets within your organization because location policies can be assigned to network sites.
• User settings: Users are enabled for E9-1-1 based on the location policy they are assigned.
• Roaming: Administrators need to take into consideration how roaming users (inside and outside the corporate network) affects E9-1-1 resolution.
• The Location Required setting
The following sections provide detailed information about each of these considerations and settings.
9-1-1 Versus E9-1-1
Lync Server supports both 9-1-1 and E9-1-1. Emergency calls to 9-1-1 are routed to the gateway (defined by a dial plan) that supports the 911 dial string. The PSAP answering the call may or may not have a location for the calling number.
When a client is enabled for E9-1-1 and an emergency call is made the following happens:
1. The location that the client has acquired is conveyed with the call.
2. When routing the call, Lync Server references the PSTN gateway usage or route that was part of the client’s enablement policy for the emergency number.
This ensures that the call is routed to a PSAP that serves the caller’s location and gives a location to which emergency responders can be dispatched.
Location Policies
A user is enabled for E9-1-1 when the UC client receives a location policy through in-band provisioning. You can assign a location policy to a user implicitly or explicitly.
Implicitly: The location policy is assigned to a grouping of IPv4 subnets. When a client registers from a network subnet that is assigned to a location policy, Lync Server sends that specific location policy to the client.
Explicitly: The location policy is assigned directly to a user. Each client the user signs in to is always enabled for E9-1-1.
Different deployment scenarios of E9-1-1 are controlled by how UC clients obtain the location policy settings and how locations are acquired. For example, assigning a location policy to a network site (meaning, a group of subnets) ensures that all UC clients that connect from this site are enabled for E9-1-1. This includes users who roam to the sites. These settings are global, so they apply to users across all pools as they roam. This allows only sites that require it to be enabled for E9-1-1.
Assigning location policies directly to users enables E9-1-1 wherever a user is, inside or outside the corporate network. This supports work-at-home scenarios by routing emergency calls to the correct PSAP instead of routing only to the PSAP that serves the company’s PSTN gateways.
You can assign a location policy (the same or different) to network sites and to users. When a user is connected to a network site that has a location policy assigned to it, the site policy takes priority over the user-assigned location policy. This allows all users to be enabled at certain areas within an enterprise but only select users to be enabled everywhere.
The location policy not only enables E9-1-1 but also determines the details of how it works. Table 1 provides an overview of the location policy settings and their purpose.
Table 1. Overview of location policy settings
|Policy Setting |Purpose |
|Identity |The specified identity of the location policy. There can be only one policy that |
| |is global in scope. This global policy is the default policy. All additional |
| |policies must be created with a tag scope. |
|EnhancedEmergencyServicesEnabled |The default value is false. |
| |This setting enables UC clients that are enabled for E9-1-1 to send location and |
| |marking emergency calls by using the EmergencyDialString setting defined later in|
| |this table. |
|LocationRequired |There are three values available: |
| |No: The default. If a UC client is enabled for E9-1-1 and fails to automatically |
| |acquire a location, the user will not be prompted to enter a location. |
| |Yes: If a UC client is enabled for E9-1-1 and fails to automatically acquire a |
| |location, the user will be prompted to enter a location. |
| |Disclaimer: If a UC client is enabled for E9-1-1 and fails to automatically |
| |acquire a location, the user will be prompted to enter a location. If the user |
| |tries to dismiss this notification, the disclaimer will be displayed. |
|UseLocationForE911Only |The default is No. |
| |Indicator to UC clients that a location acquired can only be used for emergency |
| |purposes and not displayed in presence. |
|PstnUsage |This field is blank by default. |
| |The PSTN gateway usage as defined for the emergency call route. When the number |
| |in the EmergencyDialString setting (defined later in this table) is dialed, the |
| |call will be routed based on this PSTN gateway usage. |
|EmergencyDialString |This field is blank by default and is the only field that is required if the |
| |EnhancedEmergencyServicesEnabled setting is set to Yes. |
| |The dial string of emergency calls. Only the value, 911, is supported because |
| |E9-1-1 is only available in North America at this time. |
|EmergencyDialMask |This field is blank by default. |
| |Multiple dial strings can be defined. These dial strings will be converted to the|
| |emergency dial string. For example 112 could be set and when dialed it would be |
| |changed to 911. This allows international roamers to get proper emergency |
| |routing. |
|NotificationUri |This field is blank by default. |
| |The SIP URI of users who will be alerted when an emergency dial string is called.|
| |Each user specified gets connected in an IM session with the emergency caller and|
| |will receive the location information within the Conversation window. This IM |
| |alert is distinguished from regular IM sessions by automatically becoming the |
| |active window and the conversation has an emergency call notice. |
|ConferenceUri |This field is blank by default. |
| |The telephone number that can be conferenced into the emergency call. This |
| |functionality is provided by the E9-1-1 routing partners so this number must be a|
| |DID. |
|ConferenceMode |This field is blank by default. |
| |The mode of conference for the conference URI. |
| |Two possible values are available: |
| |One-Way: The emergency conference will only be in listen mode. |
| |Two-Way: The emergency conference will be in full participation mode. |
| |Note. The serving PSAP may have rules around this setting so check before |
| |enabling. |
By default there is a single global location policy. The settings for this location policy can be changed. However, it should be noted that every UC client will always receive this policy unless implicitly or explicitly receiving another location policy. For practical reasons, the only time this policy should be customized is when every UC client in the enterprise has to be enabled for E9-1-1 both inside and outside the network.
Additional location policies can be defined at the tag scope. Tag scoped policies are assigned to network sites and individual users. Assigning the same location policy to various sites or users gives you more flexibility to customize E9-1-1.
Network Settings
A common scenario for E9-1-1 is to enable E9-1-1 at the specific business locations of organizations that have more than one office. This is generally due to state regulations and the size of the workspace. Regulations vary from state to state, but, in general, multiple buildings, multiple floors in a building, or large square footage of a work area can trigger the need to have more detailed phone numbers or locations for emergency call dispatching.
The way to enable specific geographical areas for E9-1-1 is to define network sites and assign a location policy to each network site. As noted earlier, when a UC client is registering to Lync Server from a network site that has an assigned location policy, it will receive the policy via in-band provisioning. The settings from the location policy determine how E9-1-1 calls are routed.
The network settings include three hierarchical layers:
1. Subnets
2. Sites (one or more subnets to a site)
3. Regions (one or more sites to a region)
Table 2 shows which feature areas take advantage of this infrastructure.
Table 2. Features and infrastructures
| |QoE |E9-1-1 |CAC |
|Subnet | | | |
|Network site | | | |
|Network region | | | |
The location policy that is being assigned directly to a site gives the administrator flexibility when managing subnets. You can simply add or remove subnets from a site without changing policy settings.
It is important to note that subnets defined in network sites are not related to the subnets defined in the LIS. The LIS subnets are used strictly for associating a civic address to return a location to UC clients. The network subnets are used strictly for enabling call admission control (CAC), E9-1-1, and Quality of Experience (QoE). If there are overlaps in subnets, they must be entered into the LIS and network sites.
Much like the LIS, network subnets can be imported by using a CSV file. The following Windows PowerShell syntax provides an example.
import-csv subnet.csv | foreach { New-CsNetworkSubnet $ _.IPAddress -MaskBits $_.mask -Description $_.description -NetworkSiteID $_.NetworkSiteID}
The format of the CSV files is specified in the product documentation.
Assigning a location policy to a network site usually requires identifying the tag identifier (tag ID) of the location policy and can be done by using the following.
Get-cslocationpolicy
The location policy can then be set on the network site by using the following.
set-csnetworksite "Zurich" -locationpolicy "tag:dogfoodpolicy"
The location policy can be removed by using the following.
set-csnetworksite "Zurich" -locationpolicy ""
User Settings
As noted earlier, assigning a location policy to a user enables E9-1-1 in coverage areas outside configured network sites, such as home or work locations where subnets have not been configured. Or, if a company wanted all employees to be enabled for E9-1-1 and did not want to maintain the network configuration settings map of subnets or network sites, a location policy can be assigned directly to each employee. If all employees can have the same location policy, you can use the default global policy instead of assigning a policy directly to the users.
Note. Enabling users for E9-1-1 by assigning a location policy is not correlated to acquiring a location; meaning, the process of getting a location automatically from the LIS or it being manually entered.
A location policy can be assigned to a user by using the following command.
grant-cslocationpolicy -identity "testuser" -policyname tag:redmond
A user can be removed from a location policy by using the following command.
grant-cslocationpolicy -identity "testuser" -policyname ""
Roaming
An important consideration to evaluate when designing E9-1-1 deployments is roaming users. The following are roaming scenarios to consider:
• Roaming from locations inside the enterprise within the United States to outside the enterprise within the United States
• Roaming from different locations inside the enterprise within the United States
• Roaming from outside the United States to enterprise locations within the United States
• Roaming from outside the United States to non-enterprise (external) locations within the United States
• Roaming from the United States to enterprise locations outside the United States
• Roaming from the United States to non-enterprise (external) locations outside the United States
Following sections describe the previous scenarios in more detail.
Roaming from locations inside the enterprise within the United States to outside the enterprise within the United States If providing enhanced emergency services to users that use UC clients outside the network is a goal, a user-based location policy is required. This can only be enforced by a location policy that has a scope at the tag level or by the default location policy, because location policies cannot be assigned to network subnets outside the enterprise network. The use of a tag-level policy or the default location policy is determined by whether you have UC-enabled users outside the United States and if you have the requirement to control emergency routing services for those users.
In a situation where the majority of users are located inside the United States, the users in the United States can be assigned the default location policy. For users that are not based in the United States, a tag-level location policy can be assigned to those users.
Roaming from different locations inside the enterprise within the United States In general, the expected experience for E9-1-1 within the enterprise is that all users in specific areas are enabled for E9-1-1. This includes not only users whose office or work location may be within a targeted area, but also phones that are in common areas and any user or individual that roams into the targeted area. Unless the global default location policy is used for enabling all users for E9-1-1, the expected way to accomplish this scenario is to enable each targeted area for E9-1-1 by having the subnets for each area defined as part of the network configuration settings. Any UC client that is registering from these targeted areas will then automatically be enabled for E9-1-1, including users roaming onto the premises.
Roaming from outside the United States to enterprise locations within in the United States All users that roam onto a network site will be enabled for E9-1-1, including those that are just visiting. The interesting design decision is based around how these users from outside the United States dial; they might not be familiar with 9-1-1 and dial a country-specific emergency dial string. The routing behavior in these cases depends on how the location policy is configured. Dial string masks can be defined in the location policy. Dial string masks identify emergency numbers, such as 112, that should be transcribed to the local emergency number 911. If the dialed emergency number doesn’t match either the emergency dial string or dial string mask, the call will be routed according to the users dial plan, most likely to a gateway in the user’s originating country.
Roaming from outside the United States to non-enterprise (external) locations within the United States Supporting the proper emergency routing in such a scenario is difficult if the user roams to multiple countries. Because the location policy is acquired from the user, there will be only one route associated with their emergency dial string and dial string masks. All calls matching those dial strings will go to the same gateway regardless of where the user actually is.
Roaming from the United States to enterprise locations outside the United States This scenario and the solution are a mirror image of supporting E9-1-1 at enterprise sites in the United States for using roaming from other countries. If you want to support this scenario, network sites should be created for the areas that are targeted. Each network site should have a location policy assigned to it that has the local emergency dial string configured and 911 set for a dial string mask. All emergency calls for US users that roamed into the targeted area (911 and otherwise) will be routed to the correct local gateway.
Roaming from the United States to non-enterprise locations (external) outside the United States Support for this scenario is also very difficult because the user can be assigned only one location policy. This policy is static and can contain only one emergency route; therefore, there is no way to dynamically change the emergency call route based on where a user roams to.
Note. Lync Server clients are required to be enabled for E9-1-1. Common area phones and the Attendant console are included in this support. However, analog telephony adapters are not. This is because they do not run the Microsoft UC client software.
Note. There is no integration between Active Directory sites and the Lync Server network sites.
Location Required Setting
The location required setting is included to give different levels of indication to the end user to enter a location when one is not obtained automatically. The following are the three valid values and the associated behavior of Lync 2010:
No: There is no indication to the user that a location should be entered.
Yes: There is a generic text message in red to enter a location. This appears next to the Location bar in Lync 2010. The user can dismiss this notice; however, it will re-appear at every registration when a location is not automatically acquired.
Disclaimer: The same generic text message in red appears to indicate that the user should enter a location. However, if the user clicks the Location bar to enter a location or tries to dismiss the message, the disclaimer text will appear. The disclaimer text is a globally configurable string. The user can then add a location or dismiss it.
None of these settings restrict any client functionality when a location has not been entered.
E9-1-1 Routing
This section covers details about how routing works with E9-1-1.
Trunks
E9-1-1 calls must be routed through a SIP trunk to a certified E9-1-1 partner. The reason is that the location of the caller is conveyed in the SIP INVITE of the call. The service provider partner will parse the location and route the call accordingly.
Note. Routing the call to the PSTN gateway carrier through a SIP trunk or ISDN gateway will not result in proper routing because the location will either be stripped or ignored when routing the call.
The primary advantage of this approach is that users can roam to various areas within the United States (the service provider coverage is within the United States only) and emergency calls will be routed to the correct PSAP at any time. In a traditional E9-1-1 deployment, the location of a VOIP client must be provisioned in the E9-1-1 database of the carrier and a trunk connected to the emergency routing network for that area.
The Mediation Server used in the SIP trunk for E9-1-1 calls must not be load balanced because the service providers do not yet support this configuration. As a result, if the Mediation Servers have been consolidated onto the Front End Servers in a pool, separate stand-alone Mediation Servers should be used for emergency calls. The SIP trunks can take advantage of the Internet through a VPN connection or a dedicated circuit, which would provide guaranteed call quality. Resiliency to the service provider can be achieved by setting up an alternate or diverse SIP trunks to or from different data centers. Both SIP trunks can be placed in the outbound route that is used for emergency calls. In such a configuration, if the primary link is down, the call will be routed to the secondary. Figure 17 shows an example of a deployment that has two emergency SIP trunks each originating and terminating in different locations.
[pic]
Figure 17. Deployment with two emergency SIP trunks
PSTN Gateway Usages
It is important to understand how the Lync Server Outbound Routing component processes emergency calls in the event that you want the flexibility to select which trunk emergency calls should be routed through. The following is a basic overview of the logic used by the Outbound Routing component for emergency calls:
1. A call is identified by the OutBound Routing component as an emergency call by the priority:emergency header in the INVITE.
6. The location policy ID is determined for the call by scanning the location PIDF-LO of the SIP INVITE.
7. The PSTN gateway usage is obtained by looking up the location policy.
8. The call is then routed according to the routes defined in the PSTNUsage element in the location policy.
In summary, routing of emergency calls is controlled by the PSTNUsage element in the location policy. This makes it possible to control the route of emergency calls to use specific trunks in a specific order of priority.
For example, assume an enterprise configured a SIP trunk in Washington, DC and another in Sacramento, CA. The organization could then define “EastCoast” and “WestCoast” PSTN gateway usages with the following routes:
EastCoast
PrimaryRoute:Washington, DC
SecondaryRoute:Sacramento, CA
WestCoast
PrimaryRoute:Sacramento, CA
SecondaryRoute: Washington, DC
The organization can then define two location policies that have the following labels and PSTN gateway usages:
Location Policy 1
Description: East Coast E9-1-1
Emergency Dial String: 9-1-1
PSTNUsage: “EastCoast”
Location Policy 2
Description: West Coast E9-1-1
Emergency Dial String: 9-1-1
PSTNUsage: “WestCoast”
The Location Policies 1 and 2 can then be assigned to network sites, or users, or both to optimize the routing of emergency calls.
Note. The same routing configuration can be used for emergency calls in situations where there is not a SIP trunk to an emergency service provider. This works outside the United States and in areas of an enterprise that may not be large enough to merit E9-1-1 deployment. In these situations, a location policy can be assigned to each network site that has a PSTNUsage that directs emergency calls to that site’s PSTN gateway.
There is an exception for CAC. CAC does not distinguish emergency calls. Ensuring that these don’t conflict should be considered when deploying these features. In other words, if the SIP trunk for E9-1-1 calls is on the other side of a CAC-enabled WAN link from the user making the emergency call, it is possible that the call will instead get routed out the local gateway if the bandwidth limits are reached.
Distinguishing Emergency Calls to a Security Desk
The location policy also enables you to integrate an enterprise security desk into the emergency call. There are two modes of integration:
• The security desk can be conferenced or bridged into the call’s audio.
• The security desk can be alerted to the call by location.
The bridging functionality allows a single phone number to be bridged into any E9-1-1 call. This functionality is not actually provided by Lync Server but by the E9-1-1 partners. When the call is received by the routing partner, if the Conference URI field is populated with an E.164 number, that number will be called and bridged onto the emergency call. The mode of bridging is one-way or two-way and is also controlled by the Conference mode setting in the location policy. The signaling or media path for security desk bridging is not routed over the emergency SIP trunk but over the PSTN gateway ingress link to the enterprise. This requires the phone number to be a DID.
The alerting functionality allows an IM to be established between the emergency caller and security desk personnel. The IM contains the location of the caller in the Conversation window and has visual alerts to indicate that it is an emergency IM. These visual alerts distinguish the emergency IM from other IMs. Security personnel receiving such an IM alert can then continue with the IM conversation, escalate to other modalities, or dismiss it. One interesting use can be to quickly check back on emergency call hang-ups. The location policy allows multiple SIP URIs to be specified separated by a comma. Distribution group URIs cannot be used.
Call Detail Recordings
Emergency call records are also logged to call detail recordings (CDRs). What is unique about the CDRs for emergency calls is that the location, PSTN gateway usage, and conference URI information is contained in the data. Currently there is no out-of-the-box report for emergency calls.
Routing Enhancements
This section provides details about the internals of the new routing enhancements introduced in Lync Server 2010.
These enhancements are:
• Supporting multiple gateways per Mediation Server
• Updated outbound translation rules
• Caller ID suppression
Figure 18 highlights the logical enhancements in the outbound routing (OBR) for voice calls (this does not include routing to voice applications). Figure 18 does not illustrate the complete voice routing logic in Lync Server. A detailed description of the different routing steps in addition to how the features are configured follows Figure 18.
[pic]
Figure 18. Enhancements to outbound routing logic
Note. For simplicity, the FQDN is used in this section but it refers to either the FQDN or the IP address of a gateway.
Supporting Multiple Gateways per Mediation Server
Communications Server 2007 R2 and earlier releases required a Mediation Server FQDN as part of a voice route. Each Mediation Server had a static configuration to a next hop gateway. The Mediation Server used the next hop gateway to route calls to the appropriate gateway. Because Mediation Servers and gateways have different scale characteristics, Lync Server 2010 allows a Mediation Server to route to multiple gateways.
Configuration
The mechanism to configure multiple gateways per Mediation Server is as follows:
• Add the gateways in the Lync Server 2010 topology document. You can do this by using the Lync Server Topology Builder.
• For each gateway, reference the Mediation Server instance that it depends on. This is the MediationServer parameter of the Set-CsPstnGateway cmdlet.
• Configure the voice routes to have the destination reference one or multiple gateways. This is the PstnGatewayList parameter of the New-CsVoiceRoute and Set-CsVoiceRoute cmdlets.
Routing
After the topology dependencies and the routing configuration are completed as described in the previous section, the following logic is applied when Lync Server receives a call that is bound for the PSTN gateway or a PBX through a gateway:
• Based on the voice policy of the user making the call and the destination number, Lync Server 2010 Outbound Routing component determines the voice route for that call.
• The destination gateway service ID is used to look up the dependent Mediation Server. The SIP INVITE is pointed at the gateway FQDN by specifying it in the RequestURI, and the maddr parameter is populated with the information that was looked up for the Mediation Server, and then used to route the SIP INVITE through the dependent Mediation Server or pool (if the Mediation Server is collocated with the Front End pool).
• When the Mediation Server receives the INVITE, it applies additional logic specific to the Mediation Server, and then uses the original RequestURI (the FQDN of the gateway) to route the call to the destination gateway.
• For compatibility with Office Communications Server, the Mediation Server is configured with a default gateway FQDN. This default gateway is used as the destination if the RequestURI in the INVITE is the same as the FQDN of the Mediation Server that is processing the INVITE.
Number Translations Prior to Routing
Lync Server 2010 lets you manipulate destination phone numbers before calls are routed to the gateway. The configuration and routing are described in the following sections.
Understanding the Configuration of Route Translations
Configuring translation rules is part of the trunk configuration. Configuring translation rules enables you to manipulate the numbers based on the trunk that is used to egress the call.
The translation rules of a trunk are regular expressions that have a match pattern. Translation rules also have a corresponding translation pattern that is applied if the phone number matches the match pattern. The scope of this configuration can be applied globally, at site level, or at a service (PSTN gateway) level.
The following example illustrates a service-level assignment of translation rules for the identity “service: pstngateway:172.29.107.194”. The rule applies for phone numbers with a prefix “+1” that is translated to “002” prefix. For example +14255550100 is translated to 0024255550100.
First, the OutboundTranslationRule is created and stored in variable $r3. Then the rule pattern and translation are defined as follows.
$r3 = New-CSOutboundTranslationRule -Identity: service:pstngateway:172.29.107.194/gw1_rule
$r3.Pattern = '^\+1(\d*)$'
$r3.Translation = '002$1'
The associated trunk configuration for this particular gateway, pstngateway:172.29.107.194, is stored in the variable $tk3.
$tk3 = Get-CSTrunkConfiguration -Identity service: pstngateway:172.29.107.194
Next, the new OutboundTranslationRule, $r3, is added to the trunk configuration, $tk3.
$tk3.OutboundTranslationRulesList.Add($r3)
Set-CsTrunkConfiguration -Instance $tk3
Understanding the Internals of Route Translations
When the Outbound Routing component is processing a call destined to the PSTN gateway, the following logic is applied to realize the route translation feature:
• Based on the calling user’s voice policy and the destination number, the Outbound Routing component determines which voice route and associated gateway to select for the call.
• The Outbound Routing component uses the destination gateway service ID to look up the translation rules that are associated with the destination voice route. If one or more outbound translation rules are defined at the same scope as the gateway, in the same site as the gateway or globally, the Outbound Routing component attempts to match the pattern and update the destination number.
• The RequestURI is then modified based on the retrieved translations rules, and the translated number is populated in the RequestURI field prior to routing to the Mediation Server
Caller ID Controls
The Caller ID can be manipulated before a call is routed to the gateway. The following sections describe the configuration and routing details.
Understanding the Configuration
Caller ID settings are provided to Lync Server 2010 administrators at a route level. Because the voice policy of the user making the call and the destination phone number determine the call route, configuration at the route level allows for maximum flexibility when configuring caller ID. The SuppressCallerId and AlternateCallerId parameters of the CsVoiceRoute cmdlets control the caller ID behavior.
In the following example, SuppressCallerId is set to true and the altered caller ID is +14255550100 for the voice route that has the identity PSTN-1 route.
Set-CsVoiceRoute -Identity "PSTN-1 route" -SuppressCallerId $true -AlternateCallerId "+14255550100"
Understanding the Routing
When the Outbound Routing component processes a call that is destined to the PSTN gateway, the following logic is applied to alter the caller ID:
• Based on the caller’s voice policy and the destination number, the Outbound Routing component determines the route.
• If the route has suppressCallerID set to True, the Outbound Routing component retrieves the value in the AlternateCallerID field and inserts the P-AssertedID header into the outgoing INVITE to the Mediation Server.
• The Mediation Server uses the value in the P-AssertedID header to populate the FROM header in the outgoing call (INVITE) to the gateway or Session Border Controller (SBC).
• This value is then presented as the calling party number to the destination.
The following INVITE from Luka has his DID, +14255550153, which matches the PSTN-1 route voice route mentioned earlier.
INVITE sip:+13175550123@;user=phone SIP/2.0
From: ;tag=5a3e8dfdfb;epid=374b932b83
To:
CSeq: 1 INVITE
Call-ID: 9bf2fea516424fcb941d0ebc12574fdb
P-Preferred-Identity: , tel:+14255550153
According to the rule, the caller ID is updated in the P-AssertedID header that is sent to the Mediation Server.
INVITE sip:+13175550123@172.29.107.194:5070;user=phone SIP/2.0
From: "Luka Abrus";tag=5a3e8dfdfb;epid=374b932b83
To:
CSeq: 1 INVITE
Call-ID: 9bf2fea516424fcb941d0ebc12574fdb
P-Asserted-Identity: " Luka Abrus ",tel:+1425550100
The Mediation Server then populates the FROM header in the outgoing INVITE:
INVITE sip:+13175550123@172.29.107.194;user=phone SIP/2.0
FROM: "Luka Abrus";epid=2DFFB61AB8;tag=b8216e4e1
TO:
CSEQ: 32 INVITE
CALL-ID: 75285834-7026-4fbc-9c21-d28bbef87797
Analog Devices Routing
The following sections describe the configuration and routing mechanism of analog devices, including fax machines.
Understanding the Configuration
Analog devices are represented as Application Contact objects in Lync Server 2010. This enables the administrator to act on them as they would on users and assign configuration such as dial plans and policies. This centralization of the management of analog devices eliminates repetitive configuration across a large number of gateways (to which the analog Devices are physically connected) in a typical deployment. The following example creates a new analog device by using the New-CsAnalogDevice cmdlet:
New-CsAnalogDevice –LineUri “tel:+1425550148” -RegistrarPool “examplepool.” -AnalogFax “$false” –Gateway “172.29.107.194” –OU “OU=AnalogDevice,DC=lcscorp,DC=lcesa,DC=pri,DC=local”
After the analog device is created by using the previous cmdlet, you can apply other attributes such as dial plans and policies by using the standard Lync Server Management Shell verbs. The AnalogFax attribute is used to indicate if the specified analog device is a fax device.
Understanding the Routing
Calls to or from analog devices are handled similarly to calls to users for call-handling tasks such as translations, reverse number lookup, and policy enforcement; however, the following are some of the special characteristics of routing to or from analog devices:
• When a gateway receives a call from an analog device, the gateway routes to Lync Server any call that originates from an analog device that is physically connected to the gateway. No number manipulation or policy enforcement is done at the gateway.
• When a gateway receives a call from Lync Server, it then routes the call to the specified analog device.
• Because Lync Server does not support T.38 fax protocol, special handling is done by Lync Server for calls to or from analog devices that are tagged as fax devices. The following steps describe the routing that allows the signaling to flow through Lync Server to facilitate centralized CDR collection and call authorization, while the media is handled by the gateway.
o Step 1: The Mediation Server inserts a header called ms-trunking-peer that has the FQDN of the gateway for all calls inbound to Lync Server from a gateway. This informs the Outbound Routing component which PSTN gateway the call is coming from.
o Step 2: If a call is destined to a fax analog device (in all cases, including a fax device on the same gateway, on a different gateway on the same site, or on another site), Lync Server 2010 Outbound Routing component overrides the standard route lookup procedures and routes the INVITE to the gateway that is identified in the ms-trunking-peer header (which was added by the Mediation Server in Step 1).
o Step 3: The Mediation Server uses media bypass to move the media hairpin from the fax call from the Mediation Server to the PSTN gateway.
o Step 4: The gateway then routes the call to the corresponding fax machine.
Summary
In this chapter, the major Enterprise Voice features added to Lync Server have been described in detail:
• The private line feature gives users a second phone line where they can be reached directly.
• Call admission control gives administrators the ability to control the amount of A/V traffic on network links from being over-subscribed.
• The Call Park application provides call park and retrieve functionality that is familiar to organizations that used PBX systems. Call Park application lets users place a call on the system and retrieve it from another phone.
• E9-1-1 functionality includes the ability to publish location to contacts and provides location to emergency calls.
• Routing enhancements address customer requests such as supporting multiple gateways per Mediation Server and analog device routing.
The following chapters provide further information about related components important to deploy a complete enterprise telephony infrastructure based on Lync Server:
• Response Group Application: First shipped with Communications Server 2007 R2, Lync Server provides additional features like Agent Anonymity and a new management interface. The chapter also includes a summary of the Announcement Application, which was added in Lync Server.
• Call admission control (CAC): Another important component of Lync Server that enables IT administrators to manage the corporate network bandwidth, including WAN links that connect their sites.
Additional Resources
For more information, see the following:
• [MS-SIPAPP]: Session Initiation Protocol (SIP) Application Protocol Specification,
• Microsoft Lync Server 2010 Resource Kit Tool: Call Parkometer
• Unified Communications Open Interoperability Program – Lync Server,
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- important boss audio
- user guide ecobee
- chapter 2 basic ladder logic programming
- here maps location services technical guide
- dolphin myorthodontist setup and user s guide
- packaging tool user s guide oracle
- custom plate application
- splunk tutorialspoint
- mobile user guide openair
- leveraging a hadoop cluster from sql server integration
Related searches
- chapter 8 photosynthesis biology test
- chapter 8 photosynthesis worksheet answ
- chapter 8 photosynthesis
- developmental psychology chapter 8 quizlet
- chapter 8 photosynthesis answer key
- psychology chapter 8 quizlet
- biology chapter 8 photosynthesis answers
- chapter 8 photosynthesis pdf
- chapter 8 psychology quizlet memory
- psychology chapter 8 quizlet learning
- chapter 8 photosynthesis quizlet
- psychology chapter 8 quiz answers