[AVT] Draft minutes for Paris meeting

Folks,

Enclosed are draft minutes from AVT in Paris. Comments and  
corrections to the chairs please.
Colin

Audio/Video Transport (AVT) Working Group Minutes
=================================================

Reported by Colin Perkins

    The AVT working group met twice at the 63rd IETF meeting (August  
2005,
    Paris). Subjects under discussion includes using SMPTE timestamps  
with
    RTP, new extensions to RTCP XR, an RTP payload for ECN probing,  
packet
    reordering in ECRTP, RTP header compression over MPLS paths,  
using RTP
    with TFRC, a FEC streaming framework, RTCP extensions for SSM  
sessions
    with unicast feedback, RTP payload formats for EVRC, G.722.1 and  
VC-1,
    and codec control messages. The meeting was chaired by Colin Perkins
    and Magnus Westerlund. There were approximately 80 attendees at each
    session.

Introduction and Status Update

    The chairs introduced the meeting, with the usual status review. The
    group has had four RFCs published since the last meeting, six others
    are with the RFC editor, and we have eight drafts under IESG review.
    The new working group charter and milestones have been approved; see
    the web page for details.

    Discussion regarding the use of the media types registry to name RTP
    payload formats is ongoing, although progress since the last meeting
    has been limited. Roni Even expressed concern that the discussion is
    delaying progress of several payload formats; the chairs agreed that
    this is a significant problem.

RTP extensions for SMPTE time codes

    draft-singer-rtp-hdrext-00.txt
    draft-singer-smpte-rtp-01.txt

    Dave Singer briefly outlined the contents of the drafts, and  
requested
    input from the working group.  The main open issue is the  
registration
    rules for header extensions, which need to include a date as well  
as a
    reverse DNS name. The group accepted both drafts as work items.

RTCP XR VoIP Metrics Management Information Base

    draft-ietf-avt-rtcp-xr-mib-02.txt

    Amy Pendleton discussed the RTCP XR VoIP metrics MIB, outlining  
changes
    since the previous version (see slides). Several implementations  
exist,
    and it is believed there are no significant open issues. One item  
still
    to do is to incorporate the Session Table into the RTP MIB,  
otherwise
    the draft is believed complete.

    Colin Perkins asked if incorporating the Session Table into the  
RTP MIB
    would cause any backwards compatibility issues? Dan Romascanu  
commented
    that the semantics of the MIB change (due to the extra table),  
but it's
    otherwise an extension that won't break anything.

    Dan Romascanu noted that there are still some places in the draft  
which
    refer to the old MIB structure, and need updating. He will  
propose text
    to correct these.

    Magnus Westerlund and Dan Romascanu noted that it's unclear how the
    source and destination fields are handled in multiparty conferences.
    The entries in the Session Table should be clarified, perhaps using
    the terms "local" and "remote"?

RTCP XR - New Parameter Extensions

    draft-clark-avt-rtcpxr-bis-00.txt

    Amy Pendleton discussed new parameter extensions to the RTCP XR  
block.
    The feedback from the previous meeting was to define a separate  
draft
    for video metrics - this hasn't been done yet, but will occur  
shortly.
    The present draft includes basic video metrics, and the more  
developed
    high resolution audio metrics (see slides for a summary of the  
changes).

    Colin Perkins and Magnus Westerlund expressed concern about the  
number
    of options and possibilities for vendor extensions in the new HR  
Voice
    Metrics block. Rajesh Kumar commented that there are various  
standards
    for jitter measurement that exist and must be reflected, hence  
the use
    of so many options. Colin agreed, stating that he didn't ask to  
remove
    all the options, just to use caution in adding only those which  
fulfil
    a real need.

    Colin Perkins and Dave Oran expressed concern about partial  
duplication
    of information between the RTCP XR block and the SDP signalling.  
Colin
    was of the opinion that this information can be retrieved from  
the SDP
    and doesn't need to be included in RTCP XR. Dave accepted the  
potential
    usefulness of this information, but was opposed to duplicating it  
in a
    different format: either include the complete SDP data, or rely  
on the
    signalling protocol.

RTP Payload Format for ECN Probing

    draft-alexander-rtp-payload-for-ecn-probing-01.txt
    draft-babiarz-tsvwg-rtecn-04.txt
    draft-alexander-rtecn-use-cases-00.txt
    draft-alexander-congestion-status-preconditions-00.txt

    Corey Alexander presented a proposal for an RTP Payload Format  
for ECN
    probing, which can be used for congestion-based admission  
control. The
    SDP aspects of this were presented in MMUSIC; and the drafts were  
also
    discussed in TSVWG.

    Dan Wing questioned the use scenario: what is meant by admission  
control,
    since there is no guarantee of resource availability? The  
mechanism will
    allow the state of the network to be measured, but it's unclear  
what can
    be done with that information: a measurement of the congestion  
state for
    a particular point in time implies nothing about the future state  
of the
    network.

    Colin Perkins noted that this proposal uses RTP in a manner that  
is far
    from the usual semantics: no media data is conveyed or played  
out. This
    implies that it's not an appropriate use of the RTP protocol.  
Dave Oran
    agreed, but noted that there is a desire to make probing packets  
appear
    similar to data packets. Joerg Ott wondered why appropriately  
sized and
    spaced UDP packets can't be used to probe the path, before the  
RTP flow
    starts.

    Michael Ramalho noted that while this format may not be suitable for
    admission control, it can be used to provide an indication that some
    requested level of QoS is not available. Colin Perkins agreed  
with the
    concept, but noted that ECN could be applied to standard media  
streams
    for that purpose, without needing a new payload format.

    Finally, Colin Perkins noted that, for this to be useful, it must be
    applied to all media types, including text. Colin thought it likely
    that a MIME registration for this format under the "text" top-level
    would receive considerable push back during the media types review.

Packet reordering in Extended CRTP (ECRTP)

    draft-koren-avt-ecrtp-reorder-01.txt

    Andrew Johnson discussed packet reordering and ECRTP, explaining  
how a
    decompressor can handle various jumps in sequence number that  
might be
    caused by packet reordering. The group was asked to consider the  
draft
    as a work item: the chairs agreed that it covers appropriate  
material,
    but Magnus Westerlund requested that the draft include more  
details on
    the protocol changes, use cases, and limitations before it be  
accepted.

Protocol Extensions for Header Compression over MPLS

    draft-ash-avt-hc-over-mpls-protocol-01.txt

    Jerry Ash presented protocol extensions for header compression  
over MPLS
    paths, reviewing the changes and outlining the open issues (see  
slides).
    Colin Perkins commented that the protocol constants needed to  
implement
    this are scattered over several drafts, which makes this hard to  
follow.
    Otherwise, this is progressing well, and will become an AVT work  
item
    now the new charter is in place.

RTP Profile for TCP Friendly Rate Control

    draft-ietf-avt-tfrc-profile-04.txt

    Ladan Gharai outlined the changes to the RTP profile for TFRC  
since the
    last draft (see slides).

    Dave Oran asked if there is a need to describe how to combine  
this with
    the AVPF and SAVPF profiles? Colin Perkins that the timing rules  
may be
    difficult; Anders Klemets agreed, but noted that feedback packets  
might
    be useful in conjunction the TFRC profile. Should consider  
defining the
    TFRC profile to allow AVPF packet types, with different timing  
rules.

    Stephan Wenger commented that he believed the introduction of a  
second
    timestamp to be long overdue in RTP, and asked why not add more  
timing
    info? e.g. decoding timestamp, presentation timestamp, etc.   
There was
    some discussion of the merits of this, but no conclusion was  
reached.

    Magnus Westerlund wondered if additional guidelines were needed  
for how
    applications should handle media in conjunction with congestion  
control.
    Ladan agreed that this is a difficult subject, but didn't include  
it to
    avoid overlap with Tom Phelan's draft on Strategies for Streaming  
Media
    Applications with TFRC.

Strategies for Streaming Media Applications Using TFRC

    draft-ietf-dccp-tfrc-media-00.txt

    Tom Phelan outlined the draft on streaming media and TFRC,  
explaining
    some issues that arise when designing congestion controlled  
streaming
    media applications. This was discussed more in the DCCP working  
group.

FEC Streaming Framework

    draft-watson-tsvwg-fec-sf-00.txt

    Mark Watson outlined a proposed FEC Streaming Framework, building on
    work done in RMT and 3GPP to provide an FEC layer that can be used,
    amongst other things, to provide protection for RTP flows. This was
    discussed in detail in TSVWG.

RTCP Extensions for SSM sessions with unicast feedback

    draft-ietf-avt-rtcpssm-09.txt

    Joerg Ott discussed the RTCP extensions for SSM with unicast  
feedback,
    the latest version of which has been reworked to separate the  
concepts
    of media source and distribution source. The remaining open issue  
