Re: [MMUSIC] The rtp-duplication related drafts

"Ali C. Begen (abegen)" <abegen@cisco.com> Tue, 19 March 2013 15:31 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 C577921F8DB9 for <mmusic@ietfa.amsl.com>; Tue, 19 Mar 2013 08:31:18 -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 LrZ4io1wepZx for <mmusic@ietfa.amsl.com>; Tue, 19 Mar 2013 08:31:17 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id DD39D21F8DB6 for <mmusic@ietf.org>; Tue, 19 Mar 2013 08:31:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12354; q=dns/txt; s=iport; t=1363707076; x=1364916676; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VoBRduGMFNI5qdF3xd+4B5CVDeqSetc8lXgJ5DHkWD8=; b=JE66Qi4P+Kv51R6FWAmYISuVyEvb/ni5WWqq593QttX00rOf+JhbNCBC 0FGXYaoBc7p5m9vJZwhL0f7Jw/PvuI3RxfCeLZACr8PEKlXdyusWTAxUc TxVdS6Gf2UVdyvzH060PL2SxpTxPSeGL22+zPqfyDLvcYtA37A8js1ViK Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQFAA6ESFGtJXG//2dsb2JhbAA5Cg6EJoNtvG9obxZ0giQBAQEDASMRRQwGAQgOAwMBAgECAgYgAgQwFQgIAgQOBQiIBgYBC69lgkCQHYEjjDGBBwIWEAsHBoInMmEDkxmEZY9jgks/gig
X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="scan'208";a="189143066"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 19 Mar 2013 15:31:13 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2JFVDkg027245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 15:31:13 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 10:31:13 -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/cQCAbseDAIAAV3uAgAA6UoA=
Date: Tue, 19 Mar 2013 15:30:49 +0000
Message-ID: <C15918F2FCDA0243A7C919DA7C4BE9940CF68E43@xmb-aln-x01.cisco.com>
In-Reply-To: <51486FF1.6010808@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: <506566582133AB4CA7540C0E0628C22D@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 15:31:18 -0000

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