---
--- ============================================================
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- IETF#72 MMUSIC Meeting Minutes
--- Friday, August 1, 2008, 0900-1130
--- ============================================================
The MMUSIC WG met once at IETF#72. The meeting was chaired by
Joerg Ott and Jean-Francois Mule. The session was attended by
about 70 participants on Friday morning.
Minutes reported by Jean-Francois Mule
1/ Introduction and progress report
The chairs reminded everyone of the Note Well text and the IETF
Intellectual Property policy. There were no comments on the agenda
and Joerg Ott gave a brief status update of the working group
deliverables.
- MMUSIC WG Charter:
The charter has been revised since IETF#71. All working
group drafts have milestones - see charter page for
details. Additional comments to the chairs are welcome.
- RFCs Published since IETF#71 in Philadelphia:
RFC 5159: from draft-dondeti-oma-mmusic-sdp-attrs-00.txt
RFC 5168: from draft-levin-mmusic-xml-media-control-13.txt
- RFC Editor Queue:
http://tools.ietf.org/html/draft-ietf-mmusic-ice-19 still in
the editor queue due to dependencies on other drafts.
- Publication Requested:
http://tools.ietf.org/html/draft-ietf-mmusic-qos-identification-01.txt
- Awaiting Write-up and/or Publication Request:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-09
http://tools.ietf.org/html/draft-ietf-mmusic-file-transfer-mech-08.txt
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-source-attributes-01
- Ready for WGLC:
http://tools.ietf.org/html/draft-ietf-mmusic-connectivity-precon-04.txt
- Needs Update
http://tools.ietf.org/html/draft-ietf-mmusic-decoding-dependency-01.txt
http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-08.txt
(it was noted that the media loopback draft 09 was posted
after the IETF#72 cut-off dates and exists in the ID
repository as of August 5).
- Other Drafts
http://tools.ietf.org/html/draft-ietf-mmusic-rfc4566bis-01.txt
http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework-02.txt
and SDP proto parameters in
http://tools.ietf.org/html/draft-ietf-avt-dtls-srtp-03
http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-01.txt
The MMUSIC working group received a Liaison Statement (LS) from
3GPP which asked for IETF input on "whether the .INVALID address
may be used to indicate an unspecified IPv4 connection address".
See chair slides for link and details.
Based on mailing list discussions, Jean-Francois Mule presented a
proposed response for working group review:
Recommend that 3GPP continues to use 0.0.0.0 to signal an
invalid connection address in SDP connection lines with IPv4
addresses based on the following:
- while the SDP aBNF allows .invalid (RFC 4566), the
SDP offer/answer RFC has a normative requirement for
implementations to support 0.0.0.0 as a connection
address to indicate that neither RTP nor RTCP should
be sent to the peer.
- feedback received on the IETF MMUSIC mailing list
from several SIP implementers indicate that only
0.0.0.0 is supported by IPv4-only endpoints.
- Note that this feedback is from the SIP community,
not the H.248 one.
A few comments were made at the mike by Roni Even, Gonzalo
Camarillo and Tom Taylor:
- Roni Even asked that the port should not be zero per RFC 3264.
- Gonzalo stressed the fact that this LS was related to SDP use
in H.248 and hence that we should indicate in the LS reply
that most of the feedback we got was from the SIP community
(already integrated in the proposal presented in the meeting);
- Jean-Francois stated that while the question seems related to
H.248 SDP use, MGCs tend to have SIP legs and re-use SDP
across the H.248 and SIP exchanges
- Tom Taylor added that H.248 SDP interop with SIP UA SDP is
indeed important.
There was consensus to respond that 0.0.0.0 is preferred over
.invalid based on the comments but we should add more text to
put this IETF feedback in the context of SDP use in SIP.
Jean-Francois will circulate a draft LS reply to the working group
shortly after IETF. The LS reply will then be finalized and sent.
There were additional LS received by MMUSIC on RTSP and on an
"image size" SDP attribute; some were discussed during the MMUSIC
Interim meeting held in May on RTSP and the LS content along with a
proposed response is covered below with the related Internet-Drafts.
Gonzalo Camarillo relayed some information about the HIP working
group. The HIP WG met in Dublin and had a live demo of two
implementations using ICE.
--- SDP Image Attribute
http://tools.ietf.org/html/draft-johansson-mmusic-image-attributes-01
Ingemar Johansson presented a proposal to add an SDP attribute for
image size. This document is related to a Liaison Statement the
MMUSIC WG received from 3GPP.
A set of comments on the problem statement (slide 3) followed:
- H.264 allows custom-sized picture formats and
regarding the rescaling, a receiver must be able to scale any
size it gets from the encoder per H.264 as long as it is
within the level (Roni Event)
- the main issue is the negotiation problem, doing it with the
payload types is difficult (Magnus Westerlund). Magnus also
asked if combining all of this information into one SDP
parameter is the right choice.
The objectives of the draft were discussed and commented.
- Joerg Ott asked a question concerning the asymmetry
(send-only, receive-only). How much of that asymmetry should
be negotiated vs. just declared (declare what can be
supported)? It is unclear whether we should have complete
negotiation capabilities on every parameter.
- Roni reiterated comments he sent to the list: for Roni, the
objective should be to enable the receiver to request a
specific size from the sender. The receiver should not include
all the sizes it can support. The receiver can request a
specific size. The sender can reject it, or it can choose a
size as close as possible to what the receiver asks in some
cases.
Roni recommended that the receiver should be capable of
requesting a specific size with an indication of whether it is
the exact size or if the receiver can approximate.
- Magnus agreed that the main goal is probably to allow a
receiver to express preferences about what it can receive
- there were additional comments from Roni, Magnus and Stephan
debating the scope and the requirements.
Joerg noted that parts of the problem description seem to be
related to the resolution of the screen on the receiver side,
independent from the codec capabilities.
Stephan Wenger added that we should be careful about making
assumptions on what the user interface can or cannot do. For e.g.,
overscaling TV is a reality where you do not display the outside of
the capture.
Roni Even added that even if the application knows what display the
phone can support, the user can change the display settings. You
may connect your camera onto a display information. The document
should say that we should have the ability to request a specific
resolution from the sender.
Jonathan Lennox commented that the semantics should be close to
this: "if you send me something that in the sender's opinion would
look good in this size, it is good" rather than "send me exactly
this".
Additional speakers expressed comments in favor of having this as a
work item. The working group chairs concluded that there was
interest in this work based on the discussions and consensus that
having an SDP mechanism to signal some preferences could be
beneficial. We need however to get a better understanding of the
requirements and what the scope of the problem is.
Hannu Hietalahti closed the mike line by thanking the working group
for the discussion and for providing a first level of guidance back
to 3GPP. There seems to be some interest in defining an SDP-based
solution for this.
Hannu asked where should this work be done. Based on the MMUSIC
discussions, Jean-Francois Mule as chair requested that 3GPP
brings requirement to the MMUSIC working group, possibly in the
form of an Internet-Draft. Hannu agreed with the proposed approach.
The MMUSIC chairs will respond to the 3GPP LS based on the
mailing list and the meeting's discussions.
--- SDP Media Capability Negotiation
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-media-capabilities-05
Roni Even presented the updates on the SDP Media Capability
Negotiation draft. Two revisions have been posted between the 2
meetings.
Based on comments from Ingemar Johansson, Christer Holmberg and
Hadriel Kaplan requesting that the mechanism removes the c= line,
Roni indicated that if folks don't want the c= line, it will be
removed. Christer was in favor of moving this into a separate
document.
Jonathan Lennox made a comment about one of the examples in the
slides that seem to imply that video cannot be negotiated.
Roni answered that this is just an example for this discussion, not
an inherent limitation of the mechanism.
Ingemar raised a comment on the size of the potential
configuration. Roni indicated that this is the type of input that
is required to optimized the syntax. The authors tried to find the
proper shortcuts to express it. Ingemar will send an email to the
list.
Al Morton may have comments and will talk to Roni, and send
comments to the list.
The chairs asked that folks interested in this framework are
encouraged to review this document in-depth.
--- ICE TCP
http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-07
Dan Wing presented the status on ICE TCP on behalf of Jonathan
Rosenberg. There were no changes or progress in the document
since the last IETF.
Based on the published research, the TCP-SO mechanism in the draft
provides about 40% effective success.
Cullen Jennings expressed a strong opinion not to rely on any port
prediction mechanisms to improve the success rate. Cullen pointed
to the current work around on DNS attacks that is to make your port
randomization be truly random otherwise DNS is really insecure.
Port prediction is disappearing as a technique.
Magnus added that there is a draft in the transport area for port
generalization.
Dan presented the options to move ICE-TCP forward ("Our choices" slide):
1. Discard the document as not effective enough
2. Remove TCP-SO, issue ICE-tcp with act/pass only ? will work
in cases with a public TURN server and often relay
3. Keep TCP-SO
4. Add additional TCP over UDP mechanisms of some sort to this
document
Dan also presented the author's recommendation: go with option 2.
The working group consensus is between options 2 & 3 and more
list discussions are required. Some suggested to go with option 2,
and put the TCP-SO mechanism in a separate draft.
There were a number of comments from Magnus Westerlund, Christer
Holmberg, Ron Even, Adam Roach, Cullen Jennings, Hadriel Kaplan and
a few others. The working group feedback is:
+ to keep ICE-TCP and progress the document.
No votes for option#1.
Christer and many others expressed opinions to keep it.
Cullen Jennings expressed comments as an individual against
option 1 to keep ICE-TCP because TURN relay can still be
done and clients could be forced. Besides Cullen, there was
enough support for the other options to conclude that
discarding the document is not a way forward.
The chairs polled the group on option 1: nobody raised hands
in favor of option 1.
+ to not discuss any methods to transport TCP over UDP as part
of this draft or any other in MMUSIC (several opinions against
option #4 as an MMUSIC discussion).
No support for option 4 as part of this effort.
Based on comments Cullen as an AD and Magnus Westerlund,
this is work for the transport area.
+ go with option 2, and may be split TCP-SO in a separate doc.
In addition to the above, Ted Hardie suggested to explore making
ICE-TCP an experimental document with one or more techniques (there
will be cases where there will be TURN servers with TCP out there
and having a document is good).
Cullen added that ICE-TCP and TCP-SO still represent 40% success
rate and that is interestingly pretty close to what folks first got
many years ago when testing ICE-UDP. This could change over a
5-year period.
Cullen suggested that perhaps we should keep ICE-TCP with act/pass
(option 2) and create a separate, may be experimental document on
TCP-SO to collect data.
The chairs summarized the consensus above and the best path forward
is to clarify the new proposal on the list based on the working
group feedback at this meeting and update the draft. Jonathan
Rosenberg was named to complete the document.
--- NICE
http://tools.ietf.org/html/draft-rosenberg-mmusic-ice-nonsip-01
Dan Wing presented the updates in draft-01 on NICE.
Dan asked if anyone was interested in working on this document as
an editor. Gonzalo Camarillo indicated interest for NICE in HIP
and we could look for a volunteer there eventually. Christer
Holmberg is also interested in the work; it's been implemented in
HIP. Ted Hardie reminded that Bruce Lowekamp's email on the list
did indicate he was willing to do work on this too.
Several other folks expressed interest in having NICE (Sumanth
Channabasappa, Markus Isomaki, Marc Petit Huguenin?, Jean-Francois Mule,
...).
Cullen Jennings summed it up: "we got a bunch of customers, we got
people to work on it".
Ted Hardie reiterated Bruce Lowekamp's comments sent on the list;
p2psip documents need something like NICE and having this text
available for p2psip and other protocols would be useful.
The group will continue to progress this document in MMUSIC.
--- Use of SDP Usage for Circuit-Switched
--- Bearer Connections in PSTN
http://tools.ietf.org/html/draft-garcia-mmusic-sdp-cs-01
Simo Veikkolainen presented the updates on this draft. See the
draft and slides for details on the changes in draft-01 (removed
codec negotiation intertwined with CS media, addition of a
correlation mechanism using User-User Information element of the
PSTN signaling).
Based on comments from Christer Holmberg and Hadriel Kaplan, it was
agreed that this draft should not change the c= line. The
resolution is to not deviate from the SDP media capability draft
and its approach.
Simo indicated that a new version of the draft could use the SDP
media cap framework and use media lines instead of connection line
for negotiation purposes.
Ted Hardie expressed support for continuing to work on this draft
for the 3GPP use cases.
Jonathan Lennox added that this draft looks a lot like offering
IPv4|IPv6 which was ANAT which has been deprecated by ICE. He
suggested to look at ICE or ICE-lite for the solution. May be what
you want is have an ICE PSTN-like candidate address. Comments were
made that it would not be a good idea by Ted and Cullen (what do
connectivity checks mean in this context for example?).
Based on the discussions and list comments, the chairs proposed to
continue to progress this draft as an individual submission and
decide later to adopt it as a working group item (this could be
done on the mailing list before Minneapolis based on progress).
--- RTSP liaison statements
Jean-Francois Mule presented the liaison statements received by
MMUSIC on RTSP/2.0 (see chairs' slides for details). These were
discussed during the MMUSIC interim meeting.
The chair slides provide details and proposed next steps. Based on
these notes and unless there are any further comments on the list,
the MMUSIC chairs will draft LS responses where needed by Sept 15.
- 3GPP LS:
We need a volunteer to review latest 3GPP spec and Magnus's IETF
I-D. The publication request of
draft-westerlund-mmusic-3gpp-sdp-rtsp-06.txt is imminent.
The proposed response to 3GPP LS is:
- Need I-D to explain and potentially register RTSP/FLUTE work
- Ask 3GPP to bring requirements for time shifting extensions
to IETF MMUSIC
- CableLabs LS:
The proposal is to not respond and await for an update to the ID
draft-bergren-mmusic-rtsp-ermi-extensions which should have
updates on the RTSP usage for the ERMI effort at CableLabs based
on the interim meeting feedback. A new draft should also
proposed some IANA registrations, consistent with Colin Perkins's
request some time ago and the MMUSIC LS to CableLabs.
- ETSI TISPAN
Based on the mike's comments, it is proposed to respond to ETSI
TISPAN the following:
- ask for why SETUP/PLAY could not be sent in the same message
(even if SIP dialogs support media session establishment)
- indicate that an Internet-Draft has been presented in the
past
(http://tools.ietf.org/html/draft-marjou-mmusic-sdp-rtsp-01)
and that based on the MMUSIC interim meeting in May 2008, an
update is expected. At this time, while there is no
consensus that this work should progress, discussions are
ongoing.
- ITU-T SG9
Draft a response to ITU-T SG9 after RTSP rfc2326bis has been
updated to include main reasons why RTSP 2.0 is incompatible
with RTSP 1.0. This should be inserted in the RTSP/2.0 draft
first per interim and referenced in the MMUSIC response.
- ITU-T SG16
No responses required, see slides for details.
- Open IPTV-Forum
This group intends to use PLAY without SETUP, which is very
similar to TISPAN.
Based on comments from Magnus and others, it is clear that
several organizations are looking at decomposition models for
RTSP, splitting roles and functions between SIP and RTSP.
Based on the mike comments, it is unclear what could be done and
if RTSP should be reworked to allow this. How difficult is it to
have one extra RTT or use pipeline commands? Magnus suggested
we put this in the response.
More input is required on the architecture models for separating
the session controller from the media playback.
--- RTSP and RTSP NAT
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rfc2326bis-18
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rtsp-nat-evaluation-01
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-rtsp-nat-07
Magnus Westerlund provided a status on the RTSP documents. For
RTSP, there were no updates since the interim meeting where some
progress was made on things like open issues, scale/speed, etc.
Magnus indicated an I-D update should be released in September.
Magnus presented the updates on RTSP NAT.
There was little feedback on the list and during the meeting on the
proposed changes in the draft, in particular, the RTSP
server-initiated changes to use PLAY_NOTIFY with ice-restart as the
reason. See slides for details.
Magnus also discussed some alternatives to the PLAY_NOTIFY approach
which is to have the RTSP server act as the ICE controller. One
comment was raised by Dan Wing on this alternative: the stated con
is applicable when there is no NATs and no ICE (RTSP PLAY response
may arrive after media is received).
More reviews and feedback are needed on this work to progress,
please send you comments to the list.
A discussion followed on how we could encourage participants from
other SDOs to come to IETF meetings to provide feedback. While
their participation was great at the interim meeting with folks
attending from 3GPP, DVB and ETSI, Cullen correctly pointed out
that there is still a shortage of participating during IETF
meetings or on the list.
--- SDP Media Loopback
http://tools.ietf.org/html/draft-ietf-mmusic-media-loopback-08
Kaynam Hedayat covered the changes in the to-be-posted draft -09.
Kaynam Hedayat will post a request to the AVT list for the AVT WG
participants to provide feedback on the documents' RTP payload
types.
MMUSIC chairs indicated the WGLC on this draft will be sent shortly
after IETF#72.
--- Multiple Packetization Times in SDP
http://tools.ietf.org/html/draft-garcia-mmusic-multiple-ptimes-problem-03
Joerg presented the slides on behalf of the authors and asked some
feedback for the authors.
Jeff Hunt commented that it is does not allow to arrange 2
packetization times for codec A and 2 packetization times for codec
B. It would seem better to recommend an mptime parameter. This
proposed solution seems to introduce complexity without solving the
problem.
Christer Holmberg commented that the original intention of the ID
was to allow multiple codec-specific ptime. This does not seem a
solution to the original requirements.
Chairs asked folks to send comments to the list.
The meeting was adjourned.
> end.