draft-ietf-avt-rtp-interop-01.txt | draft-ietf-avt-rtp-interop-02.txt | |||
---|---|---|---|---|
INTERNET-DRAFT 15 August 1999 | INTERNET-DRAFT 21 October 1999 | |||
Colin Perkins | ||||
University College London | ||||
RTP Interoperability Statement | Colin Perkins | |||
University College London | ||||
draft-ietf-avt-rtp-interop-01.txt | RTP Interoperability Statement | |||
draft-ietf-avt-rtp-interop-02.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 provisions of Section 10 of RFC2026. | all 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 Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that | |||
groups may also distribute working documents as Internet-Drafts. | other groups may also distribute working documents as Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months and | Internet-Drafts are draft documents valid for a maximum of six months and | |||
may be updated, replaced, or obsoleted by other documents at any time. It | may be updated, replaced, or obsoleted by other documents at any time. It | |||
is inappropriate to use Internet-Drafts as reference material or to cite | is inappropriate to use Internet-Drafts as reference 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 | Comments are solicited and should be addressed to the author and/or the | |||
the IETF Audio/Video Transport working group's mailing list at | IETF Audio/Video Transport working group's mailing list at rem-conf@es.net. | |||
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 | |||
Perkins Page 1 | ||||
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 well underway, so it has become necessary to conduct | standard status is now well underway, so it has become necessary | |||
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, and a | a statement should note the pair of implementations tested, including | |||
pass/fail statement for each feature. It is not expected that every | version numbers, and a pass/fail statement for each feature. It | |||
implementation will implement every feature, but each feature needs | is not expected that every implementation will implement every feature, | |||
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 extension, padding or CSRC list. | with no header extension, padding or CSRC list. | |||
2. Interoperable exchange of data packets which use padding | 2.Interoperable exchange of data packets which use padding. | |||
3. Interoperable exchange of data packets which use a header extension. | 3.Interoperable exchange of data packets which use a header extension. | |||
There are three possibilities here: a) if both implementations | There are three possibilities here: a) if both implementations | |||
use a header extension in the same manner, it should be verified | use a header extension in the same manner, it should be verified | |||
that the receiver correctly receives the information contained | that the receiver correctly receives the information contained | |||
in the extension header; b) If the sender uses a header extension | in the extension header; b) If the sender uses a header extension | |||
and the receiver does not, it should be verified that the receiver | and the receiver does not, it should be verified that the receiver | |||
ignores the extension; c) If neither implementation implements | ignores the extension; c) If neither implementation implements | |||
an extended header, this test is considered a failure. | an extended header, this test is considered a failure. | |||
4. Interoperable exchange of data packets using the marker bit as | 4.Interoperable exchange of data packets using the marker bit as | |||
specified in the profile. | specified in the profile. | |||
Perkins Page 2 | 5.Interoperable exchange of data packets using the payload type | |||
5. Interoperable exchange of data packets using the payload type | field to differentiate multiple payload formats according to | |||
field to differentiate multiple payload formats according to | a profile definition. | |||
a profile definition. | ||||
6. Interoperable exchange of data packets containing a CSRC list | 6.Interoperable exchange of data packets containing a CSRC list. | |||
7. Interoperable exchange of RTCP packets, which must be compound | 7.Interoperable exchange of RTCP packets, which must be compound | |||
packets containing at least an initial SR or RR packet and an | packets containing at least an initial SR or RR packet and an | |||
SDES CNAME packet. | SDES CNAME packet. Other RTCP packet types may be included, | |||
but this is not required for this test. | ||||
8. Interoperable exchange of sender report packets when the receiver | 8.Interoperable exchange of sender report packets when the receiver | |||
of the sender reports is not also a sender (ie: sender reports | of the sender reports is not also a sender (ie: sender reports | |||
which only contain sender info, with no report blocks). | which only contain sender info, with no report blocks). | |||
9. Interoperable exchange of sender report packets when the receiver | 9.Interoperable exchange of sender report packets when the receiver | |||
of the sender reports is also a sender (ie: sender reports | of the sender reports is also a sender (ie: sender reports which | |||
which contain one or more report blocks). | contain one or more report blocks). | |||
10. Interoperable exchange of receiver report packets. | 10.Interoperable exchange of receiver report packets. | |||
11. Interoperable exchange of receiver report packets when not receiving | 11.Interoperable exchange of receiver report packets when not receiving | |||
data (ie: the empty receiver report which has to be sent first in each | data (ie: the empty receiver report which has to be sent first | |||
compound RTCP packet when no-participants are transmitting data). | in each compound RTCP packet when no-participants are transmitting | |||
data). | ||||
12. Interoperable choice of CNAME, according to the rules in the RTP | 12.Interoperable and correct choice of CNAME, according to the rules | |||
specification and profile. | 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). | ||||
13. Interoperable exchange of source description packets containing | 13.Interoperable exchange of source description packets containing | |||
a CNAME item. | a CNAME item. | |||
14. Interoperable exchange of source description packets containing | 14.Interoperable exchange of source description packets containing | |||
a NAME item. | a NAME item. | |||
15. Interoperable exchange of source description packets containing | 15.Interoperable exchange of source description packets containing | |||
an EMAIL item. | an EMAIL item. | |||
16. Interoperable exchange of source description packets containing | 16.Interoperable exchange of source description packets containing | |||
a PHONE item. | a PHONE item. | |||
17. Interoperable exchange of source description packets containing | 17.Interoperable exchange of source description packets containing | |||
a LOC item. | a LOC item. | |||
18. Interoperable exchange of source description packets containing | 18.Interoperable exchange of source description packets containing | |||
a TOOL item. | a TOOL item. | |||
19. Interoperable exchange of source description packets containing | 19.Interoperable exchange of source description packets containing | |||
a NOTE item. | a NOTE item. | |||
20. Interoperable exchange of source description packets containing | 20.Interoperable exchange of source description packets containing | |||
a PRIV item. | a PRIV item. | |||
21. Interoperable exchange of BYE packets. | 21.Interoperable exchange of BYE packets containing a single SSRC. | |||
22. Interoperable exchange of BYE packets containing multiple SSRCs. | 22.Interoperable exchange of BYE packets containing multiple SSRCs. | |||
Perkins Page 3 | 23.Interoperable exchange of BYE packets containing the optional | |||
23. Interoperable exchange of BYE packets containing the optional | reason for leaving text. | |||
reason for leaving text. | ||||
24. Interoperable exchange of application defined RTCP packets. As | 24.Interoperable exchange of BYE packets containing the optional | |||
with the RTP header extension this test takes two forms: if | reason for leaving text and multiple SSRCs. | |||
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. | ||||
25. Interoperable exchange of encrypted RTP packets using DES encryption | 25.Interoperable exchange of application defined RTCP packets. As | |||
in CBC mode. | 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. | ||||
26. Interoperable exchange of encrypted RTCP packets using DES encryption | 26.Interoperable exchange of encrypted RTP packets using DES encryption | |||
in CBC mode. | in CBC mode. | |||
27.Interoperable exchange of encrypted RTCP packets using DES encryption | ||||
in CBC mode. | ||||
3 Features and options relating to scalability | 3 Features and options relating to scalability | |||
In addition to the basic interoperability tests, RTP includes a number of | In addition to the basic interoperability tests, RTP includes a number | |||
features relating to scaling of the protocol to large groups. Since these | of features relating to scaling of the protocol to large groups. | |||
features are those which have undergone the greatest change in the update | Since these features are those which have undergone the greatest | |||
of the RTP specification, it is considered important to demonstrate their | change in the update of the RTP specification, it is considered important | |||
correct implementation. However, since these changes do not affect the | to demonstrate their correct implementation. However, since these | |||
bits-on-the-wire behaviour of the protocol, it is not possible to perform a | changes do not affect the bits-on-the-wire behaviour of the protocol, | |||
traditional interoperability test. As an alternative to such testing we | it is not possible to perform a traditional interoperability test. | |||
require that multiple independent implementations complete the following | As an alternative to such testing we require that multiple independent | |||
demonstrations. | implementations complete the following demonstrations. | |||
1. Demonstrate correct implementation of basic RTCP transmission | 1.Demonstrate correct implementation of basic RTCP transmission | |||
rules: periodic transmission of RTCP packets at the minimum | rules: periodic transmission of RTCP packets at the minimum | |||
(5 second) interval and randomisation of the transmission interval. | (5 second) interval and randomisation of the transmission interval. | |||
2. Demonstrate correct implementation of the RTCP step join backoff | 2.Demonstrate correct implementation of the RTCP step join backoff | |||
algorithm as a receiver. | algorithm as a receiver. | |||
3. Demonstrate correct implementation of the RTCP step join backoff | 3.Demonstrate correct implementation of the RTCP step join backoff | |||
algorithm as a sender. | algorithm as a sender. | |||
4. Demonstrate correct steady state scaling of the RTCP interval | 4.Demonstrate correct steady state scaling of the RTCP interval | |||
acording to the group size. | acording to the group size. | |||
5. Demonstrate correct steady state scaling of the RTCP interval | 5.Demonstrate correct steady state scaling of the RTCP interval | |||
acording to the group size with compensation for the number of | acording to the group size with compensation for the number of | |||
senders. | senders. | |||
6. Demonstrate correct implementation of the RTCP reverse reconsideration | 6.Demonstrate correct implementation of the RTCP reverse reconsideration | |||
algorithm. | algorithm. | |||
Perkins Page 4 | 7.Demonstrate correct implementation of the RTCP BYE reconsideration | |||
7. Demonstrate correct implementation of the RTCP BYE reconsideration | algorithm. | |||
algorithm. | ||||
8. Demonstrate correct implementation of the RTCP member timeout | 8.Demonstrate correct implementation of the RTCP member timeout | |||
algorithm. | algorithm. | |||
9. Demonstrate random choice of SSRC. | 9.Demonstrate random choice of SSRC. | |||
10. Demonstrate random selection of initial RTP sequence number. | 10.Demonstrate random selection of initial RTP sequence number. | |||
11. Demonstrate random selection of initial RTP timestamp. | 11.Demonstrate random selection of initial RTP timestamp. | |||
12. Demonstrate correct implementation of the SSRC collision/loop | 12.Demonstrate correct implementation of the SSRC collision/loop | |||
detection algorithm. | detection algorithm. | |||
13. Demonstrate correct generation of reception report statistics | 13.Demonstrate correct generation of reception report statistics | |||
in SR/RR packets. | in SR/RR packets. | |||
14. Demonstrate correct generation of the sender info block in SR | 14.Demonstrate correct generation of the sender info block in SR | |||
packets. | packets. | |||
4 Author's Address | 4 Author's Address | |||
Colin Perkins | Colin Perkins | |||
Department of Computer Science | Department of Computer Science | |||
University College London | University College London | |||
Gower Street | Gower Street | |||
London WC1E 6BT | London WC1E 6BT | |||
United Kingdom | United Kingdom | |||
Email: c.perkins@cs.ucl.ac.uk | Email: c.perkins@cs.ucl.ac.uk | |||
5 Acknowledgments | 5 Acknowledgments | |||
Thanks to Steve Casner, Jonathan Rosenberg and Bill Fenner for their | Thanks to Steve Casner, Jonathan Rosenberg and Bill Fenner for their | |||
helpful feedback. | helpful feedback. | |||
6 References | 6 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: A Transport Protocol to Real-Time Applications'', RFC1889, | ||||
Internet Engineering Task Force, January 1996. | ||||
[3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with | [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: | |||
Minimal Control'', draft-ietf-avt-profile-new-05.txt, February 1999. | A Transport Protocol to Real-Time Applications'', RFC1889, Internet | |||
Engineering Task Force, January 1996. | ||||
Perkins Page 5 | [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences with | |||
[4] C. S. Perkins, J. Rosenberg and H. Schulzrinne, ``RTP Testing | Minimal Control'', draft-ietf-avt-profile-new-05.txt, February 1999. | |||
Strategies'', draft-ietf-avt-rtptest-01.txt, August 1999. | ||||
Perkins Page 6 | [4] C. S. Perkins, J. Rosenberg and H. Schulzrinne, ``RTP Testing | |||
Strategies'', draft-ietf-avt-rtptest-01.txt, August 1999. | ||||
End of changes. 64 change blocks. | ||||
151 lines changed or deleted | 147 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/ |