2.7.1 Audio/Video Transport (avt)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       http://www.cs.columbia.edu/~hgs/rtp/faq.html -- RTP FAQ Page
NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-10

Colin Perkins <csp@csperkins.org>
Magnus Westerlund <magnus.westerlund@ericsson.com>
Transport Area Director(s):
Allison Mankin <mankin@psg.com>
Jon Peterson <jon.peterson@neustar.biz>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Mailing Lists:
General Discussion: avt@ietf.org
To Subscribe: avt-request@ietf.org
Archive: ftp://ftp.ietf.org/ietf-mail-archive/avt
Description of Working Group:
The Audio/Video Transport Working Group was formed to specify a protocol for real-time transmission of audio and video over unicast and multicast UDP/IP. This is the Real-time Transport Protocol, RTP, together with its associated profiles and payload formats. The current aims of the working group are:

- to advance the main RTP specification and RTP Profile for Audio and Video Conferences with Minimal Control for publication as full Internet Standards

- to review and revise existing payload formats to advance those which are useful to Draft Standard, and to declare others as Historic. Milestones will be established as a champion for each payload format is identified.

- to develop payload formats for new media codecs, and to document best-current practices in payload format design. The group continues to be precluded from work on codecs themselves because of overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs. An exception was made for the freeware iLBC codec on a highly experimental basis, but acceptance of new codec work is unexpected and subject to rechartering.

- to complete the forward error correction work in the ULP and UXP payload formats

- to extend RTP to work with Source-Specific Multicast sessions with unicast feedback

- to provide a framing mechanism for RTP over TCP and TLS

- to review the applicability of Compressed RTP operation on MPLS networks, developing extensions as necessary

- to develop a new RTP profile as the combination of the SRTP profile and the Extended RTP Profile for RTCP-based Feedback (RTP/SAVPF)

The group will also coordinate with the DCCP working group to ensure that RTP can be efficiently transported over DCCP.

The longer term goals of the working group are to advance the SRTP Profile, the Extended RTP Profile for RTCP-based Feedback, the Compressed RTP framework, and the RTP MIB to Draft Standard.

The group has no plans to develop new RTP profiles beyond those listed above, but will consider rechartering to produce profile level extensions if appropriate.

