RTP Interoperability Statements

The Internet standards process places a number of requirements on a standards track protocol specification. In particular, when advancing a protocol from proposed standard to draft standard it is necessary to demonstrate at least two independent and interoperable implementations, from different code bases, of all options and features of that protocol. Further, in cases where one or more options or features have not been demonstrated in at least two interoperable implementations, the specification may advance to the draft standard level only if those options or features are removed. The Real-time Transport Protocol, RTP, was originally specified in RFC1889. The revision of this specification for draft standard status is now well underway, so it has become necessary to conduct such an interoperability demonstration.

This page describes the set of features and options of the RTP specification which need to be tested as a basis for this demonstration. Due to the nature of RTP there are necessarily two types of test described: 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.

The RTP specification and audio/video profile cannot advance to draft standard until there are at least two pass (green) entries in each row of the following tables.

Features and options required to demonstrate interoperability

In order to demonstrate interoperability it is required to produce a statement of interoperability for each feature noted below. Such a statement should note the pair of implementations tested, including version numbers, and a pass/fail statement for each feature. It is not expected that every implementation will implement every feature, but each feature needs to be demonstrated by some pair of applications. Note that some of these tests depend on the particular profile used, or upon options in that profile. For example, it will be necessary to test audio and video applications separately.

Feature rat-3.0.33 vs vat-4.0b2/yaat IP/TV v3.0 vs vat v4.0b2, vic v2.8, rat
Interoperable exchange of data packets using the basic RTP header with no header extension, padding or CSRC list. pass pass
Interoperable exchange of data packets which use padding. fail (neither generates packets with padding) fail (generates padding, but vat/vic don't remove RTCP padding correctly)
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. fail (neither implements header extension) fail (neither implements header extension, but IP/TV does have code to ignore it and to verify that the length is valid if present)
Interoperable exchange of data packets using the marker bit as specified in the profile. pass pass (IP/TV does not set marker bit for audio because it does not suppress silence, but it does properly process audio that is silence suppressed using the marker bit)
Interoperable exchange of data packets using the payload type field to differentiate multiple payload formats according to a profile definition. pass pass
Interoperable exchange of data packets containing a CSRC list. pass pass
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. pass pass
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). pass pass
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). pass pass (IP/TV never sends SR with report blocks, but does successfully receive them from vat/vic)
Interoperable exchange of receiver report packets. pass pass
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). pass pass
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). pass pass
Interoperable exchange of source description packets containing a CNAME item. pass pass
Interoperable exchange of source description packets containing a NAME item. pass pass
Interoperable exchange of source description packets containing an EMAIL item. pass pass
Interoperable exchange of source description packets containing a PHONE item. pass pass
Interoperable exchange of source description packets containing a LOC item. pass pass
Interoperable exchange of source description packets containing a TOOL item. pass pass
Interoperable exchange of source description packets containing a NOTE item. pass pass
Interoperable exchange of source description packets containing a PRIV item. fail (neither implements PRIV) fail (neither implements PRIV)
Interoperable exchange of BYE packets containing a single SSRC. pass pass
Interoperable exchange of BYE packets containing multiple SSRCs. fail (vat accepts the first ssrc only) fail (IP/TV sends only one SSRC in BYE, but should accept multiple)
Interoperable exchange of BYE packets containing the optional reason for leaving text. fail (neither send the optional reason for leaving) fail (neither send the optional reason for leaving)
Interoperable exchange of BYE packets containing the optional reason for leaving text and multiple SSRCs. fail (neither send the optional reason for leaving) fail (neither send the optional reason for leaving)
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. fail (neither implements application defined RTCP) fail (IP/TV MSOCK API implements sending and receiving of APP packets, but have not tested with any other implementation)
Interoperable exchange of encrypted RTP packets using DES encryption in CBC mode. pass fail (DES CBC not implemented)
Interoperable exchange of encrypted RTCP packets using DES encryption in CBC mode. pass (vat gets the padding wrong in some cases, but it mostly works) fail (DES CBC not implemented)

Features and options relating to scalability

In addition to the basic interoperability tests, RTP includes a number of features relating to scaling of the protocol to large groups. Since these features are those which have undergone the greatest change in the update of the RTP specification, it is considered important to demonstrate their correct implementation. However, since these changes do not affect the bits-on-the-wire behaviour of the protocol, it is not possible to perform a traditional interoperability test. As an alternative to such testing we require that multiple independent implementations complete the following demonstrations.

Feature rat-3.0.33 IP/TV v3.0 LiveCaster v1.0a41
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. not tested pass not tested
Demonstrate correct implementation of the RTCP step join backoff algorithm as a receiver. not tested fail (not implemented) not tested
Demonstrate correct implementation of the RTCP step join backoff algorithm as a sender. not tested fail (not implemented) not tested
Demonstrate correct steady state scaling of the RTCP interval acording to the group size. not tested pass (recently tested thoroughly in QA of IP/TV 3.0 release) not tested
Demonstrate correct steady state scaling of the RTCP interval acording to the group size with compensation for the number of senders. not tested pass (recently tested thoroughly in QA of IP/TV 3.0 release) not tested
Demonstrate correct implementation of the RTCP reverse reconsideration algorithm. not tested fail (not implemented) not tested
Demonstrate correct implementation of the RTCP BYE reconsideration algorithm. not tested fail (not implemented) not tested
Demonstrate correct implementation of the RTCP member timeout algorithm. not tested maybe (implemented but not tested carefully) not tested
Demonstrate random choice of SSRC. not tested pass pass
Demonstrate random selection of initial RTP sequence number. not tested maybe (not sure about initial random sequence number) pass
Demonstrate random selection of initial RTP timestamp. not tested maybe (not sure about initial random timestamp in all encodings) pass
Demonstrate correct implementation of the SSRC collision/loop detection algorithm. not tested pass (tested with vat) not tested
Demonstrate correct generation of reception report statistics in SR/RR packets. not tested pass not tested
Demonstrate correct generation of the sender info block in SR packets. not tested pass (depend on correct SR packet for synchronization) not tested

