Dépannage des appels WebRTC sur les périphériques RoomOS Webex

Introduction

Ce document décrit le dépannage WebRTC sur RoomOS, couvrant l'architecture, les diagnostics, la collecte de journaux et les techniques de corrélation SSRC.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Architecture de Cisco RoomOS et structure de navigateur WebEngine.
• Administration des périphériques, profils de configuration et analyses de dépannage du Cisco Webex Control Hub.
• Analyse de capture de paquets réseau à l’aide de Wireshark pour inspecter les flux SSRC et les formats de données utiles.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Gamme de salles Cisco (Room Bar, Room Kit, Room Kit Pro, Room Kit EQ) exécutant RoomOS 26.x ou version ultérieure
• Gamme Cisco Board (Board Pro 55/75, Board Pro G2) exécutant RoomOS 26.x
• Gamme de bureau Cisco (Desktop Pro, Desktop Mini)
• Concentrateur de contrôle Cisco Webex
• Services de collaboration WebRTC : Microsoft Teams Direct Guest Join (DGJ), Google Meet, Zoom WebRTC et Webex Instant Connect

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Qu'est-ce que WebRTC ?

WebRTC (Web Real-Time Communication) est une norme open source intégrée aux navigateurs Web modernes. Il permet la diffusion vidéo, audio et de données en temps réel entre les terminaux sans avoir recours à des plug-ins propriétaires.

• API JavaScript : Fournit des API normalisées (telles que getUserMedia, RTCPeerConnection et RTCDataChannel) qui interagissent directement avec le matériel audio/vidéo.
• Prise en charge des codecs natifs : Encapsule des codecs audio et vidéo haute définition modernes, notamment Opus, G.711, VP8, VP9 et H.264.
• Dépendance de plug-in nulle : Élimine le besoin de modules complémentaires, d'exécutables de bureau téléchargeables ou de privilèges d'installation administrative.

Fonctionnement de WebRTC sur Cisco RoomOS (WebEngine)

Sur les périphériques de collaboration vidéo Cisco exécutant RoomOS, les applications WebRTC ne s'exécutent pas en tant qu'applications de microprogramme C/C++ compilées natives. Au lieu de cela, ils s'exécutent dans l'environnement de navigateur WebEngine intégré, qui est basé sur un coeur en chrome hautes performances optimisé pour le matériel de traitement vidéo Cisco.

Configurer 

Pour activer des fonctionnalités de diagnostic complètes pour les sessions WebRTC et WebEngine sur les périphériques Cisco RoomOS, les administrateurs doivent activer le débogage à distance dans Cisco Webex Control Hub ou via l'interface xAPI du périphérique.

Étape 1: Activer le débogage à distance WebEngine dans Cisco Collaboration Control Hub

1. Connectez-vous à Cisco Webex Control Hub.
2. Accédez à Management > Devices et sélectionnez le point d'extrémité vidéo cible.
3. Cliquez sur All Configurations dans le panneau de droite.
4. Recherchez WebEngine et recherchez le paramètre RemoteDebugging.
5. Définissez WebEngine RemoteDebugging sur On et cliquez sur Save.

Vous pouvez également activer le débogage à distance directement via l'interface de ligne de commande (CLI) du périphérique :

xConfiguration WebEngine RemoteDebugging: On
xConfiguration WebEngine Features WebRTC: On

Étape 2: Vérifier

Utilisez cette section pour confirmer que WebEngine est correctement initialisé et qu'il traite activement les canaux multimédias WebRTC pendant un appel.

Exécutez les commandes xStatus via le terminal pendant qu'une téléconférence WebRTC est en cours :

xStatus WebEngine
xStatus WebRTC MediaChannels

Tableau 1 : Décrit les champs opérationnels clés renvoyés par la commande d'état WebRTC :

