Forum Discussion
Teams bot SDK - getting participants and events
MicrosoftHello 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.