Subject: [AVT] Draft first-half minutes for AVT @ IETF 55 Atlanta

From: Stephen Casner <[email-masked]>
Date: Mon, 9 Dec 2002 12:38:53 -0800 (PST)

Audio/Video Transport Working Group Minutes

Reported by Stephen Casner and Colin Perkins

The AVT working group met in two sessions at the 55th IETF meeting in
Atlanta.  In the first session, the group discussed RTP payload
formats for MIDI, DTMF digits and tones, iLBC speech, ATRAC-X audio,
and uncompressed video.  The session ended with an important
discussion of the issues to be resolved for IESG approval of Secure
RTP.  In the second session, the discussion focused on RTP payload
formats for MPEG-4 and JVT video plus RTCP extensions for voice
quality reporting and for SSM sessions, and RTP retransmission.  A
bonus topic on the RGL codec and payload format was squeezed in at the
end.

  Introduction, Document Status, and Open Issues

This meeting began with an update by Steve Casner on document
publication status, including a few issues identified for documents in
the queue.  One RFC was published since the last meeting (RFC 3389 on
Comfort Noise payload format), two are in the RFC editor queue (the
MIME registration for the payload formats in the RTP profile and the
SDP bandwidth modifiers for RTCP bandwidth, both blocked on the RTP
specification), and seven are with the IESG.  Of the latter, two are
the RTP specification and A/V profile (revisions of RFC 1889 and 1890)
which have been "tentatively approved".  Final approval is pending
preparation of a set of "RFC Editor notes" to be passed with the
drafts to the RFC Editor to implement the changes requested by the
IESG and the resolution of comments by the working group while the
documents have been under IESG review.  Steve Casner will prepare
these notes for approval by the Area Directors.

Some of those RFC Editor notes implement the resolution of an issue
with the RTP A/V profile that was raised just before the previous
(54th) IETF meeting.  This was a request to change the sample packing
order for G.726 audio encoding to be consistent with the packing order
for ATM AAL2 transport as specified in ITU-T Recommendation I.366.2
Annex E.  A request for comments on the proposal to make this change
was sent to at least ten relevant mailing lists in IETF and ITU-T.
The number of comments was surprisingly small, which indicates that
there may not be many implementations of G.726 transport in RTP.
However, the comments did indicate that both packing orders are in use
and that there are parties opposed to making the change in addition to
the those who proposed the change.

The conclusion reached by the chairs in consultation with the Area
Directors is that we need to define MIME subtypes for two payload
formats reflecting the two packing orders.  We generally prefer not to
have multiple choices because of the risk of incompatibility that
imposes, but we are forced into it in this case by an incompatibility
that already exists.  Furthermore, both packing orders are specified
in separate areas of ITU-T (AAL2 and X.400 mail).  In order to make
clear the incompatibility between the existing G726-* payload formats
and the AAL2 packing, we will add a note in the A/V profile section
that specifies those formats to note the incompatibility and say that
a second set of payload formats named AAL2-G726-* will be specified in
a separate document.  Or, if the IESG agrees, the AAL2-G726-*
specification will be added as a new section in the profile.  One
problem would be that the profile is to be published as a Draft
Standard, which means there should first be two interoperable
implementations.  Alternatively, a separate draft can be produced
quickly to be published as a Proposed Standard.

Flemming Andreasen asked why not make the existing G726-* names
indicate the AAL2 packing and make up new names for the existing
payload formats for RTP.  The primary justification for that approach
would be if most implementations used the existing name to indicate a
payload format with the same packing as ITU I366.2.  That appears not
to be the case.  The real issue is not the name but the interpretation
of static payload type 2 which is assigned to G726-32, since most
implementations are probably using the 32K rate and using the static
payload type rather than the MIME name.  This incompatible
interpretation exists and can't be avoided.  Consequently, we will
deprecate the use of static payload type 2.  All systems should
negotiate a dynamic payload type using the MIME subtypes G726-32 or
AAL2-G726-32 depending upon which packetization they want to use.  A
longer summary of the comments and the details of the conclusion was
posted by the chairs to the AVT mailing list on November 14, just
before this meeting.

Five other drafts have been submitted to the IESG but not yet accepted
for publication.  These include enhanced CRTP and TCRTP, the secure
RTP profile, the payload format for EVRC/SMV speech, and the payload
format for distributed speech recognition.  Our Area Director Allison
Mankin asked for some changes on ECRTP and TCRTP; revisions were
submitted.  Discussion of the issues for the secure RTP profile is
covered later in these minutes.

