RealConnect Usage Reporting

January 26, 2020 by Jeff Schertz · 6 Comments

In September of last year Poly released a new reporting capability, RealConnect Tenant Report, which is available to all RealConnect Service customers. It includes a customizable dashboard of tiles which provide critical usage stats, helpful charts and graphs to indicate things like historical concurrency numbers or average call duration, and the ability to view and export individual call details.

The data included in this reporting portal is only gathered from calls placed by standards-based SIP and H.323 endpoints to the RealConnect Service, which in turn bridges the call into a Microsoft Teams or Skype for Business meeting. Details related to native Microsoft clients and devices, as well as PSTN attendees in these same meetings can be found in Microsoft reporting tools like the Microsoft Teams activity reports.

Accessing the Portal

While the back-end reporting system is part of the primary Poly Cloud Services (PCS) administration portal, the RealConnect Tenant Report portal was previously only accessible by going directly to: https://rc-reports.plcm.vc. Recently though the various Poly service portals have been more closely integrated and the reporting portal is now available from within the primary administration portal: https://console.plcm.cloud. This provides a single sign on and single entry point to access the various administration and management utilities for the RealConnect Service as well as some other Poly cloud service offerings.

In order to access the reports an account must be granted permissions first. By default a primary contact email address would have been provided to Poly during the original order of RealConnect licenses. That contact would have automatically been sent an invitation email to activate their account.

Activate Initial Account

This portion can be skipped if access to PCS has already been activated for the initial administrator. If not, then locate the email entitled Welcome to Polycom Cloud Service Administration which would have been sent from the address cloud-service-team@polycom around the time of the initial RealConnect license order. The Activate Your Account button in the message body can be used to activate the account. (The “No account? Create one” link on the PCS portal is not applicable here and cannot be used to request an account. If an the account is unknown or the invitation email cannot be located then contact Poly for additional assistance accessing your tenant.)

The initial administrator account can be used to access the reporting portal, but the minimum requirements are the User Role called Device Operator. To grant reporting access to other users in your organization simply adding a new user in the PCS portal under Administration > Users and grant the Device Operator role. The user will automatically receive an invitation email to the provided email account.

The RealConnect Report tile on the Poly Cloud Services home page can be used to access the reporting portal.

If that tile does not appear as a choice in the menu then simply go to https://rc-reports.plcm.vc to access the site directly.

Dashboard

The portal menu is comprised of two main sections: Dashboard and Calls. (The RealConnect Invite Add-In menu can be ignored as it has nothing to do with the reporting portal and is simply a download link for a scheduling plug-in available for the service. This may be relocated to a different Poly website at some point.)

Once signed into the portal the main Dashboard page will appear which by default display information based on the last 7 days of activity. The drop-down menu in the upper left corner of the dashboard can be used to select the displayed time frame among the following options: Today, 24 Hours, Week, Month, Three Months, Six Months, and Year.

Call Summary

Among the available widgets the most helpful when starting to troubleshooting call connection failures can be the Call End Reason and Active Calls Over Time chart.

On the Call End Reasons pie chart the value “VTC ended call” should be the most common event, which simply indicates that something other than the service ended the call. This most often is someone in the conference room simply hanging up the call, but this result could also include unintended disconnections caused by either the endpoint or transversal solutions like video registrars and corporate firewalls. Other common values are “Failed getting meeting info” which could represent an incorrectly formatted call string, or “Meeting not found” which is usually when someone enters an incorrect or expired VTC conference ID in the call string or when prompted at the service’s entry queue.

The Active Calls Over Time graph shows two sets of overlaid data points: “Total Joined” which is an aggregate number of all successful endpoint connections across all meetings for the data point on the graph, and “Max Concurrent” which is the maximum level of concurrent connections allowed into the service for all of the tenant’s meetings which may be active at that time. Clicking on the name of either value in the legend will hide/show that data line on the graph, which is helpful in rescaling the Call Count axis on the chart to better view one value over the other.

Call Concurrency

As the service is licensed on call concurrency then understanding how calls are accepted and rejected due to license availability is critical.

There are 3 important metrics to understand which are related to call acceptance behavior during maximum concurrency events:

License Overage: The total number of calls attempted during a time when all available concurrency licenses are already in use.

Rejected Calls: The total number of calls rejected for lack of an available license at that time.

Surged Calls: The total number of calls which were allowed to join the meeting in spite of license capacity being reached.

The first two items are self-explanatory but Surged Calls warrants some additional detail. The RealConnect Service includes a feature called “Soft Ceiling” which means that when a tenant’s license capacity has been reached the service will still allow calls to connect for up to an additional 50% of the existing license capacity. Thus, if a tenant has purchased 50 licenses then their true ‘hard ceiling is actually 75 concurrent calls (50+25). In this example allowed call attempts while the current concurrency count is between 50 and 75 will be recorded as Surged Calls. And call attempts placed when above 75 will be rejected and recorded as Rejected Calls.

The one caveat to be aware of though is that this soft ceiling feature is only available for customers with 6 or more RealConnect licenses activated in their tenant. Free trials of 5 concurrent licenses or customer receiving or purchasing 5 licenses or fewer will not have a soft ceiling, meaning the maximum call concurrency will be equal to the number of licenses owned. In this example calls placed while the tenant is a maximum concurrency will be rejected and recorded as Rejected Calls.

The data points on the chart indicate a scope of time, from as little as 1 hour (when viewing data for only a day) to as much as an entire day (when viewing data for a year). This explains why a single plot point on the chart can indicate a Max Concurrent value of 4 when the Total Joined value on the same vertical axis can read as 24 and yet no surged or rejected calls are reported. In a data set for as little as an hour it is possible for several meetings to have occurred with multiple endpoints joining and then hanging up, all without ever reaching maximum concurrency and triggering a license overage event.

Devices

The Devices Pie and Devices Bar charts include categories for each manufacturer based on the names provides in the User Agent strings, which most often identifies the endpoint itself but could actually be based on the type of on-premises video infrastructure used to route the call to the service (e.g. Polycom or Cisco).

Conferences

The Top Conferences and Call Duration charts provide a glance at the most attended meetings and how those meetings stack up against all other meetings in terms of duration. Note that Call Duration is not a measurement of the length of the overall Skype or Teams meeting, but simply the length of time a VTC stays connected for each call into the service. The example data below indicates that the majority of calls are roughly 30 minutes to one hour long.

Customization

Any of the several widgets on the dashboard can be hidden or rearranged by clicking the Edit button at the top of the dashboard view. For example another column can be created by dragging widgets like License Overage, Rejected Calls, and Surged Calls up from the bottom of the view. Placing these next to the Active Calls Over Time graph makes it easy to see this information without scrolling the screen up and down.

Calls

The Calls menu includes additional views into the available call data with a summary page that is very similar to the dashboard view, a graphical map which displays where calls are originating from, and an exportable list of individual call attempts which can be used for additional troubleshooting. All of these views, like the dashboard, can be toggled between the available time frame options from a day to a year.

Summary

This view is similar to the dashboard as it provides a simple view for quickly scanning general statistics. It contains a fixed subset of the total available widgets though so it is a bit redundant to the dashboard.

Map

An interactive map provides geographical totals indicating the source location of calls placed in the selected time frame. For congested areas the bubbles can be clicked to zoon the map in for a closer look at the region.

List

Other than the dashboard this is where most time will likely be spent in the portal: looking at individual call detail records. The default view displays every call, successful or not, which has been attempted into join either a Skype for Business or Teams meeting hosted by that tenant. Calls placed into either the entry queue (<TenantKey>@*.plcm.vc) or directly into a meeting (<TenantKey>.<ConfID>@*.plcm.vc) and recorded here if the tenant’s key matches the key provided in the call string. Calls using an incorrect Tenant Key would not be matched to this tenant and thus would not appear in the tenant’s own reports.

Regardless of the selected time frame the most recent 100 records from the call log will be displayed by default. Scrolling down to the bottom of the page will load more records into memory and display them on the page, or the LOAD ALL button can be used to load the entire list of call records for the selected time frame. Once the desired set of records are loaded they can be exported into JSON and CSV formats for easier viewing in external applications.

The example above includes various types of common End Reason results which are covered in the next section. What should be obvious from the list above though is that the tenant’s licensing appears to have expired sometime after the last successful call on 1-24-2020.

To see additional Call Details information for a specific call in the list click simply the chain link icon in the first column of the table in the desired record. This call did not complete successfully due to a lack of valid licenses in the tenant (either missing or expired) as described in the callFailed section.

The remainder of the call records includes additional information like dial string used in the call attempt, the protocol used (SIP vs. H.323), source location details, timestamps, call end times, the reason the call was ended, and more.

Call quality statistics are also provided in the record but only if the call was successfully connected into a meeting and stayed connected for at least one minute. This data is included in the VTC section and is broken down into additional sections based on media type and direction. The applicable categories include audioIn, audioOut, contentIn, contentOut, videoIn, and videoOut.

As the RealConnect service is the source of this data (not the endpoint) then the directions indicated are from the point-of-view of the service. Thus, “In” statistics are what the service sees coming in, meaning these are streams from the endpoint to the service. “Out” statistics are what the service is sending out, thus streams from the service to the endpoint. As stated earlier this data is only representing the call path between the VTC and the service; any signaling or media statistics related to communications between the service and the Microsoft Skype or Teams platforms as well as those native clients is not included in this portal.

Of all the metrics available in the call data arguably the most important are the packet loss values, given that this service resides in the Microsoft Azure cloud and it most likely reached via the public Internet for most calls. For this reason the call record also includes a chart summarizing Packet Loss Per Minute at the bottom of the page.

This example shows a call which lasted just over one hour that experienced only 11 lost packets, and all occurrences were recorded on the blue ‘”To RealConnect” line.

By reviewing the VTC details in this call a total of 1,365,861 packets were reported as sent/received across both audio and video session. The 11 lost packets all occurred in the videoIn session, meaning they only occurred on the video stream coming from the VTC up to the service.

Additional Examples

Beyond the basic examples shown above there are some other common scenarios which can be identified by reviewing the data on the dashboard or looking deeper into call detail records.

License Overage

In the this example a tenant has reported that some, but not all of their call attempts into the RealConnect Service are being rejected.

Looking at the Active Calls Over Time graph in the default Week view on the dashboard page the data points appears to indicate that this tenant may only contain 2 concurrent licenses.

Clicking on the Total Joined legend item will hide that data from the graph, resulting in a focused view on the remaining data: Max Concurrent. Note that all data points indicate a Call Count value of either 1 or 2.

Additionally the following values displayed towards the bottom of the dashboard can be used to understand overage behavior that occurred during this time window. Based on the definitions provided earlier in this article the data below shows that all call attempts which occurred when the tenant was already at license capacity were rejected. If any additional calls had been allowed while at license capacity then the Surged Calls value would not be zero.

As all signs seem to point to only 2 licenses being available for this tenant then the way to confirm that is to have a Global Administrator for the Office 365 tenant sign into the RealConnect Service’s provisioning portal to view the current licensing status.

In this tenant’s case it may be advisable to add additional RealConnect licenses to address the need for more than 2 conference rooms to use the service at the same time. By switching to a larger data scope like the Three Month view additional historical data can be used to help determine what the appropriate suggested licensing count might be.

In this example it is clear that this tenant needs to add some additional licenses, but to determine how many licenses requires a closer look at the data. The Calls > List menu can be filtered by call events to view ever rejected call.

From the navigation menu select Calls > List and then click the Show Filter button.

Under the License Use drop down menu select All Overages and then click Apply Filter.

By reviewing the individual calls it can be determined if the 64 overage events in this 3 month time period are indicative of the several conference rooms trying to join the same meeting or different meetings at the same time, or are instead largely represented by repeated failed attempts from the same conference room to join a single meeting.

