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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 28 January 2014 20:19 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890C91A02F1 for <mmusic@ietfa.amsl.com>; Tue, 28 Jan 2014 12:19:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level:
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs0bPVg1rMrU for <mmusic@ietfa.amsl.com>; Tue, 28 Jan 2014 12:19:53 -0800 (PST)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id B03681A0245 for <mmusic@ietf.org>; Tue, 28 Jan 2014 12:19:53 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s0SKJlBi022656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 28 Jan 2014 14:19:48 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s0SKJivp003431 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Jan 2014 21:19:46 +0100
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 28 Jan 2014 21:19:44 +0100
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Randell Jesup <randell-ietf@jesup.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] Telephone-event and multiple clock rates
Thread-Index: AQHPGHg9LlpXnTtXk0SY+cajv/cG7ZqTZ5YAgAA1EQCAAFw3gIAEPmQAgAHpdsCAAHaq8A==
Date: Tue, 28 Jan 2014 20:19:44 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B1246AC@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <52E178F6.70009@nostrum.com> <F81CEE99482EFE438DAE2A652361EE1217A2E16D@MCHP04MSX.global-ad.net> <52E24090.1030608@ericsson.com> <52E28DEB.1040100@nostrum.com> <52E61D40.1020301@jesup.org> <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D14595C@ESESSMB209.ericsson.se>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [MMUSIC] Telephone-event and multiple clock rates
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Jan 2014 20:19:56 -0000

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

Keith 

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