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

[Paul Kyzivat <[e-mail]>]

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.

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