Event internet: plan the connection and test the backup

Map internet use separately from local network traffic

Internet connects you to external services; the local network connects equipment within the venue, such as console control or IP video. Wi-Fi is one way to access a network. A strong Wi-Fi signal can still lead to an inadequate connection to the platform. Map the functions your event needs and identify who handles each one.

Separate the uses on the plan: encoder and platforms, remote speakers, technical operation, registration and attendees. Agree with IT on switches, VLANs, SSIDs and the policies for that arrangement. A separate Wi-Fi name can help organize users; also ask how capacity is reserved if everyone shares the same internet connection.

When requesting service, explain whether you will be live streaming, bringing in remote guests, uploading files, distributing interpretation or providing attendee access. These tasks have different permissions, schedules and tolerance for interruptions. A file upload can wait, for example; a live contribution needs its connection ready at that moment.

What to ask the venue and provider before load-in

Ask in writing where the connection will be handed off, when it will be active, the agreed upload and download capacity, how it is shared and who provides support during the show. If the service is described as dedicated, ask what is exclusive: the port, local segment, reserved capacity or circuit. The answer helps you understand what you are booking and which dependencies remain.

Confirm DHCP or the agreed addressing scheme, authentication, port restrictions and any captive portal. Give IT the applications' destinations and protocols so they can authorize and test the required access under their policies. Opening a website on the device is an initial check; you still need to verify that the encoder can reach the ingest server that will receive the stream.

At a hotel or conference, test the physical handoff before doors open and ask which other events will share the service. Outdoors, establish how far a fixed connection can reach and test alternatives at that location. Agree on authorized cabinet access or support, power and cable protection. Keep the technical contact available, especially when the handoff port is far from production control.

Calculate upload capacity for simultaneous streams

List encoder video and audio, a second outgoing stream, remote participants and any other uploads that will overlap. Add their requirements according to the routing and allow operating headroom. If a platform receives your stream and distributes it, each viewer does not automatically create another upload from the venue. Multiple direct encoder outputs, however, do count toward the total.

YouTube distinguishes upload from download and recommends headroom above the total outgoing bitrate. It also notes that sharing a network limits the capacity available to each connection. Review that guidance for YouTube and add the requirements of the other services running at the event. See its streaming tips.

Resolution, frame rate and codec affect encoder settings. Before finalizing the plan, check the platform's current table and the encoder you will use. A talk, a sports event and several parallel streams may need different configurations. Consult the official YouTube encoder settings for the stream you are preparing.

A planning example: two 8 Mbps streams add up to 16 Mbps before other uses and headroom. This starts the calculation; it does not guarantee that a connection sold as 16 Mbps will be enough. You still need to account for network overhead, sustained capacity and the results of an end-to-end test.

Test the cable where the encoder will operate

OBS recommends a wired connection for streaming because Wi-Fi can be unstable. Connect the device at the authorized handoff and trace its path to the destination. A test in the lobby does not necessarily represent the port you will have at production control. The OBS connection troubleshooting guide explains what to check.

Record the port, switch, adapter, cable type, length and protection along the route. Select links with IT or the provider based on the standard and the project's distances. Label both ends and check where they could be disconnected: a moving table, a door or service traffic can affect a cable that worked during the first test.

Request a specific design for long runs, links between buildings or connections to other networks. Review that route together with power, circulation and equipment access instead of adding cables and switches as you go. Installing it early leaves time to check it before the full rehearsal.

What the backup does when the primary path fails

Map the primary and backup paths and their dependencies: provider, physical access, router, switch, power and destination. Two connections may end at the same device or share power. Ask what diversity the provider offers and which failure you want to cover: a link, equipment or power. This identifies what remains outside the backup's scope.

Haivision Gateway documents active-active and active-backup SRT paths and distinguishes link backup from equipment backup. Both endpoints and their configuration must support the arrangement. If that architecture is proposed, review the Haivision SRT redundancy documentation with the provider; connecting two modems alone does not define how the transport will be managed.

A failover router changes the outgoing connection; a bonding or transport-redundancy solution may use multiple paths according to its design. Ask the proposal to identify the service and its associated receiver or service endpoint. When the IP address or session changes, some applications may need to reconnect. Rehearse the change and watch the final player to measure what the audience sees and hears.

