Re: [rtcweb] No Plan

Emil Ivov <emcho@jitsi.org> Fri, 31 May 2013 10:51 UTC

Return-Path: <emil@sip-communicator.org>
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 37FE921F9433 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 03:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 pptw-jnRAhrS for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 03:51:27 -0700 (PDT)
Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id D66B621F94E1 for <rtcweb@ietf.org>; Fri, 31 May 2013 03:51:21 -0700 (PDT)
Received: by mail-bk0-f51.google.com with SMTP id ji1so673520bkc.38 for <rtcweb@ietf.org>; Fri, 31 May 2013 03:51:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=uU73sTtCdpBd/YrFGPzQBjycDKm9OEvee00TZ5EEb64=; b=j/MiVdLQECg4mmfS/h30HR54+qGuCG+2yv3bvRdrgK40Owm4emM7JvxdFATuY4sGj4 vzjpVyFPd3edSN1+G7cDFcmdMIEyMQJb+5RA/lUvMghO7LuxVXaQoJ4yreRSpZ81wWwt EFzjRTcPmCxazfXD7sIHzv4e900lGQCbk7N/BDKTtsaom8WYK29zK+/3DUIxsDcCxfKu WzVk7CSKPOpvgri6UR7nSaFuQZh/wGUUJZwRS3wSvyiEiOh7OA1O0hGu2hi0PM6o+eSw 49cuiNK922STYo9mOKliIM18wyFlkNEPBM05RQvnDPaQq1SmdDGfCs5g6V4hEoXJ0c+F 2hww==
X-Received: by 10.205.21.10 with SMTP id qq10mr3181136bkb.133.1369997480813; Fri, 31 May 2013 03:51:20 -0700 (PDT)
Received: from camionet.local (77-85-161-202.btc-net.bg. [77.85.161.202]) by mx.google.com with ESMTPSA id v6sm14966118bko.3.2013.05.31.03.51.19 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 03:51:20 -0700 (PDT)
Message-ID: <51A880A7.7010908@jitsi.org>
Date: Fri, 31 May 2013 13:51:19 +0300
From: Emil Ivov <emcho@jitsi.org>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <51A65017.4090502@jitsi.org> <51A65DB8.9060702@alum.mit.edu>
In-Reply-To: <51A65DB8.9060702@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQmGMVgzpOg/mM0A0nhjuk40p0HJTK9VPq6g+VPeB5kgnS+hlFBH36BDKvCPk+6eRczUOeFC
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 10:51:28 -0000

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

-- 
https://jitsi.org