Re: [rtcweb] New Draft - WebRTC JS Object API Model

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Mon, 01 July 2013 06:46 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 2880C21F9F35 for <rtcweb@ietfa.amsl.com>; Sun, 30 Jun 2013 23:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 NTa2z9UN9zCt for <rtcweb@ietfa.amsl.com>; Sun, 30 Jun 2013 23:45:55 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C61C021F9F2F for <rtcweb@ietf.org>; Sun, 30 Jun 2013 23:45:54 -0700 (PDT)
X-AuditID: c1b4fb30-b7ef76d000004bbc-03-51d125a18155
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 45.AE.19388.1A521D15; Mon, 1 Jul 2013 08:45:53 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 08:45:53 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: Robin Raymond <robin@hookflash.com>
Thread-Topic: [rtcweb] New Draft - WebRTC JS Object API Model
Thread-Index: AQHOcibV+w71mSCXSkiQxLiPakqfXQ==
Date: Mon, 1 Jul 2013 06:45:53 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3093E0@ESESSMB209.ericsson.se>
References: <51CA6FEE.6030702@hookflash.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+Jvre5C1YuBBl9XWFn87u5gt1j7r53d gcnj/NYlTB5LlvxkCmCK4rJJSc3JLEst0rdL4MqYuv8VU8E2xYrze6YzNzB+lepi5OSQEDCR +Lj2GjOELSZx4d56ti5GLg4hgcOMEovmLWGBcBYySmxdtIMdpIpNIFBi674FbCC2iIC6xIlj zWDdzED2ncXnwGqEBWwk+j58Zupi5ACqsZXY1sYKUa4nMefzSrASFgEVieaVJxlBbF4BX4np M4+AjRQS0JHYfvIXE4jNCHTQ91NrmCDGi0vcejKfCeJQAYkle85DHS0q8fLxP1YIW0nix4ZL LBD1ehI3pk5hg7C1JZYtfM0MsUtQ4uTMJywTGEVnIRk7C0nLLCQts5C0LGBkWcXInpuYmZNe br6JERgLB7f8NtjBuOm+2CFGaQ4WJXHezXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw BuauO9vvk3Z5zVr7+ddnn//jHrRpFcvCLQJG0tcqGmWkHSQOOX30mV65IEmtfdtNvV8MhS5d p71ENvIImG0Vit3FM1XAQXx7tpq6ZIvfkc1XTOx2c0mKb3B3vLXGUfIL+2aJn7fZnb9npi3f n1V64lDRDaPXH/4WxGofv2q2Ybd5KHdi84NeJZbijERDLeai4kQApQ8ogVMCAAA=
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model
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: Mon, 01 Jul 2013 06:46:02 -0000

I had a quick look at the use-cases in section 4, and have some comments:

4.1: What is "hold" really? Seems like a very SIP specific thing and 
nothing someone building a service that not interop with legacy would 
ever care about. Could the intended functionality be expressed in terms 
like "pause/resume" on MediaStreamTrack level? And, getUserMedia would 
never produce an SDP.

4.2: The model to specify video properties of a video track is to use 
constraints. And it is the generator/sender of the video that has 
control. So for the scenario described, the app at browser A would have 
to tell - in some not standardized way - the app at browser B that it 
wants to have the video in another format, and the app at browser B 
would have to modify some constraint. Not SDP involved (unless the new 
constraint applied would trigger a new SDP o/a initiated by browser B).

4.3: Nice use-case. What should happen if client D wants to enter later? 
Do you imply that all peer-2-peeer connections use the same keys and 
fingerprints?

4.4: I have always been told that in scenarios like this the new feature 
(that is described by the SDP extension) will not be used since the 
other end point does not support it. To me this is one of the nice 
things with O/A. Say that a new, better codec is being introduced. It 
won't be in all browsers over night - but I think it is nice if it gets 
used when possible without any changes to the app.

4.5: This really underlines the need to specify in detail what the 
allowed SDP variations are (or, if we remove SDP, to specify any other 
mechanism to exchange the things needed to set up RTP and other things 
going on the wire).

4.6: I'm not sure any SDP exchange would be needed at all. The bitrate 
can be varied between the boundaries already set up, and there is also 
functionality like DTX.


In section 5, I think 5.3.5 "Well Defined Behaviors" is a key 
observation. SDP or not, it must be very well specced up what different 
API call really mean, and what is allowed and not.

Note, I am not really trying to defend SDP. I think it should definitely 
not be part of the API - there should be specific API methods available 
instead IMO. I have been assuming it could be a tool for telling the 
other browser how it should use the incoming RTP, but we've all seen the 
problems with agreeing on the format (with all Plan's).

But I think we should split things up. One thing is what API methods we 
have need for. Another what signaling is needed between end-points, and 
how it is done. And this part could be split up in categories like 
things needed to be signaled to establish connection, to set up 
transmission of media and data over the connection, to change the 
characteristics of how media is transmitted.

Stefan


On 2013-06-26 06:37, Robin Raymond wrote:
>
> *
>
> According to many, real adoption of WebRTC will not happen if we
> continue to force everyone to use this SDP Offer/Answer methodology.  It
> is clearly blocking our way forward and the amount of specification
> documentation remaining needed for the browser vendors to produce a
> compatible SDP based WebRTC engine in a browser is much more daunting
> than most are willing to admit.
>
>
> The draft rationale behind a JavaScript Object API model:
>
> http://www.ietf.org/internet-drafts/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt
>
> Whereas:
>
> The WebRTC JavaScript Object API & Shim document will be along shortly.
>
>
> We wanted to get this initial rationale draft informational document out
> right away. Everyone that has any interest should review the reasons and
> concepts and comment before we get too far along on the details of an
> actual API, the initial API will follow in the coming days.
>
>
> Best regards,
>
> Robin Raymond*
>