Goals and Milestones:
Done  Review DCCP including prototypes and API; feedback to DCCP WG
Done  Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG
Dec 03  Submit RTCP/SSM draft for Proposed Standard
Done  Submit iLBC payload format for Proposed Standard
Done  Submit iLBC codec specification for Experimental
Jan 04  Advance RTP specification and A/V profile to Full Standard
Mar 04  Finish requirements for ECRTP over MPLS; recharter for subsequent work
Mar 04  Identify payload formats to classify as Historic
Mar 04  Submit Framing of RTP for TCP and TLS for Proposed Standard
Jul 04  Begin update of RTP/AVPF profile for Draft Standard RFC
Jul 04  Begin update of SRTP profile for Draft Standard RFC
Jul 04  Submit RTP/SAVPF profile for Proposed Standard
Aug 04  Consider update of RTP MIB
Nov 04  Collect RTP/AVPF implementation reports
Nov 04  Collect SRTP implementation reports
Nov 04  Submit ULP Payload Format for Proposed Standard
Nov 04  Submit UXP Payload Format for Proposed Standard
Mar 05  Submit RTP/AVPF for Draft Standard
Mar 05  Submit SRTP for Draft Standard
  • - draft-ietf-avt-tcrtp-07.txt
  • - draft-ietf-avt-ulp-09.txt
  • - draft-ietf-avt-uxp-06.txt
  • - draft-ietf-avt-srtp-09.txt
  • - draft-ietf-avt-rtcp-feedback-08.txt
  • - draft-ietf-avt-rtcpssm-06.txt
  • - draft-ietf-avt-rtp-retransmission-10.txt
  • - draft-ietf-avt-rtp-jpeg2000-04.txt
  • - draft-ietf-avt-rfc2833bis-04.txt
  • - draft-ietf-avt-ilbc-codec-04.txt
  • - draft-ietf-avt-uncomp-video-06.txt
  • - draft-ietf-avt-rfc3119bis-02.txt
  • - draft-ietf-avt-rtp-h264-04.txt
  • - draft-ietf-avt-rtp-ilbc-04.txt
  • - draft-ietf-avt-rtp-clearmode-04.txt
  • - draft-ietf-avt-mpeg1and2-mod-00.txt
  • - draft-ietf-avt-dsr-es202050-01.txt
  • - draft-ietf-avt-profile-savpf-00.txt
  • - draft-ietf-avt-rtp-midi-format-01.txt
  • - draft-ietf-avt-rtp-midi-guidelines-01.txt
  • - draft-ietf-avt-rtp-framing-contrans-00.txt
  • - draft-ietf-avt-text-red-01.txt
  • - draft-ietf-avt-rfc2032-bis-00.txt
  • - draft-ietf-avt-rfc2429-bis-00.txt
  • - draft-ietf-avt-rtp-dsr-codecs-00.txt
  • Request For Comments:
    RFC1889 PS RTP: A Transport Protocol for Real-Time Applications
    RFC1890 PS RTP Profile for Audio and Video Conferences with Minimal Control
    RFC2035 PS RTP Payload Format for JPEG-compressed Video
    RFC2032 PS RTP payload format for H.261 video streams
    RFC2038 PS RTP Payload Format for MPEG1/MPEG2 Video
    RFC2029 PS RTP Payload Format of Sun's CellB Video Encoding
    RFC2190 PS RTP Payload Format for H.263 Video Streams
    RFC2198 PS RTP Payload for Redundant Audio Data
    RFC2250 PS RTP Payload Format for MPEG1/MPEG2 Video
    RFC2343 E RTP Payload Format for Bundled MPEG
    RFC2354 I Options for Repair of Streaming Media
    RFC2429 PS RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+)
    RFC2431 PS RTP Payload Format for BT.656 Video Encoding
    RFC2435 PS RTP Payload Format for JPEG-compressed Video
    RFC2508 PS Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
    RFC2733 PS An RTP Payload Format for Generic Forward Error Correction
    RFC2736BCPGuidelines for Writers of RTP Payload Format Specifications
    RFC2762 E Sampling of the Group Membership in RTP
    RFC2793 PS RTP Payload for Text Conversation
    RFC2833 PS RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
    RFC2862 PS RTP Payload Format for Real-Time Pointers
    RFC2959 PS Real-Time Transport Protocol Management Information Base
    RFC3009 PS Registration of parityfec MIME types
    RFC3016 PS RTP payload format for MPEG-4 Audio/Visual streams
    RFC3047 PS RTP Payload Format for ITU-T Recommendation G.722.1
    RFC3119 PS A More Loss-Tolerant RTP Payload Format for MP3 Audio
    RFC3158 I RTP Testing Strategies
    RFC3189 PS RTP Payload Format for DV Format Video
    RFC3190 PS RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio
    RFC3267 PS RTP payload format and file storage format for the Adoptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs
    RFC3389 PS RTP Payload for Comfort Noise
    RFC3497 PS RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video
    RFC3550 DS RTP: A Transport Protocol for Real-Time Applications
    RFC3551 DS RTP Profile for Audio and Video Conferences with Minimal Control
    RFC3555 PS MIME Type Registration of RTP Payload Formats
    RFC3556 PS Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth
    RFC3557 PS RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding
    RFC3558 PS RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders SMV
    RFC3545 PS Enhanced Compressed RTP (CRTP) for links with High Delay,Packet Loss and Reordering
    RFC3611StandardRTP Control Protocol Extended Reports (RTCP XR)
    RFC3640StandardRTP Payload Format for Transport of MPEG-4 Elementary Streams

    Current Meeting Report

    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-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 
    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 
    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 
    (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 
    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 
       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 
    -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 
       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 
       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 
       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 
       Roni Even also commented that the use case for checking the MTU might 
    need feedback, however the QoS diagnostic does look like a different 
       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 
        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 
        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 
        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.
        - * -


    Requirements for Transport of Video Control Commands
    RTP Payload for AMR-WB+ audio codec
    ATRAC family payload
    Update on 3GPP Timed Text Payload Format
    RTPpacketizationfor text conversation.
    H.263 & H.261 payload format
    RTCP Extensions forSSM Sessions with Unicast Feedback
    Requirements for ECRTP over MPLS
    RTP No-op Payload Format
    RTP Profile for TCP Friendly Rate Control