is how
    to signal the link from media source to distribution source in  
SDP: the
    proposal is to make this a separate session at the SDP level,  
hiding the
    details from the receivers. Colin Perkins asked that the draft  
clarify
    that there is a single RTP session, despite it being separate at  
the SDP
    level, but otherwise there was general agreement on this choice.

    Dave Oran asked if there are any exceptions for RTCP packets that  
don't
    need to be reflected down the tree (e.g. NACK feedback packets?)  
and if
    the document needs to say something about this? Joerg replied  
that there
    is some wording related to this about summary reports, but that  
in the
    reflection mode you'll get compound packets, and it may not be  
possible
    to split out the subpacket when reflecting (e.g. due to  
authentication).
    Need to think about it, and include some words.

Update of ITU G.722.1 payload format

    draft-even-avt-rfc3047-bis-01.txt

    Roni Even discussed the updated payload format for G.722.1  
(adding 14kHz
    support to the RFC 3047 format). Magnus Westerlund noted that  
there is a
    need for clarifications on how the RTP marker and sequence number  
are to
    be handled, but there was otherwise little discussion because the  
format
    is not complex. The sense of the room was to accept this draft as  
an AVT
    work item.

RTP Payload Format for Video Codec 1 (VC-1)

    draft-klemets-avt-rtp-vc1-00.txt

    Anders Klemets outlining key features of the VC-1 codec, and  
described
    the payload format specification.  Discussion related primarily  
to the
    coupling of RTP timestamp to decode time, rather than the  
presentation
    time. Dave Singer noted that RTP payload formats generally set  
the RTP
    timestamp equal to the presentation time and send in decode time  
order,
    and there are good consistency and backwards compatibility  
reasons to
    stick with this if possible. Dave also had some concern about how  
one
    could calculate the presentation time from potentially missing  
packets,
    wondering if it's always possible to calculate? Including an  
explicit
    presentation time would avoid this problem.

    Stephen Wenger also spoke in favour of using the presentation  
time as
    the RTP timestamp. He noted that this codec seems similar to MPEG in
    its timing model, and wondered if the decode time was actually a  
time
    or just a sequencing concept. If the only requirement is sequencing,
    then the RTP sequence number is sufficient, rather than including  
the
    decoding timestamp.

    Finally, Magnus Westerlund noted that using the decoding time for  
the
    RTP timestamp breaks the RTP synchronisation model, since there  
is no
    longer have a common timebase for synchronisation between media  
(but,
    if the presentation time is used, this is equivalent to the sampling
    instant used for audio codecs).

    The conclusion was to change to using the presentation timestamp.

    The sense of the room was to adopt this draft as an AVT work item.

Open issues with Codec Control Messages in AVPF

    draft-wenger-avt-avpf-ccm-00.txt

    The final agenda item was a discussion of open issues with the codec
    control messages draft, led by Stephan Wenger.

    Colin Perkins, Stephan Wenger and Magnus Westerlund discussed the  
need
    for the Temporary Max Media Bit Rate (TMMBR) indication, to  
understand
    whether the usual RTCP mechanisms can be used to measure the bit  
rate,
    rather than requiring the sender to acknowledge the TMMBR  
message. The
    conclusion was that the acknowledgement is needed, but the rationale
    should be clarified.

    Dave Oran asked if the TemporalSpatialTradeOff (TSTR) message is not
    already in SDP? Yes, but there is a need for faster signalling  
than in
    a SIP exchange. Again, rationale to be clarified.

    Colin Perkins queried why FreezePicture Indication was needed,  
since it
    can be derived from the media stream (e.g. SSRC/CSRC will change, to
    indicate a change of source, and the decoder then parses but doesn't
    display the stream until it gets to a refresh point). Stephan  
replied
    that this is because some gateways don't correctly set the SSRC/ 
CSRC.
    Dave Singer also noted that some people don't like freeze  
picture, so
    the requirement for this is not universal. Stephan noted that he  
does
    not think this feature vital, and may remove it in the next  
revision.

    Dave Singer expressed concern that repeating requests does not  
always
    work; might want a method to stop a receiver making repeated  
requests
    to a sender that cannot satisfy them.

    Colin Perkins concluded by noting that these messages can  
potentially
    turn RTCP into a full scale control protocol, rather than a  
channel to
    convey presence, reception quality statistics and hints on the  
desired
    media coding. The draft needs to clearly set bounds on the  
appropriate
    codec control messages, and to understand the limits of what is  
being
    enabled.

                    - + -

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt