---
--- ============================================================
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- DRAFT IETF#73 MMUSIC Meeting Minutes
--- Monday, November 17, 2008
--- ============================================================
The MMUSIC WG met once at IETF#73. The meeting was chaired by
Joerg Ott and Jean-Francois Mule. The session was attended by
about 93 participants on Monday morning.
Minutes reported by Jean-Francois Mule
1/ Introduction and progress report
See the chairs' slide for the progress report and details, the
notes will record the main discussion points, open issues and
proposed resolutions. Joerg presented the wg status update.
Regarding media loopback (draft-ietf-mmusic-media-loopback-09),
there were some comments sent to the list that need to be answered
by the authors before the draft can advance.
Joerg Ott asked if anyone wanted to volunteer to review the
connectivity pre-condition draft (there were little comments
during WGLC).
Jonathan Rosenberg commented that if nobody cares about this
document anymore, may be the review is not required. Gonzalo and
a few others commented that some folks are using this draft and it
should continue to progress.
Jean-Francois Mule gave the update on SDP capneg on behalf of
Flemming Andreasen who could not attend the MMUSIC WG meeting.
Besides the ART and security review comments, we specifically
discussed the last call comment raised by Christer Holmberg and
Ingemar Johansson on how to allow the O/A exchange to be done in
two-stage process to accommodate middle boxes.
Flemming did summarize the options on the list, on October 16,
and three possible ways exist for accommodating this O/A exchange
requirement that do not require a change in the draft that went to
last call.
Christer Holmberg and Ingemar were present at the meeting.
Christer made comments and asked if anyone else had issues with the
current draft and did not want to wait for SDP Media CapNeg or a
new extension. Noone else commented on this particular issue. As a
conclusion, Jean-Francois Mule reiterated that there seems to be a
WG consensus to proceed as-is. Noone objected.
Christer added that he sent additional comments to the list re:
capneg in a forking scenario. We re-hashed the comment made by
John Elwell on the list (SDP cap neg adds nothing new, when
offered, an agent must be prepared to honor all alternatives).
The main action item is to ensure that the draft does not assume
that forking may never occur.
=> Action Item: Flemming to check the draft is consistent with the
way forking works in that an agent proposing alternative
configurations must be prepared to honor all of them due to
forking, or put a note to that effect.
Roni Even pointed out that the SDP Media CapNeg latent
configuration mechanism. It allows an agent to effectively not
offer all alternatives, and therefore give some flexibility if
needed.
Finally, based on the WG consensus, the chairs proposed that the
publication of SDP cap neg ID should progress as-is and without
re-opening the above-mentioned comment (pending a few changes based
on ART, Security and thread comments and nits).
Joerg Ott has asked for reviewers for two drafts:
- SDP cap neg:
The goal is to finish this document by IETF#74 in San
Francisco. Roni Even and Bob Gilman have received limited
feedback. Roni added that a new version will come after the
meeting. Please volunteer to review the document.
- RTSP: any reviews are appreciated.
The tentative interim meeting in Malta was discussed during the
meeting and has been canceled as of the writing of these notes.
2/ SDP image attribute
http://tools.ietf.org/html/draft-johansson-mmusic-image-attributes-02
Ingemar Johansson presented the revised draft for describing image
attributes in SDP (see slides for details).
Jonathan Lennox asked if the negotiation of an image size is
effectively binding the agents. For example, if something changes
mid-dialog, do you need to renegotiate or a new O/A exchange?
Ingemar confirmed the intent is to express a preference or to
advise the remote party of a suited image sized.
Jonathan Lennox asked how this would interact with multiple sources
in a session (e.g. sdp-source-attribute and more than one video
streams in an RTP session).
Ingemar indicated that it is not taken into consideration and the
draft should clarify this.
A comment was made about the text contained in the draft that
implies a second O/A exchange is not required. Ingemar agreed the
text should clarify what it means when a second O/A has to be sent
(are the attributes omitted? left as in the first O/A, etc.).
When ranges of values are allowed in the syntax, someone questioned
if any integer in the range must be supported. The draft should be
clearer on this.
The WG chairs took a hum and there was no objection to
propose this document as a working group item. WG chairs will
follow-up with the ADs.
3/ Middlebox Interactions for Signaling Protocol Comm. along Media Path
http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-01
The chairs asked if people were still interested in this work.
Seven participants raised their hands and a few committed to
provide review comments on the current draft.
4/ ICE-TCP as an Extensible Framework
http://tools.ietf.org/html/draft-lowekamp-mmusic-ice-tcp-framework-00
Bruce Lowekamp presented the draft he and Adam Roach put together.
This draft was initiated after the Dublin meeting to provide input
on the techniques that exist to improve ICE TCP's success rate for
direct connections and to provide a framework for integrating new
ones in the future. See slides for additional details.
Bruce commented that Apple and most Bittorent clients he knows
support UPnP IGD and NAT-PMP.
Based on a question from Jonathan Rosenberg, Adam Roach indicated
that Teredo gateways exist for things like IPv4/IPv6 and therefore
Teredo may not be required on both ends. The ID proposes to require
an IPv6 address in some ways even if the local network does not
support (and Toredo is one of them).
Remi Denis-Courmont raised a concern with tunneling: one pb with
tunneling is how do you know your IP address of the server to the
outside? NAT-PMP will tell you the IP address of the other side,
SSH will not.
Adam Roach confirmed that indeed, you can have situations where
the allocated allocated is different that the one you think and
this is why you apply ICE and connectivity checks.
Additional comments were made that should be sent to the list.
Jonathan Rosenberg indicated that he fully support this draft and
that it should define a minimum set of client requirements.
Remi Denis-Courmont also voiced support for the draft.
Ted Hardie expressed some concerns and recommended that the
document contains some normative requirements for techniques that
MUST be implemented to get the implementers closer to something
working. Dan York agreed with Jonathan and Ted's comments.
Bruce proposed we start with UPnP IGD, SOCKS, NAT-PMP and
Teredo.
Ted asked what success rates that would give us.
Jonathan and Ted commented that if Teredo works, why are the
other techniques required?
Cullen Jennings added that we need to collect some data (partial
data exists with those 4 techniques) and the date should include
the type of latency they introduce.
Markus I pointed out that some techniques like Teredo do not
typically work in corporate networks while SOCKS does.
Adam Roach concluded the responses to those questions by taking
Skype as an example: "Skype does a zillion of things and sees
what works." This is what Adam and Bruce have proposed here and
they believe the only way you can do this is to have an open
ended framework.
Additional comments were made by Jonathan Rosenberg, EKR, Stefan
Wenger, Ted Hardie, Markus I, and others about how many techniques
should be required, whether or not having more than one is
important, and why not mandate all four (UPnP IGD, SOCKS, NAT-PMP
and Teredo). There was no clear consensus on which way to go and
some argued the next step is not to impose some level of
requirements but just work on the framework, integrate it with
ICE and list the techniques.
There was WG consensus to merge this framework proposal with ICE to
create a new ICE TCP document.
5/ ICE TCP
http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-07
Jonathan Rosenberg presented on the TCP-SO issue.
During the meeting, there were some divergent opinions on what
popular OS versions support it or not (we still don't seem to have
a verified statement on what OSes do and don't work).
Jonathan proposed to keep it in ICE-TCP and only use it if supported.
Adam Roach stated that TCP-SO supposedly works with Windows Vista
and insisted that ICE-TCP should not mandate something that may not
be needed on some OSes.
Cullen Jennings commented that for soft phone applications, XP may
be the least important OSes for mobile phones or other CPE devices.
More implementation and real experience is required. Jonathan
asked for people interested in helping to manifest themselves to
help.
6/ RTSP
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rfc2326bis-19
Martin Stiemerling presented the updates on RTSP (see slides and
sourceforge links for the open issues and the closed one).
Remi Denis-Courmont made a comment on the multicast slide (RTSP
SETUP with multicast). Based on the three options proposed for
conveying the multicast address in the slide, Remi believes option
1 is the way to go: have the client pick the multicast address and
communicate it in the dest_addr field.
Remi asked if any clients implement cache-control in RTSP. Please
send some responses or information to the list if you know.
Martin asked what to do about the Speed and Scale headers.
Jean-Francois Mule summarized his understanding of the conclusion
of the MMUSIC interim meeting in May 2008 where this was discussed
at length. He believes the meeting concluded at the time that both
parameters had found some semantics that folks were happy with. He
committed to send some input to the list and review proposed
definitions.
Magnus concluded that the goal before the next MMUSIC meeting is to
try and solve the issues on the mailing list if possible.
7/ SDP Extension for Circuit-Switched Streams
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-cs-02
Simo Veikkolainen covered the update on the SDP Extensions for CS.
There was agreement in Dublin to split the document into two,
describe the SDP parameters in one document, and then describe all
SDP capability negotiation related considerations in another
document. See slides.
The open issue of correlating the CS call with the signaling using
the DTMF was discussed.
Jonathan Rosenberg is in favor of adding the ability to correlate
the CS call with some reliable mechanism even if it enduces call
set up delay (as long as it works reliably).
Adam Roach proposed the use of the DTMF as a correlation element
and he commented that correlation using DTMF could be used in cases
where other ways fail. Adam pointed out that this optional
functionality could provide a useful property in the signaling.
Dan York relayed some comments from Jabber from folks asking who
will implement this?
Simo concluded the discussion: the authors will add some text in
the next revision of the draft.
There was consensus to make this draft a working group item pending
AD approval.
8/ Miscellaneous Capabilities Negotiation in SDP
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-misc-cap-00
Simo Veikkolainen presented a new draft related to the previous one
proposing to add various capability negotiation to the SDP capneg
framework, specifically for the i=, c= and b= lines.
Joerg Ott wondered about the needs to include the i= line in the
framework.
Bob Gilman (one of the authors) had some use cases for this. Ted
Hardie asked for more details about those use cases be sent to the
list. Simon answered with an example: use of separate camera
views, where the views could be labelled differently and the option
tag and ability to reference those could be useful.
Roni Even responded that there is no semantic for the i= line but
the camera is something that could be conveyed in the content
attribute (RFC 4796).
As for the i- line, Ted discouraged the capability negotiation for
something that is not well defined.
Jonathan Lennox said the ccap looks like ICE "I can use this IP
address with that other IP address". Jonathan noted it provided
less than ICE.
Roni Even asked if this draft will define a new, separate extension
to the SDP capneg framework. Authors should check if this is the
case and make sure the proper IANA section is there.
9/ FEC Grouping Semantics in SDP - RFC4756bis
http://tools.ietf.org/id/draft-begen-mmusic-rfc4756bis-00.txt
Ali Begen presented an update to the RFC 4756 which lacks semantics
for expressing additivity of FEC streams and prioritization (see
slides for the motivations of this feature).
Steve Casner asked how prevalent would the use of multiple repair
flows be? Steve questioned if that was a significant problem.
Ali responded that, depending on the FEC scheme, there are schemes
that can be combined together. And there are FEC schemes that do
not give you much when you add them: the idea is to let the
receiver know this valuable information.
On the prioritization slide, Thomas Schierl indicated that for some
video coding, the prioritization was more of a codec payload
property (see AVC payload draft).
Ali agreed if it can be supported in the payload for FEC (fec-frame
WG question).
Jonathan Lennox raised the potential issue of adding too much
semantric in mid which applies to every group a session may be part
of. Jonathan is concerned that if we start putting semantics for
mids, then resolving these would be difficult. An alternative
would be an a=fec priority session media attribute parameter.
Based on the above comments, Ali proposed that the draft be first
focused on addressing the additivity of FEC streams. The
prioritization of FEC streams may be dealt with in the fec-frame
WG.
Jonathan Lennox pointed out that the SDP source attribute
Internet-Draft has a source group so it would be possible to group
sources within a session. Ali will look at ssrc groups.