Problèmes affectant 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 initiés à partir de sources SBC (Session Border Controller) ou PSTN (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 service de transport automatique et les transferts à partir d’une file d’attente d’appels. Avant de résoudre les problèmes, examinez les informations de base 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) Refer.
  2. Utilisation d’un message SIP Invite avec 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 le SBC. La méthode est utilisée uniquement si les deux premières méthodes ne sont pas pris en charge.

Tous les transferts qui utilisent un message SIP Refer doivent passer par l’infrastructure Microsoft Teams’infrastructure. Lorsque le proxy SIP Microsoft envoie un message SIP Refer à SBC, un message d’invitation SIP doit être renvoyé au proxy SIP, et non à PSTN ou à toute autre destination. Cela est vrai même si l’appel est transféré vers un numéro PSTN externe. Le SBC n’a pas besoin d’examiner le message SIP Refer pour rechercher la cible de transfert. Le 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 de demande. Il doit également inclure l’en-Referred-By du message SiP Refer. Assurez-vous que les chaînes du message SIP Invite ne sont pas modifiées et qu’elles sont envoyées en tant que chaînes identiques à celles fournies dans le message SIP Refer (en particulier dans l’en-tête Referred-By). En effet, ces chaînes sont utilisées pour identifier les appels, cibles et autres parties importantes d’un transfert d’appel.

Remarque : 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 personnalisés.

Le service de transport automatique ne transfère pas les appels vers un numéro PSTN externe

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

  • Aucune licence ou licence incorrecte n’est attribuée au attendant automatique. Si vous pouvez transférer un appel vers 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 PSTN. Par conception, les messages SIP Refer ne contiennent pas d’informations complètes sur la cible. Par exemple, un numéro PSTN est normalisé au format international.

Pour résoudre ce problème, affectez la licence correcte au attendant automatique pour lui permettre d’effectuer des appels PSTN. 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 PSTN en fonction des paramètres (par exemple, règles de normalisation, routage SBC, ID d’appelant).

Le message SIP Refer ne contient pas de numéro de téléphone ou le numéro de téléphone est mal formaté

Ce comportement est inhérent au produit. Pour contourner ce problème, assurez-vous que le proxy SIP envoie le message SIP Refer au SBC. Ensuite, configurez le SBC pour copier les chaînes Referred-By et Refer-To dans le message SIP Invite qui sera renvoyé au proxy SIP.

Aucune référence SIP ne vient du proxy SIP au SBC

Pour résoudre ce problème, suivez les étapes suivantes :

  1. Assurez-vous que la méthode SIP Refer est prise en charge pour les transferts d’appels par SBC dans la réponse « SIP Invite » 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’appels sont effectués à l’aide de l’invite SIP avec 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é du 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 être issu de n’importe quelle adresse IP à l’aide d’une nouvelle connexion TLS, même si la partie précédente de l’appel provenait d’une autre adresse IP.

Si le SBC reçoit des messages SIP Refer après avoir suivi ces étapes, assurez-vous que la nouvelle invitation SIP est transmise 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 au SBC. Dans ce cas, assurez-vous que l’appel n’échoue pas sur le SBC. Si cet appel échoue et génère une erreur, cette erreur est renvoyée au SBC sur l’appel transféré.

Abandon 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 Accepted » ou les messages « SIP Notify » du SBC en tant que réponse au message SIP Refer, et le processus est hors de l’attente.
  • Le message « SIP Bye » arrive trop tôt à partir du SBC et l’appel se termine avant que le message ne soit entièrement transféré.

Pour résoudre ce problème, assurez-vous que le SBC envoie la réponse « SIP 202 Accepté » et les messages « SiP Notify » pour fournir une mise à jour sur la progression de l’appel transféré. Lorsque le proxy SIP reçoit un message « SIP Notify » qui inclut la réponse « 200 OK », il termine 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, suivez les étapes suivantes :

  1. Assurez-vous que la méthode SIP Refer est prise en charge par le SBC dans la première invite SIP 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, pour l’instant, aucun son de sonnerie simulée n’est généré lorsque vous transférez des appels en interne.
  2. Si le SBC reçoit le message SIP Refer, mais que les utilisateurs PSTN n’entendent toujours pas de sonnerie, assurez-vous que le SBC se connecte à l’appel de transfert nouvellement initié et qu’il lit une tonalité basée sur la réponse « Sonnerie SIP 180 » ou « Session SIP 183 » envoyée à partir du proxy SIP.

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