[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06                                          
INTERNET-DRAFT                                  20 July 2001

                                               Colin Perkins
                                                     USC/ISI



      RTP Audio/Video Profile Interoperability Statement

             draft-ietf-avt-profile-interop-06.txt



                    Status of this memo



This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-Drafts.

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 is inappropriate to use Internet-Drafts as reference
material or to cite them other than as work in progress.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Distribution of this document is unlimited.

Comments are solicited and should be addressed to the author and/or the
IETF Audio/Video Transport working group's mailing list at avt@ietf.org



                         Abstract


    It is required to demonstrate interoperability of implementations
    in order to move the RTP audio/video profile to draft standard.
    This memo outlines those features to be tested, as the first
    stage of an interoperability statement.



1 Introduction



The Internet standards process [1] places a number of requirements
on a standards track protocol specification.  In particular, when
advancing a protocol from proposed standard to draft standard it



Perkins                                              Page 1



INTERNET-DRAFT                                 20 July 2001



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 level only if those
options or features are removed.  The RTP Profile for Audio and Video
Conferences with Minimal Control was originally specified in RFC1890 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 Audio/Video
profile which need to be tested as a basis for this demonstration.

This memo is for information only and does not specify a standard
of any kind.



2 Features and options required to demonstrate interoperability



In order to demonstrate interoperability it is required to produce
a statement of interoperability for each feature noted below.  Such
a statement should note the pair of implementations tested, including
version numbers, and a pass/fail statement for each feature.  It
is not expected that every implementation will implement every feature,
but each feature needs to be demonstrated by some pair of applications.

The RTP specification [3] enumerates a number of items that can be
specified or modified by a profile.  Those modified from the defaults
by the audio/video profile are as follows, and interoperable behaviour
must be demonstrated:


 1. Exchange of RTCP packets with the default RTCP reporting interval.

     o  PASS: rat, IP/TV

 2. Exchange of RTCP packets with a modified RTCP reporting interval
    as selected by a different fraction of the session bandwidth
    (the means by which this interval is signalled are outside of
    the scope of this memo, but one such mechanism should be demonstrated).

     o  PASS: IP/TV, rtplib

 3. Implementations must send RTCP packets containing an SDES CNAME
    in every reporting interval.

     o  PASS: rat, IP/TV

Perkins                                              Page 2



INTERNET-DRAFT                                 20 July 2001


 4. Other SDES items must be sent every third interval, with NAME
    every 7 of 8 times within that slot and any other SDES items
    cycically taking up the 8th slot.

     o  PASS: rat, IP/TV

 5. Interoperable selection of `pass phrase' for encryption and exchange
    of media using DES encryption.  This must include mapping of
    the pass phrase to the canonical form.

     o  FAIL: NeVoT does this, need to test...

 6. Interoperable transport of RTP via unicast UDP

     o  PASS: rat, vat, vic, IP/TV

 7. Interoperable transport of RTP via multicast UDP

     o  PASS: rat, vat, vic, IP/TV

 8. Interoperable transport of RTP via TCP using the encapsulation
    defined in section 7 of [2].

     o  FAIL: Real have it?

The primary purpose of the audio/video profile is to define the mapping
from payload format to payload type number.  Accordingly, the majority
of the work needed to demonstrate interoperability consists of testing
that media data is exchanged in an interoperable manner using the
full range of codecs enumerated in the profile.

The following codecs are assigned static payload types.  It should
be verified that interoperable implementations exist for each static
payload type:

 1. The 8kHz PCMU codec (payload type 0)

     o  PASS: rat, vat, fphone, IP/TV, Nuera.

 2. The 8kHz 1016 codec (payload type 1)

     o  FAIL

 3. The 8kHz G726-32 codec (payload type 2)

     o  PASS: rat vs Ericsson (tested by Magnus Westerlund)

 4. The 8kHz GSM codec (payload type 3)

     o  PASS: rat, vat, fphone, IP/TV

Perkins                                              Page 3



INTERNET-DRAFT                                 20 July 2001

 5. The 8kHz G723 codec (payload type 4)

     o  PASS: AudioCodes has performed Interoperability of its G.723.1
        coder with Microsoft NetMeeting, Telogy (a TI company), VocalTec
        as well as several other companies (reported by Yehuda Herskovitz).

     o  PASS: Also implementations by Nuera, Meridian 1 ITG, BCM
        and Matra 6500, Microsoft Netmeeting, Cisco.  (Reported by
        Tom Taylor).

     o  PASS: Nortel Meridian ITG with Acer, Arelnet, Cisco IOS gateway,
        CU-SeeMe (MCU and endpoint), Dataconnection (MCU and endpoint),
        Delta Information Systems, First Virtual Corporation, Intel
        Internet Phone, Avaya Definity, Lucent Alchemy, Microsoft
        Netmeeting, Radcom, Radvision L2W Gateway, Samsung Si, Sony
        Contact.  Nortel Business Communication Manager and Nortel
        Matra 6500 would have similar interoperability list.

 6. The 8kHz DVI4 codec (payload type 5)

     o  PASS: rat, vat, fphone, IP/TV

 7. The 16kHz DVI4 codec (payload type 6)

     o  PASS: QuickTime vs rat

 8. The 8kHz LPC codec (payload type 7)

     o  PASS: rat, vat, fphone

 9. The 8kHz PCMA codec (payload type 8)

     o  PASS: Nuera with Lucent

10. The 8kHz G722 codec (payload type 9)

     o  PASS: Accord have tested with Polycom, VCON and PictureTel.
        RealAudio have an implementation, also.

11. The 44.1kHz stereo L16 codec (payload type 10)

     o  PASS: RealNetworks with QuickTime

12. The 44.1kHz mono L16 codec (payload type 11)

     o  PASS: RealNetworks with QuickTime

13. The 8kHz QCELP codec (payload type 12)

     o  PASS: RealNetworks with QuickTime

14. The 8kHz CN codec (payload type 13)

     o  RESERVED: no need to test for now?

Perkins                                              Page 4



INTERNET-DRAFT                                 20 July 2001


15. The MPA codec (payload type 14)

     o  PASS: IP/TV, PixStream, Minerva, LiveCaster

16. The 8kHz G728 codec (payload type 15)

     o  PASS: Accord have tested with Polycom, VCON and PictureTel.
        Nuera have an implementation, also.

17. The 11.025kHz DVI4 codec (payload type 16)

     o  PASS: QuickTime vs rat

18. The 22.050kHz DVI4 codec (payload type 17)

     o  PASS: QuickTime vs rat

19. The 8kHz G729 codec (payload type 18)

     o  PASS: Nuera vs Cisco, Nortel, VegaStream (SIP Bakeoff 5)



The following codecs use dynamic payload types.  It should be verified
that some non-RTP means can be used to assign a dynamic payload type
to be used by implementations, and that those implementations can
then interwork.



 1. The GSM-HR codec

     o  FAIL: Cisco have an impl?  Dinesh Nambisan (dineshn@cisco.com)

 2. The GSM-EFR codec

     o  PASS: Tested implementations by Magnus Westerlund at Ericsson
        and Ari Lakaniemi at Nokia.  Also implementations by Nuera
        (Maroula Bratakos <mbratakos@nuera.com>) and Cisco (Ling
        Niu) exist.

 3. The L8 codec

     o  PASS: RealNetworks with QuickTime

 4. The RED codec

     o  PASS: rat, fphone

 5. The VDVI codec

     o  PASS: rat, fphone



Perkins                                              Page 5



INTERNET-DRAFT                                 20 July 2001

Similarly, interoperable implementation of the following video codecs
with static payload type numbers must be demonstrated:

 1. The CellB codec (payload type 25)

     o  PASS: JMF 2.1, VIC 2.8-1.1.3 from UCL, ShowMeTV, NV

 2. The JPEG codec (payload type 26)

     o  PASS: ShowMeTV, Quicktime, vic.

 3. The nv codec (payload type 28)

     o  PASS: nv and vic (confirmed by Ron Frederick)

 4. The H261 codec (payload type 31)

     o  PASS: IP/TV, vic, VCON, Polycom

 5. The MPV codec (payload type 32)

     o  PASS: IP/TV, PixStream, Minerva

 6. The MP2T codec (payload type 33)

     o  PASS: Cisco have a pre-release implementation which receives
        from the Optibase Media GateWay 3100 v1.0 (Humphrey Liu
        <hcliu@cisco.com>).  Sun also have an implementation, and are
        willing to test (Jonathan Sergent <sergent@eng.sun.com>)

 7. The H263 codec (payload type 34)

     o  PASS: PictureTel with Vtel, Polycom, etc.  (Lulin Chen)


The following codecs use dynamic payload types.  It should be verified
that some non-RTP means can be used to assign a dynamic payload type
to be used by implementations, and that those implementations can
then interwork.

 1. The BT656 codec

     o  FAIL: Cabo has an implementation

 2. The H263-1998 codec

     o  PASS: RealNetworks with QuickTime

 3. The MP1S codec

     o  FAIL: quicktime has it, anyone else?  2NetFX? Optivision?

 4. The MP2P codec

     o  FAIL: quicktime has it, anyone else?  2NetFX? Optivision?

Perkins                                              Page 6



INTERNET-DRAFT                                 20 July 2001

 5. The BMPEG codec

     o  FAIL



Implementations must also demonstrate interoperable use of the marker
bit.  That is, the M bit is set on the first packet of each talkspurt
for audio and on the last packet of each frame for video.



3 Author's Address


Colin Perkins
USC Information Sciences Institute
3811 North Fairfax Drive
Suite 200
Arlington, VA 22203
USA
Email:  csp@isi.edu



4 References



[1] S. Bradner, ``The Internet Standards Process -- Revision 3'',
RFC2026, Internet Engineering Task Force, October 1996.

[2] H. Schulzrinne, S. Casner, ``RTP Profile for Audio and Video
Conferences with Minimal Control'', RFC1890, Internet Engineering
Task Force, January 1996.

[3] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, ``RTP:
A Transport Protocol to Real-Time Applications'', RFC1889, Internet
Engineering Task Force, January 1996.



Perkins                                              Page 7