1.6 Applicability Statement

This protocol is intended only to be a streaming protocol, carrying just the payload and the minimum of 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, that is, through some other protocol (usually SIP, H.323, 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 specified in [MS-RTPRAD], can reduce the impact of packet loss but not eliminate it.

This protocol is extremely time-sensitive, especially for voice communications. This means that 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 will all negatively affect the end-user experience. This means that the choice of protocol (connectionless or connection-oriented) and connection path (direct or through an intermediate host) affects the users' experience.