SessionID in callRecord is not unique across calls

Phil Smith 36 Reputation points
2022-04-11T10:26:04.88+00:00

Your documentation states that a Call has a 1:n relationship with Sessions (ER Model diagram here: https://learn.microsoft.com/en-gb/graph/api/resources/callrecords-api-overview?view=graph-rest-1.0)

It also states that a SessionID uniquely identifies a session. (https://learn.microsoft.com/en-gb/graph/api/resources/callrecords-session?view=graph-rest-1.0)

This does not appear to be the case.

The image below shows JSON snippets of two calls, each containing the same SessionID. The relationship is therefore m:n. The key is therefore the compound of (CallID, SessionID).

Can you confirm that this is correct and your documentation is wrong?

191818-image.png

Microsoft Graph
Microsoft Graph
A Microsoft programmability model that exposes REST APIs and client libraries to access data on Microsoft 365 services.
11,083 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. JanardhanaVedham-MSFT 3,536 Reputation points
    2022-04-21T13:54:16.057+00:00

    Hi @Phil Smith ,

    I tried to replicate above mentioned issue at my side in my developer tenant and based on my testing, Call Records List Sessions API working as expected and as per the documentation. All session IDs are unique in each call's API response and I could n't find any session ID is being overlaped between these two calls.

    GET https://graph.microsoft.com/v1.0/communications/callRecords/{id}/sessions  
    

    Call 1 API response ::

    195127-image.png

    Call 2 API response : :

    195167-image.png

    If the issue still persist in your tenant then I would advise you to open a support case with Graph API team for a dedicated support and escalalating it to Microsoft engineering team to analyze it and further assistance. You can raise the case either from Azure portal or M365 admin center of your tenant.

    Hope this helps.

    If the answer is helpful, please click Accept Answer and kindly upvote it. If you have any further questions about this answer, please click Comment.

    0 comments No comments