Forum Discussion
Teams bot SDK - getting participants and events
Hi all,
I'm working on a Teams bot using the https://www.nuget.org/packages/Microsoft.Graph.Communications.Calls. So far what I managed to do is receiving incoming call events on the configured callback URL of the bot. But it seems those are the only events I get. When I hangup the call, I don't see any incoming events.
Also, I'm not able to get participant information. In the ICall object of the API there are several participant lists:
ICall.Participants
ICall.Resource.Participants
However, all of these containers are empty. Also when I examine the incoming call event XML data, I can't find a list of participants which explains why the lists are empty.
There is also a method to get a single participant. I tried to use that to get my participant like this:
await call.Participants.GetAsync(call.Resource.MyParticipantId);
But in the logging I see that it results in a 404 not found error...
request: GET https://graph.microsoft.com/v1.0/communications/calls/<callId>/participants/<participantId>
response: 404 NotFound
I can however answer the call. For this it sends:
https://graph.microsoft.com/v1.0/communications/calls/<callId>/microsoft.graph.answer
In teams I see that the call is answered.
Am I doing something wrong? Do I need to initialize something to get follow-up events of a call?
The examples in the https://github.com/microsoftgraph/microsoft-graph-comms-samples only leads up to answering the call, but not much further...
I hope someone can help me, I'm kinda stuck here...
Greetings
Johan
3 Replies
- Jose_Parada
Microsoft
Hello JohanJdm. Thanks a lot for choosing our SDK for your scenario!
I can take a couple guesses at what might be happening from what you describe. One possibility is that you are getting the notifications, but are not handling them properly: take a look at our IncidentBot sample, the part where it handles notifications (OnIncomingRequestAsync()).
As you can see any incoming notifications get put through ICommunicationsClient.ProcessNotificationAsync(HttpRequestMessage). This will make the SDK keep track of call state and roster for the ongoing call.
Another possibility that comes to mind is that you're setting the Callback URI on the Answer body to an URI where you're not listening for notifications. If you set this property when calling Answer, our service will send all subsequent notifications to the URI. If you don't set it, it will send the notifications to the same URI you use for incoming calls. Could it be your notifications are arriving to the wrong endpoint?
Since you mention you didn't find much more than how to Answer in our samples, I suggest you take a look at our IncidentBot sample which you might've missed: it contains an end to end example bot that can make calls, join calls, add participants and delete calls, all while keeping track of the call state properly.
If these suggestions don't help it'd be great if you could share with us the X-Microsoft-Skype-Chain-ID header for one of your calls (you should get one in the incoming call notification) so we can take a closer look at what's going on.
Hello Jose_Parada
Thanks for your answer!
It was indeed as you suggested that in the body of Answer command, the wrong URL was sent. We're using ngrok for generating a callback URI which at the time changed every time you start it. And I wasn't aware that I should update it on 2 locations (bot config in azure and application config).
However, in the SDK, it seems that setting the notification callback URI is mandatory. It will throw an exception when you try to build an ICommunicationsClient without setting the URI in the CommunicationsClientBuilder.
Another thing is that I have trouble to see who is calling. This information should be available in the "source" property of the call, but this doesn't seem to supply a name or address/phone number:
... "source": { "@odata.type": "#microsoft.graph.participantInfo", "identity": { "@odata.type": "#microsoft.graph.identitySet", "user": { "@odata.type": "#microsoft.graph.identity", "id": "GUID", "tenantId": "GUID" } }, "region": "emea", "languageId": "en-US", "id": "GUID", "endpointType": "(Generic: qZhQWg/4)" }I noticed that the source.identity.user.id property can be used to retrieve the identity from the user graph using the GraphServiceClient. But I'm not sure this is the way to go. It requires an extra query outside the comms SDK, and there is no calling device info (e.g. no calling address). Also the Identity.DisplayName property is available in the model, but it is not set.
Do I need to turn on some permissions or other settings to be able to get extra caller info? Or is this how it is supposed to work?
Also about the issue of not being able to get the call participants, it turns out that I'm not the only one with this problem https://github.com/microsoftgraph/microsoft-graph-comms-samples/issues/102#issuecomment-514261814. Luckily we only need to know the caller, and that is already in the source property.
I hope you can help me with the question about the caller info.
Greetings
Johan
- Jose_Parada
Hello JohanJdm. We indeed do not fill out the displayName for incoming calls to a bot. If you have the appropriate permissions you can look up all his registered information in Azure Active Directory or, as you mention, through MS Graph.
I'm not sure what you mean by calling address; if you'd like your bot to place an outgoing call to that user at a later time, the user ID should be all you need.
EDIT: I should've qualified my first statement: we do not always fill out displayName for incoming calls to the bot. Whether it's filled out or not depends on whether the displayName was sent in the call payload when the call was made. There are several situations where this can happen, for example, if the caller called from a PSTN number. In general, registered, non-guest Teams users calling your bot should usually provide a displayName for us to hand to your bot through the source Identity object displayName field.
