Routage direct - Protocoles multimédias

  • Article
  • S’applique à:
    Microsoft Teams

Cet article décrit comment le routage direct prend en charge le contournement multimédia avec un contrôleur de bordure de session (SBC) activé pour ICE Lite, comme décrit dans RFC 5245. 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.

Cet article fournit une vue d’ensemble des scénarios ice Lite et des exigences en matière d’interopérabilité. L’article décrit les formats de message et les transitions d’ordinateur d’état requises pour garantir la fiabilité des appels et du flux multimédia.

Terminologie

  • First Hello : premiers mots prononcés par l’appelant et l’appelé. Il est important que tous les efforts soient faits pour garantir que les premiers paquets des points de terminaison sont remis de manière fiable pour la plupart des cas d’usage.

  • Duplication : l’offre de l’appelant peut être remise à plusieurs points de terminaison appelés si l’appelé est disponible sur plusieurs appareils (par exemple, un utilisateur Teams peut être connecté à Teams pour Windows et Teams pour Android ou iPhone).

  • Réponse provisoire (183) : les points de terminaison appelés pour accélérer la configuration des appels envoient une réponse avec les candidats et les clés nécessaires pour établir le flux multimédia. Cette réponse est effectuée en prévision de la réponse potentielle de l’utilisateur à l’appel (200OK) à partir de cet appelé spécifique instance. Avec la duplication, l’appelant doit être prêt à recevoir plusieurs réponses provisoires.

  • Re-Invite : offre avec les candidats finaux sélectionnés par le point de terminaison de contrôle ICE. Cette offre a l’attribut a=remote-candidate pour résoudre les conditions de concurrence liées à la gestion de plusieurs duplications.

  • Point de terminaison Teams : ce point de terminaison peut être un serveur (processeur multimédia, relais de transport) ou le client Teams.

Format de message

L’infrastructure Teams suit la norme RFC 5245 pour ICE-Lite. Tous les messages STUN sont conformes à la norme RFC 5389.

Les SBC, comme l’exige la RFC 5389, doivent ignorer tous les attributs STUN qu’ils ne reconnaissent pas et continuer à traiter les messages avec les attributs connus.

Si des paquets mal formés sont reçus, les paquets doivent être ignorés sans affecter l’établissement de la session multimédia.

Configuration requise pour ICE Lite

Cette section présente brièvement les exigences pour ICE Lite.

Collecte des candidats

Le SBC ne doit proposer qu’un seul candidat. Actuellement, seuls les candidats IPV4 sont pris en charge.

Vérifications de connectivité

L’implémentation ICE Lite doit répondre à toutes les vérifications de connectivité reçues. Le point de terminaison ICE Lite ne doit pas envoyer de requêtes de connectivité case activée. (Si les vérifications de connectivité sont envoyées en violation, l’implémentation complète répond, ce qui peut entraîner la découverte de candidats dérivés d’homologues inattendus et entraîner des échecs d’appel.)

Nominations

Le point de terminaison d’implémentation complète ice est le point de terminaison de contrôle et suit les nominations « régulières » pour la sélection des candidats finaux à utiliser pour le flux multimédia. Le point de terminaison ICE Lite peut utiliser les nominations pour conclure le chemin à utiliser pour les médias et terminer l’établissement des appels.

Lors de la duplication avec des points de terminaison homologues envoie 183 réponses provisoires, le SBC doit être prêt à répondre aux vérifications de plusieurs points de terminaison et également aux nominations de plusieurs points de terminaison si les nominations ont lieu avant 200OK. En fonction de la convergence de l’ordinateur d’état ICE sur le chemin final et le minutage de la réponse de l’utilisateur, les nominations peuvent se produire avant ou après 200OK. Le SBC doit être en mesure de gérer les deux cas.

Convergence pour la duplication

Si l’offre du SBC est associée à plusieurs points de terminaison Teams, les points de terminaison Teams peuvent répondre avec une réponse provisoire et démarrer les vérifications de connectivité. Le SBC doit être prêt à recevoir des vérifications de connectivité et à répondre aux vérifications de connectivité à partir de plusieurs points de terminaison homologues. Par exemple, l’utilisateur Teams peut être connecté à un ordinateur de bureau et à un téléphone portable. Les deux appareils sont avertis de l’appel entrant et tenteront de vérifier la connectivité avec le SBC.

Finalement, un seul des points de terminaison répond à l’appel (200OK). Lors de la réception du 200OK, le SBC peut configurer le contexte approprié pour le traitement des paquets multimédias.

Scénarios

Appel entrant à partir de SBC

Pour ce scénario, il existe plusieurs points de terminaison homologues possibles que le SBC doit gérer :

  • Les points de terminaison de serveur répondent généralement directement avec 200OK. Ces points de terminaison ICE Full sont généralement impliqués dans les scénarios de messagerie vocale, de file d’attente d’appels et de standard automatique.

  • Les points de terminaison client peuvent envoyer plusieurs réponses provisoires avec différentes balises De/À (183) suivies d’un 200OK à partir du point de terminaison qui répond à l’appel. Ces points de terminaison ICE Full représentent généralement les clients des utilisateurs finaux.

  • Autres points de terminaison SBC. Ces points de terminaison ICE Lite sont généralement impliqués dans le scénario de sonnerie simultanée des points de terminaison clients et d’un autre numéro de téléphone.

Le SBC doit répondre à toutes les demandes de connectivité case activée valides reçues des points de terminaison ICE Full. Selon RFC, les points de terminaison ICE Full deviennent des points de terminaison de contrôle. Les points de terminaison Teams (client/serveur) effectuent des nominations « régulières » pour effectuer des vérifications de connectivité. Le 200Ok final peut provenir d’un point de terminaison qui a envoyé un média précoce ou d’un autre point de terminaison. Lors de la réception du 200Ok, le SBC doit configurer le contexte approprié pour le flux multimédia.

