--- ============================================================
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- DRAFT Minutes for IETF#75 MMUSIC WG Meeting
--- Thursday, July 30, 2009 - 9:00 to 11:30am
--- ============================================================
CHAIRS: Joerg Ott <jo@acm.org>
Jean-Francois Mule <jf.mule@cablelabs.com>
The MMUSIC WG met on July 30 at IETF#73. The session was attended
by 57 participants. The meeting was chaired by Joerg Ott and
Jean-Francois Mule and the minutes are reported by Jean-Francois.
1/ Introduction and progress report
Joerg and Jean-Francois presented the progress since the last
meeting.
- 3 RFCs were published since March 2009:
RFC 5547, RFC 5576 and RFC5583
- ICE is still in the RFC Editor queue and publication has
been requested for connectivity preconditions and RFC
3388bis.
- The capability negotiation draft received comments from IESG
and needs revision.
- The media path guidelines for middleboxes WGLC is complete
and the ID needs an update
- 3 I-Ds are in the queue for WGLC request (RFC4756bis, sdp
media cap and image attributes after an udpate)
- ICE TCP has not been updated and Simon Perreault who is the
new editor plans to issue a revision after IETF.
- Hadriel Kaplan volunteered to work with the authors of the
media loopback ID to complete it and go to publication
request by October 2009.
See slides for more details. There were no comments or questions
from the Working Group on the progress report.
1) RTSP-related Drafts
1.1. RTSP 2.0
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22
Magnus Westerlund presented an update on the latest RTSP draft. See
slides for details on the changes. Two versions of the
Internet-Draft were posted between IETF 74 and IETF 75. The one
open issue is to update the "changes since RFC 2326" section.
The authors believe the document is in good shape for working group
last call. There were no comments on the plan to launch WGLC in
September for 4 weeks.
The following people volunteered to be reviewers during WGLC:
Ingemar Johansson, Jeff Goldberg, and Ye-Kui Wang (thank you).
1.2 RTSP NAT
http://tools.ietf.org/html/draft-ietf-mmusic-rtsp-nat-08
Magnus Westerlund presented the draft updates on RTSP NAT. The
document received feedback from implementers.
There was consensus to go to WGLC after RTSP/2.0.
1.3 Fast Content Switching with RTSP 2.0
http://tools.ietf.org/html/draft-einarsson-mmusic-rtsp-macuri-02
http://tools.ietf.org/html/draft-lohmar-mmusic-rtsp-fcs-00
Thorsten Lohmar presented RTSP extensions to support Fast Content
Switching. There are existing extensions defined in 3GPP for RTSP
1.0 and the goal of this work would be to define extensions in IETF
for RTSP 2.0.
Joerg Ott asked how RTSP session parameters could be reused across
streams in the context of multicast. Thorsten answered that the
scope of the current ID is unicast and with unicast, channel change
is faster if you use these RTSP extensions.
On slide 7, Joerg commented that the proposed solution presented in
the examples looks "unhealthy" because various feature parameters
including SDP are put into one header line (it seems like the
DESCRIBE message is encapsulated in PLAY).
Thorsten indicated that this point was discussed in the past and
given the number of SDP descriptions for video services like
YouTube, the current direction is to not do DESCRIBEs to reduce the
number of transactions.
Jean-Francois noted that the examples show the 3gpp tags and
their particular syntax. It would be benefitial to discuss the
parameters required for fast channel switching first, then figure
out how to convey them in the protocol.
In the jabber room, Martin Stiemerling asked if the proposal is
aligned with the RTSP/2.0 state machine where you can use PLAY
on new URIs without SETUP first.
Based on questions from Wolgang Beck (via jabber), there was a
discussion on whether this work is required given the client has to
wait for an I-frame for the new content channel.
Brian Rosen responded that there is work in AVT in reducing the
delay related to the I-frame and there is enough experience in 3GPP
that this mechanism actually helps.
Ye-Kui Wang indicated the issues related to the I-frame may be
different than what is being addressed in AVT since the action is
done by the server (the server may know where the I-frame is before
starting channel change).
Joerg pointed out that there is an assumption in the mechanism that
the new SDP offer is going to be compatible (no DESCRIBE fetching).
It implies that the client makes some assumptions.
Thorsten agreed this is an open issue, even though the server
could know what the client can support.
Joerg added that if the server has multiple codec options, a SETUP
might help for the client to choose from.
Jeff Goldberg asked how this mechanism works with the RTSP NAT
draft given the exchanges. We need to consider how the two
mechanisms could work together. Thorsten indicated that there
should be little impact but further analysis is indeed required.
In summary, based on the discussions at this IETF#75 meeting, there
is WG interest in progressing this work on the mailing list and see
the Internet-Draft updated to address the feedback.
1.4 SIP-SDP Overlap with RTSP
http://tools.ietf.org/html/draft-lindquist-mmusic-sip-rtsp-00
Jan Lindquist presented a draft on how the session related
information could flow between SIP and RTSP session controllers.
Jan indicated that ETSI TISPAN, 3GPP and the Open IPTV Forum are
working on this topic.
Hadriel Kaplan asked what "session management protocol" refered to
in the slides and whether it could be somethink like SIP without
media description.
Hadriel asked whether this work proposal should potentially go to
DISPATCH given it goes beyond MMUSIC. Hadriel expressed support
for this work.
Tom Hiller expressed some concerns about the claim that OMA is
working on this topic. Tom said that this was discussed in OMA and
rejected. Tom indicated that RTSP should be left intact given the
client implementations.
Joerg suggested that Tom puts an email to the mmusic list to
explain what OMA did to solve the requirements.
Xavier Marjou expressed support for this work. There are people
that use both SIP and RTSP and there is no work in IETF to make the
2 protocols work together. It would be good to take on this
work.
The chairs polled the room for interest in this work (13 peple
interested, 5 opposed to do work on this).
Dave Oran added 3 options that could get support in MMUSIC:
a) stop RTSP 2.0 and step back to redefine it to meet the goals
defined here
b) designing new media control protocol inside a SIP session
(put the PLAY controls in SIP)
c) create an MRCP sub-set
All of these would allow to use SIP to do media streaming server
operations. Jan indicated this is good input.
Gonzalo Camarillo agrees with Hadriel that this might be best
discussed in the DISPATCH working group.
The chairs concluded that more discussion is needed on this topic.
2) SDP Attributes
2.1 SDP Connectivity Capability (CCAP)
http://tools.ietf.org/html/draft-boucadair-mmusic-ccap-00
Hadriel presented an Internet-Draft to solve some IPv4-IPv6
interworking issues.
There were questions and comments about the characterization of the
problem (slide 2).
Cullen Jennings and Francois Audet commented that there is an
implication that there are a lot of things broken, and the problem
statement is exagerated.
Cullen Jennings, it was pointed out that the WG decision to fix
IPv4-IPv6 connectivity declarations in SDP was the ICE protocol.
Xavier Marjou would like to do IPv6 in the very short-term with
this draft, and perhaps this is an informational or experimental
document, not standard-track.
There were several questions and comments on the subsequent slides:
- the c line in O/A does not need to have the same address
family (Roni Even)
- you have to do a re-INVITE since the answer should have the
same c line (Dan Wing)
- Capabiliy negotiation is "messy" and having two mechanisms
would be even worse - the garcia draft to negotiate c lines
is a potential solution (Christer Holmber).
The garcia draft has been proposed as a WG item based on
IETF#74 (Roni).
- This is a special case of capability negotiation (Roni Even)
but capneg is too complicated (Hadriel Kaplan)
- This problem could be addressed based upon the garcia draft
(Simo)
- We always start out simple and it gets complex. We will need
to implement all of this in the end process: we did discuss
and agreed on a solution (Francois Audet)
- The motivation is to do a "super-ice-lite mechanisms" -
ICE-like negotiation without the connectivity checks.
- This is a strategic direction we make for the wg (Gonzalo)
- We should spend energy on solving generic SDP capability
negotiation (Ingemar)
There were additional comments from Roni, Jonathan Lennox, Derek,
John Elwell and Christer Holmberg.
In summary, the discussions asked:
- how difficult would the solution be if it were to rely or
build on capneg and draft-garcia?
- how different is it from a solution re-using ICE?
There was no consensus on this draft but many questions and
comments recommending to re-use the tools that are available in
MMUSIC including SDP Cap Neg and its extensions like the garcia
draft for the c= line, ICE and new semantics to make this work.
2.2 SDP Attribute for Maximum Media Sources
http://tools.ietf.org/html/draft-lennox-mmusic-sdp-max-sources-00
Jonathan Lennox presented a new draft on max media source count.
Based on a comment from Dave Oran, the upper bound limit for
maxbound should be 2^32-1 (unlimited).
Christer asked how does the user know whether the media comes from
different or a single source. Jonathan clarified that the use only
cares whether media comes from a different SSRC: there are
different buffers for playing media so the question is whether the
endpoint supports more than one simulatenously. It has nothing to
do with forking.
Gunnar Hellstrom sees good use of this mechanisms; he submitted a
draft on text conferencing indicating that it can use multiple
SSRCs.
Hadriel added a few comments on SSRCs and their handling by SBCs.
The take-away from the WG discussions is that the ID should progress
and it should integrate more information about SSRC handling.
2.3 Media Source Selection in SDP
http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selection-00
Jonathan Lennox introduced his draft allowing media source
selection in SDP. There is potential IPR on this draft, check the
IPR disclosure.
Based on a discussion with Jonathan, Alan Johnston, and Roni Even,
there was consensus that this work should continue in MMUSIC and
also be presented and discussed in XCON given the related SIP/XCON
conference package.
There was a question about how to associate a media stream with a
certain SIP dialog when forking for example. Jonathan answered
that RFC 5576 should be sufficient on its own for that.
The chairs asked how many people are interested in this work by a
show of hands: 7 people.
2.4 SDP Extensions for audio over PSTN CS bearers
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-01
Simo Veikkolainen presented an update on the above ID to integrate
comments from John Elwell.
The chairs asked for reviewers to send comments to the list.
Cullen Jennings commented that this revision looks good.
Given the meeting time constraints, Peter Fassberg had a few
comments that should be discussed after the meeting and sent to the
list as needed.
2.5 Misc Capability Negotiation in SDP (Simo Veikkolainen, 10)
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-01
Simo Veikkolainen indicated there were no technical changes in this
revision.
Hadriel Kaplan asked about the motivations of bundling the bundle
i= and b= parameters. This should be clarified on the mailing
list. Simo indicated that the goal was to be exhaustive on other
SDP attributes.
Hadriel Kaplan and Mohamed Boucadair raised questions about why
comments expressed on the ccap draft presented earlier in the
session do not apply to this draft.
Jean-Francois clarified the motivations for this draft (ability to
have capability negotiation for the c line), and that this has been
discussed on the list and in previous meetings.
More discussion should continue on the list re: ccap and how the
requirements or solution relate to this Internet-Draft.
The meeting concluded.