Editor's Note:  These minutes have not been edited.



      Multiparty Multimedia Session Control (MMUSIC) Working Group
	                Minutes from the 38th IETF
	                  Memphis, Tennessee
                             April 8-9, 1997        	             

				Chairs

		Mark Handley, mjh@isi.edu
	 	Ruth Lang, rlang@sri.com
		Eve Schooler, schooler@cs.caltech.edu

The Multiparty Multimedia Session Control Working Group (MMUSIC) met
for two sessions on April 8th and 9th at the 38th IETF.  These notes,
prepared by Ruth Lang, summarize the presentations given and recount
issues raised and their resolution, if any, during these
presentations.  An on-line copy of the minutes and the accompanying
The minutes and slides are available from the MMUSIC archive area
ftp://ftp.isi.edu/confctrl/minutes in the files ietf.4.97 and
slides.4.97.(tar, tar.Z}.  Individual slide presentations can be 
obtained from the directory slides.4.97.

Mark Handley reiterated the WG Last Call placed for the Session
Description Protocol (SDP) and offered his time in sidebar meetings to
discuss any open issues.  See the slides sdp.ps.

Rob Lanphier and Anup Rao discussed the current status and open issues
of the Real Time Streaming Protocol (RTSP). They reviewed changes made
since our last meeting in December including the merger of the
original RTSP (Lanphier/Rao) and RTSP' (Schulzrinne), the maintenance
of the HTTP orientation of RTSP', and the simplification of the
protocol's state machine.  See the slides rtsp.ps.

The results of open issue discussions were as follows:
     
   - Use of two HTTP mechanisms (cookies for managing core RTSP server
     state and PEP, an option negotiation method as a replacement for
     the current "Require" field) were discussed.  The former was
     discouraged as it provided too broad of a solution (i.e.,
     overkill) for the RTSP server.  For the latter, the issue of PEP
     maturity with respect to the timeframe for forwarding RTSP to
     Proposed Draft was questioned.  Further deliberation on the this
     topic will occur on the mailing list in light of gaining a better
     knowledge of PEP.

   - A speed field whose application would imply fluctuating bandwidth
     usage during a session was encouraged as long as appropriate
     warnings about its potential misuse were included.

   - The use of absolute URIs (cf relative URIs) in the Request-URI
     message to reference content was strongly encouraged.
     
   - Further discussion will occur on the mailing list regarding the
     control of multiple streams. It was encouraged, however, that a
     single stream transmitted to n destinations be broken up into n
     separate sessions.

   - Sending data to a destination that is not the control source was
     oked for client-defined multicast address oked given inclusion of
     appropriate cautionary statement, and was discouraged (for now)
     for client-defined unicast address.

A more detailed account of these issues may be found at
http://www.real.com/prognet/rt/memphis.html.

Mark Handley presented the Session Announcement Protocol open issues
including:

   - use of a UUID vs IPv4 address for message id + source addr (the
     latter is currently specified).  The recent availability of an
     I-D describing UUIDs will seed well-thought discussion on this
     topic on the mailing list.

   - expansion of the current set of payload type fields. Although
     this adds flexibility (i.e., being able to convey other than SDP
     payloads), in practice it does not permit the presumption that
     the multicast address allocation scheme implemented by sdr --
     currently, the most widely-used tool for advertising MBone-based
     sessions -- is being used.  The more general issue of separating
     and documenting this address allocation mechanism arose.
     Although this work is needed, the downside of addressing it in
     the context of the current SAP is that redesign of the current
     mechanism and SAP protocol would be required, thus slowing-down
     progress of an already widely-used protocol to Experimental
     Standard status.

   - elimination of key identifiers for encryption as they serve as
     hints to the bad guys.  This move was supported by the group.

Mark also presented a proposal to the group to progress the current
SAP, with its security issues intact, to be an Experimental Standard.
With the movement of the SAP Security I-D to Proposed Standard, SAP or
a revision thereof would also then be forwarded to Proposed Standard.
This was met with agreement with the exception of a plea for
documentation of the current address allocation mechanism.  Mark
encouraged that this be brought to the attention of the Transport
Services Area Directors.  See the slides sap.ps.

Colin Perkins presented an overview of and open issues for the I-D
"Specification of Security in SAP Using Public Key Algorithms" aka
"SAP Security."  See the accompanying slides sap_security.ps.
SAP itself provides authentication hooks; this
document attempts to define mechanisms that can be put on those hooks.
Open issues included whether the key id field in the SAP header was
required: it was felt that this could move into a specific
authentication block as both PGP and PKCS#7 have key id fields.
Discussion of the need to define a standard privacy header, and
whether the simple public key format defined in the document
(simplified form of PKCS#7) or full PKCS#7 (or both) should be used
was deferred to discussion on the mailing list.

Joerg Ott presented "Panel-style Conferencing with H.323 based on
H.332" which described the use of H.332 for loosely coupled
conferences -- a protocol that can be used to create
IETF/MBone-interoperable sessions.  Use of SDP, SAP, and RTP are keys
to this interoperability.  Open issues presented included: SDP/SAP
does not permit dynamic changes to conference parameters as H.332
does, the potential for "floor request" implosions (a Join request on
the H.332 side which would allow the participant to generate content),
and the integration of data protocols -- T.120 style vs SRM style
application protocols -- different applications and application
protocol styles.  Joerg will circulate the H.332 specification to the
mailing list to encourage further discussion.  See the slides
h332over.{ppt, ps}.

Mark Handley presented the changes and open issues related to the
Session Invitation Protocol (SIP).  Changes included: "capabilities"
method was changed to "options" to align with RTSP, sequence numbers
were removed from the "path" field, and the "path" field was changed
to "via" to align with RTSP and HTTP (but the semantics are different
so this change is questionable).  Mark noted that the invitation of an
RTSP server into a conference needs explanation in the document. Time
was spent discussing the relationship between SIP and H.323 sessions.
Advantages of SIP were pointed out and discussions about H.323's
shortcomings ensued.  The general notion of SIP providing a more
lightweight mechanism and a different model were what justified its
independent existence but further study and discussion on this is
needed.  It was proposed by Mark that further implementation
experience be gained to aid the "shakedown" process of this proposal
(e.g., continued inclusion or exclusion of some HTTP headers which
have added complexity to the protocol).  See the slides sip.ps.

Joerg Ott presented some early results from a MERCI project on the
"Development of a Gateway for SIP/SCCP and H.323 Interaction."  Use of
SIP alone created a set-up mismatch which necessitated some string
pulling by the project team and creation of a situation where the
H.323 conference could be assumed established while the SIP-based side
was not yet established.  Introduction of SCCP to establish a
"control" conference aided this transition and created a workable
model.  Mark Handley questioned what changes to SIP would make this
call model more compatible?  Discussion will occur on the mailing list
on this.  See the slides merci-gw.{ppt, ps}.