Re: [rtcweb] We are moving beyond the assumptions on which O/A is based

Ted Hardie <ted.ietf@gmail.com> Tue, 14 May 2013 16:38 UTC

Return-Path: <ted.ietf@gmail.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 DD64521F9128 for <rtcweb@ietfa.amsl.com>; Tue, 14 May 2013 09:38:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
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 OtuG2E5A8YvC for <rtcweb@ietfa.amsl.com>; Tue, 14 May 2013 09:38:46 -0700 (PDT)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9D44621F9121 for <rtcweb@ietf.org>; Tue, 14 May 2013 09:38:46 -0700 (PDT)
Received: by mail-ie0-f178.google.com with SMTP id b11so1459424iee.23 for <rtcweb@ietf.org>; Tue, 14 May 2013 09:38:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0Hqym6ykdN/k3rO+71w+L8U8JNRRjM8987aFerWzfAI=; b=JhM6R6aUasOg3q0nLv7mvVZRgfBbMHdyDOhnn07Jm9ZLkJ1LgLXsm5/U4mtt4zAQuX Lp6J2ey5HUibI4dqqGdUqN+YMC1+u8SXva9hVmv4jdGEDrvnSoQ75tF5q2Rpz/NTh0wk 4H1adApqC8kvtS/zidDQk/gMa1PKKavW/1A3w11ccD2Nta2PestD1jUkj0qJSah3zDMh KIYrF/zYUKVwTA4tmoVvTaEn1MecQrxd+5taepILdEgdfoBO2FUEQbm4EKRPVFEG5HKE /kBryAV28KVXwRnGJ7NbMlK8+x/qpKTJQukmgQ5OGxrg3THTNQiSaakz3LFXP9WGHJc0 qScQ==
MIME-Version: 1.0
X-Received: by 10.50.128.227 with SMTP id nr3mr2778266igb.24.1368549519245; Tue, 14 May 2013 09:38:39 -0700 (PDT)
Received: by 10.42.79.73 with HTTP; Tue, 14 May 2013 09:38:39 -0700 (PDT)
In-Reply-To: <518E7700.1080906@alum.mit.edu>
References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <CALe60zAi_Lx3QFCbBQ5aPNkgorJAff0E79jkpbQX1Qt3wf2bzg@mail.gmail.com> <CAOJ7v-1Wk6u7XiYrNVmoqr5Jisu2WRvZpte7hQTOiP8YHUc6hg@mail.gmail.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu>
Date: Tue, 14 May 2013 09:38:39 -0700
Message-ID: <CA+9kkMDXRnfm6Bto4k6SB-FZHYDCfH1HWUZVat3uJmqFUQpXkw@mail.gmail.com>
From: Ted Hardie <ted.ietf@gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="047d7b10c81bf3c91404dcb0438f"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based
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 16:38:48 -0000

On Sat, May 11, 2013 at 9:51 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> In clue we are addressing that by exchanging (in a separate channel)
> advertisements of what the endpoints are willing to send, and only doing
> O/A to set up the media that is of interest.
>
> In rtcweb it isn't so structured, but I suspect something is happening
> implicitly, though it may be more hard-wired per application.
>

So, I repeat what I said before, I think you can get to there in RTCWEB,
but it won't be the same way pokerstars gets to where it wants to go.

The simplest thing I can imagine, to just put it out there, is to start
RTCWEB with just a data channel, pass the clue messages on top, then start
the media channels after that's done.  That seems to be reasonably in line
with what you've described above and it's well within the RTCWEB APIs.

What won't happen is for *every* application to adopt that procedure; some
will want behaviour that looks closer to vanilla offer/answer; some will
want behaviour that is more-or-less directed by the server, and some will
want blueberry jam (that is, something we don't know about yet).

regards,

Ted