draft-ietf-avt-rtp-interop-06.txt | draft-ietf-avt-rtp-interop-07.txt | |||
---|---|---|---|---|
INTERNET-DRAFT 5 February 2001 | Colin Perkins | |||
USC/ISI | ||||
Colin Perkins | ||||
USC/ISI | ||||
RTP Interoperability Statement | RTP Interoperability Statement | |||
draft-ietf-avt-rtp-interop-06.txt | draft-ietf-avt-rtp-interop-07.txt | |||
Status of this memo | Status of this memo | |||
This document is an Internet-Draft and is in full conformance with | This document is an Internet-Draft and is in full conformance with all | |||
all provisions of Section 10 of RFC2026. | provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering Task | |||
Task Force (IETF), its areas, and its working groups. Note that | Force (IETF), its areas, and its working groups. Note that other groups | |||
other groups may also distribute working documents as Internet-Drafts. | may also distribute working documents as Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months and | |||
and may be updated, replaced, or obsoleted by other documents at | may be updated, replaced, or obsoleted by other documents at any time. It | |||
any time. It is inappropriate to use Internet-Drafts as reference | is inappropriate to use Internet-Drafts as reference material or to cite | |||
material or to cite them other than as work in progress. | them other than as work in progress. | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Distribution of this document is unlimited. | Distribution of this document is unlimited. | |||
Comments are solicited and should be addressed to the author and/or the | Comments are solicited and should be addressed to the author and/or the | |||
IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. | IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. | |||
Abstract | Abstract | |||
It is required to demonstrate interoperability of RTP implementations | It is required to demonstrate interoperability of RTP implementations | |||
in order to move the RTP specification to draft standard. This memo | in order to move the RTP specification to draft standard. This memo | |||
outlines those features to be tested, as the first stage of an | outlines those features to be tested, as the first stage of an | |||
interoperability statement. | interoperability statement. | |||
1 Introduction | 1 Introduction | |||
The Internet standards process [1] places a number of requirements | The Internet standards process [1] places a number of requirements | |||
on a standards track protocol specification. In particular, when | on a standards track protocol specification. In particular, when | |||
advancing a protocol from proposed standard to draft standard it | advancing a protocol from proposed standard to draft standard it | |||
is necessary to demonstrate at least two independent and interoperable | is necessary to demonstrate at least two independent and interoperable | |||
implementations, from different code bases, of all options and features | implementations, from different code bases, of all options and features | |||
of that protocol. Further, in cases where one or more options or | of that protocol. Further, in cases where one or more options or | |||
features have not been demonstrated in at least two interoperable | features have not been demonstrated in at least two interoperable | |||
implementations, the specification may advance to the draft standard | implementations, the specification may advance to the draft standard | |||
level only if those options or features are removed. The Real-time | level only if those options or features are removed. The Real-time | |||
Transport Protocol, RTP, was originally specified in RFC1889 as a | Transport Protocol, RTP, was originally specified in RFC1889 as a | |||
proposed standard [2]. The revision of this specification for draft | proposed standard [2]. The revision of this specification for draft | |||
standard status is now well underway, so it has become necessary | standard status is now well underway, so it has become necessary | |||
to conduct such an interoperability demonstration. | to conduct such an interoperability demonstration. | |||
This memo describes the set of features and options of the RTP specification | This memo 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 | 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 | nature of RTP there are necessarily two types of test described: those | |||
which directly affect the interoperability of implementations at a ``bits | which directly affect the interoperability of implementations at a ``bits | |||
on the wire level'' and those which affect scalability and safety of the | on the wire level'' and those which affect scalability and safety of the | |||
protocol but do not directly affect interoperability. A related memo [4] | protocol but do not directly affect interoperability. A related memo [4] | |||
describes a testing framework which may aid with interoperability testing. | describes a testing framework which may aid with interoperability testing. | |||
This memo is for information only and does not specify a standard | This memo is for information only and does not specify a standard | |||
of any kind. | of any kind. | |||
2 Features and options required to demonstrate interoperability | 2 Features and options required to demonstrate interoperability | |||
In order to demonstrate interoperability it is required to produce | In order to demonstrate interoperability it is required to produce | |||
a statement of interoperability for each feature noted below. Such | a statement of interoperability for each feature noted below. Such | |||
a statement should note the pair of implementations tested, including | a statement should note the pair of implementations tested, including | |||
version numbers, and a pass/fail statement for each feature. It | version numbers, and a pass/fail statement for each feature. It | |||
is not expected that every implementation will implement every feature, | is not expected that every implementation will implement every feature, | |||
but each feature needs to be demonstrated by some pair of applications. | but each feature needs to be demonstrated by some pair of applications. | |||
Note that some of these tests depend on the particular profile used, | Note that some of these tests depend on the particular profile used, | |||
or upon options in that profile. For example, it will be necessary | or upon options in that profile. For example, it will be necessary | |||
to test audio and video applications operating under [3] separately. | to test audio and video applications operating under [3] separately. | |||
1. Interoperable exchange of data packets using the basic RTP header | 1. Interoperable exchange of data packets using the basic RTP header | |||
with no header extension, padding or CSRC list. | with no header extension, padding or CSRC list. | |||
o PASS: rat vs vat | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
2. Interoperable exchange of data packets which use padding. | o PASS: IP/TV vs vat/vic | |||
o PASS: IP/TV vs rat | 2. Interoperable exchange of data packets which use padding. | |||
3. Interoperable exchange of data packets which use a header extension. | o PASS: IP/TV vs rat | |||
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: jrtplib-2.4 vs UCL RTP library v1.2.2 | 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. | ||||
4. Interoperable exchange of data packets using the marker bit as | o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2 | |||
specified in the profile. | ||||
o PASS: rat vs vat | 4. Interoperable exchange of data packets using the marker bit as | |||
specified in the profile. | ||||
o PASS: IP/TV vs vic | o PASS: rat vs vat | |||
5. Interoperable exchange of data packets using the payload type | o PASS: IP/TV vs vic | |||
field to differentiate multiple payload formats according to | ||||
a profile definition. | ||||
o PASS: rat vs vat | 5. Interoperable exchange of data packets using the payload type | |||
field to differentiate multiple payload formats according to | ||||
a profile definition. | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
6. Interoperable exchange of data packets containing a CSRC list. | o PASS: IP/TV vs vat/vic | |||
o PASS: rat vs vat | 6. Interoperable exchange of data packets containing a CSRC list. | |||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
7. Interoperable exchange of RTCP packets, which must be compound | o PASS: IP/TV vs vat/vic | |||
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: rat vs vat | 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: IP/TV vs vat/vic | o PASS: rat vs vat | |||
8. Interoperable exchange of sender report packets when the receiver | o PASS: IP/TV vs vat/vic | |||
of the sender reports is not also a sender (ie: sender reports | ||||
which only contain sender info, with no report blocks). | ||||
o PASS: rat vs vat | 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: IP/TV vs vat/vic | o PASS: rat vs vat | |||
9. Interoperable exchange of sender report packets when the receiver | o PASS: IP/TV vs vat/vic | |||
of the sender reports is also a sender (ie: sender reports | ||||
which contain one or more report blocks). | ||||
o PASS: rat vs vat | 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: IP/TV vs vat/vic (IP/TV never sends SR with report | o PASS: rat vs vat | |||
blocks, but does successfully receive them from vic/vat). | ||||
10. Interoperable exchange of receiver report packets. | o PASS: IP/TV vs vat/vic (IP/TV never sends SR with report | |||
blocks, but does successfully receive them from vic/vat). | ||||
o PASS: rat vs vat | 10. Interoperable exchange of receiver report packets. | |||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
11. Interoperable exchange of receiver report packets when not receiving | o PASS: IP/TV vs vat/vic | |||
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: rat vs vat | 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: IP/TV vs vat/vic | o PASS: rat vs vat | |||
12. Interoperable and correct choice of CNAME, according to the rules | o PASS: IP/TV vs vat/vic | |||
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: rat vs vat | 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: IP/TV vs vat/vic | o PASS: rat vs vat | |||
13. Interoperable exchange of source description packets containing | o PASS: IP/TV vs vat/vic | |||
a CNAME item. | ||||
o PASS: rat vs vat | 13. Interoperable exchange of source description packets containing | |||
a CNAME item. | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
14. Interoperable exchange of source description packets containing | o PASS: IP/TV vs vat/vic | |||
a NAME item. | ||||
o PASS: rat vs vat | 14. Interoperable exchange of source description packets containing | |||
a NAME item. | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
15. Interoperable exchange of source description packets containing | o PASS: IP/TV vs vat/vic | |||
an EMAIL item. | ||||
o PASS: rat vs vat | 15. Interoperable exchange of source description packets containing | |||
an EMAIL item. | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
16. Interoperable exchange of source description packets containing | o PASS: IP/TV vs vat/vic | |||
a PHONE item. | ||||
o PASS: rat vs vat | 16. Interoperable exchange of source description packets containing | |||
a PHONE item. | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
17. Interoperable exchange of source description packets containing | o PASS: IP/TV vs vat/vic | |||
a LOC item. | ||||
o PASS: rat vs vat | 17. Interoperable exchange of source description packets containing | |||
a LOC item. | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
18. Interoperable exchange of source description packets containing | o PASS: IP/TV vs vat/vic | |||
a TOOL item. | ||||
o PASS: rat vs vat | 18. Interoperable exchange of source description packets containing | |||
a TOOL item. | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
19. Interoperable exchange of source description packets containing | o PASS: IP/TV vs vat/vic | |||
a NOTE item. | ||||
o PASS: rat vs vat | 19. Interoperable exchange of source description packets containing | |||
a NOTE item. | ||||
o PASS: IP/TV vs vat/vic | o PASS: rat vs vat | |||
20. Interoperable exchange of source description packets containing | o PASS: IP/TV vs vat/vic | |||
a PRIV item. | ||||
o FAIL: need to test rtplib against rtpdump? | 20. Interoperable exchange of source description packets containing | |||
a PRIV item. | ||||
21. Interoperable exchange of BYE packets containing a single SSRC. | o FAIL: need to test rtplib against rtpdump? | |||
o PASS: rat vs vat | o FAIL: Ericsson have an implementation, Magnus Westerlund | |||
will test against rat. | ||||
o PASS: IP/TV vs vat/vic | 21. Interoperable exchange of BYE packets containing a single SSRC. | |||
22. Interoperable exchange of BYE packets containing multiple SSRCs. | o PASS: rat vs vat | |||
o FAIL: rat can send these, but vat only accepts the first | o PASS: IP/TV vs vat/vic | |||
SSRC | ||||
o FAIL: IP/TV sends only one SSRC in BYE, but should accept | 22. Interoperable exchange of BYE packets containing multiple SSRCs. | |||
multiple | ||||
o FAIL: need to test rat-3.0.x against rtplib | o FAIL: rat can send these, but vat only accepts the first | |||
SSRC | ||||
23. Interoperable exchange of BYE packets containing the optional | o FAIL: IP/TV sends only one SSRC in BYE, but should accept | |||
reason for leaving text. | multiple | |||
o PASS: tested IP/TV sending to vat. Also rtplib generates | o FAIL: need to test rat-3.0.x against rtplib | |||
and displays them. | ||||
24. Interoperable exchange of BYE packets containing the optional | 23. Interoperable exchange of BYE packets containing the optional | |||
reason for leaving text and multiple SSRCs. | reason for leaving text. | |||
o FAIL: does anyone implement both? | o PASS: tested IP/TV sending to vat. Also rtplib generates | |||
and displays them. | ||||
25. Interoperable exchange of application defined RTCP packets. As | 24. Interoperable exchange of application defined RTCP packets. As | |||
with the RTP header extension this test takes two forms: if | with the RTP header extension this test takes two forms: if | |||
both implementations implement the same application defined packet | both implementations implement the same application defined packet | |||
it should be verified that those packets can be interoperably | it should be verified that those packets can be interoperably | |||
exchanged. If only one implementation uses application defined | exchanged. If only one implementation uses application defined | |||
packets, it should be verified that the other implementation | packets, it should be verified that the other implementation | |||
can receive compound RTCP packets containing an APP packet whilst | can receive compound RTCP packets containing an APP packet whilst | |||
ignoring the APP packet. If neither implementation implements | ignoring the APP packet. If neither implementation implements | |||
APP packets this test is considered a failure. | APP packets this test is considered a failure. | |||
o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2 | o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2 | |||
26. Interoperable exchange of encrypted RTP packets using DES encryption | 25. Interoperable exchange of encrypted RTP packets using DES encryption | |||
in CBC mode. | in CBC mode. | |||
o PASS: rat vs vat | o PASS: rat vs vat | |||
27. Interoperable exchange of encrypted RTCP packets using DES encryption | 26. Interoperable exchange of encrypted RTCP packets using DES encryption | |||
in CBC mode. | in CBC mode. | |||
o PASS (sort of): rat vs vat (vat gets the padding wrong | o PASS (sort of): rat vs vat (vat gets the padding wrong | |||
in some cases, but mostly it works). | in some cases, but mostly it works). | |||
28. Interoperable exchange of encrypted RTCP packets using DES encryption | 3 Features and options relating to scalability | |||
in CBC mode, when those compound RTCP packets have been split | ||||
into an encrypted packet and an unencrypted packet. | ||||
o FAIL: not tested (rtplib supports this?) | 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. | ||||
3 Features and options relating to scalability | 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. | ||||
In addition to the basic interoperability tests, RTP includes a number | o PASS: rat, IP/TV | |||
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. | ||||
1. Demonstrate correct implementation of basic RTCP transmission | 2. Demonstrate correct implementation of the RTCP step join backoff | |||
rules: periodic transmission of RTCP packets at the minimum | algorithm as a receiver. | |||
(5 second) interval and randomisation of the transmission interval. | ||||
o PASS: rat, IP/TV | o PASS: rat, rtplib | |||
2. Demonstrate correct implementation of the RTCP step join backoff | 3. Demonstrate correct implementation of the RTCP step join backoff | |||
algorithm as a receiver. | algorithm as a sender. | |||
o PASS: rat, rtplib | o PASS: rat, rtplib | |||
3. Demonstrate correct implementation of the RTCP step join backoff | 4. Demonstrate correct steady state scaling of the RTCP interval | |||
algorithm as a sender. | acording to the group size. | |||
o PASS: rat, rtplib | o PASS: rat, IP/TV | |||
4. Demonstrate correct steady state scaling of the RTCP interval | 5. Demonstrate correct steady state scaling of the RTCP interval | |||
acording to the group size. | acording to the group size with compensation for the number of | |||
senders. | ||||
o PASS: rat, IP/TV | o PASS: rat, IP/TV | |||
5. Demonstrate correct steady state scaling of the RTCP interval | 6. Demonstrate correct implementation of the RTCP reverse reconsideration | |||
acording to the group size with compensation for the number of | algorithm. | |||
senders. | ||||
o PASS: rat, IP/TV | o FAIL: rat is correct, | |||
6. Demonstrate correct implementation of the RTCP reverse reconsideration | o FAIL: Ericsson have an implementation: Magnus Westerlund | |||
algorithm. | is testing... | |||
o FAIL: rat is correct, need another implementation | 7. Demonstrate correct implementation of the RTCP BYE reconsideration | |||
algorithm. | ||||
7. Demonstrate correct implementation of the RTCP BYE reconsideration | o FAIL: Ericsson have an implementation: Magnus Westerlund | |||
algorithm. | is testing... | |||
o FAIL | 8. Demonstrate correct implementation of the RTCP member timeout | |||
algorithm. | ||||
8. Demonstrate correct implementation of the RTCP member timeout | o PASS: IP/TV, vat, rat | |||
algorithm. | ||||
o FAIL | o FAIL: Ericsson have an implementation: Magnus Westerlund | |||
is testing... | ||||
9. Demonstrate random choice of SSRC. | 9. Demonstrate random choice of SSRC. | |||
o PASS: rat, IP/TV, LiveCaster | o PASS: rat, IP/TV, LiveCaster | |||
10. Demonstrate random selection of initial RTP sequence number. | 10. Demonstrate random selection of initial RTP sequence number. | |||
o PASS: rat, LiveCaster | o PASS: rat, LiveCaster | |||
11. Demonstrate random selection of initial RTP timestamp. | 11. Demonstrate random selection of initial RTP timestamp. | |||
o PASS: rat, LiveCaster | o PASS: rat, LiveCaster | |||
12. Demonstrate correct implementation of the SSRC collision/loop | 12. Demonstrate correct implementation of the SSRC collision/loop | |||
detection algorithm. | detection algorithm. | |||
o PASS: IP/TV, vat | o PASS: IP/TV, vat | |||
13. Demonstrate correct generation of reception report statistics | 13. Demonstrate correct generation of reception report statistics | |||
in SR/RR packets. | in SR/RR packets. | |||
o PASS: rat, IP/TV | o PASS: rat, IP/TV | |||
14. Demonstrate correct generation of the sender info block in SR | 14. Demonstrate correct generation of the sender info block in SR | |||
packets. | packets. | |||
o PASS: rat, IP/TV | o PASS: rat, IP/TV | |||
4 Author's Address | 4 Author's Address | |||
Colin Perkins | Colin Perkins | |||
USC Information Sciences Institute | USC Information Sciences Institute | |||
4350 North Fairfax Drive | 4350 North Fairfax Drive | |||
Suite 620 | Suite 620 | |||
Arlington, VA 22203 | Arlington, VA 22203 | |||
USA | USA | |||
Email: csp@isi.edu | Email: csp@isi.edu | |||
5 Acknowledgments | ||||
Thanks to Steve Casner, Jonathan Rosenberg and Bill Fenner for their | ||||
helpful feedback. | ||||
6 References | 5 References | |||
[1] S. Bradner, ``The Internet Standards Process -- Revision 3'', | [1] S. Bradner, ``The Internet Standards Process -- Revision 3'', | |||
RFC2026, Internet Engineering Task Force, October 1996. | RFC2026, Internet Engineering Task Force, October 1996. | |||
[2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: | [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: A | |||
A Transport Protocol to Real-Time Applications'', RFC1889, Internet | Transport Protocol to Real-Time Applications'', RFC1889, Internet | |||
Engineering Task Force, January 1996. | Engineering Task Force, January 1996. | |||
[3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with | [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with | |||
Minimal Control'', draft-ietf-avt-profile-new-08.txt, January 2000. | Minimal Control'', draft-ietf-avt-profile-new-08.txt, January 2000. | |||
[4] C. S. Perkins, J. Rosenberg and H. Schulzrinne, ``RTP Testing | [4] C. S. Perkins, J. Rosenberg and H. Schulzrinne, ``RTP Testing | |||
Strategies'', draft-ietf-avt-rtptest-04.txt, November 2000. | Strategies'', draft-ietf-avt-rtptest-04.txt, November 2000. | |||
End of changes. 128 change blocks. | ||||
221 lines changed or deleted | 213 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |