MediaTechnik, LLC.

RTP/RTSP implementation

RTP/RTSP implementation

Revision 1.2 July, 2002

Overview Contents

1. Structure
This data sheet describes the
RTP/RTSP implementation of 2. Detailed description of the
implementation
MediaTechnik, LLC.
The RTP/RTSP is available as a set 3. Protocol descriptions
of library functions. 3.1. RTP/RTCP
3.2. RTSP
4. Software description
4.1. Network module
Features
4.2. RTP module
4.3. RTCP module
• Fully ISMA-compliant. Also 4.4. RTSP module
contains a full RTCP
implementation. 5. Glossary
6. References
• Can be used for distributing
media content from various 7. Further information
video and audio sources to
any PC-based media player.
• Supports transport of
multiple encoding methods
(H.263, MP3, MPEG-4).
Easily extendable with other
formats.
• The generated media stream
can be played by any MPEG-
4 compliant media player.
(Eg. QuickTime Player)
• All the code written in C.
• Uses UDP and TCP.
• Suitable for various platforms
(uses BSD Sockets).

Page 1 of 6
 MediaTechnik, LLC. RTP/RTSP implementation

1. Structure

RTSP client
Describe
Setup
Options RTSP server
Play
Pause
Teardown

RTP client
Audio port RTP
Audio/video
Video port

RTCP server
RTCP client
5 sec

Page 2 of 6
MediaTechnik, LLC. RTP/RTSP implementation

2. Detailed description of the implementation

- It is fully ISMA-compliant implementation, written in ANSI C, available as a

set of library functions. The library also contains a full RTCP implementation,
not a simplified one as other libs do.
- Compression formats that can be transported currently: H.263 [5], MP3 [18],
MPEG-4 [16] Easily extendable with other formats.
- It can be used for distributing media content from various video and audio
sources to any PC-based media player. The generated media stream can be
played by any MPEG-4 compliant media player. (Eg. QuickTime Player)
- This implementation works on every platform, which has BSD or equivalent
network interface.
- A working UDP interface needed for our implementation, as it is described as
usual practice in the protocol description ([1], [8]).

3. Protocol descriptions

3.1. RTP/RTCP

This protocol is described in RFC-1889 [1]. RTP provides end-to-end network

transport functions suitable for applications transmitting real- time data, such as audio,
video or simulation data, over multicast or unicast network services. RTP does not
address resource reservation and does not guarantee quality-of-service for real-time
services. The data transport is augmented by a control protocol (RTCP) to allow
monitoring of the data delivery in a manner scalable to large multicast networks, and
to provide minimal control and identification functionality. RTP and RTCP are
designed to be independent of the underlying transport and network layers. The
protocol supports the use of RTP- level translators and mixers.

3.2. RTSP

This protocol is described in RFC-2326 [8]. The Real Time Streaming Protocol, or
RTSP, is an application- level protocol for control over the delivery of data with
real-time properties. RTSP provides an extensible framework to enable controlled,
on-demand delivery of real- time data, such as audio and video. Sources of data can
include both live data feeds and stored clips. This protocol is intended to control
multiple data delivery sessions, provide a means for choosing delivery channels such
as UDP, multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP.

Page 3 of 6
MediaTechnik, LLC. RTP/RTSP implementation

4. Software description

4.1. Network module

• Responsible for performing network functions.

• Callback based. The user registers callback functions that will be called on
network activities.
• Supports TCP and UDP transport protocols.
• Supports multicast addresses.

4.2. RTP module

• Responsible for sending and receiving RTP packets.

• It has the capability to send packets to multiple addresses.

4.3. RTCP module

• Responsible for sending and receiving RTCP packets.

• It has the capability to send packets to multiple addresses.
• The application can set callbacks if it wants to be notified, when certain
information arrives.

4.4. RTSP module

• Implements the RTSP functions.

• The user sets callback functions for the RTSP commands and they will be called
when a command arrives or a client connects to the server.

5. Glos sary

Signal source
Source of the data, can be video source, provided by a webcam, SVHS port, or audio
source from a microphone, etc.

Signal encoder
Input data processing step, some encoder encodes the data (H.263, MP3, MPEG-4).

