Subject: [MMUSIC] [Fwd: Re: Draft MMUSIC Minutes]

From: Joerg Ott <[email-masked]>
Date: Fri, 08 Apr 2005 19:17:09 +0200

Hi,

attached are the minutes for the meeting of the MMUSIC WG
at the 62nd IETF.

Colin and Joerg
Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
====================================================================

Reported by Colin Perkins and Joerg Ott

   The MMUSIC working group met once at the 62nd IETF meeting (Minneapolis,
   March 2005). Topics under discussion included SDP extensions for BFCP,
   content labels and connectivity preconditions, the ICE methodology for
   NAT traversal, the SDPng specification, stream tracking for resource
   management, harmonisation between SDPng and MPEG-21, RTSP, and Internet
   Media Guides. The meeting was chaired by Joerg Ott and Colin Perkins.

SDP Format for BFCP

   draft-ietf-mmusic-sdp-bfcp-00.txt

   Gonzalo Camarillo presented the SDP Format for BFCP. The specification
   for BFCP now has support for different hashing algorithms, meaning that
   the SDP format needs to be updated to use the sdescriptions format, not
   than the "k=" line. There have also been a number of clarifications to 
   the draft regarding peer-to-peer use of BFCP (this work is ongoing).
   Gonzalo solicited input, noting that he expected the next revision to
   be complete. There were no comments.

SDP Content Label

   draft-hautakorpi-mmusic-sdp-media-content-00.txt

   Jani Hautakorpi discussed the SDP Content Label. This is a media level
   attribute that can be used to label streams with semantic meaning, so
   receivers can automatically treat each media stream appropriately. It
   is expected that labels will be things like "main camera", "speaker"
   or "presentation slides" and will be partly interoperable with roles
   defined by H.239.

   There was an extensive discussion regarding the difficulty of assigning
   labels and explicitly defining their semantics, with Brian Rosen noting
   that it may be hard to come to agreement about labels and their meaning.
   Gonzalo Camarillo and Roni Even disagreed about the difficulty, noting 
   that there is a need for these labels, and that products exist that 
   implement similar mechanisms. Jonathan Rosenberg and Brian Rosen both
   commented that there is related work ongoing in the SIMPLE and XCON
   working groups, and similar concepts in SMIL, with which we may need to
   align. Henning Schulzrinne and others noted that there are many possible
   labels, but that we only care about a small number of simple cases, and
   an application that receives an unknown label is no worse than one which
   receives no label. Joerg Ott finally wrapped up the discussion by noting
   that there is a clear interest in this work, and encouraged people to
   read and comment on the mailing list. 

SDP Connectivity Preconditions

   draft-andreasen-mmusic-connectivityprecondition-02.txt

   Flemming Andreasen presented the draft on connectivity preconditions for
   SDP media streams, outlining the problem and changes since the previous
   version.

   An open issue is that the draft does not mandate any particular way of
   verifying connectivity, although it does recommend the RTP NOOP format.
   Should the draft mandate a mechanism and if so which mechanism?  Colin
   Perkins noted that the RTP NOOP draft has expired and will need to be
   updated if that is the choice. Flemming and Gonzalo Camarillo wondered
   about the overlap between the connection and connectivity precondition
   drafts and whether they should be merged?  There was discussion about
   the semantics of connection establishment versus those of connectivity.
   Jonathan Rosenberg, Magnus Westerlund, Gonzalo and Flemming discussed
   the need for a three-way handshake to define connectivity and how NAT
   traversal issues may affect this. There was no real conclusion: it is
   clear further discussion is needed on the list.

