[AVT] Draft minutes from Chicago meeting

Draft minutes from the Chicago AVT meetings are enclosed. Please send  
any comments or corrections to the chairs.

Colin

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

Reported by Colin Perkins

    The Audio/Video Transport working group met twice at the 69th IETF
    meeting (Chicago, 23-27 July 2007). Subjects under discussion  
included
    DTLS extensions for keying SRTP sessions, extended reception quality
    reports for RTCP, non-compound RTCP, RTP keep alives, source  
specific
    media attributes, and various RTP payload formats.  The meeting was
    chaired by Colin Perkins, Roni Even and Tom Taylor. The blue sheets
    were signed by 94 people in the first session, and 70 in the second
    session.

Introduction and Status Update

    The working group chairs introduced the meeting, and reviewed the  
status
    of the group. Two RFCs have been published since the last meeting  
(draft-
    ietf-avt-rtp-amr-bis-06.txt as RFC 4867, and draft-ietf-avt-hc- 
over-mpls-
    protocol-08.txt as RFC 4901). The RTP payload formats for EVRC-WB  
and
    Vorbis are in IESG review, as is the SAVPF profile, the drafts  
defining
    a general RTP header extension mechanism, and the draft on the  
ULP FEC
    scheme. The draft on RTP and RTCP multiplexing is in IETF last call.

    The Codec Control Messages and Topologies drafts have completed  
working
    group last call, with some comments being made. The chairs called  
for
    reviewers to ensure these specifications can be implemented, and are
    clearly written, before we request their publication as RFCs.

DTLS Extension to Establish Keys for SRTP

    draft-ietf-avt-dtls-srtp-00

    David McGrew presented the DTLS extension to establish keys for  
SRTP.
    This is based on draft-mcgrew-tls-srtp-02.txt, which has been  
discussed
    extensively in the RTPSEC BoF, and has been adopted as an AVT  
work item
    after the discussion at the 68th IETF. It protects point-to-point  
RTP
    sessions, using a DTLS handshake on the media path to establish  
keys,
    and it defines DTLS SRTP packet processing for RTP and RTCP.

    Recent changes include a clarification that only one DTLS  
handshake is
    needed in the symmetric RTP case, the elimination of a duplicate  
list of
    SRTP profiles, and the correction of various editorial nits.  
There are a
    number of open issues:

    Open issue #1 is whether the "TLS extractor" should be used  
instead of a
    purpose-built extension to TLS KDF. This would require rewriting  
section
    3.3 of the draft. Hannes Tschofenig queried the status of the  
extractor
    in the TLS working group, and Eric Rescorla replied that his  
impression
    (without speaking for the TLS working group chairs) was that it  
would
    become a TLS work item if there was interest. Hannes also asked  
if the
    extractor is general purpose, or limited to use with DTLS SRTP -  
it is
    general purpose. Discussion was moved to the mailing list.

    Open issue #2 is whether we need a symmetry breaking rule (see  
section
    3.6.2.1 of the draft) to define what should happen when a device  
that
    sent a clientHello receives a clientHello. This would also handle  
cases
    in which the signalling can't tell which device should act as  
client and
    which as server. Colin Perkins asked if you can't solve this by  
defining
    the SIP offerer as the server, and Eric Rescorla replied that he had
    thought so initially, but there are call flows where that doesn't  
work.
    Roni Even noted that there are MCU-related call flows that  
require this
    symmetry breaking, and Jonathan Rosenberg noted that ICE has a  
similar
    feature to address this problem.  Eric Rescorla asked if the  
symmetry
    breaking tag can be included in the SDP - no, it has to be in the  
media
    path because you can't do an updated offer until after the media  
begins
    to flow, unless you also do reliable provisional responses. Jonathan
    Rosenberg spoke clearly in favour of including symmetry breaking,  
and
    David McGrew agreed to work on this in the TLS working group.

    Open issue #3 is whether a single DTLS session should be used per  
SRTP
    session (appendix B of the draft). The advantages of this are lower
    computation and latency, and a better match for the SRTP policy  
model.
    The disadvantage is that it differs from standard TLS practice.  
Jonathan
    Rosenberg asked if this is just for RTP and RTCP flows of a  
single RTP
    session, or if it can also work across audio and video RTP sessions.
    Eric Rescorla replied that it could in theory work across RTP  
sessions,
    but isn't currently specified that way. David McGrew noted that  
this is
    currently just sharing the DTLS handshake between RTP and RTCP  
flows.
    Colin Perkins asked if if might be simpler to mandate  
multiplexing RTP
    and RTCP on the same port when DTLS is used? Eric Rescorla and  
Jonathan
    Rosenberg enthusiastically supported this, but Flemming Andreasen  
noted
    some quality of service issues with multiplexing, and suggested  
