Microsoft Lync Online Dedicateddownload.microsoft.com/download/7/B/A/7BA7F47D-DFC3... · 5. Partner MUST populate required (red font) fields in MSFT provided network diagram(s) showing

Microsoft Lync® Online Dedicated Voice Partner Connectivity

© 2015 Microsoft Corporation. All rights reserved. 1

Microsoft Lync® Online Dedicated

Voice Partner Connectivity Guide

Release 15.1

Published: April 2015

Note: As of April 2015, Skype for Business became the new communications product from Microsoft that

provides instant messaging (IM), presence, conferencing, and telephony solutions to support enterprise-level

collaboration. Lync Server 2013 will remain as the infrastructure for existing Lync Online Dedicated customers.

The Skype for Business client can be used with Lync Online Dedicated; links and references to the Skype for

Business client exist within this document.



Contents 1 Introduction ............................................................................................................................................................... 3

1.1 Document Overview .......................................................................................................................................... 3

1.2 Design Goals ...................................................................................................................................................... 4

1.3 Design Non-Goals .............................................................................................................................................. 4

1.4 Cloud to Cloud - Voice Transport ...................................................................................................................... 5

2 Partner Requirements ............................................................................................................................................... 6

2.1 Redundant And Geographically Disparate Sites ................................................................................................ 6

2.2 Redundant Connectivity .................................................................................................................................... 6

2.2.1 Edge Site/PoP (Point of Presence) Connectivity ........................................................................................ 6

2.3 IP Networking .................................................................................................................................................... 7

2.3.1 IP Network Timers ..................................................................................................................................... 8

2.3.2 IP Network High Availability ...................................................................................................................... 8

2.4 Packet Transmission .......................................................................................................................................... 8

2.5 QoS .................................................................................................................................................................... 8

2.6 SIP Trunk Baseline Requirements ...................................................................................................................... 9

3 Design Principles...................................................................................................................................................... 10

3.1 Architecture Diagram ...................................................................................................................................... 11

3.1.1 SIP Trunking Circuit .................................................................................................................................. 11

4 Appendix .................................................................................................................................................................. 13

4.1 PoP Locations per Region ................................................................................................................................ 13

4.2 Forecasted Traffic ............................................................................................................................................ 13

4.3 Circuit Connectivity Model .............................................................................................................................. 13

4.3.1 Redundant circuits in Redundant PoPs ................................................................................................... 14

4.4 Acronyms Used ................................................................................................................................................ 14



INTRODUCTION

1.1 DOCUMENT OVERVIEW Lync Online Dedicated Enterprise Voice enhances the Microsoft Lync 2013 client experience with PC-based PSTN

(public switched telephone network) voice services, allowing users to place and receive telephone calls using the Lync

client as a ‘soft phone’. With the Enterprise Voice add-on feature, customers are now able to expand their

capabilities beyond Instant Messaging (IM) and Presence. Enterprise Voice is optimized for highly mobile PC-centric

users.

Enterprise Voice can reduce the costs associated with maintenance and repair of on-site voice equipment—including

fees associated with PBX moves, and add or change activities. With Enterprise Voice, the customer now has the

ability to reduce the financial burden of maintaining a legacy telecommunications environment, while enabling public

switched telephone network (PSTN) voice services for users from virtually any broadband connection.

Lync Online Dedicated recently introduced PSTN dial-in conferencing as part of the Enterprise Voice service offering.

A second method of PSTN connectivity known as On Premise Session Border Controller (SBC) was also introduced

which allows customers to connect to both the PSTN and their legacy private voice network.

Lync Online audio conferencing is expanded to enable users to join a Lync audio conference via a (PSTN) phone. This

feature enables users within your organization and persons outside your organization to join audio conferences from

a PSTN phone (e.g. home phone, mobile phone, etc…). PSTN dial-in conferencing capability is only available in select

countries and each audio conference meeting organizer must have the Enterprise Voice feature enabled. All PSTN

dial-in audio conference meeting must be initiated by an Enterprise Voice user.

