HTTP/2 302 date: Mon, 14 Jul 2025 01:00:08 GMT content-type: text/html content-length: 143 location: https://get.ietf.org/implementation-report/report-avt-rtp-rtcp.txt cache-control: private, max-age=0, no-store, no-cache, must-revalidate, post-check=0, pre-check=0 expires: Thu, 01 Jan 1970 00:00:01 GMT vary: Accept-Encoding server: cloudflare cf-ray: 95ed14d8cf60b277-BLR alt-svc: h3=":443"; ma=86400 HTTP/2 200 date: Mon, 14 Jul 2025 01:00:09 GMT content-type: text/plain etag: W/"a63137c9ba331960ee0ffa36f9b847c0" vary: Accept-Encoding server: cloudflare cf-ray: 95ed14d9faaec1b5-BLR content-encoding: gzip alt-svc: h3=":443"; ma=86400 RTP/RTCP Implementation Report ============================== This implementation report is for the RTP/RTCP specification and audio/video profile to advance to draft standard. The corresponding drafts are: draft-ietf-avt-rtp-new-11.txt draft-ietf-avt-profile-new-12.txt Due to the nature of RTP, the implementation report is split into several parts. For the RTP specification, features fall into two classes: those which directly affect the interoperability of implementations at a bits-on-the-wire level, and those which affect scalability and safety of the protocol but do not directly affect interoperability. For the audio/video profile the features to be verified are those features of RTP that can be specified or modified by a profile, along with a list of payload type mappings. The features of the RTP specification which relate to interoperability are as follows: 1. Interoperable exchange of data packets using the basic RTP header with no header extension, padding or CSRC list. o PASS: many implementations, tested Cisco IP/TV with UCL rat and LBL vic and vat. 2. Interoperable exchange of data packets which use padding. o PASS: tested Cisco IP/TV with rat 3. Interoperable exchange of data packets which use a header extension. There are three possibilities here: a) if both implementations use a header extension in the same manner, it should be verified that the receiver correctly receives the information contained in the extension header; b) If the sender uses a header extension and the receiver does not, it should be verified that the receiver ignores the extension; c) If neither implementation implements an extended header, this test is considered a failure. o PASS: Jori Liesenborgs tested jrtplib-2.4 against the UCL RTP library v1.2.2 by building test applications which show that the receiver correctly receives the information contained in the extension header. The header extension has also been used experimentally in research projects, which is the purpose for which it was intended. 4. Interoperable exchange of data packets using the marker bit as specified in the profile. o PASS: tested UCL rat with LBL vat, and Cisco IP/TV with vic 5. Interoperable exchange of data packets using the payload type field to differentiate multiple payload formats according to a profile definition. o PASS: many implementations, tested Cisco IP/TV with UCL rat and LBL vic and vat. 6. Interoperable exchange of data packets containing a CSRC list. o PASS: tested LBL vat with the mixer built into UCL rat-3.0 and Cisco IP/TV with vat/vic 7. Interoperable exchange of RTCP packets, which must be compound packets containing at least an initial SR or RR packet and an SDES CNAME packet. Other RTCP packet types may be included, but this is not required for this test. o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic. 8. Interoperable exchange of sender report packets when the receiver of the sender reports is not also a sender (ie: sender reports which only contain sender info, with no report blocks). o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic. 9. Interoperable exchange of sender report packets when the receiver of the sender reports is also a sender (ie: sender reports which contain one or more report blocks). o PASS: tested rat with vat, and Cisco IP/TV with vat and vic (IP/TV never sends SR with report blocks, but does successfully receive them from vic/vat). 10. Interoperable exchange of receiver report packets. o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic. 11. Interoperable exchange of receiver report packets when not receiving data (ie: the empty receiver report which has to be sent first in each compound RTCP packet when no-participants are transmitting data). o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic. 12. Interoperable and correct choice of CNAME, according to the rules in the RTP specification and profile (applications using the audio/video profile [3] under IPv4 should typically generate a CNAME of the form `example@10.0.0.1', or `10.0.0.1' if they are on a machine which no concept of usernames). o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic. 13. Interoperable exchange of source description packets containing a CNAME item. o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic. 14. Interoperable exchange of source description packets containing a NAME item. o PASS: tested UCL rat with vat, Cisco IP/TV with vat/vic. 15. Interoperable exchange of source description packets containing an EMAIL item. o PASS: tested UCL rat with vat, Cisco IP/TV with vat/vic. 16. Interoperable exchange of source description packets containing a PHONE item. o PASS: Many implementations, tested UCL rat with vat, Cisco IP/TV with vat/vic. 17. Interoperable exchange of source description packets containing a LOC item. o PASS: tested UCL rat with vat, Cisco IP/TV with vat/vic. 18. Interoperable exchange of source description packets containing a TOOL item. o PASS: tested UCL rat with vat, Cisco IP/TV with vat/vic. 19. Interoperable exchange of source description packets containing a NOTE item. o PASS: tested UCL rat with vat, Cisco IP/TV with vat/vic. 20. Interoperable exchange of source description packets containing a PRIV item. o PASS: Magnus Westerlund has tested an implementation at Ericsson against rat. 21. Interoperable exchange of BYE packets containing a single SSRC. o PASS: tested UCL rat with vat, Cisco IP/TV with vat/vic. 22. Interoperable exchange of BYE packets containing multiple SSRCs. o PASS: tested Cisco IP/TV 3.0 server with rat 4.2.13 23. Interoperable exchange of BYE packets containing the optional reason for leaving text. o PASS: tested Cisco IP/TV sending to vat. Also the Lucent Elemedia rtplib generates and displays them. 24. Interoperable exchange of application defined RTCP packets. As with the RTP header extension this test takes two forms: if both implementations implement the same application defined packet it should be verified that those packets can be interoperably exchanged. If only one implementation uses application defined packets, it should be verified that the other implementation can receive compound RTCP packets containing an APP packet whilst ignoring the APP packet. If neither implementation implements APP packets this test is considered a failure. o PASS: Jori Liesenborgs tested jrtplib-2.4 vs UCL RTP library v1.2.2 25. Interoperable exchange of encrypted RTP packets using DES encryption in CBC mode. o PASS: tested rat with vat 26. Interoperable exchange of encrypted RTCP packets using DES encryption in CBC mode. o PASS (sort of) tested rat with vat (vat gets the padding wrong in some cases, but mostly it works). The features of the RTP specification relating to scalability are as follows ("PASS" means that the implementation has been shown to meet the criteria in RFC 3158): 1. Demonstrate correct implementation of basic RTCP transmission rules: periodic transmission of RTCP packets at the minimum (5 second) interval and randomisation of the transmission interval. o PASS: UCL rat, Cisco IP/TV 2. Demonstrate correct implementation of the RTCP step join backoff algorithm as a receiver. o PASS: UCL rat, Cisco rtplib 3. Demonstrate correct implementation of the RTCP step join backoff algorithm as a sender. o PASS: UCL rat, Cisco rtplib 4. Demonstrate correct steady state scaling of the RTCP interval acording to the group size. o PASS: UCL rat, Cisco IP/TV 5. Demonstrate correct steady state scaling of the RTCP interval acording to the group size with compensation for the number of senders. o PASS: UCL rat, Cisco IP/TV 6. Demonstrate correct implementation of the RTCP reverse reconsideration algorithm. o PASS: UCL rat, Magnus Westerlund reports that Ericsson have an implementation which is correct 7. Demonstrate correct implementation of the RTCP BYE reconsideration algorithm. o PASS: Demonstrated with rat (Colin Perkins) and an Ericsson implementation (Magnus Westerlund) 8. Demonstrate correct implementation of the RTCP member timeout algorithm. o PASS: IP/TV, vat, rat o PASS: Ericsson have an implementation (Magnus Westerlund) 9. Demonstrate random choice of SSRC. o PASS: rat, IP/TV, LiveCaster 10. Demonstrate random selection of initial RTP sequence number. o PASS: rat, LiveCaster 11. Demonstrate random selection of initial RTP timestamp. o PASS: rat, LiveCaster 12. Demonstrate correct implementation of the SSRC collision/loop detection algorithm. o PASS: IP/TV, vat 13. Demonstrate correct generation of reception report statistics in SR/RR packets. o PASS: rat, IP/TV 14. Demonstrate correct generation of the sender info block in SR packets. o PASS: rat, IP/TV The RTP specification enumerates a number of items that can be specified or modified by a profile. Those modified from the defaults by the audio/video profile are as follows: 1. Exchange of RTCP packets with the default RTCP reporting interval. o PASS: rat, IP/TV 2. Exchange of RTCP packets with a modified RTCP reporting interval as selected by a different fraction of the session bandwidth (the means by which this interval is signalled are outside of the scope of this memo, but one such mechanism should be demonstrated). o PASS: IP/TV, UCL rtplib 3. Implementations must send RTCP packets containing an SDES CNAME in every reporting interval. o PASS: rat, IP/TV 4. Other SDES items must be sent every third interval, with NAME every 7 of 8 times within that slot and any other SDES items cycically taking up the 8th slot. o PASS: rat, IP/TV 5. Interoperable selection of `pass phrase' for encryption and exchange of media using DES encryption. This must include mapping of the pass phrase to the canonical form. o FAIL: NeVoT does this, no other known implementations. This has been removed from the audio/video profile. 6. Interoperable transport of RTP via unicast UDP o PASS: rat, vat, vic, IP/TV 7. Interoperable transport of RTP via multicast UDP o PASS: rat, vat, vic, IP/TV 8. Interoperable transport of RTP via TCP using the encapsulation defined in the audio/video profile o FAIL: no known implementations. This has been removed from the audio/video profile. The primary purpose of the audio/video profile is to define the mapping from payload format to payload type number. Accordingly, the majority of the work needed to demonstrate interoperability consists of testing that media data is exchanged in an interoperable manner using the full range of codecs enumerated in the profile. The following audio codecs have static payload types: 1. The 8kHz PCMU codec (payload type 0) o PASS: rat, vat, fphone, IP/TV, Nuera. 2. The 8kHz 1016 codec (payload type 1) o FAIL: no known implementations. This has been removed from the audio/video profile. 3. The 8kHz G726-32 codec (payload type 2) o PASS: Magnus Westerlund tested rat with an Ericsson implementation 4. The 8kHz GSM codec (payload type 3) o PASS: rat, vat, fphone, IP/TV 5. The 8kHz G723 codec (payload type 4) o PASS: AudioCodes has performed Interoperability of its G.723.1 coder with Microsoft NetMeeting, Telogy (a TI company), VocalTec as well as several other companies (reported by Yehuda Herskovitz). o PASS: Also implementations by Nuera, Meridian 1 ITG, BCM and Matra 6500, Microsoft Netmeeting, Cisco. (Reported by Tom Taylor). o PASS: Nortel Meridian ITG with Acer, Arelnet, Cisco IOS gateway, CU-SeeMe (MCU and endpoint), Dataconnection (MCU and endpoint), Delta Information Systems, First Virtual Corporation, Intel Internet Phone, Avaya Definity, Lucent Alchemy, Microsoft Netmeeting, Radcom, Radvision L2W Gateway, Samsung Si, Sony Contact. 6. The 8kHz DVI4 codec (payload type 5) o PASS: rat, vat, fphone, IP/TV 7. The 16kHz DVI4 codec (payload type 6) o PASS: QuickTime vs rat (Dave Singer) 8. The 8kHz LPC codec (payload type 7) o PASS: rat, vat, fphone 9. The 8kHz PCMA codec (payload type 8) o PASS: Nuera with Lucent (reported by Maroula Bratakos) 10. The 8kHz G722 codec (payload type 9) o PASS: Accord have tested with Polycom, VCON and PictureTel. RealAudio have an implementation, also. 11. The 44.1kHz stereo L16 codec (payload type 10) o PASS: RealNetworks tested with QuickTime 12. The 44.1kHz mono L16 codec (payload type 11) o PASS: RealNetworks tested with QuickTime 13. The 8kHz QCELP codec (payload type 12) o PASS: RealNetworks tested with QuickTime 14. The 8kHz CN codec (payload type 13) o Reserved for a future payload format specification. 15. The MPA codec (payload type 14) o PASS: IP/TV, PixStream, Minerva, LiveCaster 16. The 8kHz G728 codec (payload type 15) o PASS: Accord have tested with Polycom, VCON and PictureTel. Nuera have an implementation, also. 17. The 11.025kHz DVI4 codec (payload type 16) o PASS: QuickTime tested with rat 18. The 22.050kHz DVI4 codec (payload type 17) o PASS: QuickTime tested with rat 19. The 8kHz G729 codec (payload type 18) o PASS: Nuera tested with Cisco, Nortel, VegaStream (SIP Bakeoff 5) The following audio codecs use dynamic payload types: 1. The GSM-HR codec o FAIL: Cisco have an implementation (Dinesh Nambisan ) but no other is known. This has been removed from the audio/video profile. 2. The GSM-EFR codec o PASS: Magnus Westerlund at Ericsson and Ari Lakaniemi at Nokia have tested their implementations. Implementations by Nuera (Maroula Bratakos ) and Cisco (Ling Niu) exist. 3. The L8 codec o PASS: RealNetworks tested with QuickTime 4. The RED codec o PASS: rat, fphone 5. The VDVI codec o PASS: rat, fphone The following video codecs have static payload type assignments: 1. The CellB codec (payload type 25) o PASS: JMF 2.1, vic 2.8-1.1.3 from UCL, Sun's ShowMeTV, nv 2. The JPEG codec (payload type 26) o PASS: ShowMeTV, Quicktime, vic. 3. The nv codec (payload type 28) o PASS: nv and vic (confirmed by Ron Frederick) 4. The H261 codec (payload type 31) o PASS: IP/TV, vic, VCON, Polycom 5. The MPV codec (payload type 32) o PASS: IP/TV, PixStream, Minerva 6. The MP2T codec (payload type 33) o PASS: Cisco have a pre-release implementation which receives from the Optibase Media GateWay 3100 v1.0 (Humphrey Liu ). Sun also have an implementation (Jonathan Sergent ) 7. The H263 codec (payload type 34) o PASS: PictureTel with Vtel, Polycom, etc. (Lulin Chen) The following audio codecs use dynamic payload types: 1. The BT656 codec o FAIL: Carsten Bormann has an implementation, no others known. This has been removed from the audio/video profile. 2. The H263-1998 codec o PASS: RealNetworks tested with QuickTime 3. The MP1S codec o FAIL: There is an implementation in Quicktime, but no others are known. This has been removed from the audio/video profile. 4. The MP2P codec o FAIL: There is an implementation in Quicktime, but no others are known. This has been removed from the audio/video profile. 5. The BMPEG codec o FAIL: No known implementations. This has been removed from the audio/video profile.