Routage direct Azure Communication Services : Détails du protocole SIP

Cet article détaille la manière dont le routage direct implémente le protocole SIP (Session Initiation Protocol) pour garantir le bon acheminement du trafic entre un contrôleur de frontière de session (SBC) et le proxy SIP. Il met également en évidence l’importance de certains paramètres SIP qui nécessitent des valeurs spécifiques. Cet article s’adresse aux administrateurs Téléphonie qui sont chargés de configurer la connexion entre le SBC et le service proxy SIP.

Traitement de la requête entrante : recherche de la ressource Communication Services

Avant qu’un appel entrant ou sortant puisse être traité, les messages OPTIONS sont échangés entre le proxy SIP et le SBC. Ces messages OPTIONS permettent au proxy SIP de fournir les fonctionnalités autorisées à SBC. Il est important que la négociation des OPTIONS soit réussie (réponse 200 OK), ce qui permet de poursuivre la communication entre le SBC et le mandataire SIP pour établir des appels. Les en-têtes SIP d’un message OPTIONS vers le proxy SIP sont fournis comme exemple :

Lors d’un appel entrant, le proxy SIP doit trouver la ressource Azure Communication vers laquelle l’appel est destiné. Cette section décrit comment le proxy SIP recherche la ressource et effectue l’authentification du SBC sur la connexion entrante.

Exemple de message d’invitation SIP lors d’un appel entrant :

Lors de la réception de l’invitation, le proxy SIP effectue les étapes suivantes :

1. Vérifiez le certificat. Lors de la connexion initiale, le service de routage direct prend le nom de domaine complet (FQDN) présenté dans l’en-tête Contact et le fait correspondre au Nom commun ou au à l’Autre nom du sujet du certificat présenté. Le nom SBC doit correspondre à l’une des options suivantes :

   • Option 1. Le nom FQDN complet présenté dans l’en-tête Contact doit correspondre au Nom commun/Autre nom du sujet du certificat présenté.

   • Option 2. La partie domaine du nom FQDN présenté dans l’en-tête Contact (par exemple contoso.com du nom FQDN sbc1.contoso.com) doit correspondre à la valeur générique dans Nom commun/Autre nom du sujet (par exemple *.contoso.com).

2. Essayez de trouver un locataire Microsoft 365 en utilisant le nom FQDN complet présenté dans l’en-tête Contact.

   Vérifiez si le nom FQDN de l’en-tête Contact (sbc1.contoso.com) est inscrit en tant que nom DNS dans une organisation Microsoft 365 ou Office 365. S’il est trouvé, la recherche de l’utilisateur est effectuée dans le locataire qui a le FQDN SBC enregistré comme nom de domaine. S’il n’est pas trouvé, l’étape 3 s’applique.

3. Essayez de trouver une ressource Azure Communication en utilisant le nom FQDN complet présenté dans l’en-tête Contact.

   Vérifiez si le nom FQDN de l’en-tête Contact (sbc1.contoso.com) est enregistré en tant que FQDN SBC dans une ressource Azure Communication. S’il est trouvé, l’appel est envoyé à cette ressource. S’il n’est pas trouvé, l’étape 4 s’applique.

4. L’étape 4 s’applique uniquement si les étapes 2 et 3 ont échoué.

   Supprimez la partie hôte du FQDN, présenté dans l’en-tête Contact (FQDN : sbc1.contoso.com, après avoir supprimé la partie hôte : contoso.com), et vérifiez si ce nom est enregistré en tant que nom DNS dans l’une des organisation Microsoft 365 ou Office 365. S’il est trouvé, la recherche de l’utilisateur est effectuée dans ce locataire. S’il est introuvable, l’appel échoue.

5. L’étape 5 s’applique uniquement si les étapes 2, 3 et 4 ont échoué.

   Supprimez la partie hôte du FQDN, présenté dans l’en-tête Contact (FQDN : sbc1.contoso.com, après avoir supprimé la partie hôte : contoso.com), et vérifiez si ce nom est enregistré en tant que FQDN SBC dans l’une des ressources Azure Communication. S’il est trouvé, l’appel est envoyé à cette ressource. S’il est introuvable, l’appel échoue.

6. Si la ressource est associée à un déploiement Dynamics Omnichannel, effectuez la recherche du numéro de téléphone présenté dans l’URI de requête (Request-URI). Faites correspondre le numéro de téléphone présenté à un utilisateur Omnichannel (file d’attente) trouvé à l’étape précédente.

