Grundläggande begrepp
Det här avsnittet ger en översikt över de grundläggande begreppen i Zoom Workplace VDI app.
Optimeringslägen för insticksprogram
Zoom Workplace VDI-appen stöder tre driftlägen för realtidsmediebehandling: Direktoptimerat, Kanaloptimerat och Fallback-läge
I samband med Zoom Workplace VDI-appen avser realtidsmediebehandling vidarebefordran och rendering av realtidsmedia mellan Zoom-molnet, Zoom Workplace VDI-appen och/eller insticksprogrammet. För att stödja en rad VDI-användningsfall stöder Zoom Workplace VDI-appen tre olika driftlägen för mediebehandling och optimering: Direktoptimerat läge, Kanaloptimerat läge och Fallback-läge. Dessa beskrivs i följande avsnitt.
Direktoptimerat läge: När Zoom Workplace VDI-appen och insticksprogrammet tar emot oberoende dataströmmar från Zoom-molnet
Direktoptimerat läge är standardoptimeringsläget för Zoom Workplace VDI-appen och insticksprogrammet. 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 insticksprogrammet. Denna konfiguration gör att användarens fjärrklient (utrustad med VDI-insticksprogrammet) kan kommunicera direkt med Zoom-molnet för överföringar av realtidsmediedata, vilket eliminerar behovet av att dirigera det mesta av realtidsmedietrafiken 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, chattmeddelanden eller AI Companion-funktioner, och visar den i platsmarkören för Workplace-appen, samtidigt som den också 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 avgöra placeringen och renderingen av media på skärmen mellan de två lagren.
Kanaloptimerat läge: När insticksprogrammet tar emot data som loopas genom det virtuella skrivbordet
Kanaloptimering liknar upplevelsen med direktoptimering, där insticksprogrammet fortsätter att rendera mötesmedierna (som visas i bilden ovan), men via en annan nätverkssökväg. I detta läge inträffar följande:
All mötesmedia levereras först till VDI-servern från Zoom-molnet.
VDI-servern överför media till insticksprogrammet antingen via en out-of-band UDP-anslutning eller via 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 eventuellt leda till en sämre upplevelse än Direktoptimerat läge om nätverksdirigeringsförhållandena är suboptimala. Bilden nedan visar dataflödet för UDP-/kanaloptimering.
Fallback-läge: När all mötesmedia dirigeras till och bearbetas direkt på det virtuella skrivbordet
Fallback-läget innebär en helt ooptimerad VDI-upplevelse. I detta läge används ingen medieoptimering eller något insticksprogram, och all kommunikation sker direkt mellan VDI-servern och Zoom-molnet, med all bearbetning som sker uteslutande på VDI-servern.
Denna metod innebär en betydande bearbetningsbelastning på VDI-serverresurserna, vilket ofta resulterar i dålig prestanda, inklusive långsamhet, hackig video och förvrängt ljud. Därför är Fallback-läget det minst föredragna alternativet och bör endast användas som sista utväg eller när insticksprogram inte är tillgängliga.
Varning
Fallback-läget bör undvikas när det är möjligt för att bibehålla serverprestandan.
Sammanfattning av anslutningslägen
Zoom Workplace VDI-appen stöder tre olika anslutningslägen, vart och ett anpassat efter olika operativa behov och säkerhetsbehov. Standard- och det mest effektiva läget är Direktoptimerat läge, där Zoom Workplace VDI-appen och insticksprogrammet upprättar separata anslutningar till Zoom-molnet och oberoende hanterar sina respektive delar av ett Zoom-möte för att leverera en sömlös och optimerad upplevelse.
Utöver Direktoptimerat läge kan Zoom Workplace VDI-appen fungera i alternativa konfigurationer, inklusive Kanaloptimerat 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, data-dirigering av integritetsskäl eller avsaknad av insticksprogram.
Följande tabell sammanfattar de viktigaste skillnaderna mellan dessa lägen.
Mediaavlastning
Direkt molnåkomst från insticksprogrammet
Direktoptimerat
✔
✔
Kanaloptimerat
✔
Fallback-läge
WebRTC-mediaavlastning
Ö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 kopplar samman Zoom Web App med den motorn.
Varning
WebRTC-mediaavlastning är för närvarande begränsad till ljud och stöder inte videoptimering.
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 förfrågningar upp innan det virtuella skrivbordet försöker spela in eller bearbeta ljud. I stället för att aktivera webbläsarens inbyggda WebRTC-mediastack i den värdbaserade sessionen översätter VDI-plattformen den ljudrelaterade signaleringen till lätta styrmeddelanden. Dessa meddelanden skickas genom VDI-leverantörens virtuella kanal till användarens lokala dator och omdirigerar realtidsljudtrafik från Zoom-molnet 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 ljudet inte passerar genom den virtuella skrivbordsservern.
Följande diagram illustrerar hur data dirigeras när WebRTC-mediaavlastning används med Zoom Web App och en stödd virtuell agent.
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. Applikationen för det virtuella skrivbordet fortsätter att presentera Zoom-gränssnittet—kontroller, mötesstatus och indikatorer—medan det faktiska realtidsljudet genereras och förbrukas av den lokala datorn.
Eftersom endast signalmeddelanden passerar den virtuella kanalen är bandbreddsöverheaden låg och konsekvent, även i miljöer med flera användare.
Varför inget insticksprogram krävs
Den avgörande möjliggöraren är att VDI-klienten (t.ex. Citrix, Omnissa Horizon) redan innehåller en fullständig WebRTC-mediamotor 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 ett separat insticksprogram. Omdirigeringslogiken mappar WebRTC-API-anrop, enhetsåtkomst och sessionfö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 fullständig ljudoptimering. Gränssnittet körs inne i det virtuella skrivbordet, men realtidsljudet fångas upp och bearbetas lokalt, vilket ger användarna en responsiv och skalbar konferensupplevelse utan att kräva ytterligare Zoom-programvara på den lokala datorn eller bearbetningskrav från det virtuella skrivbordets server.
Senast uppdaterad
Var detta till hjälp?