Re: [AVT] The need for Offer/Answer sections in RTP payload format specifications
"John Lazzaro" <lazzaro@eecs.berkeley.edu> Tue, 27 January 2004 19:34 UTC
Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19366 for <avt-archive@odin.ietf.org>; Tue, 27 Jan 2004 14:34:34 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYyM-00060n-Vw for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 14:34:07 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0RJY6LK023103 for avt-archive@odin.ietf.org; Tue, 27 Jan 2004 14:34:06 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYyG-0005zW-Iy; Tue, 27 Jan 2004 14:34:00 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AlYxN-0005y1-El for avt@optimus.ietf.org; Tue, 27 Jan 2004 14:33:05 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19292 for <avt@ietf.org>; Tue, 27 Jan 2004 14:32:57 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AlYxA-0001D3-00 for avt@ietf.org; Tue, 27 Jan 2004 14:32:52 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AlYtu-00011u-00 for avt@ietf.org; Tue, 27 Jan 2004 14:29:31 -0500
Received: from relay2.eecs.berkeley.edu ([169.229.60.28]) by ietf-mx with esmtp (Exim 4.12) id 1AlYs8-0000sL-00 for avt@ietf.org; Tue, 27 Jan 2004 14:27:40 -0500
Received: from relay3.EECS.Berkeley.EDU (localhost [127.0.0.1]) by relay2.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0RJREEO017032 for <avt@ietf.org>; Tue, 27 Jan 2004 11:27:14 -0800 (PST)
Received: from gateway.EECS.Berkeley.EDU (nsmail@gateway.EECS.Berkeley.EDU [169.229.60.73]) by relay3.EECS.Berkeley.EDU (8.12.10/8.9.3) with ESMTP id i0RJRAkP027075 for <avt@ietf.org>; Tue, 27 Jan 2004 11:27:10 -0800 (PST)
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) by gateway.EECS.Berkeley.EDU (Netscape Messaging Server 4.15) with ESMTP id HS5Y1700.PT9 for <avt@ietf.org>; Tue, 27 Jan 2004 11:27:07 -0800
Mime-Version: 1.0 (Apple Message framework v612)
Content-Transfer-Encoding: 7bit
Message-Id: <CB1B54F8-50FE-11D8-B5DD-00039372C384@eecs.berkeley.edu>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
To: avt@ietf.org
From: John Lazzaro <lazzaro@eecs.berkeley.edu>
Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload format specifications
Date: Tue, 27 Jan 2004 11:27:06 -0800
X-Mailer: Apple Mail (2.612)
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
> Magnus Westerlund <magnus.westerlund@ericsson.com> writes: > > Thus we request that authors write an "Offer-Answer model > consideration" > in their SDP usage section. This should cover the following: > > - How configurations effect the interoperability. > - What parameters that are possible to subset and which are not. > - Recommendations on how to achieve good interoperability. In regards to RTP MIDI, I think it may be better for the readers of the "candidate Last Call" document to judge if the SDP sections as written (pages 20-24, and pages 68-103) handle Offer/Answer OK, and if the best solution is a new separate Offer/Answer section or a rewrite of the existing structure to discuss Offer/Answer in more depth. This way, I can handle those criticisms along with all of the other Last Call feedback at one time, in the hopes of reducing the total number of rewrite cycles before "candidate Last Call" becomes "Last Call". The alternative (going off and doing -02.txt versions to become the new "candidate Last Call", with a separate Offer/Answer section) probably knocks a month off the schedule. Not good ... My own intuition is that the RTP MIDI document is OK as it stands in regard to interop -- the world of RTP MIDI applications is big, and interoperability is going to require a framework document for each class of applications, written by application experts. The purpose of the SDP section in the payload document is to define a common set of SDP tools that these frameworks can subset. --- John Lazzaro http://www.cs.berkeley.edu/~lazzaro lazzaro [at] cs [dot] berkeley [dot] edu --- _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www1.ietf.org/mailman/listinfo/avt
- [AVT] The need for Offer/Answer sections in RTP p… Magnus Westerlund
- Re: [AVT] The need for Offer/Answer sections in R… John Lazzaro
- Re: [AVT] The need for Offer/Answer sections in R… Jonathan Rosenberg