7. L’étape 7 s’applique uniquement si l’étape 6 a échoué.

   Si aucun déploiement Omnichannel n’existe pour la ressource de communication, ou si le numéro dans Request-URI ne correspond à aucun numéro Omnichannel configuré, l’appel est envoyé à un Event Grid.

8. L’étape 8 s’applique uniquement si l’étape 7 a échoué.

   Si Event Grid n’est pas configuré ou qu’il n’existe aucune règle pour gérer l’appel entrant, l’appel est abandonné.

Exigences détaillées pour l’en-tête Contact et le Request-URI

En-tête de contact

Pour tous les messages SIP entrants (OPTIONS, INVITE) vers le proxy Microsoft SIP, l’en-tête Contact doit contenir le FQDN du SBC apparié dans le nom d’hôte de l’URI de la manière suivante :

Syntaxe : Contact : <sip:phone or sip address@FQDN of the SBC;transport=tls>

Conformément à la RFC 3261, section 11.1, un champ d’en-tête Contact PEUT être présent dans un message OPTIONS. Dans le cas du routage direct, l’en-tête de contact est nécessaire. Dans le cas des messages OPTIONS, le userinfo peut être exclu de l’URI SIP et seul le FQDN peut être envoyé dans le format suivant :

Syntaxe : Contact : <sip:FQDN of the SBC;transport=tls>

Ce nom (FQDN) doit également figurer dans le ou les champs Nom commun ou Autre nom du sujet du certificat présenté. Microsoft prend en charge l’utilisation de valeurs génériques pour le ou les noms dans les champs Nom commun ou Autre nom du sujet du certificat. La prise en charge des caractères génériques est décrite dans la RFC 2818, section 3.1. Plus précisément :

« Les noms peuvent contenir le caractère générique *, qui est considéré comme correspondant à tout composant ou fragment de composant d’un nom de domaine. Par exemple, *.a.com correspond à foo.a.com mais pas à bar.foo.a.com. f*.com correspond foo.com, mais pas bar.com. »

Si plusieurs valeurs de l’en-tête Contact sont présentées dans un message SIP par le SBC, seule la partie FQDN de la première valeur de l’en-tête Contact est utilisée. En règle générale, pour le routage direct, il est important que le FQDN soit utilisé pour remplir l’URI SIP au lieu de l’adresse IP. Si un message INVITE ou OPTIONS est envoyé au proxy SIP avec l’en-tête Contact et que le nom d’hôte est représenté par une adresse IP et non par un FQDN, la connexion est refusée avec la mention 403 Forbidden (Interdit).

Request-URI

Pour tous les appels entrants, le Request-URI est utilisé pour identifier le destinataire de l’appel. Actuellement, les numéros de téléphone doivent contenir un signe plus (+), comme le montre l’exemple suivant.

INVITE sip:+12345@sip.pstnhub.microsoft.com SIP /2.0

En-tête From

Pour tous les appels entrants, l’en-tête À partir de (From) est utilisé pour correspondre au numéro de téléphone de l’appelant.

Le numéro de téléphone doit contenir un + comme indiqué dans l’exemple suivant.

From: <sip:+12345@sbc1.contoso.com;transport=udp;tag=1c68821811

Considérations relatives aux en-têtes Contact et Record-Route

Le proxy SIP doit calculer le FQDN du saut suivant pour les nouvelles transactions client dans la boîte de dialogue (par exemple Bye ou Re-Invite), et lorsqu’il répond à des OPTIONS SIP. Cette opération peut être effectuée à l’aide de Contact ou de Record-Route. Selon la RFC 3261, section 8.1.1.8, un en-tête Contact est requis dans toute requête pouvant donner lieu à un nouveau dialogue. Record-Route est nécessaire uniquement si un proxy souhaite rester sur le chemin des futures requêtes dans une boîte de dialogue.

Pour calculer le tronçon suivant, le proxy SIP utilise :

• Priorité 1. Record-Route de niveau supérieur. Si le Record-Route de niveau supérieur contient le nom FQDN, ce dernier est utilisé pour établir la connexion sortante dans la boîte de dialogue.

• Priorité 2. En-tête de contact. Si Record-Route n’existe pas, le proxy SIP recherche la valeur de l’en-tête Contact pour établir la connexion sortante. (Configuration recommandée).