Several drafts are in (extended) working group last call.  The RTCP
feedback profile draft was updated for this meeting to address
comments from the last call, but the authors did not have time to
complete a "wording cleanup" pass they want to do, so we will wait for
that and give the WG a last chance to read it before passing it on to
the IESG.  Steve Casner asked Carsten Burmeister to update and
resubmit the Informational feedback simulation draft so it can
accompany the feedback profile to help convince the IESG that
congestion control issues have been properly addressed.  The MPEG-4
payload format has been revised to address comments regarding the
section on interleaving; those were discussed in the second AVT
session.  Two drafts specify unequal error protection: the ULP and UXP
FEC mechanisms.  At the previous AVT meeting, Steve Casner requested
that the ULP draft be changed to update and replace RFC 2733 FEC
rather than extend it.  The motivation is to correct an unfortunate
design choice in RFC 2733 resulting in the X, P and CC bits in the RTP
header not following the usual rules (these bits are the XOR of the
bits in the protected packets instead) and thus requiring a special
case for header validation.  A new draft-ietf-avt-ulp-07.txt was
submitted in response to this request, but the new design repeats all
of the RTP header in the FEC payload so the overhead is too large at 7
octets.  It may be possible to just insert the problem bits into the
FEC header by reducing the mask size instead.  This will be discussed
with the authors, and others are asked to comment as well.  Finally,
the SMPTE 292 video draft completed last call in October but needed a
few tweaks to the security considerations and references.

Steve also mentioned one new document this is not otherwise on the
agenda: draft-kreuter-avt-rtp-clearmode-00.txt, a CLEARMODE payload
format that is just the same as PCMU (G.711) audio except that the
bits carry ISDN data rather than audio.  A question is what media type
should be used in an SDP description since the bits are not
necessarily audio.  There is also the possibility of charter overlap
with PWE3 working group.  Comments are requested.

  MIDI Wire Protocol Packetization (MWPP)

Colin Perkins, sitting in for John Lazzaro, gave an update on the MIDI
Wire Protocol Packetization (draft-ietf-avt-mwpp-midi-rtp-05.txt).
This revision incorporates many changes reflecting WG comments (the
change log itself is 2 pages).  There are about 20 open issues
remaining, however; John plans a -06 revision early in the New Year to
list those issues and proposed resolutions, and then a -07 revision to
incorporate the consensus and be ready for working group last call.
This normative draft on the payload format is now accompanied by a new
informative draft intended as an implementers guide for MWPP.  It
includes a walk-through of sample coding techniques intended to help
those in the MIDI community who are totally unfamiliar with RTP
applications.  The new draft is not finished; comments are requested
on the approach and what should be added or removed.

In parallel with the document preparation, a reference implementation
of MWPP in the sfront program is tracking the spec for validation.
The MIDI Manufacturers Association has also provided comments and
positive feedback on the MWPP work.  John has also been contacted by
an IEEE WG that is forming to develop transport of MIDI directly over
Ethernet (without IP).  He asks whether there are any standards or
work on using RTP, SDP, RTSP, and SIP in that mode.  Anyone with
information should let us know.  One answer would be, "Don't do that."

  RTP end-to-end liveness test

Henning Schulzrinne presented a topic resulting from a discussion on
the mailing list:  Flemming Andreasen had asked whether the RFC 2833
tones payload format could be extended to include an active end-to-end
liveness test (an RTP "ping").  The purpose is to detect problems
above the IP level that might be induced by NATs or firewalls; some
risks are that the function could be used for DoS attacks or result in
multicast implosion.  One solution, which doesn't require anything
new, is to just rely on RTCP reception reports.  A dummy RTP packet,
perhaps with no payload, can be sent if no real traffic is being sent.
RTCP already accommodates multicast scaling, although the consequence
is that the RTCP response is not immediate.  The delay is probably not
an unreasonable wait.  Not all receivers implement RTCP, but you can
distinguish that case from a problem in the RTP forward path by
whether you don't get any RTCP at all or just don't get an RR
indicating receipt of the RTP packet.  A second solution involves
signaling (e.g., in SDP) an RTP "ping" capability, then sending a
special type of RTP packet that would elicit a response packet sent to
a signaled address or to the source address/port of the request
packet.  But this solution poses the potential for DoS and implosion
problems requiring complicated solutions some of which are already in
RTCP.  That's likely a killer.

