Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism

Harald Alvestrand <harald@alvestrand.no> Fri, 23 September 2011 09:44 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 0D6A121F8B37 for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 02:44:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.831
X-Spam-Level:
X-Spam-Status: No, score=-108.831 tagged_above=-999 required=5 tests=[AWL=1.768, 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 6j49dyP8+XQT for <rtcweb@ietfa.amsl.com>; Fri, 23 Sep 2011 02:44:56 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 67F5A21F8B20 for <rtcweb@ietf.org>; Fri, 23 Sep 2011 02:44:56 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E237739E0C4 for <rtcweb@ietf.org>; Fri, 23 Sep 2011 11:47:29 +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 zfQIzbCa6RZo for <rtcweb@ietf.org>; Fri, 23 Sep 2011 11:47:29 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3508139E0BC for <rtcweb@ietf.org>; Fri, 23 Sep 2011 11:47:29 +0200 (CEST)
Message-ID: <4E7C55B1.4050704@alvestrand.no>
Date: Fri, 23 Sep 2011 11:47:29 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se> <4E788E5C.9090306@alvestrand.no> <11209B22-4D96-4367-BC31-A4D586B55A83@edvina.net> <27019ED4-BE01-474C-886E-D237DBD6CD2C@cisco.com> <6916F9BA-3296-46DD-9F06-01E3928A8184@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233D45FB9@ESESSCMS0356.eemea.ericsson.se> <8A8889E9-2C33-40DE-90E5-E8F468072F62@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233FB6BA9@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233FB6BA9@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Forking & Early Media - Was Re: Minimal SDP negotiation mechanism
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, 23 Sep 2011 09:44:57 -0000

On 09/23/11 07:06, Christer Holmberg wrote:
> Hi,
>
>>>> The really hard part is knowing which stream to
>>>> use/render/send-to, imho.  And putting that decision in the
>>>> gateway isn't good - the best decider of that is probably the
>>>> JS in the browser.
>>> I am not sure whether the JS app would be able to make
>>> better decisions than the gateway - and I've never seen a SIP
>>> client which would allow the user to choose which early media
>>> to listen to.
>>
>> But these aren't phone-call SIP clients - they're browsers.
>> They can show the multiple video streams in separate windows,
>> for example.  They can show multiple chat sessions per fork
>> too.  Or they may just pick the most recent one and only
>> display it.  That's the nice thing about JS: the JS developer
>> decides what the user experience model is like, based on what
>> type of application/service they're providing; as opposed to
>> the IETF/W3C choosing for them.
> Sure, but it would be good if network applications, that provide the early media, could make assumptions on how the end user is going to process it.
If the network application (whatever that is) delivered the JS to the 
end-user that does the presentation, the network application knows 
exactly how the end user is going to process it (modulo various forms of 
JS local override tricks that browsers and users play).

If the network application didn't, then we're dealing with a proposal 
for an application that may be implemented on top of RTCWEB, but in my 
opinion, we shouldn't encode that into the browser specs.

In other words - "all bets are off".