Notifications d’appel entrant

Dans l’inscription d’un bot d’appels et de réunions pour Microsoft Teams, le Webhook pour l’URL d’appel est mentionné. Cette URL est le point de terminaison de webhook pour tous les appels entrants à votre bot.

Détermination du protocole

La notification entrante est fournie dans un format hérité pour la compatibilité avec le protocole Skype précédent. Pour convertir l’appel au protocole Microsoft Graph, votre bot doit déterminer si la notification est dans un format hérité et fournit la réponse suivante :

HTTP/1.1 204 No Content

Votre bot reçoit à nouveau la notification, mais cette fois dans le protocole Microsoft Graph.

Dans une version ultérieure de la plateforme multimédia en temps réel, vous pouvez configurer le protocole pris en charge par votre application pour éviter de recevoir le rappel initial dans le format hérité.

La section suivante fournit des détails sur les notifications d’appel entrantes redirigées pour l’affinité de région vers votre déploiement.

Redirections pour l’affinité de région

Vous appelez votre webhook à partir du centre de données qui héberge l’appel. L’appel commence dans n’importe quel centre de données et ne prend pas en compte les affinités de région. La notification est envoyée à votre déploiement en fonction de la résolution GeoDNS. Si votre application détermine, en inspectant la charge utile de notification initiale ou autre, qu’elle doit s’exécuter dans un déploiement différent, l’application fournit la réponse suivante :

HTTP/1.1 302 Found
Location: your-new-location

Permettre à votre bot de répondre à un appel entrant à l’aide de l’API answer. Vous pouvez spécifier le callbackUri pour gérer cet appel particulier. Cela est utile pour les instances avec état où votre appel est géré par une partition particulière, et vous souhaitez incorporer ces informations dans le callbackUri pour le routage vers l’instance appropriée.

La section suivante fournit des détails sur l’authentification du rappel en inspectant le jeton publié sur votre webhook.

Authentifier le rappel

Votre bot doit inspecter le jeton publié sur votre webhook pour valider la demande. Chaque fois que l’API publie sur le webhook, le message HTTP POST contient un jeton OAuth dans l’en-tête Authorization en tant que jeton porteur, avec l’audience comme ID d’application de votre application.

Votre application doit valider ce jeton avant d’accepter la demande de rappel.

L’exemple de code suivant est utilisé pour authentifier le rappel :

POST https://bot.contoso.com/api/calls
Content-Type: application/json
Authentication: Bearer <TOKEN>

"value": [
    "subscriptionId": "2887CEE8344B47C291F1AF628599A93C",
    "subscriptionExpirationDateTime": "2016-11-20T18:23:45.9356913Z",
    "changeType": "updated",
    "resource": "/app/calls/8A934F51F25B4EE19613D4049491857B",
    "resourceData": {
        "@odata.type": "#microsoft.graph.call",
        "state": "Established"
    }
]

Le jeton OAuth a les valeurs suivantes et est signé par Skype :

{
    "aud": "0efc74f7-41c3-47a4-8775-7259bfef4241",
    "iss": "https://api.botframework.com",
    "iat": 1466741440,
    "nbf": 1466741440,
    "exp": 1466745340,
    "tid": "1fdd12d0-4620-44ed-baec-459b611f84b2"
}

La configuration OpenID publiée sur https://api.aps.skype.com/v1/.well-known/OpenIdConfiguration peut être utilisée pour vérifier le jeton. Chaque valeur de jeton OAuth est utilisée comme suit :

  • aud où l’audience correspond à l’URI de l’ID d’application spécifié pour l’application.
  • tid est l’ID de locataire pour Contoso.com.
  • iss est l’émetteur du jeton, https://api.botframework.com.

Pour la gestion du code, le webhook doit valider le jeton, vérifier qu’il n’a pas expiré et vérifier s’il a été signé par la configuration OpenID publiée. Vous devez également vérifier si l’authentification correspond à votre ID d’application avant d’accepter la demande de rappel.

Pour plus d’informations, consultez valider les demandes entrantes.

Étape suivante

Voir aussi