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

Martin Thomson <> Tue, 29 October 2013 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C81BB21F8E97 for <>; Tue, 29 Oct 2013 11:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.52
X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MqC9rtQwo9sc for <>; Tue, 29 Oct 2013 11:27:38 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::235]) by (Postfix) with ESMTP id AD57811E8110 for <>; Tue, 29 Oct 2013 11:27:35 -0700 (PDT)
Received: by with SMTP id t60so242296wes.40 for <>; Tue, 29 Oct 2013 11:27:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ObuDvM3m2hsLUojezhB43nYcftkUhqF9SKkmMbV4VGI=; b=Fw/NDHeBvsvnKWq7E5ROnQoSNXeTP1wXXYBtb3DYOnr7fdBxD0+RQqIExc/62avZsD /XEmJ4rHaqmGXbLOwIVTY/DkCD4+5V+2wAC+5EoOTFX1fS0BdcxyyPSWAag0sIJlYXlg dVwefE/9Og8eJw6ZqEf7U1zBoMnDB1K1KuR9N2B8jqH9xP+DAHNQqVovgvt5v+iF2E6c 4r4hYW5jgbZlaYLtwf7DL4Zu2SzCJ6QglBVuCQEiCk7zYeQBTwugZWlVmHTlaZ5p2/lX jMAEw9XEY2W0m33Sg+1gkIlYYKUSw2sJi/Wfol4aM+s8qEixCsQgMIfnMIvrHvlKY3aO vS/Q==
MIME-Version: 1.0
X-Received: by with SMTP id 12mr947393wjt.64.1383071254684; Tue, 29 Oct 2013 11:27:34 -0700 (PDT)
Received: by with HTTP; Tue, 29 Oct 2013 11:27:34 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 29 Oct 2013 11:27:34 -0700
Message-ID: <>
From: Martin Thomson <>
To: Paul Kyzivat <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
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: Tue, 29 Oct 2013 18:27:38 -0000

On 29 October 2013 08:05, Paul Kyzivat <> wrote:
> How is this expected to work? Is the browser supposed to do this in the
> absence of a MediaStreamTrack?

As I understand it, and my understanding is probably imperfect [22],
the idea is that at all points where an offer or answer is
constructed, the using application has access to MediaStreamTrack
objects that relate to the various m-lines.  Mostly.

That is, prior to creating an offer, you have the MediaStreamTrack
instances that relate to what you are sending.  And Prior to creating
an answer, you have both the tracks you want to send and the ones that
you want to receive.  Adam has proposed [2] that enabling or disabling
these tracks causes the appropriate a=sendonly/etc. attribute to be

The only case that is a little strange is the one relating to the
received streams when creating an initial offer, where you use the
OfferToReceiveAudio or OfferToReceiveVideo constraint in order to
indirectly control the send/recv attributes.

[22] by which I do not offer as a failing on my part, ...