Connectivity and Optimisation


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.

Important Note:

Local organisations considering onboarding to the NHSmail Phone System service must read through this guidance and determine local pre-requisite activities before proceeding with any form of onboarding request. This is vitally important to ensure all local network changes are understood and planned for. Without this, your quality of Teams Phone System performance may vary.

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,, 80, 443 TCP
Local client Any,, 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.


Important Note:

Direct Routing with an SBC deployed on the organisation’s corporate network or in the cloud is required to be published on the Internet for inbound and outbound traffic to/from Microsoft and the SIP service provider. To achieve this, NHSmail organisations must follow network connectivity guidelines highlighted in this document.

NHSmail Secure Boundary Consideration: The NHSmail secure boundary is an outbound egress solution designed for outbound web traffic and offers two types of traffic:

  • Bi-direction Traffic: This is traffic from within the NHS perimeter. The bi-directional is supported, only when the traffic is initiated from an internal source. There is no configuration setup to allow inbound traffic initiated by an external source as the secure boundary is an outbound egress solution.


  • Inbound (external traffic): The inbound (external) traffic on a secure boundary is only supported for targeted web applications. The applicable use cases for the Imperva WAF inbound service component of Secure Boundary, explicitly state that voice gateway traffic is not a suitable use case on secure boundary.

As mentioned above, the NHSmail secure boundary is an outbound egress solution designed for outbound web traffic, therefore publishing an SBC for inbound and outbound traffic is not a current use-case for secure boundary. Direct Connect Secure Boundary organisations most have the capability to house systems on a DMZ already and here they would just need to host SBC(s) in the same way on their existing DMZ.

Consideration for HSCN Connected Organisations: The HSCN connected organisations generally have no or little Direct Internet connectivity and use HSCN for all Internet access, options for these organisations (if deploying their SBC behind the corporate network) are likely to be that the organisations would need to stand up a new local DMZ environment with direct internet connectivity to host their own SBC(s).

NHSmail local organisations must engage network Team and/or supplier (local or CN-SP if using the HSCN network) to configure the network connectivity (public IP address to publish the SBC on internet, inbound and outbound connections) for their SBCs. Local NHSmail organisations must configure, test, and validate the network connectivity for the SBCs and the Phone System features before onboarding any live user users for the Teams telephony. It is recommended that organisations manage access to/from the Internet and their SBC(s) through their firewalling so that only those connections needed are allowed.

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

  • (primary FQDN)
  • (Secondary FQDN)
  • (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,, and – will be resolved to IP addresses from the following subnets:


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


SBC Internal Interface 1024-65535/tcp


NTP Server 123 UDP NTP
SBC External Interface 1024-65535/tcp



Global Sign CRL IPs

443 TCP Certificate CRL
Management Access workstation 1024-65535/tcp


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

1024-65535 SBC IP Address Defined on the SBC (5061) SIP/TLS for signalling
SBC IP Address Defined on the SBC (5061)

5061 SIP/TLS for signalling

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

Source Source Port Destination Destination Port Service

3478-3481 and 49152 – 53247 SBC Defined on the SBC UDP/SRTP
SBC Defined on the SBC

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
Updated on 05/04/2023

Related Articles

Need Support?
Can’t find the answer you’re looking for? Don’t worry we’re here to help!
Contact Support
back to top