[MMUSIC] MMUSIC stage and studio requirements I-D ...

lazzaro <lazzaro@eecs.berkeley.edu> Thu, 07 July 2005 20:14 UTC

Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20014 for <mmusic-archive@ietf.org>; Thu, 7 Jul 2005 16:14:21 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DqdCb-0000LW-EG for mmusic-archive@ietf.org; Thu, 07 Jul 2005 16:42:33 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqcYj-0007vC-Rf; Thu, 07 Jul 2005 16:01:21 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DqcYj-0007v4-0H; Thu, 07 Jul 2005 16:01:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15921; Thu, 7 Jul 2005 16:01:18 -0400 (EDT)
Received: from gateway0.eecs.berkeley.edu ([169.229.60.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dqczv-0006K4-EQ; Thu, 07 Jul 2005 16:29:30 -0400
Received: from [128.32.34.73] (dhcp-34-73.CS.Berkeley.EDU [128.32.34.73]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.13.4/8.13.3) with ESMTP id j67K1FkX000161 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 7 Jul 2005 13:01:16 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v730)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Message-Id: <2E2A5716-791F-4C40-9583-13F95C325B3F@eecs.berkeley.edu>
Content-Transfer-Encoding: 7bit
From: lazzaro <lazzaro@eecs.berkeley.edu>
Date: Thu, 07 Jul 2005 13:01:48 -0700
To: mmusic@ietf.org
X-Mailer: Apple Mail (2.730)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
Subject: [MMUSIC] MMUSIC stage and studio requirements I-D ...
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac
Content-Transfer-Encoding: 7bit

Hi everyone,

         I just sent an new individual I-D submission
off to Internet-Drafts, that is targeted to MMUSIC:

----

Requirements for a Stage and Studio Multimedia Framework
  <draft-lazzaro-mmusic-stage-studio-requirements-00.txt>

                                 Abstract

Is the IETF multimedia stack appropriate for use in the digital
audio equipment found in recording studios and concert halls?
To help answer this question, this memo lists the requirements
for a session management framework for stage and studio
devices.

Download URL for an advance copy:

http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-sands.txt

----

Some background may be helpful.  RTP MIDI has many
potential applications.  Many are WAN-oriented, and SIP
and RTSP as is will work well for these.  The RTP MIDI
I-D includes interoperability advice for those apps.

The application described in the above abstract --
networking together professional audio equipment in
recording studios and concert stages -- is a "networking
in the small" problem (the network spans the rooms of
a recording studio or concert venue) and has unique
requirements.

MMUSIC may be the right place to design a framework
for session management for this application.

Or, maybe not -- maybe a new custom protocol done by
an audio-centric standards body is more appropriate,
free from our legacy-compatibility constraints.

Or, maybe there is room for both types of protocols,
as the potential devices span from the very simple
(powered by 8-bit micros) to very complex (expensive
multiprocessor implementations of mixing consoles).

I decided the best way to start the discussion on this
topic was to write a list of requirements for the domain
as seen by the authors.  Thus this I-D.  Even if the work of
doing the framework is not appropriate for MMUSIC,
MMUSIC may be the right place to host the discussion
of the requirements for the application.  If the WG agrees,
then elevating this I-D to WG item would be the way to
express this agreement.

I won't be in Paris, but if the chairs wish to hold a
discussion there, I'd be happy to make up slides to
guide their presentation.

Finally, AVT'ers should note this is an MMUSIC
I-D -- I CC'd this initial posting to both lists, but
discussion should occur on MMUSIC.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---



_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic