Re: [MMUSIC] Telephone-event and multiple clock rates

"Stach, Thomas" <thomas.stach@unify.com> Fri, 24 January 2014 07:19 UTC

From: "Stach, Thomas" <thomas.stach@unify.com>
To: Adam Roach <adam@nostrum.com>
Thread-Topic: [MMUSIC] Telephone-event and multiple clock rates
Thread-Index: AQHPGHg+Hoa1O/rTbkS9JzrtRXTrK5qTdMaA
Date: Fri, 24 Jan 2014 07:19:40 +0000
Message-ID: <F81CEE99482EFE438DAE2A652361EE1217A2E16D@MCHP04MSX.global-ad.net>
References: <52E178F6.70009@nostrum.com>
In-Reply-To: <52E178F6.70009@nostrum.com>
Accept-Language: de-AT, en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_F81CEE99482EFE438DAE2A652361EE1217A2E16DMCHP04MSXglobal_"
MIME-Version: 1.0
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
Precedence: list

Adam,

there is an errata that covers the issue.
http://www.rfc-editor.org/errata_search.php?rfc=4733 (close to bottom)
It points to some discussion at
http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html (close to bottom)

From that I understand that the negotiated audio codec determines the clock rate for DTMF.
It still remains interesting what his means if two codecs with different clock rates were negotiated and codec-switching-on-the-fly happens.

Kind Regards/mit freundlichen Grüßen
Thomas Stach

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Adam Roach
Sent: Donnerstag, 23. Januar 2014 21:18
To: mmusic@ietf.org
Subject: [MMUSIC] Telephone-event and multiple clock rates

I've had an interesting issue brought to my attention regarding RFC4473 "telephone-event" handling.

Section 2.1 requires that "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".

On its face, this would imply that offering voice codecs with varying clock rates would result in the need to offer several PTs with telephone-event, varying only in frequency.

So, for example, if we were setting up a media session that looked like this

   m=audio 12346 RTP/AVP 0 97 98 99
   a=rtpmap:0 PCMU/8000
   a=rtpmap:97 opus/4800 0/2
   a=rtpmap:98 AMR-WB/16000
   a=rtpmap:99 speex/32000

But want to add telephone-event to it, we would need to do this:

   m=audio 12346 RTP/AVP 0 97 98 99 100 101 102 103
   a=rtpmap:0 PCMU/8000
   a=rtpmap:97 opus/48000/2
   a=rtpmap:98 AMR-WB/16000
   a=rtpmap:99 speex/32000
   a=rtpmap:100 telephone-event/8000
   a=fmtp:100 0-15
   a=rtpmap:101 telephone-event/48000
   a=fmtp:101 0-15
   a=rtpmap:102 telephone-event/16000
   a=fmtp:102 0-15
   a=rtpmap:103 telephone-event/32000
   a=fmtp:103 0-15


Rather than this:

   m=audio 12346 RTP/AVP 0 97 98 99 100
   a=rtpmap:0 PCMU/8000
   a=rtpmap:0 PCMA/8000
   a=rtpmap:97 opus/48000/2
   a=rtpmap:98 AMR-WB/16000
   a=rtpmap:99 speex/32000
   a=rtpmap:100 telephone-event/8000
   a=fmtp:100 0-15


And then it would be incumbent on the remote end to ensure that they use the *correct* DTMF PT to match the codec that they're using for speech.

This all seems like patent nonsense, and it burns an additional PT for each clock rate. Is that really what was intended by this language in RFC 4733?

/a

Re: [MMUSIC] Telephone-event and multiple clock r… Adam Roach
Re: [MMUSIC] Telephone-event and multiple clock r… Magnus Westerlund
[MMUSIC] Telephone-event and multiple clock rates Adam Roach
Re: [MMUSIC] Telephone-event and multiple clock r… Stach, Thomas
Re: [MMUSIC] Telephone-event and multiple clock r… Magnus Westerlund
Re: [MMUSIC] Telephone-event and multiple clock r… Randell Jesup
Re: [MMUSIC] Telephone-event and multiple clock r… Christer Holmberg
Re: [MMUSIC] Telephone-event and multiple clock r… Paul Kyzivat
Re: [MMUSIC] Telephone-event and multiple clock r… Christer Holmberg
Re: [MMUSIC] Telephone-event and multiple clock r… Harald Alvestrand
Re: [MMUSIC] Telephone-event and multiple clock r… DRAGE, Keith (Keith)
Re: [MMUSIC] Telephone-event and multiple clock r… Christer Holmberg