High performance VoIP SDK for .Net developers

VoIP SIP SDK

Working with RTP in VoIP SIP calls

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.

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 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%.[8][9]

  • An optional signaling protocol such as H.323 or Session Initiation Protocol (SIP) (RFC 3261)

  • An optional media description protocol such as Session Description Protocol (SDP) (RFC 4566)

How can you establish an RTP session?

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.

bit offset 0-1 2 3 4-7 8 9-15 16-31
0 Version P X CC M PT Sequence Number
32 Timestamp
64 SSRC identifier
96 CSRC identifiers
...
96+32×CC Profile-specific extension header ID Extension header length
128+32×CC Extension header
...


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.SDPAttributes namespaces.

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

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.

If you have any questions or need assistance, please contact us at info@voip-sip-sdk.com

You can select a suitable Ozeki VoIP SIP SDK license for your project on Pricing and licensing information page

Related Pages