Subject: Draft MMUSIC minutes

From: Joerg Ott <[email-masked]>
Date: Sun, 01 Mar 1998 16:21:24 +0100

Folks,

please find attached the draft minutes of the MMUSIC meeting at the Washington IETF.
We look forward to your comments.

Joerg

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

MMUSIC Minutes
==============

Prepared by: Joerg Ott <[email-masked]>

Acknowledgement: Special thanks to Colin Perkins who has done an
		 excellent job taking notes of the MMUSIC WG session.

The MMUSIC WG met once during the 40th IETF.  The meeting started with
a brief review of the status of Internet Drafts due for last call:
Mark Handley noted that the Real Time Streaming Protocol (RTSP) is
already at last call with the IESG and that the Session Description
Protocol (SDP) will go to last call shortly after this meeting.  No
further discussion was needed on those two subjects.

Session Initiation Protocol (SIP)
---------------------------------

Henning Schulzrinne gave a presentation on the latest revision of SIP
elaborating on operational aspects of the protocol as well as
indicating the functional changes after the Munich IETF.  A long
discussion was held on the reliability needed for SIP messages if SIP
mesages are carried in UDP packets.  Henning pointed out that for many
client messages (intermediate) answers are required from the server
which imply acknowledgment of the previously sent message.  For some
messages from the server to the client, an additional ACK message is
needed, this may also be the case for the BYE message from the client
to the server (since then resources can be released at the server).
A combination of implied acknowledgments, ACK messages, and timeouts
with message repetition should solve these problems.  However, some
details remain to be sorted out.

Henning's presentation of multicast invitations extended the mechanism
to make use them to simultaneously invite several persons.  It was
noted that the semantics of such invitations are unclear and that they
may lead to answer message implosions.  It was agreed to stay with the
exclusive use of multicast invitations for user location purposes --
what they were originally intended for -- in the basic SIP
specification (see below).

Furthermore, Henning proposed various extensions in the direction of
what is referred to as "supplementary services" in the telephony / PBX
world.  Some functions of call forwarding / call deflection can be
implemented in the SIP proxy or the SIP server of a user using basic
SIP messaging.  Newly added functionality includes call disposition
and call delegation.  Call disposition allows a calling party to
influence the called user's SIP server behavior, e.g. to avoid
forwarding or to queue a call if the user is busy / unavailable.  Call
delegation allows the called endpoint to redirect the call to others
-- by changing the parties to which the call is addressed.  Finally,
the location header of the SIP Invite message may be used to indicate
alternatives where to reach the called user -- which may be given
relative preferences or which may be associated with different quality
levels.  This would allow the caller to make an intelligent decision
on which of the alternatives to try next and would also allow more
sophisticated searching which is achieved at the cost of higher
complexity.  Many participants expressed that -- although some of
these features may be desirable -- they prefer it to go into the next
version of or an extension to SIP rather than into the base
specification to be completed soon.

For configuration purposes, Henning proposed SIP messages that allow a
client to register and unregister with a SIP server; this would
include user id, location information, etc.  It was noted that is
addresses (local) configuration of SIP servers / proxies and is an
orthogonal to the functions SIP is intended to perform.  In
particular, this is moving the protocol into a new area, which it
wasn't intended to solve, and for which different mechanisms
(e.g. with respect to security) were required.  Mark Handley pointed
out that the UCL session directory (sdr) implemented configuration by
means of the HTTP POST message.  No consensus was reached in the group
for the inclusion of these features in the (basic) SIP specification.

Overall, it was noted felt the scope of the base SIP specification and
its delineation from extension / profile documents seems unclear at
the moment.  The conference chairs and the editors agreed to sort out
the details soon after the IETF (again, see below).

It should be noted that from the intense discussions during the
meeting and lack of such controversies on the mailing list -- although
the SIP draft was published for quite some time and many features were
in there since late summer 1997 -- it became apparent that the
expected review of the SIP draft did not take place before the IETF.
The chairs encourage people to timely look at Internet Drafts as they
appear and debate them on the mailing list -- otherwise, silence may
be mistaken as consensus even though there is no agreement.