Si Contact et Record-Route sont tous deux utilisés, l’administrateur SBC doit maintenir leurs valeurs identiques, ce qui entraîne une surcharge administrative.

Utilisation du nom FQDN dans Contact ou Record-Route

L’utilisation d’une adresse IP n’est prise en charge ni dans Record-Route ni dans Contact. La seule option prise en charge est un FQDN, qui doit correspondre au Nom commun ou à l’Autre nom du sujet du certificat SBC (les valeurs génériques du certificat sont prises en charge).

• Si une adresse IP est présentée dans Record-route ou Contact, la vérification du certificat échoue et l’appel échoue.

• Si le FQDN ne correspond pas à la valeur du Nom commun ou de l’Autre nom du sujet dans le certificat présenté, l’appel échoue.

En-têtes de contexte d’appel

Les en-têtes de contexte d’appel sont actuellement disponibles uniquement pour le Kit de développement logiciel (SDK) Call Automation. Le SDK Call Automation prend en charge l’en-tête Utilisateur-à-utilisateur (UUI) et jusqu’à cinq en-têtes SIP personnalisés. Ces en-têtes sont pris en charge dans les méthodes INVITE et REFER.

En-tête Utilisateur à utilisateur

L’en-tête SIP Utilisateur-à-Utilisateur (UUI) est une norme du secteur qui permet de transmettre des informations contextuelles au cours de la procédure d’établissement des appels. La longueur maximale d’une clé d’en-tête UUI est de 64 caractères. La longueur maximale de l’en-tête UUI est de 256 caractères. La valeur de l’en-tête de l’interface utilisateur peut être constituée de caractères alphanumériques et de quelques symboles sélectionnés, notamment =, ;, ., !, %, *, _, +, ~, -.

En-tête personnalisé

Azure Communication Services prend également en charge jusqu’à cinq en-têtes SIP personnalisés. La clé d’en-tête SIP personnalisée doit commencer par un préfixeX-MS-Custom- obligatoire. La longueur maximale d’une clé d’en-tête SIP est de 64 caractères, y compris le préfixe X-MS-Custom-. La clé d’en-tête SIP peut être constituée de caractères alphanumériques et de quelques symboles sélectionnés, notamment ., !, %, *, _, +, ~, -. La longueur maximale de l’en-tête SIP est de 256 caractères. La valeur de l’en-tête SIP peut être constituée de caractères alphanumériques et de quelques symboles sélectionnés, notamment =, ;, ., !, %, *, _, +, ~, -.

Pour plus de détails sur l’implémentation, consultez Comment transmettre des données contextuelles entre les appels.

Appel entrant : Description de la boîte de dialogue SIP

Voici les détails de la façon dont le proxy SIP traite les appels entrants.

Une identité Azure Communication Services peut être utilisée en même temps dans plusieurs points de terminaison (applications). Par exemple, l’application web, l’application iPhone et l’application Android. Chaque point de terminaison peut signaler un repos HTTP de la manière suivante :

• Progression de l’appel – Converti par le proxy SIP en message SIP 180. A la réception du message 180, le SBC doit générer une sonnerie locale.

• Réponse média – Convertie par le proxy SIP en message 183 avec les candidats média dans le protocole SDP (Session Description Protocol). À la réception du message 183, le SBC s’attend à se connecter aux candidats médias reçus dans le message SDP.

  Remarque

  Dans certains cas, la réponse du média peut ne pas être générée et le point de terminaison peut répondre avec le message « Appel accepté ».

• Appel accepté – Converti par le proxy SIP en message SIP 200 avec SDP. À la réception du message 200, le SBC est censé envoyer et recevoir des médias à destination et en provenance des candidats du SDP fournis.

  Remarque

  Le routage direct ne prend pas en charge l’invitation à l’offre différée (invitation sans SDP).

Plusieurs points de terminaison sonnent avec une réponse provisoire

1. Lors de la réception de la première invitation du SBC, le proxy SIP envoie le message « SIP SIP/2.0 100 Trying » et notifie tous les points de terminaison de l’utilisateur final de l’appel entrant.

2. Après notification, chaque point de terminaison commence à sonner et à envoyer des messages de « Progression de l’appel » au proxy SIP. Comme l’identité Azure Communication Services est utilisée par plusieurs points de terminaison, le proxy SIP peut recevoir plusieurs messages de progression des appels.

