rtp and rtcp

15
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.

Upload: ahmed-hesham

Post on 26-Mar-2015

349 views

Category:

Documents


3 download

TRANSCRIPT

Page 1: Rtp and Rtcp

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.

Page 2: Rtp and Rtcp

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

Page 3: Rtp and Rtcp

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

Page 4: Rtp and Rtcp

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

Page 5: Rtp and Rtcp

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

Page 6: Rtp and Rtcp

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

Page 7: Rtp and Rtcp

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.

Page 8: Rtp and Rtcp

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

Page 9: Rtp and Rtcp

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.

Page 10: Rtp and Rtcp

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

Page 11: Rtp and Rtcp

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.

Page 12: Rtp and Rtcp

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.

Page 13: Rtp and Rtcp

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

Page 14: Rtp and Rtcp

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

Page 15: Rtp and Rtcp

15

15

Figure RTP and RTCP Packet s transamination