Internet para eventos: cómo preparar la conexión y probar el respaldo

Dibujá qué usa internet y qué se queda en la red local

Internet conecta con servicios externos; la red local comunica equipos dentro del recinto, como el control de una consola o el video IP. WiFi es una forma de acceder a una red. Podés tener buena señal WiFi y, aun así, una salida insuficiente hacia la plataforma. Dibujá las funciones que necesita el evento y anotá quién se ocupa de cada una.

Separá los usos en el plano: encoder y plataformas, oradores remotos, operación técnica, acreditación y asistentes. Con el equipo de IT, acordá switches, VLAN, SSID y políticas para ese reparto. Un nombre de WiFi distinto puede ayudar a ordenar usuarios; preguntá también cómo se reserva capacidad si todos salen por la misma conexión.

Cuando pidas el servicio, explicá si vas a hacer streaming, recibir invitados remotos, subir archivos, distribuir interpretación o dar acceso al público. Esas tareas tienen permisos, horarios y tolerancia a cortes diferentes. Por ejemplo, una carga de archivos puede esperar; una intervención en vivo necesita su ruta lista en ese momento.

Qué preguntarle al recinto y al proveedor antes del montaje

Pedí por escrito dónde entregan la conexión, cuándo estará activa, qué subida y bajada acordaron, cómo se comparte y quién da soporte durante el show. Si la llaman dedicada, preguntá qué parte es exclusiva: el puerto, el segmento local, una capacidad reservada o el circuito. La respuesta te ayuda a entender qué estás contratando y qué dependencias quedan.

Confirmá DHCP o el direccionamiento acordado, autenticación, restricciones del puerto y portal cautivo. Pasale a IT los destinos y protocolos de las aplicaciones para que habilite y pruebe lo necesario dentro de sus políticas. Abrir una web desde el equipo es una comprobación inicial; falta verificar que el encoder llegue al servidor de ingest, donde enviará el directo.

En un hotel o congreso, probá el punto físico antes de abrir puertas y preguntá qué otros eventos compartirán el servicio. Afuera, revisá hasta dónde llega un enlace fijo y probá las alternativas en esa ubicación. Acordá acceso al gabinete o soporte autorizado, alimentación y protección de los tendidos. Tener el contacto técnico a mano ayuda cuando el puerto de entrega queda lejos de control.

Calculá la subida según los envíos que estarán activos

Listá video y audio del encoder, un segundo envío, participantes remotos y otras cargas que coincidan. Sumá sus demandas según cómo esté armada la ruta y dejá margen operativo. Si una plataforma recibe tu directo y lo distribuye, cada espectador no genera automáticamente otro envío desde el recinto. En cambio, varias salidas directas del encoder sí entran en la cuenta.

YouTube distingue subida y bajada y recomienda dejar margen respecto del bitrate total enviado. También advierte que compartir la red limita la capacidad de cada conexión. Revisá esa orientación para YouTube y agregá las necesidades de los otros servicios que convivirán en el evento. Tenés la referencia en sus consejos de streaming.

Resolución, cuadros por segundo y códec cambian los ajustes del envío. Antes de cerrar el plan, mirá la tabla vigente de la plataforma y el encoder que usarás. Una charla, un partido y varias transmisiones paralelas pueden exigir configuraciones distintas. Consultá los ajustes oficiales del codificador de YouTube para el flujo que estés preparando.

Un ejemplo de cálculo propio: dos envíos de 8 Mbps suman 16 Mbps antes de agregar otros usos y margen. Es una manera de empezar la cuenta, no una garantía de que una conexión contratada a 16 Mbps alcance. Todavía tenés que considerar sobrecarga de red, capacidad sostenida y el resultado de la prueba hasta el destino.

Probá el cable en el lugar donde va a trabajar el encoder

