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

On 01/28/2014 02:02 PM, Christer Holmberg wrote:
> Hi,
>
> I guess it would be good to add some text to BUNDLE, to indicate that you must include the telephone-event PTs for every m- line which may use them. I.e. you cannot indicate telephone-event for one m- line, and then use them on every m- line within the bundle group.
>
> But, I guess there will be no need for people to support telephone-events on more than one m- line to begin with, so...

Telephone-events are a hack for gateways into contexts where DTMF
signalling makes sense - which is primarily the telephone network and
telephone-related systems.

In practice, I don't expect gateways into those contexts to support very
many clock rates - they should support G.711's 8000 and Opus' 48K, and
hopefully that's the end of it.

I don't want to worry very much about two extra lines of SDP; let's just
declare (probably in -rtcweb-audio-) that if multiple audio codec
bitrates are offered, and one wishes to use DTMF no matter what codec is
selected, one must offer DTMF at each clock rate offered - each offer
consuming one PT.

>
> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Randell Jesup
> Sent: 27. tammikuuta 2014 10:48
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
>
> On 1/24/2014 10:59 AM, Adam Roach wrote:
>> On 1/24/14 04:29, Magnus Westerlund wrote:
>>> My understanding for the reasoning behind this definition in the RFC 
>>> is due to that the events is supposed to be connected to the same 
>>> time-line as the audio. Thus it ended up using the same SSRC. To 
>>> avoid timestamp rate switching which we know has issues
>>> (https://datatracker.ietf.org/doc/draft-ietf-avtext-multiple-clock-ra
>>> tes/)
>>>
>>> it was mandated to provide one PT for each rate negotiated for the 
>>> audio payload types.
>> To make sure I understand what you're saying correctly: you are 
>> asserting that having four different clock rates for voice codecs 
>> requires us to use four different PTs for telephone-event if we're 
>> going to have them on the same SSRC. Is that correct?
> If those four PT's (not codecs) are accepted (and thus can be switched between on-the-fly), yes.  Multiple clock rates plays hell with RTP timestamps.
>
> You could use a separate SSRC (or m=audio line) for each clock rate instead.  This would likely mean glitching at transitions however, so not a great solution, but works.  You might be able to avoid glitches by making sure you send RTCP for the alternate SSRCs so synchronization info is available, though this may require the receiver to know somehow that the SSRC's need to be "lip-synced" (in this case audio to audio though).  Overall - here be (baby) dragons in the glitch-avoidance variation...
>
> In theory you could allow one telephone-event PT and do a renegotiate after an effective codec/PT change.  You might need to be careful about asynchronicity due to the renegotiation and not re-use the same PT for a different rate of telephone-event (ping-pong between two).  There would exist a window when there was a switch where it would be problematic to send telephone-event (and you'd need to require that both sides switch when one does). Overall - here be (big) dragons.
>
> --
> Randell Jesup -- rjesup a t mozilla d o t com
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic

-- 
Surveillance is pervasive. Go Dark.