If the backup is cellular, test it on site at a representative time. Check antennas, power, the data plan and expected traffic. Capacity may change as attendees arrive, so record its limits and the recovery procedure. A good advance test helps with planning but does not establish the capacity available throughout the show.

Go beyond a speed test: check what the audience receives

Save the speed measurement with its time, location and conditions. Then stream from the actual encoder and account, using moving video and audio for a representative duration. YouTube recommends testing content similar to the live program and monitoring stream health. Review its ingest settings and testing guidance as you prepare the rehearsal.

In OBS, distinguish network-related dropped frames from rendering or encoding problems. Network dropped frames point to an unstable path to the server or an inability to sustain the bitrate. Save indicators and logs so the operator or provider can investigate that segment. The OBS connection diagnostics guide helps distinguish these conditions.

Watch from a connection outside the production network as well. Listen to speech and check the picture, synchronization and access on the selected devices. Keep the other event streams running and record what changes as load increases. The preview at production control is useful; the external check adds what happens at the destination.

Remote guests, languages and local recording

Rehearse each remote guest's connection, return feed, screen sharing and conversation with the room. Agree on who grants access, who follows the running order and what you will use if the guest's connection drops. That person's network is part of the contribution, even if they are in another city.

If the event includes simultaneous interpretation, add interpreter and listener paths, platform permissions and a test for each language. A system with independent receivers and an app delivering audio over a network have different requirements. Review the complete solution before switching between them.

If you need a local recording, agree on which signals it will store and listen to a sample. If the live stream fails, the file may support delivery afterward; it will contain only the channels you recorded, and the live audience still needs a recovery plan. The technical help center covers the areas involved in that signal path.

Prepare the connection and rehearse recovery

Schedule failure tests during an agreed rehearsal, before doors open or the production stream goes live. Measure recovery time and the actions required from the operator. Check every destination so you can describe the result clearly, including any interruption seen by the test audience.

1. List the uses

   Record equipment, platforms, simultaneous streams and attendee tasks. Agree on capacity and responsibilities with the venue and provider.

2. Confirm the handoff point

   Check the port, permissions, addressing, operating hours and support contact. Identify the primary and backup connections.

3. Set up at the actual operating position

   Install and label the planned Ethernet links, switches and power. Test with the encoder where it will operate.

4. Open every application

   Send to the actual ingest server, make the remote calls and listen to the languages or services that depend on the network.

5. Add the uses that will overlap

   Run representative streams and monitor the encoder, network and external playback for the agreed period.

6. Test switchover and return

   Interrupt the primary path in a controlled way during rehearsal. Check how the program recovers and what happens when you return to the primary connection.

7. Monitor the connection during the show

   Keep indicators and the support contact available. Record changes and failures so the team can review what happened after the event.

How to isolate connection drops in OBS

Compare paths and keep the log from the affected session. An improvement after several settings change does not identify a single cause. Repeat tests one change at a time, using the event's encoder and destination.

The speed test looks good, but the stream still drops

If you change several parts of the path together, a stable stream does not establish which change fixed the interruption.

For a show with multiple destinations, record the full path: encoder, connection, intermediate service and destination. Repeat comparable tests whenever the provider intervenes or you change a segment. This helps locate where the interruption appears and what changed when it stopped.

Have an alternative ready that you have already rehearsed. Changing several things at once may restore the stream without showing which change solved the problem. To investigate, change one variable per test and save the result; a stable session still needs to be checked for the planned service duration.

The OBS connection troubleshooting guide suggests comparing servers or services, reviewing dynamic bitrate and working with the internet provider. Apply those options according to what your tests show.

1. Reproduce the setup

   Test with the event's cameras, capture devices and audio. Record time, duration, destination, bitrate and dropped frames. Separate network alerts from rendering or encoding alerts.

2. Compare both paths

   Run one direct test stream and another through the intermediate service, using comparable settings. Repeat both after provider intervention. Use the results to identify the segment that changes.

3. Give the provider useful evidence

   Share the times and logs of interruptions. If you need to keep a stream running while the issue is investigated, consider reducing the bitrate or using dynamic bitrate, and agree with production on the effect on picture quality.

Keep the log from the session that failed

Use the log from the affected session to identify which connection and adapter were active when the interruption occurred.

Before replacing equipment, check that the file covers the interruption you want to investigate: time, session and adapter in use. If the log describes a different connection, you may end up adjusting a network that was not involved.