that the
    correct solution was to encourage multiplexing, avoiding the  
issues with
    using a single DTLS session for multiple flows, and to accept  
that two
    DTLS handshakes will be required when non-multiplexed flows are  
used.

    Jonathan Rosenberg raised the issue that ICE-TCP is currently  
specified
    to send DTLS over a TCP connection in parallel to STUN, and asked if
    this caused any problems? Eric Rescorla explained that there is  
no issue
    from the DTLS perspective, provided there is an underlying packet  
framing
    protocol used over the TCP connection (which is the case in ICE- 
TCP).

    Finally, Colin Perkins noted that while the draft is progressing  
well
    technically, it is difficult to read for someone who is not a DTLS
    security expert. He will provide comments to help improve the draft
    editorially, and he encouraged others to do the same.

Audio and Video Metrics Report Blocks

    draft-ietf-avt-rtcpxr-video-01
    draft-ietf-avt-rtcpxr-audio-00

    Alan Clark presented the RTCP XR audio and video metrics drafts. The
    previous RTCP XR video draft has been split into four parts  
following
    the discussion at the Prague IETF meeting; two parts were  
discussed in
    the meeting, the other two missed the deadline and will be available
    shortly.

    Alan explained that the RTCP XR video draft has aimed for  
consistency
    with ATIS IIF WT014 and DSL Forum WT135 definitions (both in final
    closure). It included an EPSNR metric defined using a packet-based
    estimation that is being evaluated by ATIS IIF group, and a MOS-V
    metric defined in ATIS IIF WT014, and zero reference algorithm due
    to be evaluated by VQEG over the coming months. The RTCP XR audio  
draft
    contains PEAQ - ITU BS.1387 and G.1070 metric, along with others  
being
    evaluation by VQEG.

    Steve Casner asked where the ATIS IIF and DSL forum expect their  
metrics
    to be used, and Alan replied that he's kept them informed, and  
this is
    one of the transports they expect to be used.

    Kaynam Hedayat reminded Alan that the consensus of the Prague  
meeting
    was that we agreed to report raw data, rather than processed  
metrics,
    but that the metrics defined here are processed metric, derived from
    the raw data. Roni Even noted that the group doesn't have the  
expertise
    to evaluate metrics, and suggested that the RTCP XR blocks should  
report
    metrics defined by other standards bodies, rather than defining  
any new
    metrics. Alan Clark noted that there are a number of ITU, and other,
    standards that exist in this area, but that these evolve, hence  
the need
    to include new(er) metrics in the RTCP XR reports.

    Dave Oran also remembered the agreement from the Prague meeting to
    transport raw metrics, rather than processed values derived from  
those
    raw metrics, noting that, e.g., if there's a standard for  
computing MOS
    the RTCP XR reports should transport the information that would  
allow a
    monitor to perform that computation, rather than transporting the  
pre-
    calculated MOS value. He justified this by noting that raw data  
is more
    stable in the long term, since recommended algorithms change.  
Alan Clark
    explained that he doesn't think this is possible, since only the end
    system has the information it needs to compute the metrics. Dave
    disagreed.

    There was considerable discussion on the issue, with Cullen  
Jennings,
    Joerg Ott, and Tom Taylor supporting the consensus from the Prague
    meeting to transport raw metrics, for similar reasons. Ravi Raviraj
    dissented, agreeing with Alan Clark that there is a need for both  
raw
    and processed metrics, and commenting that, provided the processed
    metrics are well defined, he doesn't see an issue with including  
them.
    Dave Oran concluded the discussion by noting that he doesn't see  
this
    argument coming to closure, and suggested that both raw and computed
    metrics be transported, but in separate report blocks, with computed
    metrics being defined only by explicit reference to dated standards
    produced by other standards bodies. The chairs agreed that this is a
    reasonable compromise, and emphasised the need for strict separation
    of raw and processed metrics, and clear, unambiguous, references to
    the standards defining the processed metrics.

Report Block for IPTV Metrics

    draft-venna-avt-rtcpxr-iptv-01

    Nagarjuna Venna presented the draft defining RTCP XR report  
blocks for
    IPTV metrics. He summarised the draft, noting that it relates to RTP
    streams as specified in RFC 2250, and contains sub-blocks for MPEG
    programme and elementary streams. Feedback was solicited, and it was
    asked if there was interest in taking this as a working group draft.

    Colin Perkins, as chair, asked if anyone in the group has read the
    draft? Cullen Jennings had, but had only trivial comments, but few
    others seemed to have read the draft. Accordingly, the chairs  
deferred
    on taking this as a working group item until there was more  
interest.

    Alan Clark asked about alignment with other industry standards,  
and Roni
    Even noted that multiple overlapping drafts are not desirable.  
Kaynam
    Hedayat noted that this is similar to the MPTS draft, and that  
