Surveiller le routage direct

• S’applique à:

  Microsoft Teams

Cet article explique comment surveiller et résoudre les problèmes de votre configuration de routage direct.

La possibilité d’émettre et de recevoir des appels à l’aide du routage direct implique les composants suivants :

• Contrôleurs de bordure de session (SBC)
• Composants de routage direct dans le cloud Microsoft
• Jonctions de télécommunications

Si vous rencontrez des difficultés pour résoudre les problèmes, vous pouvez ouvrir un dossier de support auprès de votre fournisseur SBC ou de Microsoft.

Microsoft travaille à fournir davantage d’outils pour la résolution des problèmes et la surveillance. Consultez régulièrement la documentation pour connaître les mises à jour.

Résoudre les problèmes de routage direct

Pour résoudre les problèmes de routage direct, consultez Diagnostiquer les problèmes liés au routage direct.

Surveillance de la disponibilité des contrôleurs de frontière de session à l’aide des messages d’options SIP (Session Initiation Protocol)

Le routage direct utilise les options SIP envoyées par les contrôleurs de frontière de session pour surveiller l’intégrité de SBC. Aucune action n’est requise de la part de l’administrateur client pour activer la surveillance des options SIP. Les informations collectées sont prises en compte lors de la prise de décisions de routage.

Par exemple, si, pour un utilisateur spécifique, plusieurs SBC sont disponibles pour acheminer un appel, le routage direct prend en compte les informations d’options SIP reçues de chaque SBC pour déterminer le routage.

Le diagramme suivant montre un exemple de configuration :

Lorsqu’un utilisateur passe un appel au numéro +1 425 <sur sept chiffres>, le routage direct évalue l’itinéraire. Il existe deux SBC dans l’itinéraire : sbc1.contoso.com et sbc2.contoso.com. Les deux SBC ont la même priorité dans l’itinéraire. Avant de sélectionner un SBC, le mécanisme de routage évalue l’intégrité des SBC en fonction du moment où le SBC a envoyé les options SIP la dernière fois.

Un SBC est considéré comme sain si les statistiques au moment de l’envoi de l’appel indiquent que le SBC envoie des options toutes les minutes.

Lorsqu’un appel est effectué, la logique suivante s’applique :

• Le SBC a été jumelé à 11h00.
• Le SBC envoie les options à 11:01, 11:02, et ainsi de suite.
• À 11h15, un utilisateur passe un appel et le mécanisme de routage sélectionne ce SBC.

Le routage direct prend les options d’intervalle régulier trois fois (l’intervalle régulier est d’une minute). Si des options ont été envoyées au cours des trois dernières minutes, le SBC est considéré comme sain.

Si le SBC dans l’exemple a envoyé des options à une période comprise entre 11h12 et 11h15 (heure à laquelle l’appel a été effectué), il est considéré comme sain. Si ce n’est pas le cas, le SBC est rétrogradé de l’itinéraire.

La rétrogradation signifie que le SBC ne sera pas essayé en premier. Par exemple, nous avons sbc1.contoso.com et sbc2.contoso.com avec la même priorité.

Si sbc1.contoso.com n’envoie pas d’options SIP à intervalle régulier comme décrit précédemment, il est rétrogradé. Ensuite, sbc2.contoso.com tente l’appel. Si sbc2.contoso.con ne peut pas remettre l’appel, le sbc1.contoso.com (rétrogradé) est réessayé avant qu’un échec ne soit généré.

Si deux SBC (ou plus) dans un itinéraire sont considérés comme sains et égaux, Fisher-Yates shuffle est appliqué pour répartir les appels entre les SBC.

Surveiller le tableau de bord Analyse de la qualité des appels et les journaux SBC

Dans certains cas, en particulier lors de l’appairage initial, il peut y avoir des problèmes liés à une mauvaise configuration des SBC ou du service de routage direct.

Vous pouvez utiliser les outils suivants pour surveiller votre configuration :

• Tableau de bord de la qualité des appels
• Journaux SBC

Le service de routage direct a des codes d’erreur descriptifs signalés à Call Analytics ou aux journaux SBC.

Le tableau de bord qualité des appels fournit des informations sur la qualité et la fiabilité des appels. Pour en savoir plus sur la résolution des problèmes à l’aide de l’analyse des appels, consultez Activation et utilisation du tableau de bord de qualité des appels pour Microsoft Teams et Skype Entreprise Online et Utiliser l’analyse des appels pour résoudre les problèmes de mauvaise qualité des appels.

En cas d’échec d’appel, l’analyse des appels fournit des codes SIP standard pour vous aider à résoudre les problèmes.

Toutefois, l’analyse des appels ne peut être utile que lorsque les appels atteignent les composants internes du routage direct et échouent. En cas de problèmes liés à l’appairage SBC ou de problèmes où l’option « Invite » SIP a été rejetée (par exemple, le nom du nom de domaine complet de jonction est mal configuré), l’analyse des appels n’est pas utile. Dans ce cas, reportez-vous aux journaux SBC. Le routage direct envoie une description détaillée des problèmes aux SBC; ces problèmes peuvent être lus à partir des journaux SBC.