Last Modified: 2005-01-25
| Done | Review DCCP including prototypes and API; feedback to DCCP WG | |
| Done | Initial draft requirements for ECRTP over MPLS; discuss with MPLS WG | |
| Done | Submit iLBC payload format for Proposed Standard | |
| Done | Submit iLBC codec specification for Experimental | |
| Done | Advance RTP specification and A/V profile to Full Standard | |
| Mar 04 | Finish requirements for ECRTP over MPLS; recharter for subsequent work | |
| 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 | |
| Sep 04 | Submit RTCP/SSM draft for Proposed Standard | |
| 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 | |
| Dec 04 | Identify payload formats to classify as Historic | |
| Dec 04 | Submit Framing of RTP for TCP and TLS for Proposed Standard | |
| Mar 05 | Submit RTP/AVPF for Draft Standard | |
| Mar 05 | Submit SRTP for Draft Standard |
| RFC | Status | Title |
|---|---|---|
| RFC1889 | PS | RTP: A Transport Protocol for Real-Time Applications |
| RFC1890 | PS | RTP Profile for Audio and Video Conferences with Minimal Control |
| RFC2029 | PS | RTP Payload Format of Sun's CellB Video Encoding |
| RFC2032 | PS | RTP payload format for H.261 video streams |
| RFC2035 | PS | RTP Payload Format for JPEG-compressed Video |
| RFC2038 | PS | RTP Payload Format for MPEG1/MPEG2 Video |
| 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 |
| RFC2736 | BCP | Guidelines 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 |
| RFC3545 | PS | Enhanced Compressed RTP (CRTP) for links with High Delay,Packet Loss and Reordering |
| 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 |
| RFC3611 | Standard | RTP Control Protocol Extended Reports (RTCP XR) |
| RFC3640 | Standard | RTP Payload Format for Transport of MPEG-4 Elementary Streams |
| RFC3711 | Standard | The Secure Real-time Transport Protocol |
| RFC3951 | E | Internet Low Bit Rate Codec |
| RFC3952 | E | RTP Payload Format for iLBC Speech |
| RFC3984 | Standard | RTP payload Format for H.264 Video |
|
Audio/Video Transport Working Group Minutes Reported by Magnus Westerlund and Colin Perkins Introduction and Status Update The Audio/Video Transport working group met twice at the 62nd IETF meeting in Minneapolis (6-11 March 2005) and was chaired by Colin Perkins and Magnus Westerlund. After an introduction and brief status update from the chairs, discussion proceeded around several RTP payload formats, RTCP extended reports, RTP header compression over MPLS paths, packet reordering in ECRTP, congestion control for real-time traffic, and RTP-based protocols for desktop and application sharing. RTP Payload Format for JPEG 2000 draft-ietf-avt-rtp-jpeg2000-07.txt draft-ietf-avt-rtp-jpeg2000-beam-00.txt Andrew Leung summarised the status and outlined changes in the JPEG-2000 payload format, which has been split into two drafts since the previous version (IPR statements have not yet been updated to reflect the split). Steve Casner raised the issue that if using the same MIME type, then compatibility should be a requirement (although there may be degraded performance). Magnus Westerlund and Colin Perkins together commented that if there is interoperability when ignoring the "beam" parameters and payload header fields, then there is probably no need to have an explict signalling indication of the mode. Andrew responded that the beam parameter may be required as it isn't required to set the "beam" header fields to a specific value if not supporting them. Magnus noted that it is probably simpler to require a non beam supporting server to set the priority field to 255. The drafts needs some more editorial work. Magnus Westerlund requsted that the drafts clarify that the "beam" stuff is an extension. Andrew informed the working group that there is ongoing work to define JPEG 2000 wireless extensions (JPWL) and that it be a benefit to align their proposals with this payload format. They have mainly one extra feature that these drafts doesn't support, and that is for interleaving. Colin responded that there is danger with too many optional features and we should spend some effort on understanding their requirements to see which is the appropriate way to proceed. RTP Payload Format DTMF Tones, Telephony Events, etc. draft-ietf-avt-rfc2833bis-08 draft-ietf-avt-rfc2833biscas-00 draft-ietf-avt-rfc2833bisdata-01 Tom Taylor explained that the previous 2833bis draft has now been split into three parts (a basic core specification, an extension for modem related events, and an extension for CAS related events), and outlined the status of the drafts representing each part. Tom also presented the changes since RFC 2833 as a preparation before WG last call. Colin Perkins raised the issue that RFC 2198 is inteneded for sending multiple and potentially different representations of the same data. Sending different type of information in the same payload using RFC 2198 is wrong: there are more appropriate ways of doing this. Tom responded that it is only different encodings of the same data and the text will be clarified. Tom Taylor raised the issue that there is no way of expressing amplitude of modulation using the tones payload. Steve Casner commented that either nobody has used this feature, or there is not a problem. Therefore it is questionable if we need to fix it. This applies also to the proposal to reorder numbering in some frequency table in the DMF numbering as proposed by a slide. The simplest is propably to leave things alone unless somebody require a feature. Colin Perkins concluded by noting that the outstanding issues appear to be minor, and solicited reviews of the drafts from experts in the area before working group last call. New mode for RFC 3640: AAC-BSAC with MPEG-21 gBSD draft-feiten-avt-bsacmode-for-rfc3640-00.txt Ingo Wolf presented a proposal to create a new mode of operation for the RFC 3640 generic MPEG-4 payload format. The mode is for carrying MPEG-21 digital item adapation information, which is written in XML for the AAC-BSAC audio codec. Steve Casner questioned the need for including this information in-band, wondering if it is possible to convey the data out-of-band to avoid the overhead due to the XML representation. Ingo replied that the data might theoretically be different for each packet, so it is desirable so convey it in-band, and commented that the XML data can be compressed to give an overhead of only 10-15% compared to the BSAC frame size. Colin Perkins asked if the data could be derived from the payload, rather than being conveyed as a separate description? This is possible, but would require the adaptation point to parse the payload, which is a complex operation that may not be feasible on a large scale. Stephan Wenger suggest an alternative design that uses two synchronised RTP sessions, one for the media and one for the adaptation information. This would allow participants to choose whether they wish to receive the adaptation information as part of an end-to-end session setup, without the need for a middlebox to act as an adaptation point. There are some discussion regarding the appropriateness of middlebox based adaptation solutions, with Colin Perkins noting that RTP does support this concept (via the RTP translator abstraction) provided the presence of the middle box is signalled. Colin Perkins asked what is the reason to have this as an named mode of RFC 3640, rather than using the generic mode? Ingo responded that is to indicate the presences of the auxilary data field and its content in accordance with RFC 3640 recommendations. Magnus Westerlund asked how likely that there is to see other proposals for carrying this generic scalibility information for another media. Don't really know, but the decription format is very generic and could be used for any other scalable codec. Stephan Wenger and Colin Perkins commented that from an architectural point of view it would make more sense to have this information in a seperate stream, allowing it to be used with any stream rather than defining a point solution. In conclusion, there is some interest but also much concern about this work. The way forward would be to consider the bigger picture, working on requirments to decide if it is worth generalizing the solution. And it is important to not forget how security functions will fit such an architecture. RTCP XR - New Parameter Extensions draft-ietf-avt-rtcpxr-bis-00.txt Amy Pendleton presented this new proposal for extensions of the RTCP XR metrics. This includes updating and extending the VoIP metrics, a new Video metric metric block, and a link layer metric block. There was considerable discussion about session identification, and if there is a need to convey information binding the metrics to a specific RTP session in band, or if it can be derived from external signalling information. Steve Casner argued that the monitoring information won't be useful unless combined with the call setup information from the signalling channel, so there is no need to convey session identification information inband. The counter argument from Amy was that monitors are sometimes operated without access to the signalling data, but Steve was unconvinced that the probes are useful in this case since they miss too much information about the session (the correlation between the session parameters and the probe data can be done offline, but is needed to make sense of the measurements). Steve's argument was accepted in principle, but it was commented that getting access to the signalling database is often difficult in practice, and implementations need to work with more limited access. Colin Perkins commented that he could understand the interest in session identifiers, but there are also privacy concerns that should be addressed. Another issue raised was the inclusion of codec configuration data in new RTCP XR clocks. Colin Perkins commented that this raises concern since there is a risk that people will not use the proper signalling, instead relying on these indications to configure codecs. Amy replied that this is important information when judging the quality and needs to be conveyed. Colin acknowldeged this point, but commented that the information does not belong in RTCP and should be discovered through a signalling protocol. There was no real conclusion on the subject on in-band information for session identification and codec configuration. The next version of the draft will include more discussion of the requirements and motivation, to attempt to resolve the issues. Steve Casner asked if there is need to wait until the quality metrics methods stabilize, since we don't want to standardize updates every 6 months when new methods are made available. Amy acknolwdged that this is a problem that needs be considered, and indeed is a problem in the currently published RTCP XR specification. Dan Romascanu commented that we need to find a way of modularity, providing a framework that more easily can update, perhaps using IANA registry. Colin Perkins commented that to much flexibility can easily result in loss of interoperability. Stpehan Wenger wondered if it would make sense to send this information as some type of XML scheme, leaving certain definitions to other groups that have more knowledge about the speech quality measuremnets. Steve Casner commented that is not clear that updating and adding new metrics really provide any benefit, as for this to be useful there is clearly need to have it implemented and widely deployed. The discussion moved on to the proposed new Video metrics block. It was asked if this is intended to be a "figure of merit", or a more absolute metric like MOS? The feeling is that the field is not mature enough to have absolute value metrics, and that the goal is to have a report block that can give a "good indication" of what is happening. This needs to be made clear in the draft, along with clarification of the proposed usage scenarios (interactive vs broadcast). Colin Perkins commented that this is clearly something reasonable to do, however the work is clearly less well defined than the update of the VoIP metrics block, and therefore it is recommended to split them into two seperate drafts which will be progressed separately. Discussion continued with the proposal for a new link layer metrics. Dan Romascanu suggested that this is not a good idea, and that we should not turn RTCP into a general purpose control plane protocol. Steven Casner agreed and commented that the most constricted link in many environments is not the nearest link, which makes this proposal less than useful. The general agreement was that this metric is not strictly necessary, and may not be general useful. RTCP XR MIB draft-avt-rtcp-xr-mib-01.txt Amy Pendleton presented the status and updates of the RTCP XR MIB. There has been discussion around if the MIB should include only VoIP metrics block or also the other blocks. The consensus seems to be that only VoIP metrics is currently of interest. Colin Perkins commented that there needs some introduction text that clarifies that only VoIP metrics are included in this MIB. Dan Romascanu commented that the quality from SNMP point is much improved. An editorial comment, is the title. Colin Perkins asked about the relation is between the RTP XR MIB and the standard RTP MIB, and if there is any overlapp or dependencies. Dan (in role as MIB advisor) commented that the new charter and milestones says that both the XR and RTP MIB should go forward before November. Therefore it is clearly expected that some work is done also on the RTP MIB. Colin responded that we do need some work on the RTP MIB, but if there exist no dependencies, the we don't need to create any artificial ones. Dan responded that the dependency is in the deployment and usage. If the XR and RTP MIB are expected to be used in together they will be out of sync if not updated. RTP Header Compression over MPLS draft-ash-avt-ecrtp-over-mpls-protocol-02.txt Jerry Ash presented the status of the open issues. The biggest issue discussed was how to ensure multi-point to point MPLS environments can work with header compression, and whether the currently proposed solution is appropriate. Andy Vallence stated that the labels are hierarchial and a solution could be to define a new pseudowire type for MPLS HC. Colin Perkins commented that there seems to be agreement to try to use a method that establishes single logical decompressor per compressor, instead of any Context ID signalling. Andy clarified that using pseudowires would mean that each different ingress node would have its own pseudowire to the egress, providing context to allow emulation of a point to point link. Carsten Borman commented that for compressor to decompressor protocols this work seems to have similar issues as the 802.x adaptation of header compression (draft-bormann-rohc-over-802- 01.txt) and that it might be appropriate to review that work. Colin Perkins and Steve Casner both commented on some misundersandings of ECRTP operation in the draft and slides (e.g. collisions in the SCID space are not possible). These may be influencing the design choices in the wrong direction. The draft will be extensively updated to try resolve the issues. Packet reordering in Extended CRTP draft-koren-avt-ecrtp-reorder-00.txt Tmima Koren summarised the draft on operation of ECRTP over links that can reorder packets. Carsten Borman noted there is an extensive draft on ROHC over reordering which answers similar questions: it would be good to see the same level of detail in this draft. Carsten also noted a thesis from Lulea university that may be relevant to the discussion (http://epubl.luth.se/1402-1617/2004/286/LTU-EX-04286-SE.pdf also noted by Lars-Erik Jonsson on the mailing list). Colin Perkins commented that it would be desired to have more analysis and statistics that shows that ECRTP really works over reordering. Magnus Westerlund commented that the document should ease implementation of ECRTP for reordering links. Tmima responded that there is a basic mode, and there is further things to do to improve performance. Tmima Koren, asked if this draft could become an AVT work item. Colin Perkins responded that it is a very reasonable to thing for the group to work on, however there need to be more detail in the draft before we accept it. TFRC VoIP mode draft-ietf-dccp-tfrc-voip-01.txt Sally Floyd outlined a proposal from the DCCP working group for a TFRC voice-over-IP mode, which is relevant to the RTP profile for TFRC that is being developed in AVT. The standard TFRC algorithm has the goal of providing fairness to TCP in terms of the number of packets sent per second, but it is known that it isn't fair to applications - such as voice over IP - that transmit small packets. The goal for the VoIP variant of TFRC is to provide fairness to TCP in bytes-per-second for flows that send small packets, making TFRC more usable for voice applications. Sally outlined the operation of the algorithm, and presented extensive simulation results showing operation of TCP compared with standard TFRC and TFRC in VoIP mode, and outlined open isses. The results show that TFRC VoIP mode generally performs much better than standard TFRC for applications sending small packets, and gets throughput much closer to that of a TCP connection (see slides). Colin Perkins asked if a TCP flow sending small packets would also be affected by these problems and get much less than desired throughput? Yes - current TCP penalises all flows that send small packets, whether TCP, TFRC or UDP. TFRC VoIP mode is intended to correct this, allowing real-time streaming applications that send small packets to get better performance than they currently would using TCP. Colin Perkins asked if this new variant needs additional feedback data compared to standard TFRC? Yes, there may be a need to slightly change the calculation of the loss event rate which is returned by the receiver. Henning Schulzrinne commented that much of the effort in desiging this new algorithm has been put into operation at high loss rates, a region where VoIP flows typically don't operate. He asked if it might be more appropriate to simply cease transmission when the loss rate increases, rather than spend the effort to more the protocol operate in a regime where the applications generally don't work. Sally replied that the work is done in the context of the DCCP protocol, which is intended to be generally useful rather than being limited to a particular application and so will need to operate at high loss rates. She has no objection to a variant that stops transmission at high loss rates, however. Magnus Westerlund agreed with Sally, commenting that there may be applications that can scale their transmission rate and make use of the limited capacity available with high loss rates. Protocols for Application and Desktop Sharing draft-lennox-avt-app-sharing-00.txt draft-schulzrinne-mmusic-sharing-00.txt Henning Schulzrinne discussed some work his group has done on protocols for application and desktop sharing. This is not a work item of AVT but was presented for information, to determine if it might be appropriate to adopt as a future work item. The motivation for this work is to allow remote viewing and access of unmodified applications, without sharing application state. An aim is to integrate with the IETF session architecture, unlike the old T.120 protocol. Henning outlined the requirements and summarised an initial protocol design outline using RTP to convey bitmap display output and keystroke/mouse input. After a number of questions for clarification, there was considerable discussion of the "big picture" open issues. Carsten Bormann wondered if this is now the right time to solve the problem, and if AVT is the right home for the work? Carsten was unconvinced by the arguments for using RTP: there are definitely some requirements for real-time data, but general remote access is not always perceived as a real-time application (indeed, the protocol uses RTP over TCP). The landscape of requirments varies: some applications have latency and timing constraints, particularly for input; others do not. It is not clear that the appropriate trade-off has been made, or that we have a good handle on the problem space. Carsten also noted that different types of operating system have become more similar over time, so the problem might be easier than when previous solutions were last developed, and that now might be a good time to attempt a new solution. Keith Lantz expressed similar concerns: this is clearly an important problem to solve, but he is not sure this is the right architecture and AVT may not be the right home. Perhaps we need to better understand the architecture to know if this is the appropriate solution? Some interest was also expressed in scaling one small screen devices, although it is unclear how that use case fits into this model. LRDP: The Lightweight Remote Display Protocol draft-stirbu-avt-lrdp-00.txt draft-stirbu-mmusic-scal-sharing-00.txt Vlad Stirbu outlined a proposed lightweight remote display protocol. This is not a work item of AVT, and was again presented for discussion to determine if it might be appropriate to adopt as a future work item. The aim of this protocol is to allow remote access to applications on a range of devices with different user interfaces, display size, windowing system and widget set, user input method & navigation logic. The protocol describes a UI in terms of logical widgets and communicates updates to an application's state as a logical operation, rather than as bitmap screen updates. Accordingly, it requires modification to applications and has a very different scope to the proposal presented by Henning Schulzrinne. Colin Perkins noted that the negotiation of this protocol in SIP/SDP is clearly in scope for the MMUSIC working group. He then asked for the opinions of those in AVT regarding the suitability of the protocol as a potential work item for AVT. Steve Casner noted that this protocol requires more general modelling of application state, and is very different to Henning's proposal. For an application of this type, it might be expected that reliable transport of the data is more important than timely data transport, and it's not clear that RTP is an appropriate transport protocol for this application. Keith Lantz made similar observations. This is a problem that is worth solving, but too far removed from the expertise of AVT. Henning Schulzrinne noted that we can abstract to some extent details of how the user interface is to be respresented, but without knowing the details of how events are to be represented this becomes a very abstract protocol to "ship events around". Without knowing the details of the UI description language, the protocol is too generic to sensibly work with. Vlad argued in favour of genericity and abstraction, and of leaving the application model outside the scope of this protocol, but Henning was not convinced. Stephan Wenger commented that the two application sharing protocols are focussed on different environments: narrow application space with low bandwidth, or wide application space but high bandwidth. There was some discussion of differences between the applications, and the appropriate choice of protocol architecture for different scenarios, but little in the way of resolution. Keith Lantz concluded by commenting that, since applications need to be modified, this proposal is probably outside the scope of the IETF: once the application sharing model has been defined, we may be able to provide more useful input. Colin Perkins concluded by asking for expressions of interest in the two proposals. The group expressed interest in further considering Henning's proposal, although it is not clear that AVT is an appropriate long term home for the work (indeed, a new working group may be more appropriate). There was consensus that the proposal presented by Vlad was interesting, but that it is clearly outside the scope of AVT and should be pursued elsewhere. -- + -- |