Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05

[Paul Kyzivat <[e-mail]>]

On 11/1/13 2:10 PM, Martin Thomson wrote:
> On 1 November 2013 13:52, Paul Kyzivat <[e-mail]> wrote:
>>
>> "MediaStreamTrack.readonly Read only
>>      Is a boolean value with a value of true if the track is readonly (such a
>> video file source or a camera that settings can't be modified), false
>> otherwise."
>>
>> That seems to imply that one that isn't read-only must be read-write. I
>> don't see any mention of write-only.
>
>
> This attribute only really pertains to the constraints API, which is
> used to do things like switch cameras between capture modes.  This is
> to do things like change resolutions or capture rates on physical
> devices.  The assumption here is that this interface is not
> appropriate for tracks that originate from the network and so this is
> a clear signal to an application that trying to apply constraints is
> going to fail.

OK, so that doesn't mean what I thought it did. (Sorry, but I haven't 
been following the WebRTC API side of this.)

Looking at:

http://dev.w3.org/2011/webrtc/editor/getusermedia.html#mediastreamtrack

I don't find any notion of readonly or writeonly tracks. If you are 
going to use the presence of readoly and writeonly tracks to determine 
the directionality of the m-line, what property of the track determines 
that?

> I know that this oversimplifies the process and that constraints could
> be used to provide indications back to RTCPeerConnection about what
> constraints to apply to its negotiation functions, but I think that
> the conclusion was that this was overcomplicating things.  And we know
> very well that it is already complicated beyond the comprehension of
> mere mortals anyway.

Its currently beyond my comprehension. Take that for what its worth.

	Thanks,
	Paul