Virtual Room combine la visioconférence WebRTC, la co-navigation et la collaboration en direct avec des documents 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 standard. Pour garantir une expérience client plus fluide, consultez 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 (ÉTOURDISSEMENT/TOUR) + UDP 1025–65535 (SRTP, préférence) ; solution de secours TURN over 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 de longue durée — que les proxies doivent traverser sans mise en mémoire tampon.
Rangée 3 Wildcards Vonage : Vonage ne fournit pas de liste FQDN complète, donc des règles de joker sont obligatoires. Les comptes sur l’environnement unifié de Vonage ont également besoin de *.vonage.com. Pour plus de détails, consultez l’article sur le pare-feu et les ports Vonage. Les clients qui ont besoin d’une liste d’autorisation basée sur IP plutôt que 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 charge partiellement — les filtres URL-mots-clés bloquent souvent la série 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 multimédias Vonage ; Il n’y a pas de trafic direct entre les participants. Les quatre protocoles impliqués sont WSS (signalisation), REST/HTTPS (configuration et journalisation), SRTP (audio/vidéo) et STUN/TURN (NAVIGATION 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 installation plus lente et une qualité inférieure ; 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 en cas de 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) à *.opentok.com, *.tokbox.com ou *.upscope.io. Cela casse les mises à jour WebSocket et TURN-over-TLS. Ajoutez ces domaines à la liste des contournements d’inspection.
Ne désactivez pas WebRTC via la politique de groupe du navigateur. Des paramètres tels que WebRtcUdpPortRange réglé à 0–0, ou des extensions bloquant WebRTC à l’échelle de la flotte, casseront 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 | Échec de jonction vidéo ; la navigation conjointe échoue ; 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 tampon les réponses en streaming. Les antivirus ou proxies DLP qui conservent les réponses pour le scan bloquent 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 permettre des sessions de 30 à 90 minutes. Les proxys avec des temps d’attente courts (par exemple, 60 secondes ou un plafond dur de 5 minutes) provoquent des chutes 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 les WebSockets. Exempter les domaines de la section 1 si des chutes 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 les proxys d’authentification. 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 la trajectoire de secours TCP plus lente. 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 Chromium offrent les résultats WebRTC les plus cohérents sur les versions d’entreprise.
L’accès aux caméras et aux microphones doit être autorisé aux trois niveaux inférieurs. La politique d’entreprise peut bloquer n’importe laquelle d’entre elles 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 le site par site ... Variantes 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 passthrough fiable de caméra et de microphone et ajoutent une latence d’encodage. Les points d’extrémité 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... » 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 à jour 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 signalent « 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 sur 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 contre le domaine OneSpan Sign ou *.media.prod.tokbox.com).
[ ] *0,upscope.io (y compris assets-proxy.upscope.io) et cobrowsingapi.com sont joignables et exclus de l’inspection TLS.
[ ] *.opentok.com et *tokbox.com jokers ; UDP 3478 ouvert, ou TURN over TCP 443 confirmé que fonctionne.
[ ] Le proxy ne tampon pas les réponses texte/flux d’événements ; Le temps d’arrêt ≥ 4 heures pour les domaines de la section 1.
[ ] Le VPN transmet le trafic WebSocket sur le port 443 ; tunnel 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 (signature par carte à puce ou 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 Virtual Room et RON, mais il est listé ici car il apparaît dans la même politique de sécurité de l’application et peut être mentionné dans la même revue informatique.