Summary

IPMX devices mark PTP as EF (46), video as AF42 (36) and audio as AF41 (34) by default. Everything else that belongs to a media stream inherits that stream's marking.

DSCP is a 6-bit field in every IP packet header (RFC 2474). Switches read it to decide which queue a packet goes into and how early it gets dropped under congestion. IPMX makes DiffServ marking mandatory in VSF TR-10-9 section 16, and certification testing (TR-10 TP-1 section 13) checks the values on the wire.

The marking alone does nothing. The switch must be configured to trust DSCP and map these values to the right queues.

Default DSCP values

Three values cover all IPMX media and timing traffic. These are defaults: devices should let the user change them, but TR-10-9 only says "should", so not every device will.

Audio and video share the AF4 class. The second digit is drop precedence: audio (AF41) is dropped last, video (AF42) before it. On a congested link the switch sheds video before audio.

The PTP and audio values match AES67 section 6.2, so IPMX and AES67 devices mark identically out of the box.

Ancillary data is grouped with video, not audio, even though it is a separate RTP stream.

Inherited markings

Some traffic has no value of its own. It must carry the same DSCP as the RTP stream it belongs to.

These are the ones that fail in practice. RTCP and HKEP are often generated by a different software process than the media engine, and that process sends with DSCP 0 unless told otherwise.

The result is a stream that looks fine in a quick capture but fails certification, or loses its RTCP timing info under load. Check each one separately.

What the spec does not cover

TR-10-9 section 16 mandates no marking for the following (yet). Expect them at DSCP 0 (best effort).

• Privacy Encryption Protocol (TR-10-13)
• USB extension (TR-10-14)
• NMOS control traffic: IS-04 registration, IS-05 connection management, IS-11, DNS-SD
• Device management: web UI, SSH, SNMP

Best effort is usually fine for control traffic on a properly sized network. USB is the exception worth watching: keyboard and mouse over a congested link feels laggy long before video breaks.

Sharing a network with Dante or Q-LAN

IPMX, Dante and Q-LAN use different defaults. On a shared network this puts one system's audio in the same queue as another system's clock.

The conflict to watch is Dante audio at 46, which lands in the same strict-priority queue as IPMX PTP. A busy Dante system can then add jitter to IPMX clock sync.

Options, in order of preference:

1. Change the IPMX devices' DSCP values to fit the site's existing QoS plan, if they expose the setting.
2. Separate the systems by VLAN and apply per-VLAN trust or remarking on the switch.
3. Remark Dante traffic at the ingress port to a lower class.

Q-LAN aligns with IPMX for PTP and audio, so it usually coexists without changes. Q-LAN video at 26 simply sits below IPMX video.

Switch configuration

A typical IPMX switch config trusts DSCP on media ports and maps the three values to separate queues. Exact commands vary by vendor. The intent is below.

• Trust DSCP on every port facing an IPMX device. Many switches default to trusting CoS or nothing, which silently flattens all traffic to one queue.
• Keep strict priority for PTP only. PTP is low bandwidth, so a strict queue cannot starve anything. Putting media in a strict queue can.
• Put audio and video in separate queues where possible. If the switch has only one AF4 queue, make sure it uses weighted drop (WRED) so AF41 survives before AF42.
• Check uplinks too. Trust and queue mapping must apply on inter-switch links, not just edge ports.

If the network carries only IPMX and is not oversubscribed, QoS will rarely be exercised. It matters most on shared or converged networks and on uplinks that carry many streams.

Verifying markings

Capture on a mirrored port and filter by DSCP in Wireshark. Each IPMX flow should show exactly one value.

Symptoms that point to a QoS problem:

• PTP offset or path delay jumps when other traffic ramps up.
• Video glitches or freezes on a busy uplink while audio stays clean. That is AF42 being dropped first, as designed. The link is oversubscribed.
• Audio drops on a network shared with Dante. Check whether both systems land in the same queue.
• RTCP-dependent features (stream info, alignment) behave erratically under load while media looks fine. RTCP is probably unmarked.

References

• VSF TR-10-9-v2:2025, Requirements for System Environments and Device Behavior, section 16 (Quality of service)
• IPMX Product Qualification and Certification Requirements v1.1, section 4.1.7
• VSF Technical Recommendations (TR-10 series)
• Q-SYS Help: Design Properties (Dante and Q-LAN defaults)
• RFC 2474 (DiffServ), RFC 2597 (AF), RFC 3246 (EF), AES67 section 6.2