draft-ietf-avt-rtp-interop-04.txt   draft-ietf-avt-rtp-interop-05.txt 
Colin Perkins Colin Perkins
USC/ISI USC/ISI
RTP Interoperability Statement RTP Interoperability Statement
draft-ietf-avt-rtp-interop-04.txt draft-ietf-avt-rtp-interop-05.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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as Internet-Drafts.
skipping to change at line 30 skipping to change at line 30
material or to cite 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 Comments are solicited and should be addressed to the author and/or the
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. in order to move the RTP specification to draft standard. This memo
This memo outlines those features to be tested, as the first outlines those features to be tested, as the first stage of an
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
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 is necessary to demonstrate at least two independent and interoperable
level only if those options or features are removed. The Real-time implementations, from different code bases, of all options and features of
Transport Protocol, RTP, was originally specified in RFC1889 as a that protocol. Further, in cases where one or more options or features
proposed standard [2]. The revision of this specification for draft have not been demonstrated in at least two interoperable implementations,
standard status is now well underway, so it has become necessary the specification may advance to the draft standard level only if those
to conduct such an interoperability demonstration. options or features are removed. The Real-time Transport Protocol, RTP,
was originally specified in RFC1889 as a proposed standard [2]. 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 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 which need to be tested as a basis for this demonstration. Due to the
the nature of RTP there are necessarily two types of test described: nature of RTP there are necessarily two types of test described: those
those which directly affect the interoperability of implementations which directly affect the interoperability of implementations at a ``bits
at a ``bits on the wire level'' and those which affect scalability on the wire level'' and those which affect scalability and safety of the
and safety of the protocol but do not directly affect interoperability. protocol but do not directly affect interoperability. A related memo [4]
A related memo [4] describes a testing framework which may aid with describes a testing framework which may aid with interoperability testing.
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 92 skipping to change at line 91
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: rat vs vat
o PASS: IP/TV vs vat/vic o PASS: IP/TV vs vat/vic
2. Interoperable exchange of data packets which use padding. 2. Interoperable exchange of data packets which use padding.
o FAIL: need to test IP/TV against Quicktime o FAIL: need to test IP/TV against Quicktime
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.
o FAIL: IP/TV, rat, rtptools, rtplib should all support this, o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2
but have not been tested.
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.
o PASS: rat vs vat o PASS: rat vs vat
o PASS: IP/TV vs vic o PASS: IP/TV vs vic
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
skipping to change at line 159 skipping to change at line 156
o PASS: IP/TV vs vat/vic (IP/TV never sends SR with report o PASS: IP/TV vs vat/vic (IP/TV never sends SR with report
blocks, but does successfully receive them from vic/vat). blocks, but does successfully receive them from vic/vat).
10. Interoperable exchange of receiver report packets. 10. Interoperable exchange of receiver report packets.
o PASS: rat vs vat o PASS: rat vs vat
o PASS: IP/TV vs vat/vic o PASS: IP/TV vs vat/vic
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).
o PASS: rat vs vat o PASS: rat vs vat
o PASS: IP/TV vs vat/vic o PASS: IP/TV vs vat/vic
12. Interoperable and correct choice of CNAME, according to the rules 12. Interoperable and correct choice of CNAME, according to the rules
in the RTP specification and profile (applications using the in the RTP specification and profile (applications using the
audio/video profile [3] under IPv4 should typically generate 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 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). are on a machine which no concept of usernames).
o PASS: rat vs vat o PASS: rat vs vat
o PASS: IP/TV vs vat/vic o PASS: IP/TV vs vat/vic
skipping to change at line 265 skipping to change at line 265
25. Interoperable exchange of application defined RTCP packets. As 25. 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 FAIL: a number of libraries (rtplib, rat, IP/TV MSOCK) support o PASS: jrtplib-2.4 vs UCL RTP library v1.2.2
this but have not been tested. Quicktime uses APP packets
and needs to be tested against one of the others.
26. Interoperable exchange of encrypted RTP packets using DES encryption 26. 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 27. 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
skipping to change at line 396 skipping to change at line 394
[2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP: [2] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP:
A 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 [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences
with Minimal Control'', draft-ietf-avt-profile-new-08.txt, January with Minimal Control'', draft-ietf-avt-profile-new-08.txt, January
2000. 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-03.txt, July 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/