IETF Logo Mail Archive

Re: [rtcweb] Rejecting MediaStreamTracks in JSEP

Jonathan Lennox <jonathan@vidyo.com> Mon, 03 February 2014 22:32 UTC

Return-Path: <jonathan@vidyo.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AA11A01EE; Mon, 3 Feb 2014 14:32:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.13
X-Spam-Level:
X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4crGNX-tLnbZ; Mon, 3 Feb 2014 14:32:21 -0800 (PST)
Received: from server209.appriver.com (server209g.appriver.com [8.31.233.122]) by ietfa.amsl.com (Postfix) with ESMTP id CF7FA1A015D; Mon, 3 Feb 2014 14:32:20 -0800 (PST)
X-Note-AR-ScanTimeLocal: 2/3/2014 5:32:18 PM
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Policy: GLOBAL - vidyo.com
X-Primary: jonathan@vidyo.com
X-Note: This Email was scanned by AppRiver SecureTide
X-Virus-Scan: V-
X-Note-SnifferID: 0
X-Note: TCH-CT/SI:0-145/SG:5 2/3/2014 5:32:05 PM
X-GBUdb-Analysis: 0, 162.209.16.214, Ugly c=0.765737 p=-0.947836 Source White
X-Signature-Violations: 0-0-0-6034-c
X-Note-419: 0 ms. Fail:0 Chk:1345 of 1345 total
X-Note: SCH-CT/SI:0-1345/SG:1 2/3/2014 5:32:06 PM
X-Note: Spam Tests Failed:
X-Country-Path: ->UNITED STATES->LOCAL
X-Note-Sending-IP: 162.209.16.214
X-Note-Reverse-DNS:
X-Note-Return-Path: jonathan@vidyo.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G327 G328 G329 G330 G334 G335 G445
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: VALID
X-Note: Headers Injected
Received: from [162.209.16.214] (HELO mail.vidyo.com) by server209.appriver.com (CommuniGate Pro SMTP 6.0.2) with ESMTPS id 94746033; Mon, 03 Feb 2014 17:32:18 -0500
Received: from 492132-EXCH1.vidyo.com ([fe80::50:56ff:fe85:4f77]) by 492133-EXCH2.vidyo.com ([fe80::50:56ff:fe85:6b62%13]) with mapi id 14.03.0146.000; Mon, 3 Feb 2014 16:32:17 -0600
From: Jonathan Lennox <jonathan@vidyo.com>
To: Justin Uberti <juberti@google.com>
Thread-Topic: [rtcweb] Rejecting MediaStreamTracks in JSEP
Thread-Index: AQHPIS46pADKsTFIzECMWWmLIWbna5qkgc6A
Date: Mon, 03 Feb 2014 22:32:17 +0000
Message-ID: <C433A27C-348A-402A-B036-07060746FADA@vidyo.com>
References: <CAOJ7v-22T7hLMdC2je0nLk34MXQ8L+JFWLtAz--6Ryt+DMaMvQ@mail.gmail.com>
In-Reply-To: <CAOJ7v-22T7hLMdC2je0nLk34MXQ8L+JFWLtAz--6Ryt+DMaMvQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [160.79.219.114]
Content-Type: multipart/alternative; boundary="_000_C433A27C348A402AB03607060746FADAvidyocom_"
MIME-Version: 1.0
Cc: Cullen Jennings <fluffy@cisco.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>, mmusic <mmusic@ietf.org>
Subject: Re: [rtcweb] Rejecting MediaStreamTracks in JSEP
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Feb 2014 22:32:22 -0000

On Feb 3, 2014, at 2:27 PM, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote:

Also, this essentially makes recv-appId the converse of MSID; for simplicity, I think we should consider unifying these concepts into a single document.

AppID (as I envision it, as the author) and MSID (as I understand it) have rather different scopes, which are visible once sources are sent using more than one packet stream.

For example, an m-line which has both a primary encoded stream (of media) and a redundancy stream (of rtx packets) would have two appid values, but only one msid.  On the receive side, if you wanted to receive both a primary encoded stream and a redundancy stream, you would have two recv-appid values.

As such, appid and msid are solving different (though related) problems, and I don't think unifying them is a good idea.

Perhaps we need a recv-msid, explicitly?

v2.23.0 | Report a Bug | By Email