Re: [MMUSIC] The rtp-duplication related drafts

"Ali C. Begen (abegen)" <abegen@cisco.com> Tue, 19 March 2013 06:49 UTC

Return-Path: <abegen@cisco.com>
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 6AC7421F88DB for <mmusic@ietfa.amsl.com>; Mon, 18 Mar 2013 23:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.399
X-Spam-Level:
X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A58N5I+R+G5o for <mmusic@ietfa.amsl.com>; Mon, 18 Mar 2013 23:49:21 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3F55F21F851F for <mmusic@ietf.org>; Mon, 18 Mar 2013 23:49:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9898; q=dns/txt; s=iport; t=1363675761; x=1364885361; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f9KEy9Yz5Usn3YoqnLkjfnRGLnYOdEekBAzQwoxYKI4=; b=M4M3RZPaF/x5I0jjEBnOnlMEA1dlNZJbJyGF8TDnW3noN3vmTE5AnXFb w4Mfjt4BzVd6IAfGcO1BOCQJAPBGkXWzTiBMuyp23G0MQ37LJ7zvLS0CO jAEepgStbEh7UQ8Y9r6LeCOc0KmYASgopUPmHj6BNBZ9fB184rCyieSX9 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAB8JSFGtJV2d/2dsb2JhbABDDoQzg228dWlzFnSCJAEBAQMBIxFFDAYBCA4DAwECAQICBiACBDAVCAgCBA4FCIgGBgELr2mCQJAdgSONOgIWEAsHBoInMmEDkxiEZY9jgks/gig
X-IronPort-AV: E=Sophos;i="4.84,870,1355097600"; d="scan'208";a="188936906"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2013 06:49:20 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2J6nKEC024576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 06:49:20 GMT
Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 01:49:20 -0500
From: "Ali C. Begen (abegen)" <abegen@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] The rtp-duplication related drafts
Thread-Index: AQHN6gIIZX3irh0G9UC8vBTgxKH8HJg41yeAgAAFCQCAAA8mgIAACswAgAW/cQCAbseDAA==
Date: Tue, 19 Mar 2013 06:48:57 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE9940CF684C7@xmb-aln-x01.cisco.com>
In-Reply-To: <50EB2AD0.1080701@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.2.130206
x-originating-ip: [10.61.103.35]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4D10F45FE4F43040B05A7D2E9D0D8346@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Tue, 19 Mar 2013 06:49:22 -0000

(Picking up this old thread as I am planning to revise all the duplication
related drafts shortly)


-----Original Message-----
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Monday, January 7, 2013 10:06 PM
To: "Ali C. Begen" <abegen@cisco.com>
Cc: "mmusic@ietf.org" <mmusic@ietf.org>
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 <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-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: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.


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