Multiple recent articles covering Cloud Video Interop for Microsoft Skype for Business and Teams meetings have introduced several Polycom services which are all resident in Microsoft’s Azure cloud.  When leveraging these services it may not be clear as to exactly where they are hosted and what are the best practices for connecting to them effectively and securely.   This article will outline the related services and where they reside with generic firewall guidance.

Service Overview

The core interoperability service addresses a simple, singular purpose: to receive inbound calls over either SIP or H.323 protocols from any standards-based Video TeleConferencing (VTC) system capable of communicating with Microsoft Azure datacenters, and then connect those calls into a Skype for Business or Microsoft Teams Multipoint Control Unit (MCU).  This traffic can be routed over the Internet or optionally via an established and correctly configured Express Route connection.  The service is comprised of several different pools of resources covering a variety of tasks, but the primary concepts are the perimeter load balancers which handle the initial inbound calls and the multiple pools of transcoding gateways which will handle the actual video calls.

In reality the RealConnect service today is actually two side-by-side solutions which are essentially identical in both deployment and overall operation.  Because of the vast difference in the Skype for Business and Microsoft Teams platforms it is not possible to use the exact same set of cloud resources to provide video interoperability into both types of meetings.  Thus two separate solutions are provided within the same service offering: one to provide interoperability into Skype Meetings hosted by Skype for Business Online and Skype for Business Server and another to provide interoperability into Microsoft Teams meetings.

Basic Architecture

The following diagrams are over-simplistic representations of the services as they are intended to highlight just a few simple concepts: communication routing and call redirection.  The RealConnect Service only answers calls from endpoints using standards-based signaling protocols SIP and H.323 negotiates media session over standards-based media codecs like H.264 Advanced Video Coding (AVC) and H.239 or BFCP content sharing, for example.

Skype for Business only deals with its native clients and devices which speak the Microsoft implementation of SIP signaling (MS-SIP) and handle Microsoft implementations of media codecs like H.264 SVC (X-H264UC), RealTime Video (RTV), Remote Desktop Sharing (RDP) and Video-based Screen Sharing (VBSS).

• Communications between the RealConnect service gateways and Skype for Business Online are contained within the Microsoft Azure datacenter network.

• Communications between the RealConnect service gateways and Skype for Business Server deployments are between the Azure datacenters and location of the Skype for Business Front End servers, using deployed Edge servers if applicable.

The Microsoft Teams platform directly handles a simpler list of native clients, devices, and protocols.  While SIP has been replaced by MNP24 as the primary signaling protocol, some of the same media codecs have been borrowed from Skype for Business like SVC for video and VBSS for desktop and application sharing.

A regional load-balanced IP address serves as the ingress for a call.  The gateways handle the majority of the heavy lifting by performing actual translation and transcoding between the various standards-based systems and the Skype for Business and Microsoft Teams systems.

• The initial call from a VTC is first routed to a load balancer in the the logically closest datacenter based on latency at the time of the call.

• The load balancer immediately responses to the inbound call by redirecting the VTC at an available gateway in the same datacenter, if available.  If the pools in the same datacenter are not able to handle the call (e.g. offline or at-capacity) then an available pool in the next closest datacenter will be offered.

• Once the call is established on a dedicated gateway in Azure that gateway will then communicate with the Skype or Teams platform to join the meeting and handle translation and transcoding of the signaling and media.

For the service to be reachable by VTCs which are typically located within an enterprise network behind one or more firewalls then outbound traffic over specific ports must be allowed to reach the various load balancers and gateways deployed world-wide.  Given this inherent level of availability and resiliency it is important to allow outbound traffic to all locations.  If traffic is only allowed to geographically-close datacenters then in the event of a partial service outage a call redirected to another datacenter may be blocked.

Locations

At the time this article was originally posted there were four worldwide Azure regions which host the RealConnect Service, but more recently a fifth region has been added.  There are separate sets of load balancers and gateways specific to connecting into Skype for Business meetings than for connecting into Microsoft Teams meetings, but both sets are deployed side-by-side in the the same Azure datacenters today with one exception*.

