Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2013 13:37:39 +1000

Hello Roni,

How would you envisage using this for CLUE? Would a "CLUE capture ID" 
attribute need to be defined?
i.e. a=appID:2 CLUECapID:1

or something else?

Regards, Christian

On 29/06/2013 2:31 AM, Mary Barnes wrote:
> ---------- Forwarded message ----------
> From: Roni Even <[email-masked]>
> Date: Fri, Jun 28, 2013 at 10:54 AM
> Subject: [MMUSIC] FW: New Version Notification for
> draft-even-mmusic-application-token-00.txt
> To: "[email-masked]" <[email-masked]>
>
>
> Hi,
> We have submitted this document that  defines a mechanism to provide
> the mapping between the
>     SSRCs of RTP streams and the application semantics by defining
> extensions to RTP and RTCP messages.
>
> It defines a new SDP attribute, RTCP SDES message and RTP header
> extension for this puropose. The document explains how it can be used
> with the different multiplexing proposal (Plan A, Plan B and no plan).
>
> It can be used also in CLUE to map SSRCs to Clue media capture.
>
> Please review and send comments
> Thanks
> Roni Even
>
> ________________________________________
> From: [email-masked] [[email-masked]]
> Sent: Friday, June 28, 2013 6:27 PM
> To: Jonathan Lennox; Qin Wu; Roni Even
> Subject: New Version Notification for
> draft-even-mmusic-application-token-00.txt
>
> A new version of I-D, draft-even-mmusic-application-token-00.txt
> has been successfully submitted by Roni Even and posted to the
> IETF repository.
>
> Filename:        draft-even-mmusic-application-token
> Revision:        00
> Title:           The Session Description Protocol (SDP) Application
> Token Attribute
> Creation date:   2013-06-28
> Group:           Individual Submission
> Number of pages: 11
> URL:
> http://www.ietf.org/internet-drafts/draft-even-mmusic-application-token-00.txt
> Status:
> http://datatracker.ietf.org/doc/draft-even-mmusic-application-token
> Htmlized:
> http://tools.ietf.org/html/draft-even-mmusic-application-token-00
>
>
> Abstract:
>     The RTP fixed header includes the payload type number and the SSRC
>     values of the RTP stream.  RTP defines how you de-multiplex streams
>     within an RTP session, but in some use cases applications need
>     further identifiers in order to identify the application semantics
>     associated with particular streams within the session.
>
>     This document defines a mechanism to provide the mapping between the
>     SSRCs of RTP streams and the application semantics by defining
>     extensions to RTP and RTCP messages.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Roni Even" <[email-masked]>
Date: Tue, 9 Jul 2013 11:40:25 +0300

Hi Christian,
This is something we need to look at, is it to a captureID or to a capture
encoding. 

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Groves
> Sent: 09 July, 2013 6:38 AM
> To: [email-masked]
> Subject: Re: [clue] Fwd: [MMUSIC] FW: New Version Notification for draft-
> even-mmusic-application-token-00.txt
> 
> Hello Roni,
> 
> > has been successfully submitted by Roni Even and posted to the IETF
> > repository.
> >

---

From: Christian Groves <[email-masked]>
Date: Tue, 09 Jul 2013 20:59:05 +1000

Hello Roni,

It probably would be the capture encoding, however the main question was 
whether a new attribute would be needed?

Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Jul 2013 11:02:16 -0400

> This is something we need to look at, is it to a captureID or to a capture

Making it a captureID is insufficient if multiple encodings of the same 
capture have been configured. So IMO it can't be that.

Making it a capture-encoding will cover precisely what we configure, so 
it is a reasonable choice.

But having it be just an Encoding can also work, because at any point in 
time an encoding is configured with at most one capture. So the 
encodingID is sufficient to determine the captureID. And having it be 
just an encodingID would be especially convenient if we describe 
encodings in SDP, because then the linkage would have some significance 
even without the clue messaging.

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 9 Jul 2013 14:34:10 -0400

> i.e. a=appID:2 CLUECapID:1

Not to speak for Roni, but as his co-author, my vague idea is that we'd bind appIDs to m-lines (either one per m-line, or multiple per m-line, depending on whether MMUSIC goes with Plan A or Plan B); then the CLUE channel would associate appIDs to either encodings or capture encodings (depending on decisions in this group).

--
Jonathan Lennox
[email-masked]

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Fri, 12 Jul 2013 11:40:22 +0000

I like the application token draft and find it very useful that its independent of CLUE to be reusable in other use cases as well.  

I think CLUE capture ID should build on the application-id . We should avoid having both application-id and capture-id in the signaling, that sounds like doubling of information. The app-id could mean a concrete capture with a given set of encoding values, which we have referred to as capture encodings.  

Regards 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jonathan Lennox
Sent: 9. juli 2013 20:34
To: Christian Groves
Cc: [email-masked]
Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt

--
Jonathan Lennox
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jul 2013 16:59:57 -0400

> I think CLUE capture ID should build on the application-id . We should avoid having both application-id and capture-id in the signaling, that sounds like doubling of information. The app-id could m…

I have to keep saying this:

This needs to be the id of a capture-encoding, not of a capture, because 
there can be multiple encodings of a capture.

It can potentially be just an encoding ID, because an encoding can only 
be mapped to one capture at a time, so that given an encoding id you can 
look up the corresponding capture id (based on currently active 
configuration.)

	Thanks,
	Paul

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Mon, 15 Jul 2013 08:00:58 +0000

Agree. 

As a receiver of a specific application-id I can map an ID back to a capture with a set of encoding attributes. In the CLUE framework I think that is named a capture encoding. 

Cheers 

-Espen 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 12. juli 2013 23:00
To: [email-masked]
Subject: Re: [clue] [MMUSIC] FW: New Version Notification for draft-even-mmusic-application-token-00.txt

This needs to be the id of a capture-encoding, not of a capture, because there can be multiple encodings of a capture.

It can potentially be just an encoding ID, because an encoding can only be mapped to one capture at a time, so that given an encoding id you can look up the corresponding capture id (based on currently active
configuration.)

	Thanks,
	Paul

> Subject: Re: [clue] [MMUSIC] FW: New Version Notification for 
>>> extension for this puropose. The document explains how it can be 
>>> used with the different multiplexing proposal (Plan A, Plan B and no plan).
>>>
>>> http://www.ietf.org/internet-drafts/draft-even-mmusic-application-to
>>> k
>>> en-00.txt
>>> Status: