Concepts des appels entrants
Azure Communication Services Call Automation permet aux développeurs de créer des applications qui peuvent effectuer et recevoir des appels. Il tire parti des abonnements Event Grid pour remettre IncomingCall
des événements, ce qui rend crucial la configuration de votre environnement pour recevoir ces notifications pour que votre application redirige ou réponde efficacement à un appel. Par conséquent, la compréhension des principes fondamentaux des appels entrants est essentielle pour tirer parti du plein potentiel d’Azure Communication Services Call Automation.
Scénarios d’appel
Avant de configurer votre environnement, il est important de comprendre les scénarios qui peuvent déclencher un IncomingCall
événement. Pour déclencher un IncomingCall
événement, un appel doit être effectué à une identité Azure Communication Services ou à un numéro RTC (Public Switched Telephone Network) associé à votre ressource Azure Communication Services. Voici des exemples de ces ressources :
- Identité Azure Communication Services
- Numéro de téléphone RTC appartenant à votre ressource Azure Communication Services
Étant donné ces exemples, les scénarios suivants déclenchent un IncomingCall
événement envoyé à Event Grid :
Source | Destination | Scénario(s) |
---|---|---|
Identité Azure Communication Services | Identité Azure Communication Services | Appeler, rediriger, ajouter un participant, transférer |
Identité Azure Communication Services | Numéro RTC appartenant à votre ressource Azure Communication Services | Appeler, rediriger, ajouter un participant, transférer |
RTC public | Numéro RTC appartenant à votre ressource Azure Communication Services | Appeler, rediriger, ajouter un participant, transférer |
Remarque
Il est important de comprendre qu’une identité Azure Communication Services peut représenter un utilisateur ou une application. Bien que la plateforme ne dispose pas d’une fonctionnalité intégrée pour affecter explicitement une identité à un utilisateur ou une application, votre application ou infrastructure de prise en charge peut y parvenir. Pour en savoir plus sur cette rubrique, reportez-vous au guide des concepts d’identité.
Enregistrer le fournisseur de ressources Event Grid
Si vous n’avez jamais utilisé Event Grid dans votre abonnement Azure, vous risquez de devoir inscrire votre fournisseur de ressources Event Grid. Pour inscrire le fournisseur, procédez comme suit :
- Accédez au portail Azure.
- Sélectionner Abonnements dans le menu de gauche.
- Sélectionnez l’abonnement que vous utilisez pour Event Grid.
- Dans le menu de gauche, sous Paramètres, sélectionnez Fournisseurs de ressources.
- Recherchez Microsoft.EventGrid.
- Si le fournisseur de ressources n’est pas inscrit, sélectionnez Enregistrer.
Réception d’une notification d’appel entrant à partir d’Event Grid
Dans Azure Communication Services, la réception d’une IncomingCall
notification est rendue possible via un abonnement Event Grid. En tant que destinataire de la notification, vous avez la possibilité de choisir comment le gérer. Étant donné que l’API Call Automation tire parti des rappels webhook pour les événements, il est courant d’utiliser un abonnement Event Grid « Webhook ». Toutefois, le service propose différents types d’abonnements et vous avez la liberté de choisir celui qui convient le mieux à vos besoins.
Cette architecture présente les avantages suivants :
- À l’aide des filtres d’abonnement Event Grid, vous pouvez router la notification
IncomingCall
vers des applications spécifiques. - L’affectation de numéros RTC et la logique de routage peuvent exister dans votre application au lieu d’être configurées de manière statique en ligne.
- Comme indiqué dans la section scénarios d’appel, votre application peut être avertie même lorsque les utilisateurs effectuent des appels entre eux. Vous pouvez ensuite combiner ce scénario avec les API d’enregistrement d’appel pour répondre aux besoins de conformité.
Pour obtenir un exemple de charge utile de l’événement et plus d’informations sur d’autres événements appelants publiés dans Event Grid, reportez-vous à ce guide.
Voici un exemple d’abonnement Webhook Event Grid où le filtre de type d’événement écoute uniquement l’événement IncomingCall
.
Options de routage des appels avec Call Automation et Event Grid
Dans Call Automation et Event Grid, le routage des appels peut être adapté à vos besoins spécifiques. En utilisant des filtres avancés dans votre abonnement Event Grid, vous pouvez vous abonner à une notification qui concerne un IncomingCall
numéro de téléphone source/destination spécifique ou une identité Azure Communication Services. Cette notification peut ensuite être dirigée vers un point de terminaison, tel qu’un abonnement Webhook. À l’aide du Kit de développement logiciel (SDK) Call Automation, l’application de point de terminaison peut ensuite prendre une décision de rediriger l’appel vers une autre identité Azure Communication Services ou vers le RTC.
Remarque
Pour vous assurer que votre application reçoit uniquement les événements nécessaires, il est recommandé de configurer le filtrage dans Event Grid. Cela est particulièrement crucial dans les scénarios qui génèrent IncomingCall
des événements, tels que la redirection d’un appel RTC entrant vers un point de terminaison Azure Communication Services. Si un filtre n’est pas utilisé, votre abonnement Event Grid reçoit deux IncomingCall
événements : un pour l’appel RTC et un pour l’utilisateur Azure Communication Services, même si vous avez l’intention de recevoir uniquement la première notification. La négligence de gérer ces scénarios à l’aide de filtres ou d’autres mécanismes dans votre application peut entraîner des boucles infinies et d’autres comportements indésirables.
Voici un exemple de filtre avancé sur un abonnement Event Grid qui surveille la data.to.PhoneNumber.Value
chaîne à partir d’un numéro de téléphone RTC « +18005551212 ».
Affectation de numéro
Lorsque vous utilisez la IncomingCall
notification dans Azure Communication Services, vous avez la liberté d’associer un nombre particulier à n’importe quel point de terminaison. Par exemple, si vous avez obtenu un numéro de téléphone RTC et +14255551212
que vous souhaitez l’affecter à un utilisateur avec une identité de 375f0e2f-e8db-4449-9bf7-2054b02e42b4
votre application, vous devez conserver un mappage de ce numéro à l’identité. Lorsqu’une IncomingCall
notification est envoyée qui correspond au numéro de téléphone dans le champ à , vous pouvez appeler l’API Redirect
et fournir l’identité de l’utilisateur. En d’autres termes, vous pouvez gérer l’attribution de numéros au sein de votre application et acheminer ou répondre aux appels au moment de l’exécution.
Meilleures pratiques
Pour vous assurer que Event Grid remet des événements à votre point de terminaison Webhook et empêche les utilisateurs malveillants d’inonder votre point de terminaison avec des événements, vous devez prouver la propriété de votre point de terminaison. Pour résoudre les problèmes liés à la réception d’événements, vérifiez que le Webhook que vous avez configuré est vérifié en gérant
SubscriptionValidationEvent
. Pour plus d’informations, reportez-vous à ce guide.Lorsqu’un événement d’appel entrant est reçu, si votre application ne répond pas avec un code d’état 200Ok à Event Grid dans le délai requis, Event Grid utilise une nouvelle tentative d’interruption exponentielle pour renvoyer l’événement. Toutefois, un appel entrant ne sonne que pendant 30 secondes et répond à un appel après ce temps n’est pas efficace. Pour éviter les nouvelles tentatives pour les appels expirés ou obsolètes, nous vous recommandons de définir la stratégie de nouvelle tentative en tant que tentatives de remise d’événements maximales sur 2 et heure d’événement sur 1 minute. Vous trouverez ces paramètres sous l’onglet Fonctionnalités supplémentaires de l’abonnement à l’événement. En savoir plus sur les nouvelles tentatives ici.
Nous vous recommandons d’activer la journalisation de votre ressource Event Grid pour surveiller les événements qui ne sont pas remises. Pour ce faire, accédez à la rubrique système sous l’onglet Événements de votre ressource Communication et activez la journalisation à partir des paramètres de diagnostic. Les journaux d’échec sont disponibles dans la table « AegDeliveryFailureLogs ».
AegDeliveryFailureLogs | limit 10 | where Message has "incomingCall"
Étapes suivantes
- Essayez le démarrage rapide pour passer un appel sortant.