Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt
Emil Ivov <emcho@jitsi.org> Tue, 14 May 2013 09:23 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 F09D521F9003 for <rtcweb@ietfa.amsl.com>; Tue, 14 May 2013 02:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.349
X-Spam-Level:
X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 DyHpDxopE57K for <rtcweb@ietfa.amsl.com>; Tue, 14 May 2013 02:23:15 -0700 (PDT)
Received: from mail-bk0-x234.google.com (mail-bk0-x234.google.com [IPv6:2a00:1450:4008:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id E988C21F8FFC for <rtcweb@ietf.org>; Tue, 14 May 2013 02:23:14 -0700 (PDT)
Received: by mail-bk0-f52.google.com with SMTP id mz1so162704bkb.11 for <rtcweb@ietf.org>; Tue, 14 May 2013 02:23:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received: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=eRD6IhSlXtlyaHREqZHeFLy2ghkGJ1iNYyWNmPsJZbs=; b=dRC5m5LSGBZt0WhtyX/LixnPgy4xPrCpMeUWsMH+Ub8pvouLQJGQjL3nAx7Nm9Fgs5 DkK4Xlnim5T1gIZtIByRsLxAzBTqyvA2BhMqCgia7+5K/JLoUe12M3kQlsxBTDvk6osg meF07BxLNU4uBl6PnMnNQK0YJVqWOarqGrtTP9qOykhLCio0LniI+gIK8iZtYM0A4ipu E0RHxDNRUwK4IzhHt4jx9QddaJUHwTNYpTE/6wOTQRTD7DodCjiBLi1D6sHPNZBhxIy2 UfMgoiqlBE6QhBZmPAbxrfioHKRZCoegComsWiXbA1OOk7e5UxXuFpl3ISp0JS6q7zxz Bs/Q==
X-Received: by 10.205.104.138 with SMTP id dm10mr7433856bkc.51.1368523393794; Tue, 14 May 2013 02:23:13 -0700 (PDT)
Received: from [192.168.1.119] ([88.203.232.9]) by mx.google.com with ESMTPSA id tl1sm3301922bkb.7.2013.05.14.02.23.12 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 14 May 2013 02:23:12 -0700 (PDT)
Message-ID: <51920280.3080308@jitsi.org>
Date: Tue, 14 May 2013 12:23:12 +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/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com>, <CALe60zAi_Lx3QFCbBQ5aPNkgorJAff0E79jkpbQX1Qt3wf2bzg@mail.gmail.com>, <CAOJ7v-1Wk6u7XiYrNVmoqr5Jisu2WRvZpte7hQTOiP8YHUc6hg@mail.gmail.com>, <008701ce4b21$a0997aa0$e1cc6fe0$@gmail.com>, <BLU169-W108D56DF61B85814543873C93BA0@phx.gbl>, <518AAAF2.5000207@alum.mit.edu>, <CA+9kkMBw4+kXAv6qLCcmGLwMxAqR6P-Tk8dm-ardv_jihHx0Hw@mail.gmail.com>, <9E563BDA-C336-4FB8-B11A-A2DC40C672C1@iii.ca>, <CA+9kkMC-NnF+VugBOZNhY4-Cz1tqJA44WSF9dg45g4GCWxkh-g@mail.gmail.com>, <518D6C76.5060606@alum.mit.edu>, <CAHBDyN6xYor-XWnLEkufoQPYrDc+KurrM0m3HBTqLXqNkPtDkQ@mail.gmail.com> <BLU169-W82D3FCC3246D6D878FA44E93A00@phx.gbl> <5191F948.3040402@ericsson.com>
In-Reply-To: <5191F948.3040402@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkr+vAckkdDECTRZyJ1CURdHGEzZrXAIHx1TqKFGVFpXn48X6GEyC774j+3zivhnKKLnXxu
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt
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: Tue, 14 May 2013 09:23:16 -0000
On 14.05.13, 11:43, Stefan Håkansson LK wrote: > On 2013-05-13 19:10, Bernard Aboba wrote: >> > [MB] I think you meant to say"..but that is NOT moving along >> very well." I do not believe we can make any >> > statements as to how CLUE identifiers map to MSIDs without doing >> that taxonomy. >> >> [BA] MSID has some aspects similar to CLUE identifiers, but it is also >> trying to do some things that are WebRTC-specific. This leads me to >> wonder whether in fact those two aspects couldn't be separated. If an >> onaddstream event is thrown when a new SSRC is received, the event >> handler could handle WebRTC-specific aspects. If this were done, it >> seems to me that we might be able to utilize the concept of CLUE capture >> in both CLUE and WebRTC, and might also get some signaling >> simplifications in the process. > > As it looks like now, onaddstream would not be fired as a result of a > new SSRC being received, but rather as a result of an SDP (offer or > answer) informing the browser of the new SSRC. (Of course there is an > escape mechanism that handles this if the offer or answer contains no > SSRC info to be able to handle legacy). Hopefully at some point we'd stop dismissing non-reliance on SDP for every single thing as "legacy". > I think signaling of some kind is needed - how would the browser > otherwise know whether the new SSRC represents a new MediaStream, a new > MediaStreamTrack (in an existing MediaStream) or just e.g. FEC data for > an already set up track? If I understand the MSID draft and Harald's mail correctly, everything would be bubbled up as separate streams and tracks and it will be up to the application to handle them and sync them one way or another. (Keeping in mind that syncing can also be auto-handled by CNAMEs) I believe that option (which works with no default signalling) is one good option. Having a second option that implements a default signalling solution is also a good idea as long as we don't consider that to be the "right way" and refer to the former as the "legacy" catch-all. > But, exactly how the signaling is made can be discussed (and I guess > that is what we're doing now). And, I am always fond of simplifications! > > A perhaps very naive thought: could we separate things up a bit? E.g. > something like: > > * Description and negotiation of codecs, PTs - this would be SDP Right! > SSRCs - this would be SDP Again, including SSRCs in SDP O/A is tricky in conferencing scenarios. > * Description of how those SSRCs map to a MediaStream+MediaStreamTrack > structure // Clue captures > * Handling of in session changes (pause/resume, resolution changes) > > Perhaps not all of the above should be done using SDP O/A, and perhaps > we should not push all the functionality into the "core" SDP. Thank you! :) Emil -- https://jitsi.org
- Re: [rtcweb] Fwd: New Version Notification for dr… Christer Holmberg
- [rtcweb] Fwd: New Version Notification for draft-… Justin Uberti
- Re: [rtcweb] Fwd: New Version Notification for dr… Harald Alvestrand
- Re: [rtcweb] Fwd: New Version Notification for dr… Harald Alvestrand
- Re: [rtcweb] Fwd: New Version Notification for dr… Stefan Håkansson LK
- Re: [rtcweb] Fwd: New Version Notification for dr… Christer Holmberg
- Re: [rtcweb] Fwd: New Version Notification for dr… Roni Even
- Re: [rtcweb] Fwd: New Version Notification for dr… Harald Alvestrand
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Harald Alvestrand
- Re: [rtcweb] Fwd: New Version Notification for dr… Christer Holmberg
- Re: [rtcweb] Fwd: New Version Notification for dr… Paul Kyzivat
- Re: [rtcweb] Fwd: New Version Notification for dr… Bernard Aboba
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Bernard Aboba
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Roni Even
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Bernard Aboba
- Re: [rtcweb] Fwd: New Version Notification for dr… Stefan Håkansson LK
- Re: [rtcweb] [MMUSIC] Fwd: New Version Notificati… Harald Alvestrand
- Re: [rtcweb] Fwd: New Version Notification for dr… Paul Kyzivat
- Re: [rtcweb] Fwd: New Version Notification for dr… Ted Hardie
- Re: [rtcweb] Fwd: New Version Notification for dr… Paul Kyzivat
- Re: [rtcweb] [MMUSIC] New Version Notification fo… Cullen Jennings (fluffy)
- Re: [rtcweb] [MMUSIC] New Version Notification fo… Hutton, Andrew
- Re: [rtcweb] New Version Notification for draft-u… Cullen Jennings
- Re: [rtcweb] New Version Notification for draft-u… Cullen Jennings
- Re: [rtcweb] New Version Notification for draft-u… Ted Hardie
- Re: [rtcweb] New Version Notification for draft-u… Paul Kyzivat
- Re: [rtcweb] New Version Notification for draft-u… Ted Hardie
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Eric Rescorla
- [rtcweb] We are moving beyond the assumptions on … Paul Kyzivat
- Re: [rtcweb] We are moving beyond the assumptions… Bernard Aboba
- Re: [rtcweb] We are moving beyond the assumptions… Emil Ivov
- Re: [rtcweb] We are moving beyond the assumptions… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Justin Uberti
- Re: [rtcweb] We are moving beyond the assumptions… Roni Even
- Re: [rtcweb] We are moving beyond the assumptions… Paul Kyzivat
- Re: [rtcweb] New Version Notification for draft-u… Mary Barnes
- Re: [rtcweb] New Version Notification for draft-u… Bernard Aboba
- Re: [rtcweb] We are moving beyond the assumptions… Martin Thomson
- Re: [rtcweb] New Version Notification for draft-u… Martin Thomson
- Re: [rtcweb] We are moving beyond the assumptions… Justin Uberti
- Re: [rtcweb] We are moving beyond the assumptions… Justin Uberti
- Re: [rtcweb] We are moving beyond the assumptions… Emil Ivov
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Emil Ivov
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] We are moving beyond the assumptions… Ted Hardie
- Re: [rtcweb] We are moving beyond the assumptions… Paul Kyzivat
- [rtcweb] Why requiring pre-announcement of SSRCs … Emil Ivov
- Re: [rtcweb] We are moving beyond the assumptions… Ted Hardie
- Re: [rtcweb] Why requiring pre-announcement of SS… Justin Uberti
- Re: [rtcweb] Why requiring pre-announcement of SS… Roni Even
- Re: [rtcweb] New Version Notification for draft-u… Paul Kyzivat
- Re: [rtcweb] Why requiring pre-announcement of SS… Emil Ivov
- Re: [rtcweb] Why requiring pre-announcement of SS… Bernard Aboba
- Re: [rtcweb] Why requiring pre-announcement of SS… Emil Ivov
- Re: [rtcweb] Why requiring pre-announcement of SS… Stefan Håkansson LK
- Re: [rtcweb] New Version Notification for draft-u… Stefan Håkansson LK
- Re: [rtcweb] Why requiring pre-announcement of SS… Emil Ivov
- [rtcweb] Common ways of handling video conference… Harald Alvestrand
- Re: [rtcweb] Common ways of handling video confer… Emil Ivov
- Re: [rtcweb] Why requiring pre-announcement of SS… Stefan Håkansson LK
- Re: [rtcweb] Why requiring pre-announcement of SS… Emil Ivov
- Re: [rtcweb] Common ways of handling video confer… Paul Kyzivat
- Re: [rtcweb] Common ways of handling video confer… Emil Ivov
- Re: [rtcweb] Common ways of handling video confer… Roni Even
- Re: [rtcweb] Why requiring pre-announcement of SS… Cullen Jennings (fluffy)
- Re: [rtcweb] Fwd: New Version Notification for dr… Iñaki Baz Castillo