Problèmes qui affectent les transferts d’appels

Cet article se concentre sur la résolution des problèmes liés aux transferts d’appels initiés par Microsoft. Cet article ne s’applique pas aux problèmes liés aux transferts d’appels lancés à partir du contrôleur de frontière de session (SBC) ou du réseau téléphonique commuté (RTC).

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 d’arrière-plan suivantes.

Contexte

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

  1. Utilisation d’un message SIP (Session Initiation Protocol).
  2. Utilisation d’un message d’invitation SIP avec un en-tête Remplacer. 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 par 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 SIP Refer doivent passer par l’infrastructure Microsoft Teams. Lorsque le proxy SIP Microsoft envoie un message SIP Refer à SBC, un message d’invitation SIP doit être retourné au proxy SIP, et non à PSTN ou à toute autre destination. Il est vrai même si l’appel est transféré vers un numéro PSTN externe. SBC n’a pas besoin d’analyser le message SIP Refer 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 SIP Refer. 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 exactes fournies dans le message SIP Refer (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 d’appels vers 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 PSTN 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 SIP Refer 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, affectez 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 (comme les règles de normalisation, le routage SBC, l’ID de l’appelant).

Le message SIP Refer ne contient pas de numéro de téléphone ou le numéro de téléphone n’est pas correctement mis en forme

Ce comportement est inhérent au produit. Pour contourner ce comportement, assurez-vous que le proxy SIP envoie le message SIP Refer à SBC. Ensuite, configurez SBC pour copier les chaînes Referred-By et Refer-To vers 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 SIP Refer est prise en charge pour les transferts d’appels par SBC dans l’invite SIP ou la réponse « SIP 200 OK » (selon que l’appel est lancé par SBC ou Microsoft). Si la méthode SIP Refer n’est pas prise en charge, les transferts d’appels sont effectués à l’aide de l’invite SIP qui a un en-tête Replaces (si cette méthode est prise en charge). Si la méthode SIP Invite ne fonctionne pas, le transfert interne masqué à partir de 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, pas seulement à partir d’adresses spécifiques. SIP Refer peut provenir de l’une des adresses 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 PSTN externe. Si l’appel est transféré vers un numéro PSTN 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 comme réponse au message SIP Refer, et le processus expire.
  • Le message « SIP Bye » arrive de SBC trop tôt et l’appel se termine avant le transfert complet du message.

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 de 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 termine l’appel d’origine en toute sécurité 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’invite SIP initiale ou la réponse « SIP 200 OK » (selon que l’appel est lancé par SBC ou Par Microsoft). SIP Refer est nécessaire pour générer correctement le son de sonnerie. C’est parce que, actuellement, aucun son de sonnerie simulée n’est généré lorsque vous transférez des appels en interne.
  2. Si SBC reçoit le message SIP Refer, mais que les utilisateurs PSTN n’entendent toujours pas de sonnerie, assurez-vous que SBC se connecte à l’appel de transfert nouvellement lancé et qu’il lit une sonnerie basée sur la réponse « SIP 180 Ringing » ou « SIP 183 Session » envoyée à partir du proxy SIP.

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