OBS recomienda conexión cableada para streaming porque WiFi puede ser inestable. Conectá el equipo al punto autorizado y seguí su ruta hasta el destino. Un test hecho en el lobby no representa necesariamente el puerto que tendrás en control. La guía de OBS sobre problemas de conexión explica qué revisar.

Anotá puerto, switch, adaptador, tipo de cable, longitud y protección del recorrido. Elegí los enlaces con IT o el proveedor según el estándar y las distancias del proyecto. Etiquetá ambos extremos y mirá dónde podrían desconectarse: una mesa que se mueve, una puerta o el paso del servicio pueden afectar un tendido que funcionó durante la primera prueba.

Para recorridos largos, cruces entre edificios o conexión con otras redes, pedí un diseño específico. Revisá esa ruta junto con energía, circulación y acceso a los equipos, en vez de ir agregando cables y switches sobre la marcha. Montarla con tiempo te deja comprobarla antes del ensayo general.

Qué hace el respaldo cuando se cae la ruta principal

Dibujá principal y respaldo con sus dependencias: proveedor, acceso físico, router, switch, alimentación y destino. Dos conexiones pueden terminar en el mismo equipo o compartir energía. Preguntá qué diversidad ofrece el proveedor y qué pérdida querés cubrir: enlace, equipo o alimentación. Con eso podés detectar qué queda fuera del respaldo.

Haivision Gateway documenta rutas SRT active-active y active-backup y distingue respaldo de enlace de respaldo de equipos. Para usarlas, los extremos y la configuración tienen que ser compatibles. Si te proponen esa arquitectura, revisá la documentación de redundancia SRT de Haivision con el proveedor; conectar dos módems por sí solo todavía deja pendiente cómo se gestiona el transporte.

Un router con failover cambia la salida; una solución de bonding o redundancia de transporte puede usar varias rutas según su diseño. Pedí que la propuesta identifique el servicio y el receptor o servicio asociado. Al cambiar IP o sesión, alguna aplicación puede tener que reconectarse. Hacé el cambio en ensayo y mirá el reproductor final para medir qué ve y escucha el público.

Si el respaldo es celular, probalo en el lugar y en un horario representativo. Revisá antenas, alimentación, plan de datos y tráfico previsto. La capacidad puede cambiar cuando llega el público, así que dejá anotados los límites y la forma de recuperar el programa. Un buen resultado previo ayuda a planificar, pero no fija la capacidad que habrá durante todo el show.

Del speedtest a una prueba que llegue al público

Guardá la medición de velocidad con hora, punto y condiciones. Después enviá desde el encoder y la cuenta reales, con video en movimiento, audio y una duración representativa. YouTube recomienda probar contenido parecido al directo y seguir la salud de la transmisión. Podés revisar sus ajustes y pruebas de ingest mientras preparás el ensayo.

En OBS, diferenciá cuadros perdidos por red de problemas de renderizado o codificación. Los dropped frames de red apuntan a una ruta inestable al servidor o a que no se sostiene el bitrate. Guardá indicadores y registros para revisar el tramo con el operador o el proveedor. La guía de diagnóstico de conexión de OBS te ayuda a separar esas situaciones.

Miralo también desde una conexión externa a producción. Escuchá la voz y comprobá imagen, sincronía y acceso con los dispositivos elegidos. Mantené activos los otros flujos del evento y anotá qué cambia al sumar carga. La vista previa en control es útil; la comprobación externa agrega lo que ocurre al llegar al destino.

Invitados remotos, idiomas y archivo local

Con cada invitado remoto, ensayá entrada, retorno, pantalla compartida y conversación con el salón. Acordá quién le da acceso, quién sigue el orden del programa y qué recurso usarás si su conexión se pierde. La red de esa persona también forma parte de la intervención, aunque esté en otra ciudad.

Si hay traducción simultánea, agregá rutas de intérpretes y oyentes, permisos de plataforma y una prueba por idioma. Un sistema de receptores independientes y una app que entrega audio por red tienen necesidades distintas. Revisá la solución completa antes de cambiar entre una y otra.

