Re: [MMUSIC] The rtp-duplication related drafts

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 07 January 2013 20:06 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F721F0CDF for <mmusic@ietfa.amsl.com>; Mon, 7 Jan 2013 12:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.59
X-Spam-Level:
X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60+0iCiq+o2t for <mmusic@ietfa.amsl.com>; Mon, 7 Jan 2013 12:06:42 -0800 (PST)
Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 81B651F0CB3 for <mmusic@ietf.org>; Mon, 7 Jan 2013 12:06:42 -0800 (PST)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id l0ev1k0081swQuc5586hGa; Mon, 07 Jan 2013 20:06:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id l86h1k00G3ZTu2S3b86hHj; Mon, 07 Jan 2013 20:06:41 +0000
Message-ID: <50EB2AD0.1080701@alum.mit.edu>
Date: Mon, 07 Jan 2013 15:06:40 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: "Ali C. Begen (abegen)" <abegen@cisco.com>
References: <C15918F2FCDA0243A7C919DA7C4BE9940CDF9AB8@xmb-aln-x01.cisco.com> <50E63E7D.5050707@alum.mit.edu> <C15918F2FCDA0243A7C919DA7C4BE9940CDFCCB7@xmb-aln-x01.cisco.com> <50E64F6B.9000507@alum.mit.edu> <C15918F2FCDA0243A7C919DA7C4BE9940CDFDA5D@xmb-aln-x01.cisco.com>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940CDFDA5D@xmb-aln-x01.cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357589201; bh=i3iYgrKEnRN17ymRmTjX/Kf/fg07K2n7u1FLMpoMJ5A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Iz+NrtH+A6lt0tjJnskdJzGkof1BBduweEYClWfy4ofJ9ntzNbh1W255SYasNxlZ9 AFqV+cUnFrAX4m+qLsg5vfkjxtSWS93F3gP1rRfkLq6YDFxEwAA7641wLaprod2aoO 55ZZum6iqmvgxJG6T0HpGYZFnx/0+C98Td8I6yC2JW5vhD+d7+BWfb+cCEYzWG7t2g 8jLdSfqYRHMoAqwbavwRQd9U3SG87QCMIuoKYZrqngxlI/5eUCbU67SRR/dDtRfwfh L3mgf7qh/QddYazuF6Xkjpw8TDc73NawKYW+6K7YvPZZAiZeZCIHPg6Bydk0sahK3P JOEVQR7scznBQ==
Cc: "<mmusic@ietf.org>" <mmusic@ietf.org>
Subject: Re: [MMUSIC] The rtp-duplication related drafts
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jan 2013 20:06:44 -0000

On 1/3/13 11:20 PM, Ali C. Begen (abegen) wrote:
>
> On Jan 3, 2013, at 10:41 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> 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 <pkyzivat@alum.mit.edu> 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-grouping/
>>>>
>>>> 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:ch1@example.com
>>>          a=ssrc:1010 cname:ch1@example.com
>>>          a=ssrc-group:DUP 1000 1010
>>>          a=duplication-delay:100
>>>          a=mid:Group1
>>> 	a=rtpmap:101 MP2T/90000
>>>          a=ssrc:2000 cname:ch2@example.com
>>>          a=ssrc:2010 cname:ch2@example.com
>>>          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:ch1@example.com
>          a=ssrc:1010 cname:ch1@example.com
>          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:ch2@example.com
>          a=ssrc:2010 cname:ch2@example.com
>          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:ch1@example.com
         a=ssrc:1010 cname:ch1@example.com
         a=ssrc:1020 cname:ch1@example.com
         a=ssrc:1030 cname:ch1@example.com
         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:ch2@example.com
         a=ssrc:2010 cname:ch2@example.com
         a=ssrc-group:DUP 2000 2010
         a=ssrc:2020 cname:ch2@example.com
         a=ssrc:2030 cname:ch2@example.com
         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.

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

And for the ssrc-grouping case you could put one of the grouped ssrcs in 
the a=duplication-delay attr value.

	Thanks,
	Paul