Flemming favors the RTCP solution, but wants faster response in the
case of success.  Could the RTCP interval be reduced?  Steve Casner
responded that the RTCP feedback timing rules would be appropriate.
Dave Oran asked why we need a dummy packet, why not just send comfort
noise?  Magnus Westerlund pointed out that works fine for audio
sessions.  For others, an empty payload may be needed.  Flemming
confirmed this because in some SIP scenarios early media packets can
cut off ringback tone.  Dave continued that this was all started by
people who don't do RTCP... they should just do it!  Roni Even said
monitoring RTCP is important because if the other side dies, there may
be no other indication that the packets go into a black hole.  Maybe
this just needs a hints-for-implementers document.  Henning will put
the discussion on his RTP web page.

  RTP Payload for DTMF Digits, Tones and Signals

Henning Schulzrinne discussed draft-ietf-avt-rfc2833bis-02.txt, which
updates the payload format for DTMF tones in RFC 2833.  This payload
format transports DTMF and other tones in the form of named events as
an alternative encoding the tone waveform with low fidelity when a
high-compression codec is in use.  There is also a second mode in
which tones are specified by their component frequencies.  An amazing
amount of email has been received with comments and requests for
additions, so many people must be implementing and using this payload
format.  The changes from the -00 revision are:

  - Addition of a formal notion of state to clarify that signals such
    as on/off-hook and the ABCD bits used on T1 trunks represent sets
    of states out of which only one can be active.  Also, the notion
    of soft state was added for signals that reset to default value
    after a period of time.

  - Clarification that events longer than the maximum duration (about 8
    seconds for 8 kHz RTP clock) can be expressed as the concatenation
    of multiple events.

  - Clarification of which tones can meaningfully have a volume
    specified.

  - Addition of a few data tones and clarification of the meaning and
    naming of ANS signals.

Colin Perkins expressed concern that the state additions may be
introducing too much application semantics into the protocol.  Henning
responded that the concern is understood, but that for the few cases
that exist the semantics are already fixed.

There are two open issues.  The first is that some signals (in
particular MF R1 signals) have acquired different names or
descriptions over the decades, some of which are not even documented
well by the ITU, so help is requested to supply definitive references
for the complete and correct text.  The second issue is more
significant.  Some (potential) users of the payload format want to
pass the signals required for fax setup and negotiation, but this
involves a non-trivial number of bits sent as 300-baud V.21 modem
data.  Sending these bits as a sequence of tones is very inefficient
at one symbol (tone) per packet.  This could be improved in various
ways, but any significant improvement would require redefining the
fields of the payload format to be interpreted differently.  There is
a real concern is that we're slipping down a dangerous slope of
mission creep: this is not a signaling protocol.  The purpose of this
payload format is to convey tones with more fidelity than low-rate
codecs can provide, and to allow the receiver to avoid the need to
implement tone detection for some scenarios.  Do we want to support a
full-featured fax negotiation as a sequence of named events?  Or
should we say that if you want to do fax you should do T.38 or
whatever else might be appropriate, and deprecate what is in RFC 2833
for V.21 now.  Either extend to do the whole job in a reasonable way,
or don't do it at all.

*** The next person introduced himself, and gave his affiliation as
*** Brooktrout, but I can't accurately hear the name on the audio tape
*** of the session and there is no plausible match on the blue sheets.
*** Please tell me if you know the name.

Jim Gerapredy (?), who has participated in IP-FAX standards work,
commented that T.38 has its pluses and minuses.  A number of people
in ITU might be interested in an RTP-based alternative to T.38, but he
questioned whether it is worth doing at this point in time.  Flemming
Andreasen agreed that this payload format shouldn't be a new way of
sending fax, but there is a strong need for it in the initial phases
of call establishment (V.8, V.8bis, V.25), and most of these signals
are sent using V.21.  Steve Casner took off his chairman's hat to
express the opinion that we should do nothing more than provide for
the sending of tones.  If it is feasible for some applications to send
each bit of V.21 data as a tone in one RFC 2833 packet, that's fine,
but we should do nothing to provide a higher-density representation.
Flemming asked for a review of the code points that are included; the
CI signal is there, but TM and JM are not, and might be useful.

Henning said the important point is to get this work completed, and
that requires interop testing to allow advancing to Draft Standard.
The number of points in the matrix is large, including features such
as redundancy; plus for each codepoint the matrix need to state what
it means to be supported.  One attendee indicated that the tones
portion of the draft (specified by frequencies) has been implemented,
but a second would be needed for interop testing.  Robert Sparks has
posted an initial draft of the matrix and others have volunteered to
help.  They plan to gather as much interop input as possible at SIPit,
but for those who are not going to be there, please send interop input
to Robert Sparks (see draft-sparks-avt-2833-interop-00.txt).

