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*.
- The South Central US datacenter, also referred to as ussouth, located in Texas.
- The West US 2 datacenter, also referred to as uswest2, located in Washington.
- The West Europe datacenter, also referred to as europewest, located in Netherlands.
- The Australia Southeast datacenter, also referred to as australiasoutheast, located in Victoria.
- 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.1Non-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.1Non-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.1Non-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.1Non-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.1Non-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.1Non-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:
- 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.
- 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.1Non-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.
Useful article Jeff thanks, one point though. Having deployed this service we had to allow a single SIP port inbound which was confirmed but Polycom as required but not in their documentation. I also had a question for you regarding the AnonymousGracePeriod which in SfBO is 90 minutes and not configurable. Have you got any info on how this has been implemented in Teams?
Thanks
Nick
Nick, I’m not sure what you are referring to but there are no inbound port requirements for video endpoints to use the service. If you are using the service with SfB Server then a proper Skype Edge Server firewall configuration is required to support federated signaling and media connections.
Also, regarding the 90 minute grace period, I’m not aware of anyway to adjust that behavior in SfB Online like it can be for SfB Server. That limitation is not applicable to Teams meetings.
Hi Jeff,
I greatly appreciate your blog. We have not moved to Teams or S4B Online yet and are currently running in Hybrid mode with S4B on Prem. We are planning to move to S4B online soon and then Teams sometime over the summer. Is there a way to call from Teams client to a Polycom VMR? Or do all meetings have to be setup as a RealConnect Meeting. Currently from a Skype Client we can dial VMR@(Trusted application pool)
Thank you,
Tom
Tom, that is not possible with Teams as it’s not a SIP-based solution like Skype for Business is. The only option is to use a CVI solution like RealConnect to bridge the video systems (or cascade a VMR) into a Teams meeting.
[…] hostname provided by the specific Microsoft partner solution which was opted for. For example, the Poly RealConnect Service utilizes the hostname "t.plcm.vc" to route all calls from standards-based endpoints to […]
Very useful Article Jeff .
My Customer has HDX7000 Poly VC endpoints with latest 3.14 firmware release and trying to share content using RC (Real Connect) service with Teams but both side content share fails.
I have asked customer to open all Real connect Gateway Public IP’s (bidirectional) using “nslookup“ command from there network for “t.plmc.vc” address as mentioned in the Poly document but it still fails !
Customer confirms that A/V call works between Poly & Teams but content share doesn’t !
Am I missing any specific IP’s range or Ports for Poly VC Gateway ?
Can network Proxy (Z Scalar) cause any issues & are there any specific guidelines around Proxy ?
Any help /pointers /links will be deeply appreciated.
Regards,
Mitesh
Content sharing issues are almost always related to firewall configurations blocking the needed port ranges, and this is most common with SIP calls as different port ranges are used for Audio/Video traffic than for content sharing streams (over BFCP). Take a look at the firewalls during the calls to see what is being blocked. I also just updated the port table in this article yesterday as I noticed that the 15001-16000 range for BFCP content sharing was not labeled correctly as it utilizes both UDP and TCP protocols.
Hi Jeff, I also noticed that the 15001-16000 range for BFCP UDP is used. Is it still true or it was a bug? BR Vlada
That shouldn’t be the case. Was that for BFCP content shared in a Skype for Business meeting or a Teams meeting?
Hi Jeff, thank you for this blog, do you have a setup guide? I’m trying to setup my RealPresence Group 500 but it’s not possible to do a Teams VC.
Thank you in advice.
If the Group Series is still SIP-registered to Skype for Business then make sure you have H.323 enabled and set as the preferred protocol for outbound video calls.
Hi Jeff, If there are multiple VTC systems in different regions (emea, apac, nala) and all call the same meeting, where is the call hosted? on the first gateway or cascaded between gateways? how does the cascade work with respect to Teams? will help if you provide a call flow. Thanks,
Each VTC is routed to a dedicated gateway resource, so each will go to the logically closest datacenter, regardless of where the Teams meeting is running. Then each gateway then connects over the Microsoft cloud to the single Teams Media Processor selected to host the meeting (which is based on proximity to the first participant to join).
Hi Jeff,
You have a link intended to show sources for RealConnect port range info (Ports and Protocols), for some reason it’s not going anywhere, you might chose to have this link there: https://rc-docs.plcm.vc/docs/prerequisites
Thank you for this blog!
Yes, the external link has changed since I posted this article.
Question.
How does the VTC information from Teams get sent to the client from PolyCom? What is the difference between Skype and Teams as far as the VTC information being sent from the server to the user when creating a meeting?
We have a situation where it works from Skype but not from Teams. We have an open ticket with Microsoft and have had this issue for over a month. It worked before with no issues at all.
I’m not sure what you are asking but the VTC information is simply included into the Skype and/or Teams meeting invitation(s). This capability is enabled differently between Skype or Teams during the initial setup, so it’s unclear if you are saying the VTC meeting details are not appearing in the Teams invites or if the VTC simply cannot connect to the Teams meeting using the provided details?
Is there a time limit that how long (e.g 30 minutes) before the Team’s meeting has been scheduled for, the VMR cascade can be established between Polycom RealConnect on RMX and MS Teams on Teams MCU?
Once the meeting is created (regardless of when it was scheduled for) it can be joined immediately by Teams clients as well as by VTC via the RealConnect service.
Update: Poly has just deployed a third instance of the RealConnect for Microsoft Teams service in the United States, located in Microsoft’s Virginia-based “East US 2” Azure data center. Note that this new instance only currently handles calls into Microsoft Teams meetings, not Skype for Business meetings.This is unique so far in that the original four deployments includes service instances for handling both Skype for Business and Teams.
Calls placed from a VTC using the service to join a Teams meeting will automatically be directed to this location by Azure Traffic Manager if it is the best suitable location at the time of the call.
Hi Jeff, we have a Polycom in our basking ridge office which is consistently being directed to the westeurope region instead of the eastus2 region. Any ideas? I would be surprised if the the westeurope region would be the lowest latency?
The latency measurement is based on where Azure Traffic Manager sees the DNS lookup come from. If the endpoint is unregistered check what it is pointing to for DNS server, but if it’s registered then DNS is handled by the registrar and not the endpoint. Azure will assume the call is coming from where the DNS request originates, so if the registrar is in a different region that could result in a less than ideal response. For example, if my X50 at home in North Carolina is registered to a registrar in California the DNS response will come from the west coast and Azure will likely offer an IP address from the West US 2 region, thus that is where my VTC’s resulting call will be routed. While rare I’ve seen latency close enough at times for calls to cross between NA, EMEA, and/or APAC regions.
On some call end region it shows “Call did not return after 302 redirect”. What is this?
It means the that VTC (or the local video registrar) was unable to handle the call redirection. This could be related to a misconfiguration on a Cisco VCS/VCS-E or unsupported firmware on a Polycom DMA/RPAD. Take a look at the logs in your firewall (for unregistered VTCs) or your registrar.
Hi Jeff,
We are having issues with outbound camera video from Trios SFB via RealConnect to Teams. We are thinking that it is an outbound port issue.
You are correct in your statement about enterprise networks not wanting to open XXXX outbound ports. The IT management wants to know what the destination addresses are. In your example, you suggest doing a NSLookup to either global, SFB, or Teams. Since we are using the SFB profile in the Trios, and utilizing Realconnect to complete a Teams video all, do we us the destination addresses for SFB or Teams?
Any input would be appreciated.
You only need to open outbound traffic to the IP addresses specifically listed in this table under the “Microsoft Teams” column: http://rc-docs.plcm.vc/docs/prerequisites#ip-addresses
Thank you sir!
You can ignore my other request. I posted the question twice.
What’s your recommendation for tagging return traffic from RealConnect? The internet strips out QoS values so these would have to be applied manually at the edge.
We seem to have intermittent video and audio lag, drops and issues. Doesn’t seem to be bandwidth congestion.
Given that the traffic is traversing the public Internet which does not support DSCP markings then the recommendation is typically not to use it. But, if you want to tag return traffic coming into your network then you could do it be source IP addresses and ports/protocols, both of which are documented here: http://rc-docs.plcm.vc/docs/prerequisites