Re: [MMUSIC] The rtp-duplication related drafts

[Paul Kyzivat <[e-mail]>]

Ali,

In my review I simply identified areas that seemed incomplete/ambiguous.
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.

	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-duplication
>>>>>>> /
>>>>>>>
>>>>>>> http://datatracker.ietf.org/doc/draft-ietf-mmusic-duplication-groupin
>>>>>>> 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
>>
>>
>
>