Joerg Ott presented a proposal on how to proceed with SIP to achieve a
stable document to become a standards track RFC soon.  In particular,
he noted that although the basic SIP idea has been around for a while
no stable state has been reached yet and that in the past only little
third party review took place.  Recently, SIP started broadening its
scope and keeps steadily growing which prevents it from becoming
stable.  He pointed out that, as there is the desire from other WGs to
make use of SIP, reaching a stable specification soon is a mandate;
otherwise, SIP may loose this last chance of gaining relevance in some
place.  As progress of the specification as it stands right now in
draft-ietf-mmusic-sip-04.txt depends on too many factors, he proposed
to split SIP into a basic specification that only defines the most
elementary features of SIP and one or more profile documents that
enhance SIP to meet the needs of other groups.  He also noted that
some of these extensions may not be in the scope of the MMUSIC WG and
in which case those would taken care of by other WGs.  The following
discussion confirmed this approach, and it was decided that the WG
chairs and the editors are to work out a delineation between the basic
SIP specification -- which is to contain a mandatory core and a few
generic extensions / options -- and potential profiles -- which may
address third party call setup (as required by PINT), advanced
supplementary services, user location, and others.  It is expected
that some extensions / profiles will be handled within the MMUSIC WG
while others will be developed in those WGs that intend to use SIP for
their purposes.

Session Annoucement Protocol (SAP)
----------------------------------

