Minutes
of the Meeting: MMUSIC working group at IETF 82
========================================================
The
MMUSIC working group of the IETF met at IETF #82 in Taipei, Taiwan. The WG met
on November 18, 2011 from 9 to 11.00.
The
meeting was chaired by Flemming Andreasen and Miguel A. Garcia.
Jean
Mahoney, Christian Schmidt and the chairs took notes. Hadriel Kaplan acted as a
jabber scribe.
This
meeting was broadcast live and recorded by the Meetecho team. The recording of
the session is available at the following URL:
http://ietf82.conf.meetecho.com/index.php/Recorded_Sessions
- fri
Introduction
and Status Update (Chairs)
========================================
The
chairs presented the agenda:
http://www.ietf.org/proceedings/82/agenda/mmusic.htm
No
agenda bashing was needed.
The
chairs presented the status of the working group (see slides):
http://www.ietf.org/proceedings/82/slides/mmusic-7.ppt
Published RFCs since last IETF
------------------------------
No new RFCs have been published since last
IETF meeting.
In RFC Editor
-------------
–
IANA Registration of the 'image' Media Type
for SDP, draft-salgueiro-mmusic-image-iana-registration-09
In IESG evaluation:
-------------------
–
TCP Candidates with ICE, draft-ietf-mmusic-ice-tcp-15.txt
Publication
requested
---------------------
No drafts are
under this category since last IETF meeting.
WGLC
completed, pending of new versions
---------------------------------------
–
An Extension to SDP for Media Loopback, draft-ietf-mmusic-media-loopback-16.txt.
The chairs informed that Hadriel Kaplan has joined the team as editor of this
draft. It was highlighted that there are a couple of drafts in ECRIT that
depend on this one, so the draft should proceed as fast as possible in order to
not block the ECRIT drafts.
–
RTSP 2.0, draft-ietf-mmusic-rfc2326bis-28.txt
Progress
of other work items
----------------------------
–
RFC 4566bis, draft-ietf-mmusic-rfc4566bis-04
Mostly
done, should keep it open for a while in case some additional fixes are needed.
–
RTSP NAT traversal, draft-ietf-mmusic-rtsp-nat-11
and RTSP NAT evaluation draft-ietf-mmusic-rtsp-nat-evaluation-04
Mostly
done, should go to WGLC right after RTSP 2.0.
–
SCTP media in SDP, draft-ietf-mmusic-sctp-sdp-00
Mostly
done, waiting for a minor update. Progressing towards WGLC soon.
–
CS descriptions in SDP, draft-ietf-mmusic-sdp-cs-09
Still
discussing some issues, status later in this meeting.
–
SDP media capabilities negotiation, draft-ietf-mmusic-sdp-media-capabilities-12
Still
discussing some issues, status later in this meeting.
–
The SDP 'trafficclass' attribute, draft-ietf-mmusic-traffic-class-for-sdp-00
Recently
became WG item.
SDP directorate
---------------
The chairs announced the imminent creation
of the SDP directorate. The purpose is to guide and review extensions to SDP
created and discussed outside the MMUSIC WG. Details of the SDP directorate are
being finalized. The final description and details of the SDP directorate will
be posted in the MMUSIC mailing list. The chairs ask the group to contact them
if a new document extending SDP becomes available.
Alternatives to ICE
===================
(Discussion facilitated by chairs)
Flemming introduced the value to
interoperability from having a single standard for NAT/firewall traversal and
IPv4/IPv6 transition, highlighting that ICE is the IETF standard mechanism for
solving those two problems. However, alternative mechanisms to ICE keep showing
up in drafts and discussion. Usually these mechanisms are simpler but also more
limited in scope. The chairs asked for a discussion to understand if there is a
new set of requirements for the two problems that ICE is currently solving and
a need to look into alternative solutions.
Cullen stated that the biggest problem with
ICE is the description and suggested a tutorial on how to understand and
implement ICE.
Hadriel indicated that NAT traversal
problems are solved without ICE in certain service provider scenarios. There
are no interoperability issues with latching mechanisms. There is a market for
both solutions (ICE and latching). Latching is available far longer than ICE
and does not need a standard, because it does not need a specific behavior from
the far end. No problems until the loopback draft showed up. When you make a
loopback call to devices behind a NAT the device behind the NAT does not send
anything out first, because it is a loopback call. However, that is a basic
requirement for all NAT traversal mechanism. You must send packets out first to
create the mapping in the NAT and to open the pinhole. This situation exists
since the last modification of the loopback draft. Proposed Solution: The
loopback call must act as closely as possible to a normal call. Cannot use ICE
for private-network to private-network. Since it is not public Internet, we do
not want to talk about it.
Flemming rephrased HadrielÕs words: Is ICE just
an issue for loopback, or do we need something other than ICE for other
scenarios?
Hadriel explained that nothing is broken we
have to fix. We can have a document describing how latching is working,
something like a BEHAVE document. But because it has no influence to
interoperability he did not know, why we need it. No other issues than loopback
is known for latching.
Flemming asked if outside of loopback we
have a deficiency in NAT traversal.
Hadriel indicated that he is not aware of
other problems other than loopback if we have latching and ICE.
Jonathan Lennox indicated he does not
understand latching. It would be useful to describe it in an informational
draft - this is what we are doing, do not break it.
Cullen described the DOS attack for
latching. An attacker sends spam packets across all the ports of the SBCs which
are easy to discover – IP addresses and ports. The SBC latches the
packets to the wrong places and forwards media traffic – normally not
encrypted – to the attacker. This is the reason, why we have no IETF
draft for latching, because nobody wants to discuss the related security issues.
Implementers do not want to hear about the security issues.
Hadriel stated that he has a rough draft on
how latching works and the security issues. Implementations can take care of
some of the issues, but cannot discuss. The described security problem came up
in latching about 6 years ago. There are some antiscan attach mechanism
available, but not widely used. That are mostly vendor specific proprietary and
secret solutions Hadriel cannot talk about here.
Cullen said that an ID explaining these issues
would be very beneficial, knowing the security properties.
Hadriel will submit an updated version of
this draft. He also indicated that v4/v6 transition is a total other issue.
Should we talk about?
Flemming said that we should keep the
discussion separate.
Simo Veikkolainen indicated that in the
Circuit-Switched descriptions draft ICE is not fitting very well in the PSTN
world. An alternative NAT traversal mechanism would be good for this.
Jonathan Rosenberg (through the jabber
room) asked Hadriel what he wanted to happen. Should the IETF recommend this
practice?
Hadriel reminded that he did not start this
discussion.
Miguel Garcia (Floor): We cannot neglect
the fact that other solutions then ICE are in the market. It would be nice to
have them documented. Why is it useful in which certain scenarios, what is the
security implication, where is it not useful? This would be good information. Miguel
would recommend writing such a document.
Hadriel expressed his concern about the
dependency between the loopback with latching draft. This could delay the
loopback draft for a couple of years. We can recommend sending STUN packets in
loopback case.
Flemming asked for having a separate
discussion on the loopback draft.
Andrew Hutton reminded that at the last
IETF meeting there was a presentation about problems with ICE. When we will
have enough info, perhaps we will see an update to ICE. We will keep this ID
alive.
Robert Sparks asked what to do. What is in
the current loopback draft is sufficient for ECRIT. It is blocking the
publication of an ECRIT document. Perhaps the group should publish a first
version now.
Miguel indicated that the working group
will take the dependency as requirement. We will continue the discussion on the
mailing list.
Real Time Streaming Protocol 2.0 (Martin,
10)
=============================================
draft-ietf-mmusic-rfc2326bis-28.txt
Martin presented his slides.
Magnus Westerlund asked about changing
transport pararameters: it would not make any difference.
Martin questioned if people would care if
Vary header field was removed. He did not get any immediate feedback from the
room.
ACTION: Martin will post the question about
the Vary header field to the list.
Martin indicated that there are a few more
issues to resolve and they will be raised on the mailing list as needed. Intent
is to have an updated draft addressing all comments before next IETF.
Expectation is that another (short) WGLC will be needed by then to review the
updates.
SDP Extension For
Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The
PSTN (Simo Veikkolainen, 10)
===============================================================
draft-ietf-mmusic-sdp-cs-09.txt
Due to lack of time, this was not
presented. The discussion is moved to the mailing list.
Miscellaneous Capabilities Negotiation in
SDP (Simo Veikkolainen, 10)
=====================================================================
draft-garcia-mmusic-sdp-miscellaneous-caps-00.txt
Simo presented his slides.
Simo explained the need to be able to
indicate alternative port numbers, but PSTN media, port number doesn't make
sense. The CS draft says use port number 9 (the discard port). We have to put
something there because required by SDP syntax. If an RTP stream is offered,
then a regular port number should be written instead. The problem arises when
both CS and RTP streams are offered at the same time, one as an alternative of
the other. Then, the port number makes sense for RTP but not for CS, but still,
there is a single place to write the port number in the SDP, so, has to be
shared by both alternative media streams.
Possible solutions:
1. Circuit-switched media uses the same
port as RTP media even though the port is not really used
2. Extend capneg with a port number
capability attribute, restricting its use to cases where ICE cannot be used.
3. Select anything as a port number and say "do not care
on reception".
Jonathan Lennox suggested
saying that port numbers not equal 0 have to be ignored.
Hadriel Kaplan asked if middle
boxes not supporting this stuff can be broken. The discussion is moved offline.
There are questions on how
could be possible to indicate preference for one media stream above the
alternative.
Miguel Garcia suggested using
port 9 if it works. If not take anything not equal 0. Receiver has to ignore.
In general, there was pushback
on the port negotiation approach. The authors should explore a solution along
the third option: write the RTP port number in the "m=" line. If CS
alternative is chosen, discard the port number on reception.
SDP Media Capability
Negotiation (Flemming Andreasen)
=====================================================
draft-ietf-mmusic-sdp-media-capabilities-12.txt
Flemming presented his slides.
Jonathan Lennox asked if
bundled streams are covered by SDP media capability negotiation? Flemming
replied that he had not though about it, so he would have to look at that.
Multiplexing
Negotiation Using SDP Port Numbers (Christer Holmberg, 10)
=======================================================================
draft-holmberg-mmusic-sdp-bundle-negotiation-00.txt
Christer presented his slides.
Paul Kyzivat identified typo on
slide 5 in the answer: the answer should not have the port number bundled.
Christer acknowledged the typo.
Flemming Andreasen asked how many
assumptions we want to make to make this work. Potential security issues have to be addressed.
Flemming also commented that a number of
parameters have to be treated different, e.g. bandwidth. There is a need to
decide for every parameter how to deal with. We need to come up with a general
mechanism, how to deal with it.
Christer indicated that there is always a need to define how these parameters
have to be treated in a bundle case. There is no difference here; Christer does
not see how to get around.
Flemming indicated that key one for audio
stream and key 2 for video stream. There will be a new parameter tomorrow and
the solution has to care about that.
Christer insisted that still he sees no alternative.
Jonathan Lennox commented on the advantage of explicit signaling versus
implicit way. If it signals explicitly, the other party knows what you mean. If
it is implicit, then one has to guess. Both approaches should come to the same
solution.
Christer indicated his preference for
explicit indicators.
Hadriel Kaplan explained that Flemming's point is about backwards capability.
There is not a real solution for this stuff. Hadriel said that he has tested
it, at least 2 vendors work this way. At least it looks like it works. There is
no perfect solution; this is the best we can do. And yes, one has to go through
every parameter in this case.
Hadriel also commented that we cannot rely on the m-line for the end of the
session. Christer agreed.
Harald Alvestrand commented about
parameters. Both sides should understand how to use it. Is it better to mandate
that the offer has the same/different port or to mandate anything at all?
Flemming indicated that having different ports would be preferable. We should
not ignore the real world (middleboxes) but...
Jonathan Lennox indicated that using
different ports is not expensive. Candidate gathering is expensive.
Hadriel said that 3GPP effectively have these things (SBCs). He thinks we
should specify the same port number. We do not know that this breaks anything.
Flemming insisted that it may very well break existing implementations whereas
different port numbers would not.
Hadriel said that it does not break existing RFCs.
Christer explained that the broken technology does not break the RFC. Christer
also indicated that using the same port is unspecified, so we should have to
define semantics.
Cullen Jennings indicated that this is not a big a issue for him. If you take
the same port number, no problem. If you want to allocate 2 ports, just choose
different port numbers. What else is there to do? One/two ports? Anyway it will
not change interoperability.
Christer indicated that none prevents any implementation to do different
anyhow.
Christer indicated the list of potential dependencies to this draft: rtcweb,
clue, avtcore.
ChristerÕs proposal is to adopt the draft
as WG item.
Miguel Garcia indicated that certainly there is a lot of interest from the WG,
keep on working, but we are not ready to adopt this work as WG item yet.
Cullen Jennings questioned what we are waiting for.
Hadriel answered that we need text to decide if this is the right approach.
Signal 3D format in SDP (Bert
Greevenbosh, 10)
==============================================
draft-greevenbosch-mmusic-signal-3d-format-02.txt
Bert presented his slides. There are no questions.
Miguel indicated, as a chair,
that we have a milestone that matches this draft. When this work was presented
at the previous IETF meeting in Quebec there was interest in the WG in pursuing
the work. However, when the chairs polled the mailing list, not many responses
were received.
Miguel indicated that there are
two separated, but somehow related drafts: 3D and parallax. Miguel asked for a
hum to sense the working group for adopting each of these drafts as WG items.
There is strong support for
adopting the 3D draft as WG item.
There is strong support for
adopting the parallax draft as WG item.
Miguel asked the author to
submit both drafts as WG items.
Extensible Bandwidth Attribute
for SDP (Magnus Westerlund, 10)
===============================================================
draft-westerlund-mmusic-sdp-bw-attribute-00.txt
Magnus presented his slides.
Magnus asked how many people
has read the draft. 6 people have read it. Magnus asked if the WG is interested
in working on this.
Roni Even indicated that he has
read the ID. An analysis how it is used today is not sufficient, some more
recommendations and guidance on bandwidth could be helpful, e.g. on how to use
existing parameters more precisely.
Charles Eckel indicated that this
is useful and interesting work. He would like to see some clarification on TLS.
What is your opinion on separate media lines?
Magnus Westerlund indicated
that double m-lines is a bit over the top.
Cullen Jennings asked if he can
solve these issues without touching the involved IPR.
Magnus indicated that he could
not answer that question. He wanted to clean up the bandwidth issues around SDP
and asked to provide feedback on the mail list, if someone has
counterproposals.
Jonathan Lennox stated that clue
is looking at bandwidth for each source.
RTSP Extension for Substream
Control (Peiyu Yue (Roi), 5)
=========================================================
draft-yue-mmusic-rtsp-substream-control-extension-00.txt
Roi presented his slides.
Magnus Westerlund had a
question about motivation: Why do you use signaling, not inline transport
feedback for this purpose?
Roy answered that client cannot
indicate the layer.
Magnus asked if a decision is
based on this information.
Charles Eckel indicated that the
motivation is still not clear. Why not using multiple sessions in SDP?
Roy agreed; we would have no
problem with multiple sessions. With single session you could save port
numbers.
Miguel summarized the
discussion by indicating that there are some concerns about motivation that have
to be worked out a bit more. There is interest of the WG related to this topic,
but it is too early to take this as WG item.