Subject: [MMUSIC] MMUSIC Minutes

From: Joerg Ott <[email-masked]>
Date: Sat, 20 Apr 2002 02:02:33 +0200

Folks,

please find attached the minutes of the MMUSIC WG.

The slides are available from http://www.dmn.tzi.org/ietf/mmusic.
In particular, collections of all the slides are available at

  http://www.dmn.tzi.org/ietf/mmusic/53/slides/53-mmusic-slides-ppt.zip
  http://www.dmn.tzi.org/ietf/mmusic/53/slides/53-mmusic-slides-pdf.zip
  http://www.dmn.tzi.org/ietf/mmusic/53/slides/53-mmusic-slides-ps.zip

for the PPT (without the SDP presentation), PDF, and PS versions.

Thanks,
Colin & Joerg

Multiparty Multimedia Session Control WG (MMUSIC) 
=================================================

Wednesday, March 20 at 0900-1130 
--------------------------------

CHAIRS: Joerg Ott <[email-masked]> 
        Colin Perkins <[email-masked]> 

NOTES:  Tom Taylor, Colin Perkins
EDITED:	Joerg Ott
SLIDES: http://www.dmn.tzi.org/ietf/mmusic/

The MMUSIC WG met once at the 53rd IETF.  The meeting was attended by
some 150 participants.  After routine announcements the chairs
presented the proposed agenda which was accepted.  Then they announced
a joint lunch discussion for interested parties from MMUSIC and
SIPPING on the general topic of conferencing on the same day right
after the MMUSIC session.  Furthermore, a lunch discussion is to take
place on Thursday on RTSP.

Agenda Bashing and Status Update
--------------------------------
Presenters: chairs
Slides:	    53-mmusic-agenda.{ppt,pdf,ps}

The chairs presented a brief status update.  Work on the following
drafts has been finished and they have been or about about to be sent
to the IESG:

        - draft-ietf-mmusic-fid-06.txt 
        - draft-andreasen-mmusic-sdp-simcap-05.txt 
        - draft-ietf-mmusic-sdp4nat-02.txt 
        - draft-ietf-mmusic-sdp-offer-answer-02.txt 
        - draft-ietf-mmusic-sdp-ipv6-03.txt 

The revised charter of the MMUSIC WG has been approved, with
milestones through July and a review for continuation in the summer.

Work regarding most of the currently defined milestones is still on
schedule.  The submission of therevised SDP spec and the SDPng
motivations are late.  SDP key management is in yellow status, not
likely going to be on time.

Revised RTSP Specification
--------------------------
Presenters: Rob Lanphier <[email-masked]>,
            Magnus Westerlund <[email-masked]> 
Drafts:     draft-ietf-mmusic-rfc2326bis-00.txt
Slides:	    53-mmusic-rtsp.{ppt,pdf,ps}

The authors are working to go to Draft Standard.

Originally submission of the revised spec was planned to be done May
2002.  However, there is only a 30% chance of finishing specification
by then.  There is a delay on interop documentation.  Authors are
working on moving more complex/less implemented features out of core
specification and into extensions.

The design team has been holding open biweekly teleconferences since
January 2002.  So far ~68 bugs and 8 feature requests have been
filed.  Of the bugs, 20 have been closed, 5 have been classified as
"large tasks", and most of the others have yet to be addressed.  The
feature requests have not been discussed in detail.

Resolution of the following big issues has reached teleconference
consensus, which the team would like the MMUSIC WG to confirm:

* Clarification of aggregate/non-aggregate control 
  - state machine has been reworked
  - removed automatic transition at end of clip 
    - general sense that all transitions should be on the client side

* Should we eliminate queued play?
  - tentative answer of the design team: yes 

* RECORD needs specification work from implementors
  - may drop for lack of participation

* MUTE/UNMUTE proposal
  - replacing use of PAUSE for this purpose

* Transport mode requirements 
  - make support of persistent TCP mode required
  - non-persistent TCP mode required? (No, make optional and use SIP
    Supported: tag)

