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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Mon, 10 June 2013 10:48 UTC

Return-Path: <keith.drage@alcatel-lucent.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 5314021F8551 for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 03:48:02 -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 Y2tSMIUok3ur for <mmusic@ietfa.amsl.com>; Mon, 10 Jun 2013 03:47:54 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C99FA21F8E93 for <mmusic@ietf.org>; Mon, 10 Jun 2013 03:47:28 -0700 (PDT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r5AAlLgu018055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Jun 2013 05:47:21 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id r5AAlEPY013349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Jun 2013 06:47:20 -0400
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 10 Jun 2013 06:47:12 -0400
Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.201]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 10 Jun 2013 12:47:06 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Cullen Jennings <fluffy@iii.ca>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [MMUSIC] Scope of RTP payload types in BUNDLE?
Thread-Index: AQHOZY1YOIhY09e1NUmwzjffFLQEKpkuxGgg
Date: Mon, 10 Jun 2013 10:47:05 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B049607@FR712WXCHMBA11.zeu.alcatel-lucent.com>
References: <749DCA95-2D40-46B3-9A3D-E63356C7A2C1@csperkins.org> <1892A917-C408-4E8F-AB19-206ED508762C@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799BC@ESESSMB209.ericsson.se> <4EDA75BD-D753-4153-929B-10427274224D@csperkins.org> <7594FB04B1934943A5C02806D1A2204B1C3799EE@ESESSMB209.ericsson.se>, <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>
In-Reply-To: <9279E993-5DB0-4987-B6D0-CF47CC1F848D@iii.ca>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: "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: Mon, 10 Jun 2013 10:48:03 -0000

"has an implantation that does not meet the requirements of the RFC - particularly in the many unspecified corner cases"

Does not make sense!

Keith

> -----Original Message-----
> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf
> Of Cullen Jennings
> Sent: 10 June 2013 04:48
> To: Paul Kyzivat
> Cc: mmusic@ietf.org WG
> Subject: Re: [MMUSIC] Scope of RTP payload types in BUNDLE?
> 
> 
> On Jun 10, 2013, at 2:07 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
> 
> > On 6/8/13 12:11 AM, Cullen Jennings wrote:
> >>
> >> On Jun 7, 2013, at 11:42 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>
> wrote:
> >>
> >>> And then can't we demand that to support BUNDLE you must also support
> PRACK?
> >>
> >> I think you will find the people that have not implemented PRACK still
> don't want to implement PRACK. I know there is no way I would want to
> mandate the complexity of PRACK just to do bundle.
> >
> > They are willing to implement BUNDLE, and probably ICE and DTLS/SRTP,
> and perhaps RTCWEB, but they find PRACK undesirable to implement???
> >
> > I have no sympathy!
> > Its time to join the 21st century.
> 
> The other point of of vies is that PRACK is very complicated, has had many
> interoperable issues, and for many deployments, unnecessary, we should
> join the 21 century and deprecate it.
> 
> Now you are unlikely to chance your opinion, I am unlikely to change mine,
> and there are many people in both camps. I will note a huge percentage of
> SIP equipment does not support it or has an implantation that does not
> meet the requirements of the RFC - particularly in the many unspecified
> corner cases. I will also note that this discussion if not new. There is a
> reason PRACK is an extension to SIP and not part of 3261. It's optional -
> and lots of people don't need or want the option.
> 
> My proposed way to move forward is that we admit there are large use bases
> in both camps and make sure we can do something that works for both theses
> camps. So far we have managed to do that just fine.
> 
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic