Routage direct - Protocole SIP
Cet article décrit comment le routage direct implémente le protocole SIP (Session Initiation Protocol). Pour acheminer le trafic entre un contrôleur de bordure de session (SBC) et le proxy SIP, certains paramètres SIP doivent avoir des valeurs spécifiques. Cet article est destiné aux administrateurs vocaux qui sont responsables de la configuration de la connexion entre le SBC local et le service proxy SIP.
Traitement de la demande entrante : recherche du locataire et de l’utilisateur
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 OPTIONS réussisse (réponse 200OK), ce qui permet une communication supplémentaire entre SBC et le proxy SIP pour établir des appels. Les en-têtes SIP d’un message OPTIONS vers le proxy SIP sont fournis à titre d’exemple :
| Nom du paramètre | Exemple de valeur |
|---|---|
| URI de requête | OPTIONS sip:sip.pstnhub.microsoft.com :5061 SIP /2.0 |
| Via l’en-tête | Via : SIP/2.0/TLS sbc1.adatum.biz:5058 ; Alias; branch=z9hG4bKac2121518978 |
| en-tête Max-Forwards | Max-Forwards :68 |
| À partir de l’en-tête | À partir de l’en-tête de : sip :sbc1.adatum.biz :5058 |
| Vers l’en-tête | À : sip:sip.pstnhub.microsoft.com :5061 |
| En-tête CSeq | CSeq : 1 INVITATION |
| En-tête de contact | Contact : sip :sbc1.adatum.biz :50588 ; transport=tls |
Remarque
Les en-têtes SIP ne contiennent pas userinfo dans l’URI SIP utilisé. Conformément à la RFC 3261, section 19.1.1, la partie userinfo d’un URI est facultative et PEUT être absente lorsque l’hôte de destination n’a pas de notion d’utilisateurs ou lorsque l’hôte lui-même est la ressource identifiée. Si le signe @ est présent dans un URI SIP, le champ utilisateur NE DOIT PAS être vide. L’URI SIPS ne doit pas être utilisé avec le routage direct, car il n’est pas pris en charge. Vérifiez la configuration de votre contrôleur de bordure de session et assurez-vous que vous n’utilisez pas d’en-têtes « Remplace » dans les requêtes SIP. Le routage direct rejette les requêtes SIP pour lesquelles les en-têtes Replaces sont définis.
Sur un appel entrant, le proxy SIP doit trouver le locataire auquel l’appel est destiné et trouver l’utilisateur spécifique au sein de ce locataire. L’administrateur de locataire peut configurer des numéros non DID, par exemple +1001, dans plusieurs locataires. Par conséquent, il est important de trouver le locataire spécifique sur lequel effectuer la recherche de nombre, car les numéros non DID peuvent être les mêmes dans plusieurs organisations Microsoft 365 ou Office 365.
Cette section décrit comment le proxy SIP recherche le locataire et l’utilisateur, et effectue l’authentification du SBC sur la connexion entrante.
Voici un exemple de message d’invitation SIP sur un appel entrant :
| Nom du paramètre | Exemple de valeur |
|---|---|
| URI de requête | INVITE sip :+18338006777@sip.pstnhub.microsoft.com SIP /2.0 |
| Via l’en-tête | Via : SIP/2.0/TLS sbc1.adatum.biz:5058 ; Alias; branch=z9hG4bKac2121518978 |
| en-tête Max-Forwards | Max-Forwards :68 |
| À partir de l’en-tête | À partir de l’en-tête de : <sip :+17168712781@sbc1.adatum.biz ; transport=udp ; tag=1c747237679 |
| Vers l’en-tête | À : sip :+183338006777@sbc1.adatum.biz |
| En-tête CSeq | CSeq : 1 INVITATION |
| En-tête de contact | Contact : sip :+17168712781@sbc1.adatum.biz :5058 ; transport=tls |
Lors de la réception de l’invitation, le proxy SIP effectue les étapes suivantes :
Vérifiez le certificat. Lors de la connexion initiale, le service de routage direct prend le nom de domaine complet présenté dans l’en-tête Contact et le fait correspondre au nom commun ou à l’autre nom de l’objet du certificat présenté. Le nom SBC doit correspondre à l’une des options suivantes :
Option 1. Le nom de domaine complet présenté dans l’en-tête Contact doit correspondre au nom commun/autre nom de l’objet du certificat présenté.
Option 2. La partie domaine du nom de domaine complet présenté dans l’en-tête Contact (par exemple, adatum.biz du nom de domaine complet sbc1.adatum.biz) doit correspondre à la valeur générique dans Nom commun/Autre nom de l’objet (par exemple *.adatum.biz).
Essayez de trouver un locataire à l’aide du nom de domaine complet présenté dans l’en-tête Contact.
Vérifiez si le nom de domaine complet de l’en-tête Contact (sbc1.adatum.biz) est inscrit en tant que nom DNS dans microsoft 365 ou Office 365 organization. Si elle est trouvée, la recherche de l’utilisateur est effectuée dans le locataire dont le nom de domaine complet SBC est inscrit en tant que nom de domaine. Si elle est introuvable, l’étape 3 s’applique.
L’étape 3 s’applique uniquement en cas d’échec de l’étape 2.
Supprimez la partie hôte du nom de domaine complet, présenté dans l’en-tête Contact (FQDN : sbc12.adatum.biz, après avoir supprimé la partie hôte : adatum.biz) et case activée si ce nom est inscrit en tant que nom DNS dans microsoft 365 ou Office 365 organization. Si elle est trouvée, la recherche de l’utilisateur est effectuée dans ce locataire. S’il est introuvable, l’appel échoue.
À l’aide du numéro de téléphone présenté dans l’URI de requête, effectuez la recherche de numéro inverse dans le locataire trouvé à l’étape 2 ou 3. Faire correspondre le numéro de téléphone présenté à un URI SIP utilisateur dans le locataire trouvé à l’étape précédente.
Appliquez les paramètres de jonction. Recherchez les paramètres définis par l’administrateur du locataire pour ce SBC.
Microsoft ne prend pas en charge l’utilisation d’un proxy SIP tiers ou d’un serveur d’agent utilisateur entre le proxy SIP Microsoft et le SBC jumelé, ce qui peut modifier l’URI de requête créé par le SBC appairé.
Les conditions requises pour les deux recherches (étapes 2 et 3) nécessaires au scénario où un SBC est interconnecté à de nombreux locataires (scénario d’opérateur) sont abordées plus loin dans cet article.
Exigences détaillées pour l’en-tête de contact et l’URI de requête
En-tête de contact
Pour tous les messages SIP entrants (OPTIONS, INVITE) vers le proxy SIP Microsoft, l’en-tête Contact doit avoir le nom de domaine complet SBC couplé dans le nom d’hôte de l’URI comme suit :
Syntaxe : Contact : <sip :phone ou sip address@FQDN du SBC ; transport=tls>
Conformément à la RFC 3261, section 11.1, un champ d’en-tête de contact peut être présent dans un message OPTIONS. Dans Routage direct, l’en-tête de contact est requis. Pour les messages INVITE au format ci-dessus, pour les messages OPTIONS, les informations utilisateur peuvent être supprimées de l’URI SIP et uniquement le nom de domaine complet envoyé au format suivant :
Syntaxe : Contact : <sip :FQDN du SBC ; transport=tls>
Ce nom (FQDN) doit également se trouver dans les champs Nom commun ou Autre nom de l’objet du certificat présenté. Microsoft prend en charge l’utilisation de valeurs génériques du ou des noms dans les champs Nom commun ou Autre nom de l’objet du certificat.
La prise en charge des caractères génériques est décrite dans RFC 2818, section 3.1. Spécifiquement:
« Les noms peuvent contenir le caractère générique *, qui est considéré comme correspondant à n’importe quel composant de nom de domaine unique ou fragment de composant. 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 dans l’en-tête Contact présenté dans un message SIP sont envoyées par le SBC, seule la partie FQDN de la première valeur de l’en-tête Contact est utilisée.
Pour le routage direct, il est important que le nom de domaine complet soit utilisé pour remplir l’URI SIP au lieu de l’adresse IP. Message INVITE ou OPTIONS entrant vers le proxy SIP avec un en-tête Contact où le nom d’hôte est représenté par l’adresse IP et non par le nom de domaine complet, la connexion est refusée avec 403 Interdit.
URI de requête
Pour tous les appels entrants, l’URI de requête est utilisé pour faire correspondre le numéro de téléphone à un utilisateur.
Actuellement, le numéro de téléphone doit contenir un signe plus (+) comme indiqué dans l’exemple suivant.
INVITE sip:+18338006777@sip.pstnhub.microsoft.com SIP /2.0
À partir de l’en-tête
Pour tous les appels entrants, l’en-tête From est utilisé pour faire correspondre le numéro de téléphone de l’appelant à la liste des numéros de téléphone bloqués de l’appelé et pour effectuer une recherche de numéro inversée afin de rechercher le nom de l’appelant à partir des enregistrements client et utilisateur existants.
Pour que ces recherches fonctionnent, le numéro de téléphone doit contenir un signe + comme indiqué dans l’exemple suivant.
From: <sip:+17168712781@sbc1.adatum.biz;transport=udp;tag=1c747237679
Considérations relatives aux en-têtes de contact et de Record-Route
Le proxy SIP doit calculer le nom de domaine complet du tronçon suivant pour les nouvelles transactions clientes dans les boîtes de dialogue (par exemple Bye ou Réinviter) et lors de la réponse aux options SIP. Contact ou Record-Route sont utilisés.
Selon la RFC 3261, section 8.1.1.8, l’en-tête de contact est requis dans toute demande qui peut entraîner une nouvelle boîte de dialogue. La Record-Route est requise uniquement si un proxy souhaite rester sur le chemin des requêtes futures dans une boîte de dialogue. Si un SBC proxy est utilisé avec l’optimisation des médias locaux pour le routage direct, un itinéraire d’enregistrement doit être configuré car le SBC proxy doit rester dans l’itinéraire.
Microsoft recommande d’utiliser uniquement l’en-tête Contact si aucun SBC proxy n’est utilisé :
Conformément à la section 20.30 de la RFC 3261, Record-Route est utilisé si un proxy souhaite rester sur le chemin des requêtes futures dans un dialogue, ce qui n’est pas essentiel si aucun SBC proxy n’est configuré, car tout le trafic passe entre le proxy SIP Microsoft et le SBC jumelé.
Le proxy SIP Microsoft utilise uniquement l’en-tête Contact (et non Record-Route) pour déterminer le tronçon suivant lors de l’envoi des options ping sortantes. La configuration d’un seul paramètre (Contact) au lieu de deux (Contact et Record-Route) simplifie l’administration si un SBC proxy n’est pas utilisé.
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 de domaine complet, le nom de domaine complet 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. (Il s’agit de la configuration recommandée.)
Si contact et Record-Route sont utilisés, l’administrateur SBC doit conserver leurs valeurs identiques, ce qui entraîne une surcharge administrative.
Utilisation du nom de domaine complet dans contact ou Record-Route
L’utilisation d’une adresse IP n’est pas prise en charge dans Record-Route ou contact. La seule option prise en charge est un nom de domaine complet, qui doit correspondre au nom commun ou à l’autre nom de l’objet 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, le certificat case activée échoue et l’appel échoue.
Si le nom de domaine complet ne correspond pas à la valeur de l’autre nom commun ou de l’objet dans le certificat présenté, l’appel échoue.
Appel entrant : description de la boîte de dialogue SIP
Le tableau suivant récapitule les différences de flux d’appels et les similitudes entre les modes de contournement et de contournement :
| Nom du paramètre | Mode sans contournement | Mode de contournement |
|---|---|---|
| Candidats aux médias dans 183 et 200 messages provenant de | Processeurs multimédias | Clients |
| Nombre de 183 messages que SBC peut recevoir | Un par session | Plusieurs |
| L’appel peut être avec une réponse provisoire (183) | Oui | Oui |
| L’appel peut être sans réponse provisoire (183) | Oui | Oui |
Flux de contournement non multimédia
Un utilisateur Teams peut avoir plusieurs points de terminaison en même temps. Par exemple, le client Teams pour Windows, le client Teams pour iPhone et Téléphonie Teams (client Android Teams). Chaque point de terminaison peut signaler un repos HTTP comme suit :
Progression de l’appel : convertie par le proxy SIP en message SIP 180. Lors de la réception du message 180, le SBC doit générer une sonnerie locale.
Réponse multimédia : convertie par le proxy SIP en message 183 avec des candidats multimédias dans le protocole SDP (Session Description Protocol). À la réception du message 183, le SBC s’attend à se connecter aux candidats des médias reçus dans le message SDP.
Remarque
Dans certains cas, la réponse 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 SDP fournis.
Remarque
Le routage direct ne prend pas en charge l’invitation d’offre différée (invitation sans SDP).
Sonnerie de plusieurs points de terminaison avec réponse provisoire
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 avertit tous les points de terminaison de l’utilisateur final de l’appel entrant.
Lors de la notification, chaque point de terminaison commence à sonner et à envoyer des messages « Progression de l’appel » au proxy SIP. Étant donné qu’un utilisateur Teams peut avoir plusieurs points de terminaison, le proxy SIP peut recevoir plusieurs messages de progression des appels.
Pour chaque message de progression de l’appel reçu des clients, le proxy SIP convertit le message d’avancement de l’appel en message SIP « SIP SIP SIP/2.0 180 Sonnerie ». L’intervalle d’envoi de ces messages est défini par 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 Teams de l’utilisateur. Les clients ont chacun un ID de balise unique. Chaque message provenant d’un point de terminaison différent est une session distincte (le paramètre « tag » dans le champ « À » est différent). Toutefois, 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.
Une fois qu’un point de terminaison génère un message Media Answer avec les adresses IP des candidats multimédias du point de terminaison, le proxy SIP convertit le message reçu en message « Progression de la session SIP 183 » avec le SDP du client remplacé par le SDP du processeur multimédia. Dans le diagramme suivant, le point de terminaison de Fork 2 a répondu à l’appel. Si la jonction n’est pas contournée, le message SIP 183 n’est généré qu’une seule fois (ring bot ou point de terminaison client). La 183 peut venir sur une fourche existante ou en démarrer une nouvelle.
Un message d’acceptation d’appel est envoyé 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.
Sonnerie de plusieurs points de terminaison sans réponse provisoire
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 avertit tous les points de terminaison de l’utilisateur final de l’appel entrant.
Lors de la notification, chaque point de terminaison commence à sonner et à envoyer le message « Progression de l’appel » au proxy SIP. Étant donné qu’un utilisateur Teams peut avoir plusieurs points de terminaison, le proxy SIP peut recevoir plusieurs messages de progression des appels.
Pour chaque message de progression de l’appel reçu des clients, le proxy SIP convertit le message De progression de l’appel en message SIP « SIP SIP/2.0 180 Tentative ». L’intervalle d’envoi des messages est défini par l’intervalle de réception des messages du contrôleur d’appel. Dans le diagramme suivant, deux 180 messages sont générés par le proxy SIP, ce qui signifie que l’utilisateur s’est connecté à trois clients Teams et que chaque client envoie la progression de l’appel. Chaque message est une session distincte (le paramètre « tag » dans le champ « À » est différent)
Un message d’acceptation d’appel est envoyé 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.
Flux de contournement de média
Les mêmes messages (100 tentatives, 180, 183) sont utilisés dans le scénario de contournement de média.
Le schéma suivant montre un exemple de flux d’appels de contournement.
Remarque
Les candidats multimédias peuvent provenir de différents points de terminaison.
Option De remplacement
Le SBC doit prendre en charge invite avec remplacements.
Considérations relatives à la taille de SDP
L’interface de routage direct peut envoyer un message SIP dépassant 1 500 octets. La taille de SDP est principalement à l’origine de ce problème. Toutefois, s’il existe une jonction UDP derrière le SBC, il peut rejeter le message s’il est transféré du proxy SIP Microsoft vers la jonction non modifiée. Microsoft recommande de supprimer certaines valeurs dans 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 pour le transfert d’appel :
Option 1. Les processus proxy SIP font référence à partir du client localement et agissent en tant qu’arbitre 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 la référence au SBC et agit en tant que transferor comme décrit dans la section 6 de la RFC 5589.
Avec cette option, le proxy SIP envoie une référence au SBC et s’attend à ce qu’il gère 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.
Voici un exemple de 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 l’option Référencer en tant que méthode prise en charge, le routage direct utilise l’option 1 (le proxy SIP fait office d’arbitre). 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 prise en charge :
ALLOW: INVITE, ACK, CANCEL, BYE, INFO, NOTIFY, PRACK, UPDATE, OPTIONS
Processus proxy SIP : référence à partir du client localement et agit en tant qu’arbitre
Si le SBC indique que la méthode Refer n’est pas prise en charge, le proxy SIP agit comme un arbitre.
La demande de référence qui provient du client est terminée sur le proxy SIP. La demande de référence du client est illustrée sous la forme « Transfert d’appel à Dave » dans le diagramme suivant. Pour plus d’informations, consultez la section 7.1 de la RFC 3892.
Le proxy SIP envoie la référence au SBC et agit en tant que transferor
Il s’agit de la méthode recommandée pour les transferts d’appels, et elle est obligatoire pour les appareils qui souhaitent obtenir une certification de contournement multimédia. Le transfert d’appel sans que le SBC puisse gérer Refer n’est pas pris en charge en mode de contournement multimédia.
La norme est expliquée à la section 6 de la RFC 5589. Les RFC associées sont les suivantes :
Contrôle d’appel SIP (Session Initiation Protocol) - Transfert
En-tête « Remplace » du protocole SIP (Session Initiation Protocol)
Mécanisme « Référencé par » du protocole SIP (Session Initiation Protocol)
Cette option part du principe que le proxy SIP agit comme un transfereur et envoie un message De référence au SBC. Le SBC agit en tant que cessionnaire et gère la référence pour générer une nouvelle offre de transfert. Il existe deux cas possibles :
- L’appel est transféré à un participant RTC externe.
- L’appel est transféré d’un utilisateur Teams à un autre utilisateur Teams dans le même locataire via le SBC.
Si l’appel est transféré d’un utilisateur Teams à un autre via le SBC, le SBC est censé émettre une nouvelle invitation (démarrer une nouvelle boîte de dialogue) pour la cible de transfert (l’utilisateur Teams) à l’aide des informations reçues dans le message De référence.
Pour remplir les champs To/Transferor pour 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 en tant qu’URI SIP composé d’un nom de domaine complet du proxy SIP dans le nom d’hôte et de l’un des éléments suivants :
Un numéro de téléphone E.164 dans la partie nom d’utilisateur de l’URI au cas où la cible de transfert est un numéro de téléphone, ou
Paramètres x-m et x-t encodant respectivement l’IRM cible de transfert complet et l’ID de locataire
L’en-tête REFERRED-BY est un URI SIP avec l’IRM du transféreur encodée, ainsi que l’ID de locataire du transfert et d’autres paramètres de contexte de transfert, comme indiqué dans le tableau suivant :
| Paramètre | Valeur | Description% |
|---|---|---|
| x-m | IRM | IRM complète du transfert/cible de transfert tel que rempli par CC |
| x-t | Identifiant du client | ID de locataire x-t ID de locataire facultatif tel que rempli par CC |
| x-ti | ID de corrélation du transfert | ID de corrélation de l’appel au transfert |
| x-tt | URI d’appel cible de transfert | URI de remplacement d’appel encodé |
Dans ce cas, la taille de l’en-tête de référence peut atteindre 400 symboles. Le SBC doit prendre en charge la gestion des messages de référence dont la taille peut atteindre 400 symboles.
Transfert d’appel
Un utilisateur Teams peut transférer les appels entrants à un autre numéro ou utilisateur Teams, sonner un autre utilisateur ou des utilisateurs en parallèle (sonnerie simultanée) ou sonner un groupe d’utilisateurs ou de numéros. Vous devez tenir compte des éléments suivants :
Request-URI dans INVITE request from SIP proxy to User C contient le paramètre cause .
En fonction des configurations de jonction (paramètre ForwardCallHistory ), l’en-tête History-Info est rempli.
Lorsque l’utilisateur A est un autre utilisateur RTC, le proxy SIP génère la réponse provisoire « L’appel SIP SIP/2.0 181 est transféré » à l’utilisateur A.
Si l’utilisateur A et l’utilisateur C sont des utilisateurs RTC, le proxy SIP conserve la réponse provisoire « L’appel SIP SIP/2.0 181 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 (offre toujours) le minuteur de session sur les appels sans contournement, mais ne l’offre pas sur les appels de contournement. 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 l’URI de demande et, si le paramètre user=phone est présent, le service gère l’URI de requête en tant que 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 heuristique pour déterminer le type d’utilisateur Request-URI (numéro de téléphone ou adresse SIP).
Microsoft recommande de toujours appliquer le paramètre user=phone pour simplifier le processus de configuration des appels.
en-tête History-Info
L’en-tête History-Info est utilisé pour recibler les demandes SIP et « fournir un mécanisme standard pour capturer les informations de l’historique des demandes afin d’activer un large éventail de services pour les réseaux et les utilisateurs finaux ». Pour plus d’informations, consultez RFC 4244 – Section 1.1. Pour le système téléphonique Microsoft, cet en-tête est utilisé dans les scénarios de simulation et de transfert d’appel.
En cas d’envoi, le History-Info est activé comme suit :
Le proxy SIP insère un paramètre contenant le numéro de téléphone associé dans des entrées de 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 jonction SIP via le proxy SIP.
History-Info'en-tête est ajouté pour les cas de sonnerie et de transfert d’appel simultanés.
History-Info'en-tête ne sera pas ajouté pour les cas de transfert d’appel.
Une entrée d’historique individuelle dans l’en-tête de History-Info reconstruit a le paramètre de numéro de téléphone fourni combiné au nom de domaine complet (sip.pstnhub.microsoft.com) de routage direct défini comme partie hôte de l’URI . un paramètre 'user=phone' est 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 de téléphone, sont transmis dans l’en-tête History-Info recréé.
Remarque
Les entrées privées (telles que déterminées par les mécanismes définis dans la section 3.3 de la RFC 4244) sont transférées telles quels, car le fournisseur de jonction SIP est un homologue approuvé.
La History-Info entrante est conservée lorsque le paramètre ForwardCallHistory est activé. Les History-Info conservées peuvent être utilisé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 relatives à chaque redirection sont incluses avec la raison appropriée dans l’ordre chronologique, dans une liste séparée par des virgules.
Exemple d’en-tête :
History-Info:
<sip:+14257123456@sip.pstnhub.microsoft.com:5061;user=phone?Reason=SIP%3Bcause%3D302%3Btext%3D%22Moved%20temporarily%22>;index=1,
<sip:+14257123456@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 Reason d’URI est SIP;cause=496;text="User Busy", qui obtient ses ;caractères , "et = placés dans une séquence d’échappement vers leurs valeurs %3Bhexadécimale ASCII , %22et 3D, respectivement.
Le History-Info est protégé par un mécanisme TLS obligatoire.
Connexion SBC au mécanisme de routage direct et de basculement
Consultez la section Mécanisme de basculement pour la signalisation SIP dans Planifier le 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 à une INVITATION, le SBC doit mettre fin à cette connexion et essayer le centre de données Microsoft disponible suivant.
Gestion des nouvelles tentatives (réponse 603)
Si un utilisateur final observe plusieurs appels manqués pour un appel après avoir refusé l’appel entrant, cela signifie que le mécanisme de nouvelle tentative du fournisseur de jonction SBC ou RTC est mal configuré. Le SBC doit être reconfiguré pour arrêter les efforts de nouvelle tentative sur la réponse 603.
Redémarrage ICE : appel de contournement de média transféré vers un point de terminaison qui ne prend pas en charge la déviation du trafic multimédia
Le SBC doit prendre en charge les redémarrages ICE, comme décrit dans RFC 5245, section 9.1.1.1.
Le redémarrage dans le routage direct est implémenté conformément aux paragraphes suivants de la RFC :
Pour redémarrer ICE, un agent DOIT changer à la fois le ice-pwd et le ice-ufrag pour le flux multimédia dans une offre. Il est autorisé d’utiliser un attribut de niveau session dans une offre, mais de fournir le même ice-pwd ou ice-ufrag qu’un attribut au niveau du média dans une offre ultérieure. Il ne s’agit pas d’une modification du mot de passe, mais simplement d’une modification de sa représentation et n’entraîne pas de redémarrage d’ICE.
Un agent définit le reste des champs du SDP pour ce flux multimédia, comme il le ferait dans une offre initiale de ce flux multimédia (voir la section 4.3). Par conséquent, l’ensemble des candidats PEUT inclure certains, aucun ou la totalité des candidats précédents pour ce volet, et PEUT inclure un nouvel ensemble de candidats, comme décrit à la section 4.1.1.
Si l’appel a été initialement établi avec la déviation du trafic multimédia et que l’appel est transféré vers un client Skype Entreprise, le routage direct doit insérer un processeur multimédia, car le routage direct ne peut pas être utilisé avec un client Skype Entreprise avec déviation du trafic multimédia. Le routage direct démarre le processus de redémarrage ice-pwd et ice-ufrag et offre de nouveaux candidats multimédias dans une réinvitation.