Re: [MMUSIC] The rtp-duplication related drafts

["Ali C. Begen (abegen)" <[e-mail]>]

-----Original Message-----
From: Paul Kyzivat <[e-mail]>
Date: Tuesday, March 19, 2013 4:02 PM
To: "Ali C. Begen" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [MMUSIC] The rtp-duplication related drafts

>Ali,
>
>In my review I simply identified areas that seemed incomplete/ambiguous.

Thanks, your review was certainly helpful to identify these issues.

>The existing syntax is inadequate to represent a full range of
>possibilities in the presence of multiple duplication groups.
>
>I don't have any particular preferences here.
>While I suggested some possible syntax changes that would allow coverage
>of all possibilities, I am in no position to know if the added cases
>that would cover make any sense in practice. I am satisfied to accept
>your judgement that they don't.
>
>If that is so, then simply pointing out that the other cases considered
>out of scope will satisfy me.

OK, both drafts will be revised shortly. Please let me know whether you
are ok with the changes when you have a chance to look at the diff.

-acbegen

>
>	Thanks,
>	Paul
>
>On 3/19/13 2:48 PM, Ali C. Begen (abegen) wrote:
>> (Picking up this old thread as I am planning to revise all the
>>duplication
>> related drafts shortly)
>>
>>
>> -----Original Message-----
>> From: Paul Kyzivat <[e-mail]>
>> Date: Monday, January 7, 2013 10:06 PM
>> To: "Ali C. Begen" <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>
>> Subject: Re: [MMUSIC] The rtp-duplication related drafts
>>
>>> On 1/3/13 11:20 PM, Ali C. Begen (abegen) wrote:
>>>>
>>>> On Jan 3, 2013, at 10:41 PM, Paul Kyzivat <[e-mail]>
>>>>wrote:
>>>>
>>>>> On 1/3/13 9:47 PM, Ali C. Begen (abegen) wrote:
>>>>>> Thanks for the review.
>>>>>>
>>>>>> On Jan 3, 2013, at 9:29 PM, Paul Kyzivat <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>> Ali,
>>>>>>>
>>>>>>> On 1/3/13 5:31 PM, Ali C. Begen (abegen) wrote:
>>>>>>>> Hi everyone,
>>>>>>>>
>>>>>>>> The following two drafts have been adopted by MMUSIC a while ago
>>>>>>>> and the main draft discussing the RTP duplication issues is being
>>>>>>>> finalized in AVTEXT (this was also adopted as a WG item a while
>>>>>>>> ago). It is simply waiting for the WG to make a decision on the
>>>>>>>> srcname proposal.
>>>>>>>>
>>>>>>>>
>>>>>>>> 
>>>>>>>>http://datatracker.ietf.org/doc/draft-ietf-mmusic-delayed-duplicati
>>>>>>>>on
>>>>>>>> /
>>>>>>>>
>>>>>>>> 
>>>>>>>>http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-group
>>>>>>>>in
>>>>>>>> g/
>>>>>>>
>>>>>>> I have a question about these:
>>>>>>>
>>>>>>> Each example shows only one group. But couldn't there be multiple
>>>>>>> duplication groups?
>>>>>>>
>>>>>> There could be.
>>>>>>
>>>>>>> If so, the current proposal has no mechanism for specifying
>>>>>>>separate
>>>>>>> duplication-delay for each group.
>>>>>>>
>>>>>>
>>>>>> a=duplication-delay:X could be specified in each media session. For
>>>>>> example:
>>>>>>
>>>>>> 	a=rtpmap:100 MP2T/90000
>>>>>>           a=ssrc:1000 cname:[e-mail]
>>>>>>           a=ssrc:1010 cname:[e-mail]
>>>>>>           a=ssrc-group:DUP 1000 1010
>>>>>>           a=duplication-delay:100
>>>>>>           a=mid:Group1
>>>>>> 	a=rtpmap:101 MP2T/90000
>>>>>>           a=ssrc:2000 cname:[e-mail]
>>>>>>           a=ssrc:2010 cname:[e-mail]
>>>>>>           a=ssrc-group:DUP 2000 2010
>>>>>>           a=duplication-delay:150
>>>>>>           a=mid:Group2
>>>>>
>>>>> This makes the attributes very order dependent. If this is intended,
>>>>> then I think you need more words to say that. Currently it says:
>>>>>
>>>>>     If used as a media-level
>>>>>     attribute, it MUST be used with the 'ssrc-group' attribute and
>>>>>"DUP"
>>>>>     grouping semantics...
>>>>
>>>> My mistake, did not copy/paste the whole thing.
>>>>
>>>> 	m=video 30000 RTP/AVP 100
>>>>           c=IN IP4 233.252.0.1/127
>>>>           a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
>>>>           a=rtpmap:100 MP2T/90000
>>>>           a=ssrc:1000 cname:[e-mail]
>>>>           a=ssrc:1010 cname:[e-mail]
>>>>           a=ssrc-group:DUP 1000 1010
>>>>           a=duplication-delay:100
>>>>           a=mid:Group1
>>>> 	m=video 40000 RTP/AVP 101
>>>>           c=IN IP4 233.252.0.2/127
>>>>           a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
>>>>           a=rtpmap:101 MP2T/90000
>>>>           a=ssrc:2000 cname:[e-mail]
>>>>           a=ssrc:2010 cname:[e-mail]
>>>>           a=ssrc-group:DUP 2000 2010
>>>>           a=duplication-delay:150
>>>>           a=mid:Group2
>>>>
>>>> so there is one duplication-delay attribute in each media session
>>>> (specified by a m= line). It does not matter whether it is before or
>>>> after the ssrc-group line. It is OK as long as it is somewhere before
>>>> the next m line.
>>>
>>> But then, duplication-delay applies to a=ssrc-group:DUP groups within
>>> that media section. You could have two groups of ssrcs in there. So the
>>> problem is the same as the problem across different m-lines. E.g.
>>>
>>> 	m=video 30000 RTP/AVP 100
>>>          c=IN IP4 233.252.0.1/127
>>>          a=source-filter:incl IN IP4 233.252.0.1 198.51.100.1
>>>          a=rtpmap:100 MP2T/90000
>>>          a=ssrc:1000 cname:[e-mail]
>>>          a=ssrc:1010 cname:[e-mail]
>>>          a=ssrc:1020 cname:[e-mail]
>>>          a=ssrc:1030 cname:[e-mail]
>>>          a=ssrc-group:DUP 1000 1010
>>>          a=duplication-delay:100
>>>          a=ssrc-group:DUP 1020 1030
>>>          a=duplication-delay:200
>>> 	m=video 40000 RTP/AVP 101
>>>          c=IN IP4 233.252.0.2/127
>>>          a=source-filter:incl IN IP4 233.252.0.2 198.51.100.1
>>>          a=rtpmap:101 MP2T/90000
>>>          a=ssrc:2000 cname:[e-mail]
>>>          a=ssrc:2010 cname:[e-mail]
>>>          a=ssrc-group:DUP 2000 2010
>>>          a=ssrc:2020 cname:[e-mail]
>>>          a=ssrc:2030 cname:[e-mail]
>>>          a=ssrc-group:DUP 2020 2030
>>>          a=duplication-delay:250
>>>
>>>  From what you say, the two duplication-delay attributes in one media
>>> section would make no sense.
>>
>>
>> Frankly, I can't think of an application where you would have multi-pair
>> streams in an RTP session and require different duplication delays
>>between
>> each pair. So, that's why I never bothered with this. Does anybody
>> actually need this use case? Otherwise, I think we can ignore it and let
>> all the pairs use the same delay.
>>
>>
>>>
>>>>> What does "used with" mean? I assumed it simply meant that both
>>>>> attributes had to be present in the media section. But what you are
>>>>> saying now says that there is some very specific ordering required.
>>>>> E.g. that the a=duplicaation-delay must follow the a=ssrc-group:DUP
>>>>>to
>>>>> which it applies, and precede any other a=ssrc-group:DUP. This is
>>>>> possible, but ugly to specify.
>>>>
>>>> I hope it is clear now?
>>>>
>>>>>
>>>>>> (The SSRC need not be different as SSRC only need to be unique
>>>>>>within
>>>>>> each media session)
>>>>>>
>>>>>> For the non-ssrc grouping, your comment holds. It does not support
>>>>>> specifying different delay values for different groups. Do you think
>>>>>> we should support distinct delay values for different groups (which
>>>>>> probably means duplication-delay attribute has to be media-level
>>>>>>only)?
>>>
>>> Well, for the non-ssrc grouping you could put the group name in the
>>> a=duplication-delay attribute value.
>>
>> There is no group name in the "a=group:DUP" line, just the list of mids)
>> so there is no unique identifier for each group. Anyway, I thought of
>>this
>> and honestly, I think we better state this "limitation" explicitly and
>> forbid the use of different session-level delays in a single SDP
>> description. In other words, if there will be a session-level delay
>> attribute, it will apply to all DUP groups. If you need different
>> duplication delays for different groups, then simply use different SDP
>> descriptions for that (or use the media-level delay attribute).
>>
>>>
>>> And for the ssrc-grouping case you could put one of the grouped ssrcs
>>>in
>>> the a=duplication-delay attr value.
>>
>> As I said above, I can't think of any use case where this will be
>> needed/useful. If there are multiple SSRC pairings inside an m line,
>>they
>> simply have to use the same delay value. I can clarify this in the
>>draft.
>>
>> My goal is to complete this work for the use cases we need now. For
>> possible but rather unrealistic use cases, I don't think we should
>> complicate the attribute. Please comment if you disagree with these
>> changes.
>>
>> Thanks,
>> -acbegen
>>
>>>
>>> 	Thanks,
>>> 	Paul
>>>
>>>
>>
>>
>
>