Data Nuances

User Id in multiple tenants

In the aggregate tables, it is possible to see a userid appear as both usertype = 1 and usertype = 2 (internal and external) In the stream table it is also possible to see a userid appear as both usertype = 1 and usertype = 2 (internal and external)

This is because there are some bot endpoints (such as TogetherMode user/app id = 9cd07db6-fab5-438c-8e34-44117fac7650)that are registered under the same user/bot id in multiple tenants.

If your users join an externally hosted meeting, and one of their bots enters the meeting, a stream (and subsequently aggregate row), will appear for an external user(the bot), but with the same userId as already recorded as in your tenant.

These will mostly be hidden from reporting because the records don’t match back to an actual registered user in AD (they are bots, not users)

Calls with default end times (negative duration)

A very small number of Call Records are returned from Microsoft with default end times (e.g. 0001-01-01 00:00:00 rather than 2021-01-20 20:30:14). These may be later superseded by newer versions of the Call Record returned by Microsoft. Call Records with default end times are considered incomplete data, and so TWA Performance discards them to avoid skewing its datasets.

Desktop share on PSTN call when sim ring is used

When you make a call in Teams desktop application (Setting–>Calls–>Also Ring and added PSTN number) that when someone calls you it should simultaneously should ring on your PSTN number provided.  An internal user is trying to call you 1:1 on Teams you are getting call in Teams application and on PSTN number as well, this is a sim ring behavior.

Isssue: You answer the call from Teams desktop application, but in the Native Call quality analytics report  shows that call was answered from mobile number and it was screen sharing session.
This screen sharing behavior on PSTN is not expected. A case has been raised with Microsoft product group and accepted as an incident. Microsoft have provided an ETA fix for end of Q4 2021.

Internal reference: 26319493

Call Failures

Internal Reference: 26123870

There are scenarios where a call failure can be deemed an “expected failure”.

For awareness: An example where this expected failure is seen would be calling a number then an IVR picks up, then simply leaving or hanging up. In this instance Microsoft deem this an expected failure, as the call did not fully complete and connect.

Call records API does NOT have a property value for determining these scenarios (excepted failures) therefore it can not be determined within the Data.

Other examples may exist for call failures where the behavior is perceived normal, however Microsoft deem the call a “failure” – if you have a high volume and example of these then please let us know where we may then assist with further understanding from Microsoft.

Modality can provide the following information based on a case raised to Microsoft:

• Graph API only relays what it shows from the Teams client.
• In technical terms for Teams, when the call didn’t complete and connect, it “failed” – this is not a failure for the end user but technically it is a failure in Teams.
  
  Update: 29/9/2021
  Microsoft have acknowledged the issue, the product Group are working for fix with an ETA October.