The SIP trunk offering requires the following to be deployed:

The method for voice connectivity is Session Initiation Protocol (SIP) Trunking using a Qualified Lync Online Dedicated provider. SIP Trunking provides PSTN connectivity for the customer in which the customer obtains service from a qualified SIP Trunking provider1. Microsoft does not sell SIP trunking services to customers directly, as such, the customer is responsible for ordering the SIP trunking service from the Qualified Lync Online Dedicated SIP trunking service provider.

Document Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in IETF RFC 2119.

1 Microsoft Unified Communications Open Interoperability Program (UCOIP) certification (SIP Trunking Services)

http://technet.microsoft.com/en-us/lync/fp179862



1.2 DESIGN GOALS Voice related features bring the following technical design goals:

End to end low latency network(s).

Redundant and scalable connectivity solution between Partner service-cloud and the MSFT service-cloud

(LYNC ONLINE DEDICATED service).

Redundant sites terminating SIP trunks. Sites are geographically disparate to avoid multiple sites being

affected by a single regional disaster, such as an earthquake. Regional latency is considered, deploying at

sites to allow for optimal media paths to & from the PSTN for Lync Online Dedicated (LOD) media.

DSCP marking and relative QoS controls to sustain media quality in the presence of IP network congestion

and to place audio streams on prescribed network paths. DSCP markings are being set but no prioritization is

done with audio traffic in Microsoft’s network.

1.3 DESIGN NON-GOALS This document does not address the following:

Monitoring and Provisioning.

Server & Server NIC redundancy.

Connectivity to Enterprise/Customer networks. NOTE: This is covered separately between Microsoft and the

customer.

MSFT is not responsible for the network connectivity between any given enterprise/customer and partner

service-clouds. This document is primarily focused on implementing the lowest latent connectivity between

Partner network demarcations and MSFT Datacenters.



1.4 CLOUD TO CLOUD - VOICE TRANSPORT

Legend

1. Multiple 1/10GigE connection from Service Provider to Lync Online Data Center

2. Service Provider’s SBC (Primary)

3. Service Provider’s SBC (Secondary)

4. Lync Online Data Center (Primary)

5. Lync Online Data Center (Secondary)

6. Customer Link (Primary)

7. Customer Link (Secondary)

8. Customer Network Locations



2 PARTNER REQUIREMENTS

2.1 REDUNDANT AND GEOGRAPHICALLY DISPARATE SITES Partners MUST have redundant and geographically disparate sites capable of terminating a SIP trunk.

a. Geographically disparate is defined as being in geographies far enough apart there is no risk of an

event, such as earthquake, affecting the availability of both sites.

b. Redundant is defined as being equal in terms of functionality, availability, and capacity.

Site placement SHOULD take latency, with respect to geography, into consideration. For example, in North

America (NOAM) a Partner SHOULD deploy an SBC site near two of the US Edge sites. As part of the

onboarding process, Microsoft will provide recommended edge sites to use.

Lync Online Dedicated Enterprise Voice is available for Large Multi-national Enterprises that have voice users

at locations all across the world. One of the design criteria for Voice deployments that cross large

geographical boundaries is to try and keep the media sessions within a region (North America or Europe) to

improve Voice performance. A multi-regional deployment must span at least 2 regions and the customer

must have at least 2 data centers in a region. Each region will have a Primary and Secondary Enterprise Voice

Data Center, with a minimum Server footprint in the Secondary Data Center. The customer must contract

PSTN SIP Trunking Services for each region. The PSTN SIP Trunking Service Provider may be the same for

both regions if the coverage area from the Service Provider meets the customer’s requirements or each

region can be served by one or more SIP Trunking Service Providers.

2.2 REDUNDANT CONNECTIVITY 1. Connectivity MUST be supplied using dedicated circuits between the Partner and MSFT networks.

2. Redundancy MUST be realized for the dedicated circuits.

3. Redundant circuits MUST traverse disparate transport & routing infrastructure in order to avoid a single

point of failure.

