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

["Roni Even" <[e-mail]>]

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: 30 June, 2013 7:03 PM
> To: Roni Even
> Cc: [e-mail]
> Subject: 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: [e-mail] [mailto:[e-mail]] On
> >> Behalf Of Paul Kyzivat
> >> Sent: 29 June, 2013 6:59 PM
> >> To: [e-mail]
> >> 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.


[Roni Even] In section 3 there is the following text
" Each value of the AppID maps to one SSRC at a time.  When a new SSRC
   is mapped to an existing AppID using an RTP header extension or SDES
   message, it replaces the previous RTP stream for this application
   usage."

> 
> 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.
[Roni Even]This needs clarification in the previous text. If the mapping is
changed using SDES or RTP header it is the current mapping so if a new offer
is sent it should use the current SSRC mapping.  

> 
> > 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.
[Roni Even] We have a problem in the syntax. We did not mean to allow
mapping two SSRCs to the same AppID. The usage for the syntax was to allow a
preannounce of AppIDs for example "a=appID:2,3" to allow them to be used
later in SDES or RTP header and know to which m-line they correspond. So we
will need to change the syntax.

> 
> 	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: [e-mail] [[e-mail]]
> >>> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/mmusic
> >>>
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >
> >