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

On 6/30/13 1:29 AM, Roni Even wrote:
> Inline
>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> Behalf Of Paul Kyzivat
>> Sent: 29 June, 2013 6:59 PM
>> To: mmusic@ietf.org
>> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-
>> mmusic-application-token-00.txt
>>
>> 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
> [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.

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.

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

I asked about

        a=ssrc:11111,22222 AppID:1

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

> Roni
>
>>
>> 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.
> [Roni Even] OK, will fix it
>>
>> 	Thanks,
>> 	Paul
>>
>> On 6/28/13 11:54 AM, Roni Even wrote:
>>> 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: internet-drafts@ietf.org [internet-drafts@ietf.org]
>>> 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
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>