The VAT protocol was originally implemented in the VAT audio tool and subsequently also in other audio tools such as NeVoT. The VAT protocol is now obsolete and should not be used or implemented.

The VAT header format is only described in header files. (See the VAT and NeVoT sources for details.) Many aspects of RTP and the VAT protocol are similar, but RTP improves upon the VAT protocol in a number of WAYS:

The VAT protocol was designed for audio only, while RTP is specified for audio and video and may be suitable for other real-time applications.

RTP is designed to be protocol-independent and can be used with non-IP protocols (ATM AAL5, for EXAMPLE) as well as, say, IPv6.

RTP source identification SIMPLIFIES the use of mixers and TRANSLATORS.

RTP has a number of features that simplify use of application-level encryption (padding, etc.).

The RTP header is extensible, should the need arise in the future.

The RTP header has a sequence number which simplifies accurate loss detection and measurement and the handling of images transmitted in several packets.

The RTCP SDES packets contain additional information that simplify tracing of misbehaving sources, e.g., their email address or telephone number.

The RTCP SDES CNAME items simplify the construction of multimedia application from independent media agents.

RTCP sender and receiver reports allow the implementation of adaptive applications, that is, applications where senders scale their bandwidth consumption based on network load.

RTCP sender and receiver reports allow monitoring of the quality of service within, say, a multimedia conference.

The VAT protocol was originally implemented in the VAT audio tool and subsequently also in other audio tools such as NeVoT. The VAT protocol is now obsolete and should not be used or implemented.

The VAT header format is only described in header files. (See the VAT and NeVoT sources for details.) Many aspects of RTP and the VAT protocol are similar, but RTP improves upon the VAT protocol in a number of ways:

The VAT protocol was designed for audio only, while RTP is specified for audio and video and may be suitable for other real-time applications.

RTP is designed to be protocol-independent and can be used with non-IP protocols (ATM AAL5, for example) as well as, say, IPv6.

RTP source identification simplifies the use of mixers and translators.

RTP has a number of features that simplify use of application-level encryption (padding, etc.).

The RTP header is extensible, should the need arise in the future.

The RTP header has a sequence number which simplifies accurate loss detection and measurement and the handling of images transmitted in several packets.

The RTCP SDES packets contain additional information that simplify tracing of misbehaving sources, e.g., their email address or telephone number.

The RTCP SDES CNAME items simplify the construction of multimedia application from independent media agents.

RTCP sender and receiver reports allow the implementation of adaptive applications, that is, applications where senders scale their bandwidth consumption based on network load.

RTCP sender and receiver reports allow monitoring of the quality of service within, say, a multimedia conference.