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 >>> >>> >> >> > >
- [MMUSIC] The rtp-duplication related drafts Ali C. Begen (abegen)
- Re: [MMUSIC] The rtp-duplication related drafts Paul Kyzivat
- Re: [MMUSIC] The rtp-duplication related drafts Ali C. Begen (abegen)
- Re: [MMUSIC] The rtp-duplication related drafts Paul Kyzivat
- Re: [MMUSIC] The rtp-duplication related drafts Ali C. Begen (abegen)
- Re: [MMUSIC] The rtp-duplication related drafts Paul Kyzivat
- Re: [MMUSIC] The rtp-duplication related drafts Ali C. Begen (abegen)
- Re: [MMUSIC] The rtp-duplication related drafts Paul Kyzivat
- Re: [MMUSIC] The rtp-duplication related drafts Ali C. Begen (abegen)