---
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- IETF#70 Meeting Minutes
--- Tuesday, December 4 2007 from 13:00-15:00
--- Thursday, December 6 2007 from 9:00-11:30
--- ============================================================
Reported by Jean-Francois Mule
based on notes from the chairs
The MMUSIC WG met twice at IETF#70. The meeting was chaired by
Joerg Ott and Jean-Francois Mule. The sessions were attended by
about 100 participants.
1/ Introduction and progress report
The chairs presented the agenda and thanked Colin Perkins who has
recently stepped down as an MMUSIC co-chair.
Joerg Ott thanked Colin for his considerable work as a chair since
Dec 2, 2000 (IETF#49), providing numerous contributions in his
architectural, education and administrative role. A big thank you
to Colin for a great guy and great contributions (clap of hands).
A brief status update as of Dec 4 2007 followed:
- RFCs Published:
draft-ietf-mmusic-securityprecondition-04 -> RFC 5027
- RFC Editor Queue:
draft-ietf-mmusic-ice-19
- Close to Publication:
draft-levin-mmusic-xml-media-control-12
- Passed WGLC
draft-ietf-mmusic-sdp-capability-negotiation-07
draft-ietf-mmusic-qos-identification-00
- WGLC Upcoming
draft-ietf-mmusic-file-transfer-mech-05
Regarding SDP parameter registrations for DTLS
(draft-fischl-mmusic-sdp-dtls-03), it was proposed that the SDP
registrations and relevant text be moved into the AVT DTLS SRTP
Internet-Draft (draft-ietf-avt-dtls-srtp-01.txt). Keith Drage
noted that the agenda slides have a typo: the draft in question is
draft-fischl-mmusic-sdp-dtls-03 and not
draft-ietf-sip-dtls-srtp-framework-00.txt.
There were no objections to the above proposal.
Joerg noted that pending one more revision
draft-ietf-mmusic-connectivity-precon-03 should move forward.
For agenda details, see file named mmusic-0.pdf
2/ SDP media capabilities Negotiation
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-02.txt
Roni Even presented the I-D update and open issues. About 10 people
have read the draft (see slides for details on history and -02
changes).
Christer Holmberg asked a clarification question regarding latent
configurations regarding the difference between latent configs and
receiving an m= line with port=0 or bw=0. Roni indicated that it
is different and the text is clear: the receiving agent does not
need to do anything with such configs and re-negotiation is
required to use such latent configs in order to send an actual
offer.
The open issues were reviewed:
- bandwidth attribute only defined as a media level attribute
as opposed to session level
- any need for supporting a media level attribute in latent
configs?
There were no specific comments on the above-mentioned open issues.
Flemming Andreasen raised a more general comment on the scope of
the document and whether another look at requirements would be
beneficial to understand the problem solved. Examples include
layered codecs and how much flexibility is needed in the
framework.
It was agreed that such a discussion on scope/reqs should take
place on the list and the outcome should be documented in the ID.
3/ Source-Specific Media Attributes in SDP
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-source-attributes-00.txt
Jonathan Lennox presented the update to the source-specific media
attributes draft.
Colin Perkins commented that this ID is ready for working group
last call. There was no objection and the chairs will add it to
the list of drafts that need to go through WGLC.
4/ An SDP Extension for Media Loopback
http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-07.txt
On behalt of Keynam Hedeyat, Joerg Ott presented the media
loopback extensions for SDP as part of the agenda bashing.
Based on a comment from Colin Perkins on the list, this draft
needs an IANA consideration section given it is registering new SDP
params.
Pending an update, we will proceed to WGLC on this draft too.
5/ Multiple Packetization Times in SDP
http://tools.ietf.org/html/draft-garcia-mmusic-multiple-ptimes-problem-01.txt
Marc Willekens presented the problem statement for multiple ptimes.
Francois Audet pointed out that the slides only show the answers to
some questions asked to various groups (codec experts, SDP
implementers, etc.) but they do not list the actual questions.
Colin Perkins insisted on the original intent of the RTP design and
the intelligent endpoint model which seems to have been lost
(endpoints should cope with 2 frames in one packet and give two
buffers to the codec).
Joerg asked if the issue is more related to de-jitter buffer
management linked with ptime rather than ptime itself. Steve Casner
underlined the importance of network characteristics when talking
about the receiver de-jitter buffer. Steve questioned the validity
of an mptime solution: what is the likelihood of having senders that
can comply with what the receivers expect.
Robert Sparks discussed what he sees at the SIPit interop events:
some implementations have silicon that receives media and ptime is
passed as a parameter to the silicon. When media is received that
does not match the ptime, the silicon drops the packets.
Joerg commented that this particular case prompts for jitter buffer
mgmt on the receiving end. Colin added that may be recommendations
should be given to folks who build RTP receivers (need de-jitter
buffer function and RTP packet payload splitter into codec
buffers).
Based on comments from Christer Holmberg and Francois Audet, the
debate was repositioned to the needs of expressing packetization
times per codec (as opposed to have one ptime for multiple codecs
expressed in the m line).
Christer and Francois indicated that based on the feedback from the
implementers that they are indeed problems, something should be
done.
Colin reminded everyone that ptime was meant to be a hint to the
sender to try to meet the receiver's preferred ptime in the context
of multicast when RTP was designed. It was not intended to be
negotiated (RTP pre-dates SIP and Offer/Answer). It may not be
what people want from it now.
There was more discussions trying to categorize the set of problems
related to mptime. There might be multiple answers to the distinct
issues presented:
- some issues do not seem to be technical spec problems, but
seem to be solvable via implementation guidelines
- some issues are related to the use of ptime as a new
parameter expressed on a per codec basis (new usage or just
new semantic).
We need to understand both set of issues better.
Robert Sparks requested support from folks involved in the codec
space who understand ptime to engage more directly with the
implementers to find out about the use cases.
6/ Signaling media decoding dependency in SDP
http://tools.ietf.org/html/draft-ietf-mmusic-decoding-dependency-00.txt
Thomas Schierl covered the update to the draft allowing the
signaling of dependency of media decoding in SDP.
Thomas raised one open issue discussed during the AVT session at
IETF#70: the indication of RTP timestamp offsets may be needed per
media stream to allow for media packet reordering based on the RTP
timestamp.
Colin Perkins suggested this new issue be dealt with in a separate
draft. Jonathan Lennox responded he would prefer to address this
issue in this draft. For many layered codecs, it is essential to
tell when a single source packet has been encoded in multiple ways
and this issue helps deal with this requirement.
Colin clarified that while it is indeed needed for the session
multiplexed layered codecs, a solution for RTP timestamp offsets
has broader applicability (e.g. lip sync).
There were no further objections to progressing this draft as-is
and create a separate draft for RTP timestamp offset.
Based on a comment from Roni Even to the list and at the mike,
Stefan Wenger proposed to add some text in the AVT H.264 SVC draft
for how to use this draft to facilitate backward compatibility with
H.264.
Finally, there were no objections to moving to WGLC on this
document.
7/ SDP Elements for FEC Framework
http://tools.ietf.org/html/draft-begen-fecframe-sdp-elements-00.txt
Ali Begen presented a first draft on SDP attributes for the FEC
framework. A longer presentation related to this draft was made in
the fec working group at IETF#70. See draft+slides for details.
Ali requested feedback from the mmusic participants.
Joerg asked if the examples in the draft could be added to the next
revision.
Colin commented on the use of the SDP namespace and the use of
"fec/" for all protocol element names. It is unclear whether this
is right to do for all of them - need more thinking.
More generally, we should think about a logical naming convention
for SDP attributes.
Stefan Wenger believes there is overlap and commonality between
this draft on SDP attributes for FEC and the media decoding
dependencies ID (draft-ietf-mmusic-decoding-dependency-00).
There are gaps between the 2 drafts, for example in the indication
of the relationships between sessions (either layered or partial
ordering relationships in decoding dependency). Some functionality
would have to be added to meet fec framework requirements on
expressing those relationships.
The chairs asked Ali and the authors of
draft-ietf-mmusic-decoding-dependency-00 to get together and
make a recommendation for the best course going forward (merge IDs
with more general solution, keep them separate?).
8/ RTSP Asynchronous Notification
http://tools.ietf.org/html/draft-stiemerling-rtsp-announce-00.txt
Martin Stiemerling who accepted to be the new editor for RTSP 2.0
presented a proposal to add asynchronious notifications to RTSP.
See slides for details.
Dave Oran asked if this method could be used for redirecting a
client from one server instance to another in a graceful manner
(client redirection). Martin answered that he believed redirect is
the proper method for client redirection and Dave asked why we
should not use redirect for everything.
Magnus Westerlund did elaborate on 3 different "semantics":
- end of stream: notification of end of stream; Magnus
believes we should have this, may be even in as an explicit
method due to implementers. There was additional support
for having this kind of notifications. Magnus asked if
there was any objection in proceeding with a draft on this -
no objections were raised.
- "session-type" notifications: "sorry, cant serve you anymore":
Magnus thinks RTSP redirect gets things done and works.
- move an RTSP session from one server host to another (this
Internet-Draft). More discussions are expected on the list.
Magnus raised another concern: NAT traversal.
Sean Sheedy added that it is not just NTT that is using extensions
like this proprietary announce. Some cable deployments are using
similar proprietary extensions.
9/ RTSP 2.0
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-16.txt
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-05.txt
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-evaluation-00.txt
Magnus Westerlund covered the updates on RTSP. There was no update
to RTSP NAT and no discussion during the meeting.
On RTSP, the open issue around the scale and speed headers
generated some discussion.
Henning Schulzrinne commented that these 2 headers are not quite
coupled (one is about how the timestamp moves in RTP, the other is
the RTP timestamp).
The cases presented by Magnus on slide 6 need more discussion on
the list (folks who have proposed the speed header were not
present). Henning added that this is an important feature that
should be addressed (independently of where it goes in the document
or separate draft).
See slides for the remaining of the presentation. The plan is to
advance some of these issues on the list with a target completion
of RTSP 2.0 at the end of 2008.
10/ IPv6 Errata in SDP RFC 4566
Colin Perkins indicated that during the SIP essentials correction
process, an error was found an error in the aBNF for IPv6 which is
also present in SDP RFC 4566.
It was agreed that Colin will submit:
- an update to RFC 4566 including the fix
- an errata against RFC 4566 to increase the likelihood of
folks finding the error.
Cullen Jennings provided some information on the new errata
process: folks should be able to put in an errata and get it
approved fairly quickly (in a matter of a week or two).
11/ ICE TCP
http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-05.txt
Jonathan Rosenberg presented the few changes in draft 05 of ICE
TCP.
The discussions centered around the big open issue related to the
lite implementation for ICE-tcp.
It can be made to work but it is not easy and ICE-TCP full has
better security properties.
Jonathan asked for input: do folks want ICE TCP lite?
Remi Denis-Courmont brought up the issue of 3pcc interacting with
co-media which can cause issues for ICE-tcp (if both sides indicate
active or passive, it's broken). If the 3pcc controller modifies
the SDP, then Jonathan suggested to set actpass in the offer.
Otherwise there is no issue.
Folks asked why we are complicating the implementations of ICE-TCP
with a lite implementation and what delta is imposed to full
implementations when talking to lite ones.
Christer Holmberg invoked 3GPP and B2BUAs. Ted Hardie expressed a
concern about putting forward a solution for ICE TCP lite that can
only be applicable to certain topologies. Jonathan indicated that
are various other cases where this could be useful (streaming media
a la RTSP over TCP or any TCP-based content). There should a
warning that if this is only applicable to certain topologies.
Based on comments from Ted Hardie and Jonathan Lennox, it appears
that the additional complexity for a full implementation to support
lite should be minimal (one flag?). If that is confirmed, it would
advocate for separating ICE lite into a separate draft. Jonathan
Rosenberg will consider this input in the next update.
Remi asked what does it buy an implementation to use ICE TCP lite
as opposed to using plain old comedia?
If it is used for TCP-based media (and not to add TCP candidates
in Offers that have both udp and TCP candidates), then using plain
comedia is adequate. TCP has connectivity checks so there is no
need for ICE ones. The proposal would then be to have the B2BUAs
indicate that ICE TCP is not supported and fall back to comedia.
Christer has commented that it is an option as long as the ICE TCP
spec clarifies the difference between ICE UDP and ICE TCP on the
handling of cases where there is no ICE support (UDP: do nothing,
TCP: fall back to comedia).
Keith Drage indicated that 3GPP has decided to have ICE (as an
option) but 3GPP has not made any decisions on whether to use ICE
full or lite for TCP streams.
Jonathan summarized the various options discussed during the
mmusic session:
1) make ICE lite TCP a separate document
2) specify that if you want to do ICE TCP lite, fall back to non
ICE comedia with the exception that it does not disable ICE
for UDP streams
3) continue to work on ICE lite in this document
4) do nothing.
More considerations and discussions are required. Jonathan will
post a note on this.
Philip Matthews brought up a concern: the method that ICE TCP
currently uses has a 40% chances of succeeding according to some
publication. The paper in question recommends a different method
of punching holes which would improve the mechanism. Jonathan and
Philip should get together and provide details on the list.
12/ Analysis of Middlebox Interactions
http://tools.ietf.org/html/draft-sipping-stucker-media-path-middleboxes-00.txt
Hannes Tschofenig and Brian Stucker introduced a document that
originated from the work done on DTLS SRTP. It provides an
analysis of middlebox interactions for signaling protocol
communications along the media path.
Folks expressed support for having such a general document
providing recommendations/guidelines to both middleboxes and
authors of signaling protocols along the media path.
There was considerable discussions and interest from the WG to
progress this document. There were no objections to making it a
working group document (may be informational, may be BCP). The
chairs will it a proposal to the AD after talking to the authors
about the exact milestone.
13/ Media Description for IKE in SDP
http://tools.ietf.org/html/draft-saito-mmusic-sdp-ike-02.txt
Dan Wing presented an update to media description for IKE.
SDP-IKE was presented in SIPPING and there was a valid use case -
see slides for details.
Hadriel Kaplan asked if UDP encapsulation of IPsec ESP packets could
just be used: is there a need for the native IPsec that does not
work through NAT. Dan answered that there are NATs that do
support IPsec passthrough mode and there were requests to support
native IPsec ESP. EKR supported the removal of native IPsec support.
Colin Perkins: SDP requires that the format of UDP protocol is
name/sub-type and the current draft format does not seem to follow
those conventions. Dan recognized IANA registration would be
required.
Dan York questioned if this application of IPsec should be
addressed in the RAI area instead of elsewhere given it is a
generic VPN initiation.
Based on a question from Joerg, Mary Barnes - sipping co-chair
clarified that the SIPPING working group had no objection to the
idea proposed in this draft and folks in SIPPING asked this draft
to be presented back in sipping.
Gonzalo Camarillo indicated that in the SIPPING wg, 3 reviewers
were assigned and none thought it was an unreasonable use. As an
individual, Gonzalo thinks it is useful.
Jon Peterson asked if this draft was out of scope of the
considerations for rtpsec. Dan answered that yes, it could secure
any traffic (RTP and anything).
Hannes Tschofenig referenced some work in HIP that could serve.
Cullen Jennings - AD stated that if we decided to do it, then
defining the SDP params is clearly in scope of MMUSIC. The
question of whether to decide to use SIP this way is outside this
working group.
Jon Peterson added that it is unclear whether the definition of a
SIP session does mean something like an IPsec connection.
Ted Hardie proposed to organize a BoF on this topic. The idea of a
BoF was supported by Francois Audet, Jonathan Rosenberg, Dan York
and others.
The meeting concluded.
> end.