Re: [rtcweb] No Plan
Emil Ivov <emcho@jitsi.org> Fri, 31 May 2013 17:56 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 1543021F8F83 for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 10:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 vyGOmLKOejkH for <rtcweb@ietfa.amsl.com>; Fri, 31 May 2013 10:56:15 -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 9C1A621F8E79 for <rtcweb@ietf.org>; Fri, 31 May 2013 10:56:11 -0700 (PDT)
Received: by mail-bk0-f51.google.com with SMTP id ji1so912890bkc.10 for <rtcweb@ietf.org>; Fri, 31 May 2013 10:56:10 -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=AHU5/veni9joeHqKRCHFY4VH6CTXvjqNwx8qo6IcrVY=; b=Ey9Ehuzs2G4amQ2fq0gYGB4xTw8qn8nkqG8j3bTcoSah7GRfCRCc0t2hUYPAtTTQDS 6fXpQMJW6SLd0TvrHtu7vqeDz7dqHdiORTjcv8AkQrWCvjxtSy582s8h6+Fz6kq+ESNn nEx6lGC7w6cY9py/t0+lbMW/8ARDgX2rvnitQfoS+BRYWcJOBjRUUPiskNZ9UYVj7YoT z4RT17dM0wRqOY/+7LeZ/tvDeTxsIjyFW3aHD1heJEgbB1x1PDDl4N+gpG2j+/22kZ1S lLV2/sdp/U2o+vMkdoODLQH9sMkzZ5pQ+5UlSFMlv3DV+/hEWKt+xYBCUJJxft9GvTxZ Iapg==
X-Received: by 10.205.113.16 with SMTP id eu16mr3732085bkc.109.1370022970356; Fri, 31 May 2013 10:56:10 -0700 (PDT)
Received: from camionet.local ([83.228.77.158]) by mx.google.com with ESMTPSA id og1sm11819674bkb.16.2013.05.31.10.56.08 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 10:56:09 -0700 (PDT)
Message-ID: <51A8E434.1020904@jitsi.org>
Date: Fri, 31 May 2013 20:56:04 +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: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
References: <51A65017.4090502@jitsi.org> <51A70CBC.5010108@ericsson.com>
In-Reply-To: <51A70CBC.5010108@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnjIsx1KNRqvFmMIeC+/u2jUlfCDP6bzXIwUyBNqEwzjISTdwlTdRYvJOYamvNR89qu3t2O
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 17:56:16 -0000
Hey Stefan, On 30.05.13, 11:24, Stefan Håkansson LK wrote: > Hi Emil, > > a couple of comments: > > "1. Expose the SSRCs of all local MediaStreamTrack-s that the > application may want to attach to a PeerConnection." > > I don't think that would be possible, or desirable. SSRC _only_ come > into play when a MediaStreamTrack is to be transported over the network > - it is useless in local cases. And, the same local MediaStreamTrack > could be sent to several peers (using different PeerConnections) and > could have different SSRC's (and even different number of SSRC's) for > the different peers. > > I think SSRCs would only be available for MediaStreamTracks that are > attached to a PeerConnection. I believe Paul already commented on this but just to be clear: yes I agree that SSRCs would only make sense for tracks that are actually going on the network, so the API methods that give access to them would have to take this into account. > One thing I like about Plan A and B is that the naive application > developer does not have to deal with things below MediaStream and > MediaStreamTrack level. I don't think this is any different with "No Plan". Is there a particular scenario that you think would not work? > The application would simply add a MediaStream > (containing MediaStreamTracks) to the PeerConnection, do the > createOffer/setLocal and exchange signaling blobs that it need not look > into, and the MediaStream with MediaStreamTrack's would be reflected at > the remote end. The application would not have to deal with PT's, SSRC's > etc. Note that No Plan does not suggest that PT's be taken up to the application. As for SSRCs, those would just serve as identifiers and shouldn't bother developers that don't care about them. > I think that the "No Plan" proposal could be made similar if the info > about how MediaStreamTrack's relate to SSRC's (including those for FEC > and RTX) is exchanged using some blobs that the (naive) app can just > exchange and need not look into. I was indeed hoping that we could push FEC and RTX down to the RTP layer for the applications that wouldn't want to be bothered. As for the SSRC, the point of making them available to applications would be so that they could use them so I don't think that putting them into blobs would change anything. > If done that way, "No Plan" seems to me to be quite similar to Plan B, It definitely has a lot in common with Plan B, and it's all about relaxing its constraints so that applications who want to handle signalling a bit differently could do so. Cheers, Emil > On 2013-05-29 20:59, 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