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

[Harald Alvestrand <[e-mail]>]

On 11/01/2013 11:49 PM, Paul Kyzivat wrote:
> 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?

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.



>
>> 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
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Surveillance is pervasive. Go Dark.