This data can further be exported into CSV and imported in something like Microsoft Excel to perform additional queries and reporting on to further scrutinize the data for patterns. Something worth noting in the data shown above is that the From field shows the same value in all of these entries. This could indicate that it is the same system placing all of these calls, but given that the value is specifically ‘Teams.Trio’ it is more likely that these are different room systems. The default value for the reg.X.address parameter provided in several configuration templates for the Poly Trio is ‘Teams.Trio’, so one cannot easily decide if these calls are from one or many different Trio installations. To avoid this it is recommended to define a unique name on each Trio to help determine the source of calls into the RealConnect Service.

License Overage with Soft Ceiling

Here is another tenant in a similar scenario of placing calls while at license concurrency but is successfully leveraging the Soft Ceiling feature.

The Active Calls Over Time graph is displayed over a Six Month period, with only the Max Concurrent data visible.

Based on what was explained in the previous example the scenario here shows the majority of maximum concurrent events approaching and eventually exceeding the 100 mark, with a few notable exceptions: peaking sometime in December followed immediately by a massive dip in utilization which occurred during the holidays. The tenant in this example is actually licensed for 100 concurrent connections, and as shown by the graph and the zero value for Rejected Calls they are appropriately sized and currently leveraging the Soft Ceiling feature by staying under the allowed 150 maximum connections. Based on the historical growth though additional licenses will likely need to be added to prevent any calls from being rejected.

Filed under Poly · Tagged with Administration, CVI, RealConnect, VTC

Managing Microsoft Teams Phone Policies

November 2, 2019 by Jeff Schertz · 43 Comments

As Microsoft and their certified device partners gear up to bring more native Microsoft Teams IP Phones to the market the management and customization of the device experience is also being expanded upon. This article introduces the current capabilities of a new PowerShell cmdlet created specifically to manage the user experience of these devices.

For some time the Set-CsIPPhonePolicy cmdlet has been available in the Skype for Business Online PowerShell module, which initially only applied to Lync Phone Edition, but was later also used with 3PIP-qualified devices (like VVX phones). That cmdlet only controls a single globally-applicable set of parameters though, so it was not possible to create different sets of behaviors which could be applied to different groupings of phones.

With Microsoft Teams a new cmdlet named Set-CsTeamsIPPhonePolicy has been introduced, which is still included in the Skype for Business Online PowerShell module alongside all other Teams platform administrative cmdlets. At the time of posting this article Microsoft has not yet published any official documentation for this cmdlet, but the functionality is already present in Office 365 tenants.

The most obvious change between the Skype IP Phone functionality and the what now exists for Teams devices is there is also a New-CsTeamsIPPhonePolicy cmdlet which allows the creation of custom policies in addition to the default global policy (which can be modified if desired). This addresses a long overdue customer request to assign unique parameter values to different categories of phones, be it by location, department, use-case, etc. Alongside this cmdlet is the requisite Grant-CsTeamsIPPhonePolicy cmdlet which is used to assign custom policies to individual user accounts.

Currently there is a very limited set of parameters available to actually control phone behavior, but the groundwork has been laid to start defining unique policies and then assigning these polices to user accounts to control their IP phone experiences.

Investigating the New Cmdlets

To take a closer look at this new capability launch PowerShell and import the Skype for Business Online module (if installed) as outlined in numerous articles like this. Then list out the available cmdlets in the imported module that match the ‘TeamsIPPhone’ naming scheme.

Launch PowerShell and connect to Skype for Business Online using an account which sufficient administrative rights in the desired tenant.

Import-Module SkypeOnlineConnector
$sfbo = New-CsOnlineSession -UserName jeff@msteams.net
Import-PSSession $sfbo

Enter the following command to list all available cmdlets matching the desired string. Take note that the name of the module is dynamic and will be unique for every imported session, so use the name shown after successfully importing the Skype module (e.g. tmp_iwwu1ido.jpc).

Get-Command -Module tmp_iwwu1ido.jpc | Where-Object {$_.Name -like “*TeamsIPPhone*”}

The results should look like the following:

The five new cmdlets could logically be grouped as:

[Get|Set]-CsTeamsIPPhonePolicy – used to review and modify the parameters of an existing global or user policy.

[New|Remove]-CsTeamsIPPhonePolicy – used to create and delete user policies.

Grant-CsTeamsIPPhonePolicy – used to assign users to a specific user policy which will override the Global policy’s behavior.

Notice that there is no companion cmdlet for the ‘Grant-’ cmdlet. This is because, like all other Skype and Teams policy-related cmdlets, the process to remove a user from an assigned user policy is simply to run the same cmdlet again, but instead assign the user to a $null policy. Users can only be assigned to user policies and cannot explicitly be assigned to a global policy; assigning them to a null policy will return them to the default behavior of adhering to the global policy.

The next step into investigating the configuration would be to take a look at the default Global policy.

Run the Get-CsTeamsIPPhonePolicy cmdlet to list all defined policies and their current settings.

Get-CsTeamsIPPhonePolicy

The default configuration in all Office 365 tenants should simply return a single Global policy with the parameters shown above. As previously mentioned, the list of configurable parameters in these policies are currently quite limited. In fact, at the time this article was written there are only two behaviors which can be controlled: the primary client experience via the sign in mode, and the inclusion of the Search function on Common Area Phones.

As best practices typically dictate it is generically recommended to leave the default global parameters as they are and create new user policies to customize any behavior. Be aware that the only available policy types here are global and user, so if there is a behavior which would be deemed desirable for all users then it would be easier to manage this change at the global level then having to manually add every new user account in the tenant to a specific user policy. This would likely become more applicable if/when future parameters are added here that make sense to modify at a tenant-wide level, as the available settings are not really good candidates for a tenant-wide change.

Now that some parameter values have been discovered the piece to uncover is what are the possible configuration options for these settings? A simple way to find that out in PowerShell is to attempt to set a parameter to an obviously invalid value and when the cmdlet fails the error response will return the list of accepted values.

Run the Set-CsTeamsIPPhonePolicy cmdlet using a bogus value (e.g. NotARealParameterValue) for the SignInMode parameter

Set-CsTeamsIPPhonePolicy -SignInMode “NotARealParameterValue”

This invalid command has returned a list of possible values for the parameter which includes UserSignIn, CommonAreaPhoneSignIn, and MeetingSignIn.

Run the same command as above, but against the SearchOnCommonAreaPhoneMode parameter.

Set-CsTeamsIPPhonePolicy -SearchOnCommonAreaPhoneMode “NotARealParameterValue”

This parameter is a simple ‘on/off’ switch as the only possible values are Enabled or Disabled.

Sign In Mode

What the SignInMode parameter controls is essentially the overall user experience on the Teams device Android client. There are three different options which provide three unique interfaces targeted at three specific, common use-cases: regular users, shared meeting rooms, and common areas. The available parameter values are as follows:

UserSignIn

The UserSignIn setting provides the full client experience which is typically targeted for regular phone users. Unless any changes are applied to the tenant using the cmdlets and guidance in this article then all user accounts signing into all Teams IP phones will receive this experience as the default global policy is set to this value.

The latest phone software no longer prompts the user during sign-in to select if they want a Personal or Shared experience (as outlined in a past article). The account type which is signing into the phone does not matter, so whether it is a user mailbox or room mailbox or if it has been enabled in Skype for Business using the CsMeetingRoom cmdlet set is irrelevant. Additionally, the type of Office 365 license applied to the account has no effect here either. Thus, an account configured as a room mailbox and assigned a Common Area Phone license (which is a bad idea for other reasons) will still show the full client experience when signing into a Teams phone in this example tenant based on the fact that only the single global policy exists which is set to UserSignIn mode. In short, the overall client experience is controlled only by this PowerShell policy, and nothing else.

This mode provides the full client experience which includes the Calls, Calendar, and Voicemail screens, the Search button, the Call Park button, and the New Meeting/New Call buttons, as shown in the following screenshots from a Poly CCX 600 phone.

Calls

Calendar

Voicemail

Note that the screenshots above are using the Dark Theme option, which is not the default appearance. Once a user signs into a phone then they can enable Dark Theme directly from within the client’s Settings menu; this is not a setting which is currently controllable by an administrator.

MeetingSignIn

This setting is meant to be used on phones which are located in conference rooms where the primary use case is joining scheduled meetings. In order to utilize this mode on a phone a new user policy must be created so that it can be assigned to the user account which will be signed into the phone.

Using the New-CsTeamsIPPohnePolicy cmdlet create a new user policy and configure the sign in mode for meeting devices.

New-CsTeamsIPPhonePolicy -Identity “MR” -Description “Meeting Room Phone User Policy” -SignInMode MeetingSignIn

Assign the new meeting room policy to the desired user account.

Grant-CsTeamsIPPhonePolicy -PolicyName “MR” -Identity “trio8500@msteams.net”

When logging into a Teams phone using this account the interface will default to showing only the Calendar view, and the Dial button if the account is Enterprise Voice enabled with the requisite Phone System licensing. Some of the available options in the client are hidden from the user, like the Sign Out menu item has been relocated to the Settings > Device Settings > Admin Only menu which is password-protected. The Search button is still available, but the Call Park button has been removed.

The following screenshots where taken from a Poly Trio 8500 using the account which was added to the Meeting Room policy in the previous steps. For comparison’s sake images from both the default theme and dark theme are shown below.

CommonAreaPhoneSignIn

This setting provides to most restrictive user experience intended for phones in common areas which may even be placed in public area. In order to utilize this mode on a phone another new user policy should be created so that it can be assigned to other user accounts.

Using the New-CsTeamsIPPohnePolicy cmdlet create a new user policy and configure the sign in mode for common area devices.

New-CsTeamsIPPhonePolicy -Identity “CAP” -Description “Common Area Phone User Policy” -SignInMode CommonAreaPhoneSignIn –SearchOnCommonAreaPhoneMode Disabled

The SearchOnCommonAreaPhoneMode parameter can be set to either Enabled or Disabled, whichever is preferred.

Assign the new common area policy to the desired user account.

Grant-CsTeamsIPPhonePolicy -PolicyName “CAP” -Identity “ccx400@msteams.net”

When logging into a Teams phone using this account the only the dial pad will be displayed along with the Call Park button. The Search function can selective be hidden or shown via the other setting in the policy.

To allow the Search function to be used on Common Area Phones simply modify the newly created user policy to enable that feature.

Set-CsTeamsIPPhonePolicy -Identity CAP -SearchOnCommonAreaPhoneMode Enabled

Once the policy change is picked up by the phone it should display the Search button.

Review Configuration

To view the existing policy configuration simply run the Get-CsTeamsIPPhonePolicy cmdlet to list all defined policies and their current parameter values.

Get-CsTeamsIPPhonePolicy

To quickly check which users have been assigned to a user policy run the following command to list all users in the tenant, showing only the User Principal Name (UPN) and TeamsIPPhonePolicy parameters. (Users with no value set for the phone policy will adhere to the Global policy.)

Get-CsOnlineUser | ft UserPrincipalName, TeamsIPPhonePolicy

Filed under Teams · Tagged with Administration, Teams Phones

Poly Group Series with Microsoft Teams

October 4, 2019 by Jeff Schertz · 76 Comments

This article covers how to successfully configure a Poly Group Series to connect to Microsoft Teams meetings. While several different options, both native and interoperable, were recently outlined for the Poly Trio the Group Series approach is much simpler. This is due to the facts that (a) there are no applicable audio-only scenarios as the Group Series is not a SIP-based phone at its core, and (b) there are no native Teams options for the Group Series as it does not run Android or Windows, and thus cannot directly run either of the device apps provided by Microsoft to their device partners.