For that computer, review the model, versions and changes made before the interruption. After an adjustment, repeat a complete, sustained test. A warning disappearing is something to observe, not the end of the rehearsal.

For cable, connection and driver checks, consult the Microsoft Ethernet guide.

1. Reproduce the issue and save that session

   During a test stream, record the exact time of the interruption. Stop the stream and save the log before closing OBS. If you have already restarted, distinguish the previous log from the current one and check which adapter was in use.

2. Change one component at a time

   Compare the cable and port with known-working alternatives. Record whether the link renegotiates, disconnects or only drops frames on the way to the destination. A 100 Mbps link reading alone does not demonstrate insufficient bandwidth.

3. Review the driver with support

   If the interruptions started after an update, check the driver for the exact model. Keep a backup installer and rehearse any change outside service hours.

Wi-Fi is connected, but the hotel has not granted internet access

Having an IP address and completing access authorization are separate checks.

Before load-in, ask IT for an authorized production connection and find out when the session expires. If the backup uses that Wi-Fi, test login with the router and equipment you will bring. A phone browsing directly on the hotel's network does not yet test clients behind the router.

1. Locate where access stops

   Check Wi-Fi association, the assigned address, portal access and connectivity from a laptop behind the router. On GL.iNet, Login Mode sets DNS to automatic and temporarily suspends some services during login; afterward, check which services are active.

2. Check the panel for your firmware

   In v4.8.x, Global Mode and Policy Mode expose different controls. Check whether a VPN policy is blocking that client's traffic before changing settings.

3. Agree on access with the hotel

   If the portal still fails, ask IT to authorize the router or provide another connection. Once access works, rehearse the encoder's stream and a reconnection before the show.

Ethernet and Wi-Fi lead to the same router: what does the backup cover?

Check whether the router detects a loss of internet access while the local physical link remains connected.

For the event, trace both paths to their internet exit. If they reach the same router and provider, switching from Ethernet to Wi-Fi retains those shared dependencies. That alternative may cover a cable problem; agree with IT on what you want to cover before describing it as internet backup.

1. Record where each path ends

   Record the connection, gateway and exit device with IT. Two different IP addresses do not tell you whether the paths share infrastructure.

2. Check what the router detects

   In GL.iNet Multi-WAN, Interface Status Track checks availability; when disabled, the router uses physical link status. Review that option and interface priorities in the firmware you will use.

3. Test a failure with the cable still connected

   Arrange a controlled loss of internet access with IT, in addition to unplugging the cable. Watch the call or stream, record recovery and repeat when returning to the primary path.

Load Balance distributes connections: test the encoder's upload

If you bring both fixed internet and a mobile connection, measure what the encoder achieves over each before adding their Mbps in a proposal. In GL.iNet Multi-WAN, Load Balance assigns new connections according to the configured ratio. That can help the devices as a group; it does not automatically give one outgoing connection the combined capacity of both links.

The Multi-WAN guide also explains that the load ratio does not guarantee the same distribution for traffic already in progress. A laptop can open several connections; counting computers is not enough to establish how usage is distributed.

Test each access connection separately at the event's bitrate, destination and duration. Then repeat with the planned mode and the other tasks running: remote guests, file uploads and incoming media. Watch the stream externally and record the connection and configuration used for each test.

If you use a Spitz AX GL-X3000, check another detail in the manual for that model: only one SIM is active at a time; the second is a backup. To assess two simultaneous cellular connections, identify the device and modem supporting each one.

Before adding a router, agree on audio network addressing

When adding internet to an event setup, notify the audio operator before connecting another router to the production switch. Map where the external connection enters and which devices already communicate on that network. Ask IT to review who assigns addresses and which ports you will use.

For an Avantis or dLive with an M-DL-DANT64/128, the manufacturer's fitting note warns that adding a DHCP-enabled network may change the card's address and cause a temporary loss of audio. Review addressing before connecting the router.

Save addresses, device names and the diagram before making the change. Agree on a rehearsal window and test the modification with a recognizable signal at each destination. If an application can no longer find the console, check its current address before changing a patch that was working.

Also identify the connector: on these cards, Control Network and the internal bridge provide control access and do not carry audio. The same fitting note describes their scope. Label the cables and keep the drawing current so another operator can distinguish control access from the Dante path.

Label each production computer connection by its function

