Grundläggande begrepp
Det här avsnittet ger en översikt över Zoom Workplace VDI-appens grundläggande begrepp.
Optimeringslägen för plug-in
Zoom Workplace VDI-appen stöder tre driftslägen för bearbetning av realtidsmedia: Direct Optimized, Channel Optimized och Fallback Mode
I sammanhanget med Zoom Workplace VDI-appen avser bearbetning av realtidsmedia vidareföring och renderingen av realtidsmedia mellan Zoom-molnet, Zoom Workplace VDI-appen och/eller plug-in. För att stödja en rad VDI-användningsfall stöder Zoom Workplace VDI-appen tre skilda driftslägen för mediehantering och optimering: Direct Optimized-läget, Channel Optimized-läget och Fallback-läget. Dessa beskrivs i följande avsnitt.
Direct Optimized-läge: När Zoom Workplace VDI-appen och plug-in tar emot oberoende dataströmmar från Zoom-molnet
Direct Optimized-läge är standardoptimeringsläget för Zoom Workplace VDI-appen och plug-in. I detta läge upprätthåller Zoom-molnet två separata dataströmmar för en optimerad VDI-användare: en för Zoom Workplace VDI-appen och en annan för plug-in. Denna konfiguration gör det möjligt för användarens fjärrklient (utrustad med VDI-plug-in) att kommunicera direkt med Zoom-molnet för överföring av realtidsmedia, vilket eliminerar behovet av att routa största delen av realtidsmediatrafiken genom den virtuella skrivbordsmiljön eller över den virtuella kanalen.
När man kör i Direct Optimized-läge sker följande:
Plug-in 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, chattmeddelanden eller AI Companion-funktioner, och visar detta i Workplace-appens platsinnehåll, samtidigt som den hanterar inkommande skärmdelning genom att vidarebefordra den till plug-in och ladda upp lokalt skärmdelningsinnehåll från den virtuella skrivbordsmiljön när den är aktiv.
Plug-in och VDI-skrivbordet använder VDI-leverantörens virtuella anslutning för att kommunicera och bestämma placering och renderering av skärmmaterial mellan de två lagren.
Channel Optimized-läge: När plug-in tar emot data som loopas via det virtuella skrivbordet
Kanalsoptimering liknar Direct Optimization-upplevelsen, där plug-in fortsätter att rendera mötesmediet (som ses i bilden ovan), men genom en annan nätverksväg. I detta läge sker följande:
Allt mötesmedia levereras först till VDI-servern från Zoom-molnet.
VDI-servern överför media till plug-in antingen via en out-of-band UDP-anslutning eller via den befintliga VDI-virtuella kanalen om UDP-anslutningen inte kan upprättas.
Denna metod kan föredras av organisationer som inte tillåter direkt internetåtkomst för tunna klienter (eller andra fjärrenheter), eller som föredrar att routa data genom sitt nätverk, men kan potentiellt leda till en sämre upplevelse än Direct Optimization om nätverksrutten är suboptimal. Bilden nedan demonstrerar UDP/Channel-optimeringens dataflöde.
Fallback-läge: När allt mötesmedia routas till och bearbetas direkt på det virtuella skrivbordet
Fallback-läget representerar en helt ooptimerad VDI-upplevelse. I detta läge finns ingen medieoptimering eller plug-in i bruk, och all kommunikation sker direkt mellan VDI-servern och Zoom-molnet, med all bearbetning som sker uteslutande på VDI-servern.
Denna metod lägger en betydande belastning på VDI-serverns resurser, vilket ofta resulterar i dålig prestanda, inklusive långsamhet, ryckig video och förvrängt ljud. Som sådan är Fallback-läge det minst önskvärda alternativet och bör endast användas som sista utväg eller när plug-ins inte är tillgängliga.
Varning
Fallback-läge bör undvikas när det är möjligt för att upprätthålla serverns prestanda.
Sammanfattning av anslutningslägen
Zoom Workplace VDI-appen stöder tre skilda anslutningslägen, vardera anpassat till olika drift- och säkerhetsbehov. Standard- och mest effektiva läget är Direct Optimized-läget, där Zoom Workplace VDI-appen och plug-in etablerar separata anslutningar till Zoom-molnet och oberoende hanterar sina respektive delar av ett Zoom-möte för att leverera en sömlös, optimerad upplevelse.
Utöver Direct Optimized-läget kan Zoom Workplace VDI-appen köras i alternativa konfigurationer, inklusive Channel Optimized-läge och Fallback-läge. Dessa lägen kan hjälpa till att hantera specifika arbetsflödes- eller nätverksbegränsningar, såsom begränsad internetåtkomst för fjärrenheter, datarouting av integritetsskäl eller frånvaro av plug-ins.
Följande tabell sammanfattar nyckelskillnaderna mellan dessa lägen.
Avlastning av media
Direkt molnåtkomst från plug-in
Direct Optimized
✔
✔
Channel Optimized
✔
Fallback Mode
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 inuti en virtuell skrivbordsmiljö. Detta fungerar utan att kräva några Zoom-specifika plug-ins eftersom VDI-plattformen tillhandahåller sin egen lokala WebRTC-motor och ett omdirigeringsramverk som kopplar Zoom Web App till den motorn.
Varning
WebRTC-medieavlastning är för närvarande begränsad till ljud och stödjer inte videoptimering.
Denna funktion stödjer följande produkter och kanaler från Zoom Web App:
Zoom Phone
Zoom Contact Center
Zoom Contact Center CTI Connector
Denna funktion stöds för närvarande av följande virtuella skrivbordplattformar:
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 inuti det virtuella skrivbordet försöker initiera WebRTC-ljud fångas dess förfrågningar upp innan det virtuella skrivbordet försöker fånga eller bearbeta ljud. Istället för att aktivera webbläsarens inbyggda WebRTC-mediehögver i den hostade sessionen, översätter VDI-plattformen de ljudrelaterade signalerna till lätta styrmeddelanden. Dessa meddelanden skickas genom VDI-leverantörens virtuella kanal till användarens lokala maskin och dirigerar realtidljudtrafik från Zoom-molnet direkt till användarens lokala maskin.
På den lokala maskinen 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 systemets lokala mikrofon, högtalare och processresurser, vilket hjälper till att säkerställa att ljud inte flödar genom den virtuella skrivbordservern.
Följande diagram illustrerar hur data routas vid användning av WebRTC-medieavlastning med Zoom Web App och en stödjande virtuell agent.

