Re: [rtcweb] No Plan

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 31 May 2013 19:11 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 ABBFC21F992C for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 12:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 Hw-R6YgPflDz for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 12:11:23 -0700 (PDT)
Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id EE55421F99C3 for <rtcweb@ietf.org>; Fri, 31 May 2013 12:11:21 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id ihww1l0041vXlb85AjBM3Z; Fri, 31 May 2013 19:11:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id ijBM1l00Q3ZTu2S3djBMid; Fri, 31 May 2013 19:11:21 +0000
Message-ID: <51A8F5D8.8070602@alum.mit.edu>
Date: Fri, 31 May 2013 15:11:20 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu> <51A880A7.7010908@jitsi.org>
In-Reply-To: <51A880A7.7010908@jitsi.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370027481; bh=xTVkW5vJqG6mLiC66mSNfz9du5iOXsH905xEXtSl8PM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=qVYyM/ci7uBiaBNyPzB0VNhNgg7i+0l0aqWqpiheKzfP2RvhcUZDhbS67kEFFvXTH Kj1kXNjbM7Ag5G+4wjYBn/7OdHR0wsBWYqtfAdZm6xejOVU6NuH3IVojvIaJyJeoEb fMILISWYs7wZDMZMwSjEILqQMvkxvMgMOOY4u24AtsSjOOQeOkMSigl1upE3B4feSN atU8z/kxjDI2Av5jReCReGTCCFSyNBjy4VeHTuRulWRfngCleakDY3zcqLjA26XWe1 BAkX7vYfx6dfDiWEyy/SPZcI3R1nZ5dgB/n31B/9ltcXDH1px7SyZbImdfqJHokiSr 4X5JQfKtJHEMQ==
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] No Plan
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, 31 May 2013 19:11:27 -0000

On 5/31/13 6:51 AM, Emil Ivov wrote:
> Hey Paul,
>
> On 29.05.13, 22:57, Paul Kyzivat wrote:
>> Emil,
>>
>> I'm going to reserve judgment on this pending further discussion.
>> I think this *might* work for CLUE, but I want to be certain.
>
> Sure!
>
>> I'm concerned with decomposed endpoints that can't manage all the
>> streams on the same address/port. They will need multiple independent
>> m-lines and/or bundle groups.
>
> This is obviously open for debate but the general idea of No Plan is
> that: Offer/Answer is used for configuring media and RTP stacks and
> additional signalling is not the browser's concern.
>
> Having extra m= lines, particularly when using BUNDLE, is in many ways
> just extra signalling.

You may be able to argue that adding extra m-lines into an existing 
bundle is "just extra signaling". But introducing an additional 5-tuple 
is more substantial. It requires configuring a new RTP stack and media.

	Thanks,
	Paul

> If you'd like for that signalling to be in SDP, I
> don't see any problem with it. However it would be best for this extra
> layer of SDP signalling to appear at either the application layer or in
> a signalling gateway (that is going to be there anyway).
>
> Does this make sense?
>
> Emil
>
>>
>> Further questions:
>>
>> I presume that you expect bandwidth in the SDP to be an aggregate
>> per-m-line, with application specific signaling for bandwidth at the
>> per-RTP-stream level?
>>
>>     Thanks,
>>     Paul
>>
>> On 5/29/13 2:59 PM, Emil Ivov wrote:
>>> Hey all,
>>>
>>> Based on many of the discussions that we've had here, as well as many
>>> others that we've had offlist, it seemed like a good idea to investigate
>>> a negotiation alternative that relies on SDP and Offer/Answer just a
>>> little bit less.
>>>
>>> The following "no plan" draft attempts to present one such approach:
>>>
>>> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
>>>
>>> The draft relies on conventional use of SDP O/A but leaves the
>>> intricacies of multi-source scenarios to application-specific
>>> signalling, with potentially a little help from RTP.
>>>
>>> Hopefully, proponents of Plans A and B would find that the
>>> interoperability requirements that concerned them can still be met with
>>> "no plan". Of course they would have to be addressed by
>>> application-specific signalling and/or signalling gateways.
>>>
>>> Comments are welcome!
>>>
>>> Cheers,
>>> Emil
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> .
>>
>