This means that there is only a single path to Microsoft Teams for the Group Series: an interoperability service like RealConnect. Thus, the few potential configuration scenarios have more to do with Skype for Business connectivity than Teams.

This article is only applicable to a standalone Group Series deployment. If a Group Series unit has been integrated with a Trio, meaning it is deployed as a Visual Pro, then the aforementioned Trio article should be used as guidance. In this scenario the registration and call control is handled by the Trio, not the Group Series/Visual Pro.

The valid configuration scenarios fall into two categories:

Interop Only – Both Teams and Skype meetings are joined via the interoperability model by using the RealConnect Service.
Mixed Mode – While the RealConnect Service must be used for Teams meetings, Skype meetings will instead connect natively.

The first option provides for the most configuration flexibility as the Group Series supports both H.323 and SIP, so either protocol can be used to join Teams meetings via the available interoperability solutions: RealConnect for Clariti or the RealConnect Service.

When Skype for Business meetings also need to be supported though, then there are two different options which could impact which protocols are available to use for connecting into Teams meetings. Essentially, if Skype meetings will be joined natively, then SIP is occupied by the registration to a Skype for Business Server, or Skype for Business Online. Only H.323 remains available to join Teams, as an attempt to call into an interoperability service for Teams using a SIP dial string would fail as the SIP registrar is Skype and would not understand that call, nor be able to route it correctly. If RealConnect will be leveraged for joining both Skype and Teams meetings then either SIP or H.323 can be used.

The configuration examples provided in this article will leverage a single Microsoft Office 365 tenant with accounts enabled and homed in Skype for Business Online and Exchange Online. Additional configuration in the management portal for the OTD service (which is not covered in this article) is required when using room mailboxes homed on an Exchange Server deployment.

Calendar Configuration

The Calendaring Service configuration will be the same across all of these scenarios as, unlike the Trio, the Group Series does not natively support the ability to recognize RealConnect meeting invitations across all possible formats. This is what the One Touch Dial (OTD) service is designed to address, for multiple different endpoint types.

In many cases the Group Series may already be configured to point to Exchange Online, especially when the system is natively registered to Skype for Business. If the resource mailbox leveraged by the Group Series has been enabled for authentication, or if a service account has been delegated permissions to the mailbox then those credentials would be included in the calendaring configuration. In these cases only a single change is needed to the configuration: pointing the system to the Poly One Touch Dial service instead of directly to Exchange Online.

Also make sure to confirm that the Exchange mailbox is correctly configured, as outlined in this article, paying close attention to the DeleteComments parameter. It is common for a previously created resource mailbox to be left in its default state which would prevent the endpoint from displaying a functional Join button on Skype and Teams invitations.

