Last Modified: 2004-06-07
- 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.
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
|
Audio/Video Transport Working Group Minutes
60th IETF, San Diego Reported by Magnus Westerlund and Colin Perkins The AVT working group met twice during the 60th IETF in San Diego. The working group discussed RTP payload formats for several new codecs, a new RTP payload format for generic FEC, the RTCP XR MIB, how to frame RTP on connection oriented transport, RTCP Extensions for SSM, header compression requirements for MPLS, requirements for video codec control, the new RTP profile for congestion control with TFRC, the RTP profile for extended RTCP feedback, a multiplexing mechanism for RTP using the SSRC, a proposed multi-flow RTP-like protocol, and issues with the use of MIME types to identify RTP payload formats. Introduction and Status Update Since the last meeting the RTP specification and A/V profile (RFCs 3550 and 3551) have been advanced to full Internet standards (STD 64 and STD 65 - the RFC numbers are unchanged). The Secure RTP profile (RFC 3711) and the MIME type for 3GPP files (RFC 3839) have been published as RFCs. The iLBC codec and payload format (draft-ietf-avt-ilbc-codec-04.txt and draft-ietf-avt-rtp-ilbc-04.txt) are with the RFC Editor awaiting publication. The following working group drafts are in area director review: draft-ietf-avt-uncomp-video-06.txt draft-ietf-avt-text-red-05.txt draft-ietf-avt-rtp-retransmission-09.txt draft-ietf-avt-rtp-dsr-codecs-03.txt draft-ietf-avt-rtp-clearmode-05.txt all for eventual publication as Proposed Standard RFCs. The TCRTP specification (draft-ietf-avt-tcrtp-07.txt) is being updated to address IESG review comments, mostly due to obsolete references but also a few technical issues. The RTP payload format for T.38 was updated by the ITU-T after we had forwarded it's MIME type registration to the IESG for publication. The changes altered the MIME parameters, so draft-jones-avt-audio-t38-05.txt was returned to the working group for further review. The revised draft is in working group last call. The RTP payload format for H.264 video (draft-ietf-avt-rtp-h264-10.txt) is completing working group last call. The RTP payload format for MIDI (draft-ietf-avt-rtp-midi-format-05.txt) and associated guidelines (draft-ietf-avt-rtp-midi-guidelines-05.txt) have received external review comments from MIDI expert Dominique Fober. An update to the draft is in preparation taking into account this review, and is expected to be in good shape for working group last call. The update to the RTP payload formats for MPEG 1 and MPEG 2 video (draft-ietf-avt-mpeg1and2-mod-00.txt) has expired: if you have interest in pursuing this work please contact the chairs, otherwise the work will be dropped. The RTP payload format for Speex (draft-herlein-avt-rtp-speex-00.txt) has expired. It appears that there is no longer interest in pursuing this work within the group. The working group is shepherding MIME types registrations for the 3GPP2 file format (draft-garudadri-avt-3gpp2-mime-00.txt), and the MPEG4 file format (draft-lim-mpeg4-mime-02.txt) to ensure the drafts are well formed, before passing them on for MIME review. The payload format for ATRAC (draft-hatanaka-avt-rtp-atrac-family-02.txt) was accepted as a working group item, by the meeting. In addition, the following five working group drafts exist but were not discussed at the meeting: draft-ietf-avt-rtp-bv-00.txt draft-ietf-avt-profile-savpf-01.txt draft-ietf-avt-ulp-10.txt, draft-ietf-avt-rfc2833bis-04.txt draft-ietf-avt-rfc3119bis-02.txt Charter Update There are several milestones on the AVT charter that are late. A charter and milestone update is needed, and can be expected in few weeks. The first late milestone is requirements for MPLS header compression: it was proposed that the draft be held in the working group while the protocol was defined to allow requirements to evolve, however after discussion with our area director it was decided to send the draft on for publication to enable more widespread review of the requirements. The update of AVPF to draft standard will be rescheduled into the future, as the proposed standard is not yet published. The update of SRTP can soon be started, but will rescheduled with a more reasonable time frame. The work on SAVPF will hopefully complete soon. The working group has a milestone to update the RTP MIB due shortly. Alan Clark volunteered to start the work by doing some requirements capture, and Dan Romascanu volunteered as a MIB expert to work on this. We need to investigate if the RTP MIB has to be updated before the RTCP XR MIB can be progressed. New milestones are needed for both tasks. In addition, milestones for the RTP profile for TFRC congestion control (previously accepted as a work item) need to be added to the charter. RTCP XR MIB draft-clark-avt-rtpmibv2-01.txt Alan Clark presented the updates and status of the RTCP XR MIB. The draft has been split from the combined RTP and RTCP XR MIB that was presented at the 58th IETF, but the draft has not yet been renamed to match the content. Alan noted that there is considerable interest in the RTCP XR extensions and that this is driving new monitoring applications that affect the RTP MIB. Dan Romascanu agreed and noted that application and usage scenarios should be added to the draft. Dan asked what happens when traffic is encrypted: should the monitoring traffic also be encrypted, requiring the probes to share the secret of the session? Alan answered that if SRTP is used, a lot of relevant RTP header information is left unencrypted, and so he recommends that RTCP XR reports are left unencrypted. Dan commented that these considerations and limitations should be documented to ensure that these facts are understood. Alan replied that there is room for a good trade off between manageability and security in the available framework. Alan continued explaining that the SNMP syntax will need some more work, while the semantics is pretty in good shape. Further work that is needed is to extend the structure to allow for several nodes to report on the same session. Add event support, and possibility to provide some basic aggregated data. There was discussion of taking this draft as a work item, although this is conditional on approval from the OPS area directors. It was suggested that the RTP MIB be updated in parallel, since the XR MIB depends on new features in RTP since the MIB was last revised; this is appropriate. Dan Romascanu volunteered to be MIB advisor for the AVT working group, also subject to confirmation by the IESG. RTP Payload format for Generic FEC-Encoded Time-Sensitive Media draft-luby-avt-rtp-generic-fec-00.txt Ross Finlayson presented a new generic FEC proposal FEC for RTP, based on the work done in the Reliable Multicast Transport working group. It reuses the FEC building block defined in that group, and applies it to RTP traffic (or other types of streaming data). There are several technical open issues: 1) it is not clear how source blocks in the original RTP stream are arranged so that reconstruction can take place and what (if any) synchronisation markers are needed; 2) SDP signalling is poorly specified, in particular how the original RTP stream and FEC format are signalled; and 3) it is not clear how to signal the usage and necessary related information for non-RTP streams transported using this framework. Magnus Westerlund, Steve Casner and Colin Perkins commented on these issues, noting also the importance of both clearly signalling the format of the content, and of limiting the possible content to time-sensitive RTP data. The latter is especially important, since the working group has previously been careful to avoid defining generic mechanisms, as RTP does not provide for all use cases. A procedural issue is the relation of this work to the ongoing FEC work within AVT (the ULP and UXP drafts). The ULP draft, updating RFC 2733, is considered independent of this new work due to the separation of the original and protection stream in that format, and because ULP provides much simpler FEC options than the new framework. The UXP draft, which defines a Reed-Solomon based protection scheme with unequal error protection, is similar to this new draft. The protection method defined in the UXP draft could mostly be realised in this generic framework by defining a Reed-Solomon building block; indeed there is work in the RMT working group to do this. The unequal error protection seems more difficult to realise and would need further discussion on the need and usefulness. Stephan Wenger supported the continued inclusion of unequal error protection, since it is very useful for video encodings supporting data partitioning, however Michael Luby noted that it is not easy to specify in a format independent manner. Stephen Casner asked for clarification on the motivation and advantage of specifying a framework rather than continuing the ULP and UXP work. Michael Luby responded that it gives an advantage in selecting the most appropriate scheme for a specific application. Colin Perkins and Magnus Westerlund commented that this proliferation of FEC schemes is not necessarily a good thing and hinders interoperability. It was concluded that there is interest, but more work and discussion is needed before this can be accepted as a working group draft. RTP Payload Formats for H.261 and H.263 draft-ietf-avt-rfc2032-bis-01 draft-ietf-avt-rfc2429-bis-01 Roni Even outlined the status of these drafts, and current open issues. One change in this version is to remove the infrequently used H.261 NACK packets in favour of the mechanisms in the RTCP feedback mechanism draft. Colin Perkins and Steve Casner supported this, but noted that the draft needs to explain how this change affects the backwards compatibility. Stephan Wenger expressed concern that there may be implementations of some features, of which the group is unaware. How do we ensure that we are not removing features that are actually used? Colin Perkins noted that we clearly can't be expected to find all implementations, however the important thing is that we must make a sufficient effort to identify widely used implementations and discuss the issues with removing any feature. Specifically, we should consult at industry interop events and with the more popular open source implementations. An open issue is that the default mode for H.261 and H.263 is currently unspecified. Roni proposed that the default resolution be set as QCIF, Stephan Wenger proposed a default of 30 frames per second. Colin Perkins commented that there is need to define a reasonable default values, MIME parameters, to specify offer/answer considerations, and to note that these where not defined originally. Stephen Casner explained that at the time this format was originally defined, there where no negotiated usage and fewer optional modes of the codecs. Stephan Wenger commented that the video redundancy mode of the H.263+ is not used and can be removed. Colin Perkins and Allison Mankin noted that the original payload format for H.263 video (RFC 2090) should be classified as historic. To do this, a short draft explaining why implementation is discouraged is needed. Roni volunteered to write such a draft. It was noted that interoperability statements are needed before these drafts can be published as draft standard RFCs. The most likely course of action is to cycle these specifications as proposed standards while the interop results are collected, then reclassify the formats to draft standard. RTP Payload Format for JPEG 2000 Video Streams draft-ietf-avt-rtp-jpeg2000-05.txt Andrew Leung discussed the RTP payload format for JPEG 200 video. Colin Perkins noted that there is IPR covering material contained in the draft and asked for clarification on the licensing terms. It is to be hoped that these are not more stringent than the terms covering the codec - the authors were requested to clarify. The major change to this payload format is the removal of the extension mechanism, as no clear idea on what to use it exists. A restriction to not change the packetization mode within the same RTP session has also been introduced. The main open issue is if the non-intelligent mode really is necessary: is the reduction in sender complexity worth additional complexity in receivers and loss of error tolerance? Colin Perkins noted that there are likely to be two types of senders: live senders where the payload packetization is negligible compared to media encoding, and senders which play back stored files where hint tracks tells the sender when to split packets; in neither case is sender complexity an issue. Andrew maintained that the desired usage is for thin senders to thin clients. Colin requested that the authors do consider this, and may seek guidance from other people in the group that may have experience from similar systems. Otherwise, the authors plan to add further parameters to the MIME type definition, for example colour space and prioritization tables, and to clarify a number of editorial issues. RTP Payload Format for VMR-WB audio draft-ietf-avt-rtp-vmr-wb-01.txt Sassan Ahmadi noted that the VMR-WB codec is now complete, and reference software and the file format are soon to be released. The payload format has been updated to include offer/answer considerations, and to clarify use cases when interoperating with AMR-WB. A mode-set parameter is added to help negotiation in when gatewaying to circuit switched networks and for AMR-WB interoperation. Magnus Westerlund noted that there is an upcoming VMR-WB codec extension that includes more modes. The group needs to decide if the VMR-WB payload format should go forward now, or if it should be delayed to include the new modes in the codec extension. There was some discussion of file formats with Magnus Westerlund asking if it is necessary to define four different file formats with their own magic numbers, or if a single file format can be used, parameterised to define the file contents. Sassan expressed the desire to retain the existing formats, since they are used by 3GPP2. Stephen Casner asked if all the work to provide multi-channel support for AMR was really needed? Magnus answered that he didn't know of any usage. Sassan commented that as long as these features do not hurt interoperability there is no real harm with them. Stephen responded that the more optional features, the more likely interoperability problems would occur. Further if there are not two implementations of a feature, they will need to be removed when going to draft standard. Sassan commented that 3GPP2 is going to use VMR for streaming service, in which case stereo may be useful. An update is expected shortly. There is a desire to finish this work quickly, to satisfy 3GPP2 dependencies. RTP Payload Format for AMR-WB+ draft-ietf-avt-rtp-amrwbplus-01.txt Ari Lakaniemi started with presenting the Nokia IPR statement for RTP payload format. Colin Perkins asked if licensing terms for the payload format are more restrictive than for the codec. Ari, could not give a definitive answer, but was not expecting them to be. The draft has been significantly updated, mostly to match changes in the codec since February. The TOC has been changed to allow different mode indexes and ISFs to be used, the interleaving method has been changed to be more flexible by using a timestamp offset, and the MIME type has also been updated. Colin Perkins commented that there are several different things that are labelled as modes, a clearer terminology would make it easier to read and understand the format. The codec is expected to be finalised in the 3GPP SA4 in mid-August, and finally approved in mid-September. The authors expect to complete the payload format specification shortly after that time. Stephen Casner made a general comment that the RTP payload formats are getting more complicated, and that this is not necessarily a good trend. Colin Perkins requested that authors do pay attention to simplicity and clarity of writing; many formats - not only this - are not easy for non experts to read. RTP Payload Format for 3GPP Timed Text draft-ietf-avt-rtp-3gpp-timed-text-04.txt Jose Rey discussed changes to the 3GPP timed text payload format. A key change is that the aggregation and fragmentation rules have been simplified. Colin Perkins reacted positively to these changes, but also requested that the draft be updated to mention the benefits of smart fragmentation of modifier boxes, even though it does not require that an implementation be able to parse modifiers and perform any such smart packetisation (the aim is to encourage high quality implementations to pay attention to application-level-framing, while still allowing dumb implementations). The draft recommends a 1000 Hz timestamp, but allows other values. There was concern expressed that too low values will prevent RTCP from working correctly, and that the draft should explain the issue and recommend not to use low clock rates. Jose asked if it is appropriate to use screen layout parameters in a symmetric manner in multicast sessions? Magnus responded that this would depend on the use cases. Colin Perkins commented that the MIME type video/3GPP-timed-text could maybe be text/3GPP-timed-text? It is clearly text, however quite fancy text, and if that is sufficient reason for registering this under video instead was unclear, and should be further discussed. Input into this question is solicited (see also the discussion of MIME types later in these minutes). RTP Payload for Text Conversation draft-ietf-avt-rfc2793bis-08.txt Arnoud van Wijk presented a short status update, as the draft finished working group last call the day before the meeting. Comments were mainly positive, but a few require minor text changes. Colin Perkins outlined a comment received from our area director, that it seems inappropriate to include both text/t140 and audio/t140c in the same document, since it ties them together to advance at the same rate. The audio/t140c format is significantly less mature then the text format and leaving the two formats combined may delay the text/t140 in its progress to draft standard. Accordingly, the authors are requested to split the draft into two, one for each format. As this is an editorial request, it is hopefully not needed to have a new WG last call, unless technical content has been changed. RTP and MIME types draft-ietf-avt-text-red-05.txt Colin Perkins reported on some discussion regarding registration of MIME content types for RTP payload formats. The working group chairs and some area directors and MIME experts had a discussion about the registration of MIME types for RTP payload formats, triggered by the submission of the text/RED payload format for publication. The expert reviewers found a number of problems with the registration, which potentially affect other media type registrations for RTP formats. Some of the problems had to do with the more stringent requirements for registering text media type compared to audio and video types. The text formats are expected to be readable without any further processing, for compatibility with historical email usage. This requirement is clearly not meet by text/RED. An RTP format like text/t140 is more arguable as meeting these requirements, since each datagram actually contains pure text. This lead to further discussion on the how we are registering MIME types for RTP payload formats, since RFC 2046 doesn't allow registration of formats with only limited domains of usage, as we have been doing for the last 5 years and is documented in RFC 3555. This issue clearly needs to be resolved. The resolution is that the MIME registration rules will be changed to allow registrations with limited domains of usage (for example, formats defined only for transfer using RTP). In addition, complex text formats will be allowed, provided they have restricted domain of applicability, and do not affect backwards compatibility for email clients. This will require an update of the MIME registration rules, and most likely also changes to RFC 3555. These changes will be discussed on the IETF types mailing list <ietf-types@iana.org>. We do not expect these changes to significantly impact how AVT is doing registration, however some update to templates and details is to be expected. As these changes will take some time, some of the AVT documents may be delayed, specifically the text/RED document (although that draft will be progressed in parallel with the rule changes, to reduce the delay as much as possible). Stephen Casner noted that the current MIME registrations published in RFCs for payload formats will most likely not need to be updated immediately, but rather at the point when the formats are updated to draft standard. The chairs noted that they will now require MIME review of all new RTP payload formats prior to working group last call. Expert review should be solicited on the <ietf-types@iana.org> mailing list, giving at least 2-weeks review time. This requirement applies to all RTP payload format RFCs produced; either new or updating existing formats, no matter what MIME top-level types they are to be registered under. MIME reviews were previously solicited by the IESG as part of their document review, this change in procedure simply means that it happens earlier, and is more visible to the working group. Framing RTP and RTCP over Connection-Oriented Transport draft-ietf-avt-rtp-framing-contrans-03.txt Colin Perkins outlined the status of the connection oriented framing draft for John Lazzaro, who was unable to attend. This draft has been updated to match the changes in draft-ietf-mmusic-sdp-comedia-08.txt, but is otherwise stable. The only open issue is to decide if the draft should also define a mapping over secure connection oriented transport (e.g. over TLS). This was discussed in MMUSIC, with the conclusion that this is potentially useful, but that there is insufficient interest to complete the work at this time. Colin reported this result to the group, noting that support for secure connection oriented transport would be dropped unless there is a volunteer to complete the work. RTCP Extensions for SSM Sessions with Unicast Feedback draft-ietf-avt-rtcpssm-07.txt Joerg Ott presented the revision of the draft, which clarifies the usage of buckets. A lot of editorial issues have been resolved. In addition it has been clarified what to do with the distribution source: this is now defined so that it works as an RTP receiver with its own SSRC, making it possible to have separation between sources and the distribution entity. The drawback is minor, as it will use some more bandwidth with its own RTCP receiver report. Colin Perkins commented that this new concept is not completely clear in the draft, and a few examples could help. Joerg also noted that comments have been received from Magnus Westerlund, and will be addressed in the next revision. It is believed the protocol is now stable, and that the draft will be complete once these comments are incorporated. RTP Profile for RTCP-based Feedback draft-ietf-avt-rtcp-feedback-09.txt draft-burmeister-avt-rtcp-feedback-sim-06.txt Joerg Ott continued by presenting the changes that have been made to the AVPF profile to address comments received as a result of IESG review. Two technical changes have been made: 1) removed any hints that the feedback, as currently defined, can be used for congestion control; and 2) the generic ACK message has been removed, since it could be misunderstood to be part of reliable transport mechanism. Applications that need positive acknowledge can define media specific ACKs for specific use cases. Stephen Casner commented that the removal of the H.261 NACK message in the latest revision to that format is based on the belief that the AVPF profile will provide that service, but no codec specific message is defined. Joerg responded that it is intended that the generic NACK message present in the draft will be used. The bit fields of it are even modelled after the H.261 (RFC 2042) definition. Stephan Wenger commented that there is also a video specific NACK message that allows one to NACK specific macro blocks. A few minor issues were missed during the update of the draft (see the IESG review comments). The draft will be updated to address these, and then will be go back to IESG for approval. RTP Profile for TCP Friendly Rate Control draft-ietf-avt-tfrc-profile-01.txt Ladan Gharai outlined the changes in the latest RTP profile for TFRC, and summarised open issues. This version of the draft introduces a 16 bit quad RTT counter instead of a 32 bit timestamp, to reduce the size of the profile extensions to the RTP header. Stephen Casner commented that it was intended that RTP header should be in units of 32 bits, and would recommend that this is maintained in the TFRC profile, making it difficult to use a 16 bit RTT counter. Colin Perkins suggested that using a send timestamp would allow for correct jitter calculations and better buffer management, and solve an oft-noted limitation of RTP. This desire to reintroduce the sending timestamp was also supported by Steve Casner and Magnus Westerlund. Another issue is the size of the RTCP packets, since the minimum size of the RTCP feedback is 84 bytes. When combined with a TFRC requirement to send one message per RTT (or one per packet, if sending at less than one packet per RTT) this can result in high feedback bandwidth. Indeed, if one adheres to the RTCP timing rules, there is only a limited range of RTT/bandwidth combinations that support TFRC feedback (see graph in the presentation slides). There are two options to increase the feasible use domain: allow feedback more often, or reduce the size of the feedback packets. There was some discussion of the amount of feedback generated, and how this compares to the feedback in a TCP connection, started when Stephen Casner raised the concern that allowing frequent RTCP feedback could be viewed as overly aggressive. This is possible, but Ladan explained that this is a feature of TFRC, which sends feedback packets independently of the forward rate, unlike TCP where ACKs are clocked by forward traffic. In addition, RTCP feedback packets used in this profile are considerably larger than TCP ACKs, and cannot be piggybacked onto data packets. Stephan Wenger commented that for higher video rates the feedback traffic packet sizes will be an order of magnitude smaller then the payload: wouldn't it make sense to specify a restriction, that the feedback traffic must not be bigger than some fraction of the forward traffic? This would limit the usage from very low RTTs or for small forward packets. Stephen Casner commented that this limitation, which prevents it from being used in certain combinations, is not really workable. Further one can't make assumptions that the forward and feedback path has the same bandwidth availability, thus comparing forward and backward packet sizes and rates are not a valid operation. Discussion then moved onto the option of reducing the size of feedback messages by allowing them to be sent as non-compound RTCP packets. Stephan Wenger commented that this profile seems mostly useful for high bit-rate usage and in those cases, for any network with more than a single hop, the RTT will be large enough that the feedback will be order of magnitudes less then the forward traffic. To keep things simple it would be preferable not to introduce different processing rules for feedback packets versus other RTCP packet types. Stephen Casner also commented that with the intention of going to experimental, it seems unnecessary to do optimisations until we know that this actually works and have plans to go beyond an experimental status. Another question is if this profile needing to share the static payload type space with the RTP/AVP profile, or could the static definitions be removed? Finally, Colin Perkins asked if this profile should include security by default, rather than defining a non-secure version now and later an SRTP based version as yet another profile. Feedback from SRTP experts was solicited. Requirements for transport of video control commands draft-basso-avt-videoconreq-01.txt Andrea Basso presented the current status of the video codec control requirements work. There have been a number of clarifications in the latest draft, videofastupadteGOB has been removed, and alignment with H.241 has been improved. It is hoped that the set of codec control commands is now final, so we can move rapidly ahead with requirements for their transport. Stephan Wenger raised the issues of congestion control and reliability for codec control commands, noting that he is concerned that this work could develop into a reliable signalling protocol. The chairs reassured him that the codec under control would be required to act in accordance with congestion control, and that reliable signalling protocols would not be developed in AVT. Christer Holmberg commented that there is no need to finalise the requirements document at this time, and to instead let is evolve with the design work. Andrea responded that although requirements tend to evolve, there is significant experience in this area from other standards and conferencing applications. Colin Perkins commented that there has been significant discussion earlier, and that we should start with what can currently be agreed on. In the future the list of commands can be extended if needed. Roni Even commented that some of the requirements can be solved by existing protocols, and the draft should reflect this. Andrea, responded that this is good comment, and should be clarified in the next revision. Stephen Casner commented that earlier in this discussion there where indications that some of the commands would fit RTCP, why others would clearly not: is it the intention to try to find a common solution for all of them? No, it appears rather clear that some can be implemented on existing protocols, and some may need its own protocol. Roni Even commented that the direction of the commands is important and effect how it would work. The plan is to finalise the requirements, so that we can figure out the charter item for AVT, or any other WGs. Header Compression over MPLS draft-ietf-avt-hc-mpls-reqs-02.txt draft-ash-avt-ecrtp-over-mpls-protocol-01.txt Jerry Ash outlined the current status of the requirements draft. This has completed working group last call on the mailing list, with the only open issue being if it should be sent to the IESG for publication now, or kept in the working group for possible update as solutions are developed. After discussion with the area director, it was agreed to send the draft forward for publication, after minor editorial work. Jerry also presented the updates to the solutions draft. Colin Perkins commented that this draft does not tell you how it actually addresses the requirements, and suggested that this be clarified in the next version. Magnus Westerlund asked why it is necessary to have a separate signalling protocol to negotiate the session context identifiers (SCID) between ingress and egress nodes. Jerry answered that in some cases several ingress nodes initiate flows to a given egress node, and since the MPLS labels at the egress node are not necessarily unique for each ingress node, the SCIDs are needed to uniquely identify each flow. Someone asked if there is any connection between the SIP call IDs and the SCIDs. Jerry answered that they are independent, but related to the actual streams in the call. The chairs noted that we need to recharter to find an appropriate long term home for the protocol work. This will be discussed with the area directors and other interested parties, and we will report back to the mailing list. A Multiplexing Mechanism for RTP draft-peterson-rosenberg-avt-rtp-ssrc-demux-00.txt Jonathan Rosenberg presented an initial proposal on how to deal with the problem of firewall traversal for RTP, using SSRC multiplexing on well known ports, one per media type. Comments received on the mailing list indicated that this proposal was not liked, but Jonathan hoped that presentation would provide some further motivation and allow discussion on the issues. Carsten Bormann asked why not use a different IP protocol number for RTP (much as Jonathan has previously proposed), with the new protocol number being used to determine the intended use of a packet. Minutes of AVT at the 41st IETF meeting contain some reasons why this is not a favoured solution; it was also commented that most firewalls do not support UDP-Lite which uses a similar technique. Stephen Casner noted that using a well-known port doesn't provide any significant security benefit, since other applications can use the port. The security gain comes if only trusted application can use this port, which is not likely to be true. Jon Peterson noted this is the same as any firewall that uses ports to identify services. Flemming Andreasen, Magnus Westerlund and Dave Oran made similar points, noting that this proposal only addresses the access control list type of security, and that firewalls often contain additional mechanisms to impose more complex policies than can be expressed in terms of well-known media ports. Dave Oran also wondered if using well-known ports would not invite more attacks since it would make it easier to identify the media services? Jonathan answered that this is dual edged sword, since it also allows one to turn off all other services on that port, rather than worrying which dynamic port media services are using. It was noted that this rapidly leads to the idea of a hybrid solution, where inbound firewall holes are opened only when there is an active session (there is a clear temptation to colocate a STUN server with the firewall, and use this to control policy, although Jon Peterson noted that the security properties of STUN are not sufficient for this). There was some discussion on the appropriateness of SSRC multiplexing, led by Magnus Westerlund. RFC 3550 identifies some reasons why this is not a good idea - and those are addressed in the draft - but there are others: how to signal valid SSRCs in dynamic sessions (e.g. in an XCON session with media mixing); and how to support SRTP without compromising security. None of these are insurmountable, but the signalling is not simple, and is complicated by the installed base on unaware systems. Colin Perkins concluded by noting that there is clearly an interest in this area, however many doubt that this is the right solution. It would be best to clarify the problem that one tries to solve, to gain a better understanding of the solution space. MRTP: A Multi-Flow Real-time Transport Protocol draft-narayanan-mrtp-00.txt Sathya Narayanan presented a new proposal that intended for information and discussion by the IETF. The proposal has no official status and any progression is subject to the normal procedures of getting it chartered as a working group item somewhere, or conditional on the outcome of a BOF to start a new effort. Jonathan Rosenberg questioned the benefits of MRTP compared to existing RTP mechanisms used along with source routing to select a network path, and with a smart implementation to handle striping across streams, and reconstruction of the result. Stephen Casner commented that RTP already has a layered concept, and that RTP implementations are often tightly linked with their applications: the normal kernel interface is often UDP. Due to this it should be considered if this is an API question, where a different API to the application could in fact encompass the necessary functionality. There was some discussion regarding the ability to choose source routes for packets in existing networks, with Dave Oran noting that this is often not possible. This will restrict the applicability of MRTP to limited classes of (ad-hoc?) networks. Allison Mankin noted that this is not inherently a real-time protocol: the initial drivers have been real-time applications, but the main new feature is that the protocol takes multi-path into consideration. Sathya asked if there is interest to provide an application with an end-to-end transport service that handle multi-path with fragmentation and per flow and session feedback. Stephen Casner commented that it might be that applications actually like to have more influence of how the channels are utilised. Sathya commented that the MRTP proposal allows for both a default data partitioning and application specific ones. Colin Perkins concluded that there seem to be some interest, however it has clearly wider scope than this working group. Especially as there where some discussion on generalising the concept. Colin proposed that a way forward could be to bring it up on the TSVWG mailing list. Management of RTP related functionality Alan Clark expressed the opinion that market research has found one of the major reasons why VoIP has not been deployed in enterprises, after security, is the lack of management and monitoring tools. The group should pay more attention to performance monitoring, perhaps going so far as to require new drafts to contain a section that explains how to do this? Stephen Casner commented that this would be desirable, however he worried that our record with other required sections (e.g. security and congestion control) is less than perfect. This is an indication that we probably would not do this as well as might be desired. Colin Perkins concluded that the group should consider this as best as possible when creating new specifications. |