This article covers the basic knowledge about RTP (Real-time Transport Protocol)
in connection with Ozeki VoIP SIP SDK support and softphone building. As the SDK uses this
protocol as basic background for data transport, you may want to understand the terms
related to RTP and this page will introduce them to you.
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 entertainment systems that involve
streaming media, such as telephony, video teleconference applications,
television services and web-based push-to-talk features (Figure 1).
Figure 1 - Working with RTP in Softphone solutions
RTP is 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. RTP
is originated and received on even port numbers and the associated
RTCP communication uses the next higher odd port number.
Ozeki VoIP SIP SDK provides all the background support for RTP, so handling this protocol
will not bother you while building your softphone. However, you may be interested in the
the structure of an RTP package to get a precise view about the topic.
RTP standard is written in the RFC 3550 document so
you can check all the information about the protocol and RTP packets in that.
Sub-protocol definitions in RTP specification
The RTP specification contains four sub-protocols that are the following:
The data transfer protocol, RTP (RFC 3550),
which deals with the transfer of real-time data. Information provided by this
protocol includes timestamps (for synchronization), sequence numbers (for packet
loss and reordering detection) and the payload format which indicates the encoded
format of the data.
A control protocol, RTCP, used to specify quality of service (QoS) feedback and synchronization between the media streams. The bandwidth of RTCP traffic compared to RTP is small, typically around 5%.
Every multimedia stream requires an established RTP session. This session consists an IP address
and two port numbers, one for RTP and the other for RTCP. The
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).
If you want to create an RTP package, you will know how the RTP header builds up as
it is the essential requirement for RTP packages.
How exactly an RTP header looks like?
The RTP header has the minimum size of 12 bytes that can be increased with optional fields.
The RTP header specification is shown in Table 1 below.
Profile-specific extension header ID
Extension header length
Table 1 - The specification of an RTP packet header
The order of the fields in RTP header can not be changed. The fields represent the following
information in the header:
Version: (2 bits) Indicates the version of the protocol. Current version is
P (Padding): (1 bit) Used to indicate if there are extra padding bytes at the
end of the RTP packet. A padding might be used to fill up a block of certain size,
for example as required by an encryption algorithm.
X (Extension): (1 bit) Indicates presence of an Extension header between
standard header and payload data. This is application or profile specific.
CC (CSRC Count): (4 bits) Contains the number of CSRC identifiers (
defined below) that follow the fixed header.
M (Marker): (1 bit) Used at the application level and defined by a
profile. If it is set, it means that the current data has some special
relevance for the application.
PT (Payload Type): (7 bits) Indicates the format of the payload and
determines its interpretation by the application. This is specified by an RTP profile.
Sequence Number: (16 bits) The sequence number is incremented by one
for each RTP data packet sent and is to be used by the receiver to detect
packet loss and to restore packet sequence. The RTP does not specify any
action on packet loss; it is left to the application to take appropriate action.
Timestamp: (32 bits) Used to enable the receiver to play back the received
samples at appropriate intervals. When several media streams are present, the
timestamps are independent in each stream, and may not be relied upon for media
synchronization. The granularity of the timing is application specific.
SSRC: (32 bits) Synchronization source identifier uniquely identifies
the source of a stream. The synchronization sources within the same RTP session will be unique.
CSRC: Contributing source IDs enumerate contributing sources to a stream which has
been generated from multiple sources.
Extension header: (optional) The first 32-bit word contains a
profile-specific identifier (16 bits) and a length specifier (16 bits) that
indicates the length of the extension (EHL=extension header length) in 32-bit
units, excluding the 32 bits of the extension header.
Ozeki VoIP SIP SDK provides you full RTP support
When you are building a softphone application you usually don't want to do every background
step from the first stage. If you don't want to be bothered with such fundamental
tools as RTP but want to be sure that your media streams will work properly with RTP
support, you need Ozeki VoIP SIP SDK.
Ozeki VoIP SIP SDK does all the background work such as settings, creating RTP headers,
generating RTP packets, etc. You do not even need to call any methods for this support as
the higher level media handler classes already have all these tools built in. If you want to enjoy all
the advantages of not having to write a single code line about RTP support download Ozeki
VoIP SIP SDK now.
What built-in tools provide RTP support in Ozeki VoIP SIP SDK?
If you want to be sure that there really is a support for RTP packets in Ozeki VoIP SIP
SDK, you can check some tools that are defined in Ozeki.VoIP.SDP.Message.SDPFields and
Ozeki.VoIP.SDP.Message.SDPFields namespace defines an Enum type for identifying
the media transport protocol. It has the values RtpAvp, RtpSavp, TcpRtp and Udp. The last
is a standard session transport protocol, and the first three defines RTP protocol
The first enum value that is RtpAvp is an implementation of a standard RTP protocol.
RtpSavp defines a secure RTP protocol implementation that uses some standard encryption techniques.
The TcpRtp implements and RTP transmission protocol on a higher network level with the
usage of the TCP protocol.
Ozeki.VoIP.SDP.Message.SDPFields.SDPAttributes namespace defines a class
for RTP mapping that is SDPAttrRtpmap. This class contains methods for checking
the clock rate, encoding name and parameter attributes and getting the payload type.
As you can see, Ozeki VoIP SIP SDK contains all the background support for RTP packet and
does it so well that you will not have to do anything with RTP protocol at all but you get
all these support when using the higher level tools of Ozeki VoIP SIP SDK.