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

[Stefan Håkansson LK <[e-mail]>]

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*
>