Direct Routing Calls API - Checking if auto attended calls were picked up

Copper Contributor

I'm using the Microsoft Graph API's direct routing calls endpoint to retrieve a list of inbound/outbound calls made by my organization.

We have auto attendant phone numbers that pick up incoming calls while they wait for a real user to pick up. If a real user picks up, two separate records are created: one for the autoattended call and another for the real call.

I want to know if there is a way to reliably correlate an autoattended call to its corresponding call with a real user or determine if an autoattended call was picked up.

Here are some observations I've made:

- Auto attended calls have the callType field as ByotInUCAP, while calls with real users have a callType ByotIn.
- Both autoattended and real calls have the same calleeNumber and callerNumber.
- Real calls have a startDateTime slightly earlier than the auto attended calls' endDateTime, but the time difference varies and is not a reliable indicator.
- Autoattended calls picked up by real users usually end with a finalSipCodePhrase similar to "Call has ended due to lack of participants," but this code is not always present.

Although I have identified some connections between these two types of calls, the relationship is still unreliable. I'm wondering if there might be other sources of information that I'm not aware of.

3 Replies

@Bemesko - Thanks for reporting your issue.
We will check this at with internal team and will get back to you once we get any update.

Thanks for the reply Sayali, I'll be available in case you need any more information.

Hello @Bemesko , we got the reply from internal team,

No, the direct routing API is only intended to return individual direct routing calls. It does not provide any correlation between separate calls or end-to-end experiences.

 

There are separate CQ/AA reports/APIs designed to support those use specific use cases: Auto attendant and Call queue historical reports - Microsoft Teams | Microsoft Learn. they would suggest using those as a primary tool for any CQ/AA reporting.

 

The more general callRecords API endpoint also does correlate individual call legs together into an overall experience, so that might also serve this particular need. It isn't designed for CQ/AA specifically, but it should integrate both call sessions into a single call record.