Subject: [AVTCORE] [Technical Errata Reported] RFC4733 (3451)

From: RFC Errata System <[email-masked]>
Date: Fri, 11 Jan 2013 05:24:51 -0800 (PST)

The following errata report has been submitted for RFC4733,
"RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3451

--------------------------------------
Type: Technical
Reported by: Xavier Marjou <[email-masked]>

Section: 2.1

Original Text
-------------
Named telephone events are carried as part of the audio stream and
MUST use the same sequence number and timestamp base as the regular
audio channel to simplify the generation of audio waveforms at a 
gateway.

Corrected Text
--------------
Named telephone events are carried as part of the audio stream and
MUST use the same SSRC (therefore the same timing and sequence
number space) and the same timestamp clock rate as the regular
audio channel to simplify the generation of audio waveforms at a
gateway.

Notes
-----
RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html)

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4733 (draft-ietf-avt-rfc2833bis-15)
--------------------------------------
Title               : RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
Publication Date    : December 2006
Author(s)           : H. Schulzrinne, T. Taylor
Category            : PROPOSED STANDARD
Source              : Audio/Video Transport
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

---

From: Tom Taylor <[email-masked]>
Date: Sun, 13 Jan 2013 20:08:38 -0500

Before accepting this report I would want to know the consensus view of 
the meaning of "same timestamp base". The problem was raised in the 
discussion of draft-ietf-avtext-multiple-clock-rates. My understanding 
of "timestamp base" is that it defines the time units in which the 
timestamp is expressed (usually some small fraction of a second) for all 
payloads using the same SSRC. The fact that the above-mentioned draft 
was accepted as a WG document suggests that my understanding is wrong. 
Perhaps someone else can comment.

On 11/01/2013 8:24 AM, RFC Errata System wrote:
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: "Art Allison" <[email-masked]>
Date: Tue, 15 Jan 2013 10:58:15 -0500

IMNSHO, for this provision to have any impact "same timestamp base" must mean the same clock source as well as the same units.
Use of the same units from a different clock source than the 'regular' audio results in an indeterminate timing relationship for rendered elements.
(would have pruned names but I do not know that all are on the avt list.)

Art Allison 
Senior Director Advanced Engineering, Technology 
National Association of Broadcasters
1771 N Street NW
Washington, DC 20036
Phone  202 429 5418
Fax  202 775 4981 
www.nab.org 
Advocacy  Education  Innovation 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tom Taylor
Sent: Sunday, January 13, 2013 8:09 PM
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4733 (3451)

Before accepting this report I would want to know the consensus view of the meaning of "same timestamp base". The problem was raised in the discussion of draft-ietf-avtext-multiple-clock-rates. My understanding of "timestamp base" is that it defines the time units in which the timestamp is expressed (usually some small fraction of a second) for all payloads using the same SSRC. The fact that the above-mentioned draft was accepted as a WG document suggests that my understanding is wrong. 
Perhaps someone else can comment.

On 11/01/2013 8:24 AM, RFC Errata System wrote:
>
> The following errata report has been submitted for RFC4733, "RTP 
> Payload for DTMF Digits, Telephony Tones, and Telephony Signals".
>
> MUST use the same SSRC (therefore the same timing and sequence number 
> space) and the same timestamp clock rate as the regular audio channel 
> to simplify the generation of audio waveforms at a gateway.
>
> Notes
> -----
> RFC4733 was written in a way to avoid the multiple clock-rate problem 
> by mandating the use of the same SSRC for DTMF and audio. However it's 
> not explicitly written, which brings an ambiguity. It was commented 
> that RFC4733 needs to be updated. (c.f. 
> http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html)
>
> Instructions:
> -------------
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party (IESG) can log in to 
> change the status and edit the report, if necessary.
>
> Audio/Video Transport Core Maintenance [email-masked]

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 15 Jan 2013 17:54:19 +0100

Hi,

(As Individual)

Are we certain that the RTP payload format will never be sent over two
different but linked SSRCs to the original audio. There is such a use
case (See RFC 3388) where DTMF and original audio are sent in two
different RTP sessions and thus with different SSRCs (although, they
could have the same number for binding reasons). I fear the proposed
corrected text is to restrictive.

Cheers

Magnus

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 16 Jan 2013 08:42:30 -0800

On 01/13/2013 05:08 PM, Tom Taylor wrote:
> discussion of draft-ietf-avtext-multiple-clock-rates. My understanding of
> "timestamp base" is that it defines the time units in which the timestamp
> is expressed (usually some small fraction of a second) for all payloads
> using the same SSRC. The fact that the above-mentioned draft was accepted
> as a WG document suggests that my understanding is wrong. Perhaps someone
> else can comment.

Unfortunately "timestamp base" is not defined in RFC 4733 nor used in RFC
3550.  Note that RFC 3550 uses "clock frequency", media clock rate", timestamp
unit", timestamp frequency", and "RTP timestamp clock rate" as synonymous for
"clock rate".

Reading it out of context, I immediately thought that it meant the same than
"random offset".  RFC 3550 does not use the word base to refer to the random
offset of timestamp, but use base_seq to refer to the random offset of the
sequence number.

So because of this, I support an errata that make clear that "timestamp base"
means "timestamp clock rate".

