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: 01 July, 2013 8:03 PM
> To: Roni Even
> Cc: [e-mail]
> Subject: Re: [MMUSIC] FW: New Version Notification for draft-even-
> mmusic-application-token-00.txt
> 
> Hi Roni. See inline.
> 
> On 7/1/13 7:38 AM, Roni Even wrote:
> >
> >
> >> -----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."
> 
> 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.


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

> 
> 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.
> 
> >> 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.
> 
> See comments above.
> 
> >>> 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.
> 
> 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