- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Mon, 21 Apr 2014 11:47:44 -0700
- 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
this.
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