Si necesitás una grabación local, acordá qué señales guarda y escuchá una muestra. Ante un corte del directo, el archivo puede servir para la entrega posterior; sólo conservará los canales que hayas grabado y la experiencia en vivo tendrá su propia recuperación. En el centro de ayuda técnica podés repasar las áreas que se cruzan en esa cadena.

Prepará la conexión y practicá la recuperación

Reservá la prueba de falla para un ensayo acordado, antes de abrir puertas o iniciar el directo de producción. Medí cuánto tarda la recuperación y qué tiene que hacer el operador. Revisá cada destino para describir el resultado con claridad, incluida cualquier interrupción que haya visto el público de prueba.

1. Hacé la lista de usos

   Anotá equipos, plataformas, envíos simultáneos y tareas del público. Acordá capacidad y responsables con el recinto y el proveedor.

2. Confirmá el punto de entrega

   Comprobá puerto, permisos, direccionamiento, horarios y contacto de soporte. Dejá identificadas la conexión principal y la de respaldo.

3. Montá en la posición real

   Instalá y etiquetá Ethernet, switches y alimentación previstos. Probá con el encoder donde va a trabajar.

4. Abrí cada aplicación

   Enviá al ingest real, hacé las llamadas remotas y escuchá los idiomas o servicios que dependan de la red.

5. Sumá los usos que coincidirán

   Activá los flujos representativos y observá encoder, red y reproducción externa durante el período acordado.

6. Probá el cambio y el regreso

   Interrumpí de forma controlada la ruta principal dentro del ensayo. Comprobá cómo se recupera el programa y qué pasa al volver al principal.

7. Seguí la conexión durante el show

   Mantené visibles los indicadores y el contacto de soporte. Anotá los cambios y las fallas para que el equipo pueda revisar lo que pasó después del evento.

Cómo aislar cortes en OBS

Compará rutas y conservá el registro de la sesión afectada. Una mejora después de cambiar varios ajustes no identifica una causa única. Repetí las pruebas de a una, con el encoder y el destino del evento.

El speedtest da bien y el streaming igual se corta

Como cambiaron varios tramos, el resultado dejó una mejora observada y preguntas abiertas sobre la causa.

Para un show con varios destinos, anotá la ruta completa: encoder, conexión, servicio intermedio y destino. Repetí pruebas comparables cada vez que interviene el proveedor o cambiás un tramo. Así podés ver dónde aparece el corte y qué cambió al desaparecer.

Dejá preparada una alternativa que ya hayas ensayado. Si modificás varias cosas a la vez, podés recuperar la emisión sin saber cuál resolvió el problema. Para investigarlo, cambiá una variable por prueba y guardá el resultado; una sesión estable todavía necesita comprobarse durante el tiempo previsto de servicio.

La guía de OBS para problemas de conexión propone comparar servidores o servicios, revisar bitrate dinámico y trabajar con el proveedor de internet. Aplicá esas opciones según lo que indiquen tus pruebas.

1. Reproducí el montaje

   Probá con cámaras, capturadoras y audio del evento. Guardá hora, duración, destino, bitrate y cuadros perdidos. Separá las alertas de red de las de renderizado o codificación.

2. Compará las dos rutas

   Hacé una emisión de prueba directa y otra mediante el servicio intermedio, con configuración comparable. Repetí ambas después de una intervención del proveedor. Usá el resultado para localizar el tramo que cambia.

3. Llevá datos al proveedor

   Pasale horarios y registros de los cortes. Si necesitás sostener una emisión mientras se investiga, evaluá reducir el caudal o usar bitrate dinámico y acordá con producción cómo afectará la imagen.

Guardá el registro de la sesión en la que ocurrió el corte

Al aportar el registro de la sesión correcta apareció una pista distinta.

