Grundläggande begrepp
Detta avsnitt ger en översikt över Zoom Workplace VDI appens kärnkoncept.
Optimeringslägen för insticksprogram
Zoom Workplace VDI-appen stöder tre driftlägen för mediebearbetning i realtid: direktoptimerat, kanaloptimerat och reservläge
I samband med Zoom Workplace VDI-appen avser mediebearbetning i realtid vidarebefordran och rendering av medier i realtid mellan Zoom-moln, Zoom Workplace VDI-appen och/eller insticksprogrammet. För att stödja en rad VDI-användningsfall stöder Zoom Workplace VDI-appen tre distinkta driftlägen för mediebearbetning och optimering: direktoptimerat läge, kanaloptimerat läge och reservläge. Dessa diskuteras i följande avsnitt.
Direktoptimerat läge: När Zoom Workplace VDI-appen och insticksprogrammet tar emot oberoende dataströmmar från Zoom-moln
Direktoptimerat läge är standardoptimeringsläget för Zoom Workplace VDI-appen och insticksprogrammet. I det här läget upprätthåller Zoom-moln två separata dataströmmar för en optimerad VDI-användare: en för Zoom Workplace VDI-appen och en annan för insticksprogrammet. Denna konfiguration gör det möjligt för användarens fjärrklient (utrustad med VDI-insticksprogrammet) att kommunicera direkt med Zoom-moln för dataöverföringar av medier i realtid, vilket eliminerar behovet av att dirigera det mesta av trafiken för medier i realtid genom det virtuella skrivbordet eller över den virtuella kanalen.
När direktoptimerat läge används inträffar följande:
Insticksprogrammet tar emot dataströmmar för video och ljud direkt från molnet.
Zoom Workplace VDI-appen hanterar allmän mötesdata, såsom deltagarinformation, chattmeddelande eller AI Companion-funktioner, och visar detta i platshållaren för Workplace-appen, samtidigt som den hanterar inkommande skärmdelning genom att vidarebefordra den till insticksprogrammet och ladda upp lokalt skärmdelningsinnehåll från det virtuella skrivbordet när det är aktivt.
Insticksprogrammet och VDI-skrivbordet använder VDI-leverantörens virtuella anslutning för att kommunicera och fastställa placering och rendering av media på skärmen mellan de två lagren.
Kanaloptimerat läge: När insticksprogrammet tar emot data som hårnålskopplas genom det virtuella skrivbordet
Kanaloptimering liknar upplevelsen med direktoptimering, där insticksprogrammet fortsätter att rendera mötesmediet (som visas i bilden ovan), men via en annan nätverksväg. I det här läget inträffar följande:
Allt mötesmedia levereras först till VDI-servern från Zoom-moln.
VDI-servern överför media till insticksprogrammet antingen genom en out-of-band-UDP-anslutning eller genom den befintliga virtuella VDI-kanalen om UDP-anslutningen inte kan upprättas.
Denna metod kan föredras av organisationer som inte aktiverar direkt internetåtkomst för tunna klienter (eller andra fjärrenheter), eller som föredrar att dirigera data genom sitt nätverk, men kan potentiellt leda till en sämre upplevelse än direktoptimering om villkoren för nätverksdirigering är suboptimala. Bilden nedan visar dataflödet för UDP-/kanaloptimering.
Reservläge: När allt mötesmedia dirigeras till och bearbetas direkt på det virtuella skrivbordet
Reservläge representerar en helt ooptimerad VDI-upplevelse. I det här läget används ingen mediaoptimering eller något insticksprogram, och all kommunikation sker direkt mellan VDI-servern och Zoom-moln, med all bearbetning uteslutande på VDI-servern.
Denna metod lägger en betydande bearbetningsbörda på VDI-serverresurser, vilket ofta leder till dålig prestanda, inklusive tröghet, hackig video och förvrängt ljud. Därför är reservläge det minst önskvärda alternativet och bör endast användas som en sista utväg eller när insticksprogram inte är tillgängliga.
Varning
Reservläge bör undvikas när det är möjligt för att upprätthålla serverprestanda.
Sammanfattning av anslutningslägen
Zoom Workplace VDI-appen stöder tre distinkta anslutningslägen, vart och ett anpassat till olika operativa behov och säkerhetsbehov. Standardläget och det mest effektiva läget är direktoptimerat läge, där Zoom Workplace VDI-appen och insticksprogrammet upprättar separata anslutningar till Zoom-moln och självständigt hanterar sina respektive delar av ett Zoom-möte för att leverera en sömlös, optimerad upplevelse.
Utöver direktoptimerat läge kan Zoom Workplace VDI-appen köras i alternativa konfigurationer, inklusive kanaloptimerat läge och reservläge. Dessa lägen kan hjälpa till att hantera specifika begränsningar i arbetsflöde eller nätverk, såsom begränsad internetåtkomst för fjärrenheter, datadirigering av integritetsskäl eller avsaknad av insticksprogram.
Följande tabell sammanfattar de viktigaste skillnaderna mellan dessa lägen.
Avlastning av media
Direkt molnåtkomst från insticksprogram
Direktoptimerat
✔
✔
Kanaloptimerat
✔
Reservläge
WebRTC-medieavlastning
Översikt
Zoom tillhandahåller en webbläsarbaserad WebRTC-klient via Zoom Web App som kan avlasta ljudbearbetning till användarens lokala enhet när den körs i en virtuell skrivbordsmiljö. Detta fungerar utan att kräva några Zoom-specifika insticksprogram eftersom VDI-plattformen tillhandahåller sin egen lokala WebRTC-motor och ett omdirigeringsramverk som bygger en brygga mellan Zoom Web App och den motorn.
Varning
WebRTC-medieavlastning är för närvarande begränsad till ljud och stöder inte videooptimering.
Denna funktion stöder följande produkter och kanaler från Zoom Web App:
Zoom Phone
Zoom kontaktcenter
Zoom kontaktcenter CTI-anslutningsprogram
Denna funktion stöds för närvarande av följande virtuella skrivbordsplattformar:
Citrix
Omnissa Horizon
Se Zooms supportcenter för mer information om konfigurera Zoom VDI för att stödja WebRTC-omdirigering för Zoom Web App.
Zoom Web App avlastar VDI WebRTC-ljud till den lokala enheten
När Zoom Web App i det virtuella skrivbordet försöker initiera WebRTC-ljud, fångas dess begäranden upp innan det virtuella skrivbordet försöker fånga eller bearbeta ljud. I stället för att aktivera webbläsarens inbyggda WebRTC-mediestack i den värdbaserade sessionen översätter VDI-plattformen den ljudrelaterade signaleringen till lättviktiga kontrollmeddelanden. Dessa meddelanden skickas genom VDI-leverantörens virtuella kanal till användarens lokala dator, vilket omdirigerar ljudtrafik i realtid från Zoom-moln direkt till användarens lokala dator.
På den lokala datorn tar den inbyggda WebRTC-motorn som ingår i VDI-klienten (t.ex. Citrix, Omnissa Horizon) emot dessa meddelanden och blir ansvarig för all ljudinspelning, kodning, avkodning och uppspelning. Motorn använder det lokala systemets mikrofon, högtalare och bearbetningsresurser, vilket bidrar till att säkerställa att ljud inte flödar genom den virtuella skrivbordsservern.
Följande diagram visar hur data dirigeras vid användning av WebRTC-medieavlastning med Zoom Web App och en virtuell agent som stöds.
Interaktion mellan Zoom Web App och den lokala datorn
Ur Zoom Web Apps perspektiv liknar upplevelsen fortfarande en standard-WebRTC-session. Signalering mellan Zoom Web App och Zooms backend vidarebefordras genom det virtuella skrivbordet, och den lokala WebRTC-motorn speglar de förhandlade sessionsparametrarna. Det virtuella skrivbordets applikation fortsätter att presentera Zoom-gränssnittet – kontroller, mötesstatus och indikatorer – medan det faktiska ljudet i realtid genereras och används av den lokala datorn.
Eftersom endast signaleringsmeddelanden passerar den virtuella kanalen är bandbreddsoverheaden låg och konsekvent, även i fleranvändarmiljöer.
Varför inget insticksprogram krävs
Den viktigaste möjliggöraren är att VDI-klienten (t.ex. Citrix, Omnissa Horizon) redan innehåller en fullständig WebRTC-mediamotor som kan hantera ljud i realtid. Eftersom omdirigeringslagret får denna motor att framstå för Zoom Web App som dess underliggande WebRTC-implementering behöver Zoom inte tillhandahålla och underhålla ett separat insticksprogram. Omdirigeringslogiken mappar WebRTC-API-anrop, enhetsåtkomst och sessionsförhandling från webbläsaren i det virtuella skrivbordet till den inbyggda motorn på den lokala datorn.
Resultat
Detta tillvägagångssätt gör att Zooms webbläsarbaserade WebRTC-upplevelse kan fungera effektivt i VDI-miljöer med full ljudoptimering. Gränssnittet körs i det virtuella skrivbordet, men ljud i realtid spelas in och bearbetas lokalt, vilket ger användare en responsiv och skalbar konferensupplevelse utan att kräva ytterligare Zoom-programvara på den lokala datorn eller bearbetningskrav från den virtuella skrivbordsservern.
Senast uppdaterad
Var detta till hjälp?