Audio/Video Transport Working Group Minutes

Reported by Magnus Westerlund and Colin Perkins

   The AVT working group had two sessions during the 59th IETF meeting, the 
first on Tuesday morning, and the second on Wednesday afternoon. During 
these sessions the WG discussed RTP payload formats for different media 
codecs, RTCP Extensions for SSM, header compression requirements for MPLS, a 
NOOP RTP payload format with RTCP request hint, and a new RTP profile for 
congestion control with TFRC. 

Introduction and Status Update

   The meeting began with a status update from the chairs. Two RFCs have 
been published since the last meeting (RFC 3611 and RFC 3640) and one 
draft (draft-ietf-avt-srtp-09.txt) is in the RFC editor's queue. Five AVT 
drafts that have been reviewed by the IESG and need to be updated to 
address the review comments:

    draft-ietf-avt-rtcp-feedback-08.txt 
draft-burmeister-avt-rtcp- feedback-sim-05.txt 
draft-ietf-avt-rtp-ilbc-04.txt draft- 
ietf-avt-ilbc-codec-04.txt draft-ietf-avt-rtp- clearmode- 04.txt

   A non-working group draft that has been reviewed by the group (draft- 
jones-avt-audio-t38-03.txt) is also in IESG review, however the ITU has 
make changes to the underlying reference, and these need to be 
reflected in the draft before it can advance.

   There are two drafts awaiting AD review 
(draft-ietf-avt-uncomp- video-06.txt and 
draft-ietf-avt-rtp-retransmission-09.txt) and and one in IETF Last Call 
(draft-ietf-avt-tcrtp-07.txt). AVT has 24 working group drafts and 15 
individual drafts that are either being reviewed by AVT, or targetted to 
become AVT WG documents.

   Roni Even asked if the RFC number for SRTP has been assigned, since the 
ITU wishes to reference it. The answer is that it is possible in these 
cases to get the RFC number, and such requests should be sent to the WG 
chairs along with motivation for pre-assignment. The earlier in regards to 
any deadline such requests are expressed, the easier it is to fulfil them. 

   Magnus Westerlund reported on the status of several drafts that were not 
otherwise discussed:

   - draft-ietf-avt-rfc2833bis-04.txt has received major updates for 
clarity and to add new events, and needs review.

   - draft-ietf-avt-ulp-09.txt has been updated to address prior 
