What determines SIP video bandwidth?

Mostly resolution and frame rate, encoded with H.264, plus the audio stream. The exact bitrate also depends on the encoder quality setting and how much motion the scene contains. Plan from your real settings, not a generic number.

How many calls can my link support?

It depends on the per-call bitrate and your peak concurrent calls, not the device count. Estimate one call's video-plus-audio bitrate, multiply by simultaneous calls on the busiest link, then add headroom. No fixed count applies to every site.

Does audio add much to the plan?

Not much. G.711 is about 64 kbps, G.722 about 64 kbps at wideband, and Opus ranges roughly 8 to 48 kHz. Count audio as a modest addition to the video figure.

What if the wireless link cannot hold video?

Design a fallback to audio-only. An audio SIP call needs a fraction of the bandwidth and still completes door release or dispatch. Confirm the terminals fall back when video negotiation fails.

Should I trust the nominal bitrate setting?

Measure it. Capture a real call and read the negotiated bitrate from the device or the SIP session; the actual encoder output is what you size from. Nominal settings often differ from the stream on the wire.

Does FlySip fix echo or noise on video calls?

No. Echo cancellation is the sister product FlyAec and noise reduction is FlyDenoise. The SIP video terminal and server handle signalling, routing and media transport, not acoustic processing.

ENGINEERING · VIDEO · 9 min read

Video Intercom Bandwidth Planning for SIP

How to size network bandwidth for SIP video intercom using resolution, frame rate and codec, with headroom and a fallback plan.

2026-11-06 · FlySip engineering · All guides

Audio SIP intercom is light; video is not. A door station streaming H.264 to a desk console adds a steady media stream that, multiplied across floors and buildings, becomes a real capacity question for the access switch and the uplink.

This guide sizes bandwidth from the variables that actually drive it: resolution, frame rate, the codec bitrate, and how many calls run at once. It gives a method and headroom rules, not a fixed table, because every site's cameras and concurrency differ.

The variables that drive bandwidth

Video bitrate is set primarily by resolution and frame rate, encoded with H.264. A higher resolution carries more pixels per frame; a higher frame rate sends more frames per second; both raise the bitrate. The exact bitrate also depends on the encoder's quality setting and how much motion the scene contains.

Audio rides alongside on a separate RTP stream, small by comparison: G.711 is about 64 kbps, G.722 also about 64 kbps at wideband, and Opus ranges roughly 8 to 48 kHz. For planning, count the audio as a modest addition to the video figure rather than a separate large budget.

Resolution — more pixels per frame raises bitrate.
Frame rate — more frames per second raises bitrate.
Codec — H.264 for video; G.711 / G.722 / Opus for audio.
Motion — busy scenes need more bits at the same setting.

Estimate per call, then multiply by concurrency

Start from a single call. Pick the resolution and frame rate the door station actually uses, and estimate the H.264 bitrate for that setting. Add the audio stream. That is one call's peak media demand.

Then multiply by the number of simultaneous calls you must support, not the number of devices. A building with two hundred door stations rarely has two hundred active video calls at once; the concurrency that matters is the peak simultaneous streams on the busiest link. Plan the access switch port and the uplink for that peak, not the device count.

Rule of thumb: size for peak concurrent calls on the worst link, then add headroom. A table that assumes a fixed number of calls for every site would mislead; your concurrency is the input.

Switch, uplink and wireless

The access switch must carry the sum of active streams on its ports without saturation, and the uplink to the recorder or the central server must carry the aggregate that crosses it. Mark the media with DSCP so the switch treats it as priority traffic, and keep the voice/video path on a separated VLAN so a burst of office traffic cannot starve a call.

Wireless door stations are the easy place to underestimate. Radio capacity is shared and variable; a video stream that is fine on a cable can stall on a weak Wi-Fi link. Where video over wireless is unavoidable, measure the real throughput at the device location before trusting the plan, and prefer wired PoE for fixed door stations.

Leave headroom and plan a fallback

Never plan to the exact number. Codec variability, retransmits, and a second concurrent call on the same link all consume the margin. A common practice is to reserve headroom above the estimated peak so a brief surge does not drop a frame-critical call.

Design the fallback before you need it. If the link cannot sustain video, the call should degrade to audio rather than fail entirely. An audio-only SIP call needs a fraction of the bandwidth and still completes the door-release or dispatch purpose. Confirm the terminals can fall back to audio when video negotiation fails, so a bandwidth squeeze never turns into a dead station.

Snapshot-assisted install and verification

During commissioning, capture a short video call and read the actual bitrate the encoder produced, rather than trusting the nominal setting. Many door stations expose the negotiated bitrate in their web interface or in the SIP session; the real number is what you size from.

Verify under realistic load: trigger several concurrent calls on the busiest switch and watch for packet loss or jitter on the media. If the measured peak plus headroom exceeds the link, move that link to a higher tier or reduce concurrency expectations before sign-off. The product page lists video ranges and concurrency estimates; ask for the test conditions before quoting them as guarantees.

Measure the real encoded bitrate on a sample call.
Multiply by peak concurrent calls on the worst link.
Add headroom above the estimated peak.
Confirm audio-only fallback when video cannot sustain.
Load-test the busiest switch before sign-off.

Frequently asked questions

What determines SIP video bandwidth?: Mostly resolution and frame rate, encoded with H.264, plus the audio stream. The exact bitrate also depends on the encoder quality setting and how much motion the scene contains. Plan from your real settings, not a generic number.
How many calls can my link support?: It depends on the per-call bitrate and your peak concurrent calls, not the device count. Estimate one call's video-plus-audio bitrate, multiply by simultaneous calls on the busiest link, then add headroom. No fixed count applies to every site.
Does audio add much to the plan?: Not much. G.711 is about 64 kbps, G.722 about 64 kbps at wideband, and Opus ranges roughly 8 to 48 kHz. Count audio as a modest addition to the video figure.
What if the wireless link cannot hold video?: Design a fallback to audio-only. An audio SIP call needs a fraction of the bandwidth and still completes door release or dispatch. Confirm the terminals fall back when video negotiation fails.
Should I trust the nominal bitrate setting?: Measure it. Capture a real call and read the negotiated bitrate from the device or the SIP session; the actual encoder output is what you size from. Nominal settings often differ from the stream on the wire.
Does FlySip fix echo or noise on video calls?: No. Echo cancellation is the sister product FlyAec and noise reduction is FlyDenoise. The SIP video terminal and server handle signalling, routing and media transport, not acoustic processing.

Bandwidth is only half the network story. For marking and isolation read network planning with VLAN and QoS, and for where audio-only fallback matters most see elevator emergency intercom. Browse all SIP guides or the FlySip product overview.