RTSP Range Header and npt=now: Debugging Live Playback Start Time, Resume, and Camera Seek Errors

A stream can connect yet start late, resume from the wrong point, or fail only when PLAY carries an RTSP Range such as npt=now-. Compare the requested start position with the server's Range/RTP-Info response and the first RTP timestamps to determine whether the client asked for an unsupported seek or the server mapped live time incorrectly. This evidence ties control-plane playback timing to the media start; it does not make RTP timestamps equivalent to wall-clock or recorder-file time.

The Range header is a control-layer timing instruction. It is not the same as RTP timestamp, wall-clock time, or recorder file timestamp. RTSP Inspector is useful because this problem sits in the RTSP method sequence and must be compared with RTP/RTCP media timing after PLAY.

What Range means in RTSP

During PLAY, a client can send:

PLAY rtsp://camera/stream RTSP/1.0
Session: 12345678
Range: npt=now-

For a live stream, npt=now- usually means "start playing from the current live point." Some clients omit the Range header. Some send npt=0.000-. Some NVRs use clock-based ranges for recorded playback.

Different RTSP servers vary in how strictly they interpret these values.

Live stream vs recorded stream

Live streams and recorded streams have different expectations:

• Live camera stream: current live media point.
• NVR playback: requested recording time range.
• Media file: offset into stored content.
• Replay server: session-specific timeline.

A Range value that is valid for a file may be invalid for a live camera. A Range value that works for one NVR may not work for another vendor.

Common symptoms

Range-related problems include:

• PLAY fails only when Range is present.
• Stream starts but with long delay.
• Resume after pause fails.
• Client receives old buffered video.
• NVR playback starts at wrong time.
• RTP timestamps jump after resume.
• Camera ignores Range but returns 200 OK.
• Server returns invalid Range response.

The player may show this as buffering or black video, but the root evidence is in PLAY.

Server response matters

After PLAY, the server may return a Range header:

RTSP/1.0 200 OK
Range: npt=0.000-
RTP-Info: url=...;seq=...;rtptime=...

RTP-Info can map the control response to initial RTP sequence and timestamp values. If RTP-Info is missing, wrong, or inconsistent, clients may struggle to align media timing.

Inspect:

• Range sent by client.
• Range returned by server.
• RTP-Info sequence and rtptime.
• First RTP sequence after PLAY.
• First RTP timestamp after PLAY.

Pause and resume

Some cameras support PAUSE; others do not support it well for live streams. A client may pause and later send PLAY with a Range value that the server treats as a seek. The server may reject it or restart the stream.

If resume breaks, compare the first PLAY with the resume PLAY.

Debug checklist

Use this process:

1. Capture PLAY request and response.
2. Check whether client sends Range.
3. Record exact value: npt=now-, npt=0-, clock range, or absent.
4. Check server response Range and RTP-Info.
5. Compare first RTP sequence/timestamp after PLAY.
6. Test with and without Range if the client allows it.
7. Test live stream and recorded playback separately.
8. Check pause/resume method sequence.
9. Avoid blaming RTP until PLAY timing is understood.
10. Preserve the whole RTSP control flow for vendor diagnosis.

Final diagnosis

RTSP Range problems are playback-control timing problems. The stream may authenticate and set up correctly, but PLAY can still start from the wrong point or fail because the server does not accept the requested range.

RTSP Inspector helps by showing Range, RTP-Info, and the first RTP packets together, so live playback start-time issues can be diagnosed from protocol evidence.