Re: [rtcweb] No Plan
Emil Ivov <emcho@jitsi.org> Mon, 03 June 2013 21:15 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 F1FB411E80F4 for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:15:00 -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 OcdD3uCBZcVi for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:14:50 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id A504A11E80F5 for <rtcweb@ietf.org>; Mon, 3 Jun 2013 14:09:46 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id hr14so3135370wib.3 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 14:09:45 -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=9nAlLtu+EzBRjJGKLi9UXVXgS9ZOLIYAjwKq2W9aD54=; b=A3cDWAAvtHm5YCrhKyVV1+0GY81zRzzs804Ns5/fxq+JmZ1HyddD14dtNhtSy/6Mcm sOPMwdjMfaZkVIwZKZfX12yKSAjBh18FK0wylmw2woRVrROcq6GEXwpYWSgAB6OlpYjT em7dOK7EmVRSCuxplmVPVAxjL6E1t+yYbS54CvzZIgBJj53UK8NyjgyO9Osl7tlurgmi 7TJEXqwCuvhK7vonAc7krIrpLxlBi68BVxS3W8occ1g+RB7epklEzoGMe17B/cFy+Ztx Gikz+AzEVqnpcYmRiFkPSQWt9PjBnSHEZkHugwlQiI3f4Eo5piifTwHthYvry+ISGFaM CLgw==
X-Received: by 10.194.243.129 with SMTP id wy1mr10346838wjc.47.1370293785756; Mon, 03 Jun 2013 14:09:45 -0700 (PDT)
Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id ff10sm26188335wib.10.2013.06.03.14.09.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:09:44 -0700 (PDT)
Message-ID: <51AD0616.5040008@jitsi.org>
Date: Tue, 04 Jun 2013 00:09:42 +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> <51A880A7.7010908@jitsi.org> <51A8F5D8.8070602@alum.mit.edu> <51A98934.3000103@jitsi.org> <51ACFE8A.8030503@alum.mit.edu>
In-Reply-To: <51ACFE8A.8030503@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQn3khdAkfP/LnoOOTTb2lIElxZztYahNnpr9lblvTqnQi2X3PdrsThyOj4ly8B2YwTug1iw
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: Mon, 03 Jun 2013 21:15:01 -0000
Hey Paul, On 03.06.13, 23:37, Paul Kyzivat wrote: > On 6/1/13 1:40 AM, Emil Ivov wrote: >> >> >> On 31.05.13, 22:11, Paul Kyzivat wrote: >>> 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. >> >> Indeed, this would require BUNDLE to work. > > I don't understand what that means - what point you are trying to make. Sorry about this. What I was trying to say was: yes, you are right, introducing a new 5-tuple is more substantial. Therefore adding a new m= line to an SDP is a lot simpler if it didn't also imply adding a new 5-tuple. This would only be possible when m= lines are bundled. This is why I said: "Indeed, this would require BUNDLE to work." Is this clearer? > You seem to have some criterion for what requires sdp and what does not. > And AFAIK you are already assuming bundle works - you are simply using > it less. No, not really. The assumption is only necessary when trying to talk to Plan A devices and you want to have new m= lines added en route. No such assumption is necessary, for example, when talking to legacy SIP phones that will only show one video and one audio stream. > As best I can tell, you acknowledge that you need SDP to: > - negotiate a 5-tuple over which media will flow > - specify which types of media can be carried and the codec info > they may use. Yes. > I'm just pointing out that for decomposed endpoints one 5-tuple may not > be enough. And the need for this might not be known a priori. One side > may be ready to add another stream for some purpose, and be willing/able > to use private signaling to negotiate that. But the other side may not > be able to handle that stream on the same 5-tuple. That in turn may > result in a need to negotiate SDP changes to establish an additional > 5-tuple that can then be used for that new stream. I think I see ... but not completely. Could you please post an SDP offer with BUNDLE and the corresponding answer? (This might be a good point to move this to mmusic) Thanks, Emil >> >> >>> >>> 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 >>>>> . >>>>> >>>> >>> >>> . >>> >> > > -- https://jitsi.org
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Richard Barnes
- Re: [rtcweb] No Plan Cullen Jennings
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Martin Thomson
- [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Mary Barnes
- Re: [rtcweb] No Plan Peter Saint-Andre
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Enrico Marocco
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan - PT based MUX Cullen Jennings
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Gunnar Hellstrom
- Re: [rtcweb] No Plan Sergio Garcia Murillo
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- Re: [rtcweb] No Plan Mark Rejhon
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Cullen Jennings (fluffy)
- [rtcweb] RTT (was Re: No Plan) Matthew Kaufman
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Matthew Kaufman
- Re: [rtcweb] RTT (was Re: No Plan) Paul Kyzivat
- Re: [rtcweb] No Plan Stefan Håkansson LK
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was Re: No Plan) Gunnar Hellstrom
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Barry Dingle
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] RTT (was :No Plan ) Iñaki Baz Castillo
- [rtcweb] Translating Plan A into No Plan (Was: No… Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Eric Rescorla
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] Translating Plan A into No Plan (Was… Martin Thomson
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] RTT (was :No Plan ) Paul Kyzivat
- Re: [rtcweb] No Plan - but what's the proposal Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Iñaki Baz Castillo
- Re: [rtcweb] Translating Plan A into No Plan (Was… Emil Ivov
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] Translating Plan A into No Plan (Was… Paul Kyzivat
- Re: [rtcweb] No Plan Paul Kyzivat
- Re: [rtcweb] No Plan Jonathan Lennox
- Re: [rtcweb] No Plan Jim Barnett
- Re: [rtcweb] Translating Plan A into No Plan (Was… Roni Even
- Re: [rtcweb] No Plan Bernard Aboba
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] No Plan Christer Holmberg
- [rtcweb] Repair Flows and No Plan (Was: No Plan) Emil Ivov
- Re: [rtcweb] No Plan Emil Ivov
- Re: [rtcweb] RTT (was :No Plan ) BeckW
- Re: [rtcweb] RTT (was :No Plan ) Gunnar Hellstrom
- Re: [rtcweb] Repair Flows and No Plan (Was: No Pl… Sergio Garcia Murillo
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Silvia Pfeiffer
- Re: [rtcweb] No Plan - but what's the proposal Emil Ivov
- [rtcweb] Plan xyz discussions; MMUSIC <> RTCweb R… Flemming Andreasen
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Cullen Jennings
- Re: [rtcweb] No Plan - but what's the proposal Peter Thatcher