Problèmes qui affectent les transferts d’appels

Cet article se concentre sur la façon de résoudre les problèmes liés aux transferts d’appels lancés par Microsoft. Cet article ne s’applique pas aux problèmes liés aux transferts d’appels lancés à partir de sources SBC (Session Border Controller) ou RTC (Public Switched Telephone Network).

Les transferts d’appels initiés par Microsoft peuvent se produire dans plusieurs scénarios, tels que les transferts d’appels initiés par l’utilisateur, les transferts à partir d’un standard automatique et les transferts à partir d’une file d’attente d’appels. Avant de résoudre les problèmes, passez en revue les informations générales suivantes.

Contexte

Un transfert d’appel peut être effectué à l’aide de l’une des méthodes suivantes, dans l’ordre de préférence :

  1. Utilisation d’un message de référence SIP (Session Initiation Protocol).
  2. Utilisation d’un message d’invitation SIP qui a un en-tête Replaces. Cette méthode est principalement utilisée pour les réponses de file d’attente d’appels.
  3. Utilisation d’une infrastructure Microsoft Teams interne. Cette méthode n’est pas visible pour SBC. La méthode est utilisée uniquement si les deux premières méthodes ne sont pas prises en charge.

Tous les transferts qui utilisent un message de référence SIP doivent passer par l’infrastructure Microsoft Teams. Lorsque le proxy SIP Microsoft envoie un message de référence SIP à SBC, un message d’invitation SIP doit être retourné au proxy SIP, et non à PSTN ou à toute autre destination. Elle est vraie même si l’appel est transféré vers un numéro RTC externe. SBC n’a pas besoin d’analyser le message De référence SIP pour rechercher la cible de transfert. SBC doit envoyer le message d’invitation SIP avec le paramètre RURI (Request-URI) uniquement au contenu de l’en-tête Refer-To. Il doit également inclure l’en-tête Referred-By du message De référence SIP. Assurez-vous que les chaînes du message d’invitation SIP ne sont pas modifiées et qu’elles sont envoyées en tant que chaînes exactement identiques à celles fournies dans le message de référence SIP (en particulier dans l’en-tête Referred-By). Cela est dû au fait que ces chaînes sont utilisées pour identifier les appels, les cibles et d’autres parties importantes d’un transfert d’appel.

Note: Les chaînes peuvent être des chaînes x-* ou des chaînes personnalisées dans les en-têtes Referred-By et Refer-To.

Le standard automatique ne transfère pas les appels à un numéro RTC externe

Ce problème peut se produire pour les raisons suivantes :

  • Aucune licence ou licence incorrecte n’est attribuée au standard automatique. Si vous pouvez transférer un appel à un utilisateur interne ou à un bot, mais si vous ne pouvez pas transférer un appel vers un numéro RTC externe, cela peut indiquer un problème de licence.
  • Le message d’invitation SIP est envoyé à un appareil incorrect. Par exemple, le message est envoyé à un fournisseur RTC. Par défaut, les messages de référence SIP ne contiennent pas d’informations complètes sur la cible. Par exemple, un numéro RTC est normalisé au format international.

Pour résoudre ce problème, attribuez la licence appropriée au standard automatique pour lui permettre d’effectuer des appels RTC. Si le problème persiste, assurez-vous que le message d’invitation SIP est envoyé au proxy SIP qui peut transférer les appels de manière appropriée. Le proxy SIP envoie le message d’invitation SIP au réseau RTC en fonction des paramètres (tels que les règles de normalisation, le routage SBC, l’ID de l’appelant).

Le message de référence SIP ne contient pas de numéro de téléphone ou le numéro de téléphone est mis en forme de manière incorrecte

Ce comportement est inhérent au produit. Pour contourner ce comportement, assurez-vous que le proxy SIP envoie le message De référence SIP à SBC. Ensuite, configurez SBC pour copier les chaînes Referred-By et Refer-To dans le message d’invitation SIP qui sera renvoyé au proxy SIP.

Aucune référence SIP ne provient du proxy SIP vers SBC

Pour résoudre ce problème, procédez comme suit :

  1. Assurez-vous que la méthode Référence SIP est prise en charge pour les transferts d’appels par SBC dans la réponse d’invitation SIP ou « SIP 200 OK » (selon que l’appel est initié par SBC ou Microsoft). Si la méthode SIP Refer n’est pas prise en charge, les transferts d’appel sont effectués à l’aide d’une invite SIP qui a un en-tête Replaces (si cette méthode est prise en charge). Si la méthode Invite SIP ne fonctionne pas, le transfert interne masqué dans SBC est utilisé.
  2. Assurez-vous que le pare-feu et les paramètres SBC autorisent les connexions entrantes à partir de n’importe quelle adresse IP de signalisation Microsoft, et pas seulement à partir d’adresses spécifiques. La référence SIP peut provenir de n’importe quelle adresse IP à l’aide d’une nouvelle connexion TLS, même si la partie précédente de l’appel provient d’une autre adresse IP.

Si SBC reçoit des messages SIP Refer après avoir suivi ces étapes, assurez-vous que la nouvelle invitation SIP est remise au proxy SIP, même si l’appel est transféré vers un numéro RTC externe. Si l’appel est transféré vers un numéro RTC externe, le proxy SIP transfère l’appel, puis envoie une nouvelle invitation SIP à SBC. Dans ce cas, assurez-vous que l’appel n’échoue pas sur SBC. Si cet appel échoue et génère une erreur, cette erreur est renvoyée à SBC lors de l’appel transféré.

Suppression des appels avant la fin du transfert

Ce problème peut se produire pour les raisons suivantes :

  • Le proxy SIP ne reçoit pas la réponse « 202 Accepté » ou les messages « Notification SIP » de SBC en réponse au message de référence SIP, et le processus expire.
  • Le message « SIP Bye » arrive de SBC trop tôt et l’appel se termine avant que le message ne soit entièrement transféré.

Pour résoudre ce problème, assurez-vous que SBC envoie la réponse « SIP 202 Accepté » et les messages « Notification SIP » pour fournir une mise à jour sur la progression de l’appel transféré. Lorsque le proxy SIP reçoit un message « Notification SIP » qui inclut la réponse « 200 OK », il met fin en toute sécurité à l’appel d’origine en envoyant la réponse « SIP Bye », car il sait que l’appel a été remplacé par un nouvel appel.

Aucun son de sonnerie lors du transfert d’appels

Pour résoudre ce problème, procédez comme suit :

  1. Assurez-vous que la méthode Sip Refer est prise en charge par SBC dans l’invitation SIP initiale ou la réponse « SIP 200 OK » (selon que l’appel est initié par SBC ou par Microsoft). Sip Refer est nécessaire pour générer correctement le son de sonnerie. En effet, actuellement, aucun son de son simulé n’est généré lorsque vous transférez des appels en interne.
  2. Si SBC reçoit le message de référence SIP, mais que les utilisateurs RTC n’entendent toujours pas de sonnerie, assurez-vous que SBC se connecte à l’appel de transfert nouvellement lancé et lit une sonnerie basée sur la réponse « SIP 180 Sonnerie » ou « Session SIP 183 » envoyée à partir du proxy SIP.

Encore besoin d’aide ? Accédez à Microsoft Community.