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

Cullen Jennings <fluffy@iii.ca> Fri, 10 May 2013 18:45 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDA321F91CE for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 11:45:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.139
X-Spam-Level:
X-Spam-Status: No, score=-3.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 0sA6a9hYi11R for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 11:45:04 -0700 (PDT)
Received: from fallback-in2.mxes.net (fallback-out2.mxes.net [216.86.168.191]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF1021F90DF for <rtcweb@ietf.org>; Fri, 10 May 2013 11:44:52 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by fallback-in1.mxes.net (Postfix) with ESMTP id 5BA892FD7D6 for <rtcweb@ietf.org>; Fri, 10 May 2013 14:44:51 -0400 (EDT)
Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 76C9622E259; Fri, 10 May 2013 14:44:46 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <518C59B5.7050200@alum.mit.edu>
Date: Fri, 10 May 2013 10:54:05 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <ACE55180-6549-4826-8245-EBBB0D071D52@iii.ca>
References: <CA+9kkMDWy_Koq0Aun5A330O7OOMt9vimWPNe_uznAQdr0TSfow@mail.gmail.com> <51897B11.60004@nostrum.com> <518AB095.7010401@alum.mit.edu> <518AC143.2010006@nostrum.com> <518BBE2A.4060102@alum.mit.edu> <518BC345.6060807@nostrum.com> <518C59B5.7050200@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1503)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Quick comments on draft-roach-rtcweb-glareless-add-00
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 May 2013 18:45:11 -0000

On May 9, 2013, at 8:21 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 5/9/13 11:39 AM, Adam Roach wrote:
>> On 5/9/13 10:18, Paul Kyzivat wrote:
>>> On 5/8/13 5:18 PM, Adam Roach wrote:
>>>> 
>>>> What I was trying to say above is that the only information you would
>>>> need to convey is literally one, two, or three <mediatype,ordinality>
>>>> pairs. You don't say what you're planning to do with them, just that you
>>>> need them.
>>> 
>>> How is that possibly enough? What codecs and codec parameters/optons?
>>> What bandwidth? What bundling options? The list goes on.
>> 
>> I apologize. I must have done a really poor job in the prose in my
>> draft, since I clearly didn't communicate the fundamental mechanism that
>> I had in mind at all.
>> 
>> Let me try with a ladder diagram to see whether that helps illuminate
>> what I'm proposing.
>> 
>> 
>> Offerer                             Answerer
>>    |                                    |
>>    |<----------Solicitation-------------|
>>    |  (I need 1 new audio 1 new video)  |
>>    |                                    |
>>    |                                    |
>>    |-------------SDP Offer------------->|
>>    | (Contains two more m-line sections |
>>    | than the current session; one      |
>>    | audio, one video. Both recvonly.)  |
>>    |                                    |
>>    |                                    |
>>    |<------------SDP Answer-------------|
>>    | (Makes use of the two new m-line   |
>>    | sections by populating them with   |
>>    | codec parameters, options, ssrc    |
>>    | bandwidth, bundling, etc, etc.)    |
>> 
> 
> Yeah, I figured that from the last message. But the answer is constrained by the offer. So the answer may only have codecs that are listed in the offer.
> 
> I guess the offerer can just include everything it is capable of supporting. But that would be especially unpleasant

it seem to me that we all the same problems in the initial offer. The whole idea of an Offer/Answer is the offer has more or less has everything you support or are willing to do so I don't really see that being a big problem here.