3. Pour chaque message de progression d’appel reçu des points de terminaison, le proxy SIP convertit le message de progression d’appel en message SIP « SIP SIP/2.0 180 Ringing ». L’intervalle d’envoi de ces messages correspond à l’intervalle de réception des messages du contrôleur d’appel. Dans le diagramme suivant, deux messages 180 sont générés par le proxy SIP. Ces messages proviennent des deux points de terminaison du Kit de développement logiciel (SDK). Les points de terminaison ont chacun un ID d’étiquette unique. Chaque message provenant d’un point de terminaison différent constitue une session distincte (le paramètre « étiquette » (tag) dans le champ « À partir de » (To) est différent). Cependant, un point de terminaison peut ne pas générer le message 180 et envoyer le message 183 immédiatement, comme illustré dans le diagramme suivant.

4. Lorsqu’un point de terminaison génère un message de réponse média qui contient les adresses IP des candidats médias du point de terminaison, le proxy SIP convertit le message reçu en un message « SIP 183 Session Progress » dans lequel le SDP du point de terminaison est remplacé par le SDP du processeur média. Dans le diagramme suivant, le point de terminaison de Fourche 2 a répondu à l’appel. Le message SIP 183 n’est généré qu’une seule fois. Les 183 peuvent venir sur une fourche existante ou commencer une nouvelle.

5. Un message d’acceptation d’appel est envoyé au proxy SIP avec les candidats finaux du point de terminaison qui a accepté l’appel. Le message d’acceptation de l’appel est converti en message SIP 200.

   

Plusieurs points de terminaison sonnent sans réponse provisoire

1. Lors de la réception de la première invitation du SBC, le proxy SIP envoie le message « SIP SIP/2.0 100 Trying » et notifie tous les points de terminaison de l’utilisateur final de l’appel entrant.

2. Après notification, chaque point de terminaison commence à sonner et à envoyer le message « Progression de l’appel » au proxy SIP. Étant donné qu’une même identité Azure Communication Services peut être utilisée dans plusieurs applications, le proxy SIP peut recevoir plusieurs messages de progression des appels.

3. Pour chaque message de progression d’appel reçu des points de terminaison, le proxy SIP convertit le message de progression d’appel en message SIP « SIP SIP/2.0 180 Ringing ». L’intervalle d’envoi des messages correspond à l’intervalle de réception des messages du contrôleur d’appel. Sur l’image, il y a deux messages 180 générés par le proxy SIP, ce qui signifie que l’appel est transféré à deux clients différents et que chaque client envoie la progression de l’appel. Chaque message est une session distincte (le paramètre « étiquette » dans le champ « Vers » est différent)

4. Un message d’acceptation d’appel est envoyé au proxy SIP avec les candidats finaux du point de terminaison qui a accepté l’appel. Le message d’acceptation de l’appel est converti en message SIP 200.

   

Option Replaces

Le SBC doit prendre en charge INVITE avec Replaces.

Considérations relatives à la taille du SDP

L’interface de routage direct peut envoyer un message SIP de plus de 1500 octets. La taille du SDP est principalement à l’origine de ce comportement. Toutefois, s’il existe une jonction UDP derrière le SBC, celui-ci pourrait rejeter le message s’il est transféré sans modification du proxy SIP Microsoft vers la jonction. Microsoft recommande de supprimer certaines valeurs dans le SDP sur le SBC lors de l’envoi du message aux jonctions UDP. Par exemple, les candidats ICE ou les codecs inutilisés peuvent être supprimés.

Transfert d’appel

Le routage direct prend en charge deux méthodes de transfert d’appel :

• Option 1. Le proxy SIP traite localement le Refer du client et agit en tant que référent, comme décrit dans la section 7.1 de la RFC 3892.

  Avec cette option, le proxy SIP met fin au transfert et ajoute une nouvelle invitation.

• Option 2. Le proxy SIP envoie le Refer au SBC et agit en tant que transmetteur comme décrit dans la section 6 de la RFC 5589.

  Avec cette option, le proxy SIP envoie un Refer au SBC et s’attend à ce que le SBC traite entièrement le transfert.