Features relating to the audio/video profile

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, and interoperable behaviour must be demonstrated:

Feature rat-4.1.1 IP/TV v3.0
Exchange of RTCP packets with the default RTCP reporting interval. pass pass
Exchange of RTCP packets with a modified RTCP reporting interval as selected by a different fraction of the session bandwidth. fail (not implemented) pass (implemented setting RTCP receive bw to zero)
Implementations must send RTCP packets containing an SDES CNAME in every reporting interval. pass pass
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. pass pass
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. fail (don't correctly map to canonical form) fail (not implemented)
Interoperable transport of RTP via unicast UDP pass pass
Interoperable transport of RTP via multicast UDP pass pass
Interoperable transport of RTP via TCP using the encapsulation defined in section 7 the audio/video profile fail (not implemented) fail (not implemented)

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 codecs are assigned static payload types. It should be verified that interoperable implementations exist for each static payload type:

Feature rat-4.1.1 IP/TV v3.0 LiveCaster v1.0a41
The 8kHz PCMU codec (payload type 0) pass (tested with vat, fphone, yaat) pass fail (not implemented)
The 8kHz 1016 codec (payload type 1) fail (not implemented) fail (not implemented) fail (not implemented)
The 8kHz G726-32 codec (payload type 2) implemented, but not tested with anyone else fail (not implemented) fail (not implemented)
The 8kHz GSM codec (payload type 3) pass (tested with vat, fphone) pass fail (not implemented)
The 8kHz G723 codec (payload type 4) fail (not implemented) fail (not implemented) fail (not implemented)
The 8kHz DVI4 codec (payload type 5) pass (tested with vat, fphone, yaat) pass fail (not implemented)
The 16kHz DVI4 codec (payload type 6) implemented, but not tested with anyone else fail (might work, never tried) fail (not implemented)
The 8kHz LPC codec (payload type 7) pass (tested with vat, fphone, yaat) fail (not implemented) fail (not implemented)
The 8kHz PCMA codec (payload type 8) implemented, but not tested with anyone else fail (not implemented) fail (not implemented)
The 8kHz G722 codec (payload type 9) fail (not implemented) fail (not implemented) fail (not implemented)
The 44.1kHz stereo L16 codec (payload type 10) implemented but not tested with anyone else implemented but not tested with anyone else fail (not implemented)
The 44.1kHz mono L16 codec (payload type 11) implemented but not tested with anyone else implemented but not tested with anyone else fail (not implemented)
The 8kHz QCELP codec (payload type 12) fail (not implemented) fail (not implemented) fail (not implemented)
The 8kHz CN codec (payload type 13) fail (not implemented) fail (not implemented) fail (not implemented)
The MPA codec (payload type 14) fail (not implemented) pass (tested with PixStream and Minerva) pass (tested with IP/TV)
The 8kHz G728 codec (payload type 15) fail (not implemented) fail (not implemented) fail (not implemented)
The 11.025kHz DVI4 codec (payload type 16) implemented, but not tested with anyone else fail (might work, never tried) fail (not implemented)
The 22.050kHz DVI4 codec (payload type 17) implemented, but not tested with anyone else fail (might work, never tried) fail (not implemented)
The 8kHz G729 codec (payload type 18) fail (not implemented) fail (not implemented) fail (not implemented)

The following codecs use dynamic payload types. It should be verified that some non-RTP means can be used to assign a dynamic payload type to be used by implementations, and that those implementations can then interwork.

Feature rat-4.1.1 IP/TV v3.0
The GSM-HR codec fail (not implemented) fail (not implemented)
The GSM-EFR codec fail (not implemented) fail (not implemented)
The L8 codec implemented but not tested with anyone else implemented but not tested with anyone else
The RED codec pass (tested with fphone) pass sort of (just play primary encoding)
The VDVI codec pass (tested with fphone) fail (not implemented)

Similarly, interoperable implementation of the following video codecs with static payload type numbers must be demonstrated:

Feature IP/TV v3.0
The CelB codec (payload type 25) fail (not implemented)
The JPEG codec (payload type 26) fail (not implemented)
The nv codec (payload type 28) fail (not implemented)
The H261 codec (payload type 31) pass (tested with vic, VCON, Polycom)
The MPV codec (payload type 32) pass (tested with PixStream, Minerva)
The MP2T codec (payload type 33) fail (not implemented)
The H263 codec (payload type 34) fail (not implemented)

The following codecs use dynamic payload types. It should be verified that some non-RTP means can be used to assign a dynamic payload type to be used by implementations, and that those implementations can then interwork.

Feature IP/TV v3.0
The BT656 codec fail (not implemented)
The H263-1998 codec fail (not implemented)
The MP1S codec fail (not implemented)
The MP2P codec fail (not implemented)
The BMPEG codec fail (not implemented)

This page is hosted by the UCL Networked Multimedia Research Group.