Connect to the IP address of the Group Series in a browser (e.g. https://192.168.1.163) to access the web management interface.

Navigate to the Admin Settings > Servers > Calendaring Service menu and, if not already enabled, select Enable Calendaring Service.

Enter the primary SMTP address of the resource (or user) mailbox intended for use with the Group Series (e.g. group@msteams.net).

Leave the Domain field blank and then in the User Name field enter the User Principal Name of the account with appropriate permissions to the mailbox. This would either be the mailbox’s own identity (e.g. group@msteams.net) or a service account which has been delegated at least ‘Reviewer’ rights to the ‘Calendar’ folder of that mailbox. Enter the Password for the provided user account.

Ignoring the Auto Discover option manually enter the address of the Poly One Touch Dial service (otd.plcm.vc) in the Microsoft Exchange Server field and then click Save.

After applying the changes the Registration Status will initially report Not Connected, but within 30 seconds or so it should update to Registered.

Once connected to the mailbox check the calendar display on the Group Series monitor and/or touch panel to confirm that any scheduled Skype or Teams meetings appear and are showing a Join button.

At this point the Group Series is ready to attempt a call using One Touch Dial, but the remaining configuration options will dictate how those call attempts are actually handled.

Scenario 1 – Interop

The ability to actually connect the call after it has been placed falls primarily on network connectivity which can vary across different infrastructure or cloud service arrangements. The system could either be unregistered or registered to one or more video infrastructure platforms (Poly RealPresence, Cisco VCS, etc) or cloud services.

Given that a variety of options exist this article will only cover one: using a standalone Group Series along with the RealConnect Service. No standards-based registrars will come into play, and the communications path to the service in Azure is available by traversing a standard firewall which allows outbound traffic to Azure over the required ports and protocols to successfully reach the service.

In this scenario either or both SIP and H.323 can be enabled and used for placing calls into the RealConnect Service.

H.323 Configuration

Perform the following steps to enable H.323 for outbound calling, if desired.

Navigate to the Admin Settings > Network > IP Network menu and then expand the H.323 section.

Select Enable IP H.323.

Enter the name which will be used to identify the system in Skype and Teams meetings in the H.323 Name field (e.g. Jeff Schertz GS500).

Leave the H.323 Extension (E.164) field blank. (It is not required for calls into the service, but it can be populated for other H.323 use cases if desired.)

Set Use Gatekeeper to Off (unless an H.323 registrar is available) and then click Save.

SIP Configuration

Perform the following steps to enable SIP for outbound calling, if desired. The majority of the settings will typically apply to whether or not a standards-based SIP registrar is available for use, or if unregistered calls are preferred over a specific transport protocol. The system’s default Auto configuration options can be used, but in the example below the configuration is specifically set to utilize unregistered, secure TLS communications.

Navigate to the Admin Settings > Network > IP Network menu and then expand the SIP section.

Select Enable SIP.

Select Specify for the SIP Server Configuration option and then select TLS as the Transport Protocol.

Leave the BFCP transport preference set to Prefer UDP (as this is the better option for content sharing media than TCP).

Leave the Registrar Server Type to Unknown and then leaving the remaining fields blank click Save.

Dialing Preference

This configuration controls which protocol is used by default when joining a meeting by using the Join button on the calendar or when using the Place a Call option on the Group Series user interface with the remote control or a touch device.

If a call is placed using the Manual Dial option on the Place a Call menu in the web management interface then a drop-down menu can be used to override the automatic behavior (which follows the defined dialing order preference) and use the selected protocol when the call is placed.

Navigate to the Admin Settings > Network > Dialing Preference menu and then expand the Dialing Options section.

Select the preferred protocol in the Video Dialing Order Preference 1 field (e.g. SIP).

One Touch Dial Configuration

The configuration of the OTD service behavior for the current tenant should be verified to validate the desired behavior of the Group Series when receiving meeting invitations which includes additional information for using the RealConnect Service.

Verify that the appropriate Poly RealConnect options are enabled under the Recognize Meeting Invitations sections.

The configuration above will trigger the Group Series to utilize the RealConnect Service for all Skype and Teams meetings which include the pertinent info for RealConnect.

The first setting will tell OTD to look for information provided in a Skype invitation under the “Join with a video conferencing device” section, and if that information exists then to parse the dialing information (Tenant Key, Conference ID, and v.plcm.vc FQDN) to assemble the correct dial string and insert those instructions as a token into the invitation before relying the message back to the endpoint. The Group Series will ignore any of the original information embedded in the invitation and use the token provided specifically by OTD.

The second setting does the same as above, but will look specifically for the string “<ConfID>@h.plcm.vc” in the administrator-defined footer of the meeting invitation as well as the Audio Conference ID provided in the body.

The third setting functions identically to the first, except that the provided hostname in a Teams meeting invitation does not necessarily need to be t.plcm.vc, which is the common default. If a custom hostname (e.g. video.msteams.net) is configured correctly then the service will parse that information to assemble the correct dial string.

Scenario 2 – Mixed Mode

This scenario leverages the RealConnect Service to join Teams meetings, yet still connects directly to Skype for Business Server or Online meetings natively. The SIP configuration must be used to natively register to the preferred Skype for Business platform, leaving only H.323 as a viable option for connecting to the RealConnect Service to join Teams meetings.

SIP Configuration

In the event that the Group Series has not already been integrated with Skype for Business, then previous articles includes more detail on registering a Group Series to Skype for Business Server or Online.

In this example the same account (group@msteams.net) which was used for the mailbox is also enabled for Skype for Business Online.

H.323 Configuration

The H.323 configuration shown here is the identical configuration as what was provided earlier in the Interop scenario.

Dialing Preference

This step is critical to perform compared to the previous scenario where it did not really matter which protocol was used (assuming sufficient network connectivity was available for both). Because SIP is occupied in this scenario for the Skype for Business registration then the preferred dialing option must be set to H.323 for RealConnect calls to be routed correctly.

Navigate to the Admin Settings > Network > Dialing Preference menu and then expand the Dialing Options section.

Set the Video Dialing Order Preference 1 to IP H.323.

One Touch Dial Configuration

Of equal importance is to properly configure the OTD portal to allow Skype meetings to use the native SIP registration path. Because the Group Series is unable to ignore the token provided in the invitation processed by OTD, then if any Skype Meetings contain details to join from a video conferencing device this will force the call to go to RealConnect, and not use the desired native SIP registration path to Skype for Business. To resolve this OTD must be configured to ignore Skype meeting invites and not process them. Doing so will relay the message unedited, allowing the Group Series to recognize and use the embedded Skype Meeting URL for the ‘Join’ button action.

Disable one or both of the Poly RealConnect with Skype for Business options under the Recognize Meeting Invitations section.

Filed under Poly · Tagged with CVI, RealConnect, VTC

Adding One Touch Dial Administrators

September 25, 2019 by Jeff Schertz · 4 Comments

This brief article outlines how to provide administrative access for additional user accounts to the management portal for the Poly One Touch Dial (OTD) Service. Typically when initially onboarding the service for a tenant one or more Microsoft online identities can be provided with the order, and these identities are enabled as administrators for the organization during the order processing stage. Yet, often after an environment has been enrolled in the service additional administrators may need to be added. Previously this required contacting Poly support to request additional accounts to be enabled as administrators in the One Touch Dial portal for their tenant, but this is now something which can be performed directly by an existing tenant administrator.

Understand that in order to perform this task for the OTD service portal the configuration is actually present in a different, central portal. To recap there are currently up to three different management portals which might be used to manage a RealConnect Service tenant:

Poly Cloud Services portal – https://console.plcm.cloud
Poly One Touch Dial portal – https://otd.plcm.vc
Poly RealConnect Service portal – https://webapp.plcm.vc

In this article the first portal (Cloud Services) will be used to enable administrators for the second (OTD). (The third portal is not used, and is only referenced here for posterity.)

Configuration

Sign in to the Poly Cloud Services portal using the credentials of a local account or (if already integrated) a Microsoft Office 365 account which has already been granted access to this portal.

Select the Administration tile from the home page and then select Users from the navigation menu.

Click the Add button and then enter the Email Address of an existing account in the same organization which needs to be granted access to the OTD portal. Select the OTD Admin user role and leave the Sign In Account setting at Enterprise Only, then click Save.

Confirm that the new user account appears in the user list and includes the appropriate permission.

At this point the configuration has been applied, but may take a few minutes before the OTD service updates its own database to reflect the changes.

Confirmation

After a couple of minutes open the One Touch Dial portal and click the Sign In button.

Select Sign in with Microsoft and then either enter or select the desired account when prompted by Microsoft.

If the previous configuration steps were performed correctly and ample time has passed, then the OTD dashboard view should appear once signed in with the new user.

If the configuration was unsuccessful, then the following error will be displayed for an authenticated account which has not been properly assigned as an administrator for any organization.

Filed under Poly · Tagged with Administration, CVI, OTD, RealConnect, VTC

Exchange Resource Mailbox Configuration for Meeting Rooms

August 12, 2019 by Jeff Schertz · 8 Comments

Several previous articles on this blog have outlined the required configuration of Exchange mailboxes for use with native Microsoft meeting room solutions for Microsoft Teams and Skype. There are also some articles which cover the configuration for mailboxes for use with standards-based video conferencing solutions from Poly and Cisco which support Microsoft Exchange to display and join scheduled Skype and Teams meetings.

All of these articles share a common and often overlooked configuration setting that is worth spending a little more time on: the DeleteComments parameter as defined on Exchange mailboxes via the Set-CalendarProcessing PowerShell cmdlet. This parameter must be set to a value of “$false” in order for most conferencing solutions to properly process the various type of meeting invitations. Yet the default value on this parameter for mailboxes in Exchange is ‘$true‘.

What this means is that Exchange will delete the entire contents of the message body when it arrives in this destination mailbox. That can prevent various meeting room solutions from joining the meetings from the calendar. In these scenarios the resolution is to simply run the Set-CalendarProcessing cmdlet against the affected resource mailbox to disable the DeleteComments parameter.

Set-CalendarProcessing -Identity vtc1@msteams.net -DeleteComments $false

As this change only applies to inbound messages then a new meeting will need to be created and booked with the updated resource mailbox in order to see any improvement. Existing meetings in the mailbox’s calendar, individual or reoccurring, would still be missing the previously-stripped information in the body of the message.

Background

This is a critical configuration parameter which is often times the only thing preventing various meeting room solutions from successfully connecting to Microsoft Teams or Skype meetings. Issues are typically more prevalent when using standards-based video conferencing systems with Cloud Video Interop (CVI) or other on-premises interoperability solutions, like RealConnect for Clariti, but native endpoints can also sometimes be negatively impacted.

The root of the issue is that Skype and Teams invitations includes important meeting information that is used by various clients and services differently. Information can be stored in the body of the invitation, where it can be seen by people and machines alike, and/or in the header of the email where it is hidden away from people, but not machines. And as meeting invitations are forwarded, both internally and externally between different organizations, some of this information can often be modified or even stripped completely from the message. This could prevent meeting rooms from joining scheduled meetings.

One example is in the earlier days of Microsoft Lync many of the native software clients and devices like Lync Phone Edition would provide the single-click join experience by looking for information stored in a specific parameter in the invitation’s header. But, if that invitation came from a different organization then the ‘Join’ button would not appear on those meetings in the calendar. This was due to fact that external delivery of that message would usually strip the needed MAPI properties in the header as the sender organization’s SMTP platform typically had Transport Neutral Encapsulation Format (TNEF) disabled. This was problematic as the workaround was something which must be applied in the sender’s environment, not on the receiving end so asking every other organization to apply these changes is not very scalable. Microsoft eventually addressed this issue in the various Lync clients by adding support for parsing additional information in the meeting invitations to correctly locate and join the scheduled meeting when the header information was lost. This was done by simply looking at the body of the message to identify the Skype meeting URL (e.g. https://meet.domain.com/user/ID) that is embedded in the “Join Skype Meeting” link.

Other solutions are also programmed to look at meeting information that is provided in the body of the message. Poly Trio is one endpoint example and the Poly One Touch Dial (OTD) service is another. Retaining the body of the meeting invitation is especially important when dealing with the various CVI solutions as their companion message processing services will look for information which they expect to see in the body.

To illustrate this take note of just how much different information is provided in the body of a Skype meeting or Teams meeting invitation. Embedded URLs for native clients, audio conferencing IDs which several third-party solutions can leverage, and video conferencing details provided for accessing the various CVI solutions.

When a client or device needs to leverage any of the information above it obviously needs to be available in the invite. Just because it was included in the original invitation though does not necessarily mean that it will still be intact by the time a recipient sees it, which brings the discussion back to the Exchange mailbox configuration.

Regular user mailboxes (which do not normally include automatic processing rules like resource mailboxes) will typically not have any issues seeing this information, thus when devices are using a regular user account everything seems to work fine. But when tested with an existing resource mailboxes in an organization is when issue can occur, most often because when the resource mailbox was originally created for a regular conference room there was no device using that mailbox and no additional custom configuration was applied. The mailbox was only setup to perform standard resource booking duties, and typically no one ever looks at the invitation details in the rooms account, it is only used as a placeholder for reserving the room. The default behavior in Exchange Server and Exchange Online has always been to trim the amount of unneeded data on every invite sent to a resource mailbox.

The configuration can be verified by looking at specific Calendar Processing parameters on mailboxes which were created using different methods. Mailboxes created using basic process like the Room & equipment section of the Microsoft 365 admin center or using “New-Mailbox –Room” in PowerShell will be setup by default to wipe the body of any emails sent to those mailboxes.

Use the following Exchange PowerShell cmdlet to review the related parameters on a standard resource mailbox in the organization (e.g. room1@msteams.net).

Get-CalendarProcessing -Identity “room1@msteams.net” | fl Add*,Delete*,Remove*

Note that DeleteComments is set to True in the output above.

But when a resource mailbox is created using the correct process it should have had the DeleteComments parameter specifically disabled, along with a few other required and optional changes.

Use the following Exchange PowerShell cmdlet to review the related parameters a customized resource mailbox in the organization (e.g. vtc1@msteams.net).

Get-CalendarProcessing -Identity “vtc1@msteams.net” | fl Add*,Delete*,Remove*

Because this second mailbox was created using the suggested approach then meetings sent to it will not have the invitation details removed as DeleteComments is set to False.

Other recommended settings for resource mailboxes used by meeting devices are covered in the Microsoft documentation, but most of them are optional changes as they apply to features like meeting conflict handling, automated responses, and privacy options which all may vary based on an organization’s requirements.

Parameter	Default	Recommended	Behavior
AddOrganizerToSubject	True	False	Would append the meeting organizer’s name to the subject, but both native endpoints and OTD-supported VTCs will already display the organizer’s name in a defined field so this parameter should be disabled.
DeleteComments	True	False	As previously outlined, this parameter must be disabled for nearly all meeting room platforms to function correctly with all supported invites.
DeleteSubject	True	False	It is optional in most cases to disable this as the Subject line typically does not include information related to joining the meeting. In some scenarios if an audio conferencing dial-in number is provided in the subject a system may be programmed to parse those digits and call into the meeting.
RemovePrivateProperty	True	False	For room systems (and the OTD service) which support hiding sender and/or meeting details from the device’s on-screen calendar for meetings marked as private this parameter must disabled for that feature to function.
AddAdditionalResponse	False	True	This is an optional setting which enables a custom message to appear in Outlook when including the mailbox in a meeting invitation.
AdditionalResponse	<null>	Custom Message	If the parameter above is enabled then this parameter should also be defined with a custom text message.

Filed under Exchange · Tagged with CVI, RealConnect, Teams Phones, Teams Rooms, VTC

Poly Trio with Microsoft Teams

August 6, 2019 by Jeff Schertz · 313 Comments

There are four primary configuration scenarios available for the Poly Trio which support Microsoft Teams and the ideal option for an organization can depend on several factors. The most important distinction is whether the Trio is deployed standalone as simply a phone or if it is also paired with Visual + or Visual Pro componentry for enabling video conferencing capabilities.

These four scenarios can generally be categorized as:

Native Mode
Gateway Mode
Hybrid Mode
USB Mode

The first two scenarios are Audio Only where the Trio is deployed as a standalone phone. The second two scenarios are applicable to Video-Enabled deployments of the Trio.

Note that in all but the USB scenario the Trio itself is the registered endpoint and the configuration is performed within the Unified Communications Software (UCS) firmware which runs on the Trio platform. The Trio performs all call control and can be paired to a variety of supported audio and video components, leveraging one or more registration and meeting platforms. Alternatively the USB mode simply turns the Trio into a USB audio device which is then connected to and controlled by a separate video-enabled endpoint like a Microsoft Teams Room.

The configuration steps in each of the following sections assumes that the Trio is in a factory-reset configuration state before starting, so some of these steps may not need to be performed on a currently deployed device.

Native Mode (Audio Only)

The first and newest option available is to simply place the Trio into the Microsoft Teams base profile which will automatically reconfigure the phone to launch and utilize the embedded Microsoft Team Android application designed for Teams-qualified IP phones. This application only provides for audio capabilities with the Trio, so it should only be used with a stand-alone Trio which is used for audio conferencing. (If any video devices are integrated with the Trio then any connected cameras and display monitors will not function in this mode.)

Configuration

Before attempting to use this option the Trio must first be upgraded to at least the 5.9.0 Rev AA firmware release which first introduced this supported capability.

Open the Settings menu on the Trio and navigate to Advanced > Administration Settings > Network Configuration > Base Profile and then select the Microsoft Teams option. (The default password is ‘456’.) Tap the back arrow and then select Save Config which will immediately reboot the phone.

After the phone reboots it will display the Microsoft Teams Sign In screen.

A Company Portal screen may be seen while the client software attempts to connect to the Microsoft Teams services. When the Microsoft Sign In screen appears it will provide two different user authentication methods: one option to directly enter the credentials into the phone using the soft keyboard and another to utilize the Web Sign In process to enter the credentials in a web page on another computer.

If it is desired to enter the account credentials directly on the phone then follow this step, otherwise skip to the next step to alternatively use a web browser on another device to enter the account credentials for the phone.

Tap on the username field to bring up the on-screen keyboard and then type in the username for the desired Teams user account (e.g. trio@msteams.net) and select Next.

Enter the password for the provided account name and then select Sign In.

Alternatively this step can be used to sign into the phone by using a web browser on a computer or other mobile device.

Tap the “Sign in from another device” option

From a web browser on another device or computer go to https://microsoft.com/devicelogin and then enter the alphanumeric code currently displayed on the Trio (e.g. e5s7p7alx) in the Enter Code field and then click Next. (As demonstrated in this example the code is not case-sensitive.)

If the Pick an account window appears and the desired account appears in the list then select that account. If not, then select the Use another account option.

If prompted to sign in then enter the username for the desired Teams user account (e.g. trio@msteams.net) and select Next. Then enter the password and select Sign In.

Regardless of which sign-in approach was used the remainder of the process is the same, as are the resulting capabilities and experience. The phone may briefly display the Company Portal page as the Microsoft 365 tenant is located and then the Teams client will appear once completed.

If prompted to select a login account type select Shared. (This is the only mode that will be supported on the Trio, so while Personal can be selected it is not recommended, nor supported.)

Behavior

The Shared option is meant for common area use-cases like conference rooms where only scheduled meetings on the room’s calendar are displayed, along with the dial pad button used to place an outgoing PSTN call. The magnifying glass icon in the upper right corner can also be used to search for other Teams users or devices to place outbound peer calls to.

In the example shown above there are both Teams and Skype for Business scheduled meetings on the Trio’s calendar. Note that the action button on Teams meetings says ‘Join’ while the button on a Skype meeting (denoted by the Skype for Business logo) says ‘Dial’. this is a very important distinction to understand as the Teams client does not have any native support for Skype for Business; it does not speak MS-SIP and cannot talk to a Skype for Business platform. The only way this client can join a Skype meeting is if the meeting organizer is configured for Dial-In Conferencing or is licensed for Audio Conferencing and the meeting invitation includes the necessary PSTN dial-in number(s). Also, the Teams user registered to the Trio must be enabled with Phone Calling using either Direct Routing or with a Microsoft Phone Calling Plan assigned to it. In short, the Trio must be able place an outbound call to the PSTN via Microsoft Teams in order to connect to the Skype meeting via basic audio conferencing.

The Teams presence state for the account can manually be set directly on the phone by tapping the ‘hamburger’ menu in the upper-left corner of the client and selecting the desired presence state.

For comparison the Personal option can be selected during sign in if prompted, but this mode is more resource-intensive and as previous stated is not supported on the current Trio models. This mode is intended for personal handsets like the upcoming Poly CCX devices and will not only show scheduled Meetings, but also provide additional capabilities in the client applicable to individual users like the history of Calls and Voicemail along with Search and Call Park retrieval options. From the Calls screen the Make a Call button can be used to either search for other Teams users or bring up a dial pad to place a PSTN call. The New event button on the Meetings screen allows the user to create a new Teams meeting directly from the phone and then invite other participants.

Gateway Mode (Audio Only)

This configuration uses a single registration into Skype for Business Online which inherently provides a limited set of core functionality into the Microsoft Teams environment. This is provided by way of a SIP to Teams audio gateway which Microsoft has deployed and manages in their cloud. The gateway is not something that devices point to directly as it is more of a set of backend connections between the Skype for Business Online and Microsoft Teams environments, allowing for mainly peer calling and meeting-join capabilities for 3PIP-qualified IP phones like the Polycom VVX, Trio, or other third-party qualified phones. Thus, the simple act of registering the phone to Skype for Business Online provides some inherent connectivity into Microsoft Teams.

Also of importance is where PSTN connectivity comes from. If the environment is currently using Enterprise Voice in Skype for Business then all PBX functionality and PSTN connectivity is retained via the registration to Skype for Business. If (and when) that Enterprise Voice functionality is migrated to Teams, by way of establishing a Direct Route to Teams or utilizing Microsoft Phone Calling Plans, then the Trio (as any 3PIP-qualified phone) will continue to operate the same via the gateway services. Thus, when moving all users in an environment to “Teams Only” mode and also migrating PSTN connectivity directly into Teams there is no impact to these phones which were already functioning; they simply stay in the same configuration and the gateway masks all of those changes.

Be aware that while this functionality does rely on Skype for Business Online it will not initially be impacted by the planned retirement of Skype for Business Online on July 31, 2021 as announced by Microsoft. Microsoft intends to support 3PIP-qualified IP phones via the gateway services for an additional two years, through July 31, 2023 as stated in this FAQ.

Configuration

Before registering the phone the desired user account should be set to Teams Only mode for best functionality. While this is not a requirement to leverage the gateway, but is recommended for proper functionality. If the account is in a different Teams Upgrade mode, like Islands for example, then peer calling behavior may not function correctly.

Open the Microsoft Teams admin center (https://admin.teams.microsoft.com) and in the Users section select the desired account.

Click Edit on the Teams Upgrade section and change Coexistence Mode to Teams only and click Save. (Ignore the setting to ‘Notify the Skype for Business user’ as this only applies to the Microsoft Skype for Business clients and is not relevant for using the account only with a 3PIP-qualified phone.)

On the Trio access the Settings menu and navigate to Advanced > Administration Settings > Network Configuration > Base Profile and then select the Skype for Business option. (The default password is ‘456’.) Tap the back arrow and then select Save Config which will immediately reboot the phone.

After the phone reboots tap the Sign In button and select the preferred option for registering to Skype for Business Online using the desired user account.

Behavior

When the Trio is registered to an account which is homed in Skype for Business Online it will retain all currently supported Skype capabilities as it is still in the Skype Base Profile. When a specific event occurs (like placing a call from the phone to another user in Teams Only mode) then Skype for Business Online knows to route that call through the gateway services into the Teams environment. Understand that if a phone is registered with an account homed on a Skype for Business Server which is not part of a Hybrid deployment then this will not function as the gateway service is only accessible via Skype for Business Online connectivity.

As pointed out above, this is an Audio Only experience with Microsoft Teams as the gateway only supports audio. Thus, this configuration is also intended specifically for audio-only deployments and should be avoided with video-enabled configurations. (There is a known issue where video sessions can erroneously be established through this gateway when joining a Teams meeting. This may not be resolved by Microsoft as the gateway is essentially in a maintenance mode and will likely not have any future feature development. Microsoft’s focus is the wholesale replacement of devices to new products which will run the native Microsoft Teams client.)

To provide some insight into how the gateway works simply save a Teams meeting invitation in Outlook as an .html file then open it in any text editor or viewer. Search for the text “focus:id” and the following OnlineMeetingConfLink section should be seen.

Note that this looks exactly like a Lync or Skype for Business conference URI, except for the additional teams:2:0!19: string. The Trio does not look at the actual Teams meeting link embedded in the Join Microsoft Teams Meeting link at the top of the invitation, but will identify these invitations as a ‘Skype Meeting’ by recognizing the conference URI embedded in the message as shown above.

A native Teams client would join this meeting using the native Teams meeting URL.

https://teams.microsoft.com/l/meetup-join/19%3ameeting_NQG2ODNzMTItZTU5Yy95ZTFhLWFmYjgtYjk4MjQ1N2Q0ZmY4%40thread.v2/0?context=%7b%22Tid%22%3a%22bc7c5f16-c55e-417d-aac0-ff6bbfc27f76%22%2c%22Oid%22%3a%22aff3cdcc-4551-4de6-8bec-e7f9e07edf61%22%7d

Yet the phone will leverage the ‘legacy’ Skype conference URI in the invitation which looks much different.

conf:sip:jeff@msteams.net;gruu;opaque=app:conf:focus:id:teams:2:0!19: meeting_NQG2ODNzMTItZTU5Yy95ZTFhLWFmYjgtYjk4MjQ1N2Q0ZmY4-thread.v2! aff3cdcc45514de68bece7f9e07edf61!bc7c5f16c55e417daac0ff6bbfc27f76

Note that both formats utilize the same unique identifier, indicating that this is the same meeting. But since the phone registered to Skype for Business cannot leverage the first URL then continues to see this invitation as a Skype meeting and then attempts to connect to the conference URI above. As far as the phone is concerned though it thinks it is talking to a Skype for Business MCU, but in reality it has been pointed to the gateway (focus:id:teams:2:0!19:) which then handles the rest of the connection to the actual Teams MCU and locates the correct meeting via the provided meeting ID (NQG2ODNz…).

Hybrid Mode

The mode is the only option which is supported by Microsoft for interoperability when the Trio is deployed as video-enabled when paired with a Poly Visual Plus (Visual+) or Visual Pro solution. This is because the Trio will leverage the supported Cloud Video Interop (CVI) approach by joining Microsoft Teams meetings using the Poly RealConnect Service.

The Hybrid name comes form the fact that the Trio can support multiple concurrent registrations to different SIP-based platforms and yet still join native Teams meetings with video and desktop sharing capabilities. One basic configuration option is to have a single line registered natively to Skype for Business to retain any existing functionality as well as utilize Enterprise Voice in Skype for PSTN connectivity, but then leverage a second (unregistered) line to join Teams meetings by placing standards-based SIP calls directly into the Azure-based interop service. Another common option comes into play when another common IP-PBX platform (e.g. Cisco or Avaya) is used in the environment and PSTN connectivity is not provided by Skype or Teams. This configuration is a true ‘hybrid registration’ option as the Trio will sustain multiple concurrent SIP registrations: one to the PBX platform for voice calling and a second to Skype for Business. The third line can be used for unregistered calls in to the CVI service or even be actively registered to any standards-based video proxy (e.g. Poly DMA/RPAD, Cisco VCS/VCS-E, etc.) for eventual routing into the video interop service (or alternatively the Poly Clariti-based configuration of RealConnect for Microsoft Teams interop.

In short, the Hybrid approach is the most flexible as it can be used to connect into any number of IP-based voice platforms and/or meeting solutions. It is not uncommon to see a Trio configured to support joining meetings scheduled on several different meeting services like Skype for Business, Microsoft Teams, Cisco WebEx, Zoom, etc. all in the same room.

Configuration

The example configuration in this article will address a single use-case, showing how register the Trio to Skype for Business and also configure it so that RealConnect will be used to join Teams meetings. This approach still retains existing Skype for Business functionality, only leveraging the interop service for joining Teams meetings

Before configuring the Trio itself a set of UCS parameters will need to be prepared to import into the phone. This is accomplished by creating a custom configuration text file and saving it with a .cfg file extension. There are several applicable parameters, most of which are required to successfully place calls into the RealConnect Service from the Trio. Only a few of the parameters need to be customized, while some of the parameters can be omitted depending on the desired capabilities.

At minimum the following parameters are required to allow the Trio to place a SIP call into RealConnect by using an additional, unregistered line. As mentioned above this specific example will configure the Trio to use Line 2 to place these calls, but for a Trio using a different configuration with potentially more than 2 registrations then simply alter the following example to use an available line number.

Attribute	Value
call.autoOffHook.2.contact	680450644@t.plcm.vc
call.autoOffHook.2.enabled	1
call.teluri.showPrompt	0
dialplan.2.applyToDirectoryDial	1
dialplan.2.digitmap	^.+@t\.plcm\.vc$
dialplan.2.digitmap.mode	regex
dialplan.2.digitmap.timeOut	4
dialplan.digitmap.lineSwitching.enable	1
exchange.meeting.realConnectProcessing.outboundRegistration	2
exchange.meeting.realConnectProcessing.skype.enabled	0
exchange.meeting.realConnectProcessing.teams.enabled	1
reg.2.address	trio
reg.2.keepalive.sessionTimers	1
reg.2.label	Teams Meeting
reg.2.server.1.address	t.plcm.vc
reg.2.server.1.register	0
reg.2.server.1.transport	TCPpreferred
reg.2.srtp.offer	1
reg.limit	2

The three highlighted parameter values above must be customized as explained below.

Most important is the specific Tenant Key (e.g 680450644) assigned to the Office 365 tenant where the RealConnect Service is used, as this controls which tenant entry queue is called when simply tapping the new line key which will appear on the phone.

Also enter the preferred name used to identify the phone in SIP calls (e.g. trio); this name can be pretty much anything unique to the specific device except for the SIP URI of the account already registered to Skype for Business as that would cause a conflict.

Finally select the desired label name which will appear under the new Line key button on the Trio’s home screen (e.g. Teams Meeting).

The following text can be copied into a new file and then saved as with a .cfg file extension for importing into the phone in a later step.

<?xml version=”1.0″ encoding=”utf-8″ standalone=”yes”?>
< !–Description: Template for configuring a Trio to connect and dial into Teams RealConnect via an unregistered Line 2. The Lobby will be autodialed when Line Key is selected.–>
< PHONE_CONFIG>
<ALL reg.limit=”2″ dialplan.digitmap.lineSwitching.enable=”1″ call.autoOffHook.2.contact=”680450644@t.plcm.vc” call.autoOffHook.2.enabled=”1″ dialplan.2.applyToDirectoryDial=”1″ dialplan.2.digitmap=”^.+@t\.plcm\.vc$” dialplan.2.digitmap.timeOut=”4″ dialplan.2.digitmap.mode=”regex” reg.2.address=”trio” reg.2.keepalive.sessionTimers=”1″ reg.2.label=”Teams Meeting” reg.2.server.1.address=”t.plcm.vc” reg.2.server.1.register=”0″ reg.2.server.1.transport=”TCPpreferred” reg.2.srtp.offer=”1″ exchange.meeting.realConnectProcessing.teams.enabled=”1″ exchange.meeting.realConnectProcessing.outboundRegistration=”2″ call.teluri.showPrompt=”0″ />
< /PHONE_CONFIG>

(Note that is configuration is identical to the “Trio-Teams-RealConnect-Line2-unregistered-Template” provided in the Polycom Device Management Service (PDMS).)

As mentioned above this specific example will configure the Trio to use Line 2 to call the RealConnect Service to join a Teams meeting. If it is preferred to move this functionality to a different line number for phones with more than a single registration then simply update each call.autoOffHook, dialplan, and reg parameter to change the .2. to the desired line number (e.g. 3). Also change the the exchange.meeting.realConnectProcessing.outboundRegistration parameter to match the same line number (e.g. 3) and finally set reg.limit parameter value from 2 to match the highest line number in the phone’s specific configuration.

On the Trio access the Settings menu and navigate to Advanced > Administration Settings > Network Configuration > Base Profile and then select the Skype for Business option. Tap the back arrow and then select Save Config which will immediately reboot the phone.

After the phone reboots tap the Sign In button and select the preferred option for registering to Skype for Business using the desired user account.

The next step is to apply the configuration file to the Trio which can be accomplished in one of several ways. If using a provisioning server solution with the Trio then that is the preferred approach, but for the purposes of this article the file will be manually imported into a single phone using the local web management administration interface. The web management interface is not available by default when the Trio is set to the Skype for Business profile, so it may need to manually be enabled. If it is already enabled on the Trio then skip this step.

On the Trio access the Settings menu and navigate to Advanced > Administration Settings > Web Server Configuration, enable Web Server, and then select the desired Web Config Mode (e.g. HTTP/HTTPS). Tap the back arrow and then select Save Config which will immediately reboot the phone.

After the phone has rebooted tap the hamburger menu in the top left corner and look for the device’s IP address as displayed in the menu (e.g. 192.168.1.167).

Open a web browser on a workstation and connect to the IP address using either HTTP or HTTPS, based on the previously-configured option(s) (e.g. https://192.168.1.167) and then sign in using the Admin account. (The default password is ‘456’.)

Go to the Utilities > Import & Export Configuration menu and then click Choose File under the Import Configuration section.

Select the previously created configuration file (e.g. Trio_RealConnect.cfg) and then click Import which should immediately trigger the Trio to reboot.

Behavior

After the phone reboots the additional line button (e.g. “Teams Meeting”) should appear on the home screen indicating that the new parameters were successfully imported. The new “Teams Meeting” line key can be used to simple call directly into the RealConnect Service’s entry queue which will prompt for the specific meeting’s video conferencing ID. The Meetings button on the home screen will provide a Join button which can be used to connect directly into a scheduled Teams meeting.

USB Mode

This mode simply turns the Trio into a USB-only audio device for when it will be physically connected to any supported Microsoft system like the Microsoft Teams Room or a Surface Hub. The Trio no longer performs any registration and is turned into an accessory to perform as a microphone and speaker.

Configuration

On the Trio access the Settings menu and navigate to Advanced > Administration Settings > Network Configuration > Base Profile and then select the Microsoft USB Optimized option. Tap the back arrow and then select Save Config which will immediately reboot the phone.

Behavior

Once the phone reboots a very simple interface will appear. When the connected room system is not in an active call the display is relegated to only showing the Date and Time. When the connected room system is in a call then the Trio will display a call timer along with Mute and End Call buttons.

Filed under Poly · Tagged with 3PIP, CVI, Trio, VTC

Customizing Microsoft Teams Meeting Invitations

July 31, 2019 by Jeff Schertz · 72 Comments

This brief article covers the customization of meeting invitations for Microsoft Teams for two different purposes. One is focused on reviewing the same basic branding options which were previously made available in Skype for Business and have recently come to Microsoft Teams, while the other is related to the additional invitation details which are part of the Microsoft Cloud Video Interop (CVI) solution.

Organization Information

A feature that has been available since Lync Server was the ability to perform some limited customization of what automatically appears in Lync or Skype meeting invitations created in Outlook. These options were limited to simply adding a small image file, typically used for adding a company logo, providing one or two additional URLs which would appear as links for users to find additional help or legal information, and adding basic text to a footer to contain any additional instructions.

This capability has recently been brought to Microsoft Teams by way of the Microsoft Teams Admin Center. To globally configure any of these options for all users in the tenant simply follow these steps.

Browse to Meetings > Meeting settings in the navigation pane.

Under the Email invitation section configure any or all of the desired fields.

The Logo URL field should be populated with a publicly available link to a .JPG or .PNG image file that is no larger than 188×30 pixels. The file itself is not embedded in the invitation, only an HTML link is added which will load the source image if it is accessible on the client reviewing the invitation.

The Legal URL and Help URL fields can optionally be populated with any URL, although the link titles will only appear as ‘Legal’ and ‘Help’ in the actual invitation.

The Footer can contain only standard, unformatted text and is limited to 255 characters. This text will appear in the invitation exactly as entered, so if HTML code was used, for example, then that would appear as raw HTML code in the invite as well.

Once customization is complete click the Preview button to see an example of what the meeting invitation will look like.

Note that the formatting in the preview will not look exactly as it will in a real invitation and the logo image is not currently displayed here either. Also, if Cloud Video Interop is enabled on the tenant the additional VTC meeting information does not appear in the preview.

Once the desired results are seen then click the Save button at the bottom of the page to apply the changes to the tenant.

In order to see the final results simply schedule a new Teams meeting invitation using any of the supported clients, although it may take several hours after saving the changes before they begin to appear in new invitations. As this change only applies to new invitations then obviously any previously scheduled Teams meetings created by any users in the tenant will remain unchanged.

Cloud Video Interop Details

Another minor, yet important detail which can be customized in Microsoft Teams meeting invitations is the hostname provided in the video conferencing device details provided by the Cloud Video Interop service. By default when a tenant enables CVI for Microsoft Teams they would typically be using the 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 the Poly services resident in various Azure data centers worldwide.

Users who are enabled for this service will have additional information provided in their Teams meeting invitations specifically designed to allow standards-based video endpoints to join. This information appears under the “Join with a video conferencing device” section, as seen below.

Note that the standard configuration utilizes the CVI provider’s domain highlighted above, but if desired this can be customized to use any hostname which is part of an owned domain namespace.

A custom hostname can either be configured during the initial CVI configuration steps or after the solution has already been enabled.

Configure DNS

Before making any changes to the Microsoft Teams configuration a new custom hostname must be selected, configured, and allowed to replicate through DNS servers.

Select a new hostname in the desired domain (e.g. video.msteams.net).
Connect to the administration portal or application for the DNS provider or service which currently manages DNS records for the selected domain (e.g. msteams.net) and create a new DNS Alias (CNAME) record for the desired hostname which points to ‘t.plcm.vc‘.

Wait for some time to pass and then check to see if the new record has replicated throughout the Internet sufficiently. Public DNS servers like Google (8.8.8.8) or Cloudflare (1.1.1.1) can give a good indication of replication status.

To check if the new DNS record is available open a command prompt and run the following nslookup command.

nslookup video.msteams.net 8.8.8.8

Once the new record has replicated then a successful resolution should look like the results shown above, where the ‘t.plcm.vc‘ record is listed as an alias. Now the custom hostname is ready to be added to the Teams invitations.

Configure Meeting Invitation

Now that the desired DNS record has been configured and replicated sufficiently the meeting invite creation process can be updated to leverage this new hostname. Again, this change will only apply to newly created meetings so any previously scheduled Teams meetings will still display the originally configured hostname.

- Open Windows PowerShell and connect to the Skype for Business Online PowerShell module using the following cmdlets, replacing the highlighted portion with the username of an administrative account in the target Office 365 tenant. Enter the account password when prompted.

Import-Module SkypeOnlineConnector
$skype = New-CsOnlineSession -UserName “jeff@msteams.net”
Import-PSSession $skype

To verify if CVI is already configured on this tenant run the Get-CsVideoInteropServiceProvider cmdlet.

Get-CsVideoInteropServiceProvider

In this example the Polycom provider was already configured in the tenant and is using the default hostname.

In the following command the configuration will be changed to replace the existing ‘t.plcm.vc‘ hostname with the customized ‘video.msteams.net‘ hostname.

To change the hostname use the Set-CsVideoInteropServiceProvider cmdlet to update the required parameters.

Set-CsVideoInteropServiceProvider -Identity “Polycom” -TenantKey “680450644@video.msteams.net” -InstructionUri “https://dialin.plcm.vc/teams/?key=680450644&conf={ConfId}&domain=video.msteams.net“

The Identity parameter should match the identity shown in the previous cmdlet for the currently selected service provider.

The TenantKey parameter needs to include the same numeric string shown in the existing configuration, with only the hostname changing to the desired string. Any incorrect changes to the tenant key will render CVI unfunctional for newly scheduled meetings.

The InstructionUri parameter also needs to be updated to include an additional value for the domain which is leveraged by the Poly One Touch Dial app and service in order to identify the target FQDN in Teams meetings.

If this was a new CVI configuration then simply use the guidance above when initially running the New-CsVideoInteropServiceProvider cmdlet.

Once sufficient replication time has elapsed (typically within 8 hours) then the new hostname should begin to appear in new Teams meeting invitations. The example invitation shown here includes both the custom organization details outlined earlier in this article and the custom CVI hostname.

Filed under Teams · Tagged with CVI, RealConnect

RealConnect for Clariti

March 15, 2019 by Jeff Schertz · 30 Comments

Several previous articles on this blog have gone into details on the Polycom RealConnect video interoperability solution for Lync and Skype for Business meetings. Most recently this article attempted to clarify all the different models available to various Polycom video infrastructure and Microsoft Skype for Business deployments across on-premises installations, cloud offerings, and hybrids of both.

As a refresher the entire Polycom RealConnect solution falls into two main categories: RealConnect for Clariti and the RealConnect Service. This article will focus on the available models which leverage a traditional on-premises deployment of standards-based infrastructure included in the Polycom RealPresence Clariti licensing model.

Two recent advances have occurred in the RealConnect solution set:

The expansion of RealConnect to include support for Microsoft Teams meetings. This compatibility was initially launched last year in the RealConnect Service to support connecting standards-based Video TeleConferencing (VTC) endpoints into Microsoft Teams meetings, and is now also available in the RealConnect for Clariti model which allows on-premises video meetings to be cascaded into Microsoft Teams meetings.

The introduction of an simplified deployment model for supporting Skype for Business Online meetings in RealConnect for Clariti. Previously in order to support Skype for Business Online meetings the Polycom infrastructure components required that at minimum a single Lync or Skype for Business Front End server/pool and a single Edge server/pool remained on-premises. That is no longer the case via the introduction of a light-weight, stateless application which now allows for all components of Lync or Skype for Business to be removed.

Infrastructure

The core Polycom Server infrastructure components which are provided within the Clariti licensing model have been covered in a previous article, so refer to it for a deeper understanding of the overall solution and what each server is and does. As a brief summary though, the Polycom Servers used throughout some or all of the RealConnect for Clariti architectures are as follows:

Distributed Media Appliance (DMA) is a core component which, for the purposes of RealConnect, primarily handles the signaling between each component and an on-premises Lync or Skype for Business Server Front End server or pool. The DMA also provides for VTC endpoint registration and manages the Polycom Multipoint Control Unit (MCU).

Collaboration Server (RMX) is the aforementioned MCU which supports both standards-based and Microsoft-specific media codecs. In some models it performs the transcoding duties between the standards-based media and the Microsoft media streams coming from and going to the Lync/SfB MCU.

ContentConnect Solution (CCS) is an additional software-only MCU that was created solely to transcode content sharing sessions between standards-based protocols like H.239 and Binary Floor Control Protocol (BCFP) into Microsoft’s sharing protocols like Video-Based Screen Sharing (VBSS) and Remote Desktop Protocol (RDP).

There are also two additional Polycom Servers which are not included as part of the Clariti licensing.

Workflow Server (WS) is an application server which can host several different Polycom application-based solutions. For RealConnect this server has two potential purposes: primarily performing Skype meeting discovery tasks as well as hosting the optional One Touch Dial (OTD) application for VTCs. Installation and configuration of this server is provided via paid professional services engagements.

Cloud Relay (CR) is similar to the Workflow Server except that is a lightweight, freely available virtual server image which, once imported into a VMware or Hyper-V host, is used to connect to Polycom and/or Microsoft services in Azure. This server can be utilized for multiple capabilities in RealConnect alone, as well as for other Polycom services, like some endpoint management tasks unrelated to RealConnect. For the purpose of RealConnect for Clariti though it is used to house a Microsoft SIP adapter which handles signaling communications between the DMA/RMX/CCS components and Skype for Business Online.

Topologies

There are currently 4 different topologies available wit RealConnect for Clariti which provide the RealConnect experience for Microsoft meeting platforms: Skype for Business Server, Skype for Business Hybrid, Skype for Business Online, and Microsoft Teams.

Skype for Business Server

This is the original deployment model for RealConnect, first introduced with Lync Server 2013, and continues to be supported today through Skype for Business Server. This solution is based on the core video infrastructure running on DMA, RMX, and CCS which performs the necessary translation between standards-based and Skype for Business protocols and codecs.

The basic call flow for the first VTC attempting to call into a Skype meeting hosted on the Skype for Business Server is as follows:

A VTC that is registered (via SIP or H.323) to the DMA places a call to the numeric Audio Conferencing ID included in the Skype meeting (e.g. 789456) over the endpoint’s preferred dialing protocol.

The DMA parses its preconfigured Dialing Rules and through a process of elimination determines that dialed string (e.g. 789456) is not another registered endpoint or a statically defined traditional Virtual Meeting Room (VMR) and then attempts to check with any configured external SIP peers.

Using Microsoft SIP over a secure TLS outbound connection via an established Trusted Application Pool configuration with the Skype for Business Front End server the DMA asks if there is a Skype meeting with that Audio Conferencing ID. If one exists then the server responds to the DMA with the Skype Meeting URL (e.g. https://meet.msteams.net/jschertz/ABCD1234).

The DMA then dynamically creates a new VMR using the conferencing ID (e.g. 789456) on the RMX and then directs the VTC to establish media with the RMX. These media sessions are utilizing standards-based protocols and codecs like Advanced Video Coding (AVC), various audio codecs, and potentially content sharing sessions over H.239 or Binary Floor Control Protocol (BFCP).

The DMA also instructs the RMX to place an outbound call from that same VMR into the resolved Skype for Business meeting. The RMX establishes a native Microsoft media session with the Audio Video Multipoint Control Unit (AVMCU) running the Skype for Business Front End server. These media sessions can utilize Scalable Video Coding (SVC) via the X-H264UC protocol, RealTime Video (RTV), and a host of common audio codecs.

The DMA similarly instructs the CCS to establish a connection to the Application Sharing Multipoint Control Unit (ASMCU) on the Skype for Business Front End server. The media sessions can support SVC desktop sharing over Video-Based Screen Sharing (VBSS) and Remote Desktop Protocol (RDP).

At this point the cascaded RealConnect meeting has been established and any additional VTCs attempting to join the same meeting will be connected directly to the active VMR.

Skype for Business Hybrid

Once on-premises deployments of Lync and Skype for Business Server began connecting to Lync and Skype for Business Online tenants an updated solution was required to support RealConnect for meetings hosted by users homed online. Supporting these split-domain hybrid environments required a wholesale change in the way that Lync/Skype Meetings were discovered and connected to as compared to when simply working with only an on-premises deployment.

The Polycom Workflow Server was thus introduced to tackle this new workflow which would provide a solution for supporting meetings scheduled by not only server-homed Lync/Skype users but also any online-homed users which had been migrated to the cloud. Whereas in the Skype for Business Server model the DMA dynamically performs the meeting discovery when the VTC places the call, in this model the meeting discovery happens prior to the call being placed. In fact, the Workflow Server handles this after the meeting is scheduled, but before any endpoints attempt to connect. Thus, when a Skype meeting is scheduled by a client that meeting invitation must pass through Workflow Server in order for RealConnect to be available for that meeting. Typically this is not an issue as a meeting room needs to be invited to leverage the One Touch Dial workflow. But in order to insure that an unscheduled VTC can join, even when manually dialing a provided audio conferencing ID in the meeting then there are two basic methods available. Either by instructing users to always invite a special, dedicated resource mailbox to all Skype meetings (crude, yet effective) or by defining an Exchange Transport Rule (supported in both Exchange Server or Exchange Online) which identifies Skype meetings and automatically sends a copy of the message to a single dedicated resource mailbox (more elegant). In either approach the Workflow Server is configured to monitor that mailbox and thus will be aware of every Skype meeting scheduled in the organization, where it will scrub the email for the meeting URL and then proactively provide it to the DMA.

Thus, the basic call flow for the first VTC joining a meeting hosted in Skype for Business Online is similar to the previous model, except for the fundamental difference in the initial Skype meeting discovery process.

A Skype meeting is scheduled in the environment and the invitation is seen by Workflow Server within a matter of minutes. Workflow Server identifies the embedded Skype Meeting URL and then either records the existing Audio Conference ID or dynamically creates a unique ID (if the Skype meeting invite does not include any Audio Conferencing details) which is used only for the DMA to generate a new VMR number.

The Workflow Server takes this information and then sends it to the DMA, essentially instructing it to create a static VMR using the provided ID and Skype Meeting URL.

Now, when a DMA-registered VTC attempts to join this Skype meeting the DMA will recognize that the call matches a VMR already defined in its own database which includes the destination Skype Meeting URL.

From this point on the remainder of the call setup is nearly identical to what happens in the Skype for Business Server model explained earlier. The only difference is that now outbound media sessions for online meetings can cascading directly to MCU resources in Skype for Business Online. Meetings hosted by the on-premises MCU for server-hosted users are still cascaded in the same fashion as in the previous section, and in either case the same transcoding workloads are still all occurring on the Polycom Servers on-premises.

Skype for Business Online

Providing the RealConnect solution for environment using only Skype for Business Online requires the most on-premises Polycom components of any of the RealConnect modes. This is because not only is the heavy lifting still all being performed by Clariti itself (communicating directly to Microsoft components via MS-SIP and transcoding audio, video, and content sharing media streams), but now in the absence of any on-premises Lync/Skype for Business Server the Polycom Server components require something local to communicate with via Microsoft SIP.

The core components of DMA, RMX, and CCS perform the same roles as in the previous topologies. The Workflow Server is still required here as it is in the hybrid topology to handle Skype meeting discovery and population into the DMA database. The main difference is that the Cloud Relay (CR) server is now added to host a Microsoft SIP gateway and provide the needed communication link between the Polycom Servers and Skype for Business Online.

Previously the Polycom Servers would each communicate using Microsoft-SIP directly to the local Lync/Skype for Business Front End Server/Pool via the standard Trusted Application model. Recently that architecture has changed to allow the removal of all on-premises Skype for Business servers. The Cloud Relay allows this by hosting a small Microsoft SIP adapter which the Polycom Servers instead communicate with as a bridge to Skype for Business Online. Note that this is only signaling traffic and no media traverses the Cloud Relay. Media will go directly from the RMX and CCS to MCU resources in Skype for Business Online, typically across the public Internet, into the Microsoft Azure Cloud. The Cloud Relay provides additional assistance here by also using its default connectivity to resident Polycom Services in Azure (which are a core part of the separate RealConnect Service, but incur no additional licensing cost here) in order to leverage media-establishment by way of ICE/STUN/TURN components. Again, this communication is limited to signaling, meaning that ICE instructions are provided by the service but the actual media communications are directed toward the Skype for Business Online Edge services in the cloud.

Microsoft Teams

Providing a solution into Microsoft Teams meetings with RealConnect for Clariti is the simplest and lightest (in terms of required on-premises components) of any model to-date. This is because the bulk of the work has been shifted to the cloud, adjacent to the Microsoft Teams services. Whereas for Skype meetings the Polycom infrastructure is dealing with all the translation and transcoding on-premises, that workload is all handled for Teams meetings by the Polycom RealConnect Service in the Azure cloud. The main reason for this difference is that the CVI solution provided by Microsoft requires partners to use components resident in Azure that communicate directly into Teams, which Microsoft provides in the way of SDKs and bots. So, in this model the Clariti components are simply cascading standards-based calls up into the RealConnect service in Azure, which in turn handles the signaling translation and media transcoding workloads with Teams.

As can be inferred from the following diagram the overall call flow is equally simplified from the Skype for Business models discussed earlier. The only technical requirement in this topology is that the DMA is running at least version 10.0.0.2 which includes new Dial Rule functionality for cascading into Teams meetings. None of the other Polycom Servers shown in the previous diagrams are required for supporting Teams meetings.

In regards to the call flow The primary difference between Skype and Teams here is that Polycom Servers do not need to perform and meeting discovery, as the Teams meeting invitations already include all the necessary standards-based details. This information is provided in the original Teams meeting as described in this article.

A VTC places a call to the SIP or H.323 address provided in the Teams meeting invitation (e.g. 123456.321654987@t.plcm.vc).

The DMA parses its preconfigured Dialing Rules and finds a match for the destination domain of “*.plcm.vc” on a specific dial rule. It then dynamically creates a new VMR using the Video Conferencing ID extracted from the dial string (e.g. 321654987) and then directs the VTC to establish the call with the RMX.

The DMA also places an outbound, standards-based SIP or H.323 call to the original dial string (e.g. 123456.321654987@t.plcm.vc) which is the Polycom RealConnect Service. It then instructs the RMX to establish outbound media connections from the local VMR (321654987) to the target meeting in the cloud, using standards-based media protocols and codecs.

The single cascade between the VMR on the RMX and an MCU in the RealConnect Service is then relayed in the Microsoft Teams meeting through the CVI gateway services to provide audio, video, and any screen sharing media between platforms.

Once the cascade has been established then any additional VTCs calling into the same meeting will be directed to connect to the active VMR on the RMX.

Realistically though most organizations will need to support RealConnect for both Skype and Teams meetings for some time to come. This means that multiple models would be used in conjunction, one of the Skype models depending on the type of Skype deployment, and the Teams model. Due the fact that the architectures are completely different, yet both leverage the core Clariti components of DMA and RMX then a single deployment can easily support any of the Skype and Teams scenarios simultaneously. What this also means for all deployments is that over time as Skype meetings are replaced by Teams meetings then the overall footprint of Polycom infrastructure components can systematically be removed as they are no longer needed.

Licensing

As Skype for Business Meetings are handled completely by Clariti then licensing is already included in the Clariti model. But for supporting Teams meetings where some of the work is performed by the cloud service then an additional concurrent-use licensing fee is required. These low-lost licenses are supplementary to the base Clariti concurrent licenses and would be acquired at a 2:1 ratio. Meaning if an organization was licensed for 10 Clariti concurrent licenses, then no more than 5 of the additional service licenses would be purchased. This one-half calculation comes from the fact a single Teams meeting being joined by a single VTC will consume two Clariti concurrent licenses to stand up the call. One license is used to connect the VTC to the RMX, and a second license to consumed to cascade that VMR on the RMX to the RealConnect Service.

For example, take an environment with 10 Clariti licenses and 5 VTCs. If all VTCs were to connect to five different Teams meetings at the same point in time the RMX would be at full capacity by the 5th meeting (5 VTCs + 5 cascades = 10 Clariti licenses consumed), which is the high-water mark. Because a maximum of 5 meetings can be cascaded into the RealConnect service, then 5 RealConnect for Clariti service licenses are required at most for this environment.

Yet in the event that all 5 VTCs were to join the same Teams meeting then the RMX would only be using 6 Clariti licenses (5 VTCs + 1 cascade = 6) and only a single RealConnect for Clariti service license would be consumed.

Filed under Poly · Tagged with RealConnect, VTC

Verifying Users Enabled for CVI

March 13, 2019 by Jeff Schertz · 3 Comments

This brief article includes a few tips on how to verify which Office 365 user account have been enabled to use a partner-provided Cloud Video Interop (CVI) solution, like the Polycom RealConnect Service.

When initially configuring an Office 365 tenant for CVI one of the final steps is to enable user accounts for the service. The steps to do so though are different between Skype for Business and Microsoft Teams.

Note that in order to perform the PowerShell commands shown in this article one or more PowerShell Online modules will need to be setup on the workstation, if not already configured. One potentially confusing concept in this article to pay extra attention to is that in order to check the Teams configuration the Skype for Business Online PowerShell Module is used (this module contains both Skype and Teams cmdlets), yet to check the Skype configuration the Azure Active Directory (v1) module is used. This is because Teams uses a simple user setting via a policy while Skype leverages Office 365 add-on licenses.

Microsoft Teams

To enable the service for users on their own scheduled Microsoft Teams meetings the configuration is straightforward. A simple PowerShell cmdlet would have been used to enable either individual users or the entire tenant globally.

Open Windows PowerShell and connect to the Skype for Business Online PowerShell module using the following cmdlets, but replacing the highlighted portion with the username of an administrative account in the target Office 365 tenant. Enter the account password when prompted.

Import-Module SkypeOnlineConnector
$skype = New-CsOnlineSession -UserName “jeff@msteams.net”
Import-PSSession $skype

Verify Service Configuration

The Get-CsVideoInteropServiceProvider cmdlet can be used to confirm which service provider the tenant has been configured to use.

Get-CsVideoInteropServiceProvider

Verify User Configuration

The preferred methodology for initially enabling users with RealConnect for Teams is to grant a policy to specific user accounts versus enabling the entire tenant wholesale. This approach is more common with initial testing and is often used with a small amount of select accounts.

The Get-CsTeamsVideoInteropServicePolicy cmdlet can then be used to identify if the preferred provider has been enabled globally for all users or not.

As the service must be turned on in a tenant this can be confirmed by validating that the ProviderName parameter on the global policy is assigned to the default setting of DefaultProvider.

Get-CsTeamsVideoInteropServicePolicy

Note that the DefaultProvider value in the Global policy above is the ProviderName for the ServiceProviderDisabled option.

Alternatively if the cmdlet results return one of the provider names (e.g. Polycom) then this indicates that the service has been enabled for every user in the organization, at the global level.

Get-CsTeamsVideoInteropServicePolicy

Note that the DefaultProvider value in the Global policy above is the ProviderName for the Polycom option. In this case the environment has previously been configured to enable RealConnect for Teams with all user’s scheduled Teams meetings.

But for environments still using the default disabled policy setting then individual user accounts would need to have been enabled. In order to identify these account the Get-CsOnlineUser cmdlet results can filtered to output only accounts which have the TeamsVideoInteropServicePolicy parameter set to the desired value.

Enter the following command to list only users which are enabled for the Polycom RealConnect Service for Microsoft Teams.

Get-CsOnlineUser -Filter {TeamsVideoInteropServicePolicy -eq ‘PolycomServiceProviderEnabled‘} | Select-Object DisplayName, UserPrincipalName, TeamsVideoInteropServicePolicy

In this example the Polycom service is being used, so the value to search for is ‘PolycomServiceProviderEnabled‘. Currently other possible parameter values are ‘BlueJeansServiceProviderEnabled‘, ‘PexipServiceProviderEnabled‘, or ‘ServiceProviderDisabled‘.

Alternately, this cmdlet can be used to list all accounts in the tenant regardless of the policy parameter value.

Get-CsOnlineUser | Select-Object DisplayName, UserPrincipalName, TeamsVideoInteropServicePolicy

In the event that the TeamsVideoInteropServicePolicy has been previously set to a specific provider globally, then the individual user’s policy setting will operate in the standard policy relationship. This means that any users with no value currently on their parameter will use the Global policy setting, but if the user’s parameter is set to a different value then the user-specific value will take precedence over a different, globally assigned value.

CVI User Status	TeamsVideoInteropServicePolicy
CVI User Status	Tenant	User
Disabled	ServiceProviderDisabled	null (or) ServiceProviderDisabled
Enabled	ServiceProviderDisabled	<PartnerName>ServiceProviderEnabled
Enabled	<PartnerName>ServiceProviderEnabled	null (or) <PartnerName>ServiceProviderEnabled
Disabled	<PartnerName>ServiceProviderEnabled	ServiceProviderDisabled

In the event that the tenant is globally enabled yet it is desired to return to the default configuration to instead manage user enablement individually then this is a simple procedure.

Execute the following cmdlet to return the global policy the ServiceProviderDisabled setting.

Grant-CsTeamsVideoInteropServicePolicy -PolicyName ServiceProviderDisabled

Skype for Business

Unlike Microsoft Teams there is no option to simply globally enable the service on all users in a tenant for Skype meetings. User configuration in Skype for Business is handled by assigning an Office 365 add-on license entitled “Skype for Business Video Interop for Skype for Business”.

Because this solution is user-license based then enough licenses must be provided in the tenant and they must all be manually assigned to existing user accounts, as well as added to new user accounts as they are created in the environment.

License entitlement is performed automatically through the Cloud Solutions Provider relationship with the partner and one license will automatically be added to the tenant for every existing qualifying user license that exists in the tenant (e.g. Business Essentials, Enterprise E5, etc). For example, the tenant used in this article currently contains 20 Enterprise E1 licenses and 4 Enterprise E3 licenses, hence the total of 24 Video Interop licenses.

Given that Microsoft licenses are the components which enable the service for users then it is trivial to list all users in the tenant via PowerShell which are assigned a specific license.

Open Windows PowerShell and connect to the Azure Active Directory PowerShell module using the Connect-MsolService cmdlet. When prompted enter the credentials of an administrative account for the Office 365 tenant.

Connect-MsolService

Enter the following command to parse all user accounts and list only those with an assigned license containing the string ‘Video’.

Get-MsolUser | Where-Object {($_.licenses).AccountSkuId -match “Video“} |ft UserPrincipalName,DisplayName,Licenses

The output above lists any user accounts currently assigned a VIDEO_INTEROP license.

Filed under Skype, Teams · Tagged with CVI, RealConnect, Troubleshooting, VTC

RealConnect Service Network Communications Explained

March 5, 2019 by Jeff Schertz · 30 Comments

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.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:

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.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.

Filed under Poly · Tagged with CVI, RealConnect, VTC

« Previous Page — Next Page »

Search for:

Tag Cloud
3PIP | Administration | Certificates | CVI | CX | Deployment | Edge | Events | LPE | Management | Media | OTD | RealConnect | Software | Teams Phones | Teams Rooms | Tips | Trio | Troubleshooting | VTC | VVX
Latest News
- Loading tweets...
Follow @jdscher
Archives
- [+]2021 (3)
  - [+]April (1)
  - [+]March (1)
  - [+]January (1)
- [+]2020 (8)
  - [+]December (1)
  - [+]September (1)
  - [+]August (1)
  - [+]May (2)
  - [+]April (2)
  - [+]January (1)
- [+]2019 (11)
  - [+]November (1)
  - [+]October (1)
  - [+]September (1)
  - [+]August (2)
  - [+]July (1)
  - [+]March (3)
  - [+]February (1)
  - [+]January (1)
- [+]2018 (11)
  - [+]December (1)
  - [+]November (1)
  - [+]October (2)
  - [+]July (1)
  - [+]June (1)
  - [+]May (2)
  - [+]April (1)
  - [+]February (2)
- [+]2017 (11)
  - [+]December (1)
  - [+]November (2)
  - [+]August (2)
  - [+]July (1)
  - [+]May (2)
  - [+]April (1)
  - [+]February (1)
  - [+]January (1)
- [+]2016 (12)
  - [+]December (1)
  - [+]October (1)
  - [+]September (1)
  - [+]August (1)
  - [+]July (1)
  - [+]June (1)
  - [+]May (1)
  - [+]April (1)
  - [+]March (2)
  - [+]February (1)
  - [+]January (1)
- [+]2015 (22)
  - [+]December (1)
  - [+]October (4)
  - [+]September (4)
  - [+]August (1)
  - [+]July (1)
  - [+]June (2)
  - [+]May (1)
  - [+]April (4)
  - [+]March (2)
  - [+]January (2)
- [+]2014 (22)
  - [+]November (2)
  - [+]October (4)
  - [+]September (1)
  - [+]August (2)
  - [+]July (1)
  - [+]June (2)
  - [+]May (2)
  - [+]April (3)
  - [+]March (2)
  - [+]February (2)
  - [+]January (1)
- [+]2013 (24)
  - [+]December (1)
  - [+]November (1)
  - [+]October (3)
  - [+]September (3)
  - [+]August (2)
  - [+]July (2)
  - [+]June (2)
  - [+]May (3)
  - [+]April (1)
  - [+]March (3)
  - [+]February (1)
  - [+]January (2)
- [+]2012 (29)
  - [+]December (4)
  - [+]November (1)
  - [+]October (4)
  - [+]September (2)
  - [+]August (3)
  - [+]July (4)
  - [+]June (1)
  - [+]May (3)
  - [+]April (2)
  - [+]March (2)
  - [+]February (1)
  - [+]January (2)
- [+]2011 (26)
  - [+]December (2)
  - [+]November (1)
  - [+]October (3)
  - [+]September (1)
  - [+]August (3)
  - [+]June (2)
  - [+]May (4)
  - [+]April (2)
  - [+]March (2)
  - [+]February (3)
  - [+]January (3)
- [+]2010 (33)
  - [+]December (2)
  - [+]November (9)
  - [+]October (4)
  - [+]September (7)
  - [+]June (2)
  - [+]May (1)
  - [+]March (2)
  - [+]February (1)
  - [+]January (5)
- [+]2009 (26)
  - [+]November (1)
  - [+]September (3)
  - [+]August (6)
  - [+]July (1)
  - [+]June (3)
  - [+]May (1)
  - [+]April (4)
  - [+]March (3)
  - [+]February (2)
  - [+]January (2)
- [+]2008 (20)
  - [+]December (1)
  - [+]November (1)
  - [+]October (4)
  - [+]September (1)
  - [+]August (4)
  - [+]July (2)
  - [+]June (1)
  - [+]May (2)
  - [+]April (2)
  - [+]March (2)
- [+]2007 (7)
  - [+]December (1)
  - [+]November (4)
  - [+]October (2)

Accessing the Portal

Activate Initial Account

Dashboard

Call Summary

Call Concurrency

Devices

Conferences

Customization

Calls

Summary

Map

List

Additional Examples

License Overage

License Overage with Soft Ceiling

Investigating the New Cmdlets

Sign In Mode

UserSignIn

Calls

Calendar

Voicemail

MeetingSignIn

CommonAreaPhoneSignIn

Review Configuration

Calendar Configuration

Scenario 1 – Interop

H.323 Configuration

SIP Configuration

Dialing Preference

One Touch Dial Configuration

Scenario 2 – Mixed Mode

SIP Configuration

H.323 Configuration

Dialing Preference

One Touch Dial Configuration

Configuration

Confirmation

Background

Native Mode (Audio Only)

Configuration

Behavior

Gateway Mode (Audio Only)

Configuration

Behavior

Hybrid Mode

Configuration

Behavior

USB Mode

Configuration

Behavior

Organization Information

Cloud Video Interop Details

Configure DNS

Configure Meeting Invitation

Infrastructure

Topologies

Skype for Business Server

Skype for Business Hybrid

Skype for Business Online

Microsoft Teams

Licensing

Microsoft Teams

Verify Service Configuration

Verify User Configuration

Skype for Business

Service Overview

Basic Architecture

Locations

Connectivity

Network Communications

Ports and Protocols

Destinations

Example Call

Tag Cloud

Latest News

Archives