[MMUSIC] Draft MMUSIC minutes from Atlanta

Multiparty Multimedia Session Control Working Group Minutes

Reported by Colin Perkins

   The MMUSIC working group met once at the 55th IETF meeting in Atlanta.
   We discussed SDP key management and media security descriptions, media
   format independent SDP parameters, SDP bandwidth modifiers, examples of
   the offer/answer model, Internet Media Guides, XML schema for video
   control and the revised RTSP specification.

Agenda Bashing and Status update

   The meeting started with an introduction and status report by Joerg Ott.
   The SIMCAP draft has been published as RFC 3407, and the FID draft is in 
   the RFC Editor's queue. The comedia, sdp4nat and SDPnew drafts are still
   with the IESG. The draft on reservation flows is completing its working
   group last call, and will be submitted to the IESG for publication as a
   proposed standard immediately after the meeting.

   There have been minor changes to the SDP spec, to address comments from
   the list. We are waiting for feedback from our area director before we
   can progress this further. There has been no recent update to the SDPng
   draft, but the authors are working on a new version that will have some
   internal reorganization, will focus on the offer/answer model, and will
   leave multiparty content-independent negotiation for a future extension
   document. 

   The SDPng Transition draft (draft-ietf-mmusic-sdpng-trans-02.txt) has
   been revised, and is largely complete. Feedback is solicited, we plan 
   to issue a working group last call shortly.

   The SDP Source Filter draft (draft-ietf-mmusic-sdp-srcfilter-02.txt)
   seems to be complete. Joerg asked if a working group last call would
   be appropriate? There were no objections, and a last call will be
   issued shortly. 

   The comedia draft is, in principle, complete but concerns have been
   raised about applicability in the presence of middle-boxes. Joerg Ott
   outlined his understanding of the issues. Jonathan Rosenberg disagreed
   with Joerg's formulation: rather the issue is that there'a a strong
   coupling between session lifetime and connection lifetime, and problems
   reusing connections. This causes too much load and bad congestion state.
   Jonathan suggested updating the comedia spec to address these concerns.
   Allison Mankin asked if this needs just a relatively small change rather
   than an elaborate extension? Jonathan expected the changes to be small.
   Joerg Ott noted that we need to understand the muxing and binding
   mechanisms. Jonathan agreed, since right now there are problems due to
   NAT, firewalls, etc. Jonathan said he would produce a concrete proposal
   on what needs to be changed in comedia "within a month", else we will go
   ahead with the existing specification.

   Joerg noted that the working group charter is out of date. The chairs
   will work on updated milestones and charter, to be circulated to the
   list for comments. Suggested new work items may include Internet Media
   Guides and Floor Control, but these need to be discussed with the area
   directors before any decision is taken.

MIKEY/Key Management with SDP

   Allison Mankin (Transport Area director) and Eric Rescorla (security
   advisor for the transport area) outlined their concerns with the key
   management model for SDP and the MIKEY draft. Eric's concern is the
   binding between MIKEY and SDP, which allows multiple key management
   protocols, such as IKE, S/MIME, etc. There is no protection against
   downgrade attacks during the protocol negotiation. 

   Elisabetta Carrara noted that there is a recommendation in the draft to
   choose between appropriate crypto-suites, but this did not satisfy Eric.
   Jonathan Rosenberg said that his understanding is that using MIKEY with 
   SDP is not sufficient, the SDP will be protected with S/MIME anyway and
   hence S/MIME provides the protection against downgrade attacks. Eric
   asked why, if you have S/MIME already, do you need MIKEY? Elisabetta
   noted that we don't commit to S/MIME, but Eric countered that, to have
   reasonable security, S/MIME or similar protection is needed in addition
   to MIKEY. Discussion continued for a while with no real resolution.
   Allison Mankin committed provide a written review of the draft, with
   detailed comments for discussion on the list.

SDP Security Descriptions for Media Streams

   Mark Baugher outlined the new draft on SDP Security Descriptions for
   Media Streams (draft-baugher-mmusic-sdpmediasec-00.txt). This is an
   alternative means of exchanging keying material, to be used when the
   SDP message is securely delivered. Accordingly it is expected to be
   complementary to key management with MIKEY. 

   Mark outlined the limitations of the existing "k=" line, described the
   proposed "a=crypto:" attribute, and outlined use with the offer/answer
   model. Jonathan Rosenberg asked unclear why you'd want to do separate
   security properties on a codec by codec basis since this seems to be the
   cause of a lot of complexity? 

   Mark asked if this could become an MMUSIC work item. The chairs agreed
   that the work is a good thing to do, but need to figure out the correct
   home for it. 

SDP attribute for qualifying Media Formats with Generic Parameters

   Flemming Andreasen presented draft-rajeshkumar-mmusic-gpmd-01.txt, the
   format independent parameter that can apply to existing MIME types. He
   outlined the background to the draft, signalling voice-band data, and
   noted issues with the current draft: it is very open-ended and needs 
   to be more limited in scope; it needs to specify interactions with the
   offer/answer model; and it needs a procedure for registration of new
   gpmd parameters. 

   Jonathan Rosenberg recommend that parameter specifications suggest the
   actual interaction with offer/anser. He also suggested that we require
   new parameters to be standards track.

