Subject: Re: [AVT] [Fwd: I-D Action:draft-petithuguenin-avt-multiple-clock-rates-00.txt]

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 05 Oct 2009 09:19:55 -0700

It seems that there was some interest at the time to have this problem fixed,
but I didn't receive any comment or suggestion since I published this I-D.  At a
minimum I would be interested in documenting what existing RTP implementations
are doing in a multiple clock rate scenario, especially on the sender side.

Thanks.

Marc Petit-Huguenin wrote:
> As discussed previously, here is an very preliminary version of an I-D about
> multiple clock rates.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> Subject:
> I-D Action:draft-petithuguenin-avt-multiple-clock-rates-00.txt
> From:
> [email-masked]
> Date:
> Wed, 30 Sep 2009 05:00:02 -0700 (PDT)
> To:
> [email-masked]
> 
> To:
> [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Support for multiple clock rates in an RTP session
> 	Author(s)       : M. Petit-Huguenin
> 	Filename        : draft-petithuguenin-avt-multiple-clock-rates-00.txt
> 	Pages           : 7
> 	Date            : 2009-09-30
> 
> The usage of multiple clock rates in an RTP session is currently
> underspecified.  This document lists multiple ways to fix this
> problem and is meant as a support for discussion.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-petithuguenin-avt-multiple-clock-rates-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 08 Oct 2009 08:55:57 -0700

Hi Jossen,

Jochen Issing wrote:
> Hi Marc,
> 
> sorry for not having responded to your I-D. I read it and found it a
> good basis for further discussion. Anyhow, I could agree with the
> approach of letting the payload specifications decide, how timestamps
> and timescales are interpreted. Anyhow, the timestamps might no longer
> be monotonically increasing and thus breaking RFC3550?

The way I understand how it would work for multiple rates in the same SSRC is
that the timestamp would always increase.  Let's say that there is two payload
types, 96 for a clock rate of 8000 and 97 for a clock rate of 16000.  With
packets each 20 milliseconds long, a packet with pt=96 would increase the
timestamp by 160 and a packet with pt=97 would increase it by 320.  So we would
have the following sequence (without the timestamp random offset):

PT  timestamp
96          0
96        160
97        320
97        640
96        960
96       1120

> 
> In our implementation, we do not support different timescales with the
> same payload type. For our adaptative RTP streaming, we are using a
> self-derived non-public payload format.

Thanks.

---

From: Colin Perkins <[email-masked]>
Date: Thu, 15 Oct 2009 11:57:06 +0100

Marc,

On 5 Oct 2009, at 17:19, Marc Petit-Huguenin wrote:
> It seems that there was some interest at the time to have this  
> problem fixed, but I didn't receive any comment or suggestion since  
> I published this I-D.  At a minimum I would be interested in  
> documenting what existing RTP implementations are doing in a  
> multiple clock rate scenario, especially on the sender side.

Looks like a reasonable summary of the issues.

What's your recommendation for preferred sender behaviour? I'm leaning  
towards requiring that the SSRC changes if the timestamp rate changes,  
since that seems to have the least corner cases with RTCP behaviour  
and synchronisation, and the backwards compatibility issues don't seem  
that serious.

It might be possible to eliminate the lip-synchronisation delay if the  
sender were to generate a compound RTCP packet containing two SRs, one  
for each SSRC, at the change-over, with each SR containing a mapping  
of its RTP timestamp to the same NTP time.

-- 
Colin Perkins
http://csperkins.org/

---

From: David R Oran <[email-masked]>
Date: Thu, 15 Oct 2009 07:59:26 -0400

On Oct 15, 2009, at 6:57 AM, Colin Perkins wrote:

> What's your recommendation for preferred sender behaviour? I'm  
> leaning towards requiring that the SSRC changes if the timestamp  
> rate changes, since that seems to have the least corner cases with  
> RTCP behaviour and synchronisation, and the backwards compatibility  
> issues don't seem that serious.
>
That strikes me as the best approach as well.

> It might be possible to eliminate the lip-synchronisation delay if  
> the sender were to generate a compound RTCP packet containing two  
> SRs, one for each SSRC, at the change-over, with each SR containing  
> a mapping of its RTP timestamp to the same NTP time.
>
Yup. Good idea.

> -- 
> Colin Perkins
> http://csperkins.org/
>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: "Ali C. Begen (abegen)" <[email-masked]>
Date: Thu, 15 Oct 2009 08:32:28 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Colin Perkins
> Sent: Thursday, October 15, 2009 6:57 AM
> To: Marc Petit-Huguenin
> Cc: [email-masked]
> Subject: Re: [AVT] [Fwd:I-D Action:draft-petithuguenin-avt-multiple-clock-rates-00.txt]
> 
> Marc,
> 

I favor this approach as well. That has been my recommendation for some time.

-acbegen

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 15 Oct 2009 08:51:39 -0700

Hi Colin,

Colin Perkins wrote:
>> It seems that there was some interest at the time to have this problem
>> fixed, but I didn't receive any comment or suggestion since I
>> published this I-D.  At a minimum I would be interested in documenting
>> what existing RTP implementations are doing in a multiple clock rate
>> scenario, especially on the sender side.
> 
> 
> since that seems to have the least corner cases with RTCP behaviour and
> synchronisation, and the backwards compatibility issues don't seem that
> serious.

Yes, it seems that this should be the preferred behavior, so I will update
section 3.4 in the next version.

> for each SSRC, at the change-over, with each SR containing a mapping of
> its RTP timestamp to the same NTP time.

That looks like a good solution to this problem, excepted that my understanding
of RFC 3550 is that the format of a compound RTCP packet is this:

compound = [encryption-prefix] ( SR | RR ) *RR 1*SDES *(APP | other) *BYE

Do you mean that in fact the format of a compound RTCP packet is something like
this? :

compound = [encryption-prefix] ( SR | RR ) *RR 1*SDES *(APP | SR | other) *BYE

Thanks.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 24 Oct 2009 13:00:23 -0700

Responding to myself, see below.

> have the following sequence (without the timestamp random offset):

It seems that there is problems with what I said above.  Nobody protested and it
seems to be in line with what Colin Perkins said, so there is a need for
clarification here.

But first of all let me state that I do not try to say that an RTP sender should
use multiple clock rates in the same SSRC as the current consensus is that
different SSRC should be used when the clock rate change.  This discussion is
about what an RTP receiver should do when an RTP sender still use multiple clock
rates in the same SSRC, in the spirit of the "be liberal in what you accept"
part of the IETF motto.

The timestamp sequence above uses in fact the following formula for each packet:

timestamp = previous_timestamp + (current_capture_time - previous_capture_time)
* previous_clock_rate

The problem with this is that the jitter calculation on the receiving side does
not work during the transition between two clock rates:

Capture	Clock	RTP	Arrival	Transit	Jitter	Average
time	rate	ts	time			jitter
0	8000	0	0.1	800	N/A
0.02	8000	160	0.12	800	0	0
0.04	8000	320	0.14	800	0	0
0.06	8000	480	0.16	800	0	0
0.08	16000	800	0.18	2080	480	30
0.1	16000	1120	0.2	2080	0	28
0.12	16000	1440	0.22	2080	0	26
0.14	8000	1600	0.24	320	720	70
0.16	8000	1760	0.26	320	0	65

(The capture and arrival time are in seconds, starting at the beginning of the
capture of the first packet; clock rate is in Hz; the RTP timestamp [RTP ts]
does not include the random offset; the transit, jitter and average jitter use
the clock rate in the same line as unit)

Having the jitter work in this case means that the formula in RFC 3550 needs to
be modified.

An alternate way of generating the RTP timestamps is to use the following formula:

timestamp = capture_time * clock_rate

In this case, the jitter formula in RFC 3550 works without modification:

Capture	Clock	RTP	Arrival	Transit	Jitter	Average
time	rate	ts	time			jitter
0	8000	0	0.1	800	N/A
0.02	8000	160	0.12	800	0	0
0.04	8000	320	0.14	800	0	0
0.06	8000	480	0.16	800	0	0
0.08	16000	1280	0.18	1600	0	0
0.1	16000	1600	0.2	1600	0	0
0.12	16000	1920	0.22	1600	0	0
0.14	16000	2240	0.24	1600	0	0
0.16	16000	2560	0.26	1600	0	0
0.14	8000	1120	0.24	800	0	0
0.16	8000	1280	0.26	800	0	0

(The spreadsheet used to generate this tables is available[1])

It is true that with this formula the RTP timestamp no longer increments
monotonically but I think that this is still conform to RFC 3550, as it says
that "[t]he sampling instant MUST be derived from a clock that increments
monotonically[...]".  It is the clock that increments monotonically, not the RTP
timestamp.

So my question to the WG is, which of the two methods above have been
implemented, and so which one (perhaps both, although I am not sure if it will
be possible to discover which one dynamically) should an RTP receiver use?

Thanks.

[1]
http://spreadsheets.google.com/ccc?key=0AndnqRvudSVbdHJhbVF4Sk5MRDEyaHhhc3M4TDRsaHc&hl=en