2026-06-03

RTCP CNAME and RTSP Audio/Video Sync Debugging: RTP Timestamps, Sender Reports, Lip Sync, and Track Drift

How to debug RTCP CNAME, RTP timestamp mapping, sender reports, audio/video synchronization, lip sync drift, and multi-track RTSP camera timing problems.

A camera stream may authenticate and play both tracks yet let video creep ahead of audio or introduce a stable lip-sync delay. Verify whether the RTP streams share an RTCP CNAME, whether each sender report maps its own RTP clock to NTP consistently, and whether drift grows before or after packet arrival. RTCP and RTP timing can prove a source-clock or synchronization inconsistency; player buffering and decode latency remain separate layers to measure.

RTSP Inspector is useful because this is a protocol timing problem. The important evidence is not only the decoded media. It is the relationship between RTP timestamps, RTCP Sender Reports, SSRC values, CNAME values, track clocks, and arrival timing.

Why RTP timestamps alone are not enough

RTP timestamps are relative to each media clock. A video track may use a 90 kHz clock. An audio track may use 8 kHz, 16 kHz, 44.1 kHz, or 48 kHz depending on codec and SDP.

That means this is not enough:

video RTP timestamp: 900000
audio RTP timestamp: 480000

Those values are not directly comparable unless each track is mapped to a shared reference clock.

What RTCP Sender Reports provide

RTCP Sender Reports can map RTP timestamps to wall-clock time. For sync analysis, this is critical evidence.

A useful report should show:

SSRC for the video stream.
SSRC for the audio stream.
RTP timestamp in each Sender Report.
NTP timestamp in each Sender Report.
Whether reports continue during the session.
Whether sender reports jump or reset.
Whether CNAME values associate related streams.

When RTCP Sender Reports are missing, delayed, or inconsistent, lip sync may depend on receiver guessing.

What CNAME is for

RTCP CNAME is used to associate RTP streams that belong to the same synchronization context. For example, a camera's audio RTP stream and video RTP stream should normally be linkable as related media from the same endpoint.

Failures include:

Audio and video use different CNAME values unexpectedly.
CNAME changes mid-session.
One track sends RTCP SDES and the other does not.
Gateway rewrites SSRC but not CNAME consistently.
RTCP is blocked by firewall or NAT.
Camera sends RTP but no RTCP at all.

If the receiver cannot associate the tracks, audio/video sync can be unstable.

Lip sync drift

Audio/video sync can be wrong immediately or drift over time.

Immediate offset suggests:

Wrong start timestamp mapping.
Missing initial sender report.
Buffering differences.
Camera encoder pipeline delay.
Audio track starts before video track.

Gradual drift suggests:

Wrong clock rate in SDP.
Inaccurate RTP timestamp increment.
Camera clock instability.
Missing or inconsistent RTCP reports.
Gateway resampling or transcoding errors.

Those are different fixes, so the article should separate them.

Wrong clock rate in SDP

An SDP line such as a=rtpmap:97 MPEG4-GENERIC/48000/2 tells the receiver how to interpret audio timestamps. If the camera sends timestamps as if the clock were 44100 but advertises 48000, audio will drift.

Video can have similar problems when the clock rate is wrong or timestamp increments do not match frame cadence.

Evidence:

SDP rtpmap clock rate.
RTP timestamp deltas.
Packet arrival deltas.
Frame duration.
Sender report mapping.
Drift amount over minutes.

RTSP Inspector can turn "audio gradually out of sync" into a measurable timestamp problem.

RTCP blocked by transport path

With UDP transport, RTP and RTCP may use adjacent ports. Firewalls and NAT rules sometimes allow RTP but block RTCP. The video may still appear, but quality reports and synchronization evidence disappear.

Symptoms:

RTP packets arrive.
RTCP Sender Reports never arrive.
Jitter/loss stats are unavailable.
Audio/video sync depends on client heuristics.
TCP interleaved transport behaves differently.

If TCP interleaved fixes sync, the issue may be RTCP reachability rather than codec decode.

Gateway and restreamer issues

RTSP proxies, NVRs, and cloud bridges may rewrite SSRC, regenerate timestamps, or relay RTCP incorrectly.

Problems include:

Video SSRC changes but CNAME stays stale.
Audio and video come from different upstream sessions.
Sender Reports map to proxy time for one track and camera time for another.
Audio is transcoded while video is passed through.
RTCP SDES is dropped.

Packet evidence is the only reliable way to identify this boundary.

Measure the sync fault before naming the cause

Record the symptom against time, rather than relying on “out of sync” alone. A fixed 180 ms offset after every new session and a 180 ms offset that becomes 600 ms after ten minutes imply different hypotheses. Sender Reports provide a mapping for each track, but arrival time, jitter buffer policy, and decoder pipeline delay still need to be kept separate.

Measured pattern	Evidence that supports it	Most careful interpretation
Same offset from the first decoded frames	Track start, first RTP timestamp, first Sender Report	Startup/buffering or initial mapping issue is plausible
Offset grows steadily over minutes	RTP timestamp deltas and repeated Sender Reports	Clock-rate, timestamp cadence, or resampling drift is plausible
Offset changes abruptly after a restart	SSRC/CNAME change and new Sender Report epoch	Source or gateway session boundary changed
Audio and video arrive but only one has RTCP	RTP trace plus missing SR/SDES for the other track	Receiver has incomplete synchronization evidence
UDP drifts but TCP interleaved does not	Same camera/profile with transport changed	Transport/reachability can be part of the fault, not proof of a codec issue