A production computer may use several networks during an event. On the working plan, identify each connection by its function: internet access, audio control or a link to another device. Record the physical adapter and the application using it so you can trace the path without guessing.

Digiface Dante is one example: in addition to USB audio, it can provide Ethernet access for a Mac. RME changed that support with firmware 64; from that version, the netifc add-on is no longer required. Check hardware and version when preparing the computer instead of repeating a configuration saved from another event.

With all planned connections present, check both the streaming output and access to local equipment. After changing an adapter, repeat both checks. One application continuing to work confirms only that part of the setup; check the other before finishing rehearsal.

Save a screenshot of the interfaces with the diagram. If another operator takes over, it gives them a starting point for identifying changes. It also helps the venue when an internet request needs to coexist with a separate technical network.

Give the network team a list of audio destinations

An event network request is clearer when it identifies who needs each signal. Separate audio sent to a single station from content that several rooms, recorders or processors will receive. That list helps review distribution before adding connections.

Dante uses unicast by default. Multicast can share channels with multiple receivers, but it still uses bandwidth when nobody is subscribed. A destination list is therefore more useful than asking for multicast everywhere.

Record which devices will be added during the program and which routes can be removed after each segment. Review changes with audio and the venue's network lead before opening the rooms. If a new station is added, update the list: connectivity requirements change even if the files or music stay the same.

Identify Primary and Secondary before connecting another device

When production, streaming and venue teams share a space, an unused port can look inviting. Identify who may connect equipment and keep a diagram by the rack. Before plugging in a new laptop, find out which network that socket belongs to.

Audinate places Primary on one physical network and Secondary on another separate network for devices that support redundancy. Devices without redundancy connect to Primary. Two network connectors alone do not establish their functions on a particular model.

Include audio connections and the internet access required at each station in the diagram. If a socket is not identified, ask the network lead before using it. Settling this during setup avoids improvised connections during a failure.

Late packets and corrupted packets need different tests

If internet still works but local audio drops out, test the link carrying that audio. An external speed test does not necessarily use the segment between the switch and receiver.

In Network Status, Latency Errors indicates arrivals near or beyond the allowed time; Packet Errors indicates corrupted packets between the switch and receiver. For the latter, compare that cable with a known-working one outside service hours.

Then repeat the same audio and watch for recurring errors. Make one comparison at a time: changing the cable, switch and settings together prevents you from knowing which change had an effect.

Connection brief for the venue and production team

List the tasks that depend on internet. For each, record the room, schedule, application and responsible person: streaming, remote guests, registration or attendee access. Mark those that overlap.

Add the venue and provider contacts and the tasks each covers. State who requests the service, who confirms the booking and who can respond during the event.

Attach the connection proposal you received and identify anything still to be confirmed. If the handoff point or activation time is unknown, assign someone to obtain that information.

Download the connection brief (TXT) — a blank planning worksheet; completing it does not send an inquiry.

SRT: distinguish detected loss from packets that were not recovered

If you receive the stream with a Makito X4 Decoder, save the stream counters at the start and end of rehearsal. Record the time of any interruptions.

In the SRT section of the version 1.7 manual, Lost Packets counts detected losses that may be recovered. Skipped Packets are packets that missed their deadline and were discarded; Recovered Packets (SRT) counts those recovered in time.

Compare those changes with picture and sound at the destination. Do not attribute a failure to the last segment using a cumulative total alone: it may include earlier incidents.

Teams: review service ports and destinations with IT

Microsoft documents TCP 80/443 and UDP 3478–3481, together with Teams URLs and IP ranges. Give IT the official list to review the path under its policies.

Rehearse audio, video and screen sharing on the event computer and connection. Record interruptions and reconnections. Opening a website does not complete that test.

Web Presenter HD/4K: confirm which connection will carry the stream

With Ethernet and a phone connected, check Setup → Network → Connection Priority. The May 2024 manual lets you select the outgoing connection; to use tethering while Ethernet is connected, it specifies Mobile.

Prepare phone tethering and rehearse the selected path while watching the final player. Record switchover and return. Selecting a priority still requires a recovery test.

Web Presenter HD/4K: watch Data Rate and Cache

Data Rate shows encoder throughput even when off air. Cache indicates occupied buffer space; at 100%, the live stream is at risk. Record both and watch the external player.

Web Presenter manual, May 2024, p. 14.