4. Redundant circuits MUST be identical in terms of bandwidth, such that if one circuit fails the other circuit is

sufficient to handle ALL voice traffic.

5. Partner MUST populate required (red font) fields in MSFT provided network diagram(s) showing dual

circuits into LYNC ONLINE DEDICATED service cloud.

6. Partner MUST provide network diagram(s) showing overall network architecture for service cloud

integration.

2.2.1 Edge Site/PoP (Point of Presence) Connectivity

1. Partners MUST have direct IP connectivity into a MSFT PoP.

2. Partners MUST have redundant and diverse connections to the MSFT service cloud.

3. Reference recommended connectivity model for all Partners, section 1.4, Figure1.



Cross-Connect at PoP

Microsoft templates include network instructions to Microsoft (NIM) and Partner Engagement Form.

1. Partner SHOULD provide suite and rack number in meet point site.

2. Partner SHOULD provide router name and u-stop location in rack.

3. Partner SHOULD provide specific Ethernet port numbers for cross-connect.

4. Partner MUST configure cross connect L2 interfaces for auto-negotiation.

5. MSFT REQUIRES cross-connects be SM fiber Ethernet to eliminate possible issues with distance between

terminating endpoints.

a. MSFT uses LC/PC fiber connectors as a standard. Partner MUST plan accordingly.

6. Partner MUST take responsibility for scheduling and deploying the cross-connect. MSFT will provide

necessary LOA(s) to the partner upon request.

2.3 IP NETWORKING Microsoft templates include network instructions to Microsoft (NIM) and Partner Engagement Form.

1. Partner MUST provide their ASN for routing with MSFT.

a. The ASN MAY be private or public.

2. Partner MUST provide peering /30 public IP space for routing between partner and MSFT, for each Layer3

(Network) connection.

a. If partner wants to use VRRP a /29 is REQUIRED.

3. Partner MUST provide specific IP address(es) to be assigned on MSFT interfaces, and floating address(es)

as necessary.

4. Partner MUST advertise all SBC subnets from all Interconnection points. The end result is that in a DR

scenario, IP traffic may enter either Partner demarcation and will be routed properly.

5. When routing towards MSFT Datacenter X the Partner MUST route to the anchor site local to the

destination DC, based on destination subnet. Partner SHOULD configure BGP such that there is route

affinity based on Datacenter to PoP proximity. MSFT MAY prepend BGP routes to enforce this

requirement.

6. Partner MUST provide ALL address space that will be advertised via BGP. For example, if the partner’s pre-

production environment traffic will traverse the same circuits as their production environment MSFT

needs the IP space from both environments.

a. Partner MUST provide descriptions of how each assigned IP address is used. E.G. the spreadsheet

(Partner Engagement Form) will detail each SBC signaling and IP address, in addition to other IP

address whose traffic is expected to traverse the dedicated circuits between the service clouds.

b. Partner MUST provide Layer4 (Transport) ports to be used when contacting a given IP address

within their service cloud.

7. DSCP markings are supported; Partner SHOULD preserve and prioritize DSCP markings as transmitted from

the MSFT service-cloud.

8. DSCP markings are supported; Partner SHOULD prioritize audio traffic from the MSFT service cloud, which

will be marked as EF.



2.3.1 IP Network Timers

1. IP network failures, at any layer, SHOULD be resolved within 100ms.

2. BGP SHOULD run over BFD.

Ideally, a failure in any part of the IP network and at any layer would be resolved within 100ms, because it

affects only a few packets of any given call. A more realistic view requires a look at the form of the network

in question. For Lync Online environments, the relevant components are BGP timers at the edges and LSPs

through the core. LSPs should naturally have rather aggressive failover – any relevant timers should simply

be tuned as low as possible without impacting stability. BGP timers will never be sufficiently short due to

protocol limitations. As a result, we strongly recommend that BGP run over BFD wherever possible.

2.3.2 IP Network High Availability

1. eBGP multi-hop is the current MSFT standard for HA in the PoP sites and MUST be supported.

