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.