¿El software de colaboración autoalojado admite llamadas de voz y vídeo? Lista de verificación de preparación de la red

Empieza por definir las llamadas que realmente necesita tu equipo

«Admite llamadas» no es un requisito de implementación completo. Antes de comparar opciones de alojamiento, define quién llamará a quién, qué clientes usará y desde dónde se conectará. Un equipo cuyos miembros comparten una red de oficina puede tener limitaciones distintas de las de un equipo con invitados externos y usuarios conectados desde redes domésticas o móviles.

Confirma qué funciones son importantes. La voz, el vídeo, el uso compartido de pantalla y las llamadas con participantes externos pueden tener distintos requisitos de compatibilidad o configuración. La [guía de implementación de Calls de Mattermost](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) describe Calls como una función autoalojada para llamadas de audio y uso compartido de pantalla; no determina por sí sola si funcionará en todas las redes de tu entorno.

• Haz una lista de las funciones de llamada, los tipos de participantes y los clientes necesarios, como el navegador o la aplicación nativa.
• Incluye las redes que utilizarán las personas: oficina, hogar, móvil y cualquier red de invitados o socios.
• Decide qué fallos son aceptables. Por ejemplo, ¿basta con recurrir al audio si no se puede conectar el vídeo?

Separa el acceso web, la señalización y los medios

Al revisar la documentación oficial de implementación, puede ser útil organizar las preguntas en torno a tres aspectos: el acceso a la interfaz web, el intercambio utilizado para establecer o gestionar una llamada (señalización) y el tráfico de audio y vídeo (medios). La aplicación puede describirlos por separado o utilizar otra terminología; no des por supuesto que esta clasificación refleja su arquitectura interna.

Poder iniciar sesión desde un navegador solo confirma que funciona el acceso web. Anota por separado qué indica la documentación sobre las llamadas y los medios, y marca como pendiente cualquier aspecto que no cubra.

