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

RTSP PLAY looks simple until a camera, NVR, or media server interprets start time differently from the client. A live stream may start late, restart from an unexpected point, fail after pause/resume, or return an error when the client sends a Range header. Users search for "RTSP Range npt now", "RTSP PLAY start time", "RTSP live stream wrong start", "RTSP seek not working", and "camera resume RTSP stream" when the stream connects but playback timing behaves incorrectly.

The Range header is a control-layer timing instruction. It is not the same as RTP timestamp, wall-clock time, or recorder file timestamp. RtspInspector 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.

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