Connectivity and Optimisation

Introduction

There are several important considerations for Local Organisations to assess when onboarding to Microsoft 365 Phone System to ensure the local network and Internet connections are set up for optimised performance.

A connection to Microsoft 365 can span over the corporate network, the Internet, and the Microsoft network. NHSmail organisations will have full control over their corporate network (local internet or secure boundary and HSCN) and will be responsible for managing their connectivity, bandwidth requirements and the quality of service (QoS) to ensure their local network configuration is sufficient to support telephony traffic.

If your organisation uses the Health and Social Care Network (HSCN) to access the internet, please contact your Consumer Network Service Provider (CN-SP) to discuss the network connectivity, bandwidth requirements, optimisation, and readiness testing as per your requirements for the Teams Phone System service. For more details on HSCN connectivity, please use the following link.

Local organisations must follow the Microsoft 365 connectivity principles:

• Network readiness ensuring the network has enough bandwidth available for the modalities Teams will provide, including Teams Phone System
• Use the endpoint categories to differentiate the M365 traffic from generic traffic for efficient routing
• Egress M365 data connections through Internet as close to the user as practical
• Configure direct egress for the M365 connections, avoiding network hairpins and minimising network latency (RTT) to Microsoft’s network
• VPN is not designed or configured to support Real-Time Media traffic; therefore, organisations should ensure that users and devices are configured to bypass the VPN-Tunnel.

There are a series of self-help steps provided by Microsoft should you experience any issues when using Teams. Find these here.

Depending on service consumption across the local organisation, there may be a requirement to uplift bandwidth in conjunction with their local network provider. If low bandwidth prevents the use of HSCN, the recommended options are:

• Install an additional HSCN line for telephony
• Use a private internet connection (if already in place and of sufficient bandwidth)
• Apply to access the levelling up funding available via the Better Connectivity for Health Programme

For optimal media quality, organisations should consider working with their network service provider or CNSP to meet the following the network performance standards for their Phone System traffic:

Metric	Endpoint to Office365	Corporate Network to Microsoft 365
Latency (one way)	<50ms	<30ms
Latency (RTT or Round-trip Time)	<100ms	<60ms
Burst packet loss	<10% during any 200ms interval	<1% during any 200ms interval
Packet loss	<1% during any 15s interval	<0.1% during any 15s interval
Packet inter-arrival jitter	<30ms during any 15s interval	<15ms during any 15s interval
Packet reorder	<0.05% out-of-order packets	<0.01% out-of-order packets

Connectivity to 365 for Clients and Devices

Computers and devices that use Phone System must use specific network ports to communicate with Microsoft 365 services. These ports are essentially doors through which devices talk to each other over a network or the internet. NHSmail organisations must check the network connectivity and configure the required network rules to allow devices on their network to reach Microsoft 365 through the following network ports:

Source	Source Port	Destination	Destination Port	Service
Local client	Any	13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/14	80, 443	TCP
Local client	Any	13.107.64.0/18, 52.112.0.0/14, 52.120.0.0/14	3478-3481	UDP

To restrict traffic to Microsoft IP addresses, check the Skype for Business Online and Microsoft Teams section in this article for the latest Microsoft IPs and endpoints.

UDP ports 3478–3481 are the required media ports and must be opened, otherwise, the client will fail back to TCP port 443. NHSmail organisations can check whether their firewall allows communication on these network ports by performing a connectivity test using the Microsoft 365 network connectivity tool from their local network.

For Calling Plans, there is no requirement to deploy an SBC. To use the Calling Plan, Teams clients/devices will be required to communicate to M365 IP addresses on TCP and UDP ports.

• Microsoft 365 Connection points for Direct Routing

The Session Border Controller (SBC) deployed for Direct Routing is required to have a connection to Microsoft 365 and the organisations selected SIP Service Provider.

 

The connection points for Direct Routing to Microsoft are the following three FQDNs:

• pstnhub.microsoft.com (primary FQDN)
• pstnhub.microsoft.com (Secondary FQDN)
• pstnhub.microsoft.com (Tertiary FQDN)

Placing these three FQDNs in order is required to:

• Provide optimal experience (less loaded and closest to the SBC datacentre assigned by querying the first FQDN).
• Provide failover when the connection from an SBC is established to a data centre that is experiencing a temporary issue.

The FQDNs sip.pstnhub.microsoft.com, sip2.pstnhub.microsoft.com, and sip3.pstnhub.microsoft.com – will be resolved to IP addresses from the following subnets:

• 52.112.0.0/14
• 52.120.0.0/14

Organisations will be required to open the required ports for all these IP addresses ranges on their network to allow incoming and outgoing traffic to and from the addresses for signalling and media.

NHSmail organisations must work with their network Team and/or supplier (local or CN-SP if using the HSCN network) to configure the required network routing and the firewall rules to allow SBCs to communicate with Microsoft and the SIP service provider for inbound and outbound traffic.

On the internal/management interface, SBC should be able to communicate to DNS, NTP, and Certificate CRL IPs.

Source	Source Port	Destination	Destination Port	Service
SBC Internal Interface	1024-65535/tcp 1024-65535/udp	DNS Server	53	TCP/UPD DNS
SBC Internal Interface	1024-65535/tcp 1024-65535/udp	NTP Server	123	UDP NTP
SBC External Interface	1024-65535/tcp 1024-65535/udp	CRL Global Sign CRL IPs 104.18.21.226 104.18.20.226	443	TCP Certificate CRL
Management Access workstation	1024-65535/tcp 1024-65535/udp	SBC Internal Interface	443	TCP Management Access

