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/