Interaktion mellan Zoom Web App och den lokala maskinen
Ur Zoom Web App:s 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. Den virtuella skrivbordsapplikationen fortsätter att presentera Zoom-gränssnittet—kontroller, mötesstatus och indikatorer—medan det faktiska realtidsljudet genereras och konsumeras av den lokala maskinen.
Eftersom endast signaleringsmeddelanden passerar den virtuella kanalen är bandbreddsöverhead låg och konsekvent, även i miljöer med flera användare.
Varför ingen plug-in krävs
Den avgörande möjliggöraren är att VDI-klienten (t.ex. Citrix, Omnissa Horizon) redan inkluderar en fullständig WebRTC-medieengine som kan hantera realtidsljud. Eftersom omdirigeringslagret får denna motor att framstå för Zoom Web App som dess underliggande WebRTC-implementation behöver Zoom inte tillhandahålla och underhålla en separat plug-in. Omdirigeringslogiken kartlägger WebRTC API-anrop, enhetstillgång och sessionsförhandling från webbläsaren inuti det virtuella skrivbordet till den inbyggda motorn på den lokala maskinen.
Resultat
Denna metod gör det möjligt för Zooms webbläsarbaserade WebRTC-upplevelse att fungera effektivt i VDI-miljöer med full ljudoptimering. Gränssnittet körs inne i det virtuella skrivbordet, men realtidsljudet fångas och bearbetas lokalt, vilket ger användarna en responsiv och skalbar konferensupplevelse utan att kräva ytterligare Zoom-programvara på den lokala maskinen eller bearbetningskrav från den virtuella skrivbordets server.
Last updated
Was this helpful?