Paramètre xStatus	État attendu	Description et impact diagnostique
État WebEngine	Marche	Indique si le coeur du navigateur Chrome est actif et en cours de rendu.
Client MediaChannels WebRTC	Actif/Connecté	Indique le transport multimédia actif entre le codec et le pont multimédia cloud.
Direction	Sortant / Entrant	Indique si le canal multimédia représente la transmission caméra/micro locale ou la réception vidéo à distance.
DébitCible	1500000 bits/s (1,5 Mbits/s)	Bande passante cible allouée par WebEngine en fonction de la capacité réseau disponible.

Dépannage

Cette section fournit des procédures de dépannage détaillées, des instructions de collecte de journaux et des techniques de corrélation de flux de support SSRC pour les problèmes WebRTC.

1. Collecte des journaux à partir de WebEngine et de l'interface tactile

Lorsqu'un problème de qualité ou de connexion se produit pendant un appel WebRTC actif, exécutez la procédure directement à partir du panneau Cisco Room Navigator / Touch 10. Pendant la téléconférence WebRTC active, effleurez le menu de contrôle du périphérique et sélectionnez Paramètres.

1. Accédez à Problèmes et diagnostics.
2. Activez Extended Logging. (La journalisation étendue enregistre les horodatages de paquets haute résolution, les rapports RTCP de l'expéditeur/récepteur et les statistiques de flux multimédia).
3. Immédiatement après la reproduction du problème audio/vidéo, sélectionnez Send WebRTC Logs (Envoyer les journaux WebRTC).

Une fois les journaux téléchargés sur le cloud Cisco, l'interface génère deux identificateurs de suivi uniques :

• ID WebRTC : Cet identificateur est formaté spécifiquement pour les fournisseurs de services de conférence tiers (par exemple, Microsoft Support for Teams Direct Guest Join ou Google Cloud Support for Google Meet). Fournissez cet ID lors de l'ouverture d'un dossier d'assistance auprès du fournisseur d'hébergement.

• ID de journal/ID de commentaire : Cet identifiant est indexé dans le Cisco Webex Control Hub. Les ingénieurs du TAC Cisco utilisent cet ID de journal pour localiser, déchiffrer et analyser l'ensemble complet de diagnostics du système d'extrémité.

ID du journal : L'ID de journal peut être utilisé pour rechercher les journaux et les télécharger à des fins de dépannage ou pour ouvrir un dossier auprès du TAC. Les journaux peuvent être téléchargés directement sur le Collaboration Control Hub et peuvent être collectés à l'aide de l'ID de journal/ID de commentaire ou de l'ID de téléconférence dans la section de dépannage.

 

2. Mappage des flux de médias et identification SSRC (corrélation xStatus)

Dans les architectures RTP (Real-Time Transport Protocol) et WebRTC, une source de synchronisation (SSRC) est un identificateur numérique 32 bits critique qui marque l'origine d'un flux multimédia. Les récepteurs utilisent le SSRC pour séquencer les paquets, calculer la gigue et synchroniser l'audio avec la vidéo.

Pour mapper un flux vidéo ou audio spécifique entre les journaux xStatus du périphérique et une capture de paquets Wireshark, convertissez l'ID de canal décimal de xstatus.txt en son équivalent hexadécimal :

(416917557)10  =  (0x18D9A835)16

Wireshark Display Filter: rtp.ssrc== 0x18D9A835

L'extrait de journal illustre un canal vidéo sortant WebRTC en direct extrait d'un fichier de diagnostic xstatus.txt du point d'extrémité :

*s WebRTC MediaChannels Client Channel 7 Direction: Incoming
*s WebRTC MediaChannels Client Channel 7 Id: "IT01V416917557"
*s WebRTC MediaChannels Client Channel 7 Netstat BytesSent: 89661904
*s WebRTC MediaChannels Client Channel 7 Netstat PacketsSent: 84431
*s WebRTC MediaChannels Client Channel 7 QualityLimitation NetworkBandwidthLimited: 50
*s WebRTC MediaChannels Client Channel 7 QualityLimitation NotLimited: 497
*s WebRTC MediaChannels Client Channel 7 TargetBitrate: 1500000
*s WebRTC MediaChannels Client Channel 7 Transport RTCP Local IpAddress: "<Local IP Address>"
*s WebRTC MediaChannels Client Channel 7 Transport RTCP Local Port: 1742
*s WebRTC MediaChannels Client Channel 7 Transport RTCP Local Protocol: UDP
*s WebRTC MediaChannels Client Channel 7 Transport RTCP Remote IpAddress: "<Server IP Address>"
*s WebRTC MediaChannels Client Channel 7 Transport RTCP Remote Port: 3478
*s WebRTC MediaChannels Client Channel 7 Transport RTCP Remote Protocol: UDP
*s WebRTC MediaChannels Client Channel 7 Type: Video
*s WebRTC MediaChannels Client Channel 7 Video EncoderImplementation: "ExternalEncoder"
*s WebRTC MediaChannels Client Channel 7 Video FrameHeight: 540
*s WebRTC MediaChannels Client Channel 7 Video FrameWidth: 960
*s WebRTC MediaChannels Client Channel 7 Video FramesPerSecond: 30
*s WebRTC MediaChannels Client Channel 7 Video Protocol: "video/VP8"

Principales conclusions de diagnostic de cette analyse de canal média :

• Corrélation SSRC : Le suffixe d'ID de canal « 416917557 » représente SSRC 0x18D9A835. Le filtrage Wireshark pour ce SSRC isole tous les paquets vidéo sortants.
• Transport et relais : Le terminal local (<Local IP Address>) communique directement avec un serveur STUN/TURN Google distant (Public IP Server Address sur le port UDP 3478).
• Résolution et codec : Le flux est codé activement à l'aide de la technologie VP8 à accélération matérielle avec une résolution de 960 x 540 à 30 images par seconde.
• Compteur de limitation de qualité : Le compteur QualityLimitation NetworkBandwidthLimited de 50 indique que l'algorithme de contrôle d'encombrement WebEngine a réduit la résolution en raison de contraintes de bande passante en amont transitoires.

3. Dépannage avancé du Cisco Webex Control Hub

Les administrateurs peuvent analyser les mesures de réunion WebRTC en direct et historiques directement dans Cisco Webex Control Hub :

1. Accédez à Control Hub > Troubleshooting > Meetings & Calls.
2. Filtrez par l'adresse MAC, le numéro de série, le nom du périphérique ou l'ID de journal du point d'extrémité.

    

    
3. Sélectionnez la session de téléconférence cible dans les résultats de recherche chronologiques.
4. Examinez les graphiques de télémétrie saut par saut en temps réel : Perte de paquets (audio/vidéo), tampon d'instabilité, latence (RTT) et mise à l'échelle de la résolution dynamique.

 

 

Tableau 2 : Modes de défaillance WebRTC courants et matrice de correction

Symptôme	Cause racine probable	Vérification de diagnostic	Étape de correction
L'appel ne parvient pas à joindre / tourne en permanence	Pare-feu bloquant les ports UDP STUN/TURN sortants (3478, 5004-65535)	Wireshark affiche des demandes de liaison STUN répétées sans réponses de liaison	Ouvrez les ports UDP sortants sur les plages IP des supports du fournisseur WebRTC.
Gel audio/vidéo unidirectionnel	Délai NAT ou UDP symétrique sur le pare-feu dynamique d'entreprise	xStatus affiche QualityLimitation NetworkBandwidthLimited s'incrémentant rapidement	Configurez le délai d'attente d'état UDP du pare-feu >= 60 secondes ; activer les keepalives STUN.
Écran noir ou blocage sur USB-C BYOM	Échec de négociation du mode alternatif DisplayPort sur un câble non certifié	messages.log affiche le délai de négociation de l'alimentation USB du noyau	Utilisez un câble de type C 10 Gbit/s certifié USB-IF ; définissez le paramètre Video Output Connector MonitorRole sur Auto.

Informations connexes

• Guide de référence des commandes Cisco RoomOS (configuration xAPI et WebEngine)
• Gestion des périphériques sur le Cisco Collaboration Hub
• Référence API Webrtc
• Meilleures pratiques pour WebEngine

Historique de révision

Révision	Date de publication	Commentaires
1.0	20-Oct-2026	Première publication