Subject: [MMUSIC] draft meeting minutes - mmusic wg - IETF 67, San Diego

From: "Jean-Francois Mule" <[email-masked]>
Date: Fri, 1 Dec 2006 09:48:27 -0700

Find below the draft minutes from the mmusic wg meeting in San Diego.

Let the chairs know if you have any comments or corrections by Monday December 4th.

Jean-Francois.

---
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- IETF#67 Meeting Minutes
--- Thursday, 9 November 2006 at 09:00-11:30
--- ============================================================

Reported by Jean-François Mulé

   The MMUSIC working group met once at the 67th IETF meeting (San
   Diego, November 2006). Topics under discussion included ICE, SDP
   for ZRTP, SDP Offer/Answer mechanism to enable file transfer, SDP
   capability negotiation, Best Effort SRTP, SDP for DTLS, Signaling
   of media decoding dependency in SDP, Diffserv code points in SDP,
   SIP for streaming media, and SDP for RTSP.
   The meeting was chaired by Jörg Ott, Colin Perkins and
   Jean-François Mulé, and it was attended by some 134 participants.

1/ Introduction and progress report

   The chairs introduced the session, reviewed the meeting agenda and
   gave a brief status report on the working group deliverables:
   - 6 RFCs were published since the last meeting with a special round
     of applause for the completion of SDP:
       draft-ietf-mmusic-sdp-new-26.txt 	-> RFC 4566
       draft-ietf-mmusic-kmgmt-ext-15.txt	-> RFC 4567
       draft-ietf-mmusic-sdescriptions-12.txt	-> RFC 4568
       draft-ietf-mmusic-sdp-srcfilter-10.txt	-> RFC 4570
       draft-ietf-mmusic-comedia-tls-05.txt	-> RFC 4572
       draft-ietf-mmusic-sdp-media-label-01.txt	-> RFC 4574
   - Two drafts are in Auth-48 status:
       draft-ietf-mmusic-sdpng-trans-04.txt
       draft-ietf-mmusic-sdp-bfcp-03.txt
   - One draft in the RFC Editor Queue
       draft-ietf-mmusic-fec-grouping-05.txt
   - and two drafts were with the ADs:
       draft-ietf-mmusic-sdp-media-content-04.txt
       draft-ietf-mmusic-security-precondition-02.txt
       (note: both drafts moved to the RFC Editor queue on 11-08-2006)

   The Internet Media Guide (IMG) work concluded and the remaining
   drafts will be published as experimental or informational RFCs. The
   chairs also requested volunteers to help complete the editing of
   RTSPv2. Finally, the creation of a design team was announced on SDP
   capability negotiation with a short-term objective of proposing a
   common approach or solution for capability negotiation that is
   backward compatible with SDP (target is before the end of 2006). An
   IPR statement from Cisco Systems on SDP capability negotiation was
   brought to the wg attention by Flemming Andreasen and noted by the
   chairs in the opening of the meeting.

   At the mike, Martin Dolly requested some meeting time to discuss
   draft-polk-mmusic-qos-mechanism-identification-02.txt. Jörg Ott
   indicated that, while no agenda time was requested, the chairs will
   open up the discussion on this draft at the end of the agenda, as
   time permits. However, the meeting went overtime and the above I-D
   was not discussed.

2/ SDP for ZRTP

   draft-zimmermann-avt-zrtp-02.txt

   Alan Johnston presented the SDP attributes for ZRTP. They are
   described in Appendix A of draft-zimmermann-avt-zrtp-02 (see slides
   for details).  Alan noted that an IPR statement has been released
   that relates to this draft.

   - 'a=zrtp' attribute (slide 2):
     A few comments were made on the meaning of the 'a=zrtp' attribute
     given that it is only a recommended attribute.
     Flemming Andreasen asked why the 'a=zrtp' attribute was not
     mandatory to include in SDP for all endpoints supporting ZRTP
     (MUST instead of SHOULD).
     Alan Johnston answered that the attribute is not required for
     ZRTP protocol operations and there are some "inline devices" that
     only have access to the media and cannot insert this attribute.
     Roni Even commented that this attribute is not meaningful to
     indicate ZRTP support as defined.
     Jonathan Rosenberg asked how an agent knows to do ZRTP or not and
     whether it is supported then?
     Flemming Andreasen proposed to move this discussion topic to the
     mailing list.
   - a=zrtp-sas and a=zrtp-sasvalue attributes (slide 3):
     Dave Oran asked whether those attributes contain a key
     fingerprint or a nonce value and if they could be generalized.
     Alan Johnston indicated that they contain a hash of the
     Diffie-Hellman public values, similar to a fingerprint.
     Eric K. Rescorla (EKR) clarified that it is a digest of both DH
     shared values in both directions and it is optionally exchanged
     after the initial offer/exchange is completed (via re-INVITE or
     UPDATE).
     Colin Perkins indicated that it would be good to generalize how
     these types of SAS strings are exchanged in SDP.
   - Based on a question from EKR, Alan Johnston clarified that if an
     agent uses RTP NOOP, it would have to negotiate a dynamic RTP AVP
     profile value for it. Colin indicated that the rationale for
     using an RTP NOOP packet is up for discussion in AVT.
   - As a closing comment, Alan Johnston suggested that these ZRTP SDP
     attributes could eventually be split out of the ZRTP AVT draft
     (slide 7).
     Colin Perkins answered that these SDP attribute definitions could
     be kept in this draft.

