> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/sv/avancerade-enterprise-tjanster/vdi/core-concepts.md).

# Grundläggande begrepp

Det här avsnittet ger en översikt över kärnkoncepten i Zoom Workplace VDI app.

### Optimeringslägen för insticksprogram

#### <mark style="color:blå;">Zoom Workplace VDI-appen stöder tre driftlägen för realtidsmediebehandling: Direktoptimerat, Kanaloptimerat och Fallback-läge</mark>

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.

#### <mark style="color:blå;">Direktoptimerat läge: När Zoom Workplace VDI-appen och insticksprogrammet tar emot oberoende dataströmmar från Zoom-molnet</mark>

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:

1. Insticksprogrammet tar emot dataströmmar för video och ljud direkt från molnet.
2. 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.
3. 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.

<div data-with-frame="true"><figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdMkBI5zRMicu977C-QSvtu06Kuvb1YyPZMOqh3Tnzd37uapLNkWLZxLNXxEgmg8e8RxX8btLPjVg8EnW0kRRe-UAjKQAIQEeKpsuR0SrEapbZSH5EO1GPtECfHz5G9uN8ptVbegA?key=Y8FtDbpjXDezi-KeGzQVkA" alt="" width="563"><figcaption><p>Diagram som illustrerar hur Zoom-molnet överför data till två separata destinationer när direktoptimerat läge används.</p></figcaption></figure></div>

#### <mark style="color:blå;">Kanaloptimerat läge: När insticksprogrammet tar emot data som loopas genom det virtuella skrivbordet</mark>

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:

1. All mötesmedia levereras först till VDI-servern från Zoom-molnet.
2. 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.

<div data-with-frame="true"><figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdDt_WwrMDVVWLYDgtsXxsqsQNcflrpzhxtQSV2cnlYTx4IKRPRT49o-VLNfImUru407_vp7LJkRdaF4SdvIO405fZaD4LCcEvTjlUgE54NwfafocBGGKNk2NmRX1dRpcbg5V7U-w?key=Y8FtDbpjXDezi-KeGzQVkA" alt="" width="563"><figcaption><p>Diagram som illustrerar hur data överförs till VDI-skrivbordet och fjärrklienten via en loopad anslutning.</p></figcaption></figure></div>

#### <mark style="color:blå;">Fallback-läge: När all mötesmedia dirigeras till och bearbetas direkt på det virtuella skrivbordet</mark>

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.

{% hint style="danger" %}
**Varning**

Fallback-läget bör undvikas när det är möjligt för att bibehålla serverprestandan.
{% endhint %}

#### <mark style="color:blå;">Sammanfattning av anslutningslägen</mark>

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

#### <mark style="color:blå;">Översikt</mark>

Zoom tillhandahåller en webbläsarbaserad WebRTC-klient via [Zoom Web App](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0064261) 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.

{% hint style="danger" %}
**Varning**

WebRTC-mediaavlastning är för närvarande begränsad till ljud och stöder inte videoptimering.
{% endhint %}

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](https://support.zoom.com/hc/en/article?id=zm_kb\&sysparm_article=KB0083142).

#### <mark style="color:blå;">Zoom Web App avlastar VDI-WebRTC-ljud till den lokala enheten</mark>

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.<br>

<div data-with-frame="true"><figure><img src="https://460446308-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FctBXUMeBy4rtLMmMkKRG%2Fuploads%2FMziMpXttOigLu71P5cJb%2FCA2AE7FE-CEB8-4890-87AD-77E31161C3CC.png?alt=media&amp;token=1e3b3f99-cb95-4ac4-82f0-c717f33b0f3f" alt="Diagram illustrating the Zoom cloud connecting to two different components, with audio going to the Remote Client and Presence, Meeting Data, Video, and Screen Sharing routing to the VDI Desktop" width="563"><figcaption><p>Diagram som illustrerar hur media delas mellan det virtuella skrivbordet och fjärrklientenheten.</p></figcaption></figure></div>

#### <mark style="color:blå;">Interaktion mellan Zoom Web App och den lokala datorn</mark>

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.

#### <mark style="color:blå;">Varför inget insticksprogram krävs</mark>

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.

#### <mark style="color:blå;">Resultat</mark>

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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://library.zoom.com/technical-library/sv/avancerade-enterprise-tjanster/vdi/core-concepts.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.