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

[Paul Kyzivat <[e-mail]>]

On 10/29/13 12:07 PM, Martin Thomson wrote:
> On 29 October 2013 11:53, Paul Kyzivat <[e-mail]> wrote:
>> This maps each MediaStreamTracks of a given type to a different m-line. I
>> *thought* the use of "specified type" above meant audio/video. Am I missing
>> something?
>
> Yes.  sort of, though I'd expand "type" to encompass the concept of
> compatibility.  Obviously a source with an H.264 encoder can't be
> bound to an m= section that only has VP8 negotiated.
>
> 1. RTCPeerConnection binds tracks to m= sections
> 2. For sending tracks, that binding is tentatively made when an offer
> or answer is constructed
> 3. Sending tracks are bound when setLocalDescription is called
> 4. For receiving tracks, that binding is made when the track is made,
> which is when setRemoteDescription is called
>
> When generating offers or answers, the set of bindings (including
> tentative ones) - plus the enabled state of the track - determines
> what of the send/recv attributes is attached to that m= section.

It would be nice for this to be clearer in this draft.
The binding of potentially *two* MediaStreamTracks to each m-line isn't 
apparent to me from the existing text.

IIUC you are assuming a sendrecv m-line will map to two unidirectional 
MediaStreamTracks. Looking at a description of the MediaStreamTrack API 
I find:

"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.

	Still confused,
	Paul