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

[Marc Petit-Huguenin <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 01/13/2013 05:08 PM, Tom Taylor wrote:
> 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.

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".

> 
> 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".
>> 
>> -------------------------------------- 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 <[e-mail]>
>> 
>> 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 
>> _______________________________________________

- -- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQ9th1AAoJECnERZXWan7EqkAP/1zgczAt5RWdMImtg65xyF8k
q8CkeXfdaFb/c/Zxz8pWRtw7pYoGBiY46tIj+2+ES0bx7BWaA3WUpmcswIsxt4LR
dVNO6pK1eFMz+dm3S7jUGptQxTfX3QAf4D9y7Czy2d45lt9EYWlkE2TESs1J5f61
UWZ4jaqoMTu/PG/AuQaUdYHYGi+s6VUsVsIAHxr108u3CSgL1tG9lgrqrGYb3YUc
J6ulAJFoi5AXcchBHdmzGy3qgCPNx4Don45nkhb03G8KrUK5ag5PIDgeoV1/V4Ca
0OTgedighdCb7bRM+5k0KM+VtAf2cLvMCbXocM4c5uIwVdxS0j+Dcknx3wNg4meF
Xl3N1i8FXscIOLVPB3Zr+cAp1oR5bLU79Hr5AxTGM0bVFCikQ7ZwydOJ8x3fo7/F
3gZcsI6QNXoAeQJ/mZT14bAzvW2xlSV3NlXoKEKnLj78OT8BH8HyIcmtJjDQ5J8r
MNvnk8kuTkVMEfUyicVH1xyby6fkfK8BAZCw81nmaX+5JP90Hf6snKuFlMWUPxj6
fxkWMcHr7FeO5A2y5yV4YMMUZ63/SnoRU9M72Z+NQD+eAbh6CiUayN+JIy7Qlr6M
0rTbvyOqEUS2oTihjsA3/8tDey46hfqAm1Onz1pM2mevKe1DPJQcghp4shHR9kMY
WL1ThAootrod7o8AR/s5
=PVll
-----END PGP SIGNATURE-----