1. The South Central US datacenter, also referred to as ussouth, located in Texas.
2. The West US 2 datacenter, also referred to as uswest2, located in Washington.
3. The West Europe datacenter, also referred to as europewest, located in Netherlands.
4. The Australia Southeast datacenter, also referred to as australiasoutheast, located in Victoria.
5. The East US 2 datacenter, also referred to as useast2, located in Virginia. (*This installation only supports Teams.)

As pointed out earlier, the initial connection into the service will be directed to the best available resource at the time.  This determination is made by measuring latency and then providing a DNS response pointing to the appropriate load balancer.  The Azure Speed Test site can be used as a handy reference for displaying live network latency statistics from a specific location to any of these datacenters.  At this point in time the South Central US location will likely be where any calls placed from this location will be directed to, but with an average latency that close then it could be either of the U.S. locations at any given time.

Connectivity

As previously stated, the RealConnect service currently exists as two side-by-side deployments to handle calls into either a Skype for Business or Microsoft Teams meeting.  There is no mixing of these conferencing platforms and each is driven by unique Outlook meeting invitations.  So what is essentially a single service includes separate ingress points for Skype and Teams purposes.  This can be demonstrated by performing simple nslookup commands on the three different Fully Qualified Domain Names (FQDN) used today: v.plcm.vc, h.plcm.vc, and t.plcm.vc.

• Perform a nslookup against the FQDN used to join Skype for Business Online meetings: v.plcm.vc

C:\>nslookup v.plcm.vc
Server:   UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:     jazz-prod-scus.plcm.vc
Address:  13.85.8.48
Aliases:  v.plcm.vc
prod-plcm.trafficmanager.net

• Perform a nslookup against the FQDN used to join Skype for Business Server meetings: h.plcm.vc

C:\>nslookup h.plcm.vc
Server:   UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:     jazz-prod-scus.plcm.vc
Address:  13.85.8.48
Aliases:  h.plcm.vc
prod-plcm.trafficmanager.net

• Perform a nslookup against the FQDN used to join Microsoft Teams meetings: t.plcm.vc

C:\>nslookup t.plcm.vc
Server:   UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:     teams-prod-scus.plcm.vc
Address:  23.100.126.112
Aliases:  t.plcm.vc
prod-plcm-teams.trafficmanager.net

These results indicate that the Skype for Business platforms (Online and Server) use the same destination IP, while Teams uses a different IP.  This underscores the two separate deployments in the same service: one for Skype meetings and one for Teams meetings.

Note that the resolved IP addresses may not match those shown above as these lookups were run a computer in central North America.  Attempts to resolve these FQDNs in other parts of the world will likely return different results, indicating the global nature of the services availability.

Network Communications

In an environment configured to allow the required standards-based traffic outbound to any destination on the Internet this service will function as designed without any additional configuration.  The availability and resiliency are automatic.  But in many enterprise networks some or all of the required firewall ports may not be opened, and thus an understanding of what traffic needs to go where can help when configuring firewall policies

Ports and Protocols

These required ports and protocols are listed in this table in the RealConnect Service documentation.  To support calls on both signaling protocols simply allow traffic outbound to all of the following destination ports.

If planning to only support one protocol then note the overlap in the center of the table where SIP and H.323 calls will share the same range or ports for most, but not all potential media session.  For H.323 calls all outbound media (audio, video, and H.239 content sharing) will utilize destination ports in the 20002-30001 UDP range.  For SIP calls that same port range can be used for audio and video, but content sharing using Binary Floor Control Protocol (BFCP) will need to be able to reach destination ports in the service over the 15001-16000 UDP range.

Destinations

Now that the types of traffic and destination ports are known the next obvious step is where to allow this traffic traverse.  The simple option is to allow this traffic outbound from any trusted network to the public Internet.  Doing this will allow calls to always reach the service, regardless of the resolved and referred addresses.  But more commonly enterprise networks are not this open and require defined subnetworks or small ranges of IP addresses to be configured on firewalls.

Polycom has provided a simple way to query for the active IP addresses utilized by the service in the event that outbound traffic cannot be allowed from an enterprise network out to to any destination on the Internet.  Instead of adding the several hundred different subnetworks used in the global Azure datacenter network a list of about 20 IP address can be configured.  Given that these services are spread out over a large area and Azure datacenters contain hundreds of discontiguous subnets it is not really worth the effort of defining the subnetwork as almost every IP address at this moment is in a different subnet.

Make sure to actually perform the nslookup commands as guided and use the real-time results.  Do not use the actual list of IP addresses shown in this article as some will likely change and new addresses may be added as the service grows.  The examples below will not be updated to reflect future changes.

If the RealConnect service will be used for joining both Skype for Business and Team meetings then all IPs for both deployments in the service should be configured as allowed destinations in a firewall policy.    (The following results has been colored-coded to indicate which portion of the service each belongs to for illustrative purposes.)

• To locate all IP addresses in all regions used for Skype for Business and Microsoft Teams solutions simply perform an nslookup against edge-global.plcm.vc.

C:\>nslookup edge-global.plcm.vc
Server:   UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:      edge-global.plcm.vc
Addresses: 104.45.16.73
13.77.5.248
40.127.74.66
23.101.236.249
104.214.224.168
23.100.126.112
40.91.214.133
13.85.8.48
40.127.71.243
52.191.165.159
13.66.242.170
40.124.6.108
52.171.141.90
13.66.206.244
13.77.56.231
23.101.74.190
104.40.177.169
13.66.192.127
40.127.69.62
52.178.95.62
104.215.77.58
13.70.181.113
13.80.96.87
13.77.175.139
13.65.254.254
52.178.95.48
52.246.253.13

The response above is essentially a concatenated list of both deployments.  Alternatively firewall access lists can be limited to allow outbound traffic to only the IP addresses associated with the desired conferencing platform.  The following FQDNs can be used to identify the Skype half of the service from the Teams half.

• If only Skype for Business meetings will be supported, then use only the subset of IP addresses returned for edge-sfb.plcm.vc.

C:\>nslookup edge-sfb.plcm.vc
Server:   UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:      edge-sfb.plcm.vc
Addresses: 52.178.95.48
104.40.177.169
13.66.192.127
52.246.253.13
52.178.95.62
13.65.254.254
23.101.236.249
40.91.214.133
13.85.8.48
13.66.242.170
13.77.5.248
52.171.141.90
13.70.181.113

• If only Microsoft Teams meetings will be supported, then use only the subset of IP addresses returned for edge-teams.plcm.vc.

C:\>nslookup edge-teams.plcm.vc
Server:   UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:      edge-teams.plcm.vc
Addresses: 13.80.96.87
23.101.74.190
13.77.56.231
13.77.175.139
104.45.16.73
40.127.74.66
40.127.69.62
52.191.165.159
23.100.126.112
40.127.71.243
104.214.224.168
40.124.6.108
13.66.206.244
104.215.77.58

Any firewall policies created to control traffic via destination cannot actual use any FQDNs outlined in this article, only the actual IP addresses (or their subnets) can be used.  There are two different reasons for this:

1. The FQDNs used to place calls (e.g. *.plcm.vc) are only leveraged in the initial call to reach the regional load balancer.  As mentioned earlier and demonstrated in the next section the call redirection process will attempt a connection to a referred IP address which would not match a rule configured for only the domain name.  The gateways in the service do not even have defined FQDNs, and would not matter if they did as the redirection process does not leverage DNS.
2. The FQDNs used to list the IP addresses (e.g. edge-*.plcm.vc) are only for reference and no calls are ever placed using these.  Thus adding them to a firewall policy would serve no functional purpose.

Additionally it is common for firewall configurations to not allow the use of domain names for egress traffic, either by solution limitation or corporate policy.  This mainly has to do with the insecurity inherent in DNS where the name resolution process can easily be spoofed.

Example Call

This section will walk through placing a SIP call from a VTC (Polycom Group Series 500) to a Microsoft Teams meeting in order to demonstrate the call handling.  Additionally the behavior will be dissected to explain what is happening in each step.  The following SIP messages are trimmed down to only show the pertinent information, and the test call was placed over TCP for easy access to the logs.  Normally these calls would be placed over TLS in ensure that the signaling traffic is encrypted over the Internet.

• A SIP call is placed to 000000.116058723@t.plcm.vc which is used to join the Teams meeting call directly.  This was placed manually but is the exact same dial string used when selecting the ‘Join’ button on the calendar invite.

