Technology Highlights

RTP (Realtime Transport Protocol, RFC3550, replaced RFC1889) is a session protocol for IP-based networks which uses UDP (User Datagram Protocol) as transport protocol. In opposite to the pure UDP implementation RTP guarantees the right sequence of packets at the receiver side.

RTP gives the packets to be sent a type identification (PTI – Payload-type Identification), sequence numbers, time-stamp and sender identification. With the timing information audio and video data can be synchronized. Sequence numbers allow the packets to be sorted in the right order as well as possible losses of the packets to be detected.

Due to the payload-type identification there are dynamic changes of an encoding procedure during the session allowed.

RTP supports Unicast and Multicast (and MAYAH products support RTP Broadcast as well).

Data transfer is monitored with RTCP.

In consumer world RTP is used by following applications: Voice-over-IP, ISMA, QuickTime Player, VLC Media Player, Windows Media Player (version 9 and later)

Full description of RFC3550 (http://www.ietf.org/rfc/rfc3550.txt)

RTCP (RTP Control Protocol, RFC3550, replaced RFC1889) is working on top of the RTP. Not interfering with a real data stream it provides some control data exchange between streaming session participants. Receiving a feedback information as packets sent, lost packets, round trip delay, jitter, etc., the streaming can be accommodated on current network conditions.

RTCP is based on a recurring exchange of a control packets between the participants of the streaming session. It provides following functions:

Quality of Service feedback

• Due to this information the sender is able to readjust the transmission parameters.

Identification of Participants of the Session

• Due to the exactly defined information the receiver can associate the different data streams with some sender to handle them accordingly.

Monitoring of RTCP bandwidth

• The data transfer must not be affected by the exchange of the control packets.

Session Control

• There are NTP time-stamps added to information of the sender. Together with RTP time-stamps they allow an intra-media synchronization (within the same data stream), and inter-media synchronization (between different streams).

Quality of Service Monitoring

• With the help of the information from sender and receiver a network jitter and a network reliability can be defined.

Full description of RFC3550 (http://www.ietf.org/rfc/rfc3550.txt)

RTP Profile for Audio and Video Conferences with Minimal Control (RFC3551, replaced RFC1890). It describes which RFC accordingly some encoding procedure encapsulate the data and which payload-type identification (PTI) becomes the procedure. E.g. AudioMPEG-1, AudioMPEG-2 are encapsulated with RFC2250 and become PTI “14”. G.711, a-law becomes “8” etc.

For encoding procedures which are not specified there are identifications 96-127(“dynamic assignment”) provided. In such a case the codec identification must be carried out the other way. With SDP for instance (see below).

MAYAH provides such other way too: RTP Header Extension.

RTP specifies an area in the RTP header which is reserved for an individual purposes. It can be supplied with an information independent of the packets type. This “Header Extension” is utilized when no packets type for the chosen encoding procedure defined. The “Header Extension” is being recurringly sent, so the receiver is able to join the session if it was already started. The format of MAYAH Header Extension is publicly available.

Full description of RFC3551 (http://www.ietf.org/rfc/rfc3551.txt)

SDP (Session Description Protocol, RFC2327). Descriptions of multimedia streaming sessions with SDP include important initialization parameters information. They are being used to invite participants and to announce the start of the session or to initialize the connection some other way.

The description is a plain text containing information about codec type, sample rate, bitrate etc. and connection details, such as protocol, address, port etc.

To distribute the SDP description there are various protocols again: SAP, RTSP, SIP.

SDP is utilized for example by Voice-over-IP, ISMA, Quicktime Player, VLC Media Player, Windows Media Player (Version 9 and later)

Full description of RFC2327 (http://www.ietf.org/rfc/rfc2327.txt)

SAP (Session Announcement Protocol, RFC2974) is used to announce the information provided by SDP on some multicast address to give the potential clients an overview of the contents available on the current (sub)network. Mayah supports in addition an untraditional way of SAP-unicast.

SAP information is being regularly updated. It can be provided with some authentication and if required encrypted.

SAP is used for instance by Voice-over-IP, VLC Media Player.

Full description of RFC2974 (http://www.ietf.org/rfc/rfc2974.txt)

RTSP (Real Time Streaming Protocol, RFC2326) is an application protocol which supports delivery, monitoring and control of the unicast or multicast multimedia data .

It’s applicable to the big conferences as well as to simple Video-on-Demand (VoD) tasks. There are discrete channels for the delivery of data (e.g. RTP) and for the monitoring (e.g. TCP). RTSP can be considered a kind of “Network Remote Protocol ” for multimedia server.

RTSP includes a client-server communication allowing to inform the client of the contents available at the server side, to make the choice of the contents, to start the connection or to join the already running one. For the description of the contents the SDP can be used.

RTSP is utilized by following applications: Voice-over-IP, ISMA, Quicktime Player, VLC Media Player, Windows Media Player (Version 9 or later)

Full description of RFC2326 (http://www.ietf.org/rfc/rfc2326.txt)