Subject: [MMUSIC] RTP packets in Draft-ietf-mmusic-rfc2326bis-16.txt

From: "Alvaro Fernandez" <[email-masked]>
Date: Sat, 23 Feb 2008 09:19:33 +0100

Hi

I know that when someone new in a forum asks something like this about a draft, usually the draft is OK and the new guy is wrong. But anyway here is the question:

RTSP 2.0

Draft-ietf-mmusic-rfc2326bis-16.txt

Page 197:   

"As an example, assume a clock frequency of 8000 Hz, a packetization   interval of 100 ms and an initial sequence number and timestamp of zero. "

...

 " The ensuing RTP data stream is depicted below:

      S -> C: RTP packet - seq = 0, rtptime = 0,    NPT time = 10s

      S -> C: RTP packet - seq = 1, rtptime = 800,  NPT time = 10.1s

      S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s

      S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s "

Without a 20 second PAUSE and 15 ms to process the PLAY request the next RTP packet should be:

S -> C: RTP packet - seq = 4, rtptime = 3200, NPT time = 10.4s

With a 20 second PAUSE and 15 ms to process the PLAY request the rpttime of the next RTP packet should be: 

20 seconds pause increase  rtptime in 20 x 8000 = 160000

15 ms process increases rtptime in 0.015 x 8000 = 120

rtptime = 3200 + 160000 + 120 = 163320 

But in the draft rtptime is 164400:

   The ensuing RTP data stream is depicted below:

      S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s

      S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s

      S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s

Why is it 164400 and not 163320?

Thanks and best regards

Alvaro

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

---

From: "Jaehwan Kim" <[email-masked]>
Date: Sun, 24 Feb 2008 14:15:17 +0900

Right. It looks wrong. But the key point is that rtp timestamp should
reflect realtime. Because of this, sometimes, we should be able to
expect 2440, not 2400, after 1600. The following example is for your
understanding. If it is still error, IMHO, it would be minor typo... BR
/Jaehwan

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alvaro Fernandez
Sent: Saturday, February 23, 2008 5:20 PM
To: [email-masked]
Subject: [MMUSIC] RTP packets in Draft-ietf-mmusic-rfc2326bis-16.txt

Hi

I know that when someone new in a forum asks something like this about a
draft, usually the draft is OK and the new guy is wrong. But anyway here
is the question:

RTSP 2.0

Page 197:   

"As an example, assume a clock frequency of 8000 Hz, a packetization
interval of 100 ms and an initial sequence number and timestamp of zero.
"

...

Without a 20 second PAUSE and 15 ms to process the PLAY request the next
RTP packet should be:

With a 20 second PAUSE and 15 ms to process the PLAY request the rpttime
of the next RTP packet should be: 

 

Thanks and best regards

Alvaro

---

From: "Alvaro Fernandez" <[email-masked]>
Date: Sun, 24 Feb 2008 09:34:14 +0100

Hi Jaehwan,

Thanks for your answer. You are right: the keypoint is the meaning of rpt timestamps.

I didn't understand rptime and the relation between NPT and rptime after reading RTSP 1.0 RFC, RTSP 2.0 draft, SDP RFC and RTP RFC.

I only understood rptime after reading the explanations in the book "RTP" from C. Perkins and another Cisco book.

I think there are some things in the draft that don't help understand rptime and its relation with NPT:

1. Page 197. What I explained before.

2. Page 196. There is an example how to avoid a RTP timestamp gap of 12.5 ms (100/8000) by sending a PLAY request with multiple ranges but the rptime values in the ensuing RTP data stream are the same 39200, 40100 (copy and paste error?)

3. Page 64. The first RTSP response with Range: npt=10-15, npt 13-20 and the second response with Range: npt=14-25 has the same rptime values in the RPT-Info header. But the text says the second PLAY is sent 4 seconds after the first PLAY. I don't understand why. Is it because the seq parameter?

4. In pages 196 and 197 it seems like if RTP packets include NPT information. I think it is to clarify the meaning of RTP packets, but a short comment would help.

I think clarifying this would help in a better understanding of rptime and its relation with NPT

Anyway I like books.

Best regards

Alvaro Fernandez

De: Jaehwan Kim [mailto:[email-masked]]
Enviado el: dom 24/02/2008 6:15
Para: Alvaro Fernandez; [email-masked]
Asunto: RE: [MMUSIC] RTP packets in Draft-ietf-mmusic-rfc2326bis-16.txt

Right. It looks wrong. But the key point is that rtp timestamp should reflect realtime. Because of this, sometimes, we should be able to expect 2440, not 2400, after 1600. The following example is for your understanding. If it is still error, IMHO, it would be minor typo... BR /Jaehwan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alvaro Fernandez
Sent: Saturday, February 23, 2008 5:20 PM
To: [email-masked]
Subject: [MMUSIC] RTP packets in Draft-ietf-mmusic-rfc2326bis-16.txt

Hi

RTSP 2.0

Page 197:   

...

 

Thanks and best regards

Alvaro