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

Harald Alvestrand <> Sat, 02 November 2013 06:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F24A21E80FB for <>; Fri, 1 Nov 2013 23:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SeL6eENnTtjJ for <>; Fri, 1 Nov 2013 23:00:20 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 79E5611E81B7 for <>; Fri, 1 Nov 2013 23:00:06 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3067239E4D1 for <>; Sat, 2 Nov 2013 06:59:49 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u--1Gw3w37Ca for <>; Sat, 2 Nov 2013 06:59:47 +0100 (CET)
Received: from [] ( []) by (Postfix) with ESMTPSA id DC32E39E12F for <>; Sat, 2 Nov 2013 06:59:46 +0100 (CET)
Message-ID: <>
Date: Sat, 02 Nov 2013 06:59:44 +0100
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] inactive m-lines in draft-ietf-rtcweb-jsep-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 02 Nov 2013 06:00:25 -0000

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 <> 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:
> 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).


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

Surveillance is pervasive. Go Dark.