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 implémente les protocoles standard RFC. 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 soit capable de recevoir SDP avec une adresse de connexion de 0.0.0.0, auquel cas cela signifie que ni RTP ni RTCP ne doivent être envoyés à 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 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

Lors de l’envoi d’une requête SIP (nouvelle ou en dialogue), le proxy SIP Microsoft peut ouvrir une nouvelle connexion TCP/TLS ou réutiliser une connexion existante, le cas échéant.

  • Il existe un maximum de deux connexions TCP/TLS 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.

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 selon RFC 5626 : Managing Client-Initiated Connections in the Session Initiation Protocol (SIP) .

    • 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 pointage, (FIN, ACK) est transmis au SBC fournisseur par proxy SIP dans un délai d’environ 10 à 20 secondes.

Remarques

  • Il est recommandé que le SBC réutilise activement les connexions, comme 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

DTMF in-band n’est pas pris en charge par la pile multimédia.