* Registration of feature tags for optional features (need to audit
  the specification)

Magnus Westerlund gave an overview of the simplified state machine.
The model features separate non-aggregate and aggregate Ready and Play
states.  Transition between Initial, Non-Aggregate, and Aggregate
modes can occur only when no media are playing out (i.e. in the Ready
states).

Question: Can resources be stranded if the server has no no automatic
change of state after play?  Rob responded: not too many resources are
tied up at that point.  The server can release resources specifically
associated with the playout without changing state.  So long as the
client is there, the remaining resources will eventually be released.

Queued play (multiple PLAY requests, with the server responsible for
serializing them): makes the state machine much more complex.  The
proposal is to allow multiple ranges in PLAY as a substitute, to be
specified as an extension to the core document.  Henning Schulzrinne
<[email-masked]> maintained that the Queued play mechanism does
not really affect the state machine.  Magnus replied that this was
technically correct, but it raises other issues.  Henning argued that
removal from the core specification could remove functionality needed
by every server.  He was concerned that mapping of multiple ranges
(the proposed substitute) might be difficult.  This subject will be
discussed further as part of Thursday's lunch meeting -- and
subsequently on the list.

RECORD: this is obviously a desirable feature, but implementors need
to to contribute since the current mechanism is underspecified.  One
of the open questions is whether ANNOUNCE is required.  If so, how
does one pair the session ID with the announcement?  Two people in the
room identified themselves as candidates for this part of the work.

The work is continuing by teleconferencing. 

Stephen Casner <[email-masked]> suggested that the current status
might call for a Proposed Standard revision, allowing the group to
finish interoperability testing in the ensuing 6 months.  Henning
Schulzrinne was concerned that this double effort might squander the
energy of the participants and the IESG.  Stephen clarified that the
transition to Draft Standard would be procedural, requiring no
revision to the specification itself.

There is an urgent need to formulate a feature matrix.  Volunteers
were sought, but none were forthcoming at the meeting.

MUTE/UNMUTE extension 
--------------------- 
Presenter:  Aravind Narasimhan <[email-masked]>.
Drafts:     draft-sergent-rtsp-mute-00.txt 
Slides:	    53-mmusic-rtsp-mute-unmute.{ppt,pdf,ps}

The authors identify that RFC 2326 is ambiguous and incomplete
regarding the implementation of features such as muting and unmuting
individual media streams as well as a session as a whole.
Particularly, aggregate/non-aggregate control interaction needs
clarification.  Currently, the PLAY and PAUSE methods are overloaded
to achieve the desired functionality.

The mute/unmute functionality seems an important (but optional)
features.  This feature specification has the support of the team at
large, not just that of the authors.  It fixes ambiguities and lack of
completeness in RFC 2326.  It is proposed to remove "mute"
functionality from the core RTSP spec and turn it into an extension.
As a result, won't be able to do pause of a single stream in an
aggregately controlled presentation.

The basic semantics of a new MUTE method are to temporarily suspend
one stream while the presentation clock keeps running (so other
streams can advance).  The proposed UNMUTE method resumes delivery of
a stream from current presentation NPT.  In both methods, a Range:
header (which must be open) is allowed to schedule MUTE commands.

The authors also list a number of open issues to be addressed:
* interation with queued PLAY, RECORD 
* UNMUTE response needs a Range header 
* what is the response to UNMUTE on an already UNMUTED stream? 
  - 200 OK? 455 Method not valid in this state? Other? 
* effect on RTSP state machine if any? 
* IANA registration: "mute" options tag 
* definitions of terms, security considerations, acknowledgements. 

Humming indicates moderate support to take this up as a WG item with
no one opposing.

RTP Archiving, Delivery, and Playback extensions for SDP (RADPlay) 
------------------------------------------------------------------ 
Presenter:  Rob Lanphier <[email-masked]>
Drafts:     draft-lanphier-radplay-00.txt 
Slides:	    53-mmusic-rtsp-radplay.{ppt,pdf,ps}