Médias précoces

S’il existe un flux multimédia précoce, le SBC doit s’accrocher au premier point de terminaison qui démarre la diffusion multimédia en continu . le flux de médias peut commencer avant que les candidats ne soient nommés. Le SBC doit prendre en charge l’envoi de DTMF pendant cette phase afin d’activer les scénarios de messagerie vocale/ivR. Le SBC doit utiliser le chemin de priorité la plus élevée sur lequel il a reçu des vérifications si les nominations ne sont pas terminées.

Appel sortant vers SBC

Les points de terminaison Teams sont l’appelant pour ce scénario et sont le point de terminaison de contrôle. Lors de la réception d’une réponse provisoire (183) ou d’une réponse finale (200OK), le point de terminaison Teams démarre les vérifications de connectivité et passe aux nominations « régulières » pour terminer les vérifications de connectivité.

Remarque : Si le SBC envoie une réponse provisoire (183), le SBC doit être prêt à recevoir la connectivité case activée demandes et éventuellement compléter les candidatures avant d’envoyer le 200OK. Si des vérifications et/ou des nominations sont effectuées avant la réception du 200OK, les vérifications et/ou les nominations ne seront plus effectuées après la réception de 200OK. Le SBC ne doit pas modifier les candidats ICE, le mot de passe et l’ufrag (fragment de nom d’utilisateur) entre 183 et 200.

Pour prendre en charge les médias précoces, le SBC peut commencer à diffuser en continu les médias vers le candidat ICE pair, avec la priorité la plus élevée en fonction des vérifications de connectivité reçues, avant même que les nominations ne soient effectuées par le point de terminaison Teams. Le SBC doit s’attendre à recevoir des médias de Teams sur n’importe quel candidat jusqu’à ce que les nominations soient terminées. Une fois qu’un candidat est nommé, le SBC doit rétablir le contexte approprié pour envoyer et recevoir des paquets multimédias.

Gestion des lignes M dans SDP

Dans certains scénarios d’appel, d’autres modalités multimédias peuvent être proposées lors d’un appel au RTC. Par exemple, m=video si un appel vidéo Teams est transféré au RTC. Si le SBC client est configuré avec la déviation du trafic multimédia, ces lignes ne seront pas supprimées par le service et doivent être gérées par le SBC suivant RFC3264 : Pour chaque ligne non « m=audio » de l’offre, le SBC doit inclure une ligne « m= » correspondante dans la réponse, et le numéro de port dans cette ligne doit être défini sur zéro, rejetant efficacement tous les flux non audio.

Configuration requise pour la prise en charge de SRTP

Le SBC doit prendre en charge le chiffrement de chiffrement SRTP AES_CM_128_HMAC_SHA1_80 pour l’offre et la réponse au format suivant :

"inline:" <key||salt> ["|" lifetime]

Voici un exemple d’attribut de chiffrement dans l’offre SDP du SBC :

a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:V/Lr6Lsvhad/crSB9kCQ28jrYDxR2Yfk5bXryH5V|2^31

Les paramètres MKI et Length ne sont pas requis.

Pour plus d’informations, consultez RFC 4568, section 6.1.

Exigences de prise en charge de SDES

L’appareil doit être en mesure d’offrir SDES au format suivant. Les processeurs multimédias Microsoft préfèrent toujours SDES.

  • Avec la déviation non multimédia, même si un client prend uniquement en charge DTLS, les processeurs multimédias sont convertis en SDES.

  • Avec la déviation du trafic multimédia, si un client est DTLS uniquement (futur état Google Chrome), le routage direct insère un mp dans le chemin, convertissant l’appel de la déviation du trafic multimédia en contournement non multimédia. Entre le SBC et le composant processeur multimédia du routage direct, SDES est toujours utilisé.

Actuellement, aucun client Teams n’offre uniquement DTLS ; cependant Google a annoncé qu’à un moment donné, ils cesseront de prendre en charge SDES.

Format de l’offre de SBC en mode contournement

L’offre doit contenir SDES et peut contenir des DTLS facultatifs au format suivant :

m=audio 54056 UDP/TLS/RTP/SAVP 0 8 76 77 18 9 101 13
a=rtcp:54056
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:krXco0QRglwErMqtbMs2zSw29tBdmdgXpEYZhQmp|2^31
a=fingerprint:sha-256 AE:24:07:15:5C:B7:45:1A:E4:45:60:C1:1E:68:0E:CC:8D:A6:78:3B:76:65:BB:B0:77:88:07:F8:98:18:62:34
a=setup:actpass
a=rtcp-mux

Format de réponse contenant SDES en SBC

m=audio 54056 RTP/SAVP 111 103 104 9 0 8 description 106 13 110 112 113 126
a=rtcp:54056
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:fBc61ikv1kMy0sF85DblNqTzVAbFa7hJQ9GKb6Yj|2^31|1:1
a=crypto:3 AES_CM_128_HMAC_SHA1_80 inline:O1qT9tWbs/NwJVwhfrgF5tCrbNOxnVDqkIqTx4rz|2^31
a=rtcp-mux

Format de l’offre de Teams vers SBC

Format de l’offre SDES uniquement pour SBC

m=audio 52884 RTP/SAVP 111 103 104 9 0 8 106 13 110 112 113 126
a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:Hr4D2cgUu9+Uza5Igz/JkVx59DAxDbaxJg862ibQ|2^31
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:JPEaIxHegfuv53ykBPZk8hV0GO8kTiiqRMfHimEE|2^31
a=rtcp:52884
a=rtcp-mux