2.8.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 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-07

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:
Oct 03  Review DCCP including prototypes and API; feedback to DCCP WG
Nov 03  Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG
Dec 03  Submit iLBC payload format for Proposed Standard
Dec 03  Submit iLBC codec specification for Experimental
Dec 03  Submit ULP Payload Format for Proposed Standard
Dec 03  Submit RTCP/SSM draft for Proposed Standard
Dec 03  Submit UXP Payload Format for Proposed Standard
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
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-08.txt
  • - draft-ietf-avt-uxp-06.txt
  • - draft-ietf-avt-srtp-09.txt
  • - draft-ietf-avt-rtcp-feedback-07.txt
  • - draft-ietf-avt-mpeg4-simple-08.txt
  • - draft-ietf-avt-mwpp-midi-rtp-08.txt
  • - draft-ietf-avt-rtcpssm-05.txt
  • - draft-ietf-avt-rtp-retransmission-09.txt
  • - draft-ietf-avt-rtp-jpeg2000-04.txt
  • - draft-ietf-avt-rfc2833bis-03.txt
  • - draft-ietf-avt-ilbc-codec-03.txt
  • - draft-ietf-avt-uncomp-video-04.txt
  • - draft-ietf-avt-rtp-h264-03.txt
  • - draft-ietf-avt-rtp-ilbc-03.txt
  • - draft-ietf-avt-rtp-clearmode-03.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-00.txt
  • - draft-ietf-avt-rtp-midi-guidelines-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)

    Current Meeting Report

    .Audio/Video Transport Working Group 
    Reported by Magnus Westerlund and Colin 
       The AVT working group met for two sessions during the 58th IETF. 
    During these sessions the group discussed RTP considerations for DCCP, the 
    SSM RTCP Extension, VoIP header compression over multiple hops and MPLS, one 
    new RTP profile, video parameter and command signalling, and numerous RTP 
    payload formats. 
    Introduction and document 
       The working group has published 8 RFCs since the previous IETF 
    meeting: RFC 3545, 3550, 3551, 3555, 3556, 3557, 3558, and 3611. There is 
    also a document 
    (draft-ietf-avt-mpeg4-simple-08.txt) in the RFC editors queue, and the RTP 
    profile for security (draft-ietf-srtp-09.txt) was approved just prior to the 
    meeting and will go on to the RFC editor.  There are four working group 
    drafts waiting for Area Director review, namely: 
    draft-ietf-avt-rtcp-feedback-07.txt and  
       The working group has a number of documents, both working group and 
    individual submissions that are not otherwise to be discussed in the  
    meeting, and were instead reported on by the chairs: 
       - Draft-ietf-avt-rtp-clearmode-03.txt and 
    draft-jones-avt-audio-t38-01.txt are basically ready for working group last 
    call. They have both received editorial comments, so after an update they 
    will go to WG last call. Any comments was encouraged to be sent in before 
    the end of the meeting week. 
       - Tom Taylor is working on updating 
    draft-ietf-avt-RFC2833bis-03.txt under Henning Schulzrinne's 
    supervision. The document will receive an editorial 
    reorganisation due to its growth from DTMF tone draft to a general tone 
    signalling draft. There were also substantial comments raised by Tom 
    Taylor and Andreasen Flemming that need to be addressed in the next 
    version. An update is expected within a few months. 
       - draft-ietf-avt-uxp-06.txt has been stalled for quite a while due to its 
    connection with the ULP draft. It has been established that they are 
    different enough to be able to progress on their own. The UXP draft seems to 
    be fundamentally sound, however it requires significant editorial work 
    before it can advance. 
       - draft-kerr-avt-vorbis-rtp-03.txt has received minor updates since last 
    meeting, and a more major update are 
    draft-herlein-speex-rtp-profile-01.txt, and 
    draft-ramalho-rgl-rtpformat-02.txt are both awaiting updates. 
       - draft-ietf-avt-mpeg1and2-mod-00.txt is an update to the RTP payload 
    format for MPEG1 and 2 video (RFC 2250) intended to be published as a 
    draft standard RFC. Review is solicited. 
       - draft-chen-rtp-bv-00.txt: there was a mix-up with the deadlines and 
    submission, and two new versions can be expected directly after the 
    meeting. Review is 
       - draft-hatanaka-avt-rtp-atracx-03.txt has recently been discussed and 
    seems to be needing some 
    Document updates on behalf of the 
     Several authors were not able to attend, but instead requested that the 
    chairs present a brief update on their draft: 
       - draft-ietf-avt-ulp-08.txt has been updated, with the main change 
    being to move a number of fields from the RTP header to the payload 
    section, making the mask field only 16 bits. This has been addressed by 
    using a flag bit to indicate 16 or 48 bits of mask field. The draft is 
    expected to advance rather 
       - draft-ietf-avt-rtp-jpeg2000-04.txt has been updated with support for 
    interlaced images. Other updates are text clarification, MIME and SDP 
    section, and security consideration. The authors has request WG last call. 
    Colin Perkins has at least some editorial comments, but the document can be 
    expected to progress rather quickly. 
       - draft-ietf-avt-midi-rtp-00.txt and 
    draft-ietf-avt-midi-guidelines- 00.txt, the updated versions contains 
    mostly editorial changes and have been renamed and republished as 
    working group documents. John Lazarro plans to ensure he has finished his 
    implementation before requesting working group last call to catch any 
    final bugs in the specification. However, he expects to have finished this by 
    the end of the year. 
    draft-lazzaro-avt-rtp-framing-contrans-02.txt, contains definition of 
    framing of RTP and RTCP into connection oriented transport, intended to be 
    interoperable with the definitions that were in RFC 1889. It was asked if we 
    should continue this path, or develop a different protocol allowing for 
    multiplexing of RTP and RTCP on the same TCP connection? Please review the 
    draft and send any comments on this issue to the 
    RTP payload format for 
       Ari Lakaniemi presented an introduction to AMR-WB+ codec and 
    proposed RTP payload format.  The codec specification is not yet 
    finished, but  is expected to be ready by March.  The payload format is 
    based on the payload format for AMR and AMR-WB (RFC 3267). The changes are 
    removal  of bandwidth-efficient mode, a RTP timestamp rate of 96 kHz, and 
    the removal of the payload level multi-channel functionality. 
       Colin Perkins commented that multi-channel usage has previously been 
    signalled out of band, however AMR-WB+ uses a mode field to indicate if 
    frames contains mono or stereo content. Magnus Westerlund commented that any 
    future signalling in this area probably needs to be more general, since the 
    ATRAC-X payload format proposes a similar thing. 
       Colin Perkins had a further comment that there are 
    interoperability considerations since AMR-WB+ is a superset of AMR-WB. If an 
    AMR-WB+ capable end-point does not also offer AMR-WB in its initial 
    offers, an AMR-WB only end-point would fail to understand that they 
    should be able to communicate. The draft needs to address this 
       Allison Mankin, stressed that this work as being related to 
    incomplete work in 3GPP, and may need technical changes later to match 
    changes in the codec. It was further noticed that this payload format will 
    not advance until the 3GPP AMR-WB+ codec specification is frozen. 
       The future work from the authors will be to track the codec 
    development to keep the payload format aligned with the codec. Comments 
    about the design choices so far are solicited. The draft was accepted as an 
    AVT work item in principle, subject to resolution of the signalling 
    RTP payload format for VMR-WB 
       Sassan Ahmadi made an overview of the Variable Multi-Rate Wide-Band 
    speech codec which is an selected 3GPP2 CDMA 2000 codec since April 2003. It 
    contains a interoperability mode that uses some modes identical to AMR-WB to 
    enable interoperability with AMR-WB only end-points. This will allow for 
    better quality and better efficiency by removing the need for 
    transcoding. There is a clear interest for having two different circuit 
    switched cellular networks using the same or interoperable speech codec to be 
    connected with an IP network. 
       The VMR-WB payload format is based on RFC3267 payload format. Most of the 
    RFC 3267 functionality is maintained, except for anything related to 
    Unequal Error Protection (UEP), as the speech encoder is design to work 
    over network with equal error protection of the encoded speech bits. 
       The main issue raised for both AMR-WB+ and VMR-WB formats is that they 
    are super-sets of the AMR-WB codec. This may result in three MIME types 
    existing for the same codec. How this signalling problem is resolved to 
    avoid interoperability problems needs to be considered before either draft 
    goes forward. Thomas Zeng asked if it is possible to come up with a 
    single payload format that would work for all the three codecs (AMR, 
    AMR-WB, AMR-WB+ and VMR-WB) to reduce implementation complexity. It could be 
    desirable to have such a solution and it should be 
       Sassan requested that the work be accepted as an AVT work item. Colin 
    Perkins commented that he has no principal problems of accepting this  as a 
    work item, as long as it is guaranteed that the codecs will be 
    accepted, and the signalling issue is resolved. Sassan answered that  the 
    codec is currently undergoing characterisation tests and that final 
    specification will be available in April 2004. 
    RTP payload formats for ETSI DSR codecs 
       Qiaobing Xie discussed the three ETSI DSR codecs without an RTP 
    payload format so far.  He outlined how that relate to the DSR codec that 
    has a payload format in RFC 3557. From an RTP payload format the 
    difference is two possible frame lengths and their internal frame 
    definition that need to be indicated through 
       It was previously suggested that the three drafts should be merged into a 
    single document, as they are very similar. This question was asked to the 
    group, but no comments were received. 
    iLBC codec and RTP payload format 
       Alan Duric presented the most recent changes to the drafts. See the 
    presentation slides for the list of changes. Alan requested that working 
    group last call be issued for both drafts.  Colin Perkins commented that 
    beside some nits, the only substantial comment regards two statements in the 
    both drafts, regarding the free-ware nature of iLBC and that CableLabs  
    intends to include it in one of its specifications, since these 
    conflict with IETF IPR disclosure rules (they should be in an IPR 
    statement, not in the 
       As soon an updated versions are available it will be last called. The 
    codec is intended to go to Experimental status, and the payload format for 
    standards track as proposed. Allison Mankin promised to provide a 
    boilerplate for the codec draft that specifies the intention of going to 
    informational when more experience has been gathered regarding the codec. 
    RTP payload format for conversational text 
       Gunnar Hellström presented this update to RFC 2793, which both 
    updates the payload format, and also defines a new format intended for 
    gateway usage allowing for audio and text multiplexing in the same RTP 
    session. There where some discussion regarding the RTP profile 
    independency of the format, to avoid confusion. The registration of 
    "text/red" should also be moved into a separate document. 
       The new format for gateway use is signalled by the "audio/t140" MIME 
    type with various parameters. It was noted that the signalled rate in 
    characters-per-second cannot be guaranteed on the receiver side due to 
    network jitter.  
       The draft defines an internal block sequence number in addition to the 
    RTP sequence number. Colin Perkins commented that when switching from 
    audio to text, it is possible for the last packet of audio to be lost, but 
    not detected. Henning Schulzrinne noted that this can be addressed by 
    using RFC 2198 redundancy to lower that risk as done in RFC 2833. A 
    further comment is that audio/t140 is capable of handling any of the 
    redundancy mechanism, so both RFC 2733 and RFC 2198 can be used. Thus 
    there is probably no need to mention either of them explicitly. Magnus 
    Westerlund commented that the usage of RFC 2198 is quite restricted due to 
    the small maximum timestamp offset for a redundancy packet (14 bits), 
    resulting in that a 16kHz timestamp rate will only allow redundant block 
    from the last second. 
       Gunnar also pointed out that ITU-T SG 16 has a desire to have this 
    format available in February 2004. To meet this goal there is need to move 
    quickly, multiple revisions are probably needed before the end of the 
       The consensus of the room was that it is appropriate to accept this as an 
    AVT work item, however Colin James made an objection against the current 
    solution because it hasn't been sufficiently reviewed, and he was not 
    convinced that it was the simplest possible solution allowing for 
    easiest implementation simplifying deployment. 
    RTP payload format for 3GPP Timed 
       José Rey presented the open issues regarding the format. The main 
    discussion has concerned if the format should be made generic, or 
    specific for each timed text format. There is work in both MPEG and W3C to 
    define additional timed text formats, however they are not yet ready. 
    There is, however, a clear desire to finish this payload format for 3GPP 
    timed text in the 3GPP Release 6 timeframe, i.e.  by March 2004. To meet the 
    deadline there is need to move much quicker than what has previously been 
       An input in this discussion was email to AVT mailing list from Jan van 
    der Meer, proposing that MPEG-4 SIMPLE payload format is used. Further 
    discussion on the list is encouraged to allow for the working group to 
    determine if there should be one payload format for all text usage or one 
    for each "codec" definition? 
       Another comment that was raised was is that it is very complex 
    solution. We should consider if the format should rather be designed as 
    transport format of the semantics, rather then being a transport of a file 
    RTP payload format for Uncompressed 
       The changes to the draft were presented by Ladan Gharai. The change list 
    is available in the presentation. A comment raised is that the draft 
    probably should define the Gamma value the video.  Magnus Westerlund asked if 
    the authors has considered the usage of the IPv6 jumbogram and if the byte 
    offset field will create any problem as being to small for really large 
    picture sizes. Besides these, and some editorial comments, the draft seems to 
    be in good shape, and a working group last call is expected when the next 
    revision becomes available. 
       Allison Mankin also asked if the draft had a strict wording (MUST) 
    about the need of being congestion aware, due to comments received 
    regarding RFC 3497. Colin Perkins responded that RFC 3497 has the 
    requested strength in wording, and would ensure that also this draft has it. 
    RTP payload format for H.264 
       Magnus Westerlund outlined recent changes in the RTP format for H.264 
    video.  There were two packetisation modes in the previous draft, one with 
    decoding order numbers (DONs), and one without. The rules for when DONs 
    should be used were unclear. The new version simplifies these rules: the DON 
    is either always present, or never present. This gives three 
    packetisation modes: single NAL unit mode, non-interleaved with STAPs, and 
    interleaved with 
       An additional interleaving parameter, max-don-diff, was added to help 
    control interleaving. This gives the maximum displacement in terms of the 
    DON, much in the style of the MPEG-4 payload 
       Minor bug fixes include: assignment of DON values for STAP-B packets was 
    corrected and clarified, derivation of the DON for MTAPs was changed to 
    allow wraparound of values within one MTAP, the use of the RTP 
    timestamp and picture timing SET message has been clarified, and Base64 
    encoding is now used in the "parameter-sets" MIME 
       Dave Lindberg noted that network SLAs are often based on RTCP jitter, but 
    H.264 bi-predictive slices disrupt the jitter calculation. This is common to 
    many payload formats, and makes the RTCP jitter measurements useless for 
    measuring network performance. Dave asked for a note to be inserted into the 
    draft, to clarify the issue, and solicited input from network 
    operators on how they intend to deal with this issue in the design of 
       There are several open issues: the security section needs review; does 
    the benefit of the max-don-diff parameter outweigh the complexity it 
    brings; and should MIME parameters, similar to the H.241 
    CustomMaxMBPS, CustomMaxFS, CustomMAcDPB and 
    customMaxBRandCPB, be added? On the later subject, Dave Lindberg - noting 
    that he's the editor of H.241 in ITU - gave an "enthusiastic yes", since the 
    profiles and levels in H.264 were designed for more traditional 
    applications, and these parameters are very useful to support emerging 
       Colin Perkins asked about Nokia's IPR statement for this draft, which 
    grants a royalty free license, provided the H.264 base also has a 
    royalty free license. Does the H.264 base have such a license? No: it 
    seems unlikely that any part of H.264 will be royalty free. The IPR 
    conditions on the payload format appear to be no more restrictive than 
    those on the codec. 
       Thomas Zeng noted that the max-don-diff is undefined if not 
    signalled, but that the receiver is expected to use this in the 
    decoding process. Magnus said that this is a complex issue, and that it's 
    not obvious what is the best buffering strategy for a receiver when 
    interleaving is used. The max-don-diff parameter is expected to be used as an 
    interleaving depth indicator, to simplify this process. Thomas 
    complained about the complexity of the terminology, and 
    clarification is probably 
    RTCP Extensions for SSM with Unicast 
       Jörg Ott updated the group on changes to the RTCP Extensions for SSM 
    with Unicast Feedback 
    <draft-ietf-avt-rtcpssm-05.txt> since the 57th IETF meeting. There are 2 
    open issues, besides security considerations, remaining: how to form 
    compound packets and how to determine the RTCP 
       RFC 3550 requires all RTCP packets to be compound packets, starting with 
    either an SR or RR packet. This draft requires sources to send 
    reception quality summary ("RSI") packets, but it's unclear if these 
    should follow an SR or RR packet.  Jörg suggested that it would be 
    cleanest to include RSI packets in a compound RTCP packets with SR data, but 
    this raises the issue of how to split RTCP bandwidth between sender and 
    receiver, and means that the timestamp in RSI packets is redundant.  Colin 
    Perkins agreed that including RSI packets with SR packets is 
    appropriate, since the reports are coming from the 
       There are two alternatives to control the RTCP bandwidth: 
    distribute the current group size in RSI packets and let the receivers 
    calculate their reporting interval, or notify receivers about the 
    allowable bandwidth. The former is closer to the standard RTCP 
    algorithm, the latter allows the sender to keep the group size 
    confidential. The draft currently allows both alternatives, but this may not 
    be ideal (and requires some clarification of the case were are 
    signalled for a session). Input is 
       Colin Perkins asked if there is an issue regarding step joins and 
    leaves when the group size is explicitly conveyed? This is the reason why 
    timer reconsideration was added to RTCP, and it may be necessary to 
    define how the extensions interact with 
       Next steps are to fix the editorial nits, provide more detail on how the 
    distribution source generates RSI packets, and to rework security 
    considerations section to give more explicit guidance to 
    implementors. The aim is to complete the work by the end of December 
    Extended Secure RTP Profile for RTCP-based 
       Jörg Ott outlined the new RTP/SAVPF profile, combining the Secure RTP 
    profile and the RTCP feedback profile.  The major implication of this 
    combination is a potential impact on the timeliness of feedback since 
    SRTCP adds some 10-20 bytes per packet (10-40%), which decreases the 
    responsiveness of the feedback. Rules are provided for negotiation and 
    inter-working, noting which combinations make sense, and ensuring that 
    there are no bidding down attacks. The combination of these profiles is 
    generally straight-forward, however. Review from the working group is 
    RTCP Streaming Extended 
       Alan Tseng introduced an extension to RTCP XR (RFC 3611) which 
    reports more detailed statistics on re-buffering and packet 
    corruption. This is intended to be useful for streaming media 
       There are several known issues with the draft: even the best 
    measurement of corruption is only a best guess of "good" versus "bad" 
    frames; and some existing application architectures may not support 
    collection of the data to be reported. Comments are solicited on the 
    mailing list - the authors are collecting feedback and sorting out the 
    details of the 
       Thomas Zeng asked for clarification on the frequency of the reports. Is it 
    sufficient to report this information once, at end of the stream, or 
    should it be reported periodically? Alan replied that it is viable to send 
    the data only once, but sending periodic updates in conjunction with 
    packet loss data would also be desirable. Will try to provide more 
    recommendations and use cases in a future version of the 
       Victor Varsa asked if these reports were intended to be used for 
    adaptation of the streaming, or just for offline collection? Alan 
    replied that the original plan was to use a single report, but it seems to be 
    useful for adjusting the feedback during the stream. Victor noted that the 
    main advantage of sending these reports within RTCP is that they're 
    synchronised with the media, this is only useful if the sender adapts in 
    real-time. To allow this, it would be helpful if the draft included a 
    description of how a sender could use the statistics to adapt. Colin 
    Perkins noted that he would prefer these drafts to describe the 
    reporting extensions in a normative manner, with separate drafts giving 
    informative guidance on how the data could be used. 
       Magnus Westerlund expressed scepticism on the use of the draft, since 
    much of the information is available from other sources, or can be 
    inferred. Michael Ramalho also wondered about the intended use of the 
    work. He noted that it's important and useful to separate network events 
    from client events, and agreed that it might be interesting to know that 
    certain client events occurred and impacted the user experience, but 
    couldn't see how the data was used - except as a reporting mechanism. If the 
    data is only reported, and not used to drive adaptation, alternative 
    transport mechanisms may be more appropriate. 
       It was suggested that the work of the RMONMIB working group may be 
    relevant to this problem. Details can be found at: 
    Datagram Congestion Control Protocol 
       Eddie Kohler gave a short presentation on the Datagram Congestion 
    Control Protocol. DCCP is under development as an alternative to UDP and 
    provides a connection-oriented, congestion controlled, datagram 
    transport service with partial checksums, mobility, DoS resistance, and 
    support for explicit congestion notification (ECN). The target 
    applications are those with long-lived flows that prefer timeliness to 
    reliability: streaming media, Internet telephony, games, 
       DCCP allows applications to select from a range of congestion control 
    algorithms (e.g. TCP-like, TFRC). It also decouples reliability from 
    congestion control, to avoid the unconditional "buffer and 
    retransmit" behaviour of TCP, and provides a range of data 
    acknowledgement options including the ability to indicate that data was 
    dropped due to buffer overflow in the application, rather than in the 
       The partial checksum support in DCCP counts the number of 32 bit words of 
    payload to be included in the checksum, up to a total of 56 octets. Eddie 
    asked if this was sufficient for the applications people used? Thomas Zeng 
    replied that this is probably sufficient for audio, but doubted that it was 
    enough for video applications. Magnus Westerlund noted that DCCP also has an 
    optional payload checksum feature, which can be used to provide more 
    flexible checksums at the expense of additional 
       DCCP provides an optional ACK vector, which allows applications to send a 
    run-length encoded history of packets received. It also has a "data 
    dropped" option, which allows a receiver to signal that certain packets 
    were dropped due to non-network reasons (e.g. corruption, 
    insufficient receive buffer space). Colin Perkins noted that this might 
    duplicate some of the information provided by RTCP with the reporting 
    extensions described earlier in the 
       Finally, Eddie noted that there has been some discussion on the use of 
    DCCP with TFRC congestion control for VoIP applications (and similar). In 
    particular, there has been some discussion of protocol complexity, which has 
    resulted in a low-complexity subset of DCCP ("CCID3-thin") being 
    defined. There has also been discussion of the congestion control 
    behaviour, with two related issues being 
        - The requirement for slow-start has been noted to be 
    problematic for some applications. Eddie noted that DCCP allows 4 
    packets per RTT to be sent during slow start, allowing a 40ms 
    packetisation interval for RTTs less than 160ms. He suggested that this was 
    sufficient for audio applications, and solicited 
        - There is also a congestion issue with applications slowing down 
    during idle periods, for example silence suppression for voice. 
    Applications which stop sending cannot just restart after an idle 
    period, they must slow-start. Applications which send some traffic during 
    idle periods will allow DCCP to maintain congestion state, allowing them to 
    largely avoid this issue (since DCCP generally allows an 
    application-limited flow to double its rate each RTT, up to the limit 
    imposed by the congestion control). Again, Eddie asked if this was a 
    feasible solution for multimedia 
       Magnus Westerlund expressed concern about the slow start, since audio 
    with 20ms packets is common, and four packets per RTT requires an RTT that is 
    difficult to obtain for many applications. Dave Lindberg asked if the 
    factor of two increase in rate allowed when moving from an 
    application limited regime to a congestion controlled regime is hard 
    coded? At present it is, but there may be a small amount of 
    flexibility. The factor of two may be a limiting for video, since the 
    first frame after an idle period will be an I-frame, which is 
    typically much larger than the P-frames which 
       Eddie continued his presentation, noting that the rate does not 
    increase during an application limited period. An application can only 
    determine if there is capacity to support a higher rate by trying to 
    increase its rate (possibly incurring loss, if the higher rate cannot be 
    supported). Eddie also noted that many applications have discrete rates, 
    which may not necessarily match the reference rate suggested by the 
    congestion controller. Again, it seems acceptable for an application to 
    send at the closest discrete rate it can support to the reference rate, 
    provided this is within a factor of two of the reference rate. [Eddie's 
    slide stated "Variable rate considered harmful" here, followed by the 
    clarification "Meaning: Continuously variable rate problematic for apps 
    with discrete sending rates" - this caused some 
    discussion/confusion as noted 
       Finally, Eddie noted that he'd received feedback that any rate change is 
    harmful.  There has been some discussion of using DCCP with 
    applications that settle on one rate initially, then never 
       Dave Lindberg asked why variable rates are considered harmful, and 
    noted that some work on audio/video codecs was leading towards truly 
    variable rate codecs. Eddie replied that they weren't planning on 
    changing the protocol to require fixed rate applications, just that they 
    wanted to support them if possible, and variable rate codecs are a good 
    thing. There was some confusion, with Dave repeating his question and 
    Eddie explaining the issues with supporting applications that can send only 
    at discrete rates. Mark Handley and Michael Ramalho noted that Dave and 
    Eddie were talking past each other: it's not that the DCCP people think 
    that variable rate is harmful, it's that the people with discrete rate 
    codecs think that being told to adapt to arbitrary variable rates due to 
    congestion control is harmful. Mark explained: the DCCP congestion 
    control scheme has a variable rate which it would like you to send at, to 
    match the network capacity. The codec has a different (variable) rate, 
    which it would like to send at. There may be a mismatch between the two 
    rates, and this mismatch has to be bounded. Provided the mismatch is 
    within a factor of two, things are okay. If the mismatch gets larger than 
    that, the codec sending rate has to be adjusted to match the rate the 
    network is capable of 
       Michael accepted that, but explained the problem from the viewpoint of a 
    codec designer: he could have been wasteful, and sent at the full rate all 
    the time, but he's developed codecs which are efficient and usually send at 
    low rates. However, every once in a while, they need to send a large burst of 
    data, due to a scene change. He would claim that he is being a good 
    citizen, by not sending all the data all the time, but he is getting 
    penalised by the congestion control when the scene change happens. This 
    doesn't feel correct, even though he understands the reason behind the 
    congestion control 
       Roni Even noted that there are applications can only change their rate by 
    completely switching codecs. These applications need the congestion 
    control to signal them to adapt, so they can perform the application level 
    signalling needed to change codec, rather than trying to directly 
    influence the flow dynamics. Eddie noted that DCCP is supposed to give the 
    application enough knowledge to support 
       Tom Phelan noted that he's been working in the DCCP working group, to try 
    to match VoIP applications onto DCCP. Some of his conclusions are "out of 
    the norm" for what people usually consider good behaviour in the 
    network: instead of "if you have nothing to say, say nothing", it may be 
    more appropriate to say "use it or lose it" since if you send nothing, any 
    TCP cross-traffic will take the unused capacity away from you. There may 
    need to be a mindset change on the part of media application authors to 
    effectively use 
       Dave Lindberg noted that the burst-to-average rate ratio for some video 
    codecs is higher than 2:1, and that to keep the quality steady one needs to 
    momentarily increase the bitrate. Ideally, one might convey a profile of the 
    burst-versus-average characteristics of the application, so that the 
    congestion control system can take that into account. Eddie noted the 
    difficulties in doing this, which Dave accepted. However, it is clear that 
    many codecs are bursty, and in order to lower the average rate, these 
    bursts need to be somehow 
       Mark noted that there is a fundamental mismatch between what can 
    safely be done to probe the capacity of the network, and what the codecs 
    want to support bursts. The bounds in DCCP are fundamental for best 
    effort networks, and reflect the limits of what the network can 
    support. They are not something we have flexibility to 
       Dave mentioned statistical multiplexing, which allows one to get 
    bursts through in many cases. He also noted that TCP flows are not 
    typically latency sensitive, so there may be some opportunity for some kind 
    of trade-off. 
       Nermeen Ismail asked if an application stops sending, and during that 
    time there was no congestion in the network, would it make sense to allow it 
    restart at the full rate? Theoretically, yes, but one can't figure out if 
    there is congestion until one starts sending, so slow start is needed to 
    provide enough feedback to make the system stable. The problem is that 
    there is insufficient knowledge in the network to know if a change of rate is 
    acceptable without trying 
       It was noted that the MPEG community studied into this problem around 
    1998-2002, and may have produced useful references. 
       Magnus Westerlund noted that some applications can smooth the bursts, 
    depending on their latency requirements.  However, if you need low 
    latency, it may be necessary to reduce the quality of inter-frames and use a 
    more incremental refresh strategy. This will reduce the quality, but will 
    fit the dictates of congestion control and the 
       Eddie noted that, to the extent that we'll have a solution, it will 
    require sending some data during idle periods to maintain congestion state 
    and knowledge of the 
       Ladan Gharai noted that the issue was largely with live 
    interactive applications, rather than with streaming applications which can 
    use buffering to smooth their rate to match that of TFRC. She 
    suggested that it may be appropriate to consider different congestion 
    control for these two classes of application, rather than assuming - as has 
    much of the discussion during the session - that a single congestion 
    control algorithm can be used for both. The appropriate congestion 
    control for live applications may be a research topic, rather than 
    something we can engineer 
       Mark Handley noted that an advantage of DCCP, compared to UDP, is that it 
    has support for ECN built-in. This allows applications to react to 
    congestion, before it becomes severe enough to cause packet loss, and may be a 
    significant benefit of 
       Eddie concluded the discussion by giving pointers to the 
    RTP Header Compression over Multi-Hop 
       Jerry Ash discussed the motivation and requirements for VoIP header 
    compression over multiple-hop paths, in particular ECRTP over 
       The motivation for this work is that carriers are planning to 
    converge their networks to use MPLS/IP with VoIP services. When using RTP 
    there is a high overhead due to the RTP/UDP/IP headers, so there is a 
    desire to use header compression. However, the compression is 
    computationally complex, and it is desirable to find a multi-hop 
    solution, rather than using hop-by-hop header compression.  This may 
    involve RTP compression across a multi-hop MPLS path, or compression over a 
    series of IP 
    hops.   Jerry summarised the requirements 
    as:    - allow header compression over multiple-hop paths, possibly through an 
    network    - avoid hop-by-hop compression/decompression 
    cycles    - compress RTP/UDP/IP header by at least 
    50%    - allow VoIP header compression over multiple-hop paths with delay not to 
    exceed 400ms 
        - allow VoIP header compression over multiple-hop paths with delay 
    variation not to exceed toms 
        - allow VoIP header compression over multiple-hop paths with packet 
    loss not to exceed 0.001 
        - support various voice encoding 
    schemes    - be scalable up to 20000 simultaneous 
    flows    - be compatible with existing standards where 
       Colin Perkins, Michael Ramalho, Dave Lindberg and Carsten Bormann all 
    questioned if the numeric requirements were appropriate, and how they 
    differed from those for VoIP traffic without header compression. There was 
    general agreement that the draft may be better if it specifies the 
    additional requirements caused by header compression, rather than 
    generic requirements to support 
       Dave Lindberg asked if there a requirement for packet loss 
    recovery, since one of the issues with CRTP is that a single packet loss can 
    cause a whole RTT of data to be lost.  This is something that concerns the 
    authors, especially for multiple-hop paths, but they hope that ECRTP will be 
    sufficiently robust. George Swallow's "simple" RTP header 
    compression proposal also avoids these problems, but Colin Perkins noted 
    that the group is not chartered to work on new compression algorithms at 
       Michael Ramalho asked if the compression was dealing with aggregate or 
    single flows, since if aggregate flows are used there may be different 
    solutions for recovery from errors. Both single and aggregate flows are 
       Magnus Westerlund noted that requirements for header compression over 
    multi-hop MPLS paths may well be different than the requirements for 
    header compression over multi-hop IP paths. The draft may be better 
    written separating these out. 
       Jerry noted that there are potential scalability issues with RSVP and 
    label processing and binding at every MPLS node on the path. It's also not 
    clear how to signal the context states within the label 
    distribution protocol, and extensions to LDP may be 
       There was some discussion of the need to produce a standard for header 
    compression on multi-hop IP paths, since routers which are 
    compressing on both ingress and egress links can unilaterally decide to 
    match CIDs and pass-through compressed flows without a 
       The chairs noted that there are significant issues to be resolved with 
    the draft, and delayed accepting it as an AVT work item until they are 
    SDP parameters for supporting H.263 and H.261 
       Roni Even discussed new SDP parameters to support various optional 
    features in H.261 and H.263 codecs. Features to be signalled include frame 
    rate and resolution dependency, and optional features defined in various 
    annexes to the codecs. The authors are looking for input on the 
    parameters chosen, to see if all have been 
       The two drafts suggest different approaches, but the authors have come to 
    consensus on using "a=fmtp:" rather than "a=gpmd:" to signal these 
    parameters. Plans for the future are to combine the ideas from the two 
    drafts, and revise the payload formats for H.261 and H.263 to include 
    these new MIME parameters. It was also suggested to move RFC 2190 to 
    historic at the same 
       Eric Burger noted that there are several parameters which are not used, 
    especially in H.261. Which revising the payload formats, we should remove 
    these. Flemming asked about backwards compatibility, since care must be 
    taken when adding new MIME parameters that won't be understood by old 
       Victor Varsa asked how these new parameters relate to the concepts of 
    profiles and levels? These are additional parameters, which signal 
    combinations of parameters which cannot be represented by the profile and 
       It was accepted to open the H.261 and H.263 payload formats for 
    revision at this time, with the aim of producing draft standard 
    Requirements for transport of video control 
       Andrea Basso outlined some initial requirements work which is ongoing 
    relating to the transport of video control commands. This is 
    exploratory work, and it has not yet been decided which parts of it will 
    continue in AVT, which in MMUSIC, and which maybe 
       Andrea outlined the use cases described in the draft, leading to the 
    need for reference frame requests, spatio-temporal tradeoff requests, 
    freeze frame requests, max-rate requests and actual rate 
    notification. He also described the wide range of requirements for 
    transport of the different 
       Next steps are to trim the command list, to tighten up the list of 
    transport requirements, and to decide a home for the various parts of the 
    work. Dave Lindberg noted that H.241 supports many of these commands, and 
    suggested that the work be harmonised between the ITU and IETF. Eric 
    Burger suggested that we have to be careful not to blindly duplicate 
    H.241, since many of the features can be signalled in other ways, or are not 
    meaningful for SIP-based systems. Most important to harmonise the work, 
    irrespective of how or where the work is 
       The requirements capture and initial discussion for the codec 
    commands will be done in AVT.  It is not yet decided where the actual work 
    will be done, that will depend on the outcome of the requirements 
    Proposed additions to RTP 
       The final presentation of the meeting was from Alan Clark on 
    proposed additions to the RTP MIB. The rationale for these additions is to 
    add support for the new RTCP XR and VoIP metrics.  The draft does this by 
    adding an rtcpXrVoipTable to the existing MIB, to support both basic call 
    information and RTCP XR 
       Several people expressed concern about adding new features to RFC 2959, 
    suggesting instead that the additions are written as a separate draft, 
    perhaps under a separate MIB root. Magnus Westerlund noted that the RTP MIB 
    also needs to be updated for the changes between RFC 1889 and RFC 3550, and 
    this may be an appropriate time to make these changes. 
    				   - + 


    RTP Payload for AMR-WB+ audio codec
    Highlights of VMR-WB RTP Payload and Storage File Format
    RTP Payload Formats for ETSI ES-202-050, ES-202-211, and ES-202-212 Distributed Speech Recognition Codecs
    draft-ietf-avt-ilbc-codec-03 draft-ietf-avt-rtp-ilbc-03
    RTP packetization for text conversation.
    Way Forward for RTP Payload for 3GPP timed Text
    RTP Payload Format for Uncompressed Video
    RTCP Extensions for SSM Sessions with Unicast Feedback
    Extended Secure RTP Profile for RTCP-based Feedback (RTP/SAVPF)
    RTCP Streaming Extended Reports
    Proposed RTP MIB V2
    Datagram Congestion Control Protocol (DCCP) Overview
    Requirements for VoIP Header Compression over Multiple-Hop Paths
    Requirements for Transport of Video Control Commands
    SDP Optional Parameters for H.261 and H.263