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

From: "Roni Even" <[email-masked]>
Date: Mon, 1 Jul 2013 14:38:59 +0300

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 30 June, 2013 7:03 PM
> To: Roni Even
> Cc: [email-masked]
> 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: [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
> >>
> >> 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: [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
> >>>
> >>
> >> _______________________________________________
> >> mmusic mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mmusic
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Jul 2013 13:02:58 -0400

Hi Roni. See inline.

>     message, it replaces the previous RTP stream for this application

It still isn't clear to me. You have three ways to communicate the mapping:

- SDP
- SDES
- header extension

I think the relationship and precedence between SDES and header 
extension is well defined in general, so I guess that doesn't need 
further elaboration.

But the relationship between the SDP and the RTP/RTCP mechanisms isn't 
so clear. This is especially problematic because it is impossible to 
synchronize the arrival of SDP with the arrival of RTP/RTCP.

The simplest answer would be to use the SDP as a *default* if the 
mapping hasn't been received in the media, with changes in the SDP 
having no effect on the mapping of a particular AppId once it has been 
mentioned in the media. But I don't know if that is a sufficient mechanism.

Alternatively, the mapping can be defined by whichever has been received 
most recently. But that may cause artifacts.

I just think this needs to be made very clear.

> is sent it should use the current SSRC mapping.

See comments above.

> will need to change the syntax.

OK. So if the intent is not to allow it, then sure, the syntax can be 
tweaked so it isn't possible to say it.

	Thanks,
	Paul

---

From: "Roni Even" <[email-masked]>
Date: Tue, 2 Jul 2013 15:32:01 +0300

> Sent: 01 July, 2013 8:03 PM
> To: Roni Even
> Cc: [email-masked]
> >>>> There are no doubt some nits to iron out, but we should get
> >>>> agreement over the concepts before worrying too much about the
> details.
> >>>>
> >>> 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.
> >>
> > [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
> I think the relationship and precedence between SDES and header extension
> is well defined in general, so I guess that doesn't need further
elaboration.
> 
> But the relationship between the SDP and the RTP/RTCP mechanisms isn't so
> clear. This is especially problematic because it is impossible to
synchronize
> the arrival of SDP with the arrival of RTP/RTCP.
> 
> The simplest answer would be to use the SDP as a *default* if the mapping
> hasn't been received in the media, with changes in the SDP having no
effect
> on the mapping of a particular AppId once it has been mentioned in the
> media. But I don't know if that is a sufficient mechanism.

[Roni Even] I think this make sense because the usage of the SDES and RTP
header is to allow changes without a new O/A what we need to specify is what
should be the SDP in a case when we used mapping to SSRC in the SDP and
after using SDES to remap we will have a new O/A. I think that we should not
try to synchronize the SDP but maybe add a flag that will say the SEDS / RTP
header should be used for the mapping.

> >> 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.
> 
> See comments above.
> 
> >>> 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
> >>
> >> 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.
> > 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.
> 
tweaked so
> it isn't possible to say it.
> 
> 	Thanks,
> 	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 2 Jul 2013 14:56:48 -0400

> extension is well defined in general, so I guess that doesn't need 

Actually, it probably needs some further elaboration in cases where RTP packets arrive out of order (either with respect to themselves or with their RTCP).  But straightforward rules for this can probably be defined fairly easily. 

> I just think this needs to be made very clear.

If we have AppIDs in SDP, I definitely think you need an "RTP associations always win" semantic.

On further reflection, though, I'm now wondering whether to what extent it's actually necessary to have per-SSRC AppIDs defined in SDP at all, since the point of AppID is to define an *alternative* to signaling SSRCs in SDP, by instead defining application semantics with a layer of indirection.

I think (and this was a bit of a point of disagreement between Roni and me in writing the draft) that "Plan B"-style signaling with AppID should use a=AppID:token attribute:value signaling in place of RFC 5576 a=ssrc:number attribute:value signaling.  I.e., it's similar semantics to RFC 5576 signaling, but with the extra indirection layer.

--
Jonathan Lennox
[email-masked]