Le proxy SIP sélectionne la méthode en fonction des fonctionnalités signalées par le SBC. Si le SBC indique qu’il prend en charge la méthode « Refer », le proxy SIP utilise l’option 2 pour les transferts d’appels. Exemple d’un SBC qui envoie le message indiquant que la méthode Refer est prise en charge :

ALLOW: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Si le SBC n’indique pas que le référent est une méthode prise en charge, le routage direct utilise l’option 1 (le proxy SIP agit en tant que Référent). Le SBC doit également signaler qu’il prend en charge la méthode Notify : Exemple de SBC indiquant que la méthode Refer n’est pas supportée :

ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS

Le proxy SIP traite localement le Refer du client et agit en tant que référent

Si le SBC indique que la méthode Refer n’est pas prise en charge, le proxy SIP agit en tant que référent. La requête Refer qui provient du client termine sur le proxy SIP. Dans le diagramme suivant, la requête Refer du client est affichée sous la forme « Transfert d’appel vers Dave ». Pour plus d’informations, consultez la section 7.1 de la RFC 3892.

Le proxy SIP envoie le Refer au SBC et agit en tant que transmetteur

Pour les transferts d’appels, il est préférable d’utiliser un proxy SIP en tant que transmetteur.

La norme est expliquée dans la section 6 de la RFC 5589. Les RFC correspondantes sont les suivantes :

• Contrôle des appels SIP (Session Initiation Protocol) – Transfert

• En-tête « Remplace » du protocole d’initiation de session (SIP)

• Mécanisme « Referred-By » du protocole SIP (Session Initiation Protocol)

Cette option suppose que le proxy SIP agit en tant que transmetteur et envoie un message Refer au SBC. Le SBC agit en tant que destinataire du transfert et gère le Refer pour générer une nouvelle tentative de transfert. Deux cas sont possibles :

• L’appel est transféré à un participant externe du RTC.
• L’appel est transféré d’un point de terminaison SDK à un autre point de terminaison SDK dans la même ressource via le SBC.

Si l’appel est transféré d’un point de terminaison SDK à un autre point de terminaison SDK via le SBC, ce dernier est censé émettre une nouvelle invitation (démarrer une nouvelle boîte de dialogue) pour la cible du transfert à l’aide des informations reçues dans le message Refer. Pour remplir les champs Vers/Transmetteur de la transaction de la requête en interne, le proxy SIP doit transmettre ces informations dans les en-têtes REFER-TO/REFERRED-BY. Le proxy SIP forme le REFER-TO sous la forme d’un URI SIP composé d’un FQDN de proxy SIP dans le nom d’hôte et soit :

• Un numéro de téléphone E.164 dans la partie nom d’utilisateur de l’URI dans le cas où la cible du transfert est un numéro de téléphone, ou

• Paramètres x-m et x-t qui encodent respectivement l’IRM cible du transfert complet et l’ID de la ressource de communication.

L’en-tête REFERRED-BY contient un URI SIP avec le MRI du transmetteur, l’ID de la ressource du transmetteur et d’autres paramètres de contexte de transfert, comme indiqué dans le tableau suivant :

Dans ce cas, la taille de l’en-tête Refer peut aller jusqu’à 400 symboles. Le SBC doit permettre de traiter les messages Refer avec une taille allant jusqu’à 400 symboles.

Transfert d’appels

Un SDK d’automatisation des appels Azure Communication Services peut rediriger les appels entrants vers un autre numéro ou un point de terminaison SDK/Teams, faire sonner un ou plusieurs autres utilisateurs en parallèle (sonnerie simultanée) ou faire sonner un groupe d’utilisateurs ou de numéros. Points importants à prendre en compte :

• Request-URI dans la requête INVITE du proxy SIP à l’utilisateur C contient le paramètre cause.

• L’en-tête History-Info est renseigné.

• Lorsque l’utilisateur A est un autre utilisateur du RTC, le proxy SIP génère la réponse provisoire « SIP SIP/2.0 181 L’appel est transféré » à l’utilisateur A.

• Si l'utilisateur A et l'utilisateur C sont des utilisateurs du RTC, le proxy SIP conserve la réponse provisoire « SIP SIP/2.0 181 L'appel est transféré ».

• L’en-tête History-Info doit être utilisé pour la prévention des boucles.

Minuteur de session

Le proxy SIP prend en charge (propose toujours) le minuteur de session. L’utilisation du minuteur de session par le SBC n’est pas obligatoire.

Utilisation du paramètre Request-URI user=phone

Le proxy SIP analyse le Request-URI et si le paramètre user=phone est présent, le service traite le Request-URI comme un numéro de téléphone, en faisant correspondre le numéro à un utilisateur. Si le paramètre n’est pas présent, le proxy SIP applique une méthode heuristique pour déterminer le type d’utilisateur Request-URI (numéro de téléphone ou adresse SIP).

Pour simplifier le processus d’établissement des appels, Microsoft recommande de toujours appliquer le paramètre user=phone.

En-tête History-Info

L’en-tête History-Info est utilisé pour le reciblage des requêtes SIP et « fournit un mécanisme standard pour capturer les informations de l’historique des requêtes afin de permettre une grande variété de services pour les réseaux et les utilisateurs finaux ». Pour plus d’informations, consultez la RFC 4244 – Section 1.1. Pour le routage direct, cet en-tête est utilisé dans les scénarios de sonnerie simultanée et de transfert d’appel.

L’historique-info est activé de la manière suivante :

• Le proxy SIP insère un paramètre contenant le numéro de téléphone associé dans les entrées History-Info individuelles qui composent l’en-tête History-Info envoyé au contrôleur RTC. En utilisant uniquement les entrées qui ont le paramètre numéro de téléphone, le contrôleur RTC reconstruit un nouvel en-tête History-Info et le transmet au fournisseur de la ligne réseau SIP via le proxy SIP.

• L’en-tête History-Info est ajouté pour les cas de sonnerie simultanée et de transfert d’appel.

• L’en-tête History-Info n’est pas ajouté pour les cas de transfert d’appel.

• Une entrée d’historique individuelle dans l’en-tête History-Info reconstruite a le paramètre de numéro de téléphone fourni combiné avec le FQDN de routage direct (sip.pstnhub.microsoft.com) défini en tant que partie hôte de l’URI. Paramètre « user=phone » ajouté dans le cadre de l’URI SIP. Tous les autres paramètres associés à l’en-tête History-Info d’origine, à l’exception des paramètres de contexte téléphonique, sont transférés dans l’en-tête History-Info reconstruit.

  Remarque

  Entrées privées (déterminées par les mécanismes définis dans la section 3.3 de la RFC 4244) transmises sans modification car le fournisseur de la ligne réseau SIP est un homologue de confiance.

• Les informations d’historique entrant sont conservées pour la prévention des boucles.

Voici le format de l’en-tête History-info envoyé par le proxy SIP :

<sip:UserB@sip.pstnhub.microsoft.com?Privacy=history&Reason=SIP%3Bcause%3D486>;index=1.2

Si l’appel a été redirigé plusieurs fois, les informations sur chacune des redirections sont incluses avec le motif approprié dans l’ordre chronologique, dans une liste séparée par des virgules.

Exemple d’en-tête :

History-Info:
  <sip:+123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
  <sip:+113579@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D496%3Btext%3D%22User%20Busy%22>;index=1.1

L’URI SIP dans l’en-tête History-Info est mis en forme conformément à la section 25 de la RFC 3261 (voir la définition de addr-spec). Dans l’exemple précédent, le texte d’origine de l’en-tête d’URI Reason est SIP;cause=496;text="User Busy", dont les caractères ;, "et = sont échangés contre leurs valeurs ASCII hexagonales %3B, %22et 3D respectivement.

History-Info est protégé par un mécanisme TLS obligatoire.

Connexion SBC pour le routage direct et le mécanisme de basculement

Consultez la section Mécanisme de basculement pour la signalisation SIP dans Exigences relatives à l’infrastructure de routage direct.

Retry-After

Si un centre de données de routage direct est occupé, le service peut envoyer un message Retry-After avec un intervalle d’une seconde au SBC. Lorsque le SBC reçoit un message 503 avec un en-tête Retry-After en réponse à un INVITE, le SBC doit mettre fin à cette connexion et essayer le prochain centre de données Microsoft disponible.

Gestion des nouvelles tentatives (réponse 603)

Si un utilisateur final constate que plusieurs appels ont été manqués après avoir refusé l’appel entrant, cela signifie que le mécanisme de nouvelle tentative du fournisseur de jonction SBC ou RTC a été mal configuré. Le SBC doit être reconfiguré pour arrêter les efforts de nouvelle tentative sur la réponse 603.