rtp and rtcp
TRANSCRIPT
1
1
RTP protocol
Written by Ahmed Hesham Mostafa,Sec 1,Level 4,CS
Faculty of computer science and information, Helwan University
Introduction
The Real-time Transport Protocol (RTP) defines a standardized packet format for delivering audio and video over IP networks. RTP is used extensively in communication and systems that involve streaming media, such as telephony, video teleconference applications and web-based push to talk features. For these it carries media streams controlled by H.323, MGCP, Megaco, SCCP, or Session Initiation Protocol (SIP) signaling protocols, making it one of the technical foundations of Voice over IP. RTP is usually used in conjunction with the RTP Control Protocol (RTCP). While RTP carries the media streams (e.g., audio and video), RTCP is used to monitor transmission statistics and quality of service (QoS) and aids synchronization of multiple streams. When both protocols are used in conjunction, RTP is originated and received on even port numbers and the associated RTCP communication uses the next higher odd port number.
More generally, RTP makes it possible to: Identify the type of information carried. Add temporary markers and sequence number to the information carried.
monitor the packets' arrival at the destination
RTP characteristics
1- Provides end-to-end transport functions for real-time applications 2- Supports different payload types 3- RTP can transport data continuously rather than in bursts, and it can handle
data delivery in multicast environments. 4- RTP takes care of data that TCP cannot handle. Such data can include voice,
video 5- RTP/RTCP are usually implemented within applications --- not as clean cut
as TCP 6- RTP do not Perform signaling (negotiate the media format) other protocol
used to perform signaling such as SIP or H323.
2
2
RTP in the OSI Layer-Model
RTP was designed to run independently of the underlying transport and network
layers of the OSI model
Application
RTP/RTCP
UDP
IP
Link layer
Physical layer
Figure 1
-How data transfer from client and server in OSI model using RTP Protocol
Figure1 –transfer multimedia (Voice /video) between client and server via RTP
3
3
RTP Packet
RTP packet generation
1-encoding (at sender) / decoding (at receiver) data.
2-segmentation (at sender) / reassembling (at receiver) of the data
3-add RTP header
4-encapsualte RTP Packets with UDP header
5-encapsualte RTP Packets with IP header to create packets
Figure RTP Packets generation
4
4
RTP Packet components
IP Header: UDP Packets are encapsulated in IP datagram
UDP Header: RTP packets are encapsulated in UDP datagrams (TCP
cannot be used due to overhead and to the fact that most of real time traffic
is multicast)
-Port number is an even number randomly assigned at the session initiation time
RTP Header: Variable size, depending on the application (i.e. when
needed). Designed to be small to decrease the overhead.
RTP Payload: a payload of voice/video samples
Figure3- RTP packet
RTP Header
Version field V: 2 bits long indicates the protocol version (V=2)
Padding field P: 1 bit, if P is equal to 1, the packet contains additional bytes
for padding to finish the last packet.
Extension field X: 1 bit, if X=1 the header is followed by an extension
packet
CSRC count field CC: 4 bits, contains the number of CSRC which follow
the header
Marker field M: 1 bit, its interpretation is defined by an application profile
IP header RTP payloadRTP headerUDP header
5
5
Payload type field PT: 7 bits, this field identifies the payload type (audio,
video, image, text, html, etc.)
Sequence number field: 16 bits, its initial value is random and it
increments by 1 for each packet sent, it can be used to detect lost packets
Timestamp field: 32 bits, reflects the moment when the first byte of the
RTP packet has been sampled. Used to enable synchronization and the
calculation of the jitter at the destination.
SSRC field: 32 bits uniquely identify the source, its value is chosen
randomly by the application. The SSRC identifies the synchronization
source (simply called "the source"). This identifier is chosen randomly with
the intent that it is unique among all the sources of the same session.
CSRC field: 32 bits, identifies contributing sources.
Figure RTP Header
RTP sessions
A session consists of a group of participants who are communicating using
RTP
6
6
A participant may be active in multiple RTP sessions (e.g. one for audio and
one for video)
For each participant, the session is identified by a network address, a port
pair for sending data and a port pair for receiving data
Each port pair comprises two adjacent ports An even-numbered port for RTP
data packets
The next higher (odd-numbered) port for RTCP control packets
RTP translator or mixer can be used in a session to adapt the data
transmission to participant’s conditions
RTP sessions types
Multicast (between n nodes).
Unicast (peer 2 peer).
Unicast with Mixer/translator
multicast to unicast
Figure RTP Sessions
Translator and mixer
Translator
Manage communications between entities that does not support the same coding scheme
Mixer
7
7
Receive RTP packets from a group of sources and combine them into a single output, possibly changing the encoding, before forwarding the result
RTCP Protocol
Designed to be used with RTP and to control an RTP session and provide
feedback on the quality of the data distribution and allows one who is
observing problems to evaluate whether those problems are local or global.
RTP and RTCP packets belonging to the same session use the same
multicast address but different port number
RTCP port number = RTP port number + 1
RTCP packets are sent periodically to provide Periodic reporting of
reception quality (e.g. number of packets sent, number of packets lost, inter-
arrival jitter) ,Notification on changes in session membership and Information needed to synchronize media streams
RTCP messages:
RTCP has five types of Messages (Reports):
RR: receiver report. Receiver reports are generated by participants
that are not active senders. They contain reception quality feedback
about data delivery, including the highest packets number received,
the number of packets lost, inter-arrival jitter, and timestamps to
calculate the round-trip delay between the sender and the receiver.
SR: sender report. Sender reports are generated by active senders. In
addition to the reception quality feedback as in RR, they contain a
sender information section, providing information on inter-media
synchronization, cumulative packet counters, and number of bytes
sent.
SDES: source description items. They contain information to
describe the sources.
BYE: indicates end of participation.
8
8
APP: application specific functions. It is now intended for
experimental use as new applications and new features are developed.
Figure RTCP Messages
RTCP Packets
RTCP Header
Version: Identifies the RTP version which is the same in RTCP packets
as in RTP data packets.
P – Padding: RTCP packet contains some additional padding octets at
the end which are not part of the control information. In a compound
RTCP packet, padding should only be required on the last individual
packet because the compound packet is encrypted as a whole.
RC- Reception report count: the number of reception report blocks
contained in this packet. A value of zero is valid.
Length: The length of this RTCP packet in 32-bit words minus one,
including the header and any padding
2 bit 3bit 8 bit 16 bit
Version P RC Packet type
9
9
Length
Figure RTCP Header
RTCP SR Header
SR - Section one. The first section is 8 octets long Version (V): 2 bits Identifies the version of RTP, which is the same in
RTCP packets as in RTP data packets. The current version is two (2).
Padding (P): 1 bit if the padding bit is set, this RTCP packet contains some additional padding octets at the end which are not part of the control information. That last octet of the padding is a count of how many padding octets should be ignored.
10
10
Reception count: 5 bits the number of reception report blocks contained
in this packet. A value of zero is also valid.
Packet type: 8 bits Contains the constant 200 to identify this as an RTCP
SR packet.
Length: 16 bits the length is the RTCP packet in 32 bit words minus one,
including the header and any padding.
SSRC: 32 bit the synchronization source identifier for the originator of
this SR packet.
SR - Section two. The second section, the sender information, is 20 octets long and is presented in every sender report packet. It summarizes the data transmissions from this sender. NTP timestamp: 64 bits Indicates the wall clock time when this report
was sent so that it may be used in combination with timestamps returned
in reception reports from other receivers to measure round-trip
propagation to those receivers. A sender that has no notion of wall clock
or elapsed time may set the NTP timestamp to zero.
RTP timestamp: 32 bits Corresponds to the same time as the NTP timestamp, but in the same units and with the same random offset as the RTP timestamps in the data packets.
Sender PKT counts: 32 bits the total number of RTP data packets by the sender since starting transmission up until the time this SR packet was generated. The count is reset if the sender changes its SSRC identifier.
Sender octet count: 32 bits the total number of payload octets transmitted in RTP data packets by the sender since starting transmission. The count is reset if the sender changes its SSRC identifier. This field can be used to estimate the average payload data rate.
SR - Section three. The third section contains zero or more reception report blocks depending on the number of other sources heard by this sender since the last report. Each reception report block conveys statistics on the reception of RTP packets from a single synchronization source. Receivers do not carry over statistics when a source changes its SSRC identifier due to a collision.
SSRC_n (src ident): 32 bits The SSRC identifier of the source to which the information in this reception report block pertains.
Fraction lost: 8 bits the fraction of RTP data packets from source SSRC_n lost since the previous SR or RR packet was sent, expressed as a fixed point number with the binary point at the left edge of the
11
11
filed. That is equivalent to taking the integer part after multiplying the loss fraction by 256. This fraction is defined to be the number of packets lost divided by the number of packets expected, as defined in the next paragraph.
Total packets lost: 24 bits Total number of RTP data packets from the source SSRC_n that have been lost since the beginning of reception. This number is defined to be the number of packets expected less the number of packets actually received, where the number of packets received includes any which are late or duplicates. Thus packets that arrive late are not counted as lost, and the loss may be negative if there are duplicates. The number of packets expected is defined to be the extended last sequence number received, as defined next, less the initial sequence number received.
Last sequence #: 32 bits the low 16 bits contain the highest sequence number received in an RTP data packet from source SSRC_n, and the most significant 16 bits extend that sequence number with the corresponding count of sequence number cycles. Note that different receivers within the same session will generate different extensions to the sequence number if their start times differ significantly.
Inter arrival jitter: 32 bits an estimate of the statistical variance of
the RTP data packet inter-arrival time measured in timestamp units
and expressed as an unsigned integer. The inter-arrival jitter J is
defined to be the mean deviation of the difference D in packet spacing
at the receiver compared to the sender for a pair of packets. As shown
in the equation below, this is equivalent to the difference in the
"relative transit time" for the two packets (i and j). The relative transit
time is the difference between a packets RTP timestamp Si and the
receiver's clock at the time of arrival, RI measured in the same units.
12
12
RTCP RR Header
An empty RR packet (RC=0) is put at the head of a compound RTCP packet when there is no data transmission or reception to report.
13
13
RTCP SDES Header
RTCP SDES Header Description
Version (V), SSRC, Padding (P), length: see SR packet description
Packet type (PT): 8 bits Contains the constant 202 to identify this as
an RTCP SDES packet.
Source Count (SC): 5 bits the number of SSRC/CSRC chunks
contained in this SDES packet. A value of zero is valid but useless.
SDES item: n bits the source description item has to be unique among
all session participants, one good choice is to use the canonical name
of the source.
RTCP BYE Header
14
14
RTCP BYE Header Description
Version (V), SSRC, Padding (P), length: see SR packet description. Packet type (PT): 8 bits Contains the constant 203 to identify this as
an RTCP BYE packet.
Source count (SC): 5 bits the number of SSRC/CSRC identifiers
included in this BYE packet.
How RTP/RTCP Protocols work together
An RTP Session is established for each multimedia stream. A session consists of an
IP address with a pair of ports for RTP and RTCP. For example, audio and video
streams will have separate RTP sessions, enabling a receiver to deselect a
particular stream. The ports which form a session are negotiated using other
protocols SIP or H323. According to the specification, an RTP port should be even
and the RTCP port is the next higher odd port number. RTP and RTCP typically use
unprivileged UDP ports (1024 to 65535).
Each participant uses two ports. One for audio data and the
other for control (RTCP) packets
Each participant sends audio data in small chunks of say 20 mS
duration
A RTP header is added which contains the timing field that
ensures that the chunks of data are continuously played for
every 20mS
Both audio and video are transmitted as two separate RTP
sessions.
Separate RTP and RTCP packets are transmitted for each
medium using two UDP port pairs and multicast addresses.
No direct coupling at the RTP level between the audio and
video sessions
15
15
Figure RTP and RTCP Packet s transamination