The motivation for this proposal is to get around firewall blocking
certain protocol traffic (such as media streaming).  It enables
HTTP-based delivery of RTP.  The approach taken also solves numerous
other problems including archiving, cache population, archive
playback.

The proposed mechanism defines a set of simple extensions to SDP: In
addition to just providing the session description for one or more
media streams as RTP session description(s), further attributes are
defined that indicate the source file format of the media streams so
that these can be retrieved (via download by means of e.g. HTTP) if
setting up an RTSP/RTP-based media session does not succeed.  Three
extension attributes are proposed:

  a=srcfile    -- URL for source media in on-demand playback 
  a=dumpfile   -- URL for "dump" of an individual stream 
  a=dumpindex  -- simple index to dumpfile 

In addition, the a=control can be used outside of RTSP session
context to indicate SDP meta files. 

Rob showed an example featuring fallback from one possibility to the
next.

Melinda Shore <[email-masked]> commented that archiving is good, but
violating firewall policy is not.  We should resist proposals with
that intent in the IETF.  Henning Schulzrinne countered that the
proposal was actually adapting to local policy, not bypassing it -- if
streaming is not allowed, the proposal falls back to file transfer.
It is easy to block the MIME type at firewall.  This is a more
explicit alternative to stealth approaches.

Syntax comment: generalize to "alternate file" attribute.  Rob
responded that it was nice to have the tighter semantics presented,
but the proposal was something to be discussed on list.

The chairs' poll indicated reasonable support for doing this work as
MMUSIC work item, with some opposition.

Revised SDP spec
----------------
Presenter:  Colin Perkins <[email-masked]> 
Drafts:	    draft-ietf-mmusic-sdp-new-06.txt 
Slides:	    53-mmusic-sdp.{pdf,ps}

The work on SDP has featured bug fixes.  There have been two revisions
since last meeting.  Colin reviewed the changes in -05 and -06.

To do: allow a=rtpmap to be a session-level attribute, as agreed on
the list.  Colin asked whether there should be a TTL parameter for
IPv6 multicast.  Gonzalo Camarillo <[email-masked]>
noted that this parameter was removed from the IPv6 draft at IESG
direction.  Conclusion: it will be removed from text.

Colin called for volunteers for interoperability testing.  A few
volunteers raised their hands.

Keith Drage <[email-masked]> asked about the schedule for approval
of the new document.  3GPP needs an RFC number for reference by June.
Colin indicated that the schedule was constrained by interoperability
testing.  A viable alternative to meet 3G deadlines is not to go to
Draft Standard right away but cycle at proposed.  If going to draft is
possible then this is the preferred approach.

Key management with SDP
-----------------------
Presenter:  Fredrik Lindholm <[email-masked]> 
Drafts:	    draft-ietf-mmusic-kmgmt-ext-03.txt 
Slides:	    53-mmusic-sdp-kmgmt-ext.{ppt,pdf,ps}

The latest revision of the document has more added more rationale to
text and has adopted the offer-answer model as basis for the key
exchange.  Furthermore, the ABNF has been updated to conform with
latest SDP, RTSP.  Scenarios and examples have been added.

The following SDP extensions are proposed: 

  keymgmt-prtcl  = "keymgmt-prot:" prtcl-name 
  prtcl-name     = non-ws-string              
  keymgmt-data   = "keymgmt-data:" byte-string 
  key-extra-auth = "keymgmt-auth:" byte-string 

For RTSP, additional extensions are required since SDP is not always
passed between the peers when key management needs it:

  KeyMgmt    = "KeyMgmt" ":" [stream-url] protocol data 
  stream-url = "url" "=" url ";"   
  protocol   = "Prot" "=" token ";" 
  data       = "Data" "=" quoted-string 

Colin noted the philosophical issue of whether parameters should be
opaque or whether instead the semantics should be more explicit.
Henning Schulzrinne commented that explicit semantics make
interoperability debugging easier.

Martin Euchner <[email-masked]> queried the scope of
intended application of the extensions, and was satisfied with
Fredrik's response.  He raised an issue with NAT passage.  Fredrik
agreed the receiver cannot authenticate a NATted port.

One person spoke against explicit semantics, except for the
authentication part.  Another person foresaw issues with encryption
validity if the blob is broken up: The length of the attributes might
cause problems for the containing signalling.  Also, offer-answer may
be able to carry other key management protocols, but a change in the
messaging model might be needed.  There is also need to think of
support for future key exchange protocols with differing numbers of
message exchanges.

Peter Barany <[email-masked]> expressed his preference for
explicit semantics, reflecting discussion from the compression group.
It is possible the static dictionary would be enhanced.  Some people
noted problems connected with this.  Carsten Bormann <[email-masked]>
noted that the SIP dictionary would be generated soon.  The stability
of naming of attributes is of interest -- changes affect efficiency.

Christian Huitema asked if we should SDP-level encryption or S/MIME.
What changes would there be if SDP were carried in S/MIME?  The
response was that this would be good if one can assume S/MIME is
always used.  Tom Taylor <[email-masked]> noted the
potential impact of that assumption on Megaco, which carries SDP
embedded within the protocol rather than as a separate body.

Joerg Ott indicated that the WG should do an analysis of the
implications of S/MIME.  Further discussion on the list is needed to
close on these issues.

SDP for connection-oriented media
---------------------------------
Presenters:  David Yon <[email-masked]> provided a status update.  The following
Drafts:	     draft-ietf-mmusic-sdp-comedia-01.txt 
Slides:	     53-mmusic-sdp-comedia.{ppt,pdf,ps}
	     53-mmusic-agenda.{ppt,pdf,ps}

Work is proceeding on the next revision of the draft (-02).  Changes
to go into this draft include a new section on symmetric RTP/AVP and
minor syntax changes to match SDP-new.  There are still issues with
the attribute direction:reuse and direction:both still have issues.

Joerg Ott took over to present some proposals to resolve the issues
that the current comedia model is somewhat inconsistent with the use
of SDP for RTP streams.  The issues as he summarized them derived from
the following points of inconsistency between the comedia model and
SDP use for RTP streams: TCP requires explicit setup/teardown as an
extra step at the transport layer (while for UDP only local state is
created but not shared at the transport layer).  TCP connections are
bi-directional but are created asymmetrically while this process is
symmetric for RTP/UDP.  There are other differences from UDP, but with
this draft we are looking at transport capability as opposed to
transport use.

It is important that the basic SDP handling not be changed for
comedia: session descriptions must be self-contained and, as for
RTP/UDP, resending same SDP should cause no change in state.

The WG came up with a list of requirements in December, but the topic
died.  Joerg presented that list, with one possible addition.  He
asked whether it is required to allow multiple TCP connections as part
of a single media stream.

Joerg noted that the requirements may differ for non-SIP use.  The WG
may want to limit the scope of the draft.

Gonzalo Camarillo didn't think multiple TCP connections would work.
However, there are other means for grouping.

Joerg summed up: the WG needs to continue work toward a general
solution, meeting the requirements one by one.  He suggested a
conceptual approach based on "primitives".

SDP for voice-band data
-----------------------
Presenters:  Rajesh Kumar <[email-masked]>
Drafts:	     draft-foster-mmusic-vbdformat-01.txt 
Slides:	     53-mmusic-sdp-vbdformat.{ppt,pdf,ps}

The draft proposes a new MIME type to distinguish voice-band encoded
data (VBD) (e.g. low-speed modems).  One parameter is specified to
indicate the underlying coding (PCMU, G.726-32, etc.), another to
indicate the data rate.  The MIME type approach was taken in response
to comments on an earlier approach.  The underlying coding parameter
is required because there is a requirement to associate VBD with the
underlying encoding.

