IETF Logo Mail Archive

Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun)

Harald Alvestrand <harald@alvestrand.no> Tue, 14 May 2013 11:41 UTC

Return-Path: <harald@alvestrand.no>
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 E705821F8F7B for <rtcweb@ietfa.amsl.com>; Tue, 14 May 2013 04:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 WDjhN86bYsjb for <rtcweb@ietfa.amsl.com>; Tue, 14 May 2013 04:41:13 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id AD26921F8F20 for <rtcweb@ietf.org>; Tue, 14 May 2013 04:41:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6B69439E18D; Tue, 14 May 2013 13:41:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnfLAWKjs0Qc; Tue, 14 May 2013 13:41:09 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:f444:dc63:8cb:d3f4] (unknown [IPv6:2001:470:de0a:27:f444:dc63:8cb:d3f4]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 8645939E03B; Tue, 14 May 2013 13:41:09 +0200 (CEST)
Message-ID: <519222D5.2080404@alvestrand.no>
Date: Tue, 14 May 2013 13:41:09 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <51894846.3090102@nostrum.com> <518A304A.1030609@alvestrand.no> <518F6338.8070903@jitsi.org> <518F83E5.4060209@alvestrand.no> <518F9280.6070803@jitsi.org> <518FAD13.9050503@alvestrand.no> <CAPvvaaK1bQ+0DwAWwjN2P1RQOAY2cGC0Hf88od2ZnFA0gu6s4g@mail.gmail.com> <518FF3AE.4050505@alvestrand.no> <5191D6C3.4090604@jitsi.org>
In-Reply-To: <5191D6C3.4090604@jitsi.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] MSID fallback for non-MSID case (Re: Plan A, respun)
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:41:19 -0000

On 05/14/2013 08:16 AM, Emil Ivov wrote:
> Hey Harald,
>
> On 12.05.13, 22:55, Harald Alvestrand wrote:
>> On 05/12/2013 06:03 PM, Emil Ivov wrote:
>>>> Or you could signal none of them and depend on the fallback case in
>>>> draft-ietf-mmusic-msid to handle them in a consistent manner, and
>>>> use other methods to figure out how to handle them...
>>> If you are referring to section 4.1 that you also pasted earlier in
>>> this thread, it only talks about one track, per stream, per m= line.
>>> This doesn't cover the conferencing case I described in my previous
>>> mail (quoted above).
>>>
>> Changing subject as I'm replying to a subtopic, and because I was
>> misunderstanding what Emil was arguing in favour of.....
>>
>> when I wrote that text, I didn't intend it to cover only one SSRC per
>> stream.
>> What I intended to say was that when, in an RTP session, a browser gets
>> several SSRCs that were not mentioned in signalling, it will send
>> several onaddstream signals to the application, each indicating a new
>> stream being added, which has exactly one track.
> Aha! OK, I understand and it sounds better now that I do.
>
> That's only half of it though. We would also need ways in the API to
> control these streams if we weren't using SDP O/A.
>
> Incidentally, when people have tried this with Chrome it didn't work as
> described above and the unannounced SSRCs were handled in unpredictable
> ways. I suppose this is just a matter of time and that the
> implementation would eventually get there?

Yes - please file a bug; that helps prioritize what gets done first!

>
>> If the language doesn't
>> say that, I need to change it.
> Well obviously I hadn't understood but that might be just me.
>
> Incidentally, we might want to replace Pre-WebRTC with Non-WebRTC or
> something similar. Applications that don't aggressively rely on SDP O/A
> for stream control are not necessarily a thing of the past.

Non-WebRTC sounds good. Or even "applications that don't use MSID for 
SSRC indications".

>
> Emil
>

v2.23.0 | Report a Bug | By Email