1.6 Applicability Statement

This protocol is intended to be a streaming protocol only, carrying just the payload and the minimum metadata needed for real-time rendering. Even RTCP is intentionally limited in negotiation and session control capabilities. Except for these few exceptions, all capability negotiation, session establishment and session control is supposed to be done by non-RTP means, through another protocol, which is usually SIP or SDP.

This protocol is a best effort protocol and, when run over unreliable transport, does not provide reliable transmission of every packet. Redundancy mechanisms, such as the one described in [MS-RTPRADEX] section 3, can reduce the impact of packet loss, but not eliminate it.

This protocol is extremely time-sensitive, especially for voice communications. The quality of the experience is very dependent upon the quality of the underlying network. Issues such as long delays, jitter, and high packet loss all negatively affect the end-user experience. The choice of protocol, connectionless or connection-oriented, or connection path, direct or through an intermediate host, also affects user experience.

Although the packet loss extension is generic, because it only includes a sequence number, its use is only specified for video streams in this document.