Stephen Casner observed that the indirect approach to the definition
of encoding seemed to be the wrong approach, because it hides the
codec at a level below where implementors would expect).  However, we
can't provide the required fmtp parameters to existing formats.  Colin
Perkins saw two choices: use attributes, or add parameters to specific
encodings.  Stephen suggested that one could have a=vbd: 98 where the
98 is then mapped to VBD/8000.  As an alternative: define PCMU-VBD
etc.  Henning Schulzrinne judged this latter the cleanest solution,
but not generalizable to the next attribute.  Stephen suggested the
possible addition of an attribute like fmtp, but not encoding
specific.

Suggestion: go off-line, do design work on such a media parameter.  As
a new attribute, this might or might not go into sdp-new.

SDPng transition
----------------
Presenters:  Joerg Ott <[email-masked]>
	     Colin Perkins <[email-masked]>
Drafts:	     draft-ietf-mmusic-sdpng-trans-00.txt 
Slides:	     53-mmusic-agenda.{ppt,pdf,ps}

The chairs created the document to prepare for a smooth transition
from SDP to SDPng.  They postulated the need for SDP and SDPng to
co-exist for a number of years.  They propose a protocol-specific
approach, wherein one end could offer both protocols to the other end
until SDPng support or non-support became clear.  Different ways could
be used to achieve this: both protocols in the same message,
alternative message formats sent to different addresses, initial offer
of SDPng with fallback to SDP, etc.  They reviewed the approaches that
might be taken for different protocols.  Tom Taylor promised to
contribute to the draft on behalf of MEGACO.

Henning Schulzrinne remarked that SIP hasn't tackled basic issues of
application of SDPng yet, so it is too early to worry about
multipart/alternative.  He also suggested the WG make sure that the
transition strategy is not too closely tied to the current specific
format.

SDPng Update
------------
Presenters:  Dirk Kutscher <[email-masked]> 
Drafts:      draft-ietf-mmusic-sdpng-04.txt 
Slides:	     53-mmusic-sdpng.{ppt,pdf,ps}

The changes in the latest revision of the draft (-04) include the
introduction of a generic syntax mechanism for reusing definitions:
sdpng:use, sdpng:group, sdpng:prop.  Also, capability negotiation is
described now more extensively.  The offer/answer model has been
incorporated: typically, the answerer matches the offer against list
of supported configurations.  In formalizing the messages, there may
be a problem with some applications (e.g. video) that need a lot of
parameters.  In such a case, representing each variant as an
individual alternative is not practical (far too verbose).  Here, a
more expressive mechanism is needed (e.g. ranges) as well as
algorithms to collapse descriptions.  Dirk listed several desiderata
for the resolution of these requirements: it must be simple, must no
yield too large messages, must be usable with SIP, RTSP, MEGACO, and
SAP, support single round-trip negotiation as in offer/answer, and
should support multiparty negotiation as well.  And the mechanism must
be extensible.  Dirk presented the conceptual overview of the proposed
algorithm contained in the current draft that meets there
requirements.

Dirk also pointed out a number of open issues to be addressed:

* In SDP, descriptions reflect originator viewpoint which often leads
  to ambiguities, particularly in multiparty scenarios.  Should the
  descriptions reflect a global viewpoint?

* SDPng currently has the concept of "external libraries" that may
  contain collections of definition to be (dynamically) imported.  Is
  this useful?

* Numerous requirements have been discussed for capability
  negotiation.  Which (minimal) functionality is really needed?  This
  requires further discussion!

* Further on capability negotiation: what are actual semantics of
  descriptions and negotiation results?
  - e.g. range of parameters in final descriptions
  - are senders free to select values?
  - is signalling required?

* SDPng provides mechanisms to label definitions and refer to them by
  those labels/names; the involved endpoints are likely to use
  different labels.  For capability negotiation, all those references
  must be resolved; then the collapsing process yields a set of new
  description instances.  How can those (likely rather verbose
  descriptions), be reduced to a new compact description instance?

