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

[Randell Jesup <[e-mail]>]

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-rates/) 
>>
>> 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