Antes de reemplazar equipos, comprobá que el archivo corresponda al corte que querés investigar: hora, sesión y adaptador en uso. Si el registro describe otra conexión, podés terminar ajustando una red que no estaba involucrada.

Para tu computadora, revisá modelo, versiones y lo que cambió antes del corte. Después de ajustar algo, repetí una prueba completa y sostenida; que desaparezca una advertencia es un dato a observar, no el cierre del ensayo.

Para revisar cable, conexión y controlador, consultá la guía de Ethernet de Microsoft.

1. Reproducí y guardá esa sesión

   En una emisión de prueba, anotá la hora exacta del corte. Detenela y guardá el registro antes de cerrar OBS. Si ya reiniciaste, diferenciá el log anterior del actual y revisá qué adaptador estaba en uso.

2. Cambiá un elemento por vez

   Compará cable y puerto con otros que sepas que funcionan. Registrá si el enlace renegocia, se desconecta o sólo pierde cuadros hacia el destino. Una lectura de 100 Mbps, por sí sola, no demuestra falta de ancho de banda.

3. Revisá el controlador con soporte

   Si los cortes empezaron después de una actualización, comprobá el controlador del modelo exacto. Conservá un instalador de respaldo y ensayá cualquier cambio fuera del horario de servicio.

El Wi-Fi figura conectado, pero el hotel todavía no te deja salir

Tener IP y haber completado el acceso son dos comprobaciones distintas.

Antes del montaje, pedile a IT una conexión autorizada para producción y preguntá cuándo vence la sesión. Si el respaldo usa ese Wi-Fi, probá el ingreso con el router y los equipos que vas a llevar. Que el celular navegue conectado directamente al hotel deja pendiente la prueba de los clientes detrás del router.

1. Ubicá dónde se corta

   Comprobá asociación al Wi-Fi, dirección entregada, apertura del portal y acceso desde una notebook detrás del router. En GL.iNet, Login Mode pone el DNS en automático y suspende algunos servicios durante el ingreso; después revisá qué quedó activo.

2. Mirá el panel de tu firmware

   En v4.8.x, Global Mode y Policy Mode muestran controles distintos. Revisá si el tráfico de ese cliente queda bloqueado por una política VPN antes de cambiar ajustes.

3. Acordá la salida con el hotel

   Si el portal sigue fallando, pedí a IT que autorice el router o entregue otra conexión. Con el acceso listo, ensayá el envío del encoder y una reconexión antes del show.

El cable y el Wi-Fi vuelven al mismo router: ¿qué falla cubre el respaldo?

Cuando fallaba el primer recorrido, no cambiaba automáticamente.

Para el evento, seguí ambos recorridos hasta su salida. Si llegan al mismo router y proveedor, cambiar de cable a Wi-Fi deja esas dependencias compartidas. Esa alternativa puede servir para un problema del tendido; acordá con IT qué querés cubrir antes de llamarla respaldo de internet.

1. Anotá dónde termina cada ruta

   Registrá conexión, gateway y equipo de salida con IT. Dos IP distintas no te dicen si las rutas comparten infraestructura.

2. Mirá qué está detectando el router

   En Multi-WAN de GL.iNet, Interface Status Track comprueba disponibilidad; deshabilitado, considera el estado físico. Revisá esa opción y la prioridad de cada interfaz en el firmware que vas a usar.

3. Probá una falla con el cable todavía conectado

   Acordá con IT una pérdida controlada de la salida a internet, además de la prueba de desconexión del cable. Observá la llamada o el directo, anotá la recuperación y repetí al volver al principal.

Load Balance reparte conexiones: probá la subida del encoder

Si llevás internet fijo y un acceso móvil, medí qué consigue el encoder con cada uno antes de sumar sus Mbps en una propuesta. En Multi-WAN de GL.iNet, Load Balance reparte conexiones nuevas según la proporción configurada. Eso puede ayudar al conjunto de equipos; una sola conexión de envío no pasa a tener automáticamente la suma de ambos enlaces.