La [descripción de Talk de Nextcloud](https://nextcloud.com/blog/nextcloud-talk-open-source-online-video-conferencing-software/) lo identifica como software de videoconferencia en línea de código abierto que admite chats, llamadas, seminarios web y retransmisiones. Es una descripción de funciones, no una especificación de red para tu implementación.

• Busca la documentación de implementación correspondiente a la aplicación y al modelo que planeas utilizar.
• Anota por separado la información documentada sobre la interfaz web, el establecimiento de llamadas y los medios.
• Comprueba si la información varía según el cliente, la función o el componente; no rellenes los vacíos con suposiciones.

Comprueba los protocolos, los puertos, los firewalls, NAT y los retransmisores

Usa la documentación oficial para elaborar una lista de cambios de red. Anota los protocolos y puertos especificados, la dirección del tráfico y los sistemas o puntos de conexión implicados. No copies una lista genérica de puertos de otro producto: los requisitos pueden variar y las descripciones de funciones no bastan para determinar valores concretos.

Busca qué comportamiento documenta la aplicación para participantes detrás de NAT o de firewalls restrictivos. Comprueba si se esperan conexiones directas de medios, si se admite o se requiere un retransmisor TURN en determinadas circunstancias y quién lo administra. Si la documentación no lo aclara, consulta al proveedor de la aplicación o del alojamiento antes del despliegue.

Un retransmisor puede ser una dependencia que haya que implementar, configurar y mantener. Confirma esos aspectos en la documentación del producto en vez de darlos por sentados. La [guía de implementación de Calls de Mattermost](https://docs.mattermost.com/deployment-guide/calls/calls-deployment-guide) es un punto de partida para Mattermost; la información de funciones citada aquí no especifica requisitos concretos de puertos, NAT o retransmisores.

• Crea una tabla con el protocolo, el puerto, la dirección del tráfico, el destino y la finalidad, según la documentación.
• Pide a los administradores de red que comprueben las reglas necesarias en las redes de oficina y remotas pertinentes.
• Confirma el comportamiento documentado de la travesía de NAT y TURN, incluida la titularidad del retransmisor y quién se encarga de su operación.
• Marca como no verificado todo requisito que no esté documentado.

Verifica TLS, los dominios y las suposiciones sobre el proxy inverso

Comprueba cómo espera la aplicación que se configuren su dominio público, la terminación de TLS y cualquier proxy inverso. Identifica qué componente gestiona cada conexión y si la documentación especifica requisitos para las llamadas aparte de los de la interfaz web. No supongas que una configuración de proxy o TLS es compatible con todas las funciones de llamada si la documentación no lo confirma.

Si tu arquitectura coloca un proxy delante de la aplicación, compara las instrucciones disponibles con la configuración real de enrutamiento y certificados. Resuelve cualquier ambigüedad antes de depender de las llamadas.

La [información del producto de Airbip](https://airbip.com) describe el enrutamiento automatizado y los certificados TLS mediante Traefik y Let’s Encrypt, además de la compatibilidad con un subdominio de Airbip o un dominio personalizado compatible. Estas funciones describen la configuración del alojamiento web; no confirman por sí solas que las llamadas o los medios de una aplicación concreta funcionen en todas las redes.

• Confirma en la documentación de la aplicación el dominio público necesario y el comportamiento de TLS.
• Compara la arquitectura documentada con la configuración real del proxy, DNS y certificados.
• Pide aclaraciones sobre cualquier requisito de proxy o TLS específico para las llamadas que no esté documentado.

Haz pruebas con usuarios representativos

Una vez implementada la configuración documentada, prueba desde las redes que realmente utilizarán tus usuarios. Incluye redes domésticas, móviles, de invitados o de socios cuando formen parte del público previsto, y al menos una red restrictiva si es pertinente.

Utiliza una lista de verificación repetible: ¿pueden los participantes iniciar y unirse a una llamada, oírse mutuamente en ambas direcciones, activar el vídeo y compartir el contenido necesario? Prueba también qué ocurre cuando se interrumpe y se restablece una conexión. Si la aplicación indica cuándo se utiliza un retransmisor, registra ese resultado; no lo deduzcas solo por la calidad de la llamada.

Considera el resultado como evidencia de cómo funcionó la configuración probada para esos usuarios y redes en ese momento, no como garantía para cualquier red o dispositivo. Las fuentes citadas no prescriben un procedimiento de pruebas de red; esta lista es una orientación general de implementación.

• Prueba cada tipo de cliente necesario y las funciones de llamada que el equipo planea utilizar.
• Haz pruebas con participantes en redes de oficina, domésticas, móviles y otras redes pertinentes, incluidos entornos restrictivos cuando sea posible.
• Registra el establecimiento de la llamada, el audio en ambas direcciones, el vídeo, el uso compartido de pantalla si se necesita, la reconexión y cualquier información disponible sobre el retransmisor.
• Anota la fecha, el tipo de cliente, el contexto de red y el resultado para comparar los resultados después de los cambios.

Elige un modelo de implementación según requisitos verificados

Compara las opciones de alojamiento después de identificar los requisitos documentados de la aplicación y los controles de red disponibles. Considera si puedes configurar las reglas necesarias, operar u obtener cualquier servicio de retransmisión requerido e investigar los fallos que experimenten los usuarios en distintas redes.

Una implementación gestionada puede encargarse de algunos aspectos de la infraestructura de una aplicación, pero eso no confirma por sí solo la compatibilidad de todas sus funciones de llamada o rutas de red. La [información del producto de Airbip](https://airbip.com) describe instancias de aplicaciones ejecutadas como cargas de trabajo de Docker en sus servidores en la nube, además de gestión del ciclo de vida del servicio, comprobaciones de DNS y copias de seguridad diarias, semanales y mensuales configurables. Evalúa estas funciones junto con los requisitos de llamadas confirmados en la documentación de la aplicación.

Si tu equipo no puede proporcionar un control de red o un retransmisor requerido, o gestionar las necesidades de sus usuarios, otro modelo de implementación o un servicio diseñado para ese caso de uso podría encajar mejor. Basa la decisión en los requisitos verificados, no en la presencia de un botón de llamada.

• Asigna cada requisito documentado a un responsable: tu equipo, el proveedor de alojamiento o el fabricante de la aplicación.
• Confirma las dependencias de retransmisores y controles de red antes de comprometerte con una implementación.
• Elige otro modelo si no se puede satisfacer una función necesaria o asumir la responsabilidad operativa correspondiente.

Documenta las responsabilidades y vuelve a probar tras los cambios

Conserva un registro conciso de la arquitectura, los protocolos y puertos documentados, la configuración de DNS y TLS, la del proxy, las dependencias de retransmisores y quién se responsabiliza de cada cambio. Incluye una vía para notificar fallos y ayudar a distinguir problemas de acceso web, de establecimiento de llamadas o de medios.

Repite las pruebas representativas después de cambios en la aplicación, el alojamiento, el proxy, el firewall, el retransmisor o las redes de los usuarios. Una comprobación documentada y repetible es más útil que tratar una llamada satisfactoria como garantía permanente.

• Registra la documentación consultada y la fecha, junto con cualquier pregunta sin respuesta.
• Asigna responsables de los cambios en el firewall, la operación del retransmisor, la configuración de la aplicación y la asistencia a los usuarios.
• Vuelve a probar tras cambios importantes en la infraestructura o la red y actualiza el registro.