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:

       RTP FAQ Page

Last Modified: 2003-07-30

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
for real-time transmission of audio and video over UDP and IP
This is the Real-time Transport Protocol, RTP, together with its
associated profile for audio/video conferences and payload format

The current goals of the working group are to revise the main RTP
specification and the RTP profile ready for advancement to draft
standard stage (including the sampling algorithms for use with very
large groups, which have been broken out into a separate document), to
complete the RTP MIB, to produce a guidelines document for future
developers of payload formats and to continue development of new

The payload formats currently under discussion include a number of
specific formats (MPEG-4, DTMF, PureVoice) and FEC techniques
to multiple formats (parity FEC, Reed-Solomon coding).

Archive before July 2001: ftp://ftp.es.net/pub/mail-archive/rem-conf/
Goals and Milestones:
Done  Working group last call on parity FEC draft (standards track)
Done  Post revised RTP MIB and issue working group last call (stds track)
Done  Working group last call on guidelines for payload format writers (BCP)
Done  Post revised RTP spec and audio/video profile
Done  Post revised DTMF payload format draft, ready for WG last call
Done  Post RTP implementation checklist draft
Done  Post payload format for MPEG-4 based on MPEG/IETF joint meetings
Done  Post revised RTP membership (SSRC) sampling draft
Done  Post revised draft on PureVoice (qcelp) payload format to address WG last call comments
Done  Submit RTP MIB to IESG for publication as Proposed Standard RFC
Done  Submit guidelines for payload format writers for publication as a BCP
Done  New working group last call on PureVoice payload format
Done  Working group last call on revised SSRC sampling draft (experimental)
Done  Analysis/simulation of multiplexing payload format proposals
Done  Post final revision of RTP spec and A/V profile drafts
Done  Revise MPEG-4 payload format document after implementation experience
Done  Decide how to proceed with multiplexing protocol: one generic payload format or a number of application specific formats
Done  Working group last call on RTP and A/V profile (for Draft Standard)
Done  Prepare MPEG4 implementation results ready for WG last call
Done  Post final revisions of selected multiplexing protocol draft(s)
Done  Working group last call on multiplexing payload format (stds track)
  • - draft-ietf-avt-tcrtp-07.txt
  • - draft-ietf-avt-ulp-07.txt
  • - draft-ietf-avt-uxp-05.txt
  • - draft-ietf-avt-srtp-09.txt
  • - draft-ietf-avt-rtcp-feedback-07.txt
  • - draft-ietf-avt-mpeg4-simple-07.txt
  • - draft-ietf-avt-mwpp-midi-rtp-08.txt
  • - draft-ietf-avt-rtcpssm-04.txt
  • - draft-ietf-avt-rtp-retransmission-09.txt
  • - draft-ietf-avt-rtp-jpeg2000-03.txt
  • - draft-ietf-avt-rfc2833bis-03.txt
  • - draft-ietf-avt-ilbc-codec-02.txt
  • - draft-ietf-avt-rtcp-report-extns-06.txt
  • - draft-ietf-avt-uncomp-video-03.txt
  • - draft-ietf-avt-rfc3119bis-01.txt
  • - draft-ietf-avt-rtp-h264-02.txt
  • - draft-ietf-avt-rtp-ilbc-02.txt
  • - draft-ietf-avt-rtp-clearmode-00.txt
  • - draft-ietf-avt-mpeg1and2-mod-00.txt
  • Request For Comments:
    RTP: A Transport Protocol for Real-Time Applications (RFC 1889) (188544 bytes) obsoleted by RFC 3550
    RTP Profile for Audio and Video Conferences with Minimal Control (RFC 1890) (37509 bytes) obsoleted by RFC 3551
    RTP Payload Format for JPEG-compressed Video (RFC 2035) (30275 bytes) obsoleted by RFC 2435
    RTP payload format for H.261 video streams (RFC 2032) (27408 bytes)
    RTP Payload Format for MPEG1/MPEG2 Video (RFC 2038) (23266 bytes) obsoleted by RFC 2250
    RTP Payload Format of Sun's CellB Video Encoding (RFC 2029) (11216 bytes)
    RTP Payload Format for H.263 Video Streams (RFC 2190) (26409 bytes)
    RTP Payload for Redundant Audio Data (RFC 2198) (25166 bytes)
    RTP Payload Format for MPEG1/MPEG2 Video (RFC 2250) (34293 bytes)
    RTP Payload Format for Bundled MPEG (RFC 2343) (16557 bytes)
    Options for Repair of Streaming Media (RFC 2354) (28875 bytes)
    RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) (RFC 2429) (43166 bytes)
    RTP Payload Format for BT.656 Video Encoding (RFC 2431) (22323 bytes)
    RTP Payload Format for JPEG-compressed Video (RFC 2435) (54173 bytes)
    Compressing IP/UDP/RTP Headers for Low-Speed Serial Links (RFC 2508) (60474 bytes)
    An RTP Payload Format for Generic Forward Error Correction (RFC 2733) (53120 bytes)
    Guidelines for Writers of RTP Payload Format Specifications (RFC 2736) (24143 bytes)
    Sampling of the Group Membership in RTP (RFC 2762) (25796 bytes)
    RTP Payload for Text Conversation (RFC 2793) (20674 bytes)
    RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals (RFC 2833) (68786 bytes)
    RTP Payload Format for Real-Time Pointers (RFC 2862) (12031 bytes)
    Real-Time Transport Protocol Management Information Base (RFC 2959) (62063 bytes)
    Registration of parityfec MIME types (RFC 3009) (16022 bytes)
    RTP payload format for MPEG-4 Audio/Visual streams (RFC 3016) (47070 bytes)
    RTP Payload Format for ITU-T Recommendation G.722.1 (RFC 3047) (16292 bytes)
    A More Loss-Tolerant RTP Payload Format for MP3 Audio (RFC 3119) (37796 bytes)
    RTP Testing Strategies (RFC 3158) (48208 bytes)
    RTP Payload Format for DV Format Video (RFC 3189) (25991 bytes)
    RTP Payload Format for 12-bit DAT, 20- and 24-bit Linear Sampled Audio (RFC 3190) (34977 bytes)
    RTP payload format and file storage format for the Adoptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) audio codecs (RFC 3267) (110652 bytes)
    RTP Payload for Comfort Noise (RFC 3389) (17018 bytes)
    RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video (RFC 3497) (26094 bytes)
    RTP: A Transport Protocol for Real-Time Applications (RFC 3550) (259985 bytes)
    RTP Profile for Audio and Video Conferences with Minimal Control (RFC 3551) (106621 bytes)
    MIME Type Registration of RTP Payload Formats (RFC 3555) (56618 bytes)
    Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth (RFC 3556) (15310 bytes)
    RTP Payload Format for European Telecommunications Standards Institute (ETSI) European Standard ES 201 108 Distributed Speech Recognition Encoding (RFC 3557) (29692 bytes)
    RTP Payload Format for Enhanced Variable Rate Codecs (EVRC) and Selectable Mode Vocoders SMV (RFC 3558) (49787 bytes)
    Enhanced Compressed RTP (CRTP) for links with High Delay,Packet Loss and Reordering (RFC 3545) (48278 bytes)

    Current Meeting Report

    Audio/Video Transport Working Group Minutes
    Reported by Magnus Westerlund and Colin Perkins 
    The AVT working group met once at the 57th IETF in Vienna. During this 
    session the working group discussed the updated charter, current status, 
    VoIP congestion control concerns raised by the IAB, the SSM RTCP 
    Extension and numerous RTP payload formats. 
    Introduction and document status
    The meeting started by Stephen Casner announcing that this will be his last 
    meeting as AVT co-chair. Allison Mankin presented Stephen with a plaque 
    enumerating the RFCs that Stephen has been shepherding during his time as 
    chair for AVT since its start in 1992. The working group showed its 
    appreciation for his long service with thundering applause.
    Stephen Casner outlined the current working group status. No RFCs 
    relating to AVT have been published since the last meeting, however there 
    are a currently 7 in the RFC editor's queue. The RTP specification is 
    currently in author's 48 hours and has gone through one substantial 
    change. The usage of the SDP RR and RS bandwidth modifier results in 
    change to the RTCP interval calculation mechanism. An RTP active sender is 
    allowed to take its part of the RR part when the number of senders are 
    larger than RS/(RS+RR).  This is a generalisation of the previous 25% rule 
    that was present.  The senders=0 clause in the example algorithm (A.7) has 
    also been removed to prevent senders bandwidth bleeding to receivers when 
    The other AVT drafts in the RFC editor's queue are the AVP profile, the RTP 
    profile MIME registration, the SDP bandwidth modifier for RTCP, the RTP 
    payload format for EVRC/SMV and the RTP payload format for ETSI ES 201 108 
    The specification for Enhanced IP/UDP/RTP header compression is with the RFC 
    Editor, but the authors would like to fix one technical shortcoming 
    before publication. This can be done if the Area Director and Working 
    Group approve of the change. The issue is to include the CSRC list in the 
    calculation of the Headers Checksum (HDRCKSUM), to enable header 
    validation and prevent error propagation in the CSRC list. The working 
    group was given until 18th July (the end of the IETF week) to comment on 
    this change. Positive comments were made during the meeting, and there were 
    no objections on the mailing list.
    The working group also has a number of drafts in IESG review: 
    Tunnelling multiplexed compressed RTP (TCRTP), Secure RTP (which has had 
    some recent  modifications in response to AD review), the Payload format for 
    MPEG-4, RTCP extended reports, RTCP feedback 
    (draft-ietf-avt-rtcp-feedback-07) and associated simulations 
    (draft-burmeister-avt-rtcp-feedback-sim-02), and RTP 
    The drafts of Uneven Level Protection 
    (draft-ietf-avt-ulp-07.txt) and Unequal erasure protection 
    (draft-ietf-avt-uxp-05.txt) were not updated for this meeting. 
    Colin Perkins noted that ITU-T SG16 Q.14 is working on standards for FAX 
    over RTP. He expressed interest in increasing coordination between ITU-T and 
    AVT to ensure that solutions developed do not conflict. He also noted that a 
    MIME type registration must be done to ensure that the FAX over RTP work can 
    be referenced by IETF protocols - such a registration should be 
    coordinated with AVT.
     Charter Update
    A preliminary updated WG charter with milestones was presented and has also 
    been posted to the mailing list. Please review and send any comments to the 
    list. The updated charter contains the following items: 
     - Advance RTP and the A/V profile to Full standard RFC  - Review and 
    revise RTP payload formats for Draft Standard RFC, as appropriate  - 
    Develop new RTP payload formats as needed.   - Complete the generic FEC 
    formats (ULP & UXP)  - Complete the RTCP extensions for SSM sessions   - 
    Develop a framing method for use of RTP/RTCP over TCP & TLS   - Review 
    applicability of RTP header compression for MPLS   - Develop a new RTP 
    profile combining AVPF and SAVP   - Coordinate with the DCCP working group to 
    ensure efficient transport of RTP over DCCP, and to ensure an 
    appropriate API is developed
    Longer term goals of the working group are to move to Draft Standard  the 
    SRTP Profile, the Extended RTP Profile for RTCP-based Feedback,  the 
    Compressed RTP (CRTP) framework, including Enhanced CRTP, and the RTP MIB. 
    Further development of media codecs is not expected to be chartered. 
    Aaron Falk made a short informational speech about DCCP and its 
    upcoming design review. He encouraged people to read the 
    specification, and come to the design review. He especially desired 
    people in AVT to comment on any API related issues, as this relates to the 
    possible usage of DCCP. 
     RTP Payload Format for MIDI 
    Colin Perkins outlined some slides from John Lazarro regarding the RTP 
    payload format for MIDI. This format has been reviewed by the MMA (the MIDI 
    Manufacturers Association) and their comments have been addressed. An 
    implementation exists and will be updated in regards to the changes 
    during the summer. It is expected that the draft will be ready for 
    working group last call before the next meeting. 
    The companion implementation guide for RTP MIDI has been updated to more 
    concern the MIDI parts, like recovery journal, than to deal with general RTP 
    things. John Lazzaro has requested that this document becomes a AVT 
    working group document. A hum was performed with some indication for 
    approval and none against.  
     RTP framing for TCP and TLS 
    Colin Perkins updated the group on the RTP framing for TCP and TLS. This 
    draft has been awaiting resolution of the MMUSIC WG comedia work and the 
    rechartering. It can be expected to make progress once the new charter is 
     IAB Concerns Regarding VoIP congestion control  
    Sally Floyd made a short presentation on an initial draft of IAB 
    recommendations regarding congestion control for Voice over IP flows. The 
    basic recommendation is that any flow that is facing persistent high rates of 
    packet loss should stop sending. Having congestion control of some type 
    will ensure that congestion collapse does not happen, user quality can be 
    maintained, and that fairness against other VoIP flows and TCP flows can be 
    maintained in a best effort network. 
    The draft does not recommend any particular deployment path for VoIP, like 
    best effort, QoS reservations, etc. It also not specifying any 
    behaviour, it is only a recommendation that there is a need to address 
    these issues. It also tries to address some of the framing problems and 
    what assumptions that can be made, like what is fairness, and is the 
    network, bit-rate or processor limited. 
    Several questions and comments where raised. One was the need to clarify 
    what it means to terminate a connection: in this case stop sending media 
    (not necessarily to terminate any signalling relationship). It was asked if 
    RTCP information is sufficient for deciding when to terminate the data 
    flow, which will need further investigation. 
    Is was also asked why the draft is restricted to VoIP and doesn't 
    address  other media types? This is not because other media don't need 
    congestion control for other media, rather it's a reaction to the 
    special treatment often proposed for voice (e.g. because flows are low 
    bandwidth). This special treatment is not considered appropriate.  It was 
    also clarified that the document does not address congestion control for 
     RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals  
    Henning Schulzrinne presented the current status of the draft. No major 
    technical changes have occurred, and it is now believed that all events 
    have been tracked down (however, review from someone working in this area 
    would be appreciated). The examples in the draft have also been 
    improved. Henning believes that the document is ready for WG last call, 
    however some more dedicated review would be beneficial. Tom Taylor and 
    Flemming Andreasen volunteered to perform a review of the document. The 
    goal is to have the draft ready for last call before or around the next 
    IETF meeting. 
    This draft was originally intended to become a Draft Standard RFC, 
    however so far the interop testing has not progressed. Henning 
    questioned the level of interoperability testing that will be needed: if 
    every event needs to be tested that will be a futile effort as they are 
    over a 100 in total, and from several different systems. 
    Alternatives are: 
     - interop testing only needs to show that the basic timing and 
    redundancy  mechanisms works  - to strip all events that can't be 
    tested, which probably will result in only DTMF tones will be left  - the 
    last alternative is to leave this as a proposed standard for all future. 
    The chairs will ask the area directors if basic timing and redundancy 
    interoperability is sufficient for testing for draft standard. It was 
    proposed that the draft be continued to be progressed to WG last call and be 
    published as Proposed Standard RFC, while work continues on 
    interoperability testing. The only consideration is if any of the 
    interoperability will result in technical changes to the document,  in that 
    case it might be better to wait. It would be advantageous if someone 
    actually doing implementation work using this format could be 
    participate in the interoperability testing. 
     Payload format for Speex Codec  
    Phil Kerr presented an update to the RTP payload format for Speex.  The 
    format has received extensive comments on the mailing list that need to be 
    addressed in next version. Comments in the meeting were regarding the 
    usage of the RTP timestamp rate. There has been some consideration that a 
    codec parameter for rate may be redundant, since the codec has some 
    functionality for recovering sampling rate. Another alternative would be to 
    use different RTP payload types and timestamp rates depending on codec 
    rate, this is however not without problem as Stephen Casner pointed out. The 
    issue needs further investigation. The recovery of the timestamp for 
    different frames when performing aggregation also needs to be 
     Payload format for Vorbis  
    Phil Kerr presented an update, where the main issue is related to the 
    codebooks that the codec uses. One thing introduced in the last version is 
    caching of the codebooks. This needs to be clarified, especially in cases 
    where the code book needs to transfered. A codebook is not limited in size 
    but they are commonly in the size 10-14 kbytes. So far suggested 
    mechanism are: 1) Transfer in HTTP, 2) send it RTCP APP packets, 3) Use RTP 
    over TCP, 4) try to define a limited set of codebooks that has to be 
    cached and are simply referenced. Steve Casner commented that in RTP 
    version 1 there was a mechanism to transfer parameters in parallel. 
    However this was removed due to synchronisation problems. Having any such 
    mechanism is a slippery slope and needs to be threaded carefully. 
    What is the gain from performing application level fragmentation, rather 
    than using IP level fragmentation? Need to be further clarified and 
    evaluated if enough gain is present to warrant the complexity of the 
    mechanism. There has also been a number of other general comments on the 
    draft on the mailing list regarding usage of SDP parameters, Path MTU 
    discovery, RTP timestamp recovery, and frame aggregation that needs to be 
     Internet Low Bit Rate Codec and RTP payload format 
    Alan Duric presented an update of the codec and payload format. The codec 
    has been reviewed by speech coding experts and their comments  will be 
    distributed when the last call is announced. As a result of  the review the 
    codec specification has been clarified and corrected. The new version 
    should be possible to implement based only on the description rather then 
    the source code.
    The payload format has an open issue with mode flag if only one side  is 
    capable of supporting 20 ms frame length in an SDP Offer/Answer 
    negotiation. The proposal to fix this is to include an offer/answer 
    section in the draft, specifying bi-directional behaviour for the mode 
    flag. A related issue is that ptime can't double as mode flag (this 
    should be explained in the text, since it is a common question). 
    As there has been no demand for comfort noise (CN) generation it will not be 
    included in the Codec. Henry Sinnreich commented that Voice Activity 
    Detection (VAD) and CN generation is important. The counter comment was 
    that an external VAD and the generic CN can be used anyway. There might 
    also be future work to provide iLBC with VAD and CN. 
    Colin Perkins asked if there is any need for test vectors? The answer from 
    Alan is that the codec specification is desired to remain being a 
    floating-point defined one and therefore exact test vectors can't be used.  
    However there is a possibility to provide test vector and then use PESQ 
    measurements to check how far from the nominal output ones 
    implementation produces. If any vector will be provided they will be in a 
    separate draft.
    Jon Peterson asked if the mode parameter is a more generic parameter and 
    therefore should be defined as such. Alan said that he had seen it in some 
    other codecs. Magnus Westerlund commented that any mode parameter and 
    their values are codec specific and should therefore be defined as such. 
     RTP Payload Format for Uncompressed Video  
    The current status and remaining open issues were presented by Ladan 
    Gharai. There have been few technical changes since the last version, 
    mostly editorial and related to understanding. The two payload 
    parameters sub-sampling and color-mode has been combined into one 
    parameter (sampling) to avoid the usage of "impossible" 
    The remaining open issue is if the currently defined colorimetry values are 
    sufficient or if there are more that should be defined? David Singer also 
    had an comment that YUV-4:4:2 sampling can have their chroma samples in 
    different orders. This needs to be addressed. 
    After the next update the draft is expected to be mature enough for 
    working group last call. 
     RTP Payload for H.264/JVT Video  
    Stephan Wenger presented the current status. The video codec itself has now 
    been approved by ITU as H.264 and will soon also be approved by 
    ISO/IEC. Work will continue in the JVT for professional extensions, 
    however the NALU interface will not be changed, so this work is not 
    believed to effect the payload format. The updated draft has been 
    significantly improved regarding understanding, especially of the 
    decoding order number (DON) concept. 
    There are a few remaining open issues. Should we do base64 encoding of the 
    parameters sets instead of base16? There does not seem to be any formal 
    problem of using this, and it will provide better efficiency.  The 
    security consideration needs to be improved and carefully reviewed. There is 
    concern over Timing SEI messages, since broken implementations may 
    disregard the RTP timestamp. There is need for strong 
    clarifications on the problem of doing that. Steve Casner commented that at 
    least the blame and cause are on the same side, namely with the 
     RTP Payload format for 3GPP Timed Text  
    Jose Rey presented for the first time a proposal for an RTP payload 
    format for the 3GPP timed text format. The timed text format provides 
    decorated and timed text, that can be used for karaoke and 
    subtitling. There is a need to complete this work fairly quickly as the 
    3GPP Release 6 deadline is officially march 2004, and may move to June 
    Steve Casner commented that the current proposal seems to provide much 
    flexibility that does not provide any useful functionality, and only 
    complicates the format. Colin Perkins also questioned how this work 
    relates to RFC 2793, RTP Payload for Text Conversation. The answer is that 
    text conversation does not provide modifiers for style and fonts and other 
    decorations as 3GPP Timed Text provides. 
    Joerg Ott raised the most substantial question: should this be a more 
    generic work. The applications are not limited to 3GPP mobile phones with 
    streaming, and a generic format seams appropriate. David Singer 
    commented that he had hoped that the W3C and MPEG work on authoring and 
    transport of decorated and timed text would be further progressed at this 
    time, and could provide input into this work. However Dave also pointed out 
    that there is a strong need to meet the 3GPP deadline. Magnus 
    Westerlund further commented that he hoped that people were talking about a 
    generic payload format rather than specifying a generic set of 
    operations on text (i.e. a text codec) in duplication of work ongoing in 
    other standards bodies. David singer further commented that there are 
    usually no comments when people standardise multiple different codecs, that 
    one generic is enough. The conclusion is that there is need to further 
    explore the scope of the work here. The subject should be clarified 
    through a mail discussion or internet draft. 
    The request for working group status has been delayed until the open 
    issues regarding how generic the work should be can be resolved. 
     RTCP Extensions for SSM Sessions with Unicast Feedback  
    Joerg Ott presented the update of the draft. The format has reverted back to 
    using its own RSI RTCP format instead of defining XR extension formats. 
    Some editorial issues have not been fixed yet. The authors believe there are 
    only a few remaining technical issues for this draft.
    One issue is if the distribution source should be allowed to use only the 
    senders RTCP bandwidth part or also the receivers? Steve commented that the 
    appropriate thing would be to allow the distribution source to use all RTCP 
    bandwidth as it summaries all RTCP. Magnus Westerlund also commented that 
    care should be take to define the RTCP behaviour for SSM in the draft as the 
    default, however future profiles may redefine this behaviour. 
    The second issue is the possible need to have values indicating for which 
    sources, or number of sources, the gathered information in RSI mode 
    applies to. This may be an unnecessary complication of the format, and 
    Magnus Westerlund commented that it only seems to be applicable to some of 
    the formats. Joerg asked if there is any need for this feature  
    otherwise the authors plan to go for simplicity here (meaning that the 
    receivers have to trust the sender to do the reasonable thing when 
    The third issue is that RTCP BYE packets are reported five times (as is 
    done for SSRC collisions). However there seems to be little necessity of 
    doing this for normal RTCP BYE packets. Steve Casner commented that it 
    seems to be an advantage of having this to work in the same way as 
    standard RTCP. Colin commented that there is probably no need to report a 
    collision more than one every time you detect it: if the receiver that 
    causes the collision does not receive the report packet, the collision will 
    continue and a new collision report will be sent after the next 
    observation of it by the source. 
    There is significant interest in this work and the authors should do their 
    best to meet the December milestone in the preliminary revised charter. 
    Colin Perkins pointed out that the definition of the "a=rtcp"  
    attribute contradicts the definition in 
    draft-ietf-mmusic-sdp-nat-05.txt.  The intention from the authors was to use 
    it as defined in the SDP NAT draft. 
    Colin Perkins noted that while the Security Considerations section has a 
    thorough declaration of the problems present with this RTCP 
    extension, there is a need to have normative declaration on how these 
    security considerations shall be addressed in different 
    applications. If not, there will not be possible to have an 
    interoperable implementations. 
     Requirements for performing RTP header compression over MPLS networks 
    Jerry Ash presented an introduction and motivation for the work that has 
    previously been discussed in the MPLS working group. There are several 
    ideas that has been proposed in this context. The main idea is to 
    provide RTP/UDP/IP header compression over several hops in access 
    networks on in backbones that have limited bandwidth or expensive 
    bit-rate costs. Ideas include that one can perform header 
    compression from an ingress point in an MPLS network to the egress point 
    without doing compression/decompression for each link.  Instead the MPLS 
    router can forward the compressed packets based on either MPLS labels, or 
    the compression context IDs. However the scalability of each solution 
    needs to be further investigated. The context switch idea could also be 
    applied outside an MPLS network for other links. Another part of the 
    complete framework is to ensure that the header compression mechanism can 
    handle the long delay that may result between the compression and 
    decompression points. So far the assumption is that ECRTP will be enough for 
    There were several voices raised questioning the need of this work, but 
    also some comments in support.  There seems to be interest to migrate 
    legacy voice channels done over circuit switched connections to instead use 
    VoIP, however there was confusion in regards to what "End-to-End" in the 
    presentation meant. However this is either MPLS ingress to egress, or in 
    some optimised cases may be through end-to-end if all nodes from 
    end-point to end-point support SCID switching and header 
    compression. This mechanism will not be media dependent as it will be able to 
    compress the header for any RTP transported media.  Although an initial 
    list of tasks was presented, some people expressed concern that the scope of 
    the work is not clear and that the rationale is poorly defined.  It is 
    apparent that the work must start by writing a requirements document which 
    defines the goals of the work, and reach agreement on that.
    Co-coordination with other working groups will be needed, in 
    particular the MPLS working group, and it is hoped that the people from 
    other WG will participate in also in the initial phases defining 
    				- * -


    AVT Document Status
    IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet
    RFC 2833bis
    Draft RTP Profile for Speex Audio
    Draft RTP Profile for Vorbis Audio
    draft-ietf-avt-ilbc-codec-02 draft-ietf-avt-rtp-ilbc-02
    RTP Payload Format for Uncompressed Video
    RTP Payload for JVT Video
    RTP Payload Format for 3GPP Timed Text
    RTCP Extensions for SSM Sessions with Unicast Feedback
    Requirements for End-to-End VoIP Header Compression