comments, and needs review. A third-party IPR notice has been received for 
RFC 2733 and this draft. The IPR holder is Lucent, who has a general IPR 
statement (see http://www.ietf.org/ipr.html). Clarification on the status of 
the IPR relating to these drafts has been sought, and will be made 
available once received.

   - draft-ietf-avt-uxp-06.txt is awaiting an update to address 
previous comments.

   - draft-ietf-avt-mpeg1and2-mod-00.txt has not been updated. It needs 
review to be able to progress towards Draft Standard.

   - draft-ietf-avt-rtp-dsr-codecs-00.txt is the result of merging the 
three separate DSR drafts. Review is needed, to see if this draft is ready 
for WG Last Call.

   - draft-ietf-avt-profile-savpf-00.txt needs review by the group, and an 
update after review comments have been given. It is hoped that it will be 
ready for WG Last Call after the update. 

   - draft-ietf-avt-rfc3119bis-02.txt has been updated and is planned to go 
for draft standard. See also interoperability draft. 

   - A new version of 
draft-ietf-avt-rtp-h264-04.txt was submitted before the meeting, but since 
then the need for some small updates has been noticed. After the update it is 
expected to be ready for working group last call.

   - draft-ietf-avt-rtp-jpeg2000-04.txt needs review. Please comment to the 
mailing list. 

   - draft-kerr-avt-vorbis-rtp-03.txt needs review. Please comment to the 
mailing list. 

   - draft-herlein-speex-rtp-profile-01 has expired, and needs to be 
updated if work is desired to progress. 

   - draft-ramalho-rgl-rtpformat-02.txt has expired, and also needs to be 
updated. Comments were provided, to be reflected in the update.

   - draft-chen-rtp-bv-02.txt needs review. The authors have requested that 
this draft become an AVT work item: comments are solicited and should be 
sent to the mailing list.

   - A number of comments on 
draft-ahmadi-avt-rtp-vmr-wb-00.txt were given during the previous IETF 
meeting, these need to be addressed in order to progress the draft. 

   - 
draft-ash-avt-ecrtp-over-mpls-protocol-00.txt is an initial proposal to 
address the requirements for MPLS header compression identified in 
draft-ash-avt-ecrtp-over-mpls-reqs-01.txt. This cannot progress until 
requirements and charter discussion have been completed.

   - draft-clark-avt-rtpmibv2-00.txt needs an update to address 
comments given on the draft. Author intends to do this in the near 
future.

   - 
draft-finlayson-avt-mpa-robust-interoperability-00.txt is an initial 
submission, on what needs to be tested to verify 
interoperability of the Robust MP3 payload format, in order to go to Draft 
Standard. 

   - 
draft-perkins-avt-rtp-reactive-fec-00.txt was a proposal on use of RFC 2733 
as a retransmission format, intended as an alternative to the RTP 
payload format for retransmission. However this proposal is IPR 
encumbered through RFC 2733.

   - 
draft-tseng-avt-rtcp-streaming-extens-00.txt received a number of 
comments before and during the last IETF meeting. These need to be 
addressed if the work is to proceed.

   Finally, the chairs asked for comments on the previously announced 
intent to advance the RTP specification and Profile for Audio/Video 
Conferences with Minimal Control (RFC 3550 and 3551) to Full Standard, 
without changes. No objections was made. 

Updates on behalf of author

   On behalf of John Lazarro, Colin Perkins outlined the status of the RTP 
payload format for MIDI 
(draft-ietf-avt-midi-rtp-01.txt) and associated guidelines 
(draft-ietf-avt-midi-guidelines-01.txt). The current versions are given as 
candidate for WG last call, to be reviewed by MMA and the working group. 
Please review and send comments to list.

   Colin also noted that the RTP framing for connection oriented 
transport 
(draft-ietf-avt-rtp-framing-contrans-00.txt) is awaiting resolution of the 
comedia draft in MMUSIC, and accordingly has not been updated.

   Unfortunately an update of Andrea Basso's Requirements for 
transport of video control commands 
(draft-basso-avt-videoconreq-00.txt) did not meet the draft 
deadlines. An update will be submitted after the meeting. This will 
clarify the terminology, cut down the command list to those used in the 
IETF. Please review this when it becomes available.

RTP payload format for AMR-WB+ audio codec 

   Ari Lakaniemi discussed 
draft-sjoberg-avt-rtp-amrwbplus-01.txt. This revision clarifies 
interoperability scenarios with AMR-WB, specifies how to signal mono and 
stereo sessions in SDP, and adds offer/answer considerations 
recommending that one declares also the non-optional parts when using 
optional features of the AMR-WB+ codec and payload format. 

   The remaining issue is to track the codec development as it is being 
finalized. It was noted that the AMR-WB+ codec has been selected as an 
optional codec to be included in the PSS and MSS services of 3GPP with 
plans to finalize the specification in May for a 3GPP release 6 
deadline that has been postponed to at least June.

   Colin Perkins asked why the Code Mode Request (CMR) field is not used? 
This is primarily because AMR-WB+ is not intended for 
conversational use, and so is not expected to be used with gateways that 
might cause rapid mode requests to be transported from the receiver to the 
sender. Colin asked for clarification of the use cases, and noted that the 
draft should also consider if it's appropriate to use the CMR fields as a 
hint for congestion control.

   Dave Lindberg asked if there is a reason for not considering AMR-WB+ for 
conversational use? The answer is that the AMR-WB+ codec has a longer 
algorithmic delay then AMR-WB.

   The opinion of the room was that the AMR-WB+ payload format should be 
accepted as an AVT work item.

Introduction of ATRAC family payload format.

   Matthew Romaine discussed 
draft-hatanaka-avt-rtp-atrac-family- 00.txt, a new RTP payload format for 
all ATRAC audio codecs. The previous attempt for an RTP payload format for 
only ATRAC-X has been abandoned due to its complexity, and to enable a 
format that encompass all codec versions. The new format is intended to be 
much simpler.

   Magnus Westerlund asked if the FrOff field is approriate, since 
changes in the number of redundant frames will change the buffering 
needed, and may force a receiver to adapt its playout delay. Colin 
Perkins remarked that such changes are commonly done before a talk spurt, so 
the playout delay can easily be various. Magnus' concern about this is that 
for an audio codec, a lot of the material is continuous without 
talkspurt-like behaviour, preventing in-band changes of the 
redundancy offset may be appropriate. Colin remarked that there exists a 
need to vary the frame offset to adapt to network behaviour anyway, so this 
shouldn't be a significant problem (RFC 2198 allows such changes in 
redundancy offset also). 

   There have also been comments about the MIME types for the payload 
format. The proposal is to have one for each codec version. There are a few 
required parameters, for example a channels parameter that contains 
different mappings of the channel, not number of channels.

   Regarding the SDP initialization, Magnus Westerlund noted that only the 
sample rate/channels can go into the "a=rtpmap" SDP attribute. All other 
parameters need to go into "a=fmtp" line. 

   The draft has made significant progress in regards to previous 
versions.

3GPP Timed Text

   Jose Rey presented 
draft-rey-avt-3gpp-timed-text-02.txt. The draft has been 
restructured and simplified by removal of advanced fragmentation of 
modifiers. Unless all modifiers fragments arrive, modifiers can't be 
applied. The structure has also be changed to be compatible with RFC 3640.

   Colin Perkins asked if it is possible to detect the number of 
characters that have been lost within a fragmented block? This is not a 
possible, however no one has raised problems with this. Colin 
requested that the draft be explicit about the limitation, to be certain it 
is handled correctly, since the handling differs from other real time text 
formats.

   The suggestion raised by Magnus Westerlund about the possibility to 
always have a length field and therefore be able to remove the L flag were 
presented, but there were no additional comments.

   Another issue is the ability to repeat modifier fragments and sample 
descriptions: it was asked if this feature should be retained, or 
disallowed in favour of external methods like FEC or 
retransmission? No suggestions were made.

   Should it be mandatory to support sample description both in-band and 
out-of-band? Colin commented that if one relies on inband 
signalling, one must measure the transport characteristics to provide 
appropriate reliability and specify what a receiver does if a sample 
descriptor is not received. Colin stressed that if one allows inband 
signalling of sample descriptors at all one needs to address these 
issues. (Name?) of University of Korea asked why not making inband 
mandatory. The issue is still that the problems with inband would need to be 
resolved. It was also commented that receivers should be able to work 
without inband sample descriptors. Receiver support of inband is not 
required, but they should at least be able to discard inband 
descriptors if the don't support them.

   Colin commented that the draft is written assuming data is sourced from a 
file. As it is possible to generate text on the fly, the draft should be 
updated to in language reflect that. 

   The authors hope this work can be completed to meet the 3GPP release 6 
deadline, which may be as early as June 2004. The chairs noted that the 
draft is still far from complete, and that work will have to proceed 
rapidly if this deadline is to be met.

   The chairs asked if this draft should be taken as a AVT WG item? The 
sense of the room was that were were few supporters, but none against. 
Hence, unless there are objections from the list, this will become an AVT 
work item.

Payload format for Text Conversation (RFC2793bis)

   Gunnar Hellström presented 
draft-ietf-avt-rfc2793bis-02.txt, noting that this version is believed to 
address all comments received to date. Magnus Westerlund raised that one 
issue that has not been addressed: when using the "audio/t140" format and 
switching between text and speech, it is possible for a packet to be lost, 
and for the receiver to be unable to determine if that was a text or a 
speech packet. This is likely not a problem, but should be better 
documented. Magnus also noted that the document is also missing a 
section mapping the MIME parameters onto SDP, and an offer-answer 
considerations section. 

   Gunnar continued with a presentation of 
draft-ietf-avt-text-red- 01.txt. Magnus raised a comment that the PT MIME 
parameter should reflect how it is actually defined in RFC 2198. Colin was of 
the opinion that it should say the same thing as the other media 
versions of RED, see RFC 3555, and any clarifications should be made when 
RFC 2198 is updated.

   ITU study group 16 has need for these documents by November. In order to 
meet this deadline, updated drafts should be produced, ready for working 
group last call by early April 2004. 

H.261 and H.263 payload parameters

   Roni Even discussed the RTP updated payload formats for H.261 and 
H.263: draft-ietf-avt-rfc2032-bis-00.txt and 
draft-ietf-avt-rfc2429- bis-00.txt. These add new codec parameters 
needed, for example, by video conference and also clarify a number of 
issues with the older RFCs. 

   An issue raised is how the Annex and profile/level parameters 
interact, for example which of them overrides the other. The proposal is to 
not use them together, to avoid this problem.

   Another issue was that only parameters that are known to be used have 
been included in these drafts. Input from implementors is solicited, 
asking if the parameters are sufficient or if any are missing. 

   The author list will also need to be trimmed to avoid problems with the 
current guidelines on number of authors. Colin commented that this is 
something the contributors will need to agree between themselves on. 
Magnus noted that correct contact information and the ability to review and 
sign off on the draft during the final "authors 48 hours" period are 
needed by anyone listed as an author.

   Colin commented that there is need for editorial pass, to check where the 
RFC 2119 normative language should be used. 

   There is interest to implement these drafts by different 
companies, and therefore this work should be moved forward. After 
another update it is hoped that WG last call will be possible. 

Verifying the media path using RTP No-Op & Preconditions 

   Flemming Andreasen discussed 
draft-wing-avt-rtp-noop-00.txt and its relation to 
draft-andreasen
-mmusic-connectivityprecondition-00.txt. This work was also discussed 
during the MMUSIC session, however mostly in regards to signalling and 
usage. The presentation in AVT was more directed towards the RTP related 
issues. 

   It was noted that Cisco claims IPR in relation to this payload format and 
it's application, and are willing to license this under reasonable and 
non-discriminatory terms. Colin Perkins asked for elaboration on the IPR. 
Flemming made it clear that the patent application is applicable to the RTP 
payload format, separate from its use with the connectivity 
preconditions.

   The payload format is intended to be used to open pinholes in NATs and 
firewalls, to verify connectivity and quality over a media path and to keep 
alive NAT and firewall bindings. As discussed in MMUSIC, there is some 
overlap between this proposal, and STUN and ICE.

   Roni Even asked why only the audio/noop MIME type is listed? The 
answer is that there is no reason for not having it for all media types in 
use. The draft is simply missing registration of all the media types that 
are appropriate.

   Dan Romascanu noted that it is not very clear from the draft how you can 
determine the actual media path characteristics through the use of RTCP, and 
how to separate the reception quality reports for the NOOP traffic from 
other media traffic. Flemming noted that the RTP SSRC can be used to 
separate traffic, and promised to work on the text, clarifying this. 

   Magnus Westerlund and Colin Perkins noted that the draft is unclear on 
the interactions between its immediate feedback request and the usual RTCP 
timers (in both the standard A/V profile and in the RTCP feedback 
profile). Clarification was requested.

   Jonathan Rosenberg was doubtful of the need to request immediate RTCP 
reports. He supported the functionality of an RTP payload format that is 
discarded, to keep NAT bindings alive when media is on hold, but asked the 
group to consider the need for requesting immediate RTCP reports and to 
clarify the problem and requirements before jumping into the solution 
space. 

   Jonathan also noted, as he did in the MMUSIC session, that ICE and STUN 
would still be needed for NAT traversal, and so can't be replaced with this 
mechanism. 

   Roni Even also commented that the use case for checking the MTU might 
need feedback, however the QoS diagnostic does look like a different 
issue. 

   Colin Perkins concluded that the draft must be updated and 
clarified on use cases, and what problems it solves.

RTCP Extensions for SSM Sessions with Unicast Feedback 

   Jörg Ott discussed 
draft-ietf-avt-rtcpssm-06.txt. This has been updated to address the 
behaviour of distribution sources and to clarify how the two ways of 
specifying RTCP receiver report bandwidth interact. Also, the security 
considerations and IANA considerations have received some 
significant updates. Colin Perkins commented that the security section now 
looks much better, and solicited review from the working group. 

   A remaining issue is to specify how sender reports unicast to the 
distribution source are to be forwarded, removing the need for the number of 
sender report block. Otherwise, while there are a few previously 
discussed issues that still need to be included, the draft is believed to be 
almost complete. 

Requirements for ECRTP over MPLS

   Jerry Ash discussed 
draft-ash-avt-ecrtp-over-mpls-reqs-01.txt, which has been updated to 
address comments raised in the last meeting and on the mailing list. 
Lars-Erik Johansson, commented that draft has been significantly 
improved and supported it becoming an working group draft. However, he 
noted that it would be good if the draft could be enhanced to better 
explain why ECRTP is the right choice, and explain the issues with using 
CRTP or ROHC as an alternative. Kristofer Sandlund commented that ECRTP is 
not that strong against reordering, and that ROHC has better 
compression efficiency. It would also be better if the draft explained what 
order of reordering that can be expected. Jerry answered that it is not 
intended to exclude ROHC from future usage. Colin Perkins clarified that AVT 
does not have the necessary experience to specify ROHC over MPLS, 
however the framework must ensure that this work can be done. 

   Allison Mankin asked if ROHC really has become resistant to 
reordering. Lars-Erik answered that currently no, however this has been 
discussed and the solution is known. However as there has been no need 
previously the solution has not been written up. Lars-Erik also 
commented that ECRTP needs to use lower layers to identify the packet 
type, which ROHC handles internally. 

   The draft was requested to become an AVT WG item. This seems 
acceptable with the current maturity of the draft, and was taken as an 
assumption. It will be expected that an updated draft be produced to 
address the comments received here. This will also need expert review from 
the MPLS community. 

   Jerry has also produced an initial draft proposing a protocol to 
address the requirements 
(draft-ash-avt-ecrtp-over-mpls-protocol- 00.txt). Colin commented that AVT is 
an appropriate temporary home this draft, until we figure out the proper 
home(s) for it. However the draft would benefit by taking a step 
backwards, to better explain the rationale for the proposed solution. 

   Allison Mankin, asked what the reason for having SIP calls in the 
draft. Jerry answered that it was put in there to illustrate the how VoIP 
and the RSVP extension would fit together. However there are no strong 
reasons for keeping it in the draft, and it can easily be moved or 
removed. Allison also stated that there definitely seems to be reasons for 
keeping the work within AVT for the moment. 

RTP Profile for TCP Friendly Rate Control

   Ladan Gharai presented 
draft-gharai-avt-tfrc-profile-00.txt, a proposal for using TFRC based 
congestion control with RTP using RTCP feedback. Her presentation 
included in a short introduction to TFRC, outlining the new 
information that needs to transported in RTP and RTCP to support the TFRC 
algorithm. The initial proposal extends both RTP and RTCP, and 
therefore needs to be new RTP profile. 

    Technical issues that exist are: 

    - The size of RTCP feedback, since RTCP packets will typically be at 
least 80 octets.

    - The size of the profile specific additions to the RTP header. The 
current proposal adds 8 octets to the RTP header.

    - The RTCP feedback rate, as TFRC either sends feedback once per sent 
packet, or once per RTT, this can be significant bit-rate. Thus the 
normal RTCP bit-rate restrictions will not provide sufficient bit-rate for a 
lot of applications. 

    It is also important to clarify the relation to the DCCP protocol. It is 
clear that DCCP provides more functionality than an RTP profile for TFRC 
congestion control, and that that functionality is useful and 
beneficial to developers. However, a new RTP profile will be easier to 
deploy, as it only involves application-level changes. An RTP profile for 
TFRC will allow application developers to experiment and gain 
experience with TFRC congestion control in the short term, with the hope of 
easing migration to DCCP in the longer term. 

    Anders Klemets asked how the use of AVPF to request 
retransmission may affect the algorithm? It is clear that 
retransmission needs to also be congestion controlled, and that the 
interactions with the changed timing rules of AVPF will definitely need to be 
considered. 

    A second question was if the TFRC algorithm implies a fixed packet 
size. Mark Handley answered that TFRC needs to know what the packet size is, 
it can be varied during a session. Sally Floyd also commented that she is 
planning to work on TFRC-PS, a variant of TFRC for applications that don't 
want to change their send rate, but instead vary their packet size. 

    The big question is: does creating an RTP profile for TFRC make 
sense?

    Brian Rosen commented that the draft would need a strong 
applicability statement explaining the effects TFRC will have on a media 
stream, and pointed to the long discussion on the AVT and DCCP mailing 
lists after the last IETF meeting.

    Mark Handley agreed that creating an RTP profile for TFRC is a good 
idea, and that it complements DCCP. Where DCCP is a long term solution with 
more benefits, a RTP profile would be a good short term solution. 

    Joerg Ott also thinks it is a good idea. However he raised concern 
about the number profiles, and the interaction between a TFRC profile and 
the current profiles. Colin commented that this is definitely an open 
issue that will need to be further considered.

    Aaron Falk requested that if this work goes forward, that any 
findings about the behaviour should be given as input to the DCCP 
working group, and especially to their user guide document. Tom Phelan also 
commented that the reverse is also true. For example the discussion in DCCP 
has already resulted in changes in CCID 3. This work should be tracked also 
by an RTP profile.

    Mark Handley commented that with the current proposal for RTP header 
changes, this profile over UDP will actually use 32-bits more than RTP over 
DCCP. In DCCP this has been achieved through the usage of 4 free bits in the 
DCCP header. There should be made some effort for finding a better way to 
encode the necessary information into the RTP header. 

    Geetha Srikantan was concerned with the fact that if an ISP is 
policing the UDP flows, how is a TFRC controlled UDP flow separated from 
other non-congestion controlled flows? It should at least be clarified what 
the assumptions are, and what can be expected. 

    Allison Mankin commented with a point she borrowed from Mark 
Handley: it is difficult to get the implementation of congestion control 
correct, with a rather large risk that there are bugs within an 
implementation. DCCP will definitely be easier for an application, since it 
can be implemented above a known-good congestion control 
implementation. 

    Colin Perkins concluded that there is certainly interest for 
performing this work. The WG will need re-chartering to take this 
aboard. This can be considered while the draft is updated to address 
comments and clarify the motivation for the work.

    - * -