> 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/virtual-desktop-infrastructure/vdi-explainer/core-concepts.md).

# Kärnbegrepp

### Optimeringslägen för insticksprogram

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

I samband med Zoom Workplace VDI-appen avser mediebehandling 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 olika 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 reservläge. Dessa diskuteras 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-moln</mark>

Direktoptimerat läge är standardoptimeringsläget för Zoom Workplace VDI-appen och insticksprogrammet. I detta läge 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 merparten av medietrafiken i realtid genom det virtuella skrivbordet eller över den virtuella kanalen.

När systemet körs i direktoptimerat läge sker 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, chattmeddelande eller AI Companion-funktioner, visar den 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.
3. Insticksprogrammet och VDI-skrivbordet använder VDI-leverantörens virtuella anslutning för att kommunicera och avgöra placering och rendering av medier på skärmen mellan de två lagren.

<figure><img src="https://lh7-rt.googleusercontent.com/docsz/AD_4nXdMkBI5zRMicu977C-QSvtu06Kuvb1YyPZMOqh3Tnzd37uapLNkWLZxLNXxEgmg8e8RxX8btLPjVg8EnW0kRRe-UAjKQAIQEeKpsuR0SrEapbZSH5EO1GPtECfHz5G9uN8ptVbegA?key=Y8FtDbpjXDezi-KeGzQVkA" alt=""><figcaption><p>Diagram som illustrerar hur Zoom-moln överför data till två separata destinationer vid användning av direktoptimerat läge.</p></figcaption></figure>

#### <mark style="color:blå;">Kanaloptimerat läge: När insticksprogrammet tar emot data som hairpinnas 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ätverksväg. I detta läge sker följande:

1. Alla mötesmedier levereras först till VDI-servern från Zoom-moln.
2. VDI-servern överför medier 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 *potentiellt* leda till en sämre upplevelse än direktoptimering om villkoren för nätverksdirigering inte är optimala. Bilden nedan visar dataflödet för UDP-/kanaloptimering.

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

#### <mark style="color:blå;">Reservläge: När alla mötesmedier dirigeras till och bearbetas direkt på det virtuella skrivbordet</mark>

Reservläge representerar 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-moln, där all behandling sker uteslutande på VDI-servern.

Denna metod innebär en betydande bearbetningsbelastning på VDI-serverresurser, vilket ofta leder till dålig prestanda, inklusive långsamhet, hackig video och förvrängt ljud. Därför är reservläge det minst föredragna alternativet och bör endast användas som en sista utväg eller när insticksprogram inte är tillgängliga.

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

Reservläge bör undvikas när det är möjligt för att upprätthålla serverprestanda.
{% endhint %}

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

Zoom Workplace VDI-appen stöder tre olika anslutningslägen, vart och ett anpassat för 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 arbetsflödes- eller nätverksbegränsningar, 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 medier** | **Direkt molnåtkomst från insticksprogram** |
| ------------------- | ------------------------ | ------------------------------------------- |
| **Direktoptimerat** | ✔                        | ✔                                           |
| **Kanaloptimerat**  | ✔                        |                                             |
| **Reservläge**      |                          |                                             |

### WebRTC-medieavlastning

#### <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 ljudbehandling 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 ramverk för omdirigering som bryggar Zoom Web App till den motorn.

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

WebRTC-medieavlastning är för närvarande begränsad till ljud och stöder inte videooptimering.
{% 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 avlyssnas dess begäranden 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 maskin, vilket omdirigerar ljudtrafik i realtid från Zoom-moln direkt till användarens lokala maskin.

På den lokala maskinen tar den inbyggda WebRTC-motor som ingår i VDI-klienten (t.ex. Citrix, Omnissa Horizon) emot dessa meddelanden och blir ansvarig för all ljudupptagning, 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 illustrerar hur data dirigeras vid användning av WebRTC-medieavlastning med Zoom Web App och en virtuell agent som stöds.<br>

<div data-with-frame="true"><figure><img src="/files/965fae9a98a388ab92c0914426ccdd895d481930" 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"><figcaption><p>Diagram som illustrerar hur medier delas upp mellan den virtuella skrivbordsmiljön och fjärrklientens enhet.</p></figcaption></figure></div>

#### <mark style="color:blå;">Interaktion mellan Zoom Web App och den lokala maskinen</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. Den virtuella skrivbordsapplikationen 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 maskinen.

Eftersom endast signalmeddelanden passerar genom 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>

Det viktigaste möjliggörande elementet är att VDI-klienten (t.ex. Citrix, Omnissa Horizon) redan innehåller en fullständig WebRTC-motor som kan hantera ljud i realtid. 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 sessionsförhandling från webbläsaren inuti den virtuella skrivbordsmiljön till den inbyggda motorn på den lokala maskinen.

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

Den här metoden gör att Zooms webbläsarbaserade WebRTC-upplevelse kan fungera effektivt i VDI-miljöer med full ljudoptimering. Gränssnittet körs inne i det virtuella skrivbordet, men ljud i realtid 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 maskinen 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:

```
GET https://library.zoom.com/technical-library/sv/avancerade-enterprise-tjanster/virtual-desktop-infrastructure/vdi-explainer/core-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.