[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[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 at ietf.org
https://www1.ietf.org/mailman/listinfo/avt