• The endpoint will resolve the domain t.plcm.vc using DNS and receive an IP address from Azure Traffic Manager based on the Performance Traffic-Routing method.  This measures the latency between the endpoint and each Azure datacenter hosting Polycom RealConnect services to determine the best location to route the call.

C:\>nslookup t.plcm.vc
Server:   UnKnown
Address:  192.168.1.1

Non-authoritative answer:
Name:     teams-prod-scus.plcm.vc
Address:  23.100.126.112
Aliases:  t.plcm.vc
prod-plcm-teams.trafficmanager.net

The endpoint in this example is located in Chicago and the returned IP address of 23.100.126.112 would likely be from a US-based Azure datacenter, but it does not have to be.  To determine which datacenter the call is being directed to there are few clues in the response.  Firstly, the DNS A Name record returned for that IP address includes “scus” which is short-hand for South Central United States, which incidentally was the site with the lowest recorded latency shown earlier in this article.

This is an assumption though based on the name, so it would be better to confirm by reviewing the latest version of the Microsoft Azure Datacenter IP Ranges documentation.  By downloading the XML file and searching for a match against that IP there is currently only one possible subnet which could contain that IP address: 23.100.120.0/21.  (For addresses with multiple matches a simple subnet calculator can be used to determine the correct subnet for the desired IP address.)  In the XML file the 23.100.120.0/21 subnet is listed under the ussouth region, indicating which region that IP address is currently assigned.  (Microsoft updates this documentation often as the subnets and locations do change over time, so it is possible that the IP address in this example does not appear in the same region at some point in the future.)

• Now that the endpoint has a destination address to connect to it will establish an outbound TCP connection to the resolved IP address and if successful will send a SIP INVITE message sent to the SIP address.  (The SDP information included in the invitation denotes the internal IP address of the endpoint.)

|>>- SEND OVER [TCP] MSG -> NET   2217 bytes  to 23.100.126.112[:5060] sock 101——–>>|
INVITE sip:680450644.114347572@t.plcm.vc SIP/2.0
Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166153661-1012
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,COMET,OPTIONS,SUBSCRIBE,NOTIFY,MESSAGE,REFER,REGISTER,UPDATE
From: sip:192.168.1.163;tag=plcm_1166153715-1012;epid=82170146F81DCV
To: <sip:680450644.114347572@t.plcm.vc>
Call-ID: 1166153290-1012
CSeq: 1 INVITE
User-Agent:PolycomRealPresenceGroup500/6.2.0
Content-Type: application/sdp
o=GroupSeries 1140207171 0 IN IP4 192.168.1.163
c=IN IP4 192.168.1.163

• • The endpoint receives an informational 100 TRYING response from the server.  Note the external public IP (22.33.44.55) of the endpoint network address translation has been changed in this article to hide the actual public IP used during the call..

|<<- RECV OVER [TCP] MSG <- NET   301 bytes  from 23.100.126.112[:5060] sock 101 ——–<<|
SIP/2.0 100 Trying
CSeq: 1 INVITE
Call-ID: 1166153290-1012
From: <sip:192.168.1.163>;tag=plcm_1166153715-1012;epid=82170146F81DCV
To: <sip:680450644.114347572@t.plcm.vc>
Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166153661-1012;received=22.33.44.55;rport=38955

• The endpoint also receives a redirection from the server in the form of a 302 MOVED TEMPORARILY response.  This instructs the endpoint to place a new call to the address provided in the Contact field.

|<<- RECV OVER [TCP] MSG <- NET   452 bytes  from 23.100.126.112[:5060] sock 101 ——–<<|
SIP/2.0 302 Moved Temporarily
CSeq: 1 INVITE
Call-ID: 1166153290-1012
From: <sip:192.168.1.163>;tag=plcm_1166153715-1012;epid=82170146F81DCV
To: <sip:680450644.114347572@t.plcm.vc>;tag=3c2129ac
Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166153661-1012;received=22.33.44.55;rport=38955
Contact: <sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58:5060;transport=tcp>;expires=15

As seen above, the new call has an updated SIP address including a new destination located at 104.215.77.58.  What has happened here is that the initial call resolved to the single load-balanced IP address for the entire region (in this case ussouth).  Once the call is accepted the load balancer will redirect the endpoint to another load-balanced IP address which sits in front of the pool of gateways.  Thus the initial call is connecting to a server which only handles SIP and H.323 signaling protocols.  Note that while in most cases the referred address will be in the same datacenter as the original connection, it is possible for the endpoint to be redirected to a different data center to complete the call.  This could occur in the event of a partial service outage, for example.  This is why it is important to configure premises firewalls to correctly handle outbound VTC traffic for both signaling and media communications to all possible destinations in all available datacenters, and not just those in the same region as the endpoints are located.

• The endpoint transmits an Acknowledgement (ACK) message to let the server know that it received and understood the redirection command.  This will be the last SIP message to use the current Call-ID value.

ACK sip:680450644.114347572@t.plcm.vc SIP/2.0
Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166153661-1012
From: sip:192.168.1.163;tag=plcm_1166153715-1012;epid=82170146F81DCV
To: <sip:680450644.114347572@t.plcm.vc>;tag=3c2129ac
Call-ID: 1166153290-1012
CSeq: 1 ACK

• At this point the endpoint opens a new TCP connection to the referred IP address and sends a new SIP INVITE with a new SIP address, complete with a new Call-ID value.  It is important to note that the new call is using an IP address instead of the domain name in the original call.  This underscores the need to define any destination hosts via IP and not by domain names in firewall policies.

|>>- SEND OVER [TCP] MSG -> NET   2293 bytes  to 104.215.77.58[:5060] sock 101——–>>|
INVITE sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58 SIP/2.0
Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166557684-1012
From: sip:192.168.1.163;tag=plcm_1166557738-1012;epid=82170146F81DCV
To: <sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58>
Call-ID: 1166557282-1012
CSeq: 1 INVITE
User-Agent:PolycomRealPresenceGroup500/6.2.0
o=GroupSeries 1873749625 0 IN IP4 192.168.1.163
c=IN IP4 192.168.1.163

• The endpoint receives a standard 180 RINGING response from the server.  (Depending on factors like latency and loads a 100 TRYING message may also be received prior to the Ringing response.)

|<<- RECV OVER [TCP] MSG <- NET   568 bytes  from 104.215.77.58[:5060] sock 101 ——–<<|
SIP/2.0 180 Ringing
To: <sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58>;tag=8B02E52E-20DFDF35
Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166557684-1012;received=22.33.44.55;rport=33779
CSeq: 1 INVITE
Call-ID: 1166557282-1012
From: <sip:192.168.1.163>;tag=plcm_1166557738-1012;epid=82170146F81DCV
User-Agent: Polycom Teams Gateway_00/master-85176_8032-2111-2142-6362-9349-7552-48

Note that the User-Agent field is now included in responses from the server, indicating that this is call into the Microsoft Teams service. (Calls into the Skype for Business service will be identified with “Polycom/Polycom Soft MCU” as the User-Agent value.)

• The endpoint receives a 200 OK message from the server along with the server’s SDP information to begin establishing the media sessions.

|<<- RECV OVER [TCP] MSG <- NET   2114 bytes  from 104.215.77.58[:5060] sock 101 ——–<<|
SIP/2.0 200 OK
To: <sip:680450644.114347572-dd80d7cd7c09a20e-2a8a2888be675193@104.215.77.58>;tag=8B02E52E-20DFDF35
Via: SIP/2.0/TCP 192.168.1.163:5060;branch=z9hG4bK1166557684-1012;received=22.33.44.55;rport=33779
CSeq: 1 INVITE
Call-ID: 1166557282-1012
From: <sip:192.168.1.163>;tag=plcm_1166557738-1012;epid=82170146F81DCV
Content-Type: application/sdp
User-Agent: Polycom Teams Gateway_00/master-85176_8032-2111-2142-6362-9349-7552-48
o=- 1551111425 1551111425 IN IP4 172.30.0.24
s=Polycom Teams Gateway
c=IN IP4 104.215.77.58

At this point it is common to see additional ACK, INVITE, TRYING, RINGING, and OK messages as the call negotiates.  Sometimes this can occur quickly and other times a handful of seemingly redundant messages will flow between the endpoint and server as call and media negotiations are attempted, but the initial redirection will always occur first.