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

Hi Paul,

I can't think of a use-case with multiple audio m- lines, where each would need to support telephone-events.

Perhaps such use-cases do exist, but I don't they are very common.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 1/28/14 8:02 AM, 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...

Why would you say that?

        Thanks,
        Paul

> 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
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic