---
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- IETF#71 Meeting Minutes
--- Monday, March 10 2008 from 9:00-11:30
--- ============================================================
The MMUSIC WG met once at IETF#71. The meeting was chaired by
Joerg Ott and Jean-Francois Mule. The session was attended by
about 140 participants.
Minutes reported by Jean-Francois Mule
based on notes from Christian Schmidt and Jean-Francois Mule
1/ Introduction and progress report
After the note well reminder on Intellectual Property, the chairs
presented the agenda and a brief working group.
- RFCs Published: none since Vancouver
- RFC Editor Queue:
draft-ietf-mmusic-ice-19 (dependencies on other drafts)
- Close to Publication:
draft-levin-mmusic-xml-media-control-13
- Awaiting Write-up and/or Publication Request:
draft-ietf-mmusic-sdp-capability-negotiation-08
draft-ietf-mmusic-qos-identification-01
draft-ietf-mmusic-sdp-source-attributes-01
(Jonathan Lennox noted the slides omitted
draft-ietf-mmusic-sdp-source-attributes-01 which had just
completed WGLC)
- Ready for WGLC:
draft-ietf-mmusic-connectivity-precon-04.txt
draft-ietf-mmusic-decoding-dependency-01.txt
- Needs Update
draft-ietf-mmusic-file-transfer-mech-06.txt
draft-ietf-mmusic-media-loopback-07.txt
(it was noted that the media loopback draft has still not
been updated based on the feedback received in IETF#70,
see details in the minutes).
- Other Drafts
draft-ietf-mmusic-rfc4566bis-00.txt
(IPv6 fix in ABNF)
draft-ietf-sip-dtls-srtp-framework-00.txt
(noted for the SDP attributes now defined in this draft)
The chairs noted the liaison statements sent by the MMUSIC
working group on RTSP 2.0, see slides for details.
Finally, the idea of conducting some ICE interoperability testing
at SIPit22 was proposed. The objectives are to do ICE/STUN/TURN
and potentially SIP outboud testing to collect feedback from the
implementers.
2/ ICE TCP
draft-ietf-mmusic-ice-tcp-06.txt
Jonathan Rosenberg presented the main changes and open issues on
ICE TCP. See draft and slides for the main changes since draft-05.
The "big problems" with the current draft were then discussed.
The main issue is that the recommended mechanisms in ICE-TCP work
for about 45% of the cases for double NAT scenarios. This is based
on the use of simultaneous opens and on the findings recorded in a
paper from SaiKat (http://saikat.guha.cc/pub/imc05-tcpnat.pdf).
The other problem is that the mechanism may have issues with
Windows XP (some have concerns that SO support does work in XP).
Different approaches for improvement were then discussed:
a) Port prediction:
The idea would be to add some text in the document to take into
account the fact that, if you open one connection and then a
second one, you normally get port+1.
Comments at the mike from Magnus Westerlund and Francois Audet,
and additional points made by Jonathan, the consensus was to not
add port prediction as part of the ICE-TCP solution but create
an informative document separate from ICE-tcp and potentially
release the document with ICE-TCP.
Later on in the meeting, Cullen Jennings brought up the scenario
of running AJAX applications while initiating ICE and based on
his testing, he was not sure port prediction would even work due
to the many TCP connections.
b) Support for TCP Simultaneous Open in Operating Systems
Jonathan called for volunteers to run some tests on OSes to
check S-O support and verify draft mechanisms.
c) TCP over UDP:
Jonathan proposed to use a radical approach in ICE-TCP: run
ICE-TCP over UDP. The success rate for a UDP connection is good
with ICE. With TCP over UDP, you get the best of both worlds,
e.g. congestion control.
Discussions followed with comments at the mike from several
folks (Remi D-C, Philip Matthews, Dave Oran, Cullen Jennings,
Adam Roach, Ekr, Rohan and others):
- some raised questions and doubts about what this proposal
was (is it TCP over IP over UDP, or TCP over UDP - Dave Oran)
- Philip Matthews indicated that behave-tcp does recommend how
to fix this in NATs and wondered if the solution was in fact
dependent on how NAT vendors do comply with those
guidelines. Cullen indicated that the problem is the
deployment of current NATs. Jonathan stated this was a
multi-year problem.
- this solution would likely be used for p2pSIP and 3GPP
- real data on how this works on NATs would be great
- Adam Roach warned about trends and not describing things
that work today but won't work anymore when the document
goes RFC.
- how would implementers do this (Ekr)?
- there are mechanisms for UDP encapsulation of other
protocols [e.g. IPsec] and there might be interest in TSVG
to define a more generic solution (Magnus W)
- this idea could be part of the solution, this is what the
HIP wg and some drafts in p2psip have been looking at.
More data is required and there was no consensus.
Cullen Jennings <AD hat on> concluded that MMUSIC is not the
right working group; the transport area and TSVWG is where
discussions should happen.
The rest of the comments were centered around what to do with the
document based on the "big" problems. Based on comments, folks
expressed interest in 3 options:
- Continue with S-O as currently defined.
The solution works (pending confirmations on the S-O use on
certain OSes), and requires TURN relay for roughly 50% of
the use cases. P2PSIP may be a customer for this solution.
- Remove S-O from the solution: this makes it easier to implement
and will result in more relay use.
- Select a radical approach like the one proposed in this
meeting.
There was consensus to continue working on this draft but no
consensus on what the best approach is based on the 3 above
options.
3/ NICE
draft-rosenberg-mmusic-ice-nonsip-00.txt
Jonathan Rosenberg presented a new draft, Non-SIP usage of ICE. A
few comments were received about additional motivations for NICE
(RTSP, Jabber/jingle).
The chairs asked where this work should be done, is MMUSIC the
right place?
Cullen Jennings mentioned that the IESG has had discussions related
to the rechartering of MMUSIC: ICE is tied to SDP so MMUSIC is the
right home but the transport of ICE in more protocols is subject to
discussions. AD discussions take place between Magnus and Cullen.
Bruce Lowekamp indicated he has implemented ICE for P2PSIP. He
wondered how many people who need something like NICE don't already
have an implementation. Therefore, simplifications for NICE might make
it harder to implement than staying close to the original ICE.
Bruce raised another comment: it is hard to predict what new
protocols will need from the ICE spec and his preference is to not do a
sub-set of ICE. This was also the opinion of Ekr, Philip Matthews,
Remi D-C, and Magnus. Some protocols may use subsets but these may
not be aligned and the NICE spec may not be the right place to make this
choice for other protocols.
In summary, the group discussed several questions related to NICE:
- is it worth having a generic ICE as NICE intends to spec out
- if yes, should it be all of ICE or a subset?
- who are the customers of NICE and where should this work be
done.
There was no consensus on whether this work is really needed and
comments were between: a) no need for this work, do ICE and
b) do this work on NICE but no subset.
4/ SDP media capabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-03.txt
Roni Even covered the last changes and open issues in draft-03 of
SDP media capability negotiation. Roni acknowledged the work done
by Bob Gilman in particular (Bob did not attending the meeting).
Note that about 5 to 7 people had read the new revision of the draft.
Christer Holmberg asked if the draft needs to support the grouping
of media lines/media attributes. This is an open question: do we
need to address regular grouping in this draft?
More reviewers and feedback are requested.
Philip Matthews indicated that a group of folks in Avaya is
interested in this work.
Henry Sinnreich wondered if this draft limits the adoption of new
codecs due to its complexity and the coupling of codec & SDP
descriptions. Joerg and Magnus addressed the comment: signaling
the codec parameters do not prohibit codec creativity and you still
need an RTP profile definition.
Miguel Garcia found a nice applicability of this draft so this I-D
is solving some problems and he would like to see this I-D
progress.
Ingemar Johannson commented that he would like to see more rules
for constructing capability attributes in SDP (Roni's last bullet
on slide 6).
The chairs called for additional reviewers to send comments to the
list.
5/ RTSP 2.0
draft-ietf-mmusic-rfc2326bis-17.txt
draft-ietf-mmusic-rtsp-nat-06.txt
draft-ietf-mmusic-rtsp-nat-evaluation-00.txt
5.1./ draft-ietf-mmusic-rtsp-nat-06
Magnus Westerlund presented the recent changes in the RTSP 2.0 NAT
draft (draft-ietf-mmusic-rtsp-nat-06.txt).
A NAT traversal solution is needed for RTSP with use cases of
clients and/or servers being behind NATs.
Jonathan Rosenberg noted that the D-ICE solution proposed in the
draft is some kind of ICE-lite with trigger checks (see draft and
slides).
There were some discussions around RTSP re-setup and ICE restarts.
Jonathan noted that ICE restart provides continuity and wondered
about the need to create a new ICE exchange. It could affect client
behavior. More discussions are needed on the list.
Remi asked about the use cases for re-setup: roaming? There is
a potential use case if the client moves from one interface to
another.
Magnus asked if this approach was a good one to use. Now is the time to send feedback.
Jonathan asked why regular nomination should be used in a core re-setup to
provide continuity? He does not see what benefits this is bringing
because you would not be able to re-use the ICE stack.
Remi asked what would the use case could be for not using RTCP mux?
Given that the other end implements ICE, why not implement RTCP
mux? This would have fewer problems.
Magnu answered that there are a few cases, for example, the
delivery of media behind a NAT and there are different RTP and RTCP
streams.
Jonathan Rosenberg added another case if for layered codecs across
ports but current ones like SVC do not work that way.
Philip Matthews commented that this is an example for ICE usage
for a certain protocol. There is a need to come up with a more general
solution.
Bill commented that we need to support components. May be FEC is a
candidate for other types of components?
5.2/ RTSP 2.0, draft-ietf-mmusic-rfc2326bis-17.txt
Martin Stiemerling presented a brief status report on the changes
in draft-17 of RTSP 2.0. There is a proposal to add semantics for
an END_of_STREAM indication.
Martin and Magnus are the two principal contributors and the working group
does not seem to review or comment. More interested folks are needed
to move this work item forward.
6/ RTSP and SIP
draft-whitehead-mmusic-sip-for-streaming-media-03.txt
The draft on Media Playback Control Protocol Requirements was
presented next by Sam Ganesam/Xavier Marjou.
Magnus indicated that there is already work done in TISPAN and may
be other standards organizations on this. Magnus believes it would be better to do a
solution in IETF as a complement to regular RTSP.
Jonathan Rosenberg commented that he is still unconvinced and more
work is required on the use cases (use case #3 seems like an RTSP
extension, the first 2 use cases are where RTSP does not work). He
asked if there were use cases compelling enough to motivate the
work and wondered if the first case really requires streaming
control.
There are relations to SIP. It would be the right approach to
identify, how SIP and RTSP can work together.
There was a discussion on whether the individual SIP TOTE draft was
a potential solution. Jonathan clarified that the ID does not
intend to do that.
Martin S. commented that we should investigate how SIP and RTSP can
work together.
Dave Oran proposed to characterize the problem of overlap in
in-session control protocols better.
The presentation concluded with no consensus to work on this and
participants requested more list discussions on the "real-world"
"concrete" use cases and related requirements.
7/ SDP DSCP Attribute
draft-polk-mmusic-dscp-attribute-02.txt
James Polk presented an update of the DSCP attributes in SDP.
Dave Oran raised the issue of where the decisions should be made for
the DSCP code points, is it layer 3 and IP or layer 7? The issue
raised by Dave is putting bits at layer 3 in layer 7.
Additional comments were made by Henry Sinnreich, Cullen Jennings,
Magnus W and Brian Rosen.
Brian summarized the comments by indicating that the problem should
be explored before finding out the solution. We might need to look
back at what needs to be communicated by whom.
8/ Signaling media decoding dependency in SDP
draft-ietf-mmusic-decoding-dependency-01.txt
Remi D-C made a minor comment on the values used for payload types
(may be a bit big numbers for payload types).
If extensibility is needed, an extension mechanism should be
defined. Magnus added that the ABNF needs some work to add
extensibility and a few cleanups.
Stefan Wenger indicated that new text should be inserted to specify
what is required to add an extension.
There was wg consensus to go to WGLC with the upcoming revised ID.
9/ SDP Grouping Issues
draft-begen-mmusic-fec-grouping-issues-00.txt
Ali Begen covered a few SDP grouping issues based on the FEC work.
RFC3388 contains a restriction related to the rule for grouping: an
“m” line identified by its ‘mid’ attribute MUST NOT appear in more
than one “a=group” line using the same semantics.
It was introduced, because, there was no use case known at the time
and to keep the solution simple. There was no objection to remove
the restriction in RFC3388 and update the RFC.
As part of the discussion, the following comments are noted:
- Jonathan Lennox indicated that the source attribute defines
grouping to the source level so we might want to look if this
problem applies to the source-specific SDP draft too.
- Joerg clarified the needs to keep implementers who have done
RFC 3388 happy. Dave Oran indicated that there is some
implementations of RFC 3388 but there does not seem to have any
dependence on the restrictions in the RFC 3388.
- Gonzalo Camarillo confirmed that as he recalls, the limitation
was due to a scope limitation more than anything else.
There was WG consensus to revise RFC 3388 to remove this restriction.
The chairs will post a note on the list though.
We ran out of time. The chairs asked if folks were willing to stay.
The last two presentations were done with only about 50% of the
working group participants in the room.
10/ SDP ptime attributes
draft-garcia-mmusic-multiple-ptimes-problem-02.txt
There were questions raised on whether MMUSIC is the right place
for this draft. Based on comments from Christer Holmberg and
Joerg, it is recommended that this draft be discussed in AVT, at a
minimum to ask for input and opinions. It was commented that the
draft has developed in the right direction in giving guidance to
implementers.
More list traffic is required on this draft.
11/ SDP for circuit-switched media
draft-garcia-mmusic-sdp-cs-00.txt
Miguel Garcia-Martin presented the motivations for defining new SDP
attributes for circuit-switched media.
Christer Holmberg commented that there could be use cases for
these. Christer brought up an issue which is not specific to this
draft but to the capneg draft. The offer/answer changes the c line
between the offer/answer and this could cause some problems.
Joerg commented this is not related to this draft, same issue with
IPv4 and IPv6. There was support stated in favor of the draft and
what the authors are trying to achieve.
Further list discussions is required on this draft to progress it.
12/ SDP for Collaboration Applications
draft-garcia-mmusic-sdp-collaboration-00.txt
This draft was not covered due to time limits.
The meeting concluded.
> end.