Is a voice VLAN a security boundary for door access?

No. A voice VLAN isolates traffic and simplifies QoS, but door-release authorization is an application-layer permission handled by the SIP server and relay logic. Do not treat VLAN separation as the access control itself.

Which DSCP value should I use for SIP voice?

Mark RTP media EF (46) per RFC 4594, SIP signalling CS3 (24) or AF31, and video AF41 (34) when it needs its own class. The marking only helps if preserved across every hop to the server.

Why does my EF marking disappear at the core?

Usually the trunk or uplink is not trusting or is rewriting DSCP. Audit the trust boundary, confirm upstream links preserve the value end to end, then verify with a capture at the server.

How should I scope multicast paging?

Keep paging on the voice VLAN and enable IGMP snooping so only subscribed ports receive the stream. Document the multicast group address and port per zone during planning to avoid silent speakers.

How do I size the PoE budget correctly?

Compare the sum of every device's class against the switch's total PoE budget with headroom, not the per-port figure. If it does not close, split load across switches or use local supplies on the UPS.

Should the switch trust DSCP from end devices?

Most deployments trust the voice VLAN access ports and re-mark there, then preserve upstream. Trusting all devices lets a misconfigured host mark itself EF and starve real voice, so keep the boundary explicit.

ENGINEERING · NETWORK · 9 min read

SIP Intercom Network Planning: VLAN and QoS

Keep SIP voice and video predictable on a shared LAN: separate voice onto its own VLAN, mark packets with DSCP, and set the switch trust boundary.

2026-11-06 · FlySip engineering · All guides

A SIP intercom is a real-time application on the same LAN as laptops, cameras, and building management. Left unplanned, a firmware download can turn a door call into a half-second of silence at the wrong moment. Network planning is what keeps voice and video predictable.

This guide covers five decisions every integrator makes: separating voice onto its own VLAN, marking packets with DSCP, handling multicast paging, sizing the PoE budget, and setting where the switch trusts or rewrites QoS. None requires exotic hardware - it requires consistency.

Voice VLAN: Isolation, Not Just a Subnet

A voice VLAN is a dedicated Layer-2 segment for terminals and the SIP server, separate from the data VLAN and ideally from the video VLAN. Isolation reduces broadcast exposure, contains a misbehaving device, and gives one place to apply QoS and policy. It is not a security perimeter; treat door-release as application-layer permission, not something the VLAN alone guarantees.

Terminals discover the voice VLAN via LLDP-MED or CDP advertised by the switch, or a DHCP option returning the VLAN ID. Pick one method per site and configure it consistently; mixing discovery across switch models causes 'the phone booted on the wrong VLAN' tickets.

LLDP-MED / CDP: the switch tells the device the voice VLAN; cleanest when all switches support it.
DHCP option: the device gets the VLAN ID from a scope option, useful on mixed networks.
Static tagging: set the VLAN ID on the device where discovery is unreliable.
Keep data separate: never share the voice VLAN with general PC traffic.

DSCP Marking: EF for Media, CS3 for Signalling

The DSCP field in the IP header signals latency sensitivity. Per RFC 4594, RTP media is marked EF, codepoint 46. SIP signalling - REGISTER, INVITE, BYE - is marked CS3 (24) or AF31; video that needs its own class is commonly AF41 (34).

The marking only helps if it survives every hop. The classic failure is a switch that rewrites or strips DSCP at a trunk, so the core never sees the EF the access switch set. Audit the trust boundary: decide which ports may set markings and ensure upstream links preserve the value end to end.

RTP media: DSCP EF (46) - highest priority of the three.
SIP signalling: DSCP CS3 (24) or AF31.
Video: DSCP AF41 (34) when video needs separation from voice.
End-to-end: verify the marking survives trunks, not just the access port.

Multicast Paging and Where It Belongs

All-call and zone paging often use multicast: one source sends a stream the switches replicate to subscribed ports. Without boundaries it floods every listening VLAN. Scope paging to the voice VLAN and use IGMP snooping so only ports with a subscribed endpoint receive the copy.

A subtle trap: some paging amplifiers and gateways expect multicast on a specific group address and port. Document the group and port per zone during planning, not commissioning, or you will lose an afternoon finding why the third-floor speaker is silent.

PoE Budget: Sum the Ports, Not the Nameplate

Every terminal, door station, and paging adapter draws power from the switch or an injector. The 802.3af and 802.3at standards define device classes, but the planning number is the switch's total PoE budget across all ports at once. A 24-port switch does not deliver full per-port power to all 24 simultaneously; the chassis budget is the ceiling.

Size against the worst case you actually run: every door station and terminal powered together during an emergency page, plus margin. If the math does not close, split the load across two switches or use local supplies on the building UPS.

Planning check: total PoE draw = sum of every device's class, against the switch's stated total budget with headroom - never the per-port number.

Trust Boundaries and a Verification Order

Decide explicitly where the network trusts DSCP. If you trust end devices, a misconfigured laptop could mark itself EF and starve real voice; if you trust nothing, you must re-mark at the edge. Most deployments trust the voice VLAN ports and re-mark there, then preserve upstream.

Verify in order: VLAN membership per port, DSCP at the access port, DSCP at the core, multicast scope, then a real call under load. A capture at the server shows whether EF arrived intact - if not, the trust boundary is where to look.

Frequently asked questions

Is a voice VLAN a security boundary for door access?: No. A voice VLAN isolates traffic and simplifies QoS, but door-release authorization is an application-layer permission handled by the SIP server and relay logic. Do not treat VLAN separation as the access control itself.
Which DSCP value should I use for SIP voice?: Mark RTP media EF (46) per RFC 4594, SIP signalling CS3 (24) or AF31, and video AF41 (34) when it needs its own class. The marking only helps if preserved across every hop to the server.
Why does my EF marking disappear at the core?: Usually the trunk or uplink is not trusting or is rewriting DSCP. Audit the trust boundary, confirm upstream links preserve the value end to end, then verify with a capture at the server.
How should I scope multicast paging?: Keep paging on the voice VLAN and enable IGMP snooping so only subscribed ports receive the stream. Document the multicast group address and port per zone during planning to avoid silent speakers.
How do I size the PoE budget correctly?: Compare the sum of every device's class against the switch's total PoE budget with headroom, not the per-port figure. If it does not close, split load across switches or use local supplies on the UPS.
Should the switch trust DSCP from end devices?: Most deployments trust the voice VLAN access ports and re-mark there, then preserve upstream. Trusting all devices lets a misconfigured host mark itself EF and starve real voice, so keep the boundary explicit.

Pair this with a migration plan from analog to SIP and, when devices sit behind NAT, the NAT traversal and RTP relay guide. See the FlySip product overview for server sizing context.