Multiparty Multimedia Session Control (MMUSIC) Working Group Minutes
====================================================================
Reported by Colin Perkins
The MMUSIC working group met twice at the 66th IETF meeting (Montréal,
July 2006). Topics under discussion included ICE, SIP for streaming
media, RTSP bitrate header, SIP preconditions for media privacy, SDP
capability negotiation, signalling media decoding dependency in SDP,
SDP security descriptions extensions for IPsec, and SDP offer/answer
to file transfer sessions. The meeting was chaired by Jörg Ott, Colin
Perkins and Jean-François Mulé, and attended by some 120 participants.
Introduction and progress report
The chairs introduced the session and gave a brief status review. The
group has had two RFCs published since the last meeting (RFC 4473 and
RFC 4435 on the IMG requirements and framework), and has several more
drafts in the AUTH48 state, which should appear as RFCs soon (sdp-new,
srcfilter, sdescriptions, sdp-bfcp, kmgmt, media-label and comedia-tls).
The sdpng-trans draft is (still) in the RFC editor queue. The security
preconditions, media content and FEC grouping drafts are with the ADs.
The chairs drew attention to draft-levin-mmusic-xml-media-control-07.txt
which is an individual submission to be published as informational after
review by the group, describing a legacy XML-based media control scheme.
Jean-François Mulé was welcomed as a new co-chair.
ICE
draft-ietf-mmusic-ice-09.txt
draft-ietf-mmusic-ice-tcp-01.txt
draft-matthews-mmusic-ice-eliminating-duplicates-00.txt
Jonathan Rosenberg described ice-9, noting in passing its capability "of
destroying the world as we know it", before moving on to a review of the
changes since the -08 version of the draft, and a discussion of the open
issues.
Open issue #1: what happens if an SBC is in the path and not ICE aware?
There was some discussion, initiated by Francois Audet, of how various
scenarios might impact ICE processing, and some discussion on the need
to document how SBCs can safely work with ICE. The general consensus was
to keep the current approach, and consider the design of ICE-aware SBCs
later.
Open issue #5 "delay checks": limited discussion. Philip Matthews
supported sticking with the current approach.
Open issue #6 "STUN from TURN": general agreement that this topology is
broken, and shouldn't be supported by ICE. Jean-François Mulé suggested
it would be good to document which topologies don't work with ICE, as
guidance to future system implementers.
Open issue #2 "Pairing peer derived with other candidates": Philip
Matthews expressed concern that this shows that one of the assumptions
behind of ICE (that candidates only need to be peered with peer-derived
candidates, not all candidates) isn't true, and wondered if there will be
other cases where this is a problem. Cullen Jennings noted that this is
a problem because there is no STUN server in the left-most inner realm
in this scenario: he considers this a broken network design, and not
something we should support. Much discussion around the issue of which
topologies we wish to support, but no agreement. No resolution of this
open issue.
Open issue #8 "too complicated": Jonathan suggested a rewrite of the ICE
specification to reduce complexity, changing the implementation style,
not the basic operation. Tim Hall noted that this is how they implement
ICE now, and that it works and is indeed simpler. Francois Audet agreed
that a reduction in complexity is appealing, not noted the risks of a
major rewrite to the specification at this late stage. Philip Zimmerman
noted that many vendors say "we don't support ICE yet", and if this is
due to the complexity, spending the effort here might be worthwhile.
Philip Matthews described his alternative proposal to eliminate duplicate
checks in ICE. There were many questions for clarification.
Open discussion followed. Key points were as follows:
- Francois Audet agreed in principle with the need to simplify, but saw
little indication that the specification was converging on a stable
version. This discourages developers, and we really need to agree a
single stable proposal. Cullen Jennings agreed: he also doesn't want
to wait for several more IETFs worth of discussion.
- Robert Sparks, Jason Fischl, and Eric Rescorla strongly supported the
need to simplify the specification, and to rework the document so that
it makes sense to implementers instead of being written for the working
group. If they had to make the choice, they would prefer simplifying the
draft rather than keeping backwards compatibility with previous versions
of ICE.
- Tim Moore stated that they've implemented the Jonathan's initial "big
idea" without any trouble, and that the result is compatible. That
said, even with the simplification, this is a complex protocol, and
he isn't sure the delay to simplify is worthwhile, since the result
won't be enough simpler.
- Rohan Mahy expressed the opinion that the goal of ICE is to make
things more predictable, work more often, and be more optimal; in
that order. He considers it counter-productive to go too far in terms
of complexity for optimisation. Simpler is better. Tim Moore and Derek
MacDonald agreed, also preferring simplification to optimisation.
- Rohan Mahy noted that a use cases document saying, "these topologies
are broken, these work" would be really useful.
Jörg Ott summarised the impression of the discussion, noting that
there was little support for further optimisation work, but
conflicting views on how to simplify the protocol (indeed, to what
extent this is just a presentation choice rather than an
algorithmic difference). To move forward, Jonathan agreed to
produce a revised draft by six weeks after the meeting,
implementing his simplification proposal, which should be discussed
in an interim teleconference. Philip Matthews and Eric Rescorla
volunteered to help with the editing process. A strong hum backed
this plan.
An Evaluation of SIP for Streaming Media
draft-whitehead-mmusic-sip-for-streaming-media-01.txt
Marie-Jose Montpetit discussed use of SIP for streaming media, with an
outline of the rationale for using SIP to signal RTSP sessions, the use
cases, and the derived requirements.
Dave Oran asked if the authors have considered MRCP for media control?
Rohan Mahy agreed, noting similarities to the proposal, and suggesting
the authors include MRCP in their requirements analysis.
Bitrate header in RTSP
draft-wei-mmusic-rtsp-bitrate-header-01.txt
Kylin Wei outlined a proposal to add an RTSP bitrate header, to allow
selection of transport bitrate. This aims to avoid the problem of big
SDP session descriptions, when including many alternate streams, moving
the complexity into RTSP instead. Colin Perkins noted Magnus Westerlund
had sent an extensive rebuttal of this draft on the mailing list, and
asked that these points be addressed. Discussion was moved to the list.
Use of SIP Preconditions for Media Privacy
draft-shacham-sip-media-privacy-02
Henning Schulzrinne briefly presented a draft on SIP preconditions for
media privacy. The aim is to signal preferences, to get user agreement
on whether a session can be recorded, as part of session establishment.
Rohan Mahy asked what's to stop someone recording anyway? Clearly this
cannot be enforced -- it's a fancy version of the "recording beep" used
in some jurisdictions and conveys preferences only.
Flemming Andreasen wondered why preconditions are the right tool here,
rather than using some sort of header? Because it'll delay setup until
the answerer agrees to the recording preference. Jonathan Rosenberg was
of the opinion that this would be better suited to a header, and is not
different from the other headers a system must consider when accepting a
call.
Mark Baugher noted that this may be legally dangerous without integrity
protection, since a middlebox could modify to SDP to add or remove the
precondition specifier.
SDP Capability Negotiation
draft-andreasen-mmusic-sdp-capability-negotiation-00.txt
Flemming Andreasen presented a new draft on SDP capability negotiation.
He reviewed the background to capability negotiation in SDP, and went on
to discuss requirements:
Req-10 "MUST be possible to indicate/negotiate alternative (combinations
of) media formats on a per media stream basis: Jonathan Rosenberg, Rohan
Mahy, Francois Audet and Roni Even expressed the opinion that this is a
useful feature, but didn't show great enthusiasm. Jonathan noted that
RFC 3264 does talk about this already, and wondered how much generality
is needed: this is "a little bit ugly, but not broken". Not sure we need
to put too much effort in here; we have a workable band-aid already.
Req-20 "MUST be possible to indicate and negotiate alternative attribute
values on a per media stream basis": Magnus Westerlund wondered why this
is needed on a per-media stream basis, rather than describe capabilities
in a more general fashion? Not clear that capability exchange should be
done in SDP offer/answer at all; use a better protocol. John Elwell saw
a need for alternates, but not sure about on a per-media level basis:
what about session-level? Stephan Wenger noted that if you want to
capture even a small amount of the power of H.245, you need this.
Req-30: (as with req-20)
Req-40: (no objections)
Req-50: (no objections)
Req-60: (people don't seem to think this is important)
Req-70: (people don't seem to think this is important)
Req-80 "MUST be backwards compatible with SIP and RTSP": Magnus Westerlund
was not sure about the inclusion of RTSP, since there's no SDP negotiation
in RTSP.
Req-90: Steve Casner was not sure about the need to be backwards compatible
for all protocols. It might be acceptable to have a solution for SIP with
offer/answer, but not for all, to ease the constraints?
Req-100: Both Magnus Westerlund and Jonathan Rosenberg expressed doubt
that this is possible, thinking that at least 1.5 RTT will be needed.
Req-110: (no objections)
Req-120: Jonathan Rosenberg wondered how does this would work with early
media?
Req-130: (no objections)
Req-140 "SHOULD be efficient in terms of message size": Jörg Ott was
not sure this was important, given the size of existing SDP messages.
Magnus Westerlund and Colin Perkins noted that caching and compression
could be used to reduce the impact of message size. Tom Taylor noted
that MEGACO specified a binary protocol for this reason, and is worried
about message size. Others supported this concern: keep it small, if
possible.
Req-150: (no objections)
Req-160: (no objections)
In conclusion, Magnus Westerlund wondered about the implications of the
work, since there is a claim to want to avoid the complexity of SDPng,
yet the discussions are in that space. Jonathan Rosenberg expressed the
opinion that backwards compatibility would kill SDPng, even if the full
set of features it provides might be useful, and that we should do
something simpler. He is unconvinced that more than profile negotiation
is needed, though. Cullen noted that it's easier to do a blank-sheet
solution, but we don't have a viable migration plan, so this will need
to be an ugly incremental solution.
To summarise: there is interest in this work, especially to solve the
urgent security negotiation problem. We should move quickly.
Signalling of media decoding dependency in SDP
draft-schierl-mmusic-layered-codec-00.txt
Thomas Schierl gave an overview of the draft on signalling dependencies
for layered media codings, such as SVC. There was no discussion.
Security Descriptions Extension for IPsec
draft-saito-mmusic-ipsec-negotiation-req-02.txt
draft-saito-mmusic-sdes-ipsec-00.txt
Makoto Saito presented work on using sdescriptions as an alternative to
IKE to negotiate IPsec keying material. Eric Rescorla was of the opinion
that this idea is "fundamentally misguided": the reason IKE is complex
is because people want to negotiate complex things, he doesn't see that
this will simplify or provide useful synchronisation with the media
session. Also the proposal you make requires deployment of S/MIME which
is "less than total", limiting the viability of this proposal.
Dan Wing proposed an alternative scheme, using a certificate fingerprint
in SDP to bootstrap IKE setup. It would be useful if discussion of this
alternative could occur on the list.
SDP Offer/Answer Mechanism to Enable File Transfer
draft-garcia-mmusic-file-transfer-mech-00.txt
Miguel Garcia updated the group on a set of SDP attributes to allow file
transfer sessions using MSRP. Steve Casner wondered if having all these
as separate attributes a good approach, rather than defining a single
new attribute? Not clear we need to use so much of the attribute space.
There was some discussion of using content-indirection, but is was
clarified that this is solving a different problem.
There was general agreement that this is reasonable, and should become a
working group item (subject to chartering).
Multiple aggregated control URIs for RTSP
draft-einarsson-mmusic-rtsp-macuri-00.txt
Ingemar Johansson's presentation on multiple aggregate control URIs for
RTSP was cancelled due to lack of time.
Controlling FLUTE sessions with RTSP
draft-lohmar-mmusic-rtsp-flute-00.txt
Ingemar Johansson's presentation on controlling FLUTE with RTSP was also
cancelled due to lack of time.
- + -