On the external interface, the SBC communicates to the SIP proxy and media processor services in the cloud. These two services have separate IP addresses in the Microsoft Cloud.

• SIP Proxy, which handles the signalling:

Source	Source Port	Destination	Destination Port	Service
52.120.0.0/14 52.112.0.0/14	1024-65535	SBC IP Address	Defined on the SBC (5061)	SIP/TLS for signalling
SBC IP Address	Defined on the SBC (5061)	52.120.0.0/14 52.112.0.0/14	5061	SIP/TLS for signalling

Media Processor, which handles media – except when Media Bypass is on:

Source	Source Port	Destination	Destination Port	Service
52.120.0.0/14 52.112.0.0/14	3478-3481 and 49152 – 53247	SBC	Defined on the SBC	UDP/SRTP
SBC	Defined on the SBC	52.120.0.0/14 52.112.0.0/14	3478-3481 and 49152 – 53247	UDP/SRTP

The deployed SBCs are also required to communicate with a SIP service provider. Organisations will be required to contact the service provider to confirm their IP addresses and the required ports.

Source	Source Port	Destination	Destination Port	Service
SIP Service Provider	Any	SBC	Defined on the SBC	UDP/SRTP
SBC	Defined on the SBC	SIP Service Provider	Any	UDP/SRTP
SIP Service Provider	5060/5061	SBC	5060/5061	SIP/TLS
SBC	5060/5061	SIP Service Provider	5060/5061	SIP/TLS

In the case of media bypass, where the clients are on the internal network, the media flows to the public IP address of the SBC. Therefore, the following rules will be required for the Teams desktop client. Media bypass is not supported by Teams web client. Therefore, the rules without media bypass must be in place to allow users with web clients to use the PSTN service.

Source	Source Port	Destination	Destination Port	Service
Local Network Subnets	50000-50039	SBC	Defined on the SBC	UDP/SRTP
SBC	Defined on the SBC	Local Network Subnets	50000-50039	UDP/SRTP

 

 

Codecs and Bandwidth

The media traffic bandwidth usage can be challenging to calculate because of the number of different variables, such as codec usage, resolution, and activity levels. Teams is always conservative on bandwidth utilisation and the bandwidth usage is a function of the codec that is used and the activity of the stream, which can vary between scenarios.

The Direct Routing interface on the leg between the Session Border Controller and Cloud Media Processor (without media bypass) or between the Teams client and the SBC (if Media Bypass enabled) can use the following codecs:

SBCs with non-media bypass: On the leg between the Cloud Media Processor and Microsoft Teams client, either SILK, G.711, G.722, or G.729 are used. The codec choice on this leg is based on Microsoft algorithms, which take into consideration multiple parameters.

Media Bypass (SBC to Teams client): With media bypass, the media is kept directly between the Teams user and the SBC. On the leg between the client and the SBC. Either SILK, G.711, G.722, or G.729 are used. Media bypass is recommended, when the users are in the same physical network/building as the deployed SBC. Media bypass is only supported for Teams desktop clients and Teams Phone devices.

Organisations deploying the SBCs can force the use of the specific codec on their SBCs by excluding undesirable codecs in the configuration.

Teams Direct Routing supports Silk, G.711, G. 722, G.729, and OPUS codecs. The peers negotiate these codecs during the call establishment process using the Session Description Protocol (SDP). Microsoft Teams preferred codec for Teams calls is the Silk codec.

Direct Routing organisations must consult their SBC model and their SIP service providers to understand what codecs are supported and can be configured.

Organisations should consider the bandwidth allocation based on the G.711 codec, which uses ~80-90 Kbps on one side of the call. To understand the bandwidth required for different codecs, see the following article.

Quality of Service

Quality of Service (QoS) in Microsoft Teams allows real-time network traffic that’s sensitive to network delays to “cut in line” in front of traffic that’s less sensitive. For QoS to be effective, organisations must apply consistent QoS settings throughout the organisation. Any part of the path that fails to support QoS priorities can degrade the quality of calls. This includes applying settings to all user PCs or devices, network switches, routers to the internet, and the Teams service.

Without some form of QoS, organisations might see the call quality issues due to jitter, packet loss, and delayed round-trip time (RTT). Organisations can consider the following marking on their network to prioritise the traffic.

Name	Use	DS Binary	DS Decimal	Port Range
EF (Expedited Forwarding)	Voice	101110	46	50000-50040
AF41 (Assured Forwarding)	Video	100010	34	58000-58040
AF31 (Assured Forwarding)	Signalling	011010	26	5060-5069
AF21 (Assured Forwarding)	App/Screen Sharing	010010	18	41000-41040

Microsoft Teams Phone System service will be using Voice and Signalling port range. The port range mentioned above for voice, video, and app sharing is configured in the NHSmail tenant.

QoS uses Windows Group Policy Objects and Port-based Access Control Lists to identify and mark all packets in real-time streams. For more details on how to implement QoS in Microsoft Teams Client, organisations can follow the details in the following articles (QoS in Teams and Implement QoS in Teams).

For organisations on the HSCN network QoS configuration change requests can be made using the below access form:

Last Reviewed Date

05/04/2023