A Transport Independent Bandwidth Modifier for SDP

   Magnus Westerlund outlined draft-westerlund-mmusic-sdp-bwparam-01.txt,
   on a new set of SDP bandwidth modifiers that signal session bandwidth in
   a transport independent manner. These are intended to solve problems due
   to NATs and protocol translation, that make the existing parameters less
   than useful.

   Steve Casner noted that biggest open issue is whether we really need to
   make the change at all? Magnus noted that the bandwidth can increase by
   25% with IPv6, compared with the value currently signalled, a compelling 
   argument for the new parameters. Steve disagreed, noting that the RTCP
   bandwidth doesn't have to be that accurate, and that this level of
   inaccuracy is unlikely to be problematic. He also said that a stronger
   point is bandwidth allocaton for links, where it seems likely that for
   tightly controlled channels, header compression will be used, so the
   difference between v6 and v4 goes away. 

SDP Offer Answer Examples

   Alan Johnston outlined draft-johnston-mmusic-offer-answer-examples-00.txt, 
   giving a series of examples and scenarios for the use of offer/answer.
   The group expressed interest. Joerg Ott asked that the draft be expanded
   to give some pointers to why the examples are correct.

A Framework for Internet Program Guides

   Yuji Nomura discussed draft-nomura-mmusic-pguide-framework-00.txt, a new
   framework for Internet Program Guides that has evolved out of the drafts
   that were discussed in Yokohama. There are a number of open issues: can
   this become a charter item of MMUSIC? Revision of requirements? Choice
   of protocol for announcements? Appropriate description format? 

   There was much discussion of the naming of the work, with many people
   disliking the term "Internet Program Guide". It was decided to call the
   work "Internet Media Guides" from now on.

   Joerg Ott noted that many description formats could be used, and that we
   would not want to restrict ourselves to a single format. Similarly, we
   would not want to define a new format within MMUSIC, but instead use the
   existing solutions.  

   Henning Schulzrinne asked that we take a step back to see what we learnt
   from SAP. Other things have happened in the space of event notification,
   and SAP hasn't been a clear success because of the service model, etc.
   We want to revisit, and see what we've learnt.

   The chairs noted that this work is not within the MMUSIC charter. They
   will work with the area director, to determine if MMUSIC is appropriate
   for this work, or if it should occur elsewhere.

XML Schema for Media Control

   Orit Levin outlined draft-levin-mmusic-xml-media-control-00.txt, an XML
   schema for media control. Orit noted that several alternative approaches
   have been discussed previously (CODEC specific RTP/RTCP primitives, RTCP
   feedback as for loss recovery, SDP extensions) but rejected for various
   reasons. They therefore propose the use of an XML scheme conveyed using
   a reliable protocol. The primitive commands are "picture fast update",
   "GOB fast update", "MB fast update" and a "picture freeze" command. This
   is encapsulated in the SIP INFO method, and next steps are to define the
   encapsulation.

   Steve Casner noted that he is sure an XML schema can be defined for this
   purpose. A more critical question might be how it is transported, and if
   the result will work. Rohan Mahey noted "if I could go back in time and
   undo INFO, so it didn't exist, I'd be very happy". He noted the issue is
   that this is media oriented, and should be sent with the media. Asked if
   some form of RTCP based approach might be more appropriate?

   Henning Schulzrinne expressed concern about re-inventing SOAP on the
   sly. Besides asking whether this belongs in SIP or not, we don't need
   yet another RPC protocol. If it is an RPC mechanism we should ask how
   we can make exisitng RPC solutions work in this context? He also asked
   if there is a need for a traditionally reliable mechanism, and how it 
   relates to other work on, for example, floor control?

   Nermeen Ishmail noted that there is a real problem of using SIP, since
   if you lose the control path, you lose the media. This leads towards
   using RTCP, but there is an interoperability problem with that since
   H.323 systems convey this information in the control path. Accordingly,
   we should steer away from RTCP, and use a media control protocol. There
   was concern that this would not work either, due to the latency of the
   control channel.

   Jonathan Rosenberg noted that this might be a perfect candidate for a
   SOAP protocol, signalled in SDP? Henning agreed that SOAP works today, 
   but there is a need for a way of associating SOAP connections with a
   media stream, in SDP. Orit asked where should we do SOAP work, since
   it is unclear if MMUSIC is the appropriate forum? The answer seems to
   depend on the form of the final solution.

RTSP Update

   Magnus Westerlund outlined recent changes to the revised RTSP draft
   (draft-ietf-mmusic-rfc2236bis-02.txt) and gave a pointer to the bug
   tracker at http://rtspspec.sourceforge.net/. He asked for the group 
   to review the updated specification, and noted that teleconferences
   to discuss changes will resume shortly. He also outlined major open
   issues.

   This first open issue is redirect: shall the server be allowed to
   close a session as soon as the clients ACKs the REDIRECT? And what
   should be done with the 3xx codes? 

   Magnus noted that the authors are lacking experience with RECORD. It
   seems that the spec needs significant clarifixation on how to use it,
   and that there are many open issues. Input was requested from someone
   who has implemented RECORD, otherwise the authors proposed to remove it
   from the base specification (leaving it as an extension document). Steve
   Casner said he was pretty sure that IP/TV used RECORD, and that this may
   provide implementation experience? Rob Lanphier explained that we need
   people to document what they're doing with RECORD, not just to list
   implementations. Henning Schulzrinne asked if the issues with RECORD
   might be somewhat similar to WEBDAV style protocols, and if experience
   in that field may be helpful? 

   Other open issues exist with Appendix C, the Accept-Ranges header, the
   Via header, Negative Scale, TLS support, RTSP over UDP, etc. A bar BOF
   was scheduled for later in the week to discuss these, and discussion
   will continue via the mailing list and teleconferences.

				   - * -

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic