info@voip-sip-sdk.com Tel: +36 1 371 0150


Did you know?

This SDK was used to build:

Ozeki Phone System XE - VoIP PBX Software for Developers Which is a high performance PBX system supporting Mobile and Desktop phones.


It was also used to create Ozeki 3D VoIP softphone. A cool SIP client that allows 3D Video calls.

Real-time Transport Protocol (RTP)

Real-time Transport Protocol specifies a standardized packet format that is applied for the transmission of multimedia data such as audio and video over the Internet.

RTP ensures end-to-end multimedia data delivery with real-time characteristics. Practically it means that with the implementation of RTP it is possible to deliver interactive video or audio data over multicast or unicast network services.

RTP is also able to ensure data delivery to multiple destinations with the use of multicast distribution. These facts make RTP be the primary standard for audio/video delivery in IP networks.

Therefore, RTP is often and widely employed by network or transport protocols. For example, in case of UDP, RTP helps use its multiplexing and checksum services.

RTP is often used together with RTCP (RTP Control Protocol). If both protocols are included, RTP is responsible for delivering media streams, while RTCP checks transmission statistics and quality of service. Since real-time multimedia streaming applications need timely data delivery but they are able to tolerate some packet loss RTP can be adopted easily by them.

In this way, communication and entertainment systems widely employ RTP when they include streaming media, like telephony or videoconferencing and web-based push to talk feature.

That is why RTP becomes one of the basic elements of VoIP technology.

Protocol components

  • RTP: The real-time transport protocol carries real-time multimedia data including timestamps (for synchronization), sequence numbers (for packet loss detection) and the payload format which indicates the encoded format of the data.
  • RTCP: The RTP control protocol monitors the quality of service and conveys information about the participants in an on-going session.

Sessions

For all multimedia streams RTP sessions are build-up and these sessions include an IP address with a port for RTP and another port for RTCP. The RTP ports needs to be even port numbers while the RTCP port has the next higher odd port number. The ports can use other protocols such as SDP or SIP, as well.

Profiles

RTP supports a wide range of multimedia formats (e.g. MPEG-4, MJPEG, MPEG, etc) and it also allows to add new formats without the need of revision of the RTP standard.

RTP headers do not include information about the needs of respective applications. These information are defined by RTP profiles and payload formats. In this way for all applications (e.g. audio) there is a defined profile and one or more associated payload formats by RTP.

The Profile specifies the codecs that encodes the payload data and their way to payload format codes in the "Payload Type" field of the header.

Protocol Structure (Packet)

Figure 1 demonstrates an RTP packet and its segments. For example, if 5 MPEG packets are transferred in RTP, they are forwarded to RTP Payload segment. Since it is an UDP packet there are an IP header and a UDP header segment and because it is sent via RTP there is an RTP header segment, as well.


Figure 1 - RTP packet

The RTP header fields are the follows

Version number
(2 bits)
Identifies the RTP version
Padding bit
(1 bit)
Indicates if there are extra padding bytes at the end of the RTP packet
Extension
(1 bit)
Indicates if there is an optional extension header between standard header and payload data
Contributing sources
(4 bits)
CSRC identifiers are included in it that comes after the fixed header
Marker bit
(1 bit)
It is defined by a profile. It is for allowing significant events like frame boundaries to be marked in the packet stream
Payload type
(7 bits)
Identifies the RTP payload's format and determines its interpretation by the application
Sequence number
(16 bits)
Increments by one for each RTP data packet sent and used by the receiver to detect packet loss and to restore packet sequence.
Timestamp
(32 bits)
It allows the receiver to play back the received samples at the proper intervals. If there are more media streams the timestamps are independent in each stream
Synchronization source
(32 bits)
Ensures that each source of stream will have a unique identifier within the same RTP session. In this way it is avoided that two sources has the same SSRC identifier within the same RTP session.
CSRC It is an identifier list of contributing sources for the payload that is included in this packet.
Extension header (optional) 16 bit: Profile specific identifier
16 bit: Length specifier of the extension

Related Pages

Ozeki Cookie Policy
Ozeki Informatics Ltd uses cookies to provide you the best experience on this website. The further use of the website will be considered as an agreement to the use of cookies. For more information read this website.

Cookies are enabled You are browsing the optimized version of this website. For more information read this website.