An attendee asked if other forms of DTMF-represented coding can be
added, e.g. some signaling supplementary services as defined by
Telcordia related to voiceband data transmission.  Henning replied
that there is more room to add tones that fit the design of the
payload format.  If there is something that exists now, and
preferably is already implemented since we want to get to Draft
Standard, send the info: common name, succinct description, and
citable reference.  However, the list is intended to be extendible
after the draft is published; there is an IANA registration mechanism.

  Payload format for iLBC Speech

Alan Duric presented an update of two drafts on the iLBC speech codec
and its associated payload format, in draft-ietf-avt-ilbc-codec-00.txt
and draft-ietf-avt-rtp-ilbc-00.txt, respectively (each was preceded
by two revisions as individual submissions).  Extensive changes were
made to the iLBC codec since last meeting.  The number of bits per
frame was reduced from 416 to 399 bits to fit in 50 bytes while at the
same time the quality was improved and the complexity was significantly
reduced (to less than G.729a).  A/B tests by the authors and by third
parties confirmed the quality improvement which derives from the
addition of a 57th sample in the quantized residual state and an
increase in the number of bits allocated to gain (utilizing bits freed
elsewhere).  A demo SIP client with the iLBC codec is available by
request from [email-masked].

Steve Casner asked why the 400th bit should not be used for something
more than setting it to zero.  Alan replied that several ideas have
been proposed and that these will be sent on the mailing list.  Steve
also commented that the codec seems to be still changing a lot.  We
don't want to progress this until the codec format has stabilized.
Alan responded that no further changes are expected on the codec
itself.  This round of changes completes the work on reduction of
frame size and complexity as planned.  Plans for a 20ms frame option
may be dropped because the need does not appear strong.  Comments on
that are requested.  Work on voice activity detection is ongoing; this
may be paired with the RFC 3389 Comfort Noise.  That work is expected
to be completed in time for interop testing planned for the next SIPit
in February.

Steve asked whether the sorting of bits for ULP is intended to be
applied across frames, because the payload format draft is not clear
on this.  The answer is yes.  Steve said that is appropriate
(otherwise the sorting does no good), but it is a lot of work which
gives no advantage in environments without ULP at lower layers.  It
may be necessary to allow both sorted and unsorted modes as in the AMR
codec.  We'd like feedback from implementers about the cost and
utility of the ULP sorting.

Alan asked about the possibility of adding another document giving the
qualification criteria for the codec.  Steve replied that this would
need to be standards track to be effective, but the status even of
standardizing the codec itself is still not entirely clear.  Generally
IETF avoids conformance testing.  Stephan Wenger asked when the
general issue of standardizing media codecs in IETF will be resolved.
Steve Casner replied that, although the Transport ADs were consulted
and were in favor of this work before it started, we won't know the
answer for sure until the work is submitted to the whole IESG for
approval.

  RTP Payload Format for ATRAC-X

Matthew Romaine present a new payload format for ATRAC-X audio in
draft-hatanaka-avt-rtp-atracx-00.txt.  Sony's ATRAC family of
perceptual codecs is used in MD's and solid-state recorders.  The -X
version supports multiple channels in a wide range of data rates from
8kbps to 1.4Mbps.  The payload format supports multiplexing of
multiple streams and metadata within a single session, redundant data
to mitigate packet loss, and fragmentation.  The draft details the
segmentation of streams into segments and the association of segments
from different streams in the same time slot.  Two open issues were
identified; the first was how to manage the allocation of metadata
identifiers.  Some appropriate body could static identifiers, as is
done in MIDI, or the assignments could be a dynamic free-for-all.
There was no input on this.  The second issue is the determination of
the RTP timestamp: the draft currently specifies transmit time, but it
has already been pointed out that a presentation (sampling) timestamp
is needed to allow synchronization with other streams.  The problem is
that a single session might carry multiple sampling rates.  Steve
Casner offered the example of MPEG audio in which the timestamp clock
rate is always 90kHz synchronized to the sampling clock, which may
vary in rate.  Could a similar arrangement be used here?  Magnus
Westerlund suggested that if different rates are needed, perhaps
different RTP sessions should be used.

