Address Resiliency Within a Site
In Lync Server 2010, you must define virtual gateways to achieve resiliency
Virtual gateway FQDNs all resolve to the same IP address
Virtual gateways do not work when there is no control over the certificate used for TLS interactions Gateway-specific inbound policy cannot be applied when virtual gateways are used
Front-End
Server Mediation Server 1
Mediation Server 2
SBC
PSTN MPLS
Address Multiple Sites
Connecting to the Same
Service Provider
In Lync Server 2010, virtual gateways must be defined to allow connectivity from multiple MS pools to the same Session Border Controller (SBC) Fully Qualified Domain Name (FQDN) TLS could not be used because the SBC certificate does not contain the virtual gateway’s name SBC PSTN GW FE Pool 1 Backup MS Pool Trunk 3 Preferred MS Pool Trunk 1 Trunk 2 MS Pool 1 MS Pool 2
Site 1
Site
2
Address IP-PBX Interworking
for Bypass
In Lync Server 2010, you need to define virtual gateways to achieve bypass between a PBX endpoint and a Lync endpoint at the same site Virtual gateway FQDNs all resolve to the same IP address of the IP-PBX SIP call control termination point
GW1 is associated with MT Resource at Site 1 in the CMS; Route 1 to all extensions in Site 1 has GW1
GW2 is associated with MT Resource at Site 2 in the CMS; Route 2 to all extensions in Site 2 has GW2
Bypass can now happen for calls between a Lync endpoint and an IP-PBX endpoint at the same site Onerous task for admin when dealing with tens of sites
Site 1
Site 2
MT Resource MT Resource Extension Extension Mediation ServerFront End Server
IP-PBX SIP
Head Office
Signaling Path
Non-Bypass Media Path
Trunk Definition
In Lync Server 2013, a trunk is defined as a combination of:
MS FQDN, Mediation Server Session Initiation Protocol (SIP) listening port, Gateway FQDN, Gateway SIP listening port
This provides for:
Better resiliency—both service and on-premises scenarios
Better interworking with IP-PBXs for bypass Using TLS plus Secure Real-Time Transport Protocol (SRTP) for multiple SIP trunks to the same SBC FQDN
When Outbound Routing matches a dialed PSTN number to a route, the route will consist of a list of trunks
Contrast this with Lync 2010, where a route consisted of a list of gateways
Trunks and IP-PBX
Interworking
Define multiple trunks between MS and PSTN gateway representing IP-PBX SIP termination Each trunk will be associated with the appropriate route for outbound calls from MS to IP-PBX
For inbound calls, per-trunk policy will be applied
Trunk configuration will be scoped globally or per trunk; similarly, dial plan can be scoped per trunk
Representative Media IP is a per-trunk parameter Port A Port B Port N Port A1 Port B1 Port N1 Trunk 1 Trunk 2 Trunk N
Trunks and Resiliency
Note that a single MS listening
port is needed for trunks to multiple gateways Example:
Port C : 5061, can be used as the MS listening port
for Gateway 1 and Gateway 2
Port D : 5068 can be used on SAME MS for a different gateway or IP-PBX if required Resiliency does not require multiple MS listening ports
Quicker Failover Based on
Options Polls
If all trunks on that MS have failed in at least their most recent options poll, the MS will immediately instruct the Front-End Server by means of a 503 to retry other MS in the pool for the call FE MS1 GW 1 GW 2 GW 3 Options Options d. SIP c. SIP a. SIP b. 503 MS2 MS3 MS Pool
Quicker Failover Based on
Options Polls
If at least one other trunk has been successful in its most recent options poll, the MS will immediately instruct the Front-End Server by means of a 504 response that the trunk is down and a different trunk should be tried for the call
OBR Retries to Next Trunk if
No Timely 18X Received
For non-bypass calls, the MS automatically sends a 183 response to OBR in Lync 2010
This results in the timer being immediately stopped, even though the gateway never answers with an 18x; the net result is that misconfigured and/or nonfunctioning gateways are masked, and OBR recovery to alternate routes is thwarted
In Lync Server 2013, the autogenerated 183 response from the MS to OBR will not cause the OBR timer to stop
Lync Server 2013 15 15 Supported Lync Server 2013— Lync Server 2010 15 14 Supported 14 15 Supported Lync Server 2013— OCS 2007 R2 15 13 Supported 13 15 Not Supported
Lync Server 2013 15 15 15 Supported
Lync Server 2013— Lync Server 2010 15 15 14 Supported 14 14 15 Supported Lync Server 2013— OCS 2007 R2 15 15 13 Supported 13 13 15 Supported
Outbound Calls
Inbound Calls
** Assumed certified gateways for the release of Mediation Server shown in the tables above.
Lync 2010 SBA Supported Supported *
Lync 2013 SBA Not Supported Supported
* Contents from Lync 2010 SBA will write monitoring and archiving contents to Lync 2010 store.
Routing of IP-PBX Calls to
Another IP-PBX System via
Lync
1. Incoming call from the PBX trunk 2. Validate incoming trunk associated PSTN
usages
3. Determine a route
4. Apply outbound translation rules
5. Route to outgoing PBX trunk via Lync
PBX User IP-PBX IP-PBX PBX User
Mediation
Server Mediation Server
Trunk Trunk
Media
Front-End Server Inbound
Trunk PSTN Usage Route Outbound Trunk
Routing of IP-PBX Calls to
PSTN via Lync
1. Incoming call from the PBX trunk 2. Validate incoming trunk associated PSTN
usages
3. Determine a route
4. Apply outbound translation rules 5. Route to outgoing gateway trunk
PBX User IP-PBX Gateway PSTN
Mediation
Server Mediation Server
Trunk Trunk
Media
Front-End Server Inbound
Configure a voice route
New-CsVoiceRoute -Identity RedmondRoute -PstnUsages @{add=“Redmond"} -PstnGatewayList @{add="PstnGateway:redmondgw1.contoso.com"}
Lync user call to PSTN
network
1. An administrator can associate a set of
translation rules to a trunk configuration to enable calling number manipulation
2. A trunk to route the call is determined based on the user voice policy and destination number
3. From the trunk configuration, a translation
rule is applied for the calling number Gateway
PSTN MS
Front-End Server Voice Policy
“Redmond” “InternationalPSTN Usage ”
Route
Redmond-Int Outbound TrunkRedmond-GW
Trunk
Called # Trans.
Use “011” prefix Calling # Trans.Remove “+” Route call
Managed
Unmanaged
Management Managed by an administrator or a manager Managed only by an administrator
Delegation Managed by an administrator or the response group manager Delegation not supported
Sharing
Cannot share the response group queues or
agent groups with any other response group Can share queues and agent groups with other unmanaged response groups
Visibility
Visible to the response group manager Visible to the administrator
Not visible to other managers
Visible only to the administrator Not visible to any manager