IETF Logo Mail Archive

Re: [MMUSIC] The rtp-duplication related drafts

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 04 January 2013 03:41 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 1AE2C21F8EAA for <mmusic@ietfa.amsl.com>; Thu, 3 Jan 2013 19:41:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.149
X-Spam-Level:
X-Spam-Status: No, score=0.149 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 Sd-5HyxCNQBb for <mmusic@ietfa.amsl.com>; Thu, 3 Jan 2013 19:41:33 -0800 (PST)
Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 66AD821F8EA8 for <mmusic@ietf.org>; Thu, 3 Jan 2013 19:41:33 -0800 (PST)
Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta12.westchester.pa.mail.comcast.net with comcast id jfhY1k00216LCl05CfhYZW; Fri, 04 Jan 2013 03:41:32 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id jfhX1k00j3ZTu2S3SfhY7d; Fri, 04 Jan 2013 03:41:32 +0000
Message-ID: <50E64F6B.9000507@alum.mit.edu>
Date: Thu, 03 Jan 2013 22:41:31 -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>
In-Reply-To: <C15918F2FCDA0243A7C919DA7C4BE9940CDFCCB7@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=1357270892; bh=8iTsWg+CffmjsaMHxnHNmc7ZJR0xqa4gd33tos5EzKw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=b4AbtLEE7kKQ+6wFDb5Zq9PlhZvCQGsFGZrIPrYCjb8oqLaPD9xH9+l6P73hwyDSy 9g9pBsXhnU5FbKCpQNobyyP8tK1fGPhzDisZJi0j/cV97vnLcNYtY9ETVJBWBaKp1M o+OKzT6CuOuZCkQES/dmWRgLcfrTAPT6naLx6WxShhRUBrevarZZubQ5G76Dgd25Of uEY5ARQfBjCcL2SE06i5oplgLnFjpVq7FAcPrEnIKxmBs9cn39o60EmTLVDjZN3Bza h5G6lxRUa8q+XUBiP/JrZZCjkcy+2vjtm5U3Tg4sPcuz7NPFmlMe7+wgbl5py67v+Z 0GNRBPk5QZBVg==
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: Fri, 04 Jan 2013 03:41:34 -0000

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

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.

> (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)?

I don't know. Nothing seems appealing.

	Thanks,
	Paul

> -acbegen
>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>

v2.23.0 | Report a Bug | By Email