Steve Casner asked why the multiplexing of streams built into the
payload format rather than using multiplexing at the UDP/RTP level.
Is the format derived from something already in use on MD or other
media and therefore hard to change, or is it a new design that is part
of the payload format and therefore open to discussion?  Matthew
responded that the format was developed with streaming in mind; it is
supposed to be extensible.  Multiple bit rates are supported for
scalable QoS, and they have specified multi-channel configurations up
to 7.1 but it could be expanded to 32 channels.  The benefit is
payload overhead.  Steve asked how this would be used for QoS: keep
some parts of the packet and throw away others?  That does not work.
It might make sense for the file format to contain multiple rates for
scalability, but the packets should only contain the rate appropriate
for the receive or you have not achieved the goal of fitting the
available bandwidth.  If you need to deliver different rates to
different receives, send different streams, or layered coding for
multicast.  Roni Even echoed this concern; if the multiplexing of
streams is for redundancy, the draft needs to explain the relationship
between the fragments, redundant segments, etc.

Colin Perkins asked why redundancy was built into the payload format
rather than using RFC 2198.  The authors were unaware of 2198.  Steve
also pointed out that for redundancy to be useful the redundant copy
may need to be separated further in time than one slot.  He also
suggested that it would be useful for the authors to review several of
the other payload formats since several of the architectural ideas
commonly used in AVT have been missed, such as separate streams for
separate needs.

Magnus asked if is it possible for fragments to be independently
decoded, or must a segment be fully reassembled to decode it.  Matthew
said the answer depends on the encoder, and needs to look into this
further.  In summary, this payload format may need quite a bit of
change from what is defined so far.

  RTP Payload Format for Uncompressed Video

Ladan Gharai presented updates to draft-ietf-avt-uncomp-video-01.txt.
In addition to the correction of editorial nits and the inclusion of
an applicability statement and a comparison to RFC 2431 (BT.656
video), some new features were added: 12- and 16-bit sample sizes join
to the 8- and 10-bit sizes specified previously, and monochrome,
4:4:4:4 chrominance subsampling, and RGBA color representations were
added.  The payload header was unchanged except that the 'M' bit was
renamed 'C' to avoid possible confusion with marker bit in RTP header.
The draft has established a list of mandatory SDP fmtp parameters and
a partial list of optional parameters.  The authors are still working
on the representation of these parameters, but will complete this work
for the next draft.

Ladan identified a few open issues.  Currently only packed sample
formats are provided; the authors are considering adding planar and
macro-blocked formats as well.  The planar format, in which color
planes are sent separately, is straightforward; it would be identified
by an SDP parameter.  However, it is unclear whether it makes sense to
have packed and macro-block formats in the same payload format.  To
accommodate macro-blocks, width and length parameters would have to be
added to the payload header (there is room), and then the packed
format would be indicated by a macro-block size of 1.  Stephan Wenger
would like to see the planar representation added, but has doubts
about a macro-block-based scheme.  There are applications for which it
would be useful, but there are too many complications related to
interlacing.  You can't assume that the shape of a macro-block will be
16x16 in a progressive scan or in one field.  Sometimes a macro-block
is a different size with parts from both fields.  It is also affected
by transcoding.

A second open issue is the transport of interlaced 4:2:0 color
subsampling.  This has been discussed on the mailing list and work is
still in progress.  Lastly, for interlaced video, there is a question
whether the two fields should have distinct timestamps.  A problem is
that for the current 90kHz timestamp clock rate which increments at
3003 for 29.97fps NTSC video, a fractional increment of 1501.5 would
be needed for the intermediate field timestamp, but the RTP timestamp
is an integer.  It should be possible instead to derive the timestamp
from header bits and the frame rate.  Stephan explained that you need
to have a timestamp for every field in order to indicate the proper
mapping of fields between 24fps film content and 30fps video using
3-2-pulldown because an individual field may be repeated so they do
not always appear in even-odd pairs.  However, we don't worry about
the exact timestamp value for this, it would be safe to round up to
the next integer.

  Resolution of comments on draft-ietf-avt-srtp-05.txt

The first session ended with a discussion of IESG security concerns
regarding the Secure RTP (SRTP) profile.  For this discussion, Allison
Mankin introduced herself as the Transport AD for this group, Eric
Rescorla as security advisor to the Transport Area, and Steve Bellovin
who is one of the Security Area Directors.

[This discussion was captured on the second audio tape and will be
covered in the second half of the minutes written by Colin Perkins.]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt