IETF Logo Mail Archive

Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00

Bernard Aboba <bernard_aboba@hotmail.com> Mon, 13 May 2013 18:01 UTC

Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4C021F93F0 for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 11:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.731
X-Spam-Level:
X-Spam-Status: No, score=-101.731 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dtzm86HJ4cH for <mmusic@ietfa.amsl.com>; Mon, 13 May 2013 11:01:07 -0700 (PDT)
Received: from blu0-omc2-s29.blu0.hotmail.com (blu0-omc2-s29.blu0.hotmail.com [65.55.111.104]) by ietfa.amsl.com (Postfix) with ESMTP id D4C3521F913E for <mmusic@ietf.org>; Mon, 13 May 2013 11:01:06 -0700 (PDT)
Received: from BLU405-EAS319 ([65.55.111.72]) by blu0-omc2-s29.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 13 May 2013 11:01:05 -0700
X-EIP: [2FelAzCNspurtoE8qRYfvcP1H2Su+h2v]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU405-EAS319B9F23CC4FE84E47239EE93A00@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com> <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <1447FA0C20ED5147A1AA0EF02890A64B1C2C70B9@ESESSMB209.ericsson.se> <518D6482.2010008@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2C807D@ESESSMB209.ericsson.se> <518E70A9.7070007@alum.mit.edu> <1447FA0C20ED5147A1AA0EF02890A64B1C2CA23E@ESESSMB209.ericsson.se> <CAPvvaaKwKBmeXYrCNr-8RAcg3ff5WGwXt77TPc4v-xFKpQWTnQ@mail.gmail.com> <5190948A.5070707@ericsson.com> <5190F9A6.4000904@jitsi.org> <5190FC42.10108@alum.mit.edu> <BLU404-EAS31977F25A18724612780DB693A00@phx.gbl> <C5E08FE080ACFD4DAE31E4BDBF944EB1134E3F33@xmb-aln-x02.cisco.com>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <C5E08FE080ACFD4DAE31E4BDBF944EB1134E3F33@xmb-aln-x02.cisco.com>
Date: Mon, 13 May 2013 11:01:06 -0700
To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
X-OriginalArrivalTime: 13 May 2013 18:01:05.0952 (UTC) FILETIME=[D6D1CA00:01CE5003]
Cc: "avtcore@ietf.org" <avtcore@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 13 May 2013 18:01:11 -0000

I agree with this, and think the overall experience will be better if we can do this.  It should have been defined years ago. 

On May 13, 2013, at 10:28, "Cullen Jennings (fluffy)" <fluffy@cisco.com> wrote:

> 
> We already have RTCP to pause / un pause things and it seems like we should have RTCP to change resolution, frame rate, bandwidth inside of the parameters set in the SDP envelope (some people think we have that ). I agree that needs to all be clearly specifies how one does all of that with RTCP and how an endpoint signals in in SDP that it is capable of such negotiations. It seems fairly easy to specify whatever parts of that are missing. 
> 
> 
> On May 13, 2013, at 9:37 AM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> 
>> I think you are right on target - but if we do not have a clear articulation of the line between RTCP and O/A, then it is going to be hard to prevent going off Into the weeds.
>> 
>> On May 13, 2013, at 7:44, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:
>> 
>>> I'm not going to comment further on the specifics here, since they have been well flogged already. But the point of this particular discussion was about the likelihood of glare. Stefan's assertion was that O/As initiated by one end due to rapid changes in which streams it wants to receive will drive up the possibility of glare when the other end wants to do an O/A.
>>> 
>>> I'll just say that if the number of O/As has gone up that much, then that was a bad choice of mechanism.
>>> 
>>>  Thanks,
>>>  Paul
>> 
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email