a. MSFT does not perform label exchange over BGP due to overlapping label and IP issues.

b. MSFT BGP peering password will be provided in a private correspondence between MSFT and

Partner network engineers.

2.4 PACKET TRANSMISSION 1. Average packet jitter SHOULD be less than 1ms, and MUST be less than 6ms.

2. Max packet jitter SHOULD be less than 21ms, and MUST be less than 41ms.

3. Average packet loss rate SHOULD be less than 1%, and MUST be less than 2.01%.

4. Max packet loss gap SHOULD be less than 41ms, and MUST be less than 81ms.

5. Network latency (round-trip) between the MSFT MS and the partner SBC SHOULD be less than 41ms, and

MUST be less than 64ms.

6. Voice SIP/(S)RTP/(S)RTCP traffic MUST NOT be routed across an internet connection when being

transported to the LYNC ONLINE DEDICATED service cloud.

7. The codec used between MSFT and Partner clouds will be G711u-law (or a-law) with a packetization time

of 20ms. Partner IP infrastructure involved in cloud-to-cloud connectivity MUST be robust enough to

handle bandwidth and PPS requirements for forecasted voice load, as shown in the Appendix.

2.5 QOS DSCP markings are currently added and preserved, however we’re not prioritizing traffic.



2.6 SIP TRUNK BASELINE REQUIREMENTS Partner SBCs will interface with MSFT Mediation Servers. A reiteration of the general connectivity related

requirements are given in this section. Compliance with this section does not imply full compliance with the

SIP Trunking Interoperability specification document.

1. SIP over TCP MUST be supported, per IETF RFC 3261.

2. RTP and RTCP over UDP MUST be supported.

3. Where TCP only is used, Partner MUST target MSFT at TCP 5060.

4. Where TLS is used, Partner MUST target MSFT at TCP 5067.

5. TCP/IP Socket use

a. A SIP response MUST go over the same connection that the SIP request was sent over; other SIP

transactions may use any available connection.

b. Connections will be established on demand (there are no pinned up connections) and will be re-

cycled at least once every 24 hours.

c. If the maximum concurrent connections (4) are reached, the Partner SBC will not establish a new

connection but will instead re-use an existing connection.

d. Inbound connections from the Partner SBC must come via the private service-cloud network.



3 DESIGN PRINCIPLES

Overview - The proposed solution is to make use of dedicated circuits as a delivery method to achieve reliable quality

media transport between service clouds (MSFT and Partner). Both service-clouds’ applications will locate each other

via DNS lookups. The solution will be deployed per region in a mutually exclusive manner.

Dedicated Circuits – are used between Partner core network and the MSFT network demarcation (PoP). Both

networks route voice signaling and media to each other via the dedicated circuits. Any given IP network entry point

is able to service traffic for all MSFT and Partner Datacenters related to the service being provided.

Latency and Congestion Control - Packets carrying real-time traffic, such as voice or video, are mapped to lowest-

latency routes across the service network. Lowest latency intra-network paths are controlled within each cloud.

Redundancy – IP level redundancy is realized via BGP. Ethernet redundancy is utilized as appropriate and is

supported by RSTP. Site capacity, functionality, and availability are redundant.

Shared Egress – This design provides the capability for a sip provider to deploy large-capacity sip trunk into the Office

365 Dedicated (O365-D) environment which can then be provisioned to support multiple customers via 802.1Q. This

reduces provisioning costs for the sip provider as well as the time it takes to provide PSTN connectivity to a

customer.

SIP Provider

Off

ice

36

5 D

ed

ica

ted

VLAN400

VLAN401

VLAN402

802.1Q CUSTB

VRF:RMT

CUSTC

VRF:RMT

CUSTA

VRF:RMT

In each datacenter the sip provider wishes to deliver services they will provision two 802.1q trunks (TRUNK-A,

TRUNK-B). TRUNK-A will connect to the Microsoft A side MER/GMR (RTR-A) and TRUNK-B will connect to the

Microsoft B side MER/GMR (RTR-B).

When a customer purchases services from the sip provider each trunk will have a new vlan provisioned, a layer 3

connection established into the customer’s VRF:RMT and BGP configured to exchange routes. The sip provider will

advertise the networks required to reach the session border controllers for the customer and Microsoft will advertise

the networks that contain Lync Mediation Servers (MGS) for the customer.



3.1 ARCHITECTURE DIAGRAM

Partner/Carrier to MSFT network – Access for the Partner to physically connect to the MSFT network is necessary,

and will be provided in the form of a cross-connect in the agreed upon edge site locations.

Figure: High level diagram of topology per region (example: Northamerica).

For customer specific topology to be defined, the carrier will need to complete the partner engagement form and

Microsoft will document Lync specific information.

3.1.1 SIP Trunking Circuit

To provide PSTN SIP Trunking services for Lync Online Dedicated Enterprise Voice, the SIP Trunking Service Provider

MUST enable dedicated MPLS circuits into the Lync Online Dedicated Data Centers. Each Lync Online Dedicated

customer is deployed in at least two Data Centers and connectivity to the Service Provider’s SIP Trunking network is

required to each of the Lync Online Data Centers enabled for voice. The Lync Online Dedicated Enterprise Voice

Service is engineered to be highly available. A secondary regional data center and alternate SIP Trunking paths are

used in the event of a data center failure. The Lync Online Deployment team will work with the Service provider to

determine the location for SIP Trunking demarcation.



The standard configuration for PSTN SIP Trunking Service providers require redundant links to be deployed in each

Lync Online Data Center. The circuits will terminate into an Access Edge managed by Microsoft. If a Service Provider

requires on premise equipment to be deployed (router), rack space will be coordinated by the Lync Online

Deployment Team. The Service provider is REQUIRED to provide Out of Band (OOB) management using a

POTS/Analog line to any devices in the Lync Online Data Center.

Figure: Sample per-datacenter region network topology diagram (example: San Antonio – SN1).



4 APPENDIX

4.1 POP LOCATIONS PER REGION Partner MUST confirm PoP location with MSFT before ordering circuits to that location.

4.2 FORECASTED TRAFFIC Partners SHOULD have redundant (active/active) circuits into the MSFT service cloud adequate for existing

customer purchased talk paths (G.711).

4.3 CIRCUIT CONNECTIVITY MODEL



4.3.1 Redundant circuits in Redundant PoPs

1. Allows for VRRP fail-over for redundant circuits within a PoP 2. Allows for PoP redundancy 3. Allows for avoiding additional backbone traversal in all scenarios not involving DR

4.4 ACRONYMS USED APAC – Asia Pacific

ASN – Autonomous System Number

BFD – Bidirectional Forwarding Detection

BGP – Border Gateway Protocol

CA – Certificate Authority

CRL – Certificate Revocation List

DNS – Domain Name System

DSCP – DiffServ Code Point

eBGP – External BGP

EMEA – Europe Middle East Asia

GTM – Global Traffic Management

HA – High Availability

IETF – Internet Engineering Task Force

IM – Instant Messaging

IP – Internet Protocol

LOA – Letter of Authorization aka Letter of

Agency

MMR – Meet Me Room

MPLS – Multi-Protocol Label Switching

MTLS – Mutual Transport Layer Security

MS – Milliseconds

NOAM – North America

OBR – Out Bound Routing

PoP – Point of Presence (*AKA – Edge Site,

Carrier Hotel, Anchor Site)

PSTN – Public Switched Telephone Network

QoE – Quality of Experience

QoS – Quality of Service

RFC – Request For Comments

RSTP – Rapid Spanning Tree Protocol

SBC – Session Border Controller

SM – Single Mode

VAP – Voice Anywhere Partner

VRRP – Virtual Router Redundancy Protocol

Microsoft Lync Online Dedicateddownload.microsoft.com/download/7/B/A/7BA7F47D-DFC3... · 5. Partner MUST populate required (red font) fields in MSFT provided network diagram(s) showing

Documents