---
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- IETF#69 Meeting Minutes
--- Tuesday, 24 July 2007 from 15:20-17:20
--- Wednesday, 25 July 2007 from 13:00-15:00
--- ============================================================
Reported by Jean-François Mulé
based on notes from Colin Perkins and Jean-François Mulé
The MMUSIC WG met twice at the 69th IETF. The meeting was chaired
by Colin Perkins, Jörg Ott, and Jean-François Mulé. Both sessions
were attended by some 100+ participants.
1/ Introduction and progress report
The chairs presented the agenda and a brief status of the working
group:
- no RFCs were published between IETF#68 and IETF#69
- draft-ietf-mmusic-securityprecondition-04 was in IESG review
at the time of IETF#69 and is in the RFC Editor queue as of
August 21 2007
- draft-ietf-mmusic-sdpng-trans-04 is dead.
For agenda details, see file named mmusic-0.pdf
2/ Source-Specific Media Attributes in SDP
http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-attributes-01.txt
Jonathan Lennox presented the source-specific media attributes
draft.
There was some discussion on whether there should be an SDP
attribute for an agent to indicate that it can handle a maximum of
N sources (slide 7).
Some believed the mechanism is not required since in ASM, it's
never been possible to control this and implementers need to
realize that RTP is a group communication protocols; others raised
the issue and complexity of dealing with errors and what to do if
an agent can only support one source, which one it could/should
select, etc.).
Based on the above comments from Steve Casner, Roni Even, Colin
Perkins and other participants, the consensus was that this
functionality should not be added to the current draft.
On the usages of source-specific fmtp (slide 8), Roni Even noted
that the draft is unclear on which stream will be chosen if the
remote agent does not support this attribute.
Flemming commented that defining a means to indicate source-specific
fmtp parameters at a media attribute level could lead to numerous
offer/answer exchanges and could constitute a major change to the
offer/answer model (since a=fmtp is negotiated in the offer/answer
exchange). Flemming recommended that more general guidance be
provided on how this interworks with offer/answer. The discussion
ended without any clear consensus and more will follow on the list.
John Elwell asked how this draft interacts with sip forking &
multiple streams, and if it could help correlating the call legs.
Christer Holmberg also wondered if it can help associate a media
stream with a particular dialog. Jonathan Lennox responded that it
may help but other mechanisms like ICE could be used.
Jonathan Lennox would like to move quickly on the base spec due to
the RTCP-SSM dependency. Colin Perkins asked the working group for
the level of interest in this draft via a hum (consensus was
"yes"). Subject to rechartering, there was consensus that this work
should progress in MMUSIC.
3/ Media Description for IKE in SDP
http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-01.txt
Makoto Saito presented the draft update for IKE media description
in SDP. The draft has been updated by Makoto Saito and Dan Wing and
proposes to use the same concept as comedia-tls to exchange the
fingerprint of the self-signed cert for IKE authentication.
Eric Rescorla (EKR) said that there should be a means to indicate
that IKE leads to IPsec. Dan Wing clarified that some semantics may
be missing in the draft to indicate that the IKE negotiation of a
security association will lead to an IPsec tunnel.
EKR also noted that in the presence of NATs, it is not sufficient
to punch holes for IKE using ICE since IPsec is a separate
protocol.
There were additional discussions on how an agent could signal that
it wants to initiate an IKE negotiation. Colin Perkins noted that
the use of "m=application 500 udp ike" which defines
application/ike might be controversial.
The chairs also noted that the SIPPING working group should also be
aware and folks from SIPPING should be involved. It was agreed that
the MMUSIC chairs will talk with the AD Cullen Jennings to figure
out the best path forward so the authors can make progress. May be
MMUSIC is the home for SDP issues, and other parts of the drafts
can be homed elsewhere.
4/ Configuring DSCP of SDP Established Media Streams
http://tools.ietf.org/html/draft-polk-mmusic-dscp-attribute-01.txt
James Polk presented an update of the draft proposing to
"configure" (offer or dynamically change) the DSCP markings of a
session's media streams.
Several comments were made on the open issues (slide 7):
- Francois Audet first recommended to not to use DSCP code
points but something that is more high level; Francois also
added that while an SDP attribute may make sense for
end-to-end, if the mechanism relies on an SBC or network
middle box to work, it should use subscribe/notify rather than
allowing SDP to be modified midcall
- Dave Oran has several issues with the draft: one, the
mechanism is not granular enough to specify which packet of a
given media stream a certain DSCP is applied to (e.g. media
packets of I and P frames of an MPEG2-TS with 2 different DSCP
values). Secondly, there are concerns about rewriting DSCP
across domains and the problem space may be bigger than the
current draft.
- James Polk responded that the scope could be expanded beyond
the current "per-stream solution", the draft is open for
suggestions on this
- Hadriel Kaplan insisted that a B2BUA is a UA and can change
SDP
- Other comments followed from Jean-Francois Mule, Brian Stucker
raising concerns about UAs across domains marking packets
based on the remote UA's local DSCP policy, and whether a
server has more of better knowledge than the UA.
- James responded that a solution could be applicable to a
private network where the above is known
- John Elwell asked if the SIP Session Policy framework could
help (James does not think so).
- Dave Oran concluded the comments by raising the question of
whether a more abstract mechanism could be proposed: signal
"service X" instead of "DSCP X" which implements that
service).
It was proposed to organize a meeting while at IETF or organize a
conference call after IETF in order to discuss the problem
statement, scope of applicability and set of issues.
5/ SDP Offer/Answer Mechanism for File Transfer
http://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-03.txt
Miguel Garcia presented the recent changes and open issues on the
SDP mechanism for file transfer.
Related to a bullet point referencing a recent change on hash
algorithms (slide 6), Jonathan Rosenberg asked why multiple hash
algorithms are needed and EKR commented on the purpose of the hash
(integrity check vs. security feature). EKR recommended using
something other than a hash like a specific CRC if it's a CRC.
There were no comments from the working group on the proposal to
refer to MSRP and make message/cpim is mandatory to implement for
the message/cpim wrapper.
On the open issue of aborting existing file transfers, based on
questions from Jonathan Rosenberg, Gonzalo Camarillo clarified the
use case description. One of the requirements is to have a
mechanism to restart a transfer, including an explicit signal to
start the file transfer over in a re-invite and distinguish an
explicit restart request from a message repeat.
Based on comments from Jonathan Rosenberg and Joerg Ott, it is
proposed to add some kind of transfer identifier field which
could for example change if the user wants to abort.
The authors will revised the draft which should then be pretty
close to WGLC.
6/ Multiple Packetization Times in SDP
http://tools.ietf.org/html/draft-garcia-mmusic-multiple-ptimes-problem-00.txt
This draft describes a problem statement for multiple packetization
times in SDP.
Colin Perkins and Joerg Ott asked why this is needed.
Hadriel Kaplan, Robert Sparks, Jean-Francois Mule provided examples
including express requests from the implementers community of
media gateways, limitations in DSP silicon some vendors have,
accurate QoS budget calculations in some networks.
Robert Sparks mentioned that in SIP-it, while issues related to the
lack of such a mechanism are not widely spread (below 10%), some
implementations break at every SIP-it so a clarification for
implementers would be good.
There were divergences in what should be done about this problem,
either produce a fix or recommendation for so-called "broken
implementations".
Colin Perkins stated that we should not assume the outcome and that
telling folks that their implementation is broken is a possible
outcome (it may not be the consensus but a possible outcome).
It was concluded that more input is needed on this topic.
7/ Signaling media decoding dependency in SDP
http://tools.ietf.org/html/draft-schierl-mmusic-layered-codec-04.txt
Thomas Schierl presented the updates done in the draft addressing
how media decoding dependencies could be expressed in SDP. This is
in part motivated by RTP session multiplexing of layered media or
multi description coding.
There was some debate on where those media decoding dependencies
fit (media or session level attribute).
Roni Even asked why dependencies are done at the media attribute
level and not at the session level.
Magnus Westerlund justified its definition as a media attribute
since it is the media stream that has dependency.
Another discussion was about the scope of the document and the
choice of the grouping framework as part of the solution.
Flemming Andreasen commented that it is not clear that grouping is
the right framework: how can an agent express an offer with 2
alternative video codecs?
Thomas proposed to use different groups to express this Magnus and
Flemming agreed that there are cases where this does not work and
get complex.
Magnus concluded this discussion by proposing to limit the scope of
this document per payload type; this could solved in a different
draft. This scope question should be confirmed on the list.
Pending rechartering approval, there was consensus for this draft
to become a wg item.
8/ RTSP 2.0
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-15.txt
See slides for details.
Dave Oran pointed to various project initiatives and SDOs modifying
RTSP: ITU, ATIS, 3GPP, DVB, etc.
Jean-Francois Mule indicated he had calls with the editor of the
RTSP requirements in DVB trying to get them to contribute to IETF.
Dave Oran, IAB requested the chairs send liaison statements to
those various organizations to invite people to bring their work to
IETF on 2.0 RTSP.
9/ RTSP 2.0 and NAT Traversal
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-00.txt
Magnus Westerlund presented the work initiated on RTSP 2.0 and NAT
traversal by outlining that the problem to solve is the NAT
traversal of the media stream from the RTSP server to the RTSP
client.
As for the solution, comments were made in favor of continuing with
the previous consensus that the solution relies on ICE (slide 6).
10/ SDP Capability Negotiation
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-06.txt
Flemming Andreasen presented the latest drafts on SDP capneg
(draft-ietf-mmusic-sdp-capability-negotiation-06,
draft-andreasen-mmusic-sdpcapneg-att-del-00 and
draft-ietf-mmusic-sdp-capability-negotiation-reqts-01) - see slides
for details.
The open issues in the core specification
(draft-ietf-mmusic-sdp-capability-negotiation-06) were discussed
first:
- 1) Lack of support for bandwidth capabilities (slide 7):
The consensus was to continue discussing the requirements
and examples on the list. Magnus agreed to write up
something (an example?) on how to use the for codec and bw
modifiers for negotiations in the core spec.
- 2a) Lack of support for media capability negotiations (slide 8):
Magnus stressed the importance of this but Flemming and
Ron commented that there is no requirement to justify this
is in the core. To be added, there should be a requirement
for it.
- 2b) Session level coordination between potential configs
(slides 9 & 10):
There were no comments from the wg which suggests that
this would be left out of the core unless someone brings a
strong use case scenario.
- 2c) Media capabilities negotiation, in or out of core
(slide 11)?
Consensus: leave it out unless someone comes up with a
strong example and case in the near term (within 2 weeks
or so). Some of the discussion items are captured below.
Jonathan Rosenberg, Roni Even and Flemming made comments
towards leaving media capability negotiation out of the
core. Jonathan indicated that we should leave it out in
the interest of making progress for the negotiation of RTP
| SRTP ("SRTP problem").
Magnus agreed but had concerns about forward compatibility
and not having enough flexibility for later (the tcap
param is not generic enough to support future
extensions).
Steve Casner commented that the main problem with SDP is
that attributes you don't understand are ignored. This makes
extensions hard, because you can't tell if they're being
used or not. If you've addressed that, the problem is a
lot easier to solve.
- 3) Usage of Truncated Syntax as capability definitions
(slide 12)
The group's consensus was to remove this functionality.
Jonathan voted for "less is more". Joerg Ott raised the
issue that you may end up with arbitrarily truncated
attributes for which the meaning is unclear.
- 4) Media Before Answer (slide 13):
Consensus: leave as-is
- 5) Obsoleting RFC 3407 (slide 14):
Based on input from Francois Audet, and Flemming, and the
fact that RFC 3407 is deployed in some networks, the
consensus was to not obsolete RFC 3407 (option 3) in slide
14)
This is document is getting ready for Working Group Last Call
unless Magnus or anyone else comes up with something new or major
that should be addressed.
11/ ICE TCP
http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-04.txt
Jonathan Rosenberg presented the changes and open issues in
ICE-TCP.
- Open issue #1: DTLS-SRTP
EKR indicated that there is no technical reason why this won't
operate correctly. Francois Audet agreed that this is not as bad
as it sounds.
Dave Oran is ok with the recommendation but noted that what is
deployed in the field is RTP over TCP and problems will arise
when the negotiation of RTP over TCP is different from DTLS-SRTP
over TCP.
Colin Perkins recommended using DTLS-SRTP over TCP instead of RTP
over TLS which should be avoided. Jonathan agreed.
We had general consensus to run DTLS-SRTP over TCP rather than
RTP over TLS.
Steve Casner proposed that the document should have a paragraph
to capture why RTP over TLS should not be done.
- Open issue #2: S-O candidate from TURN server
Phil Matthews expressed concerns that we do not fully understand
the combinations of NAT cases that are eliminated if this is
removed and indicated that for p2psip in particular, having this
functionality may be an interesting case. Cullen outlined a
really unlikely use case (2 peers behind fully symmetric NAT and
one peer uses a TURN server behind a NAT?).
Jonathan agreed to reconsider this whole case in the light of
p2psip which seems to be a valid case. More considerations is
required given the implementation impact -> more discussion to
the list is expected on this.
- Open issue #3: TURN vs. RTP shim (RFC4571)
There was general agreement to keep using the RTP shim (RFC4571)
as current defined in the draft. This consensus was based on
comments from Colin (given what's deployed, it is good to stick
with 4571), Jonathan Rosenberg and Rohan Mahy.
ICE-TCP needs more reviews pending some updates.
The meeting concluded.
> end.