[MMUSIC] Telephone-event and multiple clock rates

[Adam Roach <[e-mail]>]

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