Subject: [rtcweb] RTP clock rates

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 12 Jun 2012 22:39:31 -0700

In discussion at the interim meeting yesterday, Harald expressed a 
desire to prohibit a sender from changing the Payload Type associated 
with an SSRC to one that runs at a different clock rate. This raised the 
question of what clock rates are supported for various codecs where we 
might want to switch, specifically Opus and DTMF.

draft-spittka-payload-rtp-opus-00 specifies that the clock rate for Opus 
will always be 48 kHz. According to RFC 4733, DTMF supports any integer 
clock rate. The "duration" field for a DTMF telephone event is a 16-bit 
unsigned integer, giving a maximum duration of 1.365 seconds per packet. 
Events can be extended beyond this by splitting them into segments and 
sending a separate packet for each segment (using the 'E' bit to mark 
the last one).

So I don't think this prohibition imposes any serious limitations, at 
least with regards to Opus and DTMF.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Jun 2012 09:22:56 +0200

On 06/13/2012 07:39 AM, Timothy B. Terriberry wrote:
> with an SSRC to one that runs at a different clock rate.
To be more precise: I suggested that we should incorporate by reference 
the advice in draft-ietf-avtext-multiple-clock-rates-05:

4.1.  RTP Sender (with RTCP)

    An RTP Sender with RTCP turned on MUST use a different SSRC for each
    different clock rate.  An RTCP BYE MUST be sent and a new SSRC MUST
    be used if the clock rate switches back to a value already seen in
    the RTP stream.

> This raised the question of what clock rates are supported for various 
> codecs where we might want to switch, specifically Opus and DTMF.
>
> draft-spittka-payload-rtp-opus-00 specifies that the clock rate for 
> Opus will always be 48 kHz. According to RFC 4733, DTMF supports any 
> integer clock rate. The "duration" field for a DTMF telephone event is 
> a 16-bit unsigned integer, giving a maximum duration of 1.365 seconds 
> per packet. Events can be extended beyond this by splitting them into 
> segments and sending a separate packet for each segment (using the 'E' 
> bit to mark the last one).
>

This of course means that if one wants to use DTMF with multiple codecs 
that have different clock rates, there must be multiple payload types 
that identify as DTMF - one for each clock rate.

The same issue arises with CN (Comfort Noise).

Not a problem, as long as implementors are aware, I think.

                               Harald

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 13 Jun 2012 05:10:54 -0700

>     be used if the clock rate switches back to a value already seen in

[BA] Yes, I think this makes sense.