La guía Multi-WAN aclara que la proporción de carga tampoco garantiza el mismo reparto del tráfico que ya está activo. Una notebook puede abrir varias conexiones; contar computadoras no alcanza para saber cómo se distribuye el uso.

Probá por separado cada acceso con el bitrate, destino y duración del evento. Después repetí con el modo previsto y las otras tareas en marcha: invitados remotos, carga de archivos y recepción de material. Mirá la emisión desde afuera y guardá qué conexión y configuración usaste en cada prueba.

Si usás un Spitz AX GL-X3000, revisá otro detalle del manual de ese modelo: sólo una SIM está activa a la vez; la segunda queda como reserva. Para evaluar dos accesos celulares simultáneos, necesitás identificar qué equipo y módem sostiene cada uno.

Antes de sumar un router, acordá qué direcciones usa la red de audio

Cuando el evento suma internet, avisale a quien opera el audio antes de conectar otro router al switch de producción. Dibujá dónde entra la conexión externa y qué equipos ya se comunican en esa red. Pedile a IT que revise quién asigna direcciones y qué puertos vas a usar.

En Avantis o dLive con M-DL-DANT64/128, la nota del fabricante advierte que agregar una red con DHCP puede cambiar la dirección de la tarjeta y causar una pérdida temporal de audio. Por eso conviene revisar el direccionamiento antes de conectar el router.

Guardá direcciones, nombres de dispositivos y diagrama antes de la intervención. Acordá una ventana de ensayo y probá la modificación con una señal reconocible en cada destino. Si una aplicación deja de encontrar la consola, comprobá también la dirección actual antes de tocar el patch que estaba funcionando.

Identificá además el conector: en esas tarjetas, Control Network y el puente interno sirven para control y no pasan audio. La misma nota describe su alcance. Etiquetá el tendido y dejá el plano actualizado para que otra persona pueda distinguir el acceso de control del recorrido Dante.

En la computadora de producción, nombrá cada conexión por su función

Una computadora puede participar en varias redes durante el evento. En el plano de trabajo, identificá cada conexión por lo que hace: acceso a internet, control de audio o enlace de otro equipo. Anotá también el adaptador físico y la aplicación que lo usa, para poder seguir el recorrido sin adivinar.

La Digiface Dante ofrece un ejemplo concreto: además del audio por USB, puede aportar acceso Ethernet al Mac. RME cambió ese soporte con firmware64; desde esa versión no hace falta el add-on netifc. Por eso vale la pena comprobar hardware y versión cuando armás la computadora, en lugar de repetir la configuración guardada de otro evento.

Con todas las conexiones previstas presentes, comprobá la salida de streaming y el acceso a los equipos locales. Después de cambiar un adaptador, repetí ambas verificaciones. Que una aplicación siga funcionando sólo confirma esa parte del montaje; mirá la otra antes de cerrar el ensayo.

Guardá una captura de las interfaces junto al esquema. Si otra persona toma el puesto, tiene un punto de partida para reconocer qué cambió. Esa información también ayuda al venue cuando el pedido de internet convive con una red técnica propia.

Para repartir audio, pasá una lista de destinos a la red

Un pedido de red para un evento queda más claro si incluye quién necesita cada señal. Separá el audio que va sólo a un puesto del contenido que van a recibir varias salas, grabadores o procesadores. Esa lista ayuda a revisar el reparto antes de sumar conexiones.

Dante usa unicast por defecto. Multicast permite compartir canales entre varios receptores, pero sigue ocupando ancho de banda aunque nadie esté suscripto. Por eso una lista de destinos sirve más que pedir multicast para todo.

Anotá qué equipos se agregan durante el programa y qué rutas pueden retirarse al terminar cada bloque. Revisá los cambios con audio y el responsable de la red del recinto antes de abrir las salas. Si aparece un puesto nuevo, actualizá ese listado: el pedido de conectividad también cambia aunque los archivos o la música sean los mismos.

