draft-ietf-avt-rtp-interop-07.txt   draft-ietf-avt-rtp-interop-08.txt 
Colin Perkins Colin Perkins
USC/ISI USC/ISI
RTP Interoperability Statement RTP Interoperability Statement
draft-ietf-avt-rtp-interop-07.txt draft-ietf-avt-rtp-interop-08.txt
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with
provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering
Force (IETF), its areas, and its working groups. Note that other groups Task Force (IETF), its areas, and its working groups. Note that
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
may be updated, replaced, or obsoleted by other documents at any time. It and may be updated, replaced, or obsoleted by other documents at
is inappropriate to use Internet-Drafts as reference material or to cite any time. It is inappropriate to use Internet-Drafts as reference
them other than as work in progress. material or to cite 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
skipping to change at line 58 skipping to change at line 58
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
nature of RTP there are necessarily two types of test described: those of RTP there are necessarily two types of test described: those which directly
which directly affect the interoperability of implementations at a ``bits affect the interoperability of implementations at a ``bits on the wire
on the wire level'' and those which affect scalability and safety of the level'' and those which affect scalability and safety of the protocol but
protocol but do not directly affect interoperability. A related memo [4] do not directly affect interoperability. A related memo [4] describes a
describes a testing framework which may aid with interoperability testing. 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
skipping to change at line 225 skipping to change at line 225
19. Interoperable exchange of source description packets containing 19. Interoperable exchange of source description packets containing
a NOTE item. a NOTE item.
o PASS: rat vs vat o PASS: rat vs vat
o PASS: IP/TV vs vat/vic o PASS: IP/TV vs vat/vic
20. Interoperable exchange of source description packets containing 20. Interoperable exchange of source description packets containing
a PRIV item. a PRIV item.
o FAIL: need to test rtplib against rtpdump? o PASS: Magnus Westerlund has tested an implementation at Ericsson
against rat.
o FAIL: Ericsson have an implementation, Magnus Westerlund
will test against rat.
21. Interoperable exchange of BYE packets containing a single SSRC. 21. Interoperable exchange of BYE packets containing a single SSRC.
o PASS: rat vs vat o PASS: rat vs vat
o PASS: IP/TV vs vat/vic o PASS: IP/TV vs vat/vic
22. Interoperable exchange of BYE packets containing multiple SSRCs. 22. Interoperable exchange of BYE packets containing multiple SSRCs.
o FAIL: rat can send these, but vat only accepts the first o PASS: IP/TV 3.0 server with rat 4.2.13
SSRC
o FAIL: IP/TV sends only one SSRC in BYE, but should accept
multiple
o FAIL: need to test rat-3.0.x against rtplib
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.
o PASS: tested IP/TV sending to vat. Also rtplib generates o PASS: tested IP/TV sending to vat. Also rtplib generates
and displays them. and displays them.
24. 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
skipping to change at line 277 skipping to change at line 268
o PASS: rat vs vat o PASS: rat vs vat
26. 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).
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.
o PASS: rat, IP/TV o PASS: rat, IP/TV
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.
skipping to change at line 297 skipping to change at line 288
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.
o PASS: rat, IP/TV o PASS: rat, IP/TV
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.
o PASS: rat, rtplib o PASS: rat, rtplib
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.
o PASS: rat, rtplib o PASS: rat, rtplib
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.
o PASS: rat, IP/TV o PASS: rat, IP/TV
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.
o PASS: rat, IP/TV o PASS: rat, IP/TV
6. Demonstrate correct implementation of the RTCP reverse reconsideration 6. Demonstrate correct implementation of the RTCP reverse reconsideration
algorithm. algorithm.
o FAIL: rat is correct, o PASS: rat is correct,
o FAIL: Ericsson have an implementation: Magnus Westerlund o PASS: Ericsson have a correct implementation (Magnus Westerlund)
is testing...
7. Demonstrate correct implementation of the RTCP BYE reconsideration 7. Demonstrate correct implementation of the RTCP BYE reconsideration
algorithm. algorithm.
o FAIL: Ericsson have an implementation: Magnus Westerlund o PASS: Demonstrated with rat (Colin Perkins) and an Ericsson
is testing... implementation (Magnus Westerlund)
8. Demonstrate correct implementation of the RTCP member timeout 8. Demonstrate correct implementation of the RTCP member timeout
algorithm. algorithm.
o PASS: IP/TV, vat, rat o PASS: IP/TV, vat, rat
o FAIL: Ericsson have an implementation: Magnus Westerlund o PASS: 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.
skipping to change at line 377 skipping to change at line 367
Arlington, VA 22203 Arlington, VA 22203
USA USA
Email: csp@isi.edu Email: csp@isi.edu
5 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: A [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP:
Transport Protocol to Real-Time Applications'', RFC1889, Internet A 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
Minimal Control'', draft-ietf-avt-profile-new-08.txt, January 2000. with 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. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/