RTP broadcaster
Makes the RTP packets and sends them via UDP.

Page 4 of 6
MediaTechnik, LLC. RTP/RTSP implementation

RTP receiver
Receives the RTP packets, constructs the original data from the fragments.

6. References

[1] RFC-1889, “RTP: A Transport Protocol for Real-Time Applications”,

Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, Jan 1996
[2] RFC-1890, “RTP Profile for Audio and Video Conferences with Minimal
Control”, Schulzrinne, H., Jan 1996
[3] RFC-2029, “RTP Payload Format of Sun's CellB Video Encoding”, M. Speer,
D. Hoffman, Oct 1996
[4] RFC-2032, “RTP Payload Format for H.261 Video Streams”, T. Turletti, C.
Huitema, Oct 1996
[5] RFC-2190, “RTP Payload Format for H.263 Video Streams”, C. Zhu., Sep 1997
[6] RFC-2198, “RTP Payload for Redundant Audio Data”, C. Perkins, I. Kouvelas,
O. Hodson, V. Hardman, M. Handley, J.C. Bolot, A. Vega-Garcia, S.
Fosse-Parisis, Sep 1997
[7] RFC-2250, “RTP Payload Format for MPEG1/MPEG2 Video”, D. Hoffman, G.
Fernando, V. Goyal, M. Civanlar, Jan 1998
[8] RFC-2326, “Real Time Streaming Protocol (RTSP)”, H. Schulzrinne, A. Rao, R.
Lanphier, Apr 1998
[9] RFC-2343, “RTP Payload Format for Bundled MPEG”, M. Civanlar, G. Cash,
B. Haskell, May 1998
[10] RFC-2429, “RTP Payload Format for the 1998 Version of ITU-T Rec. H.263
Video (H.263+)”, C. Bormann, L. Cline, G. Deisher, T. Gardos, C. Maciocco, D.
Newell, J. Ott, G. Sullivan, S. Wenger, C. Zhu, Oct 1998
[11] RFC-2431, “RTP Payload Format for BT.656 Video Encoding”, D. Tynan, Oct
1998
[12] RFC-2435, “RTP Payload Format for JPEG-compressed Video”, L. Berc, W.
Fenner, R. Frederick, S. McCanne, P. Stewart, Oct 1998
[13] RFC-2658, “RTP Payload Format for PureVoice(tm) Audio”, K. McKay, Aug
1999
[14] RFC-2733, “An RTP Payload Format for Generic Forward Error Correction”, J.
Rosenberg, H. Schulzrinne, Dec 1999
[15] RFC-2833, “RTP Payload for DTMF Digits, Telephony Tones and Telephony
Signals”, H. Schulzrinne, S. Petrack, May 2000
[16] RFC-3016, “RTP Payload Format for MPEG-4 Audio/Visual Streams”, Y.
Kikuchi, T. Nomura, S. Fukunaga, Y. Matsui, H. Kimata, Nov 2000
[17] RFC-3047, “RTP Payload Format for ITU-T Recommendation G.722.1”, P.
Luthi, Jan 2001

Page 5 of 6
MediaTechnik, LLC. RTP/RTSP implementation

[18] RFC-3119, “A More Loss-Tolerant RTP Payload Format for MP3 Audio”, R.
Finlayson, Jun 2001
[19] RFC-3158, “RTP Testing Strategies”, C. Perkins, J. Rosenberg, H. Schulzrinne,
August 2001.
[20] RFC-3189, “RTP Payload Format for DV (IEC 61834) Video”, K. Kobayashi,
A. Ogawa, S. Casner, C. Bormann, Jan 2002
[21] RFC-3190, “RTP Payload Format for 12-bit DAT Audio and 20- and 24-bit
Linear Sampled Audio”, K. Kobayashi, A. Ogawa, S. Casner, C. Bormann, Jan
2002

7. Further information

To find out more about the technical features of this library or to request information
on pricing and licensing, please contact MediaTechnik, LLC.

Address: MediaTechnik, LLC.

Peterfia u. 53.
Debrecen
H-4026
HUNGARY

Phone: +36-52-525-865
Fax: +36-52-525-861
E- mail: [email protected]
Web: http://www.mediatechnik.com

Page 6 of 6