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

> Well I could postulate a webrtc endpoint forming the collection endpoint for a telephone voting system.

Sure, if you are going to represent every new incoming "vote call" by adding an audio m- line to a single ongoing session.

Regards,

Christer

> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer 
> Holmberg
> Sent: 28 January 2014 13:03
> To: Randell Jesup; mmusic@ietf.org
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
> 
> 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...
> 
> 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
> 