3/ ICE
   draft-ietf-mmusic-ice-12.txt
   draft-ietf-mmusic-ice-tcp-01.txt

   Jonathan Rosenberg presented the latest changes in ICE draft-12.
   A design team was formed after IETF#66 and conference calls were
   held almost weekly since ICE-10 was released (massive rewrite to
   meet simplification goals). Some considerable efforts were put by
   Jonathan and the design team to address open issues and release
   updated drafts.

   The main changes discussed in IETF#67 are the ones between draft-12
   and draft-11. There were no comments or questions on the first part
   of the presentation, the changes made in draft-12.

   Jonathan then presented the open issues on draft-12. The notes
   below summarize the consensus on the resolution of these issues and
   the main comments.
- 3.1. Open Issue: Considerations for broken, ICE-unaware SBC/ALG
-      (slides 6-9)
     + Jonathan presented the approach taken in draft-12:  detection
       of broken, ICE-unaware middleboxes, mechanisms for the offerer
       & answerer to indicate this via SIP option tag and/or a new SDP
       attribute, and ICE abort.
     + There was a general agreement that the current approach is
       appropriate (based on comments from Brian Stucker, Hadriel
       Kaplan, Francois Audet, and Derek MacDonald).
     + It was agreed that the scope of this ICE protocol is not to fix
       the problems generated by ICE-unaware broken ALGs and SBCs. The
       goal is to improve the detection mechanism to detect those
       cases, to diagnose that this has happened.
     + It was noted that ICE should work for non-broken ALGs/SBCs
       (Hisham Khartabil, Rohan Mahy, Jonathan Rosenberg) and that it
       may be too strong to state that it is not in scope to fix
       problems with SBCs and NATs (Francois Audet).
     + Based on a comment from Christer Holmberg, Jonathan clarified
       that the SIP option tag for ICE and the SDP attribute
       'a=ice-mismatch' are complementary to indicate the presence of
        a broken SBC/ALG:
         o the presence of SIP option tag helps in the cases where
           those middleboxes strip out ICE candidates from SDP
         o the presence of the SDP 'a=ice-mismatch' attribute helps to
           notify the offerer than ICE candidates were received but
           there is a mismatch with the m/c line.
     + The best way to go through these types of middleboxes is to use
       SIP over TLS (Jonathan Rosenberg, Derek McDonald) and, in some
       cases, to not use the default port 5060 (Hadreil Kaplan)
#    + The following comments were accepted as suggested changes for
#      the revised version of ICE:
            a) recommend that agents put the 'ice' SIP option tag when
               registering (Hadriel Kaplan). Hadriel noted that some
               SBCs can learn not to muck with SDP if an option tag is
               present in the Supported header of REGISTER requests.
            b) clarify the text re: how ICE allows for traversal of
               NATs and therefore, help traverse some types of
               unbroken ALGs/SBCs (Francois Audet), yet does not
               attempt to solve the problems generated by broken
               NATs/ALGs (Jonathan Rosenberg, Derek McDonald).
            c) indicate that the best way to deal with these broken
               SBCs and ALGs without knowing more about the network
               topology is to use SIP over TLS (Francois Audet,
               Jonathan Rosenberg, Derek McDonald).

- 3.2. Open Issue: Where to put text on ICE-for-gateways?
-      (MacDonald-2, slide 10)
     + There was general agreement to have a separate document for
       devices that are known to not be behind a NAT (applies to
       gateways but not exclusively as Francois Audet noted).
     + This document should progress as quickly as the main
       ICE document (Hisham Khartabil).
     + EKR and Jonathan agreed to co-author such a document.

     + Jonathan added a concern raised by the design team at IETF
       about the fact that ICE passive-only implementations still have
       to generate a triggered STUN request. This requires those
       devices like decomposed gateways to keep track of timers
       and retransmits. The goal is further simplification.
