Partager via

Routage direct : définitions et normes RFC

  • Article
  • S’applique à:
    Microsoft Teams

Cet article décrit comment Téléphonie Teams routage direct utilise les protocoles standard définis par les requêtes de commentaires (RFC) du Groupe de travail d’ingénierie Internet. Cet article est destiné aux administrateurs vocaux qui sont responsables de la configuration de la connexion entre le contrôleur SBC (Session Border Controller) local et le service proxy SIP (Session Initiation Protocol).

Le SBC client s’interface avec les composants suivants dans le back-end Microsoft Teams :

  • Proxy SIP pour la signalisation. Ce composant est le composant internet du routage direct qui gère les connexions SIP (TLS) entre les SBC et le routage direct.

  • Processeurs multimédias pour média. Ce composant est le composant internet du routage direct qui gère le trafic multimédia. Ce composant utilise les protocoles SRTP et SRTCP.

Pour plus d’informations sur le routage direct, consultez routage direct Téléphonie Teams.

Pour plus d’informations sur la façon dont le routage direct implémente le protocole SIP, consultez Routage direct - Protocole SIP.

Normes RFC

Le routage direct est conforme aux normes RFC. Le SBC connecté au routage direct doit également respecter les RFC suivants (ou leurs successeurs).

Normes applicables aux appareils qui prennent en charge le mode de contournement non multimédia

Les normes suivantes s’appliquent aux appareils qui prennent uniquement en charge le mode de contournement non multimédia :

  • RFC 3261 SIP : Protocole d’initiation de session
  • RFC 3325 Extension privée au protocole d’initiation de session pour l’identité déclarée dans les réseaux de confiance - Sections sur la gestion de l’en-tête P-Asserted-Identity. Le routage direct envoie P-Asserted-Identity avec des en-têtes d’ID de confidentialité.
  • RFC 4244 Extension du protocole SIP (Session Initiation Protocol) pour les informations d’historique requises. Consultez aussi : Description du protocole SIP de routage pour plus d’informations.
  • RFC 3892 Mécanisme de Referred-By du protocole d’initiation de session
  • RFC 3891 L’en-tête « Remplace » du protocole d’initiation de session (SIP)
  • RFC 6337 Utilisation du protocole SIP (Session Initiation Protocol) du modèle d’offre/réponse. Consultez la section « Écarts par rapport à RFC ».
  • RFC 3711 et RFC 4771. Protégez le trafic RTP à l’aide de SRTP. Le SBC doit être en mesure d’établir des clés à l’aide de SDES.
  • RFC 8035 Clarifications des offres/réponses du protocole SDP (Session Description Protocol) pour le multiplexage RTP/RTCP

Normes applicables aux appareils qui prennent en charge le mode de contournement multimédia

En plus des normes répertoriées comme applicables au mode sans passage, les normes suivantes sont utilisées pour le mode de contournement du trafic multimédia :

Normes applicables à la prise en charge de la transmission d’informations d’emplacement aux fournisseurs E911

Écarts par rapport aux RFC

Le tableau suivant répertorie les sections des RFC dans lesquelles l’implémentation de la pile sip ou multimédia par Microsoft s’écarte de la norme :

RFC et sections Description Déviation
RFC 6337, section 5.3 Conservation et reprise du média RFC permet d’utiliser « a=inactive », « a=sendonly », a=recvonly » pour placer un appel en attente. Le proxy SIP prend uniquement en charge « a=inactive » et ne comprend pas si le SBC envoie « a=sendonly » ou « a=recvonly ».
RFC 6337, section 5.4 Comportement sur la réception de SDP avec c=0.0.0.0 RFC3264 exige qu’un agent puisse recevoir SDP avec une adresse de connexion 0.0.0.0, indiquant de ne pas envoyer RTP ou RTCP à l’homologue. Le proxy SIP ne prend pas en charge cette option.
RFC 3261, section 25 BNF augmentée pour le protocole SIP Le caractère '#' doit être envoyé en tant que '%23' Le proxy SIP envoie le caractère « # » dans un URI de requête sans séquence d’échappement.
RFC 3264, section 8.3.1 Modèle d’offre/réponse avec SDP RFC 3264 détaille un mécanisme de reciblage de média MAY (facultatif) permettant de modifier le port multimédia, l’adresse IP ou le transport après l’établissement de la session. Le reciblage multimédia facultatif n’est pas pris en charge. Pendant un appel, les demandes SIP pour mettre à jour le port multimédia, l’adresse IP ou le transport ne sont pas prises en charge. Le média n’est pas envoyé à la cible de session mise à jour ; les médias du routage direct continuent de circuler vers la cible d’origine.

