Subject: [MMUSIC] wg meeting minutes from IETF 71

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 14 Apr 2008 04:01:54 -0600

The minutes from the MMUSIC WG meeting at IETF#71 are below.
   They are also posted at:
   http://www.ietf.org/proceedings/08mar/minutes/mmusic.html

Your comments are welcome by April 21.

Joerg and Jean-Francois.

---
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- IETF#71 Meeting Minutes
--- Monday, March 10 2008 from 9:00-11:30
--- ============================================================

   The MMUSIC WG met once at IETF#71.  The meeting was chaired by
   Joerg Ott and Jean-Francois Mule.  The session was attended by
   about 140 participants.

Minutes reported by Jean-Francois Mule
based on notes from Christian Schmidt and Jean-Francois Mule

1/ Introduction and progress report
  
   After the note well reminder on Intellectual Property, the chairs
   presented the agenda and a brief working group.

        - RFCs Published: none since Vancouver

        - RFC Editor Queue:
          draft-ietf-mmusic-ice-19 (dependencies on other drafts)

        - Close to Publication:
          draft-levin-mmusic-xml-media-control-13

        - Awaiting Write-up and/or Publication Request:
          draft-ietf-mmusic-sdp-capability-negotiation-08
          draft-ietf-mmusic-qos-identification-01
          draft-ietf-mmusic-sdp-source-attributes-01
           (Jonathan Lennox noted the slides omitted
            draft-ietf-mmusic-sdp-source-attributes-01 which had just
            completed WGLC)
 
        - Ready for WGLC:
          draft-ietf-mmusic-connectivity-precon-04.txt
          draft-ietf-mmusic-decoding-dependency-01.txt

        - Needs Update
          draft-ietf-mmusic-file-transfer-mech-06.txt
          draft-ietf-mmusic-media-loopback-07.txt
           (it was noted that the media loopback draft has still not
            been updated based on the feedback received in IETF#70,
            see details in the minutes).

        - Other Drafts
          draft-ietf-mmusic-rfc4566bis-00.txt
            (IPv6 fix in ABNF)
          draft-ietf-sip-dtls-srtp-framework-00.txt
            (noted for the SDP attributes now defined in this draft)

   The chairs noted the liaison statements sent by the MMUSIC
   working group on RTSP 2.0, see slides for details.

   Finally, the idea of conducting some ICE interoperability testing
   at SIPit22 was proposed.  The objectives are to do ICE/STUN/TURN
   and potentially SIP outboud testing to collect feedback from the
   implementers.

2/ ICE TCP
   draft-ietf-mmusic-ice-tcp-06.txt

   Jonathan Rosenberg presented the main changes and open issues on
   ICE TCP.  See draft and slides for the main changes since draft-05.

   The "big problems" with the current draft were then discussed.
   The main issue is that the recommended mechanisms in ICE-TCP work
   for about 45% of the cases for double NAT scenarios.  This is based
   on the use of simultaneous opens and on the findings recorded in a
   paper from SaiKat (http://saikat.guha.cc/pub/imc05-tcpnat.pdf).
   The other problem is that the mechanism may have issues with
   Windows XP (some have concerns that SO support does work in XP).

   Different approaches for improvement were then discussed:
   a) Port prediction:
      The idea would be to add some text in the document to take into
      account the fact that, if you open one connection and then a
      second one, you normally get port+1.
      Comments at the mike from Magnus Westerlund and Francois Audet,
      and additional points made by Jonathan, the consensus was to not
      add port prediction as part of the ICE-TCP solution but create
      an informative document separate from ICE-tcp and potentially
      release the document with ICE-TCP.
      Later on in the meeting, Cullen Jennings brought up the scenario
      of running AJAX applications while initiating ICE and based on
      his testing, he was not sure port prediction would even work due
      to the many TCP connections.
      
   b) Support for TCP Simultaneous Open in Operating Systems
      Jonathan called for volunteers to run some tests on OSes to
      check S-O support and verify draft mechanisms.

   c) TCP over UDP:
      Jonathan proposed to use a radical approach in ICE-TCP: run
      ICE-TCP over UDP. The success rate for a UDP connection is good
      with ICE. With TCP over UDP, you get the best of both worlds,
      e.g. congestion control.
      Discussions followed with comments at the mike from several
      folks (Remi D-C, Philip Matthews, Dave Oran, Cullen Jennings,
      Adam Roach, Ekr, Rohan and others):
        - some raised questions and doubts about what this proposal
          was (is it TCP over IP over UDP, or TCP over UDP - Dave Oran)
        - Philip Matthews indicated that behave-tcp does recommend how
          to fix this in NATs and wondered if the solution was in fact
          dependent on how NAT vendors do comply with those
          guidelines.  Cullen indicated that the problem is the
          deployment of current NATs.  Jonathan stated this was a
          multi-year problem.
        - this solution would likely be used for p2pSIP and 3GPP
        - real data on how this works on NATs would be great
        - Adam Roach warned about trends and not describing things
          that work today but won't work anymore when the document
          goes RFC.
        - how would implementers do this (Ekr)?
        - there are mechanisms for UDP encapsulation of other
          protocols [e.g. IPsec] and there might be interest in TSVG
          to define a more generic solution (Magnus W)
        - this idea could be part of the solution, this is what the
          HIP wg and some drafts in p2psip have been looking at.
     More data is required and there was no consensus.
    
     Cullen Jennings <AD hat on> concluded that MMUSIC is not the
     right working group; the transport area and TSVWG is where
     discussions should happen.
    
     The rest of the comments were centered around what to do with the
     document based on the "big" problems.  Based on comments, folks
     expressed interest in 3 options:
        - Continue with S-O as currently defined.
           The solution works (pending confirmations on the S-O use on
           certain OSes), and requires TURN relay for roughly 50% of
           the use cases. P2PSIP may be a customer for this solution.
        - Remove S-O from the solution: this makes it easier to
implement
          and will result in more relay use.
        - Select a radical approach like the one proposed in this
          meeting.
    
     There was consensus to continue working on this draft but no
     consensus on what the best approach is based on the 3 above
     options.

3/ NICE
   draft-rosenberg-mmusic-ice-nonsip-00.txt

   Jonathan Rosenberg presented a new draft, Non-SIP usage of ICE. A
   few comments were received about additional motivations for NICE
   (RTSP, Jabber/jingle).

   The chairs asked where this work should be done, is MMUSIC the
   right place?
   Cullen Jennings mentioned that the IESG has had discussions related
   to the rechartering of MMUSIC: ICE is tied to SDP so MMUSIC is the
   right home but the transport of ICE in more protocols is subject to
   discussions.  AD discussions take place between Magnus and Cullen.

   Bruce Lowekamp indicated he has implemented ICE for P2PSIP.  He
   wondered how many people who need something like NICE don't already
   have an implementation.  Therefore, simplifications for NICE might
make

   it harder to implement than staying close to the original ICE.  
   Bruce raised another comment: it is hard to predict what new
   protocols will need from the ICE spec and his preference is to not do
a
   sub-set of ICE.  This was also the opinion of Ekr, Philip Matthews,
   Remi D-C, and Magnus.  Some protocols may use subsets but these may

   not be aligned and the NICE spec may not be the right place to make
this

   choice for other protocols.

   In summary, the group discussed several questions related to NICE:
      - is it worth having a generic ICE as NICE intends to spec out
      - if yes, should it be all of ICE or a subset?
      - who are the customers of NICE and where should this work be
        done.

   There was no consensus on whether this work is really needed and
   comments were between: a) no need for this work, do ICE and
   b) do this work on NICE but no subset.

4/ SDP media capabilities Negotiation
   draft-ietf-mmusic-sdp-media-capabilities-03.txt

   Roni Even covered the last changes and open issues in draft-03 of
   SDP media capability negotiation.  Roni acknowledged the work done
   by Bob Gilman in particular (Bob did not attending the meeting).

   Note that about 5 to 7 people had read the new revision of the draft.

   Christer Holmberg asked if the draft needs to support the grouping
   of media lines/media attributes.  This is an open question: do we
   need to address regular grouping in this draft?

   More reviewers and feedback are requested.
   Philip Matthews indicated that a group of folks in Avaya is
   interested in this work.
  
   Henry Sinnreich wondered if this draft limits the adoption of new
   codecs due to its complexity and the coupling of codec & SDP
   descriptions.  Joerg and Magnus addressed the comment: signaling
   the codec parameters do not prohibit codec creativity and you still
   need an RTP profile definition.

   Miguel Garcia found a nice applicability of this draft so this I-D
   is solving some problems and he would like to see this I-D
   progress.

   Ingemar Johannson commented that he would like to see more rules
   for constructing capability attributes in SDP (Roni's last bullet
   on slide 6).

   The chairs called for additional reviewers to send comments to the
   list.

5/ RTSP 2.0
         draft-ietf-mmusic-rfc2326bis-17.txt
         draft-ietf-mmusic-rtsp-nat-06.txt
         draft-ietf-mmusic-rtsp-nat-evaluation-00.txt

5.1./ draft-ietf-mmusic-rtsp-nat-06
   Magnus Westerlund presented the recent changes in the RTSP 2.0 NAT
   draft (draft-ietf-mmusic-rtsp-nat-06.txt).

   A NAT traversal solution is needed for RTSP with use cases of
   clients and/or servers being behind NATs.
   Jonathan Rosenberg noted that the D-ICE solution proposed in the
   draft is some kind of ICE-lite with trigger checks (see draft and
   slides).

   There were some discussions around RTSP re-setup and ICE restarts.
   Jonathan noted that ICE restart provides continuity and wondered
   about the need to create a new ICE exchange. It could affect client
   behavior. More discussions are needed on the list.

   Remi asked about the use cases for re-setup: roaming?  There is
   a potential use case if the client moves from one interface to
   another.

   Magnus asked if this approach was a good one to use.  Now is the time
to send feedback.
   Jonathan asked why regular nomination should be used in a core
re-setup to
   provide continuity? He does not see what benefits this is bringing
   because you would not be able to re-use the ICE stack.

   Remi asked what would the use case could be for not using RTCP mux?
   Given that the other end implements ICE, why not implement RTCP
   mux?  This would have fewer problems.
   Magnu answered that there are a few cases, for example, the
   delivery of media behind a NAT and there are different RTP and RTCP
   streams.
   Jonathan Rosenberg added another case if for layered codecs across
   ports but current ones like SVC do not work that way.
                
   Philip Matthews commented that this is an example for ICE usage
   for a certain protocol. There is a need to come up with a more
general
   solution.

   Bill commented that we need to support components.  May be FEC is a
   candidate for other types of components?

5.2/ RTSP 2.0, draft-ietf-mmusic-rfc2326bis-17.txt

   Martin Stiemerling presented a brief status report on the changes
   in draft-17 of RTSP 2.0.  There is a proposal to add semantics for
   an END_of_STREAM indication.
  
   Martin and Magnus are the two principal contributors and the working
group
   does not seem to review or comment.  More interested folks are needed
   to move this work item forward.

6/ RTSP and SIP
   draft-whitehead-mmusic-sip-for-streaming-media-03.txt

   The draft on Media Playback Control Protocol Requirements was
   presented next by Sam Ganesam/Xavier Marjou.

   Magnus indicated that there is already work done in TISPAN and may
   be other standards organizations on this.  Magnus believes it would
be better to do a
   solution in IETF as a complement to regular RTSP.

   Jonathan Rosenberg commented that he is still unconvinced and more
   work is required on the use cases (use case #3 seems like an RTSP
   extension, the first 2 use cases are where RTSP does not work).  He
   asked if there were use cases compelling enough to motivate the
   work and wondered if the first case really requires streaming
   control.

   There are relations to SIP. It would be the right approach to
   identify, how SIP and RTSP can work together.
   There was a discussion on whether the individual SIP TOTE draft was
   a potential solution. Jonathan clarified that the ID does not
   intend to do that.

   Martin S. commented that we should investigate how SIP and RTSP can
   work together.

   Dave Oran proposed to characterize the problem of overlap in
   in-session control protocols better.  
  
   The presentation concluded with no consensus to work on this and
   participants requested more list discussions on the "real-world"
   "concrete" use cases and related requirements.

7/ SDP DSCP Attribute
   draft-polk-mmusic-dscp-attribute-02.txt

   James Polk presented an update of the DSCP attributes in SDP.

   Dave Oran raised the issue of where the decisions should be made for
   the DSCP code points, is it layer 3 and IP or layer 7? The issue
   raised by Dave is putting bits at layer 3 in layer 7.

   Additional comments were made by Henry Sinnreich, Cullen Jennings,
   Magnus W and Brian Rosen.

   Brian summarized the comments by indicating that the problem should
   be explored before finding out the solution.  We might need to look
   back at what needs to be communicated by whom.

8/ Signaling media decoding dependency in SDP
   draft-ietf-mmusic-decoding-dependency-01.txt

   Remi D-C made a minor comment on the values used for payload types
   (may be a bit big numbers for payload types).

   If extensibility is needed, an extension mechanism should be
   defined. Magnus added that the ABNF needs some work to add
   extensibility and a few cleanups.
  
   Stefan Wenger indicated that new text should be inserted to specify
   what is required to add an extension.

   There was wg consensus to go to WGLC with the upcoming revised ID.

9/ SDP Grouping Issues
   draft-begen-mmusic-fec-grouping-issues-00.txt

   Ali Begen covered a few SDP grouping issues based on the FEC work.

   RFC3388 contains a restriction related to the rule for grouping: an
   "m" line identified by its 'mid' attribute MUST NOT appear in more
   than one "a=group" line using the same semantics.
   It was introduced, because, there was no use case known at the time
   and to keep the solution simple.  There was no objection to remove
   the restriction in RFC3388 and update the RFC.

   As part of the discussion, the following comments are noted:
     - Jonathan Lennox indicated that the source attribute defines
       grouping to the source level so we might want to look if this
       problem applies to the source-specific SDP draft too.
     - Joerg clarified the needs to keep implementers who have done
       RFC 3388 happy.  Dave Oran indicated that there is some
       implementations of RFC 3388 but there does not seem to have any
       dependence on the restrictions in the RFC 3388.
     - Gonzalo Camarillo confirmed that as he recalls, the limitation
       was due to a scope limitation more than anything else.

   There was WG consensus to revise RFC 3388 to remove this restriction.
   The chairs will post a note on the list though.

We ran out of time.  The chairs asked if folks were willing to stay.
The last two presentations were done with only about 50% of the
working group participants in the room.

10/ SDP ptime attributes
    draft-garcia-mmusic-multiple-ptimes-problem-02.txt

   There were questions raised on whether MMUSIC is the right place
   for this draft.  Based on comments from Christer Holmberg and
   Joerg, it is recommended that this draft be discussed in AVT, at a
   minimum to ask for input and opinions.  It was commented that the

   draft has developed in the right direction in giving guidance to

   implementers.
  
   More list traffic is required on this draft.

11/ SDP for circuit-switched media
    draft-garcia-mmusic-sdp-cs-00.txt

   Miguel Garcia-Martin presented the motivations for defining new SDP
   attributes for circuit-switched media.

   Christer Holmberg commented that there could be use cases for
   these.   Christer brought up an issue which is not specific to this
   draft but to the capneg draft.  The offer/answer changes the c line
   between the offer/answer and this could cause some problems.
   Joerg commented this is not related to this draft, same issue with
   IPv4 and IPv6.  There was support stated in favor of the draft and

   what the authors are trying to achieve.
  
   Further list discussions is required on this draft to progress it.

12/ SDP for Collaboration Applications
    draft-garcia-mmusic-sdp-collaboration-00.txt

   This draft was not covered due to time limits.

The meeting concluded.

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