Re: [rtcweb] Convey "label"

Justin Uberti <juberti@google.com> Fri, 09 September 2011 16:13 UTC

Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5396D21F8B9F for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 09:13:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.738
X-Spam-Level:
X-Spam-Status: No, score=-104.738 tagged_above=-999 required=5 tests=[AWL=-0.728, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7WfU5rhAgK0x for <rtcweb@ietfa.amsl.com>; Fri, 9 Sep 2011 09:13:24 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2E121F8B9C for <rtcweb@ietf.org>; Fri, 9 Sep 2011 09:13:23 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p89GFITX007385 for <rtcweb@ietf.org>; Fri, 9 Sep 2011 09:15:18 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1315584918; bh=zEpiMyZi598NFN6fNWripUqd7AI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=s0o/IRsLt/RQr+eCvQONvEiNZjQQdolbCpKPgJMBBiOcV3Bqkvgw84NHqZc+dKwAR n6a4/m8Q+jTTpAzPqTeWA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=O6RP6OdvrSMfb2npZFgeiXEnrPAUv6JCWch/FOflahiPY7KhhVlMrkKK2TPR6sRUR uR7VMRLDsUIHpVXhEdnbw==
Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by hpaq12.eem.corp.google.com with ESMTP id p89GE79l018798 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <rtcweb@ietf.org>; Fri, 9 Sep 2011 09:15:16 -0700
Received: by gyf2 with SMTP id 2so2073350gyf.13 for <rtcweb@ietf.org>; Fri, 09 Sep 2011 09:15:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=G5L3oZcFAmI5P3AKdN3ye6IrRKY6uNaqseAQ8WHc37A=; b=o5aFPLPGk02LoxULZjU8Wuonb+3ON6q+6pQSgCVnrYIA6VM5TXhRsd7hqHx5vVgyQ/ XYavruNwARsEQNRgWM2Q==
Received: by 10.42.134.2 with SMTP id j2mr1212791ict.149.1315584916496; Fri, 09 Sep 2011 09:15:16 -0700 (PDT)
Received: by 10.42.134.2 with SMTP id j2mr1212786ict.149.1315584916265; Fri, 09 Sep 2011 09:15:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.36.10 with HTTP; Fri, 9 Sep 2011 09:14:56 -0700 (PDT)
In-Reply-To: <4E6A1107.8090302@ericsson.com>
References: <4E69B77E.7090205@ericsson.com> <DC53C7A0-64E0-4BA1-8111-39B974879DA3@edvina.net> <56C22F41-852F-4B20-A907-1181FE77E854@csperkins.org> <58801C7D-AAD4-4C27-A2C2-6378AF18DBFE@edvina.net> <CAOJ7v-16AZLHyESMGSVV5_W1zXOfUErqRRxBB8K9P8cxVpwiEg@mail.gmail.com> <4E6A1107.8090302@ericsson.com>
From: Justin Uberti <juberti@google.com>
Date: Fri, 9 Sep 2011 12:14:56 -0400
Message-ID: <CAOJ7v-29oKovfN-mb5TrYnviO1q5ry8mmQNny0Mhd8wO5D3p5g@mail.gmail.com>
To: =?UTF-8?Q?Stefan_H=C3=A5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
Content-Type: multipart/alternative; boundary=90e6ba6e8dba9b1b2d04ac847bd8
X-System-Of-Record: true
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Convey "label"
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 09 Sep 2011 16:13:25 -0000

On Fri, Sep 9, 2011 at 9:13 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 2011-09-09 14:58, Justin Uberti wrote:
>
>>
>>
>> On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson <oej@edvina.net
>> <mailto:oej@edvina.net>> wrote:
>>
>>
>>    9 sep 2011 kl. 09:07 skrev Colin Perkins:
>>
>>     > On 9 Sep 2011, at 07:53, Olle E. Johansson wrote:
>>     >> 9 sep 2011 kl. 08:51 skrev Stefan Håkansson LK:
>>     >>> there was a discussion yesterday of how to convey the Id (aka
>>    "label") of a MediaStream object when it is sent over a
>>    PeerConnection. Presumable this info would be in the SDP offer (or
>>    whatever we end up using). There was a discussion on if CNAME could
>>    be used or if we need something new.
>>     >>>
>>     >>> You mentioned that it would be quite easy to add a new element
>>    or attribute if we would need that. Could you explain a bit more?
>>     >>
>>     >> Just a kind reminder that there are application specific fields
>>    that we can use in RTCP too...
>>     >
>>     >
>>     > I was actually thinking of a new RTCP SDES item type to convey
>>    the label.
>>     >
>>    Side note: I know we're not talking SIP, but it actually touches
>>    Hadriel's Session ID proposal too...
>>
>>
>> It's not clear to me that we need a MediaStream to have a label, or any
>> identifier other than CNAME, unless it's meant to be some sort of
>> "display name" for that particular stream. If there are other expected
>> usages of the label, I'd be interested to know what they are.
>>
> The main purpose of an identifier of MediaStream's I see is to be able to
> reference them after transport over a PeerConnection. If several
> MediaStreams are sent over a PC, you need to be able to reference them - all
> the receiving app gets is "addstream" events.
>
> Of course you could add them one by one in a determined order, but that
> would mean that set up takes longer than required.
>
> I'm not sure CNAME can fulfill this purpose in all cases or not.


Right, I agree the app needs to be able to say "this video feed is for user
A" and "this video feed is for user B", if for no other reason than to be
able to display a user identifier underneath the appropriate video feed.
However as mentioned previously I think that this implies that each feed
(i.e. track) requires an identifier, not necessarily the stream. So I
propose we add a unique label attribute for tracks, which is essentially a
handle; this handle allows clear identification of a track, and can be
passed around in application messaging if needed. We may also want to allow
a non-unique display name to be provided as well.

I see no harm in having MediaStream's label be the CNAME, as a portable
handle for MediaStreams, but I haven't yet heard a use case where one would
use this handle instead of the track handle.


>
> ______________________________**_________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>