* Profiles need development, now they are just represented by
  examples.  In particular, a full representation of AVP/RTP needs to
  be specified, security e.g. MIKEY, possibly QoS, etc.

The next steps are to restructure the current spec iinto several
documents: a framework document (Informational), the SDPng
specification (Standards Track), and Profiles (Standards Track).  A
complete list of open issues needs to be discussed and resolve on
list.  Work on profiles needs to progress further.

There is a C++ implementation of SDPng-03 using the expat parser.  It
is being updated to take in newer material.

Henning Schulzrinne asked if they had examined schema definition
languages and WSDL type definitions.  Dirk responded that they had
weighed this approached and found that it had complexity issues.  He
agreed with Henning on the basic concern.  Henning identified a second
issue: whether SDPng can express capabilities vs. preferences.

SDPng and QoS
-------------
Presenters:  Chairs
Drafts:      draft-bos-mmusic-sdpng-qos-00.txt 
Slides:	     53-mmusic-agenda.{ppt,pdf,ps}

The chairs noted a number of activities relating to QOS signalling
including manyfolks work on QoS relating to SIP, media authentication
(also from the SIP context), reservation parameters derived from
codec, dynamic mapping to RSVP, and diffserv traffic classes.

A brief overview of the above draft was given: they identify types of
end-to-end QOS information: traffic information, i.e. characterization
of the packet traffic for a specific media flow, and sensitivity
information that specifies the QOS level given the traffic information
(and can be expressed in various ways).

The chairs moved on to present a general overview of various QoS
architectures showing different ways of how and where QoS may be
requested, enforced, and/or provided in the network, including RSVP,
diffserv, centralized resource control, among others.  They pointed
out a number of questions to ask before/when taking up QoS work in the
context of the MMUSIC WG (for SDPng):

- What have we missed so far?
- Do we need QoS information beyond what can be derived from the current SDP?
- Where would this information come from?
- Is there a need to signal this inband?
- Is this signaling session or application layer?
- Do we need to synchronize endpoints on (changes in) QoS (profiles)?
- How much complexity is acceptable?

In summary, we need to determine what the real problem is and whether
or not there is a real need to do QoS signaling in the control path

The chairs pointed out that QoS, if signalng in the control path, is
potentially just yet another dimension of potential and actual
configuration.  Similar approaches may need to be taken for other
areas as well, e.g. security.  If QoS is taken up (as part of SDPng),
it should just be a specific instantiation of a generalized mechanism.

MMUSIC and Electronic Program Guides 
------------------------------------
Presenters:  Chairs
	     Yuji Nomura <[email-masked]>
Drafts:	     draft-nomura-mmusic-pguide-requirements-00.txt 
Slides:	     53-mmusic-agenda.{ppt,pdf,ps}
	     53-mmusic-epg.{ppt,pdf,ps}

The chairs introduced the topic of Electronic Program Guides (EPGs):
Various groups are looking at broadcasting over IP (DVB-IPI, set-top
boxes running IP).  Electronic program guides are a necessary part of
this.  Do we want to work on them?  Possible work items are:

- SDPng for Electronic Program Guides 
- SAP and other mechanisms for distributing them 
- minimal RTSP for retrieval 

Yuji Nomura <[email-masked]> presented a first requirements
document.  He gave a brief definition of program guide and outlined
the basic protocol requirements: on demand retrieval, update
notification, comprehensive description.  He feels that SDPng does not
match these requirements well today.  He also points out that MPEG-7
offers a comprehensive set of description tools, and could be the
basis (or input) for the work.

Rob Lanphier asked if any file retrieval protocol would work.  Henning
Schulzrinne responded: the point is that candidates are available, but
they are missing the update notification component.

Joerg Ott saw some potential areas of activity fitting into the
traditional scope of the Working Group.  The was some support for
taking up this work in the MMUSIC WG, nobody opposed.  The Chairs will
examine further for potential uptake.