Mark Handley presented recent considerations on the Session
Announcement Protocol (SAP).  One major intended change stems from the
recent efforts on multicast address allocation undertaken by the IDMR
WG and from the discussion on using multiple Session Directories for
announcements (see Ross Finlayson's presentation described below).
This work will require to split away the part of SAP dealing with
multicast address allocation.  Mark noted that this does not require
protocol changes, but updates to the descriptive text may be needed in
various parts of the document.  Furthermore, the SAP specification
shall force people towards the use of administratively scoped
multicast addresses (to replace the currently used TTL scoping) and
hence the corresponding section on TTL scoping shall be
removed/replaced.

It was noted that SAP payloads (if carrying SDP data) may easily grow
larger than a typical MTU so that a UDP datagram carrying a SAP
message may need fragmentation.  It is suggested to use the GZIP
compression algorithm, but it was pointed out that GZIP is not
sufficiently well specified at this point.  Further work is needed
here.

A brief discussion on the use of the delete message for session
announcements was held.  It was found that the default means to delete
session announcements should be a timeout with delete messages used as
an optimization.

Finally, SAP shall be kept entirely independent of the payload type
SAP messages carry, i.e. the payload does not have to be SDP.
However, for the base session announcement multicast address, SDP
should be the default payload type.

With respect to the further work plan, it ws agreed to put SAP and
SAP Security (see next item) on the Standards track early 1998.

Session Annoucement Protocol (SAP) Security
-------------------------------------------

Edmund Whelan gave a presentation of the current status of work on
security.  SAP itself provides hooks to integrate security functions
(beyond encryption) but does not specify specific algorithms.  The
current Internet Draft draft-ietf-mmusic-sap-sec-03.txt defines
authentication and privacy based upon the PGP or PKCS#7 algorithms to
close these holes in the base SAP specification.

For authentication, a generic authentication header is provided which
is followed by an algorithm-specific subheader.  For symmetric
encryption, the approach of the basic SAP specification is followed,
hybrid encryption schemes make use of a combination of a generic
header and an algorithm-specific subheader.

The changes since the previous draft of Secure SAP include the
following.  Draft -03 now specifies two algorithms to be used with
SAP: PGP (RFC 1991) and PKCS#7.  Two open issues were raised by Edmund
for discussion in the group but not yet resolved: whether the group
should move from PGP to Open PGP to avoid mandatory support for
encumbered algorithms and, similarly, whether S/MIME version 3 should
be used instead of PKCS#7.  It was found that people seem to be keen
to make such moves, but the success depends on the progress of Open
PGP and S/MIME.  Another question raised in this context was whether
it was possible to mandate only a single algorithm rather than
requiring any implementation to support both.  There was no resolution
to this issue.

Finally, Edmund reported on the implementation status of Secure SAP:
symmetric encryption and PGP-based authentication and encryption were
reported to be complete in SDR.  He expect the remaining functions to
be completed in the near future -- i.e. in the January 1998 time
frame.

Work is continuing on the Secure SAP Internet Draft; a new revision
shall be coming up soon after the publication of the revised SAP draft.

Multiple Directories in SDP
---------------------------

Ross Finlayson presented an approach to support multiple session
directories instead of a single one for session announcements.  The
motivation for this idea stems from the observation that a single
directory does not scale.  Even with today's moderate use of the Mbone
announcement channel and despite regional announcements, the session
directory tools such as SDR show several dozens of sessions (with this
number continuously increasing).  This results in the user interface
getting cluttered and -- with only a single multicast group being used
to distribute all the announcents -- the interval between two
announcements of the same session gets very large (eventually
rendering this retransmission scheme useless) because of the fixed
bandwidth allocated to the announcement channel.

The solution proposed by Ross uses multiple directories with distinct
respective multicast addresses, bandwidth limitations, etc.  The use
of multiple independent directories is enabled because the recent work
on multicast address allocation allows decoupling this task from SAP.
A possible approach is to continue using the current announcement
session as "base directory" and announce new session directories
within the base directory as another session with a certain subject,
e.g. "test sessions", "radio/tv sessions", etc.  A new SDP media type
for session directory announcement could be

	m=directory <port> <protocol> <format>

with the initial protocol and format defined being "SAP" and "SDP".
Ross pointed out that this concept would in principle not require a
single root directory session but allow directories to be related to
one another in arbitrary graphs (like the world wide web), media
sessions could be coupled with related directory sessions, encrypted
directories are possible, and other (standardized or proprietary)
announcement protocols and directory formats could be used.  Finally,
it was pointed out that allowing multiple directories may require
changes to firewalls.

In the following discussion in the working group, a variety of issues
were raised that need to be solved in conjunction with the concept of
multiple directories.  It needs to be sorted out who controls the
creation of new directories and what happens with sessions announced
within a directory when this directory is deleted.  One approach could
be to see what happens and worry about it later; another would be to
follow a policy style comparable to NetNews.  As a policy will
eventually be needed anyway, one should think about a proper policy
right from the beginning.  In any case, security mechanisms
(particularly authentication) are a prerequisite for controlling use
of multiple directories.  Another issue pointed out is that arbitrary
graphs of directories may easily lead to confusion and make it
difficult to find the session directories or sessions of interest.  It
was also noted that the functionality of multiple directories could in
principle be easily provided by dedicated announcement newsgroups,
too, and hence care should be taken not to duplicate effort to solve a
well understood problem in an incompatible fashion.

It was concluded that much further investigation is needed.  Best
current practice should be documented to explain how multiple
directories are to be used, to delineate this concept from other
solutions for announcement channels (such as NetNews), to clarify
which features should be included in such a directory system, and to
enable deriving a feasible policy for its use.

Future Work in MMUSIC
---------------------

Joerg Ott briefly reviewed the status of the MMUSIC WG: RTSP and SDP
will be done soon, SIP is expected to go into last call by the end of
February or the beginning of March.  It was pointed out that SIP
requires authentication mechanisms; the editors agreed to investigate
the work on Secure SAP for re-use within SIP and incorporate the
necessary functions into the revised SIP specification.  Further work
on SIP profiles may be required to satisfy various usage scenarios for
this protocol and to provide support for other working groups that do
want to make use of SIP for other purposes.

The group decided to move SAP and Secure SAP should go experimental
RFC by the end of January to freeze the current specification and
their revisions should become standards track documents later in 1998.
The Internet Multimedia Conferencing Architecture draft should be
re-issued in the second week of January and go to last call shortly
thereafter.