--- ============================================================
--- Multiparty Multimedia Session Control (MMUSIC) Working Group
--- DRAFT Minutes for IETF#76 MMUSIC WG Meeting
--- Friday, November 13, 2009 - 9:00 to 10:30am
--- ============================================================
WG CHAIRS: Joerg Ott <jo@acm.org>
Jean-Francois Mule <jf.mule@cablelabs.com>
The MMUSIC WG met on November 13 at IETF#76.
The session was attended by 32 participants. The meeting was
chaired by Jean-Francois Mule as Joerg Ott had a conflict.
The minutes are reported by Daryl Malas and Jean-Francois Mule.
1/ Introduction and WG Progress Report
The WG agenda was reviewed with no comments or additional suggestions.
Jean-Francois presented the WG progress report since IETF#75:
- no RFC was published since Stockholm,
- draft-ietf-mmusic-ice-19 is in the RFC Editor queue.
Magnus Westerlund indicated that it should come out of the RFC
editor queue "very soon".
- 2 Internet-Drafts were evaluated by the IESG:
draft-ietf-mmusic-connectivity-precon-06
draft-ietf-mmusic-rfc3388bis-04
rfc3388bis-04 was posted November 11 and Gonzalo
addressed the IESG comments in this revision.
- ID revisions are required for the following draft:
draft-ietf-mmusic-sdp-capability-negotiation-10
Flemming Andreasen has indicated he expects to submit a
revision addressing the IESG comments before the end of
December 2009.
draft-ietf-mmusic-image-attributes-03
Ingemar Johansson plans to release draft-04 to fully
address the comments received from WG participants.
draft-ietf-mmusic-media-loopback-11
This ID has not been revised to address the comments
raised on the list. Jean-Francois took the action item
to follow-up with the authors on the open comments and a
date for completion.
- Other drafts:
draft-ietf-mmusic-rfc4566bis-02 will remain as-is for now.
draft-ietf-mmusic-rtsp-nat-08
Magnus Westerlund suggested the ID is ready for WGLC.
There were no objections and the chairs will request
WGLC after IETF#76.
draft-ietf-mmusic-sdp-cs-02: Simo Veikkolainen has indicated
that work is progressing and an update is expected to come
out soon.
We also discussed the status of ICE-TCP which has not received any
significant changes since draft-06 in February 2008.
Jean-Francois recapped the outcome of the IETF#73 session where we
had some good consensus to use the ICE-TCP framework proposal from
Bruce Lovekamp and Adam Roach as a baseline for revising ICE-TCP
as an extensible framework.
The WG chair asked what options should be considered to conclude
this work item.
- Robert Sparks indicated that p2psip has a normative reference
on ICE-TCP and it therefore needs to be finished.
- Roni Even added that ICE TCP is also important for TCP media
established with RSTP.
- Jean-Francois will coordinate with the chairs of p2psip and
propose a way forward on the MMUSIC list.
2/ RTSP 2.0
http://tools.ietf.org/html/draft-ietf-mmusic-rfc2326bis-22
Magnus Westerlund reviewed the comments received during Working
Group Last Call on draft-22. Note the IPR statement from Ericsson
at https://datatracker.ietf.org/ipr/1189/. Magnus disclosed it as
part of his presentation (slide 5) and there were no comments
expressed during the meeting.
The list of issues raised during WGLC is in the slides with full
details. It includes:
- Seek-style with conditional Random Access Point (RAP) policy:
the proposal is for the server to reply 4xx (466) if RAP is
before playout.
– IANA comments:
Jean-Francois expressed concerns about the proposal to only
have "Specification Required" for RTSP Status Codes. This
would mean that other SDOs could define codes in their
specifications without having the need to document and review
them in IETF.
Based on a question from Roni Even, any type of RFC would be
sufficient. After some discussion, it was agreed that the
RTSP 2.0 draft will be revised to have "RFC Required" for RTSP
status codes.
.
– Other issues reviewed include: Media type review, ABNF Syntax,
Grouping of media lines and Aggregation in proxies.
Magnus clarified that some text will be proposed in draft-23
to address these comments.
The authors' plan is to release draft-23 and the chairs will
request a second WGLC given the changes.
A quick poll of WG participants showed that about 15 people have
read some versions of RTSP 2.0 over the years and 7 are willing to
review the upcoming draft which will should be close to the final
draft.
3/ FEC Grouping Semantics in SDP
http://tools.ietf.org/html/draft-ietf-mmusic-rfc4756bis-05
Ali Begen recapped the motivation behind this RFC update and
summarized the WGLC comments - see slides.
draft-05 does address all the WLGC comments. Jean-Francois will
review the document and request publication after IETF#76.
4/ Port Mapping Between Unicast and Multicast RTP Sessions
http://tools.ietf.org/html/draft-begen-avt-ports-for-ucast-mcast-rtp-01
Ali Begen presented a proposal to indicate port mappings for
unicast sessions in the context of multicast RTP. The draft was
presented in AVT and additional input is seeked from MMUSIC
participants.
There were no comments or questions on first the 11 slides.
On slide 12, Ali requested feedback: should we keep server/client
ports unchanged across sessions? One key assumption is that this
solution requires strict SSRC management across all multicast RTP
streams.
Cullen Jennings thought that the probably of collision is to
small to worry about.
Ali Begen indicated that even if the probability is small, if
they do collide the result will be bad.
Xavier Marjou : In my opinion, the proposal on slide 12 is
good.
Roni Even commented that other options should be considered.
Roni added that this document would update RFC 3350 - Ali did
not think so.
Jean-Francois Mule indicated that even if the probability is
small, having a mechanism that we know can break some (rare)
times seems like a badly engineered solution. It would be good
to understand the impacts when things break.
Cullen Jennings concluded the comments at the mike by saying
that the odds of having a collision versus the odds of the
equipment failing should be considered into whether or not the
complexity of this problem should be solved.
On slide 13, input on RFC 4588 was requested for the following
requirement:
"In the case of session-multiplexing, the same SSRC value MUST be
used for the original stream and the retransmission stream."
Ali is concerned since the primary multicast and retransmission
streams may use different SSRCs.
Ali will post these questions on the mailing list given the low
attendance of the meeting.
The meeting was adjourned.
>end.