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

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

On 01/15/2013 08:54 AM, Magnus Westerlund wrote:
> 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.

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.

> 
> Cheers
> 
> Magnus
> 
> On 2013-01-11 14:24, 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 <xavier.marjou@orange.com>
>> 
>> 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 
>> _______________________________________________ Audio/Video Transport
>> Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt
>> 
> 
> 

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

iQIcBAEBCAAGBQJQ9tkkAAoJECnERZXWan7E3koP/0AqEe+Iuy8RLOmU0jls4+fv
kMZdDsuI6MtHiAUhOZ+DLuKww5pt6ubskiILud6GlqQPwFf3kEAzYXeYJUmX7bJ5
r4BSqkKwQsIf1OUR6V4a0jpy3Ydy6FJNqe0CS8dQPrD4otLnT6AjFW/StZVbhBzT
wdmj3gfS4YQY9FkI3eHQxXEIAsqT53iuI5m6x9+5BFMU47M5Xh4WM49RdHwZP0uO
Mqo3CYjBe7I1bBo7y9V+uaddQj+nW5MeNoAbXl9hKZCtZOL2TRq8M2OQpVqnDsNx
LmPtxcSud9fW07GxWlmJgQBiV2C+LVj4TSjXeIvZozwceRIg304yLpJLfe4hkulK
/Qahsz1VIGXR2ddacdYTIZtPCP+uRbpFal+zoTlbscdRTlrx5xgpvY/x2saqj79m
31QJ6WrN1cRW7fJU3i6NQvM+UB0+v3PVnu4WpNaa5o+yoVU1UItKXDlFTh+hUbjQ
sfKFbcsZcJERCHH4Wc58zCbj5/O2iXbwPzmnfe5seFrxxxO5U+RNu/yZO0GwWmAo
qx/V2Z0VoSgVHip0LbtgJeTkIOt3V791sFZt61H1D2sbofTvhdLrAsrRvaqPuGId
C3tX6YBEhrBk19rzDMQmInXHCf1wL17wc6Oojy8Lt/oCO9rLVCTvOcNPK5TDG1qc
fagpbtxylCBGa1T/6UNy
=FMtx
-----END PGP SIGNATURE-----