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

From: Roni Even <[email-masked]>
Date: Fri, 28 Jun 2013 15:54:38 +0000

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 29 Jun 2013 11:58:45 -0400

I looked this over, and it seems to solve many of the issues at hand.
There are no doubt some nits to iron out, but we should get agreement 
over the concepts before worrying too much about the details.

A couple of things I wanted to comment on:

You give examples of form:
       a=ssrc:11111 AppID:1
But you don't say too much about the meaning of this. The reason I ask 
is that you say elsewhere that the appid can move from one ssrc to 
another. My question is: If this form is used, can that appid later be 
bound to a different ssrc via the header extension? Also, is the 
following legal?
       a=ssrc:11111,22222 AppID:1

My other issue is with:
    In the CLUE WG case the mapping is from an RTP stream to a CLUE media
    capture specified in the CLUE framework [I-D.ietf-clue-framework].
This should be to a CLUE capture-encoding.

	Thanks,
	Paul

On 6/28/13 11:54 AM, Roni Even wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: "Roni Even" <[email-masked]>
Date: Sun, 30 Jun 2013 08:29:58 +0300

Inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 29 June, 2013 6:59 PM
> To: [email-masked]
> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-
> mmusic-application-token-00.txt
> 
> There are no doubt some nits to iron out, but we should get agreement over
> the concepts before worrying too much about the details.
> 
> But you don't say too much about the meaning of this. The reason I ask is
> that you say elsewhere that the appid can move from one ssrc to another.
> My question is: If this form is used, can that appid later be bound to a
> different ssrc via the header extension? Also, is the following legal?
[Roni Even] The AppID can be mapped later using SDES or header extension to
a new SSRC and our view is that this is a replacement. An AppID can be
mapped to a single SSRC at a time.
We looked at having more than one SSRC mapped to a single AppID and decided
to leave it to discussion. It will require to distinguish between adding and
SSRC and replacing an SSRC when a new mapping is specified.
My view is that the unique mapping is clearer and I assume we can look at
using SDP grouping if want to associate two RTP media streams to an
application usage.

Roni

> This should be to a CLUE capture-encoding.
[Roni Even] OK, will fix it
> > 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).
> >
> > has been successfully submitted by Roni Even and posted to the IETF
> > repository.
> >
> > Title:           The Session Description Protocol (SDP) Application
Token
> Attribute
> > Htmlized:
http://tools.ietf.org/html/draft-even-mmusic-application-
> token-00

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 30 Jun 2013 12:02:36 -0400

> mapped to a single SSRC at a time.

OK. That's fine, but then I think the draft should say more about it.

Also, a followup question:

Suppose I start with an offer with

        a=ssrc:11111 AppID:1

and then use SDES or header extension to change move AppID 1 to ssrc 22222.

If there is then another O/A, with the same SDP as before:

        a=ssrc:11111 AppID:1

Does that change the mapping back to 11111, or does it stay as 22222?

This impacts how closely the SDP signaling must be coupled to the media 
processing.

> using SDP grouping if want to associate two RTP media streams to an

I asked about

just because it seemed to be allowed by the syntax. My next question 
would be what it means. E.g, it *could* mean that it is expected that 
11111 and 22222 may both be used, but won't be used simultaneously. If 
it turned out that they *were* used simultaneously, then the effect 
would be to switch rapidly between them.

	Thanks,
	Paul