Subject: [rtcweb] Convey "label"

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 9 Sep 2011 08:51:42 +0200

Colin,

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?

Stefan

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 9 Sep 2011 08:53:43 +0200

9 sep 2011 kl. 08:51 skrev Stefan Håkansson LK:

> Colin,
> 
> 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...

/O

---

From: Colin Perkins <[email-masked]>
Date: Fri, 9 Sep 2011 08:07:39 +0100

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

-- 
Colin Perkins
http://csperkins.org/

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 9 Sep 2011 09:09:19 +0200

> I was actually thinking of a new RTCP SDES item type to convey the label.

Does this mean it would be conveyed by RTCP (and not by e.g. SDP)? 
(Sorry to ask stupid questions).

---

From: Colin Perkins <[email-masked]>
Date: Fri, 9 Sep 2011 08:20:15 +0100

On 9 Sep 2011, at 08:09, Stefan Håkansson LK wrote:
> Does this mean it would be conveyed by RTCP (and not by e.g. SDP)? (Sorry to ask stupid questions).

I'd guess you'd need something in SDP too, although I haven't followed the API closely enough to be sure. I suggested a new RTCP SDES item because the CNAME didn't seem to have quite the right semantics, but otherwise seemed to be conveyed in the way people wanted.

-- 
Colin Perkins
http://csperkins.org/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 9 Sep 2011 09:55:17 +0200

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

/O

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Sep 2011 08:58:32 -0400

On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson <[email-masked]> wrote:

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

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 9 Sep 2011 15:13:43 +0200

On 2011-09-09 14:58, Justin Uberti wrote:
>
>
> On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>      >>> 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?
>      >>
> 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.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 9 Sep 2011 12:14:56 -0400

On Fri, Sep 9, 2011 at 9:13 AM, Stefan Håkansson LK <
[email-masked]> wrote:

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

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
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 12 Sep 2011 09:31:51 +0200

On 2011-09-09 18:14, Justin Uberti wrote:
>
>
> On Fri, Sep 9, 2011 at 9:13 AM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         On Fri, Sep 9, 2011 at 3:55 AM, Olle E. Johansson
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>
>     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.
>
> 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.

This is an interesting idea. However, in the html5 spec media elements 
deal with 'media resources' which can have multiple tracks of audio and 
video. To be able to reuse what is already in place (e.g. audio and 
video elements) I think we should conform to this.

Besides, if you can identify the MediaStream, it is quite 
straightforward to reference a specific track in it as it is the same 
tracks on both sides of the PeerConnection.

> 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
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>