IETF Logo Mail Archive

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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 18 June 2013 08:31 UTC

Return-Path: <ibc@aliax.net>
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 F20F321F9992 for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 01:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.095
X-Spam-Level:
X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[AWL=-0.617, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, 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 vRZYXXSWVWah for <rtcweb@ietfa.amsl.com>; Tue, 18 Jun 2013 01:31:22 -0700 (PDT)
Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 66E1621F8F5C for <rtcweb@ietf.org>; Tue, 18 Jun 2013 01:31:22 -0700 (PDT)
Received: by mail-qa0-f47.google.com with SMTP id i13so2013117qae.20 for <rtcweb@ietf.org>; Tue, 18 Jun 2013 01:31:21 -0700 (PDT)
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:content-transfer-encoding:x-gm-message-state; bh=CR1LSk65tYF7soiLGpc+oL2MiDfqEQSDo9Bn8zmhgcc=; b=PjX2FpHOOyf/3+Q8EF1sm1zIlfxOoETvfeSYZ1JhsCCZLB40z9fBNbNY/vQDUD2FV+ oC8+QymjtWH0LM0SdBJwhktcCfXg7oOllvqZ92/2AL+QzVESkNu84/MRHAtyped94Su5 0S57LnJpeGUM5pLgQ6b9BVxjdTB1XaQbqXKHE5txdOoT3DDtxLzofjp7wdcSwc39SXe/ kZy2QW7cBWWpuSip12EoyTK+5Z8fuz7HamNeuv96T6FytkWMRvsqIlxyMgzAuZNXTUAA hfM/9PfY4IWVevnY/EW35SV6Xb7K93jfe0qyQl2V14FCZX+fxVTigUu44Ml0roFoyNM7 o/FA==
X-Received: by 10.229.149.198 with SMTP id u6mr8288698qcv.20.1371544281830; Tue, 18 Jun 2013 01:31:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 01:31:00 -0700 (PDT)
In-Reply-To: <CAJrXDUFkdfE2gfkRx6im3qNwjd3ObNv0tGO8O0vht146+A1kfQ@mail.gmail.com>
References: <CAJrXDUHdoxLTsofiwLBdwBNnCCkCBgjSdbmLaXrNEPODMrsSVA@mail.gmail.com> <CABkgnnUmRpanfpwryyiCUsOdMLzrd74n-4LXaj_AK3aLe0yQ8Q@mail.gmail.com> <CAJrXDUGnEwtsGZwUUqQgH0vDnMPy=XxqwQB9fpNcW9yQDhFt4w@mail.gmail.com> <CABkgnnVghXLu0ZdNkBkvLkqr=xgx6irWnyebU6rv+D45M+iaUg@mail.gmail.com> <CAJrXDUFkdfE2gfkRx6im3qNwjd3ObNv0tGO8O0vht146+A1kfQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Date: Tue, 18 Jun 2013 10:31:00 +0200
Message-ID: <CALiegfmMWiEZDL4eCc6VSEsH1z8F6K5Xzz_-Z6hiKiD9yAap0Q@mail.gmail.com>
To: Peter Thatcher <pthatcher@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkMM8dDoXlPz5s24D/8XY+ADE+mtGZIgnh7L2uiJUnIJbZkADH/sagoKbAVR1QAY1l1lL5X
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: Tue, 18 Jun 2013 08:31:23 -0000

2013/6/18 Peter Thatcher <pthatcher@google.com>;:

> That means the
> SDP is really just used as a way to tell the browser what ice ufrag, ice
> pwd, and DTLS fingerprint to use.

And do we really need SDP for that? mandatory?


> It would look something like this
> (forgive me if I got the SDP slightly wrong;  it's easy to get wrong):
>
> v=0

Unneeded line v.


> o=- 697639972863421376 2 IN IP4 127.0.0.1

Unneeded line o.


> s=-
> t=0 0

Unneeded lines s and t.


> m=application 1 DTLS/SCTP 5000

Why is this required at all?


> c=IN IP4 0.0.0.0

Anti-useful c line.


> a=mid:transport

What else can it be?


> a=ice-ufrag:tEP42he9r6LycvmM
> a=ice-pwd:cKJLuvHy9pas9rdezUZB9xet
> a=fingerprint:sha-256
> EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79:C4:95:9C

Finally we get 3 useful fields (related to ICE and encryption). And
are we going to mandate SDP O/A for this? really? I really hope NOT.




> Ignoring ICE candidates and restarts, that's all the SDP what would be
> needed for the whole PeerConnection (one for the local and one for the
> remote).

And WHY do we need to *mandate* SDP for that? Why don't we define a
IceData object, something that can be serialized in JSON to be sent to
the remote peer in any custom way? Why should we deal with blob
strings in an old-school format?




> 10 lines of SDP just to setup a transport isn't quite such an abomination,
> is it?

Yes, because we don't need those 10 lines, but just 3 string values.








> You're not forced to do SDP, except for the transports.  For defining the
> streams, you can avoid SDP altogether.  As a WebRTC JS app developer, I know
> I would find working with this API much better than working with SDP
> munging.

And what is the advantage of mandating usage of SDP for the transport
(over letting the user communicate it to the browser via API by
passing some JS object?).




Regards.


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

v2.1.2.p1 | Report a Bug | By Email