Subject: [AVT] Question on RTP timestamp unit in an RTP session

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 25 Sep 2009 14:52:23 -0700

RFC 3550/3551 does not seems to prohibit using different codecs with different
clock rates on the same RTP session, so this SDP fragment seems to be valid:

m=audio 54874 RTP/AVP 96 0
a=rtpmap:96 PCMU-WB/16000
a=rtpmap:0 PCMU/8000

My understanding is that the RTP sender could choose to switch between the two
payloads at any time and so the clock rate used for the RTP timestamp in the RTP
packets would change depending on the payload type.

My question is about the associated RTCP packets.  Which clock rate must be used
for fields like RTP timestamp in a sender report or interarrival jitter in a
receiver report?

Thanks.

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

---

From: Colin Perkins <[email-masked]>
Date: Sat, 26 Sep 2009 09:59:09 +0100

On 25 Sep 2009, at 22:52, Marc Petit-Huguenin wrote:
> RFC 3550/3551 does not seems to prohibit using different codecs with  
> different clock rates on the same RTP session, so this SDP fragment  
> seems to be valid:
>
> My understanding is that the RTP sender could choose to switch  
> between the two payloads at any time and so the clock rate used for  
> the RTP timestamp in the RTP packets would change depending on the  
> payload type.

That was my interpretation also.

> My question is about the associated RTCP packets.  Which clock rate  
> must be used for fields like RTP timestamp in a sender report or  
> interarrival jitter in a receiver report?

It's not well specified. My implementation uses the media clock in use  
at the instant it sends the RTCP packet. This is easy to implement,  
but it's not ideal when it comes to interpreting the data.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 26 Sep 2009 07:54:35 -0700

Colin Perkins wrote:
>> My understanding is that the RTP sender could choose to switch between
>> the two payloads at any time and so the clock rate used for the RTP
>> timestamp in the RTP packets would change depending on the payload type.
> 
> at the instant it sends the RTCP packet. This is easy to implement, but
> it's not ideal when it comes to interpreting the data.

What about always using the highest clock rate for the RTCP data?  Wouldn't that
be a better choice for a new RTP implementation that does not have to worry
about interoperability?

---

From: Colin Perkins <[email-masked]>
Date: Sat, 26 Sep 2009 16:53:35 +0100

On 26 Sep 2009, at 15:54, Marc Petit-Huguenin wrote:
>>> RFC 3550/3551 does not seems to prohibit using different codecs  
>>> with different clock rates on the same RTP session, so this SDP  
>>> fragment seems to be valid:
>>>
>>> between the two payloads at any time and so the clock rate used  
>>> for the RTP timestamp in the RTP packets would change depending on  
>>> the payload type.
>>
>> It's not well specified. My implementation uses the media clock in  
>> use at the instant it sends the RTCP packet. This is easy to  
>> implement, but it's not ideal when it comes to interpreting the data.
>
> What about always using the highest clock rate for the RTCP data?   
> Wouldn't that be a better choice for a new RTP implementation that  
> does not have to worry about interoperability?

That runs into problems with older implementations, and if the clock  
rates are not integer multiples of each other.

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 26 Sep 2009 09:17:56 -0700

> rates are not integer multiples of each other.

Right.

With the deployment of so called HD codecs in VoIP, can't this
underspecification become an issue, at least for the few implementations that
bother managing congestion with RTCP, and so be worth some kind of clarification
from the WG?

---

From: Colin Perkins <[email-masked]>
Date: Sat, 26 Sep 2009 18:03:16 +0100

On 26 Sep 2009, at 17:17, Marc Petit-Huguenin wrote:
>>>>> for the RTP timestamp in the RTP packets would change depending  
>>>>> on the payload type.
>>>>
>>>>> My question is about the associated RTCP packets.  Which clock  
>>>>> rate must be used for fields like RTP timestamp in a sender  
>>>>> report or interarrival jitter in a receiver report?
>>>>
>>>> It's not well specified. My implementation uses the media clock  
>>>> in use at the instant it sends the RTCP packet. This is easy to  
> underspecification become an issue, at least for the few  
> implementations that bother managing congestion with RTCP, and so be  
> worth some kind of clarification from the WG?

Sure, that'd be useful. I don't have the cycles to contribute to a  
draft, but maybe you want to write something?

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 26 Sep 2009 10:15:38 -0700

Colin Perkins wrote:
>>>>>> rate must be used for fields like RTP timestamp in a sender report
>>>>>> or interarrival jitter in a receiver report?
>>>>>

OK, I will.

Thanks.

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Sun, 27 Sep 2009 13:00:43 -0400

Hi folks,

Is there a case where an implementation today is using multiple clock
rates for the same SSRC? I would have thought that this is not entirely
legal.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Colin Perkins
> Sent: Saturday, September 26, 2009 4:59 AM
> To: Marc Petit-Huguenin
> Cc: [email-masked]
> Subject: Re: [AVT] Question on RTP timestamp unit in an RTP session
> 
between
> It's not well specified. My implementation uses the media clock in use
at the
> instant it sends the RTCP packet. This is easy to implement, but it's
not ideal
> when it comes to interpreting the data.
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 27 Sep 2009 10:13:09 -0700

