Re: [rtcweb] New Version Notification for draft-uberti-rtcweb-plan-00.txt

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Tue, 14 May 2013 11:44 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
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 E568921F8425 for <rtcweb@ietfa.amsl.com>; Tue, 14 May 2013 04:44:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.683
X-Spam-Level:
X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_FWDLOOK=1.666]
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 tk2BGkezAroF for <rtcweb@ietfa.amsl.com>; Tue, 14 May 2013 04:44:39 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 31D2621F8F7B for <rtcweb@ietf.org>; Tue, 14 May 2013 04:44:38 -0700 (PDT)
X-AuditID: c1b4fb25-b7f396d000007d06-ae-519223a12117
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 33.B3.32006.1A322915; Tue, 14 May 2013 13:44:33 +0200 (CEST)
Received: from [150.132.141.119] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Tue, 14 May 2013 13:44:33 +0200
Message-ID: <519223A0.1040908@ericsson.com>
Date: Tue, 14 May 2013 13:44:32 +0200
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
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> <51920280.3080308@jitsi.org>
In-Reply-To: <51920280.3080308@jitsi.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGfG3Vneh8qRAgxVXjC3W7JzAYrH2Xzu7 A5PHkiU/mTz+vwkMYIrisklJzcksSy3St0vgyrgw+T9jwQ6ZincrzrA2MO4W62Lk5JAQMJFo 33iBGcIWk7hwbz1bFyMXh5DAKUaJ1Wu6oZy1jBJ/vl1kBaniFdCWaOpfxAZiswioSpydcQvM ZhMIlLj+/xcTiC0qECXx7+1uRoh6QYmTM5+wgNgiAvIS3W2LwGqYBYQlNlxsA4sLCwRJfFlw jxFi2XVWiZ+LXwElODg4BTQlGi9pQNTbSlyYc50FwpaXaN46G+xqIQFdiXev77FOYBSchWTd LCQts5C0LGBkXsXInpuYmZNebrSJERiSB7f8Vt3BeOecyCFGaQ4WJXHeZK7GQCGB9MSS1OzU 1ILUovii0pzU4kOMTBycUg2M856ZzjjYn+vq7JphnaXiJONieJo3vNhr3T7GcHfnORm1PbMb Nt+ftqDy1HMN4U0Zl29wTNNJaygtPPVA8Pdf7pZr6f+YZOSl4lgdK2W6V+tlnav1qXqe1WS3 Tedvltyiu1+Wyk7REEnv8TB+eHMe+9bHYoEOXk9EZ+hdX6SZItC4+beObaoSS3FGoqEWc1Fx IgDxwYSNFwIAAA==
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 11:44:46 -0000

On 2013-05-14 11:23, Emil Ivov wrote:
>
>
> 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.

Here seems to be something that I have missed. That there are existing 
implementations that do not signal SSRC is fine, and in most cases there 
would be only one audio and one video SSRC used anyway. And rtcweb (and 
Clue?) should be able to interoperate (but perhaps your web app need to 
be designed in a specific way).

But if we design something forward looking, that can handle many 
streams, that can handle layered codecs and FEC data, signaling SSRCs 
seems like a must to me.

But I have missed that this is problematic in conferencing scenarios, 
could you tell me why (and I probably should know :) )?

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