1.4 Relationship to Other Protocols
Sessions for this protocol are usually initiated through Session Initiation Protocol (SIP) Routing Extensions, as described in [MS-SIPRE] section 3.14. RTP transport parameters, such as protocol, IP, and port, for sessions established through SIP are usually communicated through Session Description Protocol (SDP) extensions for audio and video, as described in [MS-SDPEXT] section 3.1.5.
A host can negotiate multiple transport parameters, in which case the selection can be made by means of an advanced connectivity mechanism such as the Interactive Connectivity Establishment (ICE) protocol, as described in [MS-ICE] section 3.1.4.8.3 and [MS-ICE2] section 3.1.4.8.3. The ICE negotiation can use User Datagram Protocol (UDP), Transmission Control Protocol (TCP), or an assortment of network address translation (NAT) traversal mechanisms. If a connection-oriented transport protocol, such as TCP, is used, the framing described in [RFC4571] section 2 is used.
This protocol is based, in large part, on the RTP protocol, as described in [RFC3550] and [RFC3551].RTP packets can be encrypted and authenticated through the secure RTP protocol, as described in [MS-SRTP] section 3.1.3.3. For audio communications, RTP supports a redundancy mechanism for FEC, as described in [MS-RTPRADEX] section 3, as well as a mechanism for communicating dual-tone multi-frequency (DTMF) events, as described in [MS-DTMF] section 3.
This protocol supports the RTCP protocol, as described in [RFC3550]. This protocol also supports the RTCP-based feedback protocol, as described in [RFC4585], and the reduced-size RTCP protocol, as described in [RFC5506] with extensions described in section 2.2.12.
RTP supports Comfort Noise payload, as described in [RFC3389] section 4. Comfort Noise is used for audio codecs that do not support Comfort Noise, such as G.711, G.722.1, G.726, GSM 6.10, G.722, Siren, and RT Audio, for optimal audio quality. The clock rate of Comfort Noise is the same as the clock rate of the audio codec.
RTP also supports the application sharing payload, as described in [MS-RTASPF] section 3.2.5 for sending an RDP payload for application and desktop sharing.
Negotiation for these and other payload properties, including supported codecs, sampling rates, and dynamic payload type mappings, can also be done through SDP. For video communications, because data for a single frame can sometimes span more than one RTP packet, various video encapsulation methods can be used, such as RTVideo and H264, as described in [MS-RTVPF] and [MS-H264PF].
The following diagram illustrates this hierarchy between protocols. SIP and SDP are not represented because they are parallel to RTP. CN stands for Comfort Noise.
CN Events, CN over RTP, G.722, G.722/2 (see section 2.2.1.1), H264, H263, RDP Payload, and RDP over RTP are not uniformly supported across all endpoints (2).
Figure 1: Protocol hierarchy of RTP with the extension