the two
    should perhaps be merged.

    Someone asked about drafts proposing metrics for scalable video.  
Colin
    Perkins noted that there are none yet, but the group will  
consider them
    if any are submitted. Stephan Wenger cautioned that such drafts are
    likely premature, given his understanding of the state of scalable
    coding work.

H.264 Payload optional parameters

    draft-ietf-avt-rtp-h264-params-00

    Tom Kristensen discussed new media parameters for static  
macroblocks and
    aspect ratio for the RTP payload format for H.264. This was  
previously
    discussed as draft-kristensen-avt-rtp-h264-extension-00.txt in  
Prague;
    that has been split into draft-kristensen-avt-rtp-h264- 
rcdo-00.txt and
    this draft (the RCDO draft was not discussed).

    After briefly outlining the contents of the draft, Tom noted that  
the
    ITU has ongoing work on video submode control, which will result in
    additions to this draft. The authors therefore proposed to keep this
    draft in the working group for now, and to incorporate the additions
    when the work is complete in ITU.

Non-Compound RTCP Packets

    draft-johansson-avt-rtcp-avpf-non-compound-02.txt

    Ingemar Johansson presented the draft proposing that non-compound  
RTCP
    packets be allowed in some circumstances. He noted that non-compound
    RTCP has been adopted by 3GPP (in 26.114 section 7.3.5). It can  
be used
    with both voice and video, for either RTCP APP packets, generic NACK
    packets, and for CCM TMMBR and TMMBN packets. The main open  
issues are
    how to do the bandwidth computation, and the allow_early flag in  
AVPF.

    There are two alternatives for RTCP bandwidth computation: either  
let
    both compound and non-compound RTCP packets update avg_rtcp_size, or
    only allow regular (compound) RTCP to update avg_rtcp_size. The  
latter
    is simple to implement, but risks that regular RTCP doesn't get it's
    fair share of the bandwidth (which can be alleviated using  
allow_early
    flag) and, due to the size difference between compound and non- 
compound
    packets, requires modification to the 1/16 averaging factor in  
RFC 3550.
    The other approach is more complex, but gives an opportunity to  
ensure
    that compound RTCP gets its fair share, while still enabling  
frequent
    feedback when needed.

    The allow_early flag (RFC 4585 section 3.4 (k)) limits the  
potential for
    using non-compound RTCP as a generic NACK, since it puts a limit  
on the
    early non-compound RTCP sending rate. It was suggested to allow  
this to
    be overridden, when combined with a robust bandwidth computation
    algorithm to guarantee the regular RTCP report interval. Joerg  
Ott noted
    that RFC 4585 doesn't specify compound RTCP packets, just regularly
    scheduled packets, so there may not be a need to override  
allow_early
    if the RTCP bandwidth is increased (this is option 1 from the  
slides,
    for how to do this). Magnus Westerlund agreed that this probably  
is a
    solution to this issue, and will do some analysis to confirm.

    It was asked if the draft might be appropriate to accept as an  
AVT work
    item. Steve Casner noted that the purpose of requiring all RTCP  
packets
    to be compound packets was for multicast sessions, which are now  
less
    widely used, so he thought this reasonable, provided strong  
guidance is
    given on when it is appropriate. The sense of the room was in  
agreement,
    so the chairs agreed to pursue taking this as a work item (which  
will
    need a charter update).

RTP Keep Alive

    draft-ietf-avt-app-rtp-keepalive-00

    Xavier Marjou presented the draft on RTP keep alive. This draft  
gives a
    list of mechanisms used to keep alive NAT bindings, and details  
the pros
    and cons of each. Mechanisms surveyed include 0 byte UDP packet,  
RTCP
    multiplexed on the RTP port, STUN packets, RTP packets with  
incorrect
    version number, RTP packets with comfort noise, RTP packets with  
a no-op
    payload, and RTP packets with unknown payload type. Xavier asked  
if any
    other mechanism were known (perhaps RTSP transport of RTP), and  
if we
    want to recommend one mechanism.

    Magnus Westerlund noted that RTSP encapsulation of RTP is TCP- 
based, so
    the usual TCP keep alive mechanism will be used to maintain NAT  
bindings,
    out of the scope of this document. Jonathan Lennox noted that  
there are
    often codec specific keep alive mechanisms, in addition to  
comfort noise.
    Tom Phelan noted that 0-length DCCP packets may also be used.

    Jonathan Rosenberg noted that keep alive is only one part of the NAT
    traversal problem, and it's unclear how this draft relates to the  
full
    problem. He believes that some of the recommendations conflict  
with ICE,
    and asked that the draft be updated to much more clearly specify  
how it
    fits the big picture.

    Jonathan Rosenberg also noted that multiple options for keeping NAT
    bindings alive are bad, and requested that rather than keep  
