How to work with RTP in VoIP SIP calls?

This article is about to introduce the basic knowledge about RTP (Real-time Transport Protocol) in connection with Ozeki VoIP SIP SDK support and softphone developement. As the SDK uses this protocol as basic background for data transport.

Figure 1 - Working with RTP in Softphone solutions

What is RTP? How does it work?

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

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.

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

The RTP header has the minimum size of 12 bytes that can be increased with optional fields. The RTP header specification is shown in Figure 2 below.

Figure 2 - 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.

RTP standard is written in the RFC 3550 document so you can check all the information about the protocol and RTP packets in that.

How to use RTP packages in C#?

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.

As you can see, Ozeki VoIP SIP SDK contains all the background support for RTP packets, and you will not have to do anything with RTP protocol at all, but you get all the support when using the higher level tools of Ozeki VoIP SIP SDK.

Training guides, simple examples

If you would like to visit the detailed developer documentations, you can learn much more from the Ozeki VoIP SIP SDK Training chapter.

Communication through the network

During the established communication (after the SIP Register and SIP Invite period is done successfully), communication is being done with RTP Package sending and RTP package receiving. An example rtp package:

[Stream setup by SDP (frame 28)]
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source code identifiers count: 0
1... .... = Marker: True
Payload type: ITU-T G.711 PCMU (0)
Sequence number: 7133
[Extended sequence number: 72669]
Timestamp: 85000
Synchronization Source identifier: 0x712f7356 (1898935126)

If you have any questions or need assistance, please contact us at

Related Pages

Copyright © 2000- - Ozeki Ltd |
Legal | Privacy | Terms of use | 7088 | | Login