[MMUSIC] Draft MMUSIC minutes

[Joerg Ott <[e-mail]>]

All,

please find attached the MMUSIC minutes from SFO.
Sorry for the delay.

Jean-François and Joerg




Draft MMUSIC WG Minutes
-----------------------

MONDAY, March 23, 2009, 0900-1130 Morning Session I
ROOM: Continental 4

CHAIRS:  Joerg Ott <[e-mail]>
          Jean-Francois Mule <[e-mail]>

Reported by Joerg Ott

1. Agenda bashing and WG update (chairs)
----------------------------------------

The MMUSIC WG met once at the 74th IETF in San Francisco.  The meeting
was attended by 75 people.

Jean-FranÁois MulÈ presented the agenda which was accepted by the working
group.  He proceeded to reviewing the Internet Drafts pushed out of the
WG towards the AD and the IESG.  In particular, since Minneapolis,
draft-ietf-mmusic-qos-identification-03.txt was published as RFC5432.
See slides for further details.

Joerg Ott then discussed the status of the other WG drafts, noting that
they are mostly progressing well.  Reviews are needed for the
draft on middleboxes in the media path.  ICE TCP requires a
new editor, preferably someone who has been working with ICE for a while
and, as Jonathan Rosenberg added, someone who is intimately familiar
with the socket interface and specific ICE implementations over TCP.


2. SDP Media Capabilities (Roni Even, 10)
    draft-ietf-mmusic-sdp-media-capabilities-07
    -------------------------------------------

Roni Even presented the changes to the media caps draft.  The draft extends
the SDP capability negotiation mechanisms to media-related aspects, most
importantly supporting non-trivial codec specifications including FEC,
layered codecs, redundancy coding, and so on.  Multiple revisions of the
draft were issued since Minneapolis.  Significant changes from version
04/05 include removing the definitions for bcap, ccap, icap, and kcap
(to be spec'ed in another document), allowing capability renegotiation
when modifying sessions and quite some editorial cleanup.  The current
version satisfies all the documented requirements, but the group is
asked to double-check whether anything is missing.  Roni called for
further reviewers of this draft.  A poll in the room revealed that
only very few people are currently considering implementing this,
but volunteers for reviewing were found.


3. RTSP 2.0 (Magnus Westerlund, Martin Stiemerling, 40)
    draft-ietf-mmusic-rfc2326bis-20
    ----------------------------------------------------

Magnus Westerlund and Martin Stiemerling presented the updates to the
RTSP-bis specification.  He started out with a formal note that the
new IETF copyright statement requires contacting and obtaining consent
from all authors, yet not all have responded.  On the technical and
editorial side, quite a few major changes were performed in -20.
The biggest editorial change was replacing the many references to the
HTTP RFC with text so that the RTSP spec becomes self-contained,
much more readable, and less ambiguous.  While most references have
adapted text, two sections, in fact, contain an exact copy of the HTTP
text (18.1 and 18.2).  Since this involved a major (re)write, good
reviewers are needed to double-check that the outcome is correct.

Furthermore, draft -20 includes clarifications to the model and use of
GET_PARAMETER, covered by completely new text.  The technical
mechanisms are not new or modified, but they are described in a
different way and additional text is provided to describe how headers
are supposed to be used.  For some headers, Accept-Ranges,
Media-Range, Media-Properties, Range, and RTP-Info, GET_PARAMETERS may
be used to retrieve their current values.

As a follow-up of a long design discussion at the Stockholm interim
meeting, the Speed header has now been properly defined (see slides).
Specifically, speed ranges are allowed to enable buffer prefill.
One skeptical comment raised from the audience was whether this should
even be specified, considering that this would also need to be
implemented.  In the meeting, there was some interest in this feature,
and further discussion will be taken to the list.

A clarification question raised on the list on the use of sequence
numbers was discussed, namely the addition that RTP sequence numbers
need to be monotonically increasing, unless PAUSE and PLAY are used
in a live stream.  Some clarifying text was added (and gaps in the
RTP sequence number space are now explicitly allowed).

Finally, RTP and RTCP multiplexing is now documented as a optional
feature, not mandated on either (client or server) side.  Support for
this feature can be indicated by the server in the SDP session
description and, if so, may be requested by the client.

A couple of open issues remain that require feedback from the group:

-- The Server killing the session in ready state despite
    keep-alives.  This was discussed on the list and new text was
    added; needs feedback.

-- RTSP From header; what is needed?

-- The possible interaction between speed/scale is not yet
    clarified in text; Speed/scale are seen to be orthogonal.
    But this needs a textual description.

The authors announced that they are performing consistency checking
now and that another update to be coming by the end of April.
They make a call for reviewers, now!  This is the last chance to
make technical changes!


4. Middlebox Interactions for Signaling Protocol Comm. along Media Path
    (Hannes Tschofenig, 5)
    draft-ietf-mmusic-media-path-middleboxes-02
    --------------------------------------------------------------------

Hannes Tschofenig reviews what this document is about and explains its
history and context (no slides).  The recap is primarily done to
obtain reviewers for the document.  Three volunteers are found: Martin
Stiemerling, Jonathan Rosenberg, Cullen Jennings.

The chairs will issue WGLC now.


5. FEC Grouping Semantics in SDP - RFC4756bis (Ali Begen, 10)
    draft-ietf-mmusic-rfc4756bis-01
    ----------------------------------------------------------

Ali Begen presented the draft with the aim to head for WGLC soon.
He briefly reviewed the basic motivation, most notably to achieve
maximum flexibility for the FEC framework with respect to protection
of and across individual streams (see the slides for details).  He
identified the currently missing semantics and presented the approach
taken in the present draft.

One question was raised on the relation to the SSRC attributes draft.
Ali mentioned that this was brought up before and that the draft
attempts to be broader than RTP.  Jonathan Lennox and Ali Begen will
check offline whether there are any issues and report the results
to the list.

Ali also raises the question whether RFC 4756 shall be obsoleted.
Steve Casner points out that, if the draft is complete, RFC 4756 can
be obsoleted.  Ali will poll the list on this.

The chairs ask the group to raise any comments on the list.  They will
be issuing WGLC soon.



6. SDP image attribute (Ingemar Johansson, 10)
    draft-ietf-mmusic-image-attributes-01.txt
    -------------------------------------------

Ingemar presented the SDP image attribute draft.  The intention is to
capture generic image attributes (generic in the sense of independent
of a specific codec or format).  Numerous clarifications were folded
into the draft since the last revision and the known issues were
addressed.  The aim is now to head for WGLC.

Ingemar discussed one potential issue, namely if it is a problem if an
answerer replaces all offered parameters in its response because there
is no good match -- and how the individual configurations are then
negotiated (see slides for details, specifically also the simplified
example from the 3GPP context).

Quite some discussion about square pixels and aspect ratios ensued.
It was commented , there may be some distortion on the screen
depending on the pixel aspect ratio between the original picture size
and the finally rendered one.  It was noted that the 'sar' parameter
is primarily intended to reduce the processing load on the receiver.
Non-square pixels will require further consideration.


7. SCTP protocol identifier for SDP (Gonzalo Camarillo, 10)
    draft-loreto-mmusic-sctp-sdp-03.txt
    draft-ietf-tsvwg-dtls-for-sctp-00.txt
    -------------------------------------

Gonzalo presented SDP extensions to support SCTP.  The draft defines
two new protocol identifiers ('SCTP' and 'SCTP/TLS') as well as the
use of the 'setup' and 'connection' attributes to establish SCTP
associations.  Since no-one so far has implemented SCTP/TLS and it has
some issues, one suggestion is to remove it and use DTLS/SCTP instead,
as documented in draft-ietf-tsvwg-dtls-for-sctp-00.txt.

Gonzalo discussed the use of SDP and SCTP with multihoming (see the
slides for details).  Specifically, SCTP can exchange additional
addresses in-band without signaling them via SDP.  This creates an
issues with SBCs that would not be aware of these additional addresses
(and could block them).  This could be resolved by using a 'main'
address in the SDP c= lines and use re-INVITEs whenever a new set of
addresses is chosen.  While cumbersome and inefficient, this would
make those addresses visible to SBCs.

A quick inquiry revealed that there is limited interest in the
audience; only a few people had read the draft.  This will be
progressed as an individual contribution for the time being.