Microsoft Teams call flows
Tip
Watch this session to learn how Teams leverages your network and how to plan for optimal network connectivity: Teams Network Planning.
Overview
This article describes how Teams uses Microsoft 365 call flows in various topologies. In addition, it describes unique Teams flows that are used for peer-to-peer media communication. The document describes these flows, their purpose, and their origin and termination on the network. For purposes of this article, assume the following:
Flow X is used by the on-premises client to communicate with the Microsoft 365 service in the cloud. It originates from the customer network, and it terminates as an endpoint in Microsoft 365.
Flow Y is used by the on-premises client to communicate with a service on the Internet that Microsoft 365 has a dependency on. It originates from the customer network, and it terminates as an endpoint on the Internet.
This article covers the following information:
Background. Provides background information such as networks that the flows may traverse, types of traffic, and connectivity guidance from the customer network to Microsoft 365 service endpoints. It also describes interoperability with third-party components, and principles that are used by Teams to select media flows.
Call flows in various topologies. Illustrates the use of call flows in various topologies. For each topology, the section enumerates all supported flows and illustrates how these flows are used in several use cases. For each use case, it describes the sequence and selection of flows using a flow diagram.
Teams with Express Route optimization. Describes how these flows are used when Express Route is deployed for optimization, illustrated using a simple topology.
Background
Network segments
Customer network. The network segment that you control and manage. This segment includes all customer connections within customer offices, whether wired or wireless, connections between office buildings, connections to on-premises datacenters, and your connections to Internet providers, Express Route, or any other private peering.
Typically, a customer network has several network perimeters with firewalls and/or proxy servers, which enforce your organization's security policies, and that only allow certain network traffic that you set up and configure. Because you manage this network, you have direct control over the performance of the network. We recommend that you complete network assessments to validate performance both within sites in your network and from your network to the Microsoft 365 network.
Internet. The network segment that is part of your overall network that is used by users who are connecting to Microsoft 365 from outside of the customer network. This segment is also used by some traffic from the customer network to Microsoft 365.
Visited or guest private network. The network segment outside your customer network, but not in the public Internet, that your users and their guests may visit. For example, a home private network or an enterprise private network, that does not deploy Teams, where your users and their customers that interact with Teams services may reside.
Note
Connectivity to Microsoft 365 is also applicable to these networks.
Microsoft 365. The network segment that supports Microsoft 365 services. It's distributed worldwide with edges in proximity to the customer network in most locations. Functions include Transport Relay, conferencing server, and Media Processor.
Express Route (optional). The network segment that is part of your overall network that gives you a dedicated, private connection to the Microsoft 365 network.
Types of traffic
Real-time media. Data encapsulated within Real-time Transport Protocol (RTP) that supports audio, video, and screen sharing workloads. In general, media traffic is highly latency sensitive. You want this traffic to take the most direct path possible, and to use UDP versus TCP as the transport layer protocol, which is the best transport for interactive real-time media from a quality perspective. (Note that as a last resort, media can use TCP/IP and also be tunneled within the HTTP protocol, but it isn't recommended due to bad quality implications.) RTP flow is secured using SRTP, in which only the payload is encrypted.
Signaling. The communication link between the client and server, or other clients that are used to control activities (for example, when a call is initiated), and deliver instant messages. Most signaling traffic uses the HTTPS-based REST interfaces, though in some scenarios (for example, connection between Microsoft 365 and a Session Border Controller) it uses SIP protocol. It's important to understand that this traffic is much less sensitive to latency but may cause service outages or call timeouts if latency between the endpoints exceeds several seconds.
Connectivity to Microsoft 365
Teams requires connectivity to the Internet. Teams endpoint URLs and IP address ranges are listed in Office 365 URLs and IP address ranges. Open connectivity to TCP ports 80 and 443, and to UDP ports 3478 (STUN), 3479 (Audio), 3480 (Video), and 3481 (sharing/VBSS) are required.
Teams media flows connectivity is implemented using standard IETF Interactive Connectivity Establishment (ICE) procedures.
Interoperability restrictions
Third-party media relays. A Teams media flow (that is, where one of the media endpoints is Teams) may traverse only Teams or Skype for Business native media relays. Interoperability with a third-party media relay isn't supported. (A third-party SBC on the boundary with PSTN must terminate RTP/RTCP stream, secured using SRTP, and not relay it to the next hop.)
Third-party SIP proxy servers. A Teams signaling SIP dialog with a third-party SBC and/or gateway may traverse Teams or Skype for Business native SIP proxies. Interoperability with a third-party SIP proxy isn't supported.
Third-party B2BUA (or SBC). A Teams media flow to and from the PSTN is terminated by a third-party SBC. However, interoperability with a third-party SBC within the Teams network (where a third-party SBC mediates two Teams or Skype for Business endpoints) is not supported.
Technologies that aren't recommended with Microsoft Teams
VPN network. It isn't recommended for media traffic (or flow 2'). The VPN client should use split tunneling and route Teams media traffic like any external non-VPN user, as specified in Enabling Lync media to bypass a VPN tunnel.
Note
Although the title indicates Lync, it is applicable to Teams as well.
Packet shapers. Any kind of packet snipper, packet inspection, or packet shaper devices aren't recommended for Teams media traffic and may degrade quality significantly.
Principles
There are four general principles that help you understand call flows for Microsoft Teams:
A Microsoft Teams conference is hosted by Microsoft 365 in the same region where the first participant joined. (If there are exceptions to this rule in some topologies, they're described in this document and illustrated by an appropriate call flow.)
A Teams media endpoint in Microsoft 365 is used based on media processing needs and not based on call type. (For example, a point-to-point call may use a media endpoint in the cloud to process media for transcription or recording, while a conference with two participants may not use any media endpoint in the cloud.) However, most conferences will use a media endpoint for mixing and routing purposes, allocated where the conference is hosted. The media traffic sent from a client to the media endpoint may be routed directly or use a Transport Relay in Microsoft 365 if required due to customer network firewall restrictions.
Media traffic for peer-to-peer calls takes the most direct route that is available, assuming that the call doesn't mandate a media endpoint in the cloud (see previous principle). The preferred route is direct to the remote peer (client), but if that route isn't available, then one or more Transport Relays will relay traffic. It's recommended that media traffic does not transverse servers such as packet shapers, VPN servers, and so on, since this will impact the media quality.
Signaling traffic always goes to the closest server to the user.
To learn more about the details on the media path that is chosen, see Understanding Media Flows in Microsoft Teams - BRK4016.
Call flows in various topologies
Teams topology
This topology is used by customers that leverage Teams services from the cloud without any on-premises deployment, such as Skype for Business Server or Phone System Direct Routing. In addition, the interface to Microsoft 365 is done over the Internet without Azure Express Route.
Figure 1 - Teams topology
Keep the following in mind:
- The direction of the arrows on the diagram reflect the initiation direction of the communication that affects connectivity at the enterprise perimeters. For UDP for media, the first packet(s) may flow in the reverse direction, but these packets may be blocked until packets in the other direction flow.
- Teams is deployed side by side with Skype for Business Online, hence clients are displayed as "Teams/SFB user."
You can find more information on the following optional topologies later in the article:
- Skype for Business on-premises deployment is described in Teams hybrid topology.
- Phone System Direct Routing (for PSTN connectivity) is described in Teams with Direct Routing topology.
- Express Route is described in Teams with Express Route optimization.
Flow descriptions:
- Flow 2 – Represents a flow initiated by a user on the customer network to the Internet as a part of the user's Teams experience. Examples of these flows are DNS and peer-to-peer media.
- Flow 2' – Represents a flow initiated by a remote mobile Teams user, with VPN to the customer network.
- Flow 3 – Represents a flow initiated by a remote mobile Teams user to Microsoft 365 Teams endpoints.
- Flow 4 – Represents a flow initiated by a user on the customer network to Microsoft 365 Teams endpoints.
- Flow 5 – Represents a peer-to-peer media flow between a Teams user and another Teams or Skype for Business user within the customer network.
- Flow 6 – Represents a peer-to-peer media flow between a remote mobile Teams user and another remote mobile Teams or Skype for Business user over the Internet.
Use case: One-to-one
One-to-one calls use a common model in which the caller obtain a set of candidates consisting of IP addresses/ports, including local, relay, and reflexive (public IP address of client as seen by the relay) candidates. The caller sends these candidates to the called party; the called party also obtains a similar set of candidates and sends them to the caller. STUN connectivity check messages are used to find which caller/called party media paths work, and the best working path is selected. Media (that is, RTP/RTCP packets secured using SRTP) are then sent using the selected candidate pair. The Transport relay is deployed as part of Microsoft 365.
If the local IP address/port candidates or the reflexive candidates have connectivity, then the direct path between the clients (or using a NAT) are selected for media. If the clients are both on the customer network, then the direct path should be selected. This requires direct UDP connectivity within the customer network. If the clients are both nomadic cloud users, then depending on the NAT/firewall, media may use direct connectivity.
If one client is internal on the customer network and one client is external (for example, a mobile cloud user), then it's unlikely that direct connectivity between the local or reflexive candidates is working. In this case, an option is to use one of the Transport Relay candidates from either client (for example, the internal client obtained a relay candidate from the Transport relay in Microsoft 365; the external client needs to be able to send STUN/RTP/RTCP packets to the transport relay). Another option is the internal client sends to the relay candidate obtained by the mobile cloud client. Although UDP connectivity for media is highly recommended, TCP is supported.
High-level steps:
- Teams User A resolves URL domain name (DNS) using flow 2.
- Teams User A allocates a media Relay port on Teams Transport Relay using flow 4.
- Teams User A sends "invite" with ICE candidates using flow 4 to Microsoft 365.
- Microsoft 365 sends notification to Teams User B using flow 4.
- Teams User B allocates a media Relay port on Teams Transport Relay using flow 4.
- Teams User B sends "answer" with ICE candidates using flow 4, which is forwarded back to Teams User A using Flow 4.
- Teams User A and Teams User B invoke ICE connectivity tests and the best available media path is selected (see the following diagrams for various use cases).
- Teams Users send telemetry to Microsoft 365 using flow 4.
Within customer network:
Figure 2 - Within customer network
In step 7, peer-to-peer media flow 5 is selected.
Media is bidirectional. The direction of flow 5 indicates that one side initiates the communication from a connectivity perspective, consistent with all the flows in this document. In this case, it doesn't matter which direction is used because both endpoints are within the customer network.
Customer network to external user (media relayed by Teams Transport Relay):
Figure 3 - Customer network to external user (media relayed by Teams Transport Relay)
In step 7, flow 4, from customer network to Microsoft 365, and flow 3, from remote mobile Teams user to Microsoft 365, are selected. These flows are relayed by Teams Transport Relay within Microsoft 365.
Media is bidirectional, where direction indicates which side initiates the communication from a connectivity perspective. In this case, these flows are used for signaling and media, using different transport protocols and addresses.
Customer network to external user (direct media):
Figure 4 - Customer network to external user (direct media)
In step 7, flow 2, from customer network to the Internet (client's peer), is selected.
Direct media with remote mobile user (not relayed through Microsoft 365) is optional. In other words, customer may block this path to enforce a media path through Transport Relay in Microsoft 365.
Media is bidirectional. The direction of flow 2 to remote mobile user indicates that one side initiates the communication from a connectivity perspective.
VPN user to internal user (media relayed by Teams Transport Relay)
Figure 5 - VPN user to internal user (media relayed by Teams Transport Relay)
Signaling between the VPN to the customer network is using flow 2'. Signaling between the customer network and Microsoft 365 is using flow 4. However, media bypasses the VPN and is routed using flows 3 and 4 through Teams media relay in Microsoft 365.
VPN user to internal user (direct media)
Figure 6 - VPN user to internal user (direct media)
Signaling between the VPN to the customer network is using flow 2'. Signaling between the customer network and Microsoft 365 is using flow 4. However, media bypasses the VPN and is routed using flow 2 from the customer network to the Internet.
Media is bidirectional. The direction of flow 2 to the remote mobile user indicates that one side initiates the communication from a connectivity perspective.
VPN user to external user (direct media)
Figure 7 - VPN user to external user (direct media)
Signaling between the VPN user to the customer network is using flow 2' and using flow 4 to Microsoft 365. However, media bypasses VPN and is routed using flow 6.
Media is bidirectional. The direction of flow 6 to the remote mobile user indicates that one side initiates the communication from a connectivity perspective.
Use Case: Teams to PSTN through Microsoft 365 Trunk
Microsoft 365 have a Phone System that allows placing and receiving calls from the Public Switched Telephone Network (PSTN). If the PSTN trunk is connected using the Phone System Calling Plan, then there are no special connectivity requirements for this use case. (If you want to connect your own on-premises PSTN trunk to Microsoft 365, you can use Phone System Direct Routing.)
Figure 8 - Teams to PSTN through Microsoft 365 Trunk
Use case: Teams meeting
The audio/video/screen sharing (VBSS) conferencing server is part of Microsoft 365. It has a public IP address that must be reachable from the customer network and must be reachable from a Nomadic Cloud client. Each client/endpoint needs to be able to connect to the conferencing server.
Internal clients obtain local, reflexive, and relay candidates in the same manner as described for one-to-one calls. The clients send these candidates to the conferencing server in an invite. The conferencing server doesn't use a relay since it has a publicly reachable IP address, so it responds with its local IP address candidate. The client and conferencing server check connectivity in the same manner described for one-to-one calls.
Keep the following in mind:
Teams clients can't join Skype for Business meetings, and Skype for Business clients can't join Teams meetings.
A PSTN user optionally "Dials IN" or is "Dialed OUT", depending on the meeting's organizer PSTN Calling and/or conferencing provisioning.
A guest or a customer may join from a guest private network, which is protected using FW/NAT with strict rules.
Figure 9 - Teams Meeting
Use case: Federation with Skype for Business on premises
Media relayed by Teams Transport Relay in Microsoft 365
Figure 10 - Media relayed by Teams Transport Relay in Microsoft 365
Keep the following in mind:
Federation is, by definition, a communication between two tenants. In this case, tenant A, which uses Teams, federates with tenant B, which uses Skype for Business on premises. If tenant B is also using Microsoft 365, then the Skype for Business client would have used flow 3 to connect with Microsoft 365.
Signaling and media from the federated Skype for Business client to on-premises Skype for Business Server is out of scope of this document. However, it's illustrated here for clarity.
Signaling between Teams and Skype for Business is bridged by a gateway.
Media in this case is relayed by Teams Transport Relay to the customer network and remote Skype for Business client using flow 4.
Media relayed by Skype for Business Media Relay in federated tenant
Figure 11 - Media relayed by Skype for Business Media Relay in federated tenant
Note that:
Signaling and media from the federated Skype for Business client to an on-premises Skype for Business Server is out of scope of this document. However, it's illustrated here for clarity.
Signaling between Teams and Skype for Business is bridged by a Gateway.
Media in this case is relayed by Skype for Business on-premises Media Relay to the customer network using flow 2. (Note that traffic from Teams user to the remote Media Relay in the federated customer network will be initially blocked by the Media Relay until traffic in the reverse direction starts to flow. However, the bidirectional flow will open connectivity in both directions.)
Direct (peer-to-peer)
Figure 12 - Direct (peer-to-peer)
Teams hybrid topology
This topology includes Teams with a Skype for Business on-premises deployment.
Figure 13 - Teams hybrid topology
The direction of the arrows on the diagram above reflect the initiation direction of the communication that affects connectivity at the enterprise perimeters. In the case of UDP for media, the first packet(s) may flow in the reverse direction, but these packets may be blocked until packets in the other direction flow.
Teams is deployed side by side with Skype for Business Online, hence clients are displayed as "Teams/SFB user."
Additional flow (on top of Teams topology):
- Flow 5A – Represents a peer-to-peer media flow between a Teams user within the customer network and a Skype for Business on-premises media relay at the customer network edge.
Use case: Teams to Skype for Business one-to-one
Hybrid within the customer network
Figure 14 - Hybrid within customer network
Signaling between Teams and Skype for Business is bridged by a gateway. However, media is routed directly peer-to-peer within the customer network using flow 5.
Hybrid customer network with external Skype for Business user – relayed by Microsoft 365
Figure 15 - Hybrid customer network with external Skype for Business user - relayed by Microsoft 365
Note that:
Signaling and media from the Skype for Business client to an on-premises Skype for Business Server is out of scope of this document. However, it is illustrated here for clarity.
Signaling between Teams and Skype for Business is bridged by a gateway.
Media is relayed through Teams Transport Relay to the customer network through flow 4.
Hybrid customer network with external Skype for Business user – relayed by on-premises Edge
Figure 16 - Hybrid customer network with external Skype for Business user - relayed by on-premises Edge
Note that:
Signaling and media from Skype for Business client to an on-premises Skype for Business Server is out of scope of this document. However, it is illustrated here for clarity.
Signaling is bridged by a gateway.
Media is relayed by Skype for Business Media Relay within Skype for Business on-premises Edge to Teams user within the customer network using media flow 5A.
Teams with Phone System Direct Routing topology
This topology includes Teams with Phone System Direct Routing.
Direct Routing enables you to use a third-party Public Switched Telephone Network (PSTN) service provider by pairing a supported on-premises customer-owned Session Border Controller (SBC) hardware device to Microsoft 365, and then connecting the telephony trunk to that device.
To support this scenario, the customer must deploy a certified SBC for Direct Routing from one of Microsoft's certified partners. The SBC must be configured as recommended by the vendor, and be routable from Microsoft 365 for direct UDP traffic. The media may flow directly from Teams and/or the Skype for Business client to the SBC (bypassing the Teams gateway) or traverse through the Teams gateway. The connectivity with the SBC, when the trunk is configured to bypass the Teams gateway, is based on ICE, where SBC supports ICE-Lite, while the Teams/Skype for Business media endpoint supports ICE Full Form.
*Figure 17 - Teams with Phone System Direct Routing topology
Note that:
The direction of the arrows on the diagram above reflect the initiation direction of the communication that affects connectivity at the enterprise perimeters. In the case of UDP for media, the first packet(s) may flow in the reverse direction, but these packets may be blocked until packets in the other direction will flow.
Teams is deployed side by side with Skype for Business Online, hence clients are displayed as "Teams/SFB user."
Additional flows (on top of Teams online topology):
- Flow 4' - Represents a flow from Microsoft 365 to the customer network, used to establish a connection between the Teams media server in the cloud with the SBC on premises.
- Flow 5B – Represents a media flow between the Teams user within the customer network with the Direct Routing SBC in bypass mode.
- Flow 5C – Represents a media flow between the Direct Routing SBC to another Direct Routing SBC in a PSTN hairpin call bypass mode.
Internal user with Direct Routing (media relayed by Teams Transport Relay)
Figure 18 - Internal user with Direct Routing (media relayed by Teams Transport Relay)
Note that:
The SBC must have a public IP address that is routable from Microsoft 365.
Signaling and media from the SBC to Microsoft 365 and vice versa use flow 4 and/or flow 4'.
Signaling and media from the client within the customer network to Microsoft 365 use flow 4.
Remote user with Direct Routing (media is routed through a media server (MP))
Figure 19 - Remote user with Direct Routing (media is routed through a media server (MP))
Note that:
The SBC must have a public IP address that is routable from Microsoft 365.
Signaling and media from the SBC to Microsoft 365 and vice versa use flow 4 and/or flow 4'.
Signaling and media from the client on the Internet to Microsoft 365 use flow 3.
Internal user Direct Routing (media bypass)
Figure 20 - Internal user Direct Routing (media bypass)
Note that:
The SBC must have a public IP address that is routable from Microsoft 365.
Signaling from SBC to Microsoft 365 and vice versa use flow 4 and/or flow 4'.
Signaling from client within the customer network to Microsoft 365 use flow 4.
Media from client within the customer network to SBC within the customer network use flow 5B.
Remote user with Direct Routing (media bypass relayed by Teams Transport Relay)
Figure 21 - Remote user with Direct Routing (media bypass relayed by Teams Transport Relay)
Note that:
The SBC must have a public IP address that is routable from Microsoft 365 and Internet.
Signaling from the SBC to Microsoft 365 and vice versa uses flow 4 and/or flow 4'.
Signaling from the client on the Internet to Microsoft 365 uses flow 3.
Media from the client on the Internet to the SBC within the customer network uses flows 3 and 4, relayed by Teams Transport Relay.
Remote user Direct Routing (media bypass direct)
Figure 22 - Remote user Direct Routing (media bypass direct)
Note that:
The SBC must have a public IP address that is routable from Microsoft 365 and the Internet.
Signaling from the SBC to Microsoft 365 and vice versa uses flow 4 and/or flow 4'.
Signaling from the client on the Internet to Microsoft 365 uses flow 3.
Media from the client on the Internet to the SBC within the customer network uses flow 2.
Direct Routing (media bypass) – PSTN hairpin call (due to call forward/transfer)
Figure 23 - Direct Routing (media bypass) - PSTN hairpin call (due to call forward/transfer)
Note that:
The SBC must have a public IP address that is routable from Microsoft 365.
Signaling from the SBC to Microsoft 365 and vice versa uses flow 4 and/or flow 4'.
The client is out of the signaling and media loop after the call is hairpinned from PSTN to PSTN.
Media from SBC instance A within the customer network to SBC instance B within the customer network (where, A and B can be the same instance) uses flow 5C.
Direct Routing (media through Microsoft 365) – PSTN hairpin call across two tenants
Figure 24 - Direct Routing (media through Microsoft 365) – PSTN hairpin call across two tenants
Note that:
The SBC must have a public IP address that is routable from Microsoft 365.
Signaling from the SBC to Microsoft 365 and vice versa uses flow 4 and/or flow 4'.
The client is out of the signaling and media loop after the call is hairpinned from PSTN to PSTN.
Media from SBC instance A within the customer network X to SBC instance B must be relayed through the Microsoft 365 Media Server and can't use bypass mode.
Teams with Express Route optimization
Figure 25 - Teams with Express Route optimization
In the case that Express Route is justified and deployed, then Teams flows could be re-routed from flow 4 to flow 1 and from flow 4' to flow 1'. However, the Teams application has a hard dependency on other Microsoft 365 flows over the Internet using flows 4 and 4'; hence these flows must not be blocked.
Note that Skype for Business hybrid Edge traffic is routed to the Internet and not to Express Route to communicate with external users and federate with other tenants.
To prevent asymmetrical flows, re-routing must be in both directions. In other words, an address within the customer network is routable either through Internet or Express Route, based on optimization, but not through both.
Customer network to external user (media relayed by Teams Transport Relay):
Figure 26 - Customer network to external user (media relayed by Teams Transport Relay)
High-Level Steps:
- Teams User within customer network resolves URL domain name (DNS) using flow2.
- Teams User within customer network allocates a media Relay port on Teams Transport Relay using flow 1.
- Teams User within customer network sends "invite" with ICE candidates using flow 1 to Microsoft 365.
- Microsoft 365 sends notification to external Teams user using flow 3.
- Teams external user allocates a media Relay port on Teams Transport Relay using flow 3.
- Teams external user sends "answer" with ICE candidates using flow 3, which is forwarded back to Teams user A using Flow 1.
- Teams User A and Teams User B invoke ICE connectivity tests and selects flows 1 and 3, which are relayed by Teams Transport Relay.
- Teams Users send telemetry to Microsoft 365 using flows 1 and 3.
Note
Flow 4 must be enabled to support dependencies of Teams application on other micro-services that mandates flow 4.
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for