ICE

   draft-ietf-mmusic-ice-04.txt

   Jonathan Rosenberg discussed the ICE methodology for NAT traversal,
   noting that the -04 draft has not been changed compared to the -03,
   but that there are a number of open issues. Changes that have been
   agreed and will be incorporated include a clarification of re-INVITE
   behaviour, a change to make implementation of TURN optional, setting
   the RTCP bandwidth parameter to zero if you are not using RTCP, and
   some discussion on issues regarding congestion caused by STUN traffic
   using session startup.

   Open issue #1: obfuscating ICE addresses. Is there a need to try to
   obfuscate IP addresses to prevent "helpful" NATs from rewriting the 
   addresses and breaking ICE? Consensus: no.

   Open issue #2: RTP specificity. The candidate attribute is RTP specific
   but we may need candidate addresses for non-RTP transports. Propose to
   define a more generic candidate attribute, using the priority field to
   group candidate addresses (e.g. to group RTP and RTCP). Consensus was 
   to make this change.

   Open issue #3: TCP alternates for UDP. Currently the only alternatives
   you can choose for UDP are other UDP addresses; we cannot fall back to 
   a TCP connection if all UDP addresses fail. Propose to extend the ICE 
   specification to allow fallback to TCP as a connection of last resort,
   and to document both how this affects performance and the implications
   this has for sites that block UDP at their firewall as a policy measure
   to prevent VoIP. Cullen Jennings was concerned that this has potential
   to start an arms race with firewall vendors and administrators, and
   worried about circumvention of firewall policy. Colin Perkins and Jon
   Peterson noted that certain proprietary applications also fallback to
   TCP: this is not an unknown technique, we need to compete with those
   systems to ensure our protcols remain valid and useful. It seems that
   there was rough consensus that use of TCP was not ideal, and concern
   that one may not wish to implement fallback to TCP as a default, but
   that in the current Internet it may be necessary to allow such a
   fallback as an option.

   There are a number of other open issues, concerning fallback to TCP and
   identification of RTP profiles, diagnosis of problems since the final IP
   address and port are never signalled, interaction with preconditions and
   middleboxes, dynamic RTP address changes, the ugliness of demuxing STUN 
   and RTP, and interactions with SRTP. 

   Jonathan noted that the root cause of all these problems is the single
   fact that a peer in the dialog starts sending media to the new address
   once the connectivity check succeeds without signalling that address.
   Proposal: separate these and always send media to the address/port in
   the "m=" and "c=" lines, and only send connectivity checks to the
   address/port in the candidate lines. When connectivity checks succeed,
   do a re-INVITE or UPDATE that "promotes" the candidate address/port to
   the "m="/"c=" lines. Note that this does not increase call setup time
   or post-dial delay. [see slides for a sample call flow, illustrating
   operation of the proposal]. There was considerable discussion of the
   details of the idea, with the consensus being generally in favour. The
   details will be defined on the mailing list, with an updated draft to
   be published documenting the new approach.

Stream Tracking for Resource Management in the Network

   draft-guenkova-mmusic-sdp-ng-streamtrack-00.txt

   Ingo Wolf presented a new proposal for streaming tracking for resource
   management in the network. This is a modification to SDP and SDPng to
   convey source addresses and ports, which is hoped can be used to signal
   stream details to middleboxes which can then attempt to ensure QoS. 

   Cullen Jennings inquired the precise problem definition that the
   draft is supposed to solve and wanted to know why the proposed
   solution solved it.  Ingo stated that the motivation is to provide
   an explicit grouping between source addresses of RTP and RTCP.
   However, Cullen argued that the draft seemed to be primarily about
   QoS with some missing information at present.  Source port
   information are only one piece of these missing bits but there is a
   whole lot more.  He wondered why the draft did not concern itself
   with these additional missing parameters.  According to Ingo, this
   was beyond the scope of the draft -- which was understood, but this
   exactly raised the issue of what precisely the draft tries to address.

   Joerg Ott noted that SIP signalling provides a clear separation between
   the precondition work to signal that some sort of QoS is required and
   the mechanism used to establish the QoS. The two pieces are currently
   separate: this draft tries to combine them, but it is not clear that
   they belong together. Joerg noted that the draft assumes entities on the
   path have access to the content, and that source ports are accurate, but
   we have generally assumed the opposite in the IETF. Magnus Westerlund
   agreed with Joerg and Cullen, further noting that with NAT traversal
   being an increasing issue it is often the case that an end point is not
   aware of its address as seen by the peer endpoint. 

   In summary, the added value of this proposal is unclear.

Harmonization between SDPng and MPEG-21

   draft-guenkova-mmusic-mpeg21-sdpng-00

   Ingo Wolf presented further on a proposed harmonizatoin between
   SDPng and MPEG-21: He claimed that SDPng was transport-oriented
   while MPEG-21 DIA was technology-independent and focused on (media)
   presentation.  He suggested an integration model in which all the
   SDPng containers are reused.  The <cap>, <def>, <cfg> elements
   largely remain the same, only some adjustments are proposed to the
   RTP package.  The <constraints> element is augments to cover Usage
   Environment Descriptions (UED) and should be used to address
   constraints all levels of abstraction.  Important extensions
   include the reference to external definitions using the href
   attribute, the application of MPEG-7 media stream and codec
   spefications, and some revisions to name-value pair based
   mechanism for cross referencing definitions within an SDPng
   document.  Ingo walked through a detalied example (see slides for
   the details).

   Steve Casner noted that the namespace for MPEG-21 has a huge
   overlap to the one defined in RFC3551.  He further pointed out that
   to the extent that MPEG-21 identifies how transport is to be done,
   the RTP names identify actual payload formats.  One cannot simply
   skip that identification as this is needed in additon to the codec
   identification.  Brian Rosen agreed that one needs to explicitly
   specify the mapping.  Colin noted that the key advantage of SIP/SDP
   is that peers can negotiate arbitrary MIME types.  He questions the
   benefit from the proposal which is limited to a subset of the
   codecs that are supported through the MIME type mechanism and adds
   that the proposal does not support application/*, text/*, etc.
   Magnus Westerlund pointed out that the proposal allows to describe
   streams that cannot be transported, and Dirk Kutscher uttered
   similar concerns to Colin and Magnus.

   In summary, it is questionable how the approach presented relates
   properly to the work in MMUSIC, AVT, and other groups in the IETF
   at large.

SDPng

   draft-ietf-mmusic-sdpng-08.txt

   Dirk Kutscher presented the latest draft on SDPng.  After a brief
   recap of the motivation and the overall structure, he stressed
   which aspects are not (supposed to be) covered by the SDPng base
   spec: application-specific vocaublary, application semantics,
   vocabulary for expressing constraints across multiple
   configurations, and vocabulary for metadata.  This additional
   information needs be either specified as extensions/packages (e.g.,
   transport protocols, codecs, packetization formats) or defined
   in the context of the respective applications (e.g., semantics).

   The changes in the most recent version include a more explicit
   inclusion of broadcast scenarios (cf. SAP, IMG), correspondingly
   make the <cap> element for negotiation optional,  and the addition
   of descriptions of further scenarios.  A "status" attribute has
   been added for the <component> elements and a new child element
   <part> is now allowed for the <info> element that allows
   encapsulating arbitrary meta description formats.

   Open issues at this point include: the status element is currently
   overloaded (and part of the semantics will be moved to the RTP
   package), IANA considerations need to be written (a registry for
   package information needs to be set up), XLM schema and DTD
   definitions need to be done, and the examples need to be aligned
   with the spec.  Finally, at some point, the spec needs a real name
   (other than "SDPng").  The group is encouraged to review the spec
   now and comment so that WGLC before 63rd IETF is possible.  Next
   steps to take further include completing the RTP package
   definition, dealing with a security package, and providing for meta
   descriptions.

   Info Wolf noted that he wants to see more discussion about how
   people could extend SDPng.  Colin Perkins agreed with that and
   encouraged further work to be put into this.

RTSP

   draft-ietf-mmusic-rfc2326bis-09.txt

   Magnus Westerlund presents the current status and some issues with
   the current revision of the RTSP specification.  Due to shortage of
   time, he skips most of the stuff and starts with the issue of
   explicit white spacing (slide #5): he reviews the RTSP rules for
   white spaces as separators between tokes.  He wants to change the
   use of "," and ";" to explicitly allow for whitespaces around them
   for which he seeks input from the group.  Another (related) issue
   are the RTSP headers that are currently defined with reference to
   RFC 2616.  However, RFC 2616 does not use RFC 2234 BNF with
   explicit white spacing.  His suggestion is to copy the syntax
   into RTSP and make the whitespaces explicit.

   The chairs urge people to review the draft and comment.

Internet Media Guides

   Yuji Nomura shortly described the recent activities regarding IMGs.
   Due to lack of time, he keeps the presentation extremely short: He
   briefly summarizes the interim discussions on the IMG envelope to
   carry metadata: the authors and a few others have discussed the use
   of XML as envelope systax vs. MIME encapsulation.  Both can be
   defined (or extended) to provide the right functions for IMG
   envelopes and allow the re-use of existing specifications.  XML is
   expected to require more work and be not as efficient to
   encapsulate binary data but MIME is not a perfect match either.
   Open issues are related to the inclusion/representation of
   versioning information and a metadata URI, a validity period, and
   proper authentication of subsets of IMG metadata.  For the next
   steps, input from the group is sought: a new draft on an IMG
   envelope based upon MIME may be defined, the other drafts will be
   updated.

                                   - + -

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic