IETF Logo Mail Archive

Re: [MMUSIC] draft-roach-mmusic-unified-plan-00

"Cullen Jennings (fluffy)" <fluffy@cisco.com> Fri, 26 July 2013 12:04 UTC

Return-Path: <fluffy@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 52E7121F8C9D for <mmusic@ietfa.amsl.com>; Fri, 26 Jul 2013 05:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 nbOT0nVytyLG for <mmusic@ietfa.amsl.com>; Fri, 26 Jul 2013 05:04:51 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 92F9E21F89A5 for <mmusic@ietf.org>; Fri, 26 Jul 2013 05:04:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1403; q=dns/txt; s=iport; t=1374840291; x=1376049891; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nicQR7dSM8lkCvLa9TQ6zwRfXRTnGfpPKXoq9AGRZis=; b=EkIQIRzOpq5oDU0l0hbJ2ek/v1+6+7vsKQckS/d1pMSSDgX2QWJ1v5wn bJDBZVbvOrRGFED552ocdRn6p+Kuus8N8exVVkXBYw9q4IXpPthMPZear LdnM7Qv3G8vl+lddb0og1z2WngfGOssWzwxvHxdh7GcDRxewiCvAoPly1 I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAJFk8lGtJV2b/2dsb2JhbABaDoJ4gQW9RIEWFnSCJAEBAQMBOj8FCwIBCA4KChQQMiUCBA4FCIgCBrkVj0oCMQeDFm8DlAiVI4JWPoIq
X-IronPort-AV: E=Sophos;i="4.89,751,1367971200"; d="scan'208";a="239838024"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jul 2013 12:04:51 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6QC4p2R031811 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Jul 2013 12:04:51 GMT
Received: from xmb-aln-x02.cisco.com ([169.254.5.29]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 07:04:50 -0500
From: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] draft-roach-mmusic-unified-plan-00
Thread-Index: AQHOifhUWXK+VS/nCkSjdG4nezl1sg==
Date: Fri, 26 Jul 2013 12:04:50 +0000
Message-ID: <C5E08FE080ACFD4DAE31E4BDBF944EB113612FDE@xmb-aln-x02.cisco.com>
References: <51EFF8E0.6010203@alum.mit.edu> <51EFFACD.7040905@nostrum.com> <C5E08FE080ACFD4DAE31E4BDBF944EB1136123F4@xmb-aln-x02.cisco.com> <51F1C09B.2020205@alum.mit.edu>
In-Reply-To: <51F1C09B.2020205@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.20.249.164]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <E129D43A341451409DF7FB5A868759ED@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: IETF MMUSIC WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-roach-mmusic-unified-plan-00
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, 26 Jul 2013 12:04:57 -0000

On Jul 25, 2013, at 6:19 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 7/25/13 7:41 PM, Cullen Jennings (fluffy) wrote:
>> 
>> 
>> On Jul 24, 2013, at 10:03 AM, Adam Roach <adam@nostrum.com> wrote:
>> 
>>> On 7/24/13 10:55, Paul Kyzivat wrote:
>>>> This seems to be excluded, except by sending a new O/A every time the speaker switches, which isn't feasible. If this means that CLUE can't represent capture-encodings as m-lines, then there is no benefit to CLUE for the unified plan over No Plan (Emil's multiple-sources draft).
>>> 
>>> That's interesting. I wonder whether we should simply move to the RTP header extension described in section 3.2.1.1 as the primary means of correlation. It would seem to address the case you describe.
>>> 
>>> /a
>> 
>> SSRC can collide too so they might be wrong but the  header extension does not have that problem. It seems to me the algorithm is roughly
>> 
>> if you have  header extension, use that, if not then if you know the SSRC use that, if not then if you have unique PTs, use that. Perhaps there are other things to use too but roughly those get used in that order.
> 
> I commented on this before. You don't need to have an ordering.
> 
> If the combination of things you have is unique, use that. If not, then you have a problem.
> 

That would be fine with me too.

v2.23.0 | Report a Bug | By Email