Marcá Primary y Secondary antes de conectar otro equipo

Cuando conviven producción, transmisión y gente del recinto, un puerto libre termina siendo una tentación. Identificá quién puede conectar equipos y dejá un esquema junto al rack. Antes de enchufar la notebook nueva, averiguá a qué red pertenece esa toma.

Audinate describe Primary en una red física y Secondary en otra separada para los dispositivos con redundancia. Los equipos sin redundancia se conectan a Primary. Dos conectores de red por sí solos no confirman qué función cumplen en ese modelo.

Incluí en el esquema las conexiones de audio y el acceso a Internet que necesita cada puesto. Si una toma no está identificada, consultá al responsable de red antes de usarla. Dejar esto resuelto en el armado evita improvisar conexiones durante una falla.

Paquetes tardíos y corruptos: pruebas distintas

Si internet sigue andando y el audio local se corta, llevá la comprobación al enlace que usa ese audio. Un speed test hacia afuera no recorre necesariamente el tramo entre el switch y el receptor.

En Network Status, Latency Errors señala llegadas cerca o fuera del plazo; Packet Errors, paquetes corruptos entre switch y receptor. Para lo segundo, compará ese cable con uno probado, fuera del servicio.

Después repetí el mismo audio y observá si vuelven los errores. Hacé una comparación por vez: cambiar cable, switch y ajustes juntos impide saber qué tuvo efecto.

Ficha de conexión para coordinar recinto y producción

Hacé una lista de las tareas que dependen de internet. Para cada una, anotá sala, horario, aplicación y responsable: transmisión, invitados remotos, acreditación o acceso de asistentes. Marcá cuáles coinciden.

Sumá el contacto del recinto y el del proveedor, con la tarea que cubre cada uno. Dejá escrito quién solicita el servicio, quién confirma su contratación y quién puede responder durante el evento.

Adjuntá la propuesta de conexión que recibiste y señalá qué falta confirmar. Si todavía no conocés el punto de entrega o el horario de habilitación, poné un responsable para conseguir esos datos.

En SRT, separá pérdidas detectadas de paquetes que no se recuperaron

Si recibís el directo con un Makito X4 Decoder, guardá los contadores del flujo al empezar y terminar el ensayo. Anotá la hora de los cortes.

En la sección SRT del manual 1.7, Lost Packets cuenta pérdidas detectadas que pueden recuperarse. Skipped Packets son los paquetes que no llegaron a tiempo y quedaron descartados; Recovered Packets (SRT), los recuperados a tiempo.

Compará esas variaciones con imagen y sonido en el destino. No uses un total acumulado para adjudicarle un fallo al último bloque: puede incluir incidencias anteriores.

Teams: revisá con IT los puertos y destinos del servicio

Microsoft documenta TCP 80/443 y UDP 3478–3481, junto con URLs y rangos IP de Teams. Pasale a IT el listado oficial para revisar la ruta dentro de sus políticas.

Ensayá audio, video y pantalla compartida en la computadora y conexión del evento. Registrá cortes y reconexiones. Que abra una web no completa esa prueba.

Web Presenter HD/4K: confirmá qué conexión usará el envío

Con Ethernet y un celular conectados, revisá Setup → Network → Connection Priority. El manual de mayo de 2024 permite elegir la conexión del envío; para usar tethering con Ethernet conectado indica Mobile.

Prepará el tethering del teléfono y ensayá la ruta elegida mirando el reproductor final. Registrá el cambio y el regreso. Elegir prioridad todavía requiere probar la recuperación.

Web Presenter HD/4K: mirá Data Rate y Cache

Data Rate muestra el caudal del encoder incluso fuera del aire. Cache indica buffer ocupado; al 100% se compromete el directo. Anotá ambos y mirá el reproductor externo.

Manual Web Presenter, mayo 2024, p.14.