>> The following errata report has been submitted for RFC4733, "RTP Payload
>> for DTMF Digits, Telephony Tones, and Telephony Signals".
>> 
>> -------------------------------------- You may review the report below
>> and at: http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3451
>> 
>> -------------------------------------- Type: Technical Reported by:
>> Xavier Marjou <[email-masked]>
>> 
>> Section: 2.1
>> 
>> Original Text ------------- Named telephone events are carried as part of
>> the audio stream and MUST use the same sequence number and timestamp base
>> as the regular audio channel to simplify the generation of audio
>> waveforms at a gateway.
>> 
>> Corrected Text -------------- Named telephone events are carried as part
>> of the audio stream and MUST use the same SSRC (therefore the same timing
>> and sequence number space) and the same timestamp clock rate as the
>> regular audio channel to simplify the generation of audio waveforms at a 
>> gateway.
>> 
>> Notes ----- RFC4733 was written in a way to avoid the multiple clock-rate
>> problem by mandating the use of the same SSRC for DTMF and audio. However
>> it's not explicitly written, which brings an ambiguity. It was commented
>> Instructions: ------------- This errata is currently posted as
>> "Reported". If necessary, please use "Reply All" to discuss whether it
>> should be verified or rejected. When a decision is reached, the verifying
>> party (IESG) can log in to change the status and edit the report, if
>> necessary.
>> 
>> -------------------------------------- RFC4733
>> (draft-ietf-avt-rfc2833bis-15) -------------------------------------- 
>> Title               : RTP Payload for DTMF Digits, Telephony Tones, and 
>> Telephony Signals Publication Date    : December 2006 Author(s)
>> : H. Schulzrinne, T. Taylor Category            : PROPOSED STANDARD 
>> Source              : Audio/Video Transport Area                :
>> Real-time Applications and Infrastructure Stream              : IETF 
>> Verifying Party     : IESG 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 16 Jan 2013 08:45:29 -0800

On 01/15/2013 08:54 AM, Magnus Westerlund wrote:
> different but linked SSRCs to the original audio. There is such a use case
> (See RFC 3388) where DTMF and original audio are sent in two different RTP
> sessions and thus with different SSRCs (although, they could have the same
> number for binding reasons). I fear the proposed corrected text is to
> restrictive.

Right.  I propose this:

Named telephone events are carried as part of the audio stream and if they use
the same SSRC (therefore the same timing and sequence number space), they MUST
use the same timestamp clock rate as the regular audio channel to simplify the
generation of audio waveforms at a gateway.

>> _______________________________________________ Audio/Video Transport
>> Core Maintenance [email-masked] https://www.ietf.org/mailman/listinfo/avt
>> 
> 
> 

- -- 
Marc Petit-Huguenin

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 16 Jan 2013 17:54:39 +0100

On 2013-01-16 17:45, Marc Petit-Huguenin wrote:
>> Are we certain that the RTP payload format will never be sent
>> over two different but linked SSRCs to the original audio. There
>> is such a use case (See RFC 3388) where DTMF and original audio
>> are sent in two different RTP sessions and thus with different
>> SSRCs (although, they could have the same number for binding
>> reasons). I fear the proposed corrected text is to restrictive.
> 
> Right.  I propose this:
> 
> if they use the same SSRC (therefore the same timing and sequence
> number space), they MUST use the same timestamp clock rate as the
> regular audio channel to simplify the generation of audio waveforms
> at a gateway.
> 

I think this is much better.

Cheers

Magnus Westerlund

---

From: "Art Allison" <[email-masked]>
Date: Wed, 16 Jan 2013 12:13:27 -0500

It seems to me that the conditional mandatory sentence is clearer if the (informative) reason is separated to prevent any misread of the 'MUST' as appling only to streams that pass through a gateway.
As in RTR:
" Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel.  Note: One benefit of this requirement is simplification of the generation of audio waveforms at a gateway." 

Regards, 
Art
Art Allison 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marc Petit-Huguenin
Sent: Wednesday, January 16, 2013 11:45 AM
To: Magnus Westerlund
Cc: [email-masked]
Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4733 (3451)

Right.  I propose this:

Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel to simplify the generation of audio waveforms at a gateway.

>> -------------------------------------- You may review the report 
>> below and at: 
>> Original Text ------------- Named telephone events are carried as 
>> part of the audio stream and MUST use the same sequence number and 
>> timestamp base as the regular audio channel to simplify the 
>> Corrected Text -------------- Named telephone events are carried as 
>> part of the audio stream and MUST use the same SSRC (therefore the 
>> same timing and sequence number space) and the same timestamp clock 
>> rate as the regular audio channel to simplify the generation of audio 
>> waveforms at a gateway.
>> 
>> Notes ----- RFC4733 was written in a way to avoid the multiple 
>> clock-rate problem by mandating the use of the same SSRC for DTMF and 
>> audio. However it's not explicitly written, which brings an 
>> ambiguity. It was commented that RFC4733 needs to be updated. (c.f.
>> "Reported". If necessary, please use "Reply All" to discuss whether 
>> it should be verified or rejected. When a decision is reached, the 
>> verifying party (IESG) can log in to change the status and edit the 
>> report, if necessary.
>> 
>> Core Maintenance [email-masked] 

- --
Marc Petit-Huguenin