Re: [MMUSIC] mmusic Digest, Vol 117, Issue 19

[Sumanth Suryanarayan <[e-mail]>]

Cool dude. BTW, how much sqft does wardrobe come to?
On Jan 29, 2014 12:51 AM, <[e-mail]> wrote:

> Send mmusic mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/mmusic
> or, via email, send a message with subject or body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mmusic digest..."
>
>
> Today's Topics:
>
>    1. Re: Telephone-event and multiple clock rates (Christer Holmberg)
>    2. Re: New Version Notification for
>       draft-reddy-mmusic-ice-happy-eyeballs-04.txt
>       (Pal Martinsen (palmarti))
>    3. Re: Telephone-event and multiple clock rates (Paul Kyzivat)
>    4. Re: Telephone-event and multiple clock rates (Christer Holmberg)
>    5. Re: Telephone-event and multiple clock rates (Harald Alvestrand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 28 Jan 2014 13:02:50 +0000
> From: Christer Holmberg <[e-mail]>
> To: Randell Jesup <[e-mail]>, "[e-mail]"
>         <[e-mail]>
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
> Message-ID:
>         <[e-mail]>
> Content-Type: text/plain; charset="us-ascii"
>
> 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:[e-mail]] On Behalf Of Randell Jesup
> Sent: 27. tammikuuta 2014 10:48
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 28 Jan 2014 13:49:19 +0000
> From: "Pal Martinsen (palmarti)" <[e-mail]>
> To: Ari Ker?nen <[e-mail]>
> Cc: mmusic <[e-mail]>, "Tirumaleswar Reddy \(tireddy\)"
>         <[e-mail]>
> Subject: Re: [MMUSIC] New Version Notification for
>         draft-reddy-mmusic-ice-happy-eyeballs-04.txt
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="Windows-1252"
>
>
> On 24 Jan 2014, at 14:59 pm, Ari Ker?nen <[e-mail]> wrote:
>
> > Hi,
> >
> > The way forward you proposed sounds good. Looking forward to the updated
> draft. However, I didn?t really understand how is the lack of coordination
> and different promo algorithms an advantage?
>
> My thought at the time was due to triggered checks it could in some cases
> be good to have uncoordinated checklists for IPv6 due to less NATs and
> other restrictive ?things?. But that is clearly a bad idea. Sorry for the
> derailing.
>
> Just posted -05 version of the draft.
>
> Name:           draft-reddy-mmusic-ice-happy-eyeballs
> Revision:       05
> Title:          Happy Eyeballs Extension for ICE
> Document date:  2014-01-28
> Group:          Individual Submission
> Pages:          5
> URL:
> http://www.ietf.org/internet-drafts/draft-reddy-mmusic-ice-happy-eyeballs-05.txt
> Status:
> https://datatracker.ietf.org/doc/draft-reddy-mmusic-ice-happy-eyeballs/
> Htmlized:
> http://tools.ietf.org/html/draft-reddy-mmusic-ice-happy-eyeballs-05
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-reddy-mmusic-ice-happy-eyeballs-05
>
>
> Not sure if we hit the right balance between keeping it short, but still
> readable without having all the ICE details fresh in memory.
>
> Do we ask for WG adoption, or do we need another MMUSIC session discussing
> this?
>
> .-.
> P?l-Erik
>
> >
> >
> > Cheers,
> > Ari
> >
> > On 13 Jan 2014, at 13:46, Pal Martinsen (palmarti) <[e-mail]>
> wrote:
> >
> >>>
> >>>
> >>> Also, if there is no coordination/signaling between the endpoints,
> what are the odds they'd end up using the same promotion algorithm?
> >>>
> >> Exactly, and that might be an advantage..
> >
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 28 Jan 2014 11:32:02 -0500
> From: Paul Kyzivat <[e-mail]>
> To: [e-mail]
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> 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:[e-mail]] On Behalf Of Randell Jesup
> > Sent: 27. tammikuuta 2014 10:48
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 28 Jan 2014 18:25:17 +0000
> From: Christer Holmberg <[e-mail]>
> To: Paul Kyzivat <[e-mail]>, "[e-mail]"
>         <[e-mail]>
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset="us-ascii"
>
> 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 <[e-mail]> 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:[e-mail]] On Behalf Of Randell Jesup
> > Sent: 27. tammikuuta 2014 10:48
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 28 Jan 2014 19:01:46 +0100
> From: Harald Alvestrand <[e-mail]>
> To: [e-mail]
> Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
> Message-ID: <[e-mail]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> 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:[e-mail]] On Behalf Of Randell Jesup
> > Sent: 27. tammikuuta 2014 10:48
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
> ------------------------------
>
> End of mmusic Digest, Vol 117, Issue 19
> ***************************************
>