documenting
    potential methods, the draft pick one. Xavier agreed with the  
goal, but
    noted that there is no consensus on which mechanism to pick. Lars  
Eggert
    replied that perhaps this is a sign that the draft is premature.  
Steve
    Casner dissented slightly, commenting that a draft which explains  
why
    certain mechanisms don't work is valid, and that suggesting a single
    standard mechanism isn't the only use for this draft. Magnus  
Westerlund
    agreed, and commented that the draft needs much more work on the  
pros
    and cons of the alternative mechanisms, since some of these clearly
    should be documented as one "SHOULD NOT do this".

RTP Payload Format for SVC Video

    draft-ietf-avt-rtp-svc-02

    Thomas Schierl presented the RTP payload format for SVC video.  
The SVC
    codec is now essentially stable and done, as of the Geneva JVT  
meeting
    in June 2007, so there is now a need to complete this draft. Thomas
    summarised the draft, outlined the changes since the -01 version,  
and
    the mailing list discussion (see slides). The authors' to-do list
    includes fixing the packetization rules, adding signalling, and work
    on the security consideration.

    A plea for review of the congestion control section was made.

    Roni Even, Colin Perkins, Stephan Wenger, and Jonathan Lennox  
discussed
    the use of NALU type 30, and whether it might clash with future NALU
    type allocations made by JVT. It will not, since it's in "user  
space"
    intended for unregistered allocations, and is private to this  
payload
    format. It was requested that some words be added to the draft to
    explain this status.

    The main open issue is removal of the DON ordering section,  
allowing all
    modes for the base layer, and specifying a re-sequencing  
algorithm without
    the DON. This is needed for backwards compatibility with a standard
    H.264 base layer. Stephan Wenger thinks this is the right thing  
to do,
    but cautions that it will make the draft more complex, in a way  
which
    will be difficult for non-SVC experts to understand. There are some
    discussion about how to ensure backwards compatibility with Roni  
Even,
    but no objections to this approach. Colin Perkins asked if this  
change
    will impact the IPR status of the payload format, since the DON  
ordering
    was covered by Nokia IPR. Stephan Wenger explained that it would  
not -
    the encumbered technology is still present, but is not optional  
to use.

Source-Specific Media Attributes

    draft-lennox-mmusic-sdp-source-attributes-01

    Jonathan Lennox briefly presented the source-specific SDP  
attributes.
    This is an MMUSIC draft, and is being presented in AVT to ensure  
there
    are no RTP architectural issues or problems that have been missed.
    Review is solicited.

High Resolution VoIP Metrics

   draft-ietf-avt-rtcphr-01.txt

   Geoff Hunt presented the RTCP HR VoIP metrics draft, outlining  
changes
   since the previous version, and discussing how report multiplexing  
can
   be achieved.

   Colin Perkins suggested that, while the report multiplexing  
section has
   value, it is more widely applicable than this draft.  He proposed  
that
   it would be better split into a separate draft, leaving this to  
simply
   define new metrics.

   Geoff noted that control by SDP is an open issue, especially when  
talking
   to middleboxes. Colin Perkins agreed, but suggested MMUSIC and/or  
SIPPING
   need to review that, since they have the relevant expertise.

   Geoff asked about the implications of concatenation of reports,  
problems
   with long packets, and the behaviour of HR-unaware translators. Colin
   Perkins pointed to sections in RFC 3550 describing this, and  
suggested
   that the standard behaviour should be sufficient.

Using SEED Cipher Algorithm with SRTP

    (no draft)

    Seokung Yoon presented a proposal to use the SEED cipher  
algorithm with
    SRTP. SEED is a 128 bit symmetric block cipher developed by KISA  
in 1999
    and published in TTAS.KO-12.0004 and JTC1/SC 27 N3979. It is  
defined for
    use with IPsec, TLS, etc. (see slides for RFC references).

    Dan Wing and Magnus Westerlund asked how key exchange is done,  
and noted
    that there may be a need for work in MMUSIC to define the  
appropriate
    SDP signalling to use this cipher with MIKEY and/or sdescriptions.

    Hadriel Kaplan noticed that this cipher operates on fixed block  
sizes,
    and asked if RTP padding is required to pad packets to the  
correct size
    before they can be encrypted.

    It was asked that the group consider this as a work item. The chairs
    noted that new modes of operation for SRTP are in scope, so they  
don't
    see any problem with taking this as a work item, but requested an
    individual draft be submitted initially for the group to review.

Concluding Remarks

    After the published agenda had been completed, Qiaobing Xie asked  
if the
    draft on forward shifted redundancy could be taken as a working  
group
    draft. The chairs were unwilling to make such a call with no time  
for
    the group to review the draft, and suggested it be discussed on  
the list
    over the coming weeks.

				   - + -

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