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

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Nov 2013 13:52:53 -0700

On 10/29/13 12:07 PM, Martin Thomson wrote:
> On 29 October 2013 11:53, Paul Kyzivat <[email-masked]> 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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Nov 2013 14:10:39 -0700

On 1 November 2013 13:52, Paul Kyzivat <[email-masked]> wrote:
>     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."
>

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.

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.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Nov 2013 15:49:40 -0700

> a clear signal to an application that trying to apply constraints is

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?

> very well that it is already complicated beyond the comprehension of

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

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 02 Nov 2013 06:59:44 +0100

On 11/01/2013 11:49 PM, Paul Kyzivat wrote:
> the directionality of the m-line, what property of the track
> determines that?

A MediaStreamTrack is unidirectional. Think of it as an SSRC; it helps
(even though simulcast and repair flows make the picture more complex).

The basic decision of UnifiedPlan was to map a maximum of 2
MediaStreamTracks (one in each direction) to each m-line.

So the directionality of an m-line is dictated by whether there are
tracks mapped to it in each direction, and whether they are active (if
we decide to map "active"; this isn't clearly decided yet, I think).

Table:

Tracks that are mapped
to this M-line                            Resulting m-line state at A

None                                        a=inactive
A->B, disabled                         a=inactive
A->B, enabled                         a=sendonly
A->B enabled, B->A disabled  a=sendonly
A->B enabled, B->A enabled  a=sendrecv

I think you can complete the rest of the table in your head.

The defense for this somewhat arcane mechanism is that it creates SDP
that interoperates with endpoints that expect one outgoing and one
incoming video track, both described by the same M-line.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

-- 
Surveillance is pervasive. Go Dark.

---

From: Justin Uberti <[email-masked]>
Date: Sun, 3 Nov 2013 23:35:56 -0800

Harald's understanding is correct.

Concerning the original question about Section 5.3.1, the text tried to
indicate that the processing described should be performed for each "send"
MediaStreamTrack. The local endpoint has no control over how the remote
endpoint associates MSTs with m= lines. However, the mapping of "enabled"
to the directional attribute is something we need to discuss, and if
sensible, write into the draft.