---
--- 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-securityprecondition-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 Majou. 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.