draft-ietf-avt-rtp-interop-02.txt   draft-ietf-avt-rtp-interop-03.txt 
Colin Perkins Colin Perkins
University College London USC/ISI
RTP Interoperability Statement RTP Interoperability Statement
draft-ietf-avt-rtp-interop-02.txt
draft-ietf-avt-rtp-interop-03.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.
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
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.
outlines those features to be tested, as the first stage of an This memo outlines those features to be tested, as the first
interoperability statement. stage of an 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
which need to be tested as a basis for this demonstration. Due to the specification which need to be tested as a basis for this demonstration.
nature of RTP there are necessarily two types of test described: those Due to the nature of RTP there are necessarily two types of test described:
which directly affect the interoperability of implementations at a ``bits those which directly affect the interoperability of implementations at a
on the wire level'' and those which affect scalability and safety of the ``bits on the wire level'' and those which affect scalability and safety of
protocol but do not directly affect interoperability. A related memo [4] the protocol but do not directly affect interoperability. A related memo
describes a testing framework which may aid with interoperability testing. [4] 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
skipping to change at line 112 skipping to change at line 115
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. Other RTCP packet types may be included, SDES CNAME packet. Other RTCP packet types may be included,
but this is not required for this test. 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 which of the sender reports is also a sender (ie: sender reports
contain one or more report blocks). which 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 data (ie: the empty receiver report which has to be sent first
in each compound RTCP packet when no-participants are transmitting in each compound RTCP packet when no-participants are transmitting
data). data).
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
skipping to change at line 234 skipping to change at line 237
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 USC Information Sciences Institute
University College London 4350 North Fairfax Drive
Gower Street Suite 620
London WC1E 6BT Arlington, VA 22203
United Kingdom USA
Email: c.perkins@cs.ucl.ac.uk Email: csp@isi.edu
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: [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 with [3] H. Schulzrinne, ``RTP Profile for Audio and Video Conferences
Minimal Control'', draft-ietf-avt-profile-new-05.txt, February 1999. 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-01.txt, August 1999. Strategies'', draft-ietf-avt-rtptest-03.txt, July 2000.
 End of changes. 

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