MMUSIC minutes

[Joerg Ott <[e-mail]>]

Folks,

attached are the minutes of the MMUSIC WG session in DC.

Joerg

-------------------------------------------------------------------------

Minutes of the MMUSIC WG
========================

46th IETF, Washington, DC

Reported by Joerg Ott
Notes taken by Tom Taylor


The MMUSIC WG met once during the 46th IETF, for a two hour slot.  The
meeting was chaired by Joerg Ott.  Some 150 participants attended the
meeting.

Revised MMUSIC Charter
----------------------

Joerg gave an overview of the tentative new charter of the Working
Group.  He noted that Ruth Lang, Eve Schooler, and Mark Handley have
stepped down as co-chairs and thanked them for the years of great work
together.  Due to the re-organization of MMUSIC, the mailing list and
archive location will change in the next months.

Joerg then discussed the tentative work items for MMUSIC and outlined
a deliverable schedule for the next 12 months to come.  The
development of a capability description framework as successor for the
Session Description Protocol (SDP) will be the most important
short-term work item.  Another new work item will be the design of a
local coordination mechanism for conferencing applications (the
Message Bus).  Further work items include collecting and documenting
existing and emerging extensions to SDP (Session Description
Protocol), documenting current practice SAP (Session Announcement
Protocol) and moving a revised SAP spec ahead to Proposed Standard.
The Real-time Streaming Protocol (RTSP, RFC 2326) will be revisited to
be advanced to Draft Standard or revised as Proposed; a simple
conference control protocol for tightly coupled sessions will be
developed in the long term.  Finally, Joerg announced that a WG Last
Call shall be issued on the IETF Multimedia Conferencing Architecture
I-D shortly after this IETF.

With respect to SAP, an issue was raised whether a local access
protocol to a site central SAP server would be in scope of MMUSIC.  It
was agreed that this is necessary for the specification of a complete
system.  HTTP was suggested as one possibility.  The chair asked for
volunteers to write up a document outlining possible alternatives for
this task so that the working group can review these.

It was also pointed out that, from the experience gained so far with
SDP in the context of the AVT WG, not only extensions but also
corrections may need to be applied to the current SDP spec.  This
discussion was postponed to the capability framework agenda item.

Session Announcement Protocol (SAP) Version 2
---------------------------------------------

Colin Perkins briefly discussed recent work on version 2 of the
Session Announcement Protocol.  Two drafts (02 and 03) have been
submitted since the Oslo meeting.  Draft 02 contains most of the
changes: this draft clarifies the text describing the authentication
procedure and specifies more exactly when session announcements are to
be sent.  Draft 03 has removed the references to directory sessions;
instead, a separate draft will be submitted for the next meeting.
Colin continues to explain the algorithm for calculating the
announcement interval.  It was noted that the RTCP timer
reconsideration algorithms works slightly differently from the one of
SAP and that it may be worthwhile to align SAP here.  This will be
considered further.  Colin pointed out that the current SAP is ready
for WG Last Call for Experimental RFC (rather than standards track
because of the well-known scaling problems).  A successor version of
SAP should then be targeted at Proposed Standard.  WG Last Call was
agreed subject to the change to the reconsideration behavior noted
above.

Session Description Protocol (SDP) and Administrative Scoping
-------------------------------------------------------------

Colin Perkins also introduced extensions to SDP to deal with
administrative scoping.  The problem is that a session description may
contain administratively scoped multicast addresses (which are not
globally unique); in this case, the receiver of an SDP message body
cannot tell from the session description alone whether or not this
address is valid in the particular scope zone.  Colin proposed two
possible solutions: as long as the session is announced with SAP, the
announcement has to use the same scope zone as the session.  If this
is done, then everyone who receives the announcement will also be able
to receive the media streams.  However, Colin points out that relying
on SAP is obviously not always suitable.  An alternative would be to
include a "scope identifier" in the session description.  One
possibility is to include the MZAP scope name (human readable, not
unique though), using the MZAP zone identifier is another (the MZAP
zone identifier is unique but may change over time).  Colin considered
the latter approach to be an acceptable solution for now.

It was discussed whether this is a real issue that needs to be solved
within SDP.  Colin argues that at least for Mbone conferences
(possibly announced on web pages) there is a potential need for such
an attribute.  It is tentatively agreed to inlucde the MZAP zone
identifier in SDP, but investigations will continue.


SIP/SDP Call Setup for Real-time Fax over IP (T.38)
---------------------------------------------------

Glenn Parsons introduced the ITU-T protocol for real-time fax over IP:
T.38 which can be described as demodulated and packetized T.30.  It
does use TCP or UDP (UDP optionally with FEC) for data transport, no
RTP.  Two call signaling protocols are being standardized for T.38:
H.323 (T.38 Annex B and H.323 Annex D) as well as SIP/SDP (to become
T.38 Annex D).  T.38 Annex D uses SIP INVITE for establishing fax-only
and fax/voice calls.  A number of T.38-specific attributes are
proposed to indicate capabilities of fax endpoints such as the maximum
bit rate, MMR and JBIG transcoding, and the use of error correction as
attributes.  Two SDP extensions are to be registered with IANA:
("image/t38") as format type and "TCP" as transport protocol.  For
call signaling, call progress mappings to SIP are being defined as is
DTMF carriage during a call.

