Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Peter Thatcher <pthatcher@google.com> Wed, 19 June 2013 18:36 UTC

Return-Path: <pthatcher@google.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 E5DBF21F9CD1 for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 11:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.744
X-Spam-Level:
X-Spam-Status: No, score=-1.744 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 FMh6NZUftHA4 for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 11:36:20 -0700 (PDT)
Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2994821F9931 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 11:35:59 -0700 (PDT)
Received: by mail-pb0-f51.google.com with SMTP id um15so5346670pbc.38 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 11:35:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=wmfEnt9Kzs0mktpz8ckPDZAVulEayRRsETV/JfE/swI=; b=ADcco3wkT/1CZWGljA/S/63FhTmYUcPJEV1+P73SadabC6Ah2qxYbUsN9STflzf2Of greAORhB6F+xxSYpv/juGXI6SrK8/Pi+dzZ3zIANelYqN8LZESXwRsegLKRnE92FKAR2 APINu3Rl0QlF+Pjr4uFn80sV6brCHEQqfRnecgHPCOo7Bv/EbJD5JRzv2pPR16NSYdGN J9ddKmDG8jyLMLywK6g9c6pu/uYPNaichyl8w0FZCRDXmHkGAj8+iIUBthgXO9xWB4PE Ui6FfiwB1JVUemjb3hi9g7IZOeW8v3ObRgp6307RwNTUfh19WpuHkkX4oJWLy0yZAAVy FoCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=wmfEnt9Kzs0mktpz8ckPDZAVulEayRRsETV/JfE/swI=; b=nc0pg1pWr/nd1y2+t6X8Y0e12pdLlrEPSYkzhZ27AvDEsiK+dFNQGaV4gFYMmAu9VX nC/pBQ9koNOEsDegNsZP0PXJ9FU49GxlTHvEvzHqLBvmMuwKOmFbZnh8B0C972z7Ba3c PP2AAziaPEVGM3nMcdPM6tTDcyB5g/QhB7xGp02YhArjEq3tbR65JYOAZWSji3pUThkI NsrIiDYcu2mejwpS66R6G3qfnQvncspbUpGdhmonk4ubfcGDvbzYFOpjS40jIx19QkJs w7KSGZJM5T9PZF5ssC0kyQdgQJ8ABEuTlhqQcAci8wARETUka3EnZ9MbdW1QbavEws4M rolw==
X-Received: by 10.66.83.7 with SMTP id m7mr8081399pay.150.1371666958838; Wed, 19 Jun 2013 11:35:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 11:35:18 -0700 (PDT)
In-Reply-To: <CALiegf=q5c=mw9=mCz0nM=TxRZXySbNM=SmQ4Ai1CTH=eRc05A@mail.gmail.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CAHp8n2m4VwkpbdGE+q73qqij5RDCB4Vb-Ui1LmGSx1zmv8TX2g@mail.gmail.com> <CAJrXDUEfdsZJBgkcb=MJnxRmk9ZMTHw39DE=YWa+ngXxvfsQ0A@mail.gmail.com> <51C1D55D.6040905@hookflash.com> <CAJrXDUEcmWDhJ_3sq9W_VS=KvS3TxB1uPMBBm1W5GoPs=PrpMQ@mail.gmail.com> <CALiegf=q5c=mw9=mCz0nM=TxRZXySbNM=SmQ4Ai1CTH=eRc05A@mail.gmail.com>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 19 Jun 2013 11:35:18 -0700
Message-ID: <CAJrXDUE-Cwz3aLwLt0Ro5Lb9PQwhwAvor_peP7K=+4aQmjX3hA@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
Content-Type: multipart/alternative; boundary="f46d042ef48dd4ff0d04df8619c0"
X-Gm-Message-State: ALoCoQmjQeBUR+wv79JjDIVYRoWAsiliHtV5VpgXaQHuuCPYmQ2aRC1jI0gB7x4FaxTYdIGlN15udC8uBNKRJRBbvSNkSZS3uh32XUoAazZ2decyfuGQITagALrZ3uWtHFnYKTaHT0TWD70sFh5z29jDabDGgE62fH0xGnpj36Onv5R7WVL1nirH1XgLQQNvksPUxZST98dz
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
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: Wed, 19 Jun 2013 18:36:21 -0000

On Wed, Jun 19, 2013 at 10:20 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

> 2013/6/19 Peter Thatcher <pthatcher@google.com>
>
> > You don't need a lower level API.  SDP munging can get you what you
> need.  But what you want is to not have to do SDP munging.
> >
> > My proposal is to add two methods to PeerConnection that, if optionally
> used by JS, will give you what you want for media streams: the ability to
> control what is sent and received without SDP munging.  It does not,
> however, relieve you from SDP munging on the transport side.  But as I've
> pointed out, that's limited to about 10 lines of SDP, so at least it's much
> less SDP munging.  Later, once could consider more simple additions that
> reduce the need for SDP munging further.
>
>
> You base your proposal on the fact that SDP is here forever and must
> be used in WebRTC, and then propose some new API methods along with
> *lot* of SDP JS parsing/mangling/hackery to mitigate the API
> limitations.
>

Not quite.  I base my proposal on the fact that you can currently do
everything via SDP mangling, and I propose a simple addition that would
allow getting rid of a lot of that SDP munging.    There is still some,
which could theoretically be addressed with more future additions, but at
least the munging is greatly reduced with my proposal.

I also assume that blowing up everything and started over without SDP in
the browser isn't going to fly with the WG.  I'd be happy to be proven
wrong, but I'm trying to be realistic.


>
> While it could be the best we have for now, IMHO it is still a hack or
> workaround to just circumvent the real problem and the real
> limitation.
>

There are two parts to the real problem: transports and streams.  My
proposal solves one of them and leaves the other for future improvement.  I
thing it's better than just a hack or circumvention.


> Things can be done much better if we remove SDP from the equation.


I won't disagree, but I don't think it's realistic with the WG to remove
SDP from the API.  I think the best we can get is to allow SDP to choose
wether to use SDP or not.  Choose your battles.


>
>
> Best regards.
>
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>