> 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/es/servicios-empresariales-avanzados/zoom-mesh/zoom-mesh-functionality.md).
# Funcionalidad
Esta sección detalla información adicional sobre la funcionalidad de Zoom Mesh.
### Funcionalidad principal-secundario
Las siguientes secciones proporcionan información adicional sobre las relaciones entre padre e hijo dentro de una red de malla.
#### De forma predeterminada, Zoom Mesh crea una red exclusivamente para los usuarios dentro de la misma cuenta
De forma predeterminada, Zoom Mesh crea una red exclusivamente para los usuarios que pertenecen a la misma cuenta. Sin embargo, una cuenta puede permitir opcionalmente que usuarios externos autenticados dentro de la misma red de área local participen en la malla, proporcionando la cuenta del usuario externo *también* les permite [conectarse a la red de malla de otra cuenta](https://support.zoom.us/hc/en-us/articles/14925064423693-How-to-enable-Zoom-Mesh-Guest-Access).
#### Los roles de padre e hijo son determinados por el Servicio de orquestación en la nube de Zoom Mesh
El Servicio de orquestación en la nube de Zoom Mesh (COS) es un servicio en la nube responsable de definir los roles de cliente padre e hijo dentro de una red. El Servicio de orquestación en la nube considera numerosos conjuntos de datos para determinar clientes padre viables, entre ellos:
{% columns %}
{% column %}
* Utilización de CPU
* Tipo de CPU
* Utilización de RAM
* Rendimiento histórico de la malla
{% endcolumn %}
{% column %}
* Disponibilidad del Dispositivo (Encendido/Apagado)
* Aceptación/Exclusión del Dispositivo
* Sistema operativo
{% endcolumn %}
{% endcolumns %}
Usando estos conjuntos de datos, el COS puntúa los resultados de un usuario mediante una rúbrica: cuanto más alta sea la puntuación de un usuario, más probable es que el cliente sea seleccionado como padre; cuanto más baja sea la puntuación, menos probable.
#### La designación de cliente padre e hijo es dinámica y puede cambiar durante un evento
Durante el transcurso de una reunión o seminario web, la designación de cliente de un usuario puede cambiar en función del rendimiento o la demanda.
Por ejemplo, en un evento de 100 asistentes, solo pueden requerirse 10 clientes padre para satisfacer la demanda de redistribución, y los 90 usuarios restantes reciben transmisiones redistribuidas como clientes hijo. Sin embargo, si el evento aumenta a 200 asistentes, los clientes que antes eran clientes hijo pueden ascender a un cliente padre para hacer frente a la mayor demanda.
Alternativamente, si un cliente padre comienza a experimentar un rendimiento degradado, el cliente puede ser rebajado al estado de cliente hijo, y se asignará un nuevo cliente padre.
#### La proporción de clientes padre-hijo se determina dinámicamente según el hardware y el rendimiento de red de cada máquina
Durante un evento, la proporción padre-hijo entre clientes se actualiza dinámicamente según el rendimiento continuo de red y hardware del dispositivo.
Por ejemplo, si un dispositivo muestra una baja utilización de hardware (CPU/RAM) con una alta capacidad de enlace ascendente de ancho de banda, el dispositivo es ideal para un rol de cliente padre y puede establecer una relación padre-hijo con varios otros dispositivos. En este escenario, el cliente padre puede intentar redistribuir medios a otros dispositivos, siempre que el dispositivo no esté sobreasignado o comience a degradarse en rendimiento. Sin embargo, si el rendimiento de red o hardware del dispositivo comienza a declinar, puede ceder su designación de cliente padre y volver a un rol de cliente hijo.
#### A cada hijo se le asignan dos padres
A los clientes hijo conectados a una red de malla se les asignan *dos* clientes padre para resiliencia. Si un cliente padre falla, el usuario cambiará inmediatamente al segundo cliente padre. Luego se establece un nuevo cliente padre secundario para restaurar la resiliencia.
#### Los usuarios no son informados cuando están conectados a una red de malla
Los anfitriones del evento y los asistentes no reciben notificaciones dentro del cliente cuando están conectados a una red de malla. Las conexiones de la red de malla solo pueden ser vistas por un administrador o un usuario autorizado a través de la [Panel de control de Zoom Mesh](/technical-library/es/servicios-empresariales-avanzados/zoom-mesh/zoom-mesh-dashboard.md).
#### Los clientes VDI solo pueden establecer una conexión de malla con otros clientes VDI
Cuando se usa Zoom Mesh con infraestructura de escritorio virtual (VDI), los dispositivos cliente solo pueden establecer conexiones de Zoom Mesh con otros clientes VDI, siempre que ambos usuarios estén usando un complemento VDI compatible. Esto se debe a las limitaciones técnicas de la infraestructura virtual y a la retransmisión de medios entre dispositivos.
**Los clientes VDI no distribuyen el canal de uso compartido de contenido en una red de malla**
Debido al diseño del cliente VDI de Zoom, el contenido de uso compartido de pantalla debe enrutarse a través de la máquina virtual. En consecuencia, los clientes VDI no pueden distribuir el uso compartido de contenido a través de una red de malla, y deben seguir distribuyéndose dentro de la infraestructura virtual.
### Funcionalidad de Zoom Mesh para reuniones
Las siguientes secciones describen detalles de la funcionalidad de Zoom Mesh para reuniones.
#### Mesh for Meetings Redistribuye el video del orador activo
Con Zoom Mesh para reuniones, la optimización del ancho de banda se logra redistribuyendo el *descendente* **del orador activo** video entre los participantes cuando hay cuatro o más usuarios en una reunión. Esta característica **no** se aplica a la carga de medios, y todos los usuarios seguirán cargando individualmente su audio, video y uso compartido de pantalla a la nube de Zoom.
{% hint style="success" %}
**Ejemplo**
Si hay 10 usuarios en una reunión con Zoom Mesh habilitado, pueden elegirse dos clientes padre con siete u ocho clientes hijo. Cuando el orador activo actual está hablando, la *transmisión de video* se transmitirá desde la nube de Zoom a los clientes padre, y luego se redistribuirá a los clientes hijo dentro de la red.
En este escenario, los clientes hijo **no** reciben la señal de video del orador activo desde la nube de Zoom, ahorrando potencialmente hasta más de 3 megabits de datos por usuario cuando se usa video de 1080p.
{% endhint %}
La siguiente imagen proporciona un ejemplo de cómo el contenido de video del orador activo descendente se redistribuye dentro de una red de malla.
#### Los cambios de orador activo en Mesh for Meetings no alteran las relaciones padre-hijo ni los ahorros de ancho de banda de la distribución de video
Aunque el enfoque de Zoom Mesh para reuniones es redistribuir la señal de video del orador activo, los cambios en el orador activo no afectan las relaciones entre clientes padre e hijo ni los ahorros de ancho de banda que proporciona la redistribución de video. Cuando cambia el orador activo, los clientes padre designados simplemente cambian la señal del video que están redistribuyendo.
{% hint style="success" %}
**Ejemplo**
Si Maurice está hablando en una reunión y luego Holly comienza a hablar, la señal de redistribución del cliente padre cambiará de la señal de video de Maurice a la de Holly.
Este cambio no altera qué clientes de usuario están actualmente designados como padres o hijos, ni los ahorros generales de ancho de banda que proporciona la redistribución de video; solo cambia la señal de video redistribuida.
{% endhint %}
#### Los ahorros de ancho de banda pueden variar según los diseños de video seleccionados por el usuario
Aunque Zoom Mesh ahorra consumo de ancho de banda al redistribuir la señal de video del orador activo, los ahorros de ancho de banda pueden verse afectados según los diseños elegidos por los usuarios. Por ejemplo, Vista de galería admite hasta 49 transmisiones de video en pantalla a la vez, mientras que Vista del orador muestra una sola transmisión de video a la vez. Si un usuario está viendo una reunión en Vista de galería, se beneficiará al recibir la única señal de video del orador activo a través de la red de malla, pero seguirá consumiendo cantidades estándar de ancho de banda al descargar las 48 transmisiones de video restantes de los usuarios desde la nube de Zoom.
Para las mejores prácticas de ahorro de ancho de banda, se anima a los usuarios a ver las reuniones con un diseño lo más parecido posible al de un seminario web, como Multi-Speaker o Vista del orador.
### Funcionalidad de Zoom Mesh para seminarios web
Las siguientes secciones describen detalles de la funcionalidad de Zoom Mesh para seminarios web.
#### Mesh for Webinars redistribuye *todos* las transmisiones de video de los anfitriones y panelistas del seminario web dentro de la red
A diferencia de Zoom Mesh para reuniones, Zoom Mesh para seminarios web redistribuye todas las transmisiones de video de los anfitriones y panelistas del seminario web dentro de la red local usando relaciones padre-hijo, no solo los oradores activos. Con este diseño, todos los usuarios que participan en la red de malla seguirán beneficiándose de un consumo reducido de ancho de banda externo mientras experimentan la misma calidad de video que los demás.
#### Los beneficios de Mesh for Webinars no cambian con los diseños de video
Independientemente del diseño de video que los usuarios elijan al ver un seminario web, los usuarios seguirán recibiendo los beneficios de la redistribución de video dentro de la red, incluyendo Vista de galería, Vista del orador o Vista de múltiples oradores.
---
# 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/es/servicios-empresariales-avanzados/zoom-mesh/zoom-mesh-functionality.md?ask=&goal=
```
`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.
