Subject: [MMUSIC] Draft MMUSIC minutes

From: Joerg Ott <[email-masked]>
Date: Thu, 09 Dec 2004 18:01:30 +0100

Folks,

attached are the draft minutes of the MMUSIC meeting in DC.
Please review them and send any comments to the list.

Thanks,
Joerg

Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
61st IETF meeting, Washington DC, November 2004

Reported by Colin Perkins

   The MMUSIC working group met once at the 61st IETF in Washington
   DC.  The meeting was attended by some 80 participants.  Subjects
   under discussion included application sharing, ICE, Internet Media
   Guides, SDP and various SDP extensions (for media loopback, BFCP,
   labels and connection establishment, security and connectivity
   preconditions).

Introduction and Status Update

   The meeting started with an introduction and status update from the
   chairs. The working group has had one RFC published since the last
   meeting (RFC 3890 on the Session Bandwidth Modifier) and has several
   drafts are under IESG review: the IMG requirements and framework, SDP
   source filter extensions and SDP connection oriented media extensions.
   The draft on Alternative Network Address Types Semantics (ANAT) for the
   SDP Grouping Framework has been updated in response to IESG comments and
   is back under review. The SDP key management and security descriptions
   drafts are being updated in response to review comments from the IESG.

   Several drafts have been discussed on the mailing list, but are not on
   the agenda for the meeting. Remote camera control will be discussed in
   AVT (draft-even-avt-h224-00.txt). RTSP (draft-ietf-mmusic-rfc2326bis-08.txt)
   and the ANNOUNCE extension (draft-ietf-mmusic-rtsp-announce-00.txt) are 
   in progress, but delayed due to lack of review and editing manpower --
   help was solicited. The main connection-oriented media specification
   (draft-ietf-mmusic-sdp-comedia-09.txt) is under IESG review, the TLS
   extension to comedia (draft-ietf-mmusic-comedia-tls-02.txt) is under
   development. Symmetric RTP (draft-wing-mmusic-symmetric-rtprtcp-01.txt)
   is clearly useful, but the chairs suggested it would be better suited 
   to the AVT working group. The draft on tight membership support in SDP
   (draft-ekim-mmusic-sdp-membership-01.txt) conflicts with work in XCON,
   and should be discussed there.

   The Internet Media Guide (IMG) requirements and framework are complete
   and under review by the IESG. We have a milestone to revise our charter 
   to accomodate future work in this area. Work to be considered includes:
   IMG ANNOUNCE via FLUTE, IMG QUERY/RESOLVE via HTTP, IMG SUBSCRIBE/NOTIFY 
   via SIP, and possibly IMG MIME types and URI/URL formats. The chairs,
   area director, and parties interested in IMGs will work to develop new
   milestones are charter text to cover this work, and bring it back to
   the working group for review.

ICE: A Methodology for NAT Traversal

   Jonathan Rosenberg presented ICE (draft-ietf-mmusic-ice-03.txt) outlining
   the changes since the previous version and discussing open issues. Major 
   changes include: 

    - In the ABNF, rename the "alt" attribute to "candidate" to avoid a
      conflict with 3GPP specs, remove the remnents of "derived-from",
      and change the "username" attribute to "user-frag" to more closely
      reflect its semantics.

    - The ICE XML schema has been updated to support both IPv4 and IPv6
      (the implementation of ICE using ANAT supports this already, this
      change brings the schema in line with reality).

    - Added implementation hints on masking allocation latency.

    - Updated discussion of use of TURN as an address allocation protocol,
      making it "SHOULD" strength rather than "MUST" strength, to reflect
      concerns expressed previously. Added text to explain why TURN is a 
      good thing to implement for address allocation. Noted that other
      allocation protocol can be used.

    - Clarified that username and password are different for each transport
      address.

    - Discussed the misrouting scenario raised by Pete Cordell, where STUN
      keep-alives can be sent to a third party that isn't expecting them.
      This is a fundamental issue with the non-uniqueness of IP addresses
      across NAT-realms, not something that can be solved in ICE.

    - Removed mid-session checks. STUN now runs until a media packet is
      received, then you revert to sending only media packets (and using
      media-specific means, rather than STUN, as a keep-alive). Enforces
      a clear separation between the STUN server and the media tool.
      Added a section on application-layer keep-alives.

    - Add discussion on how to choose a default address. 

    - Now use one local transport address for each usable address. This
      gives a one-to-one mapping between the local address/port pair and
      the address that goes in SDP, simplifying the protocol and fixing 
      some bugs, but at the cost of opening more sockets. 

    - Rewrote the description of re-invite handling. Cullen Jennings noted 
      an issue with this, since reverting to an old address can fail if the
      NAT binding for that address has timed out. There may be a need to
      redo the negotiation with a new username and password. 

    - TURN has been promoted to a normative reference, however Cullen
      Jennings is worried that TURN is late and a normative reference may
      delay ICE. It was agreed to revert this to a reference to "some media
      relay protocol" using TURN as an example of a protocol with the
      required properties, to avoid this potential delay.  Considerable
      discussion ensued, covering a number of these issues.

    - Made RTCP information optional in SDP, since many devices don't
      implement RTCP. Magnus Westerlund suggested it is necessary to set
      the RTCP bandwidth parameter to zero, in addition to avoiding the ICE
      check, to inform the other end-point that RTCP isn't used. Jonathan
      agreed that setting the RTCP bandwidth to zero would be a good thing,
      but that implementations didn't do it. Rohan Mahy noted that we can
      say "if you don't do RTCP, you MUST do this with the signalling".
      After much discussion, the consensus seemed to be to make inclusion
      of the RTCP address/port optional, but mandate that implementations
      MUST include a "b=" field of zero if RTCP is not used.

    - Rewrote the security and IANA considerations, and made a number of
      editorial fixes.

   There are a number of open issues relating to mid-session checks, use
   of STUN vs. STUN-over-RTP, forcing symmetry, and local-to-derived
   mapping.

   Mid-session STUN checks serve the purpose of keeping alive NAT bindings,
   detecting interface and NAT failures, and probing for bandwidth. If they
   are included, we need to specify frequency of transmission, a definition 
   of failure and protection against flapping. There are two choices for a
   mid-session keepalive: STUN based and application based. STUN based mid-
   session checks have the advantage of being codec/transport independent, 
   but require applications to demultiplex STUN and media data, make it hard 
   to specify timers and only provide a partial failure detection/recovery 
   solution. Application based mid-session checks provide a clean handoff
   between STUN and the media, separating problems and limiting the scope
   of ICE, and move timers and failure detection to the application.

   Jonathan proposed to keep with the solution in the current, with STUN
   being used for the initial keepalive check, and application specific
   solutions being used after the initial check. He noted that his slide 
   saying "Recommentation: keep stun keepalives" is wrong. Joerg Ott and
   Dave Oran agreed with Jonathan.

   The next open issue was the use of STUN vs. STUN-over-RTP for initial 
   connectivity checks (i.e. the 1st RTP packet's payload data is a STUN
   packet). The disadvantages of using STUN over RTP are that it's ugly,
   the request/response nature of STUN isn't well matched with RTP
   semantics, the RTP timestamp would jump since the STUN packets aren't
   really media, it doesn't work with SRTP, and it makes ICE specific to
   RTP. The only advantage is that is avoids a STUN/RTP demultiplex --
   although that comes at the cost of embedding STUN into RTP. Dave Oran
   agreed with all these, provided this is done for RTCP. For RTCP, the
   issues are not as bad since RTCP APP packets can be used. Magnus
   Westerlund noted that there are other protocols and making ICE RTP
   specific is a mistake. The consensus of the room was that STUN-over-RTP
   is a mistake, especially since we now have a clean handoff between STUN
   and the media.

   Regarding forced symmetry, the problem is that the current algorithm can
   result in you sending on a different port than that on which you receive
   media. This doesn't work if one is depending on application-level keep
   alives. The suggested fix is MUST send on the port on which you last
   received a valid RTP packet. Magnus Westerlund noted that there's a
   potential for flapping, but Jonathan countered that the protocol will
   settle to a stable state, and there are further rules to ensure one
   SHOULD use the highest priority address on which you got a STUN request. 

   Regarding local to derived mapping, previous versions of the draft
   allowed a single socket to be used for it's local address, and as a
   source of STUN and TURN requests used to determine derived addresses.
   This caused confusion with username-to-address mapping for the STUN and
   TURN requests, made it hard to determine when to stop the STUN server,
   and made it difficult to assess which address was used. The latest
   version of the draft uses distinct ports for the local address, and to
   run STUN and TURN to derive addresses. This avoids all the multiplexing
   issues, but at the expense of additional local port usage. Jonathan is
   worried about the port footprint, and is considering going back to the
   multiplexing solution (one local address for each derived address), and 
   defining appropriate timeouts for each protocol. Rohan Mahy noted that 
   the folks that have port issues will likely be those who have problem
   multiplexing, so this may not solve the problem. Dan Wing suggested that
   the problem is that we're lacking a message to say "STUN packet received"
   so why not create a stun message to say exactly that? Jonathan considered
   that, but thought that while it helps you turn off the STUN listener, it
   doesn't solve the demultiplexing issues. Cullen Jennings asked why we
   can't do both? The choice of one-to-one or many-to-one mappings between
   local and derived addresses is a local implementation choice, and which
   doesn't affect remote clients. Why not document the issue, and let the
   implementor choose? Jonathan agreed that this is a good way forward.

   Magnus Westerlund noted that ICE could generate a lot of packets, and
   may cause congestion. It may be better to have some initial delay and to
   send messages in priority order. Jonathan agreed that this could reduce
   the amount of data sent, but increased the post-dial delay (which is a
   hard requirment for some applications). Joerg Ott noted that it's
   unlikely there are many addresses, so this may not be such a problem:
   maybe just add a warning note? Jonathan agreed that a discussion of the
   issue would be appropriate.

   Magnus also worried about switching media between different addresses;
   we should highlight the potential congestion control issue when changing 
   connection addresses.

   Jonathan committed to revising draft immediately after the meeting, to
   aim for working group last call before Christmas.

Internet Media Guides

   Yuji Nomura discussed Internet Media Guides. The IMG requirements and
   framework are with the IESG for review, so it is now time to identify
   the specific protocol components that need to be developed. The main
   items are an IMG transfer envelope, a multicast delivery method, and a
   subscribe/notify delivery method.

   The groundwork for the unicast subscribe/notify mechanism is defined
   in draft-nomura-mmusic-img-notify-00.txt. Yuji noted that using HTTP 
   doesn't meet the requirements, so the working assumption is that SIP
   events will be used for subscribe/notify, and there is a need to define
   an event package for IMG. Multicast delivery will be via FLUTE: an
   intial draft defining this has previously been submitted, and will
   be updated shortly.

   In addition to the transport protocols, and envelope is needed for the
   data. An initial proposal (draft-walsh-mmusic-img-envelope-01.txt)
   exists for this and provide a common minimal set of information to
   manage transfer of IMG data, independent of the transport protocol.
   The working assumption here is to use an XML format.

   Open issues include the need to define an IMG URI (e.g. img://...)
   and naming IMG data for encapsulation ("application/envelope+xml"?).
   It will also be necessary to define versioning and delta descriptions
   for the IMG data, to support partial transmission.

   Henning Schulzrinne asked if the IMG URI is intended to identify the
   content or the transport, and wondered how it should be used? There
   was some confusion on this point, and it isn't clear how to translate
   from the URI to the retrieval mechanism. Clarifiation is needed.

Application Sharing

   Henning Schulzrinne discussed draft-schulzrinne-mmusic-sharing-00.txt on
   requirements for application sharing. This is speculative new work, and
   it's not clear if it belongs in MMUSIC. Our conferencing architecture is 
   deficient in support for shared applications, and Henning has considered
   how this can be resolved without reinventing T.120. The presentation and 
   draft outline the problem space and the requirements. 

   Rohan Mahy expressed concern that the scope being addressed here is
   significantly larger than he had imagined. We may want to solve the
   problem for named categories of application, splitting the problem space
   rather than "trying to boil the ocean". Dave Oran, Jonathan Rosenberg
   and Roni Even and also expressed similar concern regarding the scope of
   the work, compatibility with other systems, the form of the data to be
   shared, etc. Henning noted that he's raising possible requirements, not
   suggesting that we'll solve them all immediately. Steve Casner noted
   that we already have limited RTP payload formats for pointers and text
   events, which may feed into this work. 

   Joerg Ott concluded by noted that this is an intersting problem, and
   noted that while the negotiation of application sharing sessions is
   clearly in scope for MMUSIC, the application sharing protocol itself 
   isn't. There doesn't seem to be a natural home for this work in the 
   IETF, although we can think about it here for now.

SDP

   Colin Perkins outlined the changes to draft-ietf-mmusic-sdp-new-21.txt
   since the last meeting (see slides for details). There are open issues
   regarding support for internationalized DNS, layered coding, direction
   attributes and the placement of the spec in context.
   
   Internationalized DNS names did not exist when the original SDP was
   written, so the draft doesn't indicate how they should be represented.
   Advice was solicited from the working group and Bernie Hoeneisen gave
   the suggestion that internationalized DNS names should be conveyed in 
   the ASCII Compatible Encoding (ACE) form defined in RFC 3490, rather
   than in UTF-8 or some other encoding. This requires no changes to SDP,
   other than to note that this form should be used.

   Regarding layered coding, the issues are that allocation of consecutive
   multicast addresses is problematic, and that the "a=rtcp:" attribute is 
   not fully specified for layered encoding. Colin suggested that, since
   this part of the spec is not widely implemented, it should be left as-is
   for now, and updated if layered multicast transport becomes popular. No
   comments were received.

   There was a suggestion that interactions between the direction attributes 
   ("a=recvonly", etc.) and the offer/answer spec should be documented, and
   offer/answer referenced. More generally, is there need to include more
   context on how SDP is used with, for example, SIP? Jonathan Rosenberg
   and Keith Drage suggested that these interactions are defined in other 
   drafts, so there's no need to add anything to the SDP spec. 

SDP Extension for Media Loopback

   Kaynam Hedayat discussed draft-hedayat-media-loopback-01.txt. The goal
   of this draft is to enable SIP endpoint to initiate calls with media
   loopback. It introduces two SDP media attributes, giving the type and
   mode of the loopback and is based on the offer/answer model.

   Colin Perkins and Dave Oran were uncomfortable with the requirement that
   endpoints MUST support RTCP-XR, and suggested that support for RTCP-XR
   be OPTIONAL. The loopback attribute is more general than voice over IP
   applications, so there is no way a particular subset of RTCP-XR support 
   can be mandated. 

   Magnus Westerlund expressed concern that the security aspects of this
   new attribute haven't been fully considered, and that it may introduce
   potential packet bombing attacks. This issue needs to be documented.

   The consensus of the room was that this a good idea, and should be
   adopted as an MMUSIC work item.

SDP Extension for BFCP

   Gonzalo Camarillo presented (draft-camarillo-mmusic-sdp-bfcp-00.txt)
   on the SDP extensions needed to support the XCON binary floor control
   protocol. BFCP is defined under the "application/bfcp" media type and
   runs over TCP. It fits into SDP as a transport protocol with connection
   establishment is handled by the comedia framework. The "k=" line can be
   used to convey the shared secret needed by BFCP, and attributes are
   defined to convey the confid and userid. Mapping between floor IDs and
   streams can be done using the SDP label attribute. There is an open
   issue regarding the need for a nonce attribute, which will be discussed
   in XCON.

   The consensus of the room was to accept this as an MMUSIC work item.

SDP Label Attribute

   Gonzalo Camarillo presented (draft-ietf-mmusic-sdp-media-label-00.txt)
   on the SDP label attribute. The main issue at the last meeting was why
   label media streams, rather than referring to the n'th media stream. It
   has been clarified that this is so static documents can be created that
   refer to specific media streams within future SDP files, without having
   to revise those static documents if the type or order of the media in
   those future sessions changes. 

   The authors asked for the draft to go to working group last call. Colin
   Perkins raised an issue that the label is defined as "any octet string"
   but needs to be restricted to octet strings that can be represented in
   SDP (i.e. printable ASCII). The working group last call will be issued
   after the meeting, with this comment being fixed as an editorial
   clarification after the last call.

SDP Connection Establishment Precondition

   Gonzalo Camarillo presented (draft-ietf-mmusic-connection-precon-00.txt)
   on SDP connection establishment preconditions, briefly noting that the
   SIP working group is performing an expert review of the draft. 

SDP Security Precondition

   Flemming Andreasen gave an overview of the SDP security precondition
   draft (draft-andreasen-mmusic-securityprecondition-02.txt). The problem
   that it solves is when an offer includes several security descriptions
   from which the answerer picks one and sends secure media. The media can
   start to arrive before the answer, but cannot be be decoded since the
   offerer doesn't know which security parameters were chosen. Hence a new
   precondition is defined to delay completion of the call until all
   parties have agred on the security parameters. 

   Changes in this version are to clarify the definition of "send" and
   "recv" security preconditions, add more detail in the example flow, and
   add security considerations. This is needed by SIP, and there are no
   known open issues.

   Colin Perkins asked that an example be included using the kgmnt-ext form
   of SDP signalling, in addition to the sdescriptions examples, but
   otherwise agreed that the draft was in good shape. The authors were
   requested to make this change, and submit the draft as a working group
   draft, then a working group last call could start.

SDP Connectivity Precondition

   Flemming Andreasen also presented the SDP connectivity preconditions
   (draft-andreasen-mmusic-connectivityprecondition-01.txt). This draft
   defines a precondition to ensure there is media stream connectivity
   between offerer and answerer prior to proceeding with session
   establishement. It doesn't mandate a particular mechanism to verify
   connectivity.

   Changes in this version are to clarify the definition of "send" and
   "recv" preconditions, add more detail in the example flow, and add 
   security considerations. Open issues include adding an explanation
   of the relationship between this and ICE, and explaining how it will
   interact with SIP forking.

   Colin Perkins asked that this draft be clearer on the difference between
   it and the connection precondition, in particular to be careful about
   the precondition names (i.e. "con" vs. "conn"). Paul Kyzivat noted that
   we have many preconditions, and worried about use cases and feature
   interaction. It may be appropriate to consider documenting possible
   interactions? Henning Schulzrinne raised a general concern that the
   precondition framework may be covered by IPR?

   It was agreed that this draft should become an MMUSIC work item.

				  -- + --

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