#      No objection was raised and there was consensus for accepting
#      the following proposed solution (based on comments from Derek
#      McDonald, Phil Matthews, Alan ?, Jonathan Lennox and Roni
#      Even):
       when an agent talks to a device in passive-only mode, the agent
       does not put the done flag in a check unless a previous check
       was that same candidate was ack'ed and the check succeeded.
       This is a change from ICE-12 which allows the done flag to be
       put.
       This does eliminate the triggered check to be initiated by the
       gateway by adding 1 RTT in call set-up delay for each component
       RTP & RTCP.
     + Roni Even added a final note on the above proposed: it may be
       the case that gateway implementers will need to do full mode
       implementations as those gateways may end up being behind
       NATs. Jonathan commented that this is done as a transition to
       get ICE deployed on agents to have then have full mode
       implementations on the gateways.

- 3.3. Open Issue, ICE Hammer (slide 11)
     + There was some rough consensus to add a requirement to protect
       against ICE hammer attacks: ICE checks SHOULD be limited to 100
       total checks by default.
       It would mean about 2 seconds max of ICE checks with the
       current timers.
     + It was pointed out that this solution is by no means perfect
       (Jonathan Rosenberg, Philip Matthews).
     + Phil Matthews commented that if a response to any of these
       checks is received, the timer goes away.
     + Based on a question from Brian Stucker about what happened if
       this timer expires and no responses were received, Cullen
       Jennings commented it was agreed that ICE must not specify what
       happens to a call when ICE reaches an end-state.
     + Tim Moore? claimed that there are issues because some networks
       (cable and DSL's) have an initial 2 second-delay at call set-up
       when no STUN UDP packets go through. Then packets are
       transmitted fine. Jonathan added that the controling agent
       could implement methods to work around this problem as this
       solution does not say "don't do more checks after 2 seconds".
       Tim agreed it will work but may need to be careful.
     + Flemming Andreasen commented that putting these kinds of
       arbitrary limits into protocols may not help in the end
     + EKR: this proposal seems a fine compromise; the importance of
       this limit mechanism is that it be expressed in terms of max
       number of packets, not a timer.
     + Colin Perkins closed the comments by underlining the SHOULD
       strength of this requirement.

- 3.4. Other Open Issues (slide 12-15)
     There was consensus on the following resolutions:
     + leave optimizations of the ICE and ICE pacing for further study
     + leave fine tuning of the ICE retransmits for future
       enhancements once operational and deployment experience is
       available on ICE
     + reject the proposal to obfuscate ICE candidates
     + close issue Holmberg-1 without making any changes to ICE-12
     + keep the mechanism for reliable provisionals using STUN
       (retransmission of 1xx until STUN requests arrive) and add that
       agents SHOULD use PRACK if it is available, not hang up the
       call if STUN never arrives, and stop 1xx retransmits when
       sending a 200 OK (independently of whether or not STUN
       arrived).
#      The following comments were accepted as suggested changes for
#      the revised version of ICE:
       - add a sentence to clarify that, if an agent does not support
         PRACK, this mechanism may be used for 1xx that triggered the
         start of ICE (1xx that contain SDP and are associated with an
         offer/answer exchange). This was agreed to based on comments
         from Rohan and Jonathan.
       - verify there is text to say that the agent still needs to
         send the answer in the 200 OK to complete the offer/answer
         exchange. This was agreed to based on a comment from Christer
         Holmberg.
     + keep QoS section as there is no harm and it helps in
       some environments where ICE will get deployed (Jonathan and
       Cullen).
     + loosen the requirements on ICE keepalives to only require ICE
       keepalives to be sent when there is no media traffic, and also
       recommend the use of the STUN Binding Indication in 3489bis.
       It was noted that if the transport port is set to 0 in the m
       line, no ICE checks should be performed (check for IP adds set
       to 0.0.0.0).
       These keepalives should be sent no matter what the SDP modes
       are active (sendrev, reconly).

   Jonathan concluded with a brief update on ICE-TCP (see slides for
   details). More reviewers are welcome on the ICE-TCP draft,
   especially from folks working on TCP in the behave wg.
- Open Issue, ICE-TCP and TLS as a separate transport protocol
   One open issue was raised by EKR during a design team meeting:
   should TLS be treated as a separate transport protocol in ICE-TCP.
   In the interest of time, Jonathan proposed to address this issue on
   the list.

   The presentation concluded with a summary of the plan moving
   forward. ICE-13 will be submitted shortly after the meeting along
   with the separate document for "ICE-for-gateways". The
   intent is to begin WGLC shortly after that and complete ICE before
   the end of the year as far as the wg is concerned.

   A final issue was raised by Christer Holmberg for addressing the
   case of restarting ICE due to an answerer changing m/c line media
   parameters in an answer message.
   Cullen Jennings requested that this issue be addressed in
   the wg meeting rather than on the list with a resolution.
   A discussion followed with comments from Derek McDonald, Rohan
   Mahy, Francois Audet and Jonathan.
   The following consensus was reached:
        + an agent must not restart ICE in an answer:
          An agent must not change media related parameters ICE uses
          in an Answer message. The agent should instead send the
          answer, and send an updated offer by initiating a new
          Offer/exchange with new parameters.
        + The text should not necessarily cover what an agent does
          when receiving an answer with changed parameter (Jonathan).
   The motivations behind this consensus were that the above brings
   generality rather than the additional complexity associated with
   the proposed improved efficiency goals (Rohan Mahy), it means just
   one UPDATE transaction (Derek).

4/ SDP Offer/Answer Mechanism to Enable File Transfer
   draft-garcia-mmusic-file-transfer-mech-01.txt

   Miguel Garcia presented the updated Internet-Draft on the SDP
   offer/answer mechanism to enable file transfer and covered the main
   changes in draft-01 (see slide 3, 4 for details).

   There were some discussions on how the draft should deal with
   non-printable UTF-8 characters in the file name for example. This
   is important as this field may be used to present the filename to
   the end user (rendering purposes).
   Colin Perkins noted that the authors should discuss this with folks
   in the APPS area and recommended that, at a minimum, a note should
   be added that there might be some issues displaying non-printable
   characters.

   There were no comments or objections expressed on the proposal to
   rename the 'byte-range' SDP attribute to 'file-range'.

   Regarding the disposition type, there were no objections for using
   the 'render' value to mean "This is a file I want you to see on
   your screen" and defining a new value to mean "This is a file you
   may want to save".

   For the file selector attribute and the hash attribute, Jonathan
   Lennox recommended to re-use the work done for TLS comedia on the
   naming of the hash algorithms.
   Joerg Ott and Eric Rescorla noted that for the purpose of the file
   selector hash (identification rather than protection), even MD5
   could be ok.

5/ Signaling of media decoding dependency in SDP
   draft-schierl-mmusic-layered-codec-01.txt

   Thomas Schierl presented the changes in the signaling of layered
   and multi description media in SDP. See slides for the change
   details.

   Based on a comment from Flemming Andreasen, Thomas Schierl agreed
   that the next version of the draft should contain some text
   regarding SSRC collisions, how to handle them, especially given
   the offer/answer exchanges.

   There were some final discussions and comments on whether this work
   should happen in MMUSIC for layered codec media. Colin Perkins
   summarized the consensus by stating that this work should happen in
   MMUSIC and it may be difficult.

6/ SDP Capability Negotiation
   draft-andreasen-mmusic-sdp-capability-negotiation-01.txt

   Flemming Andreasen presented the latest main changes in
   the SDP capability negotiation draft. An IPR statement from Cisco
   was noted in slide #2.

   The general scope of the draft and completeness of the requirements
   currently in the draft were discussed.
   Jonathan Rosenberg questioned whether the complexity of the
   proposed mechanism aligns with the scope of the problem. He added
   that the proposed mechanism feels too much but it is unclear what
   requirements should be removed to make the mechanism less complex.
   Flemming answered that the important part of the discussion for now
   is whether the requirements are valid to keep. Jonathan responded
   that it is also important to look at the proposed mechanism, not
   just the requirements to weigh the complexity.
   There were some discussions on whether it is a fundamental
   requirement to be able to negotiation SDP capabilities in a single
   offer/exchange but no conclusions were reached.
   Eric Rescorla asked whether the current requirements were complete
   enough. Given the scope of the effort and complexity, we should
   think hard so that no new requirements emerge in the next 2 years.
   Colin Perkins added that we should attempt to tackle the problem
   with a full list of requirements rather than doing multiple
   incremental revisions to address the problem.
   Some noted that the requirements 150 and 160 are ok (Roni Even,
   Stefan ?).
   Steve Casner would like to see a solution that just looks
   more generally at the problem rather than just taking a quick fix
   for a particular case.

   There was consensus on the fact that the new solution should not be
   bound to RFP 3407 (simcap): it is not widely implemented (Jonathan
   Rosenberg, Francois Audet).
   Francois Audet insisted on the fact that the generic solution
   should address the things we need now, like the ability to
   indicate support for RTP or sRTP.

   Flemming concluded that the next steps include finalizing the
   requirements for SDP capability negotiation.

7/ Best Effort SRTP
   draft-kaplan-mmusic-best-effort-srtp-01.txt

   Hadriel Kaplan presented a draft on Best Effort sRTP.

   Christer Holmberg commented that if the answerer does not support
   SRTP, the draft allows to choose a dynamic payload type for RTP.
   Hadriel answered that UAs should not do that.

   Magnus Westerlund asked about the lack of RTCP consideration in the
   draft. Hadriel Kaplan mentioned that the options for addressing
   sRTCP include: a) sRTCP SR and RR should be given a specific
   payload type, or, b) payload mappings for RTCP packets, or c) wait
   until the answer is received to send RTCP.
   Magnus responded that these look like a hack to work around the
   limitations of the SRTP solutions which assume you know you can do
   SRTP before sending packets. Also, doubling the payload types is
   not a good solution as we will soon run out of the name space.
   Jonathan added a fourth options: d) you could run ICE and include
   an attribute in a STUN check to indicate that SRTP is coming.

   Eric Rescorla commented that the srtp attribute must be present if
   SRTP is required: one should not infer that from other media
   attribute parameters. Hadriel agreed.

   Roni Even suggested that AVPF is required for video and should be
   added (slide 9).

8/ SDP for DTLS
   draft-fischl-mmusic-sdp-dtls-01.txt

   Jason Fischl presented a draft that defines a way to signal that
   the RTP/AVP stream should be secured with DTLS/SRTP (DTLS used to
   negotiate keys for use in SRTP).
   There were no discussion on this draft as it addresses a similar
   problem space as the 2 previous ones and the chairs suggested an
   open mike discussion on how to deal with those requirements and
   solutions.

6/ 7/ 8/ Open Mike discussion
   Cullen Jennings made an opening comment: these 3 drafts deal with
   SDP capability negotiation, some propose a generic set of
   requirements and solution, some address a specific issue with a
   point solution.
   Cullen indicated that this has been an issue for some time in the
   RAI area (SRTP, RTP over dccp, fec-frame, video) and he concluded
   that the wg should solve this and provide a general solution: we
   need a path forward and this path forward should be fast.

   Flemming insisted that we should have a requirement on the scope of
   the problem and the requirements as it is apparent that the drafts
   have different views on the scope of the problem. It might be
   possible to come up with a modular solution that would allow folks
   to implement a subset for the things they need now.
   Colin Perkins concurred, it seems reasonable if it is achievable.
   Roni Even added that having just one solution will not solve the
   problem in the long run, implying that the scope should be to
   address the larger problem of SDP capability negotiation.

   Various participants expressed opinions in favor of converging and
   working together on a solution (Francois Audet, Cullen Jennings,
   Colin Perkins, Flemming Andreasen, Roni Even, Hadriel Kaplan,
   Stefan ?, Jonathan Rosenberg).
   In the end, based on the wg consensus, the chairs proposed to start
   a design team led by Flemming Andreasen with the following mandate:
    - define requirements for the overall problem space,
    - produce a common, generic but modular solution to do SDP
      capability negotiation that allows for incremental pieces to be
      deployed (i.e. keep in mind that it should provide a
      solution for things needed now like best effort SRTP).

9/ Diffserv code points in SDP
   draft-polk-mmusic-dscp-attribute-00.txt

   James Polk present a draft to indicate DSCP code points in SDP.
   Francois Audet commented that the problem scope/statement is not
   explained or described well enough in the current draft.
   Due to time constraints, minimal discussions occurred during the wg
   meeting. It was proposed to continue this topic on the list and do
   a couple more iterations of the draft.

10/ An Evaluation of SIP for Streaming Media
   draft-whitehead-mmusic-sip-for-streaming-media-02.txt
11/ SDP for RTSP
   draft-marjou-mmusic-sdp-rtsp-00.txt
12/ An Evaluation of SIP for Streaming Media
   draft-whitehead-mmusic-sip-for-streaming-media-02.txt

   The above three drafts were presented very briefly together by
   Xavier Marjou. Due to time constraints (the wg was 15 minutes behind
   schedule at that point), and the lack of comments, minimal
   discussions occurred.
   Some comments were re-iterated from the previous meeting (issues
   re: removal of RTSP SETUP message, overall of SIP and RTSP session
   establishment, use of RTSP vs. MRCP). It was proposed to continue
   this topic on the list.

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