W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2014

Re: Doohickeys - slightly another take

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 21 Apr 2014 11:47:44 -0700
Message-ID: <CABkgnnVBPGhXRG3th_42CMi4zVKtDXt8dCbE3R10uavvnALnug@mail.gmail.com>
To: "Suhas Nandakumar (snandaku)" <snandaku@cisco.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 20 April 2014 12:48, Suhas Nandakumar (snandaku) <snandaku@cisco.com> wrote:
> interface MediaFlow implements Constrainable
> {
>   attribute  RTCIceConnection iceConnnectionState; // transport state
>   attribute  RTCIceGatheringState iceGatheringState; // transport state
>   attribute DOMString CNAME;
>   ...
> }

I think that this encapsulates all the problems with this proposal:

1.  I think that this leaps to the conclusion that constraints are
right without strong enough justification.  Constrainable is a
powerfully generic tool, and I'd want to see stronger evidence that a
less generic mechanism is not going to work before I'd be happy with

  flow.pause()/flow.resume()/flow.stop() might work for the stopping case
  flow.priority = "high" seems workable for the other case

2. As a result of the above, this does a grand hand-wave over the
details for layering and simulcast.  No one has really sat down and
carefully described what it means to "control" layering.  Until I see
that, I can't make any assessments about proposed APIs.

3. MediaFlow is bound to a MediaStreamTrack.  Without another layer of
abstraction for transport(s), the ICE states have a cardinality issue.

4. Since tracks can be sent on multiple RTCPeerConnection instances, I
assume that the original argument to addTrack() can't be modified to
include the MediaFlow.  Therefore, I conclude that the direction of
the arrow (MediaStream -> MediaFlow) is backwards.
Received on Monday, 21 April 2014 18:48:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:55 UTC