CallMeter Docs

Advanced Track Settings

Configure DSCP/QoS marking for traffic prioritization and deferred track negotiation for mid-call media activation on a per-track basis.

Each media track in a group has an Advanced section accessible by clicking the caret next to "Advanced" below the codec selection. These settings control network-level traffic prioritization and mid-call media negotiation behavior.

DSCP / QoS Marking

DSCP (Differentiated Services Code Point) marking tags RTP packets with a priority value so that network equipment (routers, switches, firewalls) can prioritize voice and video traffic over best-effort data. This is essential for enterprise networks with QoS policies.

How It Works

When you set a DSCP value on a track, every RTP and RTCP packet sent by that track's endpoint is marked with the specified code point at the IP layer. Network devices that honor DSCP values will then queue and forward these packets according to their configured QoS policies.

Presets

CallMeter provides presets based on RFC 4594 (Configuration Guidelines for DiffServ Service Classes):

PresetDSCP ValuePer-Hop BehaviorRecommended For
Voice (EF / 46)46Expedited ForwardingAudio RTP streams
Video (AF41 / 34)34Assured Forwarding 41Video RTP streams
Signaling (CS3 / 24)24Class Selector 3SIP signaling (future)
Low Priority (CS1 / 8)8Class Selector 1Background/scavenger traffic
Default (Best Effort)NoneBest Effort (CS0)No marking applied
Custom0-63ManualAny custom DSCP value

Default Values

When creating a new test, CallMeter automatically sets recommended DSCP values:

  • Audio tracks: EF / 46 (Expedited Forwarding) -- the standard for voice traffic
  • Video tracks: AF41 / 34 (Assured Forwarding) -- the standard for video conferencing

When editing an existing test, the previously saved values are preserved.

Network path requirements

DSCP marking is applied at the source (the worker endpoint). For the marking to have effect, every network hop between the worker and your SIP infrastructure must honor DSCP values. Docker bridge networking and many cloud VPC boundaries strip DSCP markings. For accurate QoS testing, use --network=host on Docker workers or deploy workers directly on the network path you want to test.

Verifying DSCP Marking

To confirm DSCP markings are being applied and preserved:

  1. Run a short test (30 seconds, 2 endpoints) with DSCP set
  2. Capture packets on the worker or SIP server using tcpdump or Wireshark
  3. Inspect the IP header TOS byte: TOS = DSCP << 2 (e.g., EF/46 = TOS 0xB8)
  4. If TOS is 0x00 at the destination, a network hop is stripping the marking

Deferred Track Negotiation

Deferred track negotiation controls when a media track is negotiated and activated during the call lifecycle. This is used for advanced enterprise scenarios like content sharing activation, mid-call video escalation, and SBC/PBX interoperability testing.

Negotiate at Call Start

Default: Enabled (checked)

When enabled, the track is included in the initial SDP offer with a real port and codec information. The remote endpoint sees and negotiates this track during call setup.

When disabled, the track is included in the initial SDP offer with port 0, signaling that this media line exists but is not active. The track can later be negotiated mid-call via a scenario action of type Negotiate Track.

Scenario action required

Disabling "Negotiate at call start" means this track will not carry any media unless a Negotiate Track scenario action is configured to activate it during the call. Without the corresponding action, the track remains at port 0 for the entire call.

Start Sending at Establishment

Default: Enabled (checked)

This setting is only available when "Negotiate at call start" is enabled.

When enabled, the track begins sending media as soon as the call is established (after the SIP ACK). This is the standard behavior for most VoIP calls.

When disabled, the track is negotiated during call setup (included in SDP with a real port) but marked as a=inactive. The endpoint allocates ports and maintains NAT bindings via RTP keepalive packets, but does not send actual media. The track can later be activated mid-call via a scenario action of type Start Sending Track.

This simulates scenarios where a media track is negotiated upfront but activated later -- for example, a video track that only starts sending when the user clicks "Share Video" in a conferencing application.

Track Lifecycle Summary

Negotiate at StartSend at EstablishmentInitial SDPMedia BehaviorActivation
EnabledEnabledReal port, a=sendrecvFull media from call startAlready active
EnabledDisabledReal port, a=inactivePorts allocated, RTP keepalive sentStart Sending Track action
DisabledN/APort 0, codec info onlyNothing allocatedNegotiate Track action

RTP Keepalive for Inactive Tracks

When a track is negotiated but not sending (Negotiate=on, Send=off), the endpoint sends:

  • Empty RTP packets every 15 seconds (valid header, same SSRC, incrementing sequence, zero payload)
  • RTCP Sender Reports every 5 seconds

This prevents NAT/firewall bindings from timing out while the track is inactive, ensuring mid-call activation succeeds without connectivity issues.

Combining Settings

Example: Video Escalation

Configure a test where audio starts immediately but video activates 30 seconds into the call:

  1. Audio Track 1: Default settings (negotiate=on, send=on, DSCP=EF/46)
  2. Video Track 2: Negotiate=on, Send=off, DSCP=AF41/34
  3. Scenario Action: At 30 seconds, Start Sending Track targeting Video Track 2

Example: Deferred Content Sharing

Simulate a conferencing scenario where a content-sharing track is negotiated mid-call when the remote puts you on hold:

  1. Audio Track 1: Default settings
  2. Video Track 2: Negotiate=off (port 0 in initial SDP)
  3. Scenario Action: On event Hold Received, Negotiate Track targeting Video Track 2

Next Steps

On this page