The RTP provides end-to-end network transport functions suitable for applications transmitting real-time audio or video packets over multicast or unicast network services. It was developed by the IETF and is used with the H.323’s recommended H.225 protocols to provide reliable communications. RTP by itself does not address resource reservation and does not guarantee QoS for real-time services. The packet transport is supplemented by a control protocol (RTCP) that monitors data delivery in a manner scalable to large multicast networks and provides minimal control and identification functionality. RTP and RTCP are designed to be independent of the underlying transport and network layers. The protocol supports the use of RTP-level translators and mixers. The following are the elements of RTP.
RTP Payload
The media payload is transported by RTP in a packet, such as audio samples or compressed video data. The payload format and interpretation are beyond the scope of this document.
RTP Packet
A packet consists of the fixed RTP header, a possibly empty list of contributing sources (see below), and the payload data. Some underlying protocols may require an encapsulation of the RTP packet to be defined. Typically, one packet of the underlying protocol contains a single RTP packet, but several RTP packets may be contained, if permitted by the encapsulation method.
RTCP Packet
A control packet consists of a fixed header part similar to that of RTP packets, followed by structured elements that depend on the RTCP packet type. Typically, multiple RTCP packets are sent together as a compound RTCP packet in a single packet of the underlying protocol; this is enabled by the length field in the fixed header of each RTCP packet. Figure 1 shows the RTP header.
The RTP fixed header fields have certain functions. V (version): Identifies the RTP version. P (padding): When set, the packet contains one or more additional padding octets at the end that are not part of the payload. X (extension bit): When set, the fixed header is followed by exactly one header extension with a defined format. CSRC count: Contains the number of CSRC identifiers that follow the fixed header. M (marker): The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame boundaries to be marked in the packet stream. Payload type: Identifies the format of the RTP payload and determines its interpretation by the application. A profile specifies a default static mapping of payload type codes to payload formats. Additional payload type codes may be defined dynamically through non-RTP means. Sequence number: Increments by one for each RTP data packet sent and may be used by the receiver to detect packet loss and restore packet sequence. Timestamp: Reflects the sampling instant of the first octet in the RTP data packet. The sampling instant must be derived from a clock that increments monotonically and linearly in time to allow synchronization and jitter calculations. The resolution of the clock must be sufficient for the desired synchronization accuracy and for measuring packet arrival jitter (one tick per video frame is typically not sufficient). SSRC (synchronization source): Identifies the synchronization source. This identifier is chosen randomly, with the intent that no two synchronization sources within the same RTP session will have the same SSRC identifier. CSRC (contributing source): Contributing source identifiers list. Identifies the contributing sources for the payload contained in this packet.
 |
No comments:
Post a Comment