Comments are welcome with respect to all of the current work areas.
Glenn noted that ITU-T SG8 plans to approve the document (with SDP
extensions) in its February 2000 meeting.  Sample call flows will be
added as an appendix.  Comments on the work should be sent to the
mailing list, to the chair, or to Glenn and will be summarized and
prepared as input to the ITU-T meeting by January, 19th, 2000.

RTSP-based media control in MPEG-4
----------------------------------

Andrea Basso presented on the issue of MPEG-4 stream control with
RTSP, the aim being to understand how RTSP can be used to control

MPEG-4 streams and which RTSP extensions may be necessary for this
purpose.  The particular issue discussed was how to initially retrieve
a scene description from an RTSP server.  The architecture of MPEG-4
comprises scene descriptions and elementary streams which are linked
by object descriptors.  Object descriptors can vary widely in size
(and pariticularly those belonging to the initial scene description
tend to be large) which raises the issue of reliable delivery from the
media server to the client.  Andrea proposed two possible solutions:
two RTSP DESCRIBE message could be exchanged -- which, however, would
require two round-trips before the description is available to the
client.  It was noted from the audience that both DESCRIBEs could be
sent in a single message (which would require that an implementation
uses the same URL for both, though).  Alternatively, the content-type
multipart (SDP, IOD) could be used to carry both session description
and initial object descriptors in one message (and thus retrieve it in
a single round-trip).  Andrea solicited further feedback/input on
methods for delivering the initial Object Descriptor.

During a short discussion, it was pointed out that similar work has
been presented in MMUSIC before, and the respective presenters agreed
to join their efforts to develop a solution.  An Internet Draft
describing RTSP for MPEG-4 stream control will be made available
within the next two months.  The work is targeted to be completed by
July 2000.

Message Bus for Call Control
----------------------------

Joerg Ott provided an update of the work on the Message Bus: the
transport is deemed stable by now.  An internal interoperability day
in Bremen has led to a number of minor clarifications in the text as
well a few minor technical fixes in the specification and has proven
interoperability of three implementations: one from UCL in C, two from
Bremen (C++ and Java).  An optimization to reduce load is also
included now: Mbus messages targeted at a single recipient may be sent
via unicast (instead of multicast); the decision to use unicast is
taken within the Mbus transport layer implementation and is
transparent to the application.  The revised Internet Drafts for
requirements and transport will be submitted shortly.  The Message Bus
transport Internet Draft is targeted for Proposed Standard.

Joerg also reviewed the concepts for Mbus message semantics and
described the simple command naming scheme allowing for generic as
well as protocol/tool-specific commands to be described without the
risk of name clashes.  He noted that protocol/media and tool-specific
commands are defined for RTP, audio streams, and the Robust Audio Tool
(RAT), respectively.  Then he focused on Mbus commands for call
control presenting a set of elements common to H.323, SIP, and ISDN
and designed to be suitable for building gateways as well.
(Protocol-specific messages are yet to be defined.)  As an example, he
presented a call setup message (conf.call-control.call) along with its
parameters in more detail.  Similar messages are defined for incoming
call, accepting and rejecting calls, redirection, etc. as well as for
event notifications (ringing, accepted, etc.).  Using ladder diagrams
Joerg described sample call flows with Mbus-controlled SIP engines on
both sides of a call.  Further call flows for other scenarios were
shown as well.  He noted that the first revision of the call semantics
Internet Drafts are likely to be targeted for Experimental to gain
more experience before a Standards Track document will be pursued.

An issue was raised that the Message Bus commands for call control
seem very similar to an API -- a seemingly similar work item was
rejected by the Area Directors in the meeting of the SIP WG (SIP
servlet API).  The chair agreed to discuss this subject with the Area
Directors.  It was also noted that much more functionality as
presented during the meeting (and specified in the draft so far) will
be needed for e.g. call center applications.  Joerg pointed out that
further commands were already under investigation (such as conveying
DTMF, controlling announcements, etc.) and there were more to come.

Joerg also outlined a number of potential application scenarios for
the Message Bus.  The fundamental idea is that Mbus enables modular
system design (with components exchangeable at run time) and allows
independence of programming languages.  The Mbus concept can be used
to implement minimal browser plug-ins that use Mbus messages to talk
to a powerful call control engine / conferencing system.  Also, Mbus
allows to create an open interface for remotely controlling
stand-alone devices (such as IP telephone sets) from PCs/workstations.
Many further areas of application are conceivable.

In the future, work will need to move towards on completing the work
for generic call control, defining specific control commands for SIP
and H.323 (both of which are in progress).  Those Mbus commands which
use SDP right now for carrying media descriptions need to be revised
to incorporate the new capability framework syntax.  Finally,
tool-specific commands should be defined for video applications,
whiteboards, etc. and new areas of deployment could be investigated
for the Message Bus.


Capability Framework
--------------------

Joerg Ott presented the current status of the work on the capability
framework.  Capability negotiation is required for call and conference
control among other areas, and is needed by / worked on in a number of
working groups: MMUSIC, SIP, AVT, MEGACO, CONNEG, and possibly (much
more limited) IPTEL and ENUM.  The capability framework aims at
providing a good solution for MEGACO, SIP, and MMUSIC,
borrowing/re-using as much as possible from other work.

Joerg continued to review the system model: he described the
application and the component view of a call/conference situation.  To
provide the desired communication functionality (such as audio
communication or shared viewing of transparencies) different
configurations (applications used, protocols and parameters using
within the applications) are conceivable at each endpoint involved.
The intersection of capabilities (expressed by protocols and protocol
parameters) supported by the endpoints defines the set of potential
configurations to be used in the particular setting.  Out of these
potential configurations one or several actual configurations will be
chosen for the communication tasks; these actual configurations
constitute the session descriptions for the various media (as
currently found in SDP).

Today, a number of protocols make use of SDP to express capabilities.
However, SDP was originally designed for session announcements rather
than capability negotiation and does not make a distinction between
potential and actual configurations.  While SDP is simple, network
efficient, and easily extensible within its scope (all properties that
are desirable to keep), it is not designed to indicate alternatives,
counts, or groupings of capabilities.  Furthermore, SDP as a
description language does not provide adequate means to address
aspects such as redundancy coding or FEC.  Joerg stated that a new
capability framework needs to address all these asepcts as well as
additional ones.  Requirements (augmented durint the MMUSIC session)
for negotiation include:

- simple capability description and negotiation process
- multiparty with dynamic membership
- generality: semantics-ignorant negotiation
- accommodate user preferences
- simultaneous and mutually exclusive capabilities
  (combinations, quantities)
- fix initial choice of a capability for the entire session
  (no later changes possible)
- policies
- negotiation restricted to one to one and a half round trips

Requirements for the language:
- expressiveness e.g. support for redundancy, FEC, layered encodings
- efficiency -- concise, easy to parse
- generality -- no semantics in base specification
- extensible -- support naming and reuse of "profiles"
- network-friendly -- compactness, firewall/NAT support
- available within the next 18 months.

Completing the presentation of the current capability framework
Internet Draft, Joerg reviewed the major comments that the authors had
received so far: it was noted that the relation between requirements,
system model, and description language needs clarification, and a
major concern was raised that the capability framework draft would
duplicate work of the CONNEG WG.  While the authors suggested that
re-use of CONNEG work was a nice-to-have, comments from the audience
urged that re-use wherever possible is rather a mandate --
particularly given the complexity of the issues, the potential
similarity of requirements, and the goal to complete this work as
quickly as possible.

Finally, Joerg outlined the next steps to be taken (considering the
comments received).  Work items include defining syntax, types and
parameters for media encodings (codecs) as well as redundancy, FEC,
and interleaving schemes.  Work on these aspects can draw from other
sources inside and outside the IETF.  Also, the negotiation model
needs to be fixed: for the concrete negotiation model, it needs to be
decided how far to reuse or adapt the CONNEG work, a syntax need to be
specified, and special cases for capability negotiation need to be
worked out (such as sending vs. receiving capabilities, symmetric
vs. asymmetric capabilities).

A general discussion followed on the implications of this work: an
issue was raised that if this capability framework is intended as a
replacement for SDP, this will have an impact on a lot of other
protocols and deployed applications (which suggests further discussion
on the list).  Also, it was pointed out that (like in the MEGACO WG)
two camps are likely to surface: one looking for a number of
extensions to SDP to satisfy the immediate needs, another will want
something similar to H.245.  The chair argued that there is a need to
make progress on this, that all requirements have to be reviewed
carefully (in order not to overengineer a solution), and that, with
respect to the two camps, the goal is to make neither of them too
unhappy.

It was pointed out the SDP specification needs revision to incorporate
fixes.  This raises the issue of which functionality will be added to
SDP during this revision cycle and what will be done as part of the
new work item.  The chair argued that he would like to avoid feature
creep in SDP and that SDP should be kept within its original scope as
a pure description language.  He also pointed out that a clear
migration path from SDP towards the new work needs to be defined.

The capability framework was accepted as a new work item.  All
requirements listed so far (and new ones to be found) will be reviewed
carefully, and a solution as simple as possible will be developed.
The authors agreed to investigate the CONNEG work again with the aim
to re-use as much as possible and provide a revised capability draft
by February 2000.  Further discussion will take place on the list.