Re: [MMUSIC] Scope of RTP payload types in BUNDLE?

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 11 June 2013 14:46 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 3700121F9925 for <mmusic@ietfa.amsl.com>; Tue, 11 Jun 2013 07:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.415
X-Spam-Level:
X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 E25w3ax2iYO7 for <mmusic@ietfa.amsl.com>; Tue, 11 Jun 2013 07:46:17 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 98B5721F999A for <mmusic@ietf.org>; Tue, 11 Jun 2013 07:46:14 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta15.westchester.pa.mail.comcast.net with comcast id myhA1l00F0vyq2s5F2mDBv; Tue, 11 Jun 2013 14:46:13 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id n2mD1l00z3ZTu2S3R2mDtc; Tue, 11 Jun 2013 14:46:13 +0000
Message-ID: <51B73834.3090209@alum.mit.edu>
Date: Tue, 11 Jun 2013 10:46:12 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Cullen Jennings <fluffy@iii.ca>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <599C780A-F483-470E-91F2-68DBA605C79C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379D6E@ESESSMB209.ericsson.se>, <64C06EE8-A16D-4C3E-8A11-D6400F620A8E@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C379DC8@ESESSMB209.ericsson.se> <71ED9E54-DF0C-4DB9-A7F4-09A0BC90B177@csperkins.org> <51A3B070.1090006@alum.mit.edu> <FF8A3ABB-992C-48D9-856F-A6A21A35A0C1@iii.ca> <51AF5EEE.8080904@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C3836E7@ESESSMB209.ericsson.se> <51AF6BB9.3010807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C383757@ESESSMB209.ericsson.se> <5E88302B-9DA1-4752-A6C5-367D6F00FAB5@iii.ca> <51B20D64.7050600@alum.mit.edu> <ED508E23-575A-471A-90AB-3D5DF3D90314@iii. ca> <51B4B64B.1050101@alum.mit.edu> <9279E993-5DB0-4987-B6D0-CF47CC1F848D@iii.ca> <949EF20990823C4C85C18D59AA11AD8B049607@FR712WXCHMBA11.zeu.alcatel-lucent.com> <A57B7A9E-B809-473A-80E7-1A3DFE2BB7B8@iii.ca>
In-Reply-To: <A57B7A9E-B809-473A-80E7-1A3DFE2BB7B8@iii.ca>
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=1370961973; bh=+214PhgTQGB7N9KukxSNxwFfIaE8A6xm1PHPJ3jDiso=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=DeMwsk4T3+1xOqv8nIE/KWk7aMhgmDfOGWTMT2LL+6VtZCHZnXGslLSRQTXK2P6st 8ioVCPHhamW6ChnwY6h+ZWXjKmrPVtzNQFG6z9U26/hrjYGEaJb9ReLo73CAUAcGBq ApaWcZQvh6N/iuYxJwsDQrEhuUZ+hJBrBtHcfCAJp5mH5TPNqBgMuWj/ecUoNT7Nit 8tqcSAxVK71uL+bfgRJMRK4A6PQ5Ul79ypFuZXP/ptW+B6VSa3+/+h4Ebxb3XnixHJ eNL+5VYdLXT1JvDL8LOGyFoxAyu9Zm5iNbDr2BHPs/NtG0LUcZdskElmJWVFMlQ2+Z X94UEcPt1NbVg==
Cc: "DRAGE, Keith \(Keith\)" <keith.drage@alcatel-lucent.com>, "mmusic@ietf.org WG" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
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, 11 Jun 2013 14:46:23 -0000

On 6/11/13 2:00 AM, Cullen Jennings wrote:
>
> Sorry - trying to say
>
> Several of the implementations of 100rel have bugs in the case of where there is an outstanding transaction and they get an event that might cause them to want to start a second transaction before the first transaction completes.

We are in real trouble if we say a feature can't be used because some 
implementations of it are buggy. We might as well all go home.

(It's a different story if nobody is able to construct a working 
implementation.)

	Thanks,
	Paul

> On Jun 10, 2013, at 7:47 PM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> wrote:
>
>> "has an implantation that does not meet the requirements of the RFC - particularly in the many unspecified corner cases"
>>
>> Does not make sense!
>
>