Utilisez notre outil de vérification du réseau Virtual Room / RON pour vérifier rapidement votre navigateur afin de voir les configurations détaillées dans cet article.
Virtual Room combine la visioconférence WebRTC, la co-navigation et la collaboration en temps réel dans un navigateur. Parce qu’il repose sur des connexions persistantes et des médias en temps réel, il est plus sensible aux réseaux d’entreprise restrictifs que la signature électronique classique. Pour garantir une expérience client plus fluide, examinez les exigences ci-dessous avant que les hôtes ou participants ne rejoignent depuis un réseau d’entreprise ou un VPN.
Toutes les exigences suivantes sont susceptibles d’être modifiées.
Liste des autorisations du pare-feu et des proxy
Toutes les connexions sont sortantes depuis le navigateur du participant. Aucune règle d’entrée n’est nécessaire.
Pour utiliser OneSpan Notary, vous devez mettre en liste blanche les URL suivantes :
Pour plus d’informations sur ces URL, voir le tableau ci-dessous.
# | Destination | Protocole / Port | Objectif | Obligatoire |
|---|---|---|---|---|
1 | Votre domaine OneSpan Sign — le domaine dans l’URL de signature ou de transaction (par exemple apps.esignlive.com ; varie selon la région et le compte) | HTTPS + WSS, TCP 443 | Cérémonie de signature UI, API | Toujours |
2 | Même domaine que la ligne 1, chemin /virtual-room/* | HTTPS + Événements envoyés par le serveur, TCP 443 | Salle virtuelle : état de la salle, événements de rejoint/départ, sous-titres en direct | Toujours (VR) |
3 | *.opentok.com et *.tokbox.com (jokers requis — Vonage ne publie pas de liste FQDN fixe) | HTTPS + WSS, TCP 443 | Vidéo Vonage : mise en place de session, signalisation en appel, télémétrie, solution de secours média-over-WebSocket | Toujours (VR) |
4 | Serveurs multimédias Vonage | UDP 3478 (ÉTOURDIR/TOURNER) + UDP 1025–65535 (SRTP, préféré) ; rechange TURN sur TCP/TLS 443 | Médias audio et vidéo — voir la section 2 pour les options de port à plusieurs niveaux | Toujours (VR) |
5 | *.upscope.io (voir la note ci-dessous si les jokers ne sont pas pris en charge) | HTTPS + WSS, TCP 443 | Co-navigation Upscope et vue partagée de documents | Toujours (VR) |
6 | cobrowsingapi.com | HTTPS, TCP 443 | Visualiseur de co-navigation (iframe) | Toujours (VR) |
La ligne 2 n’est pas une règle de pare-feu distincte. Le service de salle virtuelle fonctionne sur le même domaine OneSpan Sign et le même port que la ligne 1. Il est listé séparément car il utilise des événements envoyés par serveur — une réponse de streaming longue durée — que les proxies doivent traverser sans mise en mémoire tampon.
Ligne 3 Wildcards Vonage : Vonage ne fournit pas une liste FQDN complète, donc des règles de joker sont requises. Les comptes sur l’environnement unifié de Vonage doivent également *.vonage.com. Pour plus de détails, voir l’article pare-feu et ports de Vonage. Les clients qui ont besoin d’une liste d’autorisation basée sur IP au lieu de domaines doivent demander l’extension « IP autorisées » de l’environnement d’entreprise auprès de Vonage — contactez notre Support Team pour le signaler.
Hôtes explicites Upscope de la rangée 5 : Si *.upscope.io n’est pas possible, autorisez ces hôtes individuellement : js.upscope.io, code.upscope.io, assets-proxy.upscope.io, application cdn.upscope.io, api.upscope.io, data.upscope.io, et les points de terminaison régionaux data--us-east.upscope.io, data--us-west.upscope.io, data--eu-west.upscope.io, data--eu-central.upscope.io, data--sa-east.upscope.io, data--ap-southeast.upscope.io. Commencez par assets-proxy.upscope.io si la navigation conjointe se charge partiellement — les filtres de mots-clés URL bloquent souvent la vidéo car le nom d’hôte contient « proxy ».
Si la ligne 1 est limitée à des chemins d’URL spécifiques, incluez /virtual-room/*, /graphql et /transaction/* en plus des pages de signature.
WebRTC et transport des médias
Virtual Room utilise Vonage Video en mode média routé — tous les flux passent par des serveurs médias Vonage ; il n’y a pas de trafic direct pair-à-pair entre les participants. Les quatre protocoles impliqués sont WSS (signalisation), REST/HTTPS (configuration et journalisation), SRTP (audio/vidéo) et STUN/TURN (DÉPLACEMENT NAT). Toutes les connexions sont sortantes. Aucune règle d’entrée ni redirection de port n’est requise.
Vonage définit trois niveaux de configuration de pare-feu :
Niveau | Ports à ouvrir (sortant) | Résultat |
|---|---|---|
Optimal | UDP 3478 (ÉTOURDISSEMENT/VIRAGE) + UDP 1025–65535 (ICE/SRTP) + TCP 443 | Installation la plus rapide, meilleure qualité |
Minimum recommandé | UDP 3478 (ÉTOURDISSEMENT/TOUR) + TCP 443 | Bonne qualité — les médias utilisent toujours UDP via TURN |
Minimum absolu | TCP 443 uniquement (WSS, HTTPS, TURN OVER TLS) | Fonctionnel, mais une configuration plus lente et de moindre qualité ; sensible à la perte de paquets |
Si TCP 443 vers les domaines Vonage est également bloqué ou soumis à une interception TLS, la vidéo échoue complètement avec des erreurs « impossible de se connecter au média ».
Recommandations pour votre service informatique :
Ouvrez au moins UDP 3478 (le minimum recommandé). Le TCP-443 uniquement est un dernier recours — la retransmission TCP dégrade les médias en temps réel et la qualité chute sur tout réseau avec perte de paquets.
Le client Vonage essaie toujours UDP en premier, même si UDP est bloqué. Les tentatives UDP dans une trace réseau sont attendues et ne sont pas des erreurs.
N’appliquez pas l’inspection TLS (déchiffrement MITM) sur *.opentok.com, *.tokbox.com ou *.upscope.io. Cela casse les mises à jour WebSocket et le TURN-over-TLS. Ajoutez ces domaines à la liste de contournement des inspections.
Ne désactivez pas WebRTC via la politique de groupe du navigateur. Des paramètres comme WebRtcUdpPortRange réglés sur 0–0, ou des extensions bloquant WebRTC à l’échelle de la flotte, briseront silencieusement la vidéo de la Salle Virtuelle.
WebSocket et connexions en streaming (proxy / VPN)
Virtual Room nécessite trois types de connexions persistantes. Les proxies et VPN ne doivent pas les interrompre :
Type de connexion | Extrémité | Qu’est-ce qui casse si on est interrompu |
|---|---|---|
WebSocket (WSS) | Signalisation Vonage (*.media.prod.tokbox.com), Upscope, abonnements GraphQL sur le domaine OneSpan Sign | échecs de jonction vidéo ; échecs de co-navigation ; l’état du document cesse de se mettre à jour |
Événements envoyés par le serveur (flux HTTP persistant) | /virtual-room/{id}/event sur le domaine OneSpan Sign, port 443 | Les participants cessent de recevoir des événements de la salle : rejoins, statut d’enregistrement, légendes, statut de vérification, expiration de la session |
Médias WebRTC | Serveurs multimédias Vonage | Gel ou déconnexion vidéo et audio |
Exigences relatives au proxy :
Doit supporter la mise à jour : websocket handshake (HTTP/1.1) sur le port 443.
Il ne faut pas mettre en mémoire tampon les réponses en streaming. Les antivirus ou proxies DLP qui retiennent les réponses pour le balayage interrompent les événements envoyés par le serveur — le client semble connecté mais ne reçoit aucun événement.
Les délais de connexion doivent prendre en charge des sessions de 30 à 90 minutes. Les proxies avec des délais d’arrêt courts (par exemple, 60 secondes ou un plafond dur de 5 minutes) provoquent des coupures répétées. Fixez un délai d’attente de ≥ 4 heures — ou pas de plafond — pour les domaines de la section 1.
La réauthentification NTLM/Kerberos en cours de connexion peut supprimer des WebSockets. Exempter les domaines de la section 1 si des coupures sont observées.
Le proxy doit être transparent ou explicitement configuré dans le navigateur ou le système d’exploitation. Les SDK Vonage ne prennent pas en charge les fichiers PAC, et les SDK natifs (hors navigateur) ne prennent pas en charge l’authentification des proxys. Pour les environnements très restreints, Vonage propose un proxy IP auto-hébergé et des modules complémentaires TURN configurables — contactez notre Support Team ou la gestion des comptes Vonage.
Exigences en VPN :
Il faut passer les connexions WebSocket du port 443 au domaine OneSpan Sign et à tous les domaines de la section 1.
Les VPN à tunnel complet ajoutent de la latence et poussent souvent les médias vers le chemin de secours TCP plus lent. Le split tunneling pour *tokbox.com et *opentok.com est fortement recommandé.
Bande passante et performances
Minimum recommandé : 3 Mbps de téléchargement et de téléchargement par participant (couvre la vidéo, l’audio, la navigation conjointe et la synchronisation des documents).
Par flux vidéo : environ 300 kbps en basse qualité, jusqu’à 1,5+ Mbps en HD — dans chaque direction. Les sessions avec plusieurs participants devant la caméra nécessitent plus de bande passante en aval.
La latence aller-retour vers la région OneSpan Sign devrait être inférieure à 150 ms. Le virage VPN via une passerelle régionale distante dégrade à la fois la vidéo et la co-navigation.
Une perte de paquets supérieure à 3 % dégrade la qualité du WebRTC, quelle que soit la bande passante.
Exigences du point de terminaison et du navigateur
Utilisez une version actuelle de Chrome, Edge, Firefox ou Safari. Les navigateurs basés sur Chrome offrent les résultats WebRTC les plus cohérents sur les versions d’entreprise.
L’accès par caméra et microphone doit être autorisé aux trois niveaux ci-dessous. La politique d’entreprise peut bloquer n’importe lequel d’entre eux indépendamment :
Paramètres de confidentialité du système d’exploitation (confidentialité de la caméra/microphone Windows ; autorisations TCC de macOS).
Politique de groupe du navigateur : VideoCaptureAllowed, AudioCaptureAllowed, et les variantes par site ... AllowedUrls sur Chrome ou Edge gérés.
L’invite par navigateur par site — les utilisateurs doivent pouvoir cliquer sur Permettre.
Les extensions de navigateur à l’échelle de la flotte qui bloquent WebRTC, scripts ou trames tierces (confidentialité ou bloqueurs de publicité) peuvent casser la co-navigation vidéo et Upscope.
Les machines virtuelles et les clients légers (Citrix, VDI) manquent souvent de passage fiable de caméra et de microphone et ajoutent une latence d’encodage. Les points de terminaison physiques sont recommandés pour les hôtes et les notaires.
Dépannage
Symptôme | Cause probable |
|---|---|
La cérémonie de signature se charge mais la salle virtuelle ne se termine jamais de charger | /virtual-room/* bloqué par un proxy de filtrage de chemin, ou flux SSE bloqué ou tampon |
Les participants rejoignent mais ne voient pas les changements d’état (adhésions, bannière d’enregistrement, statut de vérification) | Buffering ou terminaison du flux SSE par proxy (/virtual-room/{id}/event) |
« Connexion à la vidéo... » se bloque ou échoue immédiatement | Les domaines Vonage bloquaient (config.opentok.com, anvil.opentok.com, *media.prod.tokbox.com) ou l’inspection TLS interrompait la mise à niveau WebSocket |
La vidéo se connecte, puis les tuiles deviennent noires ou figées, ou seulement le son | Le support UDP bloqué et le plan de secours TCP/TLS 443 également bloqué ou inspecté |
La vidéo fonctionne mais la qualité est mauvaise ou chute à plusieurs reprises | UDP bloqué (médias fonctionnant via le secours TCP), VPN en tunnel complet ou délais d’attente proxy |
Les sous-titres en direct n’apparaissent jamais | Le flux SSE bloqué ou mis en mémoire tampon (les sous-titres utilisent le même canal d’événements que les autres événements de salle) |
La navigation partagée est vide ou ne synchronise pas | *upscope.io ou cobrowsingapi.com bloqué, ou WSS vers Upscope bloqué |
La navigation conjointe se charge partiellement (styles ou images manquants) | assets-proxy.upscope.io bloqué — les filtres de mots-clés URL marquent « proxy » dans le nom d’hôte |
Travaille à la maison, échoue au bureau | Restriction de proxy ou de pare-feu — vérifiez d’abord le support WebSocket, le tampon SSE et l’inspection TLS |
Si une panne est suspectée plutôt qu’un blocage réseau, consultez la page de statut correspondante :
Statut Vonage : https://vonageapi.statuspage.io/
Upscope : https://status.upscope.io/
Liste de contrôle de validation avant session
Effectuez ces vérifications depuis l’intérieur du réseau d’entreprise avant la première session en direct.
[ ] Domaine OneSpan Sign accessible via le port 443, y compris le chemin de la salle virtuelle — par exemple, curl -s -o /dev/null -w ' %{http_code}' https://<your-domain>/virtual-room/probe/existence renvoie tout code d’état HTTP.
[ ] La mise à jour WebSocket réussit via le proxy du port 443 (tester avec le domaine OneSpan Sign ou *media.prod.tokbox.com).
[ ] *.upscope.io (y compris assets-proxy.upscope.io) et cobrowsingapi.com sont joignables et exclus de l’inspection TLS.
[ ] *.opentok.com et *tokbox.com accessibles via les jokers ; UDP 3478 ouvert, ou TURN over TCP 443 confirmé fonctionnel.
[ ] Le proxy ne met pas en mémoire tampon les réponses texte/flux d’événements ; le délai d’attente ≥ 4 heures pour les domaines de la section 1.
[ ] VPN transmet le trafic WebSocket sur le port 443 ; tunneling divisé configuré pour *tokbox.com et *.opentok.com lorsque possible.
[ ] La politique de navigateur géré permet l’accès à la caméra et au microphone pour le domaine OneSpan Sign.
[ ] Au moins 3 Mbps en upload et en téléchargement par participant confirmés par le réseau d’entreprise.
[ ] Session de test terminée avec un animateur et un participant avant la vraie session.
Pour obtenir de l’aide afin de valider la configuration de votre réseau, contactez notre Support Team.
Signature basée sur des certificats
Si le compte utilise le Client de Certificat Personnel (carte à puce ou signature de certificat), le navigateur ouvre également des connexions WSS vers *esignlive.com sur les ports agents locaux 26666, 31222, 32444, 44555, 47777, 48888. C’est distinct de la Salle Virtuelle et du RON, mais il est listé ici car il apparaît dans la même politique de sécurité applicative et peut être mentionné dans la même revue informatique.