Jochen Issing wrote:
> Hi Marc,
> 
> On 26.09.2009, at 19:15, Marc Petit-Huguenin wrote:
> 
>> Colin Perkins wrote:
> As far as I understand the spec, the RTCP report time stamps need to
> relate directly to the RTP time stamps, which must be based on the
> current used timescale (specified by payload type).
> 
> Hence, my implementation uses a offset calculation, meaning that the
> time stamps are monotonically increasing, but (depending on the payload
> type) with a differing increment. Hence, the actual playout time can not
> be calculated using something like:
> (current_timestamp - start_timestamp) / timescale
> but must be managed separately (by remembering switching times and the
> related playout times)...
> 
> To my understanding, the RTCP  RTP and NTP time stamps shall map sample
> times to system times only and according to Henning Schulzrinne, the
> issue is transient - this was at least the answer I got from him.
> 
> I am completely unhappy with the solution either and hence would like to
> offer my help in this case.

Thanks for the help offer.  I am preparing an I-D that explains the problems and
lists various alternative solutions, with pros and cons.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sun, 27 Sep 2009 10:36:44 -0700

> rates for the same SSRC? I would have thought that this is not entirely

This is what RFC 3550 section 5.2 would suggest:

"Interleaving packets with different RTP media types but using the same SSRC
would introduce several problems:

[...]

   2. An SSRC is defined to identify a single timing and sequence number
      space.  Interleaving multiple payload types would require
      different timing spaces if the media clock rates differ and would
      require different sequence number spaces to tell which payload
      type suffered packet loss.

   3. The RTCP sender and receiver reports (see Section 6.4) can only
      describe one timing and sequence number space per SSRC and do not
      carry a payload type field."

Using a different SSRC for each clock rate seems the sensible thing to do (and
was suggested offline), but I cannot find it written anywhere and anyway it
seems that there is implementations out there that made other assumptions (see
comments by Colin Perkins and Jochen Issing), so I think that there is a need
for a document that clearly states what need to be done in this case, and how to
inter operate with this implementations.

When trying to collect the "state of the art" on this subject, I found that a
very similar effort was proposed in an IETF meeting:

http://www.ietf.org/proceedings/61/slides/avt-8.pdf
http://www.ietf.org/proceedings/61/slides/avt-9.pdf

The minutes show clearly that the proposal was rejected:

"1) Only support codecs with one sample rate. This makes for easy backwards
compatibility, but won't support certain codecs.

2) Mandate a common clock rate for all RTP codecs as described in
draft-ietf-avt-variable-rate-audio-00.txt. Stephan Wenger gave an outline of
this (the "uRTR" approach).

3) Allow each codec to specify its own definition for the RTP timestamp and
signaling

4) Do something else?

[...]

The group took a "hum" on the preferred outcome. Option 3 got the majority.
Options 1 and 4 got nothing, option 2 very little. Colin Perkins wrapped up the
session by stating that it was clear option 3 was the consensus, and we just
have to accept the complexity it causes for implementations."

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Sun, 27 Sep 2009 23:43:26 -0400

Marc,

Thanks for digging up the history. I'm of the same view as you: that
different clock rates should really be represented in different SSRCs.
But we are where we are :-). Perhaps both mechanisms (clock-rate per
SSRC and clock-rate per SSRC,PT) can be captured and one recommended
over the other?

BTW: There is another inconsistency (one I'm less concerned about, to be
honest) in having multiple payload-types (of irrelevant clock freq
differences). Comfort noise (RTP-PT == 19) is sent under the same SSRC
as media, but in this case, timestamp field is set to 0, and is ignored
for the jitter calculation. 

> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Sunday, September 27, 2009 1:37 PM
> To: Aamer Akhter (aakhter)
> Cc: Colin Perkins; [email-masked]
> > rates for the same SSRC? I would have thought that this is not
> > entirely legal.
> 
> "Interleaving packets with different RTP media types but using the
same
> SSRC would introduce several problems:
> 
> [...]
> 
> seems that there is implementations out there that made other
assumptions
> (see comments by Colin Perkins and Jochen Issing), so I think that
there is a
> need for a document that clearly states what need to be done in this
case,
> and how to inter operate with this implementations.
> 
> "1) Only support codecs with one sample rate. This makes for easy
> backwards compatibility, but won't support certain codecs.
> 
draft-ietf-
> avt-variable-rate-audio-00.txt. Stephan Wenger gave an outline of this
(the
> "uRTR" approach).
with
> >>> My question is about the associated RTCP packets.  Which clock
rate
> >> use

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 28 Sep 2009 09:39:48 -0700

Hi Aamer,

> for the jitter calculation. 

Hmmm, I just read again RFC 3389 and section 4 clearly states that "...the RTP
timestamp designates the beginning of the comfort noise period.", so it should
not be set to 0.  Also the PT for CN is 13, not 19 (I remember that a long time
ago an RTP implementation was using 0x13 instead of 13, which seems to be what
you are talking about).

---

From: "Aamer Akhter (aakhter)" <[email-masked]>
Date: Mon, 28 Sep 2009 16:01:20 -0400

:-) I tracked this down and the PT/19 was a defect in the product. Never
assume that because you see something in a packet trace and everything
seems to be working as grounds for nothing being wrong.

> Sent: Monday, September 28, 2009 12:40 PM
> > BTW: There is another inconsistency (one I'm less concerned about,
to
> > be
> > as media, but in this case, timestamp field is set to 0, and is
> > ignored for the jitter calculation.
> 
> timestamp designates the beginning of the comfort noise period.", so
it
> should not be set to 0.  Also the PT for CN is 13, not 19 (I remember
that a
> long time ago an RTP implementation was using 0x13 instead of 13,
which
> seems to be what you are talking about).
> 
> --
> Marc Petit-Huguenin