Subject: Re: [MMUSIC] RTSP: Updated text in RTP-Info

From: Magnus Westerlund <[email-masked]>
Date: Tue, 22 Feb 2005 17:06:15 +0100

Hi Thomas,

Thanks for the comments and corrections.

Thomas Zeng wrote:
> [tz] The last two paragraphes, along with the example below, seem to fit better in the section: B.1.8 Maintaining NPT synchronization with RTP timestamps.
> 

I don't know, people seem to misinterpret this frequently, and having an 
motivation and example near the specification text will hopefully make 
it so much clearer. However I haven't review the new text in light of 
B.1.8.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Thomas Zeng" <[email-masked]>
Date: Mon, 21 Feb 2005 16:48:22 -0800

Magnus:

Comments, mostly editorial, are inlined.

Best regards,
-thomas

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Magnus Westerlund
Sent: Monday, February 21, 2005 2:01 AM
To: mmusic (E-mail)
Subject: [MMUSIC] RTSP: Updated text in RTP-Info

Hi,

In November I received some comments on the RTP-Info text that it is 
often misinterpreted regarding what values should be put into the 
"rtptime" parameter. In trying to address this and also the requirement 
to include the different parameters I have tried to rephrase the 
sentence. Please provide comments.

Cheers

Magnus

In Section 14.38 the following text is proposed.

    The header can carry the following parameters:

         url: Indicates the stream URI which for which the following RTP
[tz]                             change     "which for which" ===> "to which"
              parameters correspond, this URI MUST be the same used in
              the SETUP request for this media stream. Any relative URI
              SHALL use the Request-URI as base URI. This parameter SHALL
              be present.

         seq: Indicates the sequence number of the first packet of the
              stream that is the direct result of the PLAY request. This allows
	                       ^^^ [tz] add             ^^^^  [tz] add
              clients to gracefully deal with packets when seeking. The
              client uses this value to differentiate packets that
              originated before the seek from packets that originated
              after the seek. Note that a client may not receive the
              packet with the expressed sequence number, and instead
              packets with a higher sequence number, due to packet loss
              or reordering. This parameter is RECOMMENDED to be present.

         rtptime: SHALL indicate the RTP timestamp value corresponding to
              the start time value in the Range response header, or if the Range header
                                                                 [tz]  ^^^^^^^^^^^^^^^^  [tz] add
              not explicitly given, the implied start point. The client
                      [tz]        ^ [tz] add
              uses this value to calculate the mapping of RTP time to NPT
              or other media timescale. This parameter SHOULD be present
              to ensure inter-media synchronization is achieved. There
              exist no requirement that any received RTP packet will have
              the same RTP timestamp value as the one in the parameter
              used to establish synchronization.

         A mapping from RTP timestamps to NTP timestamps (wall
         clock) is available via RTCP. However, this information is
         not sufficient to generate a mapping from RTP timestamps to
         media clock time (NPT, etc.). Furthermore, in order to
         ensure that this information is available at the necessary
         time (immediately at startup or after a seek), and that it
         is delivered reliably, this mapping is placed in the RTSP
         control channel.

    In order to compensate for drift for long, uninterrupted
    presentations, RTSP clients should additionally map NPT to NTP, using
    initial RTCP sender reports to do the mapping, and later reports to
    check drift against the mapping.
[tz] The last two paragraphes, along with the example below, seem to fit better in the section: B.1.8 Maintaining NPT synchronization with RTP timestamps.

    Example:

    Range:npt=3.25-15
    RTP-Info:url=rtsp://example.com/foo/audio;seq=45102;rtptime=12345678,
             url=rtsp://example.com/foo/video;seq=30211;rtptime=29567112

    Lets assume that audio uses a 16kHz RTP timestamp clock and Video
    a 90kHz RTP timestamp clock. Then the media synchronization is
    depicted in the following way.

    NPT    3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
    Audio               PA A
    Video                  V    PV

    X: NPT time value = 3.25, from Range header.
    A: RTP timestamp value for Audio from RTP-Info header (12345678).
    V: RTP timestamp value for Video from RTP-Info header (29567112).
    PA: RTP audio packet carrying an RTP timestamp of 12344878. Which
        corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
    PV: RTP video packet carrying an RTP timestamp of 29573412. Which
        corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32

-- 

Magnus Westerlund