Remarque de la RFC prenant en charge le choix ; L’offreur DOIT être prêt à recevoir des médias sur l’ancien et le nouveau port dès que l’offre est envoyée. L’offreur NE DOIT PAS cesser d’écouter les médias sur l’ancien port jusqu’à ce que la réponse soit reçue et que le média arrive sur le nouveau port.|

Considérations relatives au transport TCP/TLS

Lorsque le proxy SIP de Microsoft envoie une requête SIP (nouvelle ou en dialogue), il peut ouvrir une nouvelle connexion TCP/TLS ou réutiliser une connexion existante, le cas échéant.

  • Un maximum de deux connexions TCP/TLS sont autorisées par nom de domaine complet/IP distant, par machine virtuelle proxy SIP. Avant d’envoyer une requête SIP, le proxy SIP recherche les connexions TCP actives avec l’adresse IP résolue du nom de domaine complet SBC/Trunk cible. S’il existe deux connexions, elles sont réutilisées. Si deux connexions n’existent pas, une nouvelle connexion est ouverte.

    • Cette logique est par machine virtuelle proxy SIP.

    • Les adresses IP de proxy SIP sont prises en charge par plusieurs machines virtuelles par région.

    • Du point de vue SBC, il peut y avoir plusieurs connexions proxy entrantes à partir de toutes les régions proxy SIP.

  • Les connexions TCP/TLS ouvertes par le proxy SIP ne restent pas nécessairement ouvertes tant que l’appel le fait. Toutefois, la connexion ne se ferme pas immédiatement après une réponse à une requête SIP. Si une connexion n’expire pas, elle peut être réutilisée pour d’autres requêtes SIP.

  • Le proxy SIP ne prend pas en charge l’alias de connexion comme décrit dans RFC 5923 : Réutilisation de la connexion dans le protocole SIP (Session Initiation Protocol).

    • Les connexions TCP de proxy SIP sortants ne service que les requêtes proxy SIP sortantes (vers les SBC) et les réponses associées.

    • Les connexions TCP du proxy SIP entrant (à partir de SBC) ne service que les requêtes SIP entrantes et les réponses associées.

N’oubliez pas que dans certaines situations, les passerelles/SBC tierces peuvent marquer les réinitialisations de connexion TLS pour les services O365. Le comportement de réinitialisation de connexion est attendu, car les nouvelles connexions sont générées dynamiquement sans affecter l’expérience utilisateur.

Stratégies de délai d’expiration

  • Le délai d’inactivité TCP du proxy SIP est de deux minutes. Le minuteur se réinitialise lorsqu’une transaction SIP se produit sur la connexion.

  • Le proxy SIP envoie l’application CRLF keep-alive conformément à la RFC 5626 : Gestion des Client-Initiated Connections dans le protocole SIP (Session Initiation Protocol).

    • Le keep-alive ne réinitialise pas le minuteur d’inactivité TCP.

    • Le crlf keep-alive envoyé par le SBC fournisseur réinitialise le minuteur d’inactivité TCP.

  • En raison de la contrainte d’alias mentionnée précédemment, le SBC fournisseur ne doit pas utiliser les demandes SIP en dialogue pour réinitialiser le minuteur sur les connexions créées par le proxy SIP sortant vers le SBC fournisseur.

  • Après deux minutes de marche au moteur (FIN, ACK) sont transmises au SBC fournisseur par proxy SIP dans un délai d’environ 10 à 20 secondes.

Remarques

  • Le SBC doit réutiliser activement les connexions, telles que le proxy SIP. Cette méthode permet de gagner du temps, ce qui est nécessaire pour les connexions TCP et TLS.

  • Le SBC doit renouveler la connexion au moins une fois par heure.

  • Lorsque le certificat d’un nouveau SBC est chargé, le SBC doit renouveler toutes les connexions.

  • Lorsque les configurations de domaine sont mises à jour, il est recommandé de renouveler les connexions du SBC. Dans le cas contraire, une nouvelle configuration sera appliquée après le renouvellement du cache du proxy SIP interne ( jusqu’à quatre heures).

Modes opérationnels

Il existe deux modes opérationnels pour le routage direct :

  • Sans contournement multimédia dans lequel tout le trafic RTP circule entre le client Teams, les processeurs multimédias et le SBC.

  • Avec déviation du trafic multimédia dans lequel tous les médias RTP circulent entre les points de terminaison Teams et le SBC.

Le trafic SIP transite toujours par le proxy SIP.

DTMF

La pile multimédia ne prend pas en charge DTMF in-band.