For each Sender Report, retain the NTP time, RTP timestamp, SSRC, CNAME when available, and capture arrival time. Compare changes within a track first. Only then compare the mapped audio and video timeline. Direct comparison of the raw RTP timestamp numbers remains invalid when their clock rates differ.

CNAME and SSRC continuity checks

A CNAME helps a receiver associate related RTP sources, but it is not a substitute for correct timestamps. Likewise, a stable SSRC does not prove that audio and video share one clock. Use both pieces of evidence with the SDP track definitions.

Trace condition	What it can show	Escalation note
Same CNAME and stable SSRCs on both tracks	The tracks claim one synchronization context	Continue to Sender Report mapping and clock-rate checks
Different CNAME values after a gateway change	Association may have been broken or rewritten	Preserve pre- and post-gateway SDES, not only player screenshots
SSRC changes with a fresh CNAME and new SR epoch	A new source session started	Measure sync after the reset; do not blend the timelines
RTP continues but SR/SDES stops	The media path is alive while RTCP evidence is incomplete	Check UDP RTCP routing, relay policy, or interleaving
One track has no SDP clock-rate mapping	A timestamp calculation cannot be trusted	Fix or obtain the session description before diagnosing drift

The RTP timestamp drift guide covers clock-rate evidence in more detail. For cases where RTCP disappears only on UDP, use the RTSP UDP and TCP interleaved guide to document the transport comparison.

QA workflow for an audio/video sync incident

Record one controlled symptom: fixed initial offset, gradual drift, or a discontinuity after a session event.
Save the SDP for every audio and video track, including payload type, codec, clock rate, and control URL.
Capture enough uninterrupted media and RTCP to measure the reported drift; a few seconds cannot establish a ten-minute rate error.
Extract at least two Sender Reports per available track and record SSRC, NTP, RTP timestamp, and CNAME/SDES presence.
Mark packet loss, SSRC changes, renegotiation, camera reboot, gateway restart, and transport changes on the same timeline.
Repeat the controlled comparison over TCP interleaving only if the camera supports it, keeping profile and client settings fixed.
Export redacted packet evidence and the measured offset/rate, not passwords, full camera addresses, or an unsupported claim that a player bug is proved.

Does matching CNAME prove perfect lip sync?

No. It associates synchronization context; it does not validate sender-report mapping, correct SDP clock rates, media timestamps, or player buffering behavior.

Can an RTCP Sender Report prove the decoder caused the delay?

No. It can show whether source timing is internally consistent at the captured protocol boundary. Rendering, audio output, and player buffering need separate measurement.

What can RTSP Inspector prove in this case?

It can preserve the observed SDP, RTP, RTCP, SSRC, CNAME, timestamp, and transport relationships and make the conclusion appropriately narrow: source timing mismatch, absent RTCP evidence, a session discontinuity, or no protocol-level inconsistency in the captured interval.

Debug checklist

Use this workflow:

Capture SDP for all audio and video tracks.
Record each track's payload type and clock rate.
Identify RTP SSRC values.
Capture RTCP Sender Reports.
Capture RTCP SDES CNAME values.
Compare audio and video synchronization context.
Measure RTP timestamp deltas.
Check whether drift is immediate or gradual.
Compare UDP and TCP interleaved behavior.
Preserve a long enough trace to measure drift.

Final diagnosis

RTSP audio/video sync problems require RTP and RTCP timing evidence. The key facts are clock rates, RTP timestamp deltas, RTCP Sender Reports, CNAME association, SSRC continuity, and whether RTCP reaches the receiver.

RTSP Inspector helps diagnose lip sync and track drift as protocol timing evidence rather than vague playback complaints.

How do you validate RTCP CNAME audio/video synchronization?

Map each negotiated media track to its RTP SSRC, RTP clock rate, RTCP Sender Reports, and SDES CNAME. Then choose a bounded interval that includes multiple Sender Reports for audio and video. For every report, retain NTP time, RTP timestamp, SSRC, capture time, and the CNAME association visible at that point. The shared CNAME groups synchronization sources, but it does not by itself prove a player used the mapping correctly.

Synchronization check	Required evidence	Failure boundary
Track mapping	SDP media section, payload/clock rate, SSRC	Wrong clock interpretation can mimic drift
Sender timing	NTP/RTP pairs from repeated SRs	Missing or inconsistent mapping needs sender review
Source grouping	SDES CNAME for both media sources	Different/missing CNAME complicates association
Continuity	SSRC changes, resets, packet gaps	A source transition may invalidate old timing state
Playback result	Measured offset and change over time	Constant offset differs from accumulating drift

Measure both initial offset and slope. A fixed 150 ms offset suggests a different class of problem than an offset that grows every minute. Compare UDP and TCP-interleaved runs only with the same camera profile, clock duration, and receiver. Transport success does not correct a wrong RTP clock rate or a client that ignores Sender Reports.

Acceptance is a repeated run where audio and video remain within the product’s documented tolerance and no stale mapping survives an SSRC change. Preserve the timing table in an RTSP Inspector report and use the RTP timestamp-drift guide when the offset grows rather than remaining constant.

Retain receiver version and buffering policy with the test. If two receivers produce different offsets from the same valid sender reports, the comparison should identify a client timing boundary instead of incorrectly assigning the whole symptom to the camera.

Archive both measured offset series under the same case clock and profile.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: