--- ============================================================
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- DRAFT Minutes for IETF#75 MMUSIC WG Meeting
--- Thursday, July 30, 2009 - 9:00 to 11:30am
--- ============================================================

CHAIRS:  Joerg Ott <jo@acm.org>
         Jean-Francois Mule <jf.mule@cablelabs.com>

    The MMUSIC WG met on July 30 at IETF#73. The session was attended
    by 57 participants. The meeting was chaired by Joerg Ott and
    Jean-Francois Mule and the minutes are reported by Jean-Francois.

1/ Introduction and progress report
   Joerg and Jean-Francois presented the progress since the last
        - 3 RFCs were published since March 2009:
          RFC 5547, RFC 5576 and RFC5583
        - ICE is still in the RFC Editor queue and publication has
          been requested for connectivity preconditions and RFC
        - The capability negotiation draft received comments from IESG
          and needs revision.
        - The media path guidelines for middleboxes WGLC is complete
          and the ID needs an update
        - 3 I-Ds are in the queue for WGLC request (RFC4756bis, sdp
          media cap and image attributes after an udpate)
        - ICE TCP has not been updated and Simon Perreault who is the
          new editor plans to issue a revision after IETF.
        - Hadriel Kaplan volunteered to work with the authors of the
          media loopback ID to complete it and go to publication
          request by October 2009.
   See slides for more details. There were no comments or questions
   from the Working Group on the progress report.

1) RTSP-related Drafts

1.1. RTSP 2.0

   Magnus Westerlund presented an update on the latest RTSP draft. See
   slides for details on the changes.  Two versions of the
   Internet-Draft were posted between IETF 74 and IETF 75.  The one
   open issue is to update the "changes since RFC 2326" section.
   The authors believe the document is in good shape for working group
   last call. There were no comments on the plan to launch WGLC in
   September for 4 weeks.
   The following people volunteered to be reviewers during WGLC:
   Ingemar Johansson, Jeff Goldberg, and Ye-Kui Wang (thank you).


   Magnus Westerlund presented the draft updates on RTSP NAT.  The
   document received feedback from implementers.
   There was consensus to go to WGLC after RTSP/2.0.

1.3 Fast Content Switching with RTSP 2.0

   Thorsten Lohmar presented RTSP extensions to support Fast Content
   Switching.  There are existing extensions defined in 3GPP for RTSP
   1.0 and the goal of this work would be to define extensions in IETF
   for RTSP 2.0.

   Joerg Ott asked how RTSP session parameters could be reused across
   streams in the context of multicast.  Thorsten answered that the
   scope of the current ID is unicast and with unicast, channel change
   is faster if you use these RTSP extensions.

   On slide 7, Joerg commented that the proposed solution presented in
   the examples looks "unhealthy" because various feature parameters
   including SDP are put into one header line (it seems like the
   DESCRIBE message is encapsulated in PLAY).
   Thorsten indicated that this point was discussed in the past and
   given the number of SDP descriptions for video services like
   YouTube, the current direction is to not do DESCRIBEs to reduce the
   number of transactions.

   Jean-Francois noted that the examples show the 3gpp tags and
   their particular syntax. It would be benefitial to discuss the
   parameters required for fast channel switching first, then figure
   out how to convey them in the protocol.

   In the jabber room, Martin Stiemerling asked if the proposal is
   aligned with the RTSP/2.0 state machine where you can use PLAY
   on new URIs without SETUP first.

   Based on questions from Wolgang Beck (via jabber), there was a
   discussion on whether this work is required given the client has to
   wait for an I-frame for the new content channel.
   Brian Rosen responded that there is work in AVT in reducing the
   delay related to the I-frame and there is enough experience in 3GPP
   that this mechanism actually helps.

   Ye-Kui Wang indicated the issues related to the I-frame may be
   different than what is being addressed in AVT since the action is
   done by the server (the server may know where the I-frame is before
   starting channel change).

   Joerg pointed out that there is an assumption in the mechanism that
   the new SDP offer is going to be compatible (no DESCRIBE fetching).
   It implies that the client makes some assumptions.
   Thorsten agreed this is an open issue, even though the server
   could know what the client can support.
   Joerg added that if the server has multiple codec options, a SETUP
   might help for the client to choose from.

   Jeff Goldberg asked how this mechanism works with the RTSP NAT
   draft given the exchanges.  We need to consider how the two
   mechanisms could work together.  Thorsten indicated that there
   should be little impact but further analysis is indeed required.

   In summary, based on the discussions at this IETF#75 meeting, there
   is WG interest in progressing this work on the mailing list and see
   the Internet-Draft updated to address the feedback.

1.4 SIP-SDP Overlap with RTSP

   Jan Lindquist presented a draft on how the session related
   information could flow between SIP and RTSP session controllers.
   Jan indicated that ETSI TISPAN, 3GPP and the Open IPTV Forum are
   working on this topic.
   Hadriel Kaplan asked what "session management protocol" refered to
   in the slides and whether it could be somethink like SIP without
   media description.
   Hadriel asked whether this work proposal should potentially go to
   DISPATCH given it goes beyond MMUSIC. Hadriel expressed support
   for this work.

   Tom Hiller expressed some concerns about the claim that OMA is
   working on this topic. Tom said that this was discussed in OMA and
   rejected.  Tom indicated that RTSP should be left intact given the
   client implementations.
   Joerg suggested that Tom puts an email to the mmusic list to
   explain what OMA did to solve the requirements.

   Xavier Marjou expressed support for this work.  There are people
   that use both SIP and RTSP and there is no work in IETF to make the
   2 protocols work together.  It would be good to take on this

   The chairs polled the room for interest in this work (13 peple
   interested, 5 opposed to do work on this).

   Dave Oran added 3 options that could get support in MMUSIC:
        a) stop RTSP 2.0 and step back to redefine it to meet the goals
           defined here
        b) designing new media control protocol inside a SIP session
           (put the PLAY controls in SIP)
        c) create an MRCP sub-set
   All of these would allow to use SIP to do media streaming server
   operations. Jan indicated this is good input.

   Gonzalo Camarillo agrees with Hadriel that this might be best
   discussed in the DISPATCH working group.

   The chairs concluded that more discussion is needed on this topic.


2) SDP Attributes

2.1 SDP Connectivity Capability (CCAP)

   Hadriel presented an Internet-Draft to solve some IPv4-IPv6
   interworking issues.

   There were questions and comments about the characterization of the
   problem (slide 2).
   Cullen Jennings and Francois Audet commented that there is an
   implication that there are a lot of things broken, and the problem
   statement is exagerated.
   Cullen Jennings, it was pointed out that the WG decision to fix
   IPv4-IPv6 connectivity declarations in SDP was the ICE protocol.

   Xavier Marjou would like to do IPv6 in the very short-term with
   this draft, and perhaps this is an informational or experimental
   document, not standard-track.

   There were several questions and comments on the subsequent slides:
        - the c line in O/A does not need to have the same address
          family (Roni Even)
        - you have to do a re-INVITE since the answer should have the
          same c line (Dan Wing)
        - Capabiliy negotiation is "messy" and having two mechanisms
          would be even worse - the garcia draft to negotiate c lines
          is a potential solution (Christer Holmber).
          The garcia draft has been proposed as a WG item based on
          IETF#74 (Roni).
        - This is a special case of capability negotiation (Roni Even)
          but capneg is too complicated (Hadriel Kaplan)
        - This problem could be addressed based upon the garcia draft
        - We always start out simple and it gets complex. We will need
          to implement all of this in the end process: we did discuss
          and agreed on a solution (Francois Audet)
        - The motivation is to do a "super-ice-lite mechanisms" -
          ICE-like negotiation without the connectivity checks.
        - This is a strategic direction we make for the wg (Gonzalo)
        - We should spend energy on solving generic SDP capability
          negotiation (Ingemar)
   There were additional comments from Roni, Jonathan Lennox, Derek,
   John Elwell and Christer Holmberg.

   In summary, the discussions asked:
        - how difficult would the solution be if it were to rely or
          build on capneg and draft-garcia?
        - how different is it from a solution re-using ICE?

   There was no consensus on this draft but many questions and
   comments recommending to re-use the tools that are available in
   MMUSIC including SDP Cap Neg and its extensions like the garcia
   draft for the c= line, ICE and new semantics to make this work.

2.2 SDP Attribute for Maximum Media Sources

   Jonathan Lennox presented a new draft on max media source count.
   Based on a comment from Dave Oran, the upper bound limit for
   maxbound should be 2^32-1 (unlimited).

   Christer asked how does the user know whether the media comes from
   different or a single source.  Jonathan clarified that the use only
   cares whether media comes from a different SSRC: there are
   different buffers for playing media so the question is whether the
   endpoint supports more than one simulatenously.  It has nothing to
   do with forking.
   Gunnar Hellstrom sees good use of this mechanisms; he submitted a
   draft on text conferencing indicating that it can use multiple

   Hadriel added a few comments on SSRCs and their handling by SBCs.

   The take-away from the WG discussions is that the ID should progress
   and it should integrate more information about SSRC handling.

2.3 Media Source Selection in SDP

   Jonathan Lennox introduced his draft allowing media source
   selection in SDP.  There is potential IPR on this draft, check the
   IPR disclosure.

   Based on a discussion with Jonathan, Alan Johnston, and Roni Even,
   there was consensus that this work should continue in MMUSIC and
   also be presented and discussed in XCON given the related SIP/XCON
   conference package.
   There was a question about how to associate a media stream with a
   certain SIP dialog when forking for example.  Jonathan answered
   that RFC 5576 should be sufficient on its own for that.

   The chairs asked how many people are interested in this work by a
   show of hands: 7 people.
2.4 SDP Extensions for audio over PSTN CS bearers

   Simo Veikkolainen presented an update on the above ID to integrate
   comments from John Elwell.

   The chairs asked for reviewers to send comments to the list.
   Cullen Jennings commented that this revision looks good.
   Given the meeting time constraints, Peter Fassberg had a few
   comments that should be discussed after the meeting and sent to the
   list as needed.

2.5 Misc Capability Negotiation in SDP         (Simo Veikkolainen, 10)

   Simo Veikkolainen indicated there were no technical changes in this

   Hadriel Kaplan asked about the motivations of bundling the bundle
   i= and b= parameters.  This should be clarified on the mailing
   list.  Simo indicated that the goal was to be exhaustive on other
   SDP attributes.

   Hadriel Kaplan and Mohamed Boucadair raised questions about why
   comments expressed on the ccap draft presented earlier in the
   session do not apply to this draft.
   Jean-Francois clarified the motivations for this draft (ability to
   have capability negotiation for the c line), and that this has been
   discussed on the list and in previous meetings.
   More discussion should continue on the list re: ccap and how the
   requirements or solution relate to this Internet-Draft.

The meeting concluded.