Olaf Beier Studiengang: Dipl. Ing. Informationstechnik - IfI

Olaf Beier 

Studiengang: Dipl. Ing. Informationstechnik 

Kursbezeichnung BA-Mannheim: TIT 99 BGR 

Abstract des Praxisbericht 

zur 4. Praxisphase (02.07.2001 - 28.09.2001) 

Firma dieser Praxisphase: University of Oslo, Department of Informatics 

Ausbildungsbetrieb: Fraunhofer IPSI Darmstadt 

Thema: “Operating system and protocol enhancements for increased 

performance in distributed interactive multimedia 

presentations” 

Fachliche Ausbildungsbetreuung Oslo: Dr. Ing. Carsten Griwodz 

Administrative Betreuung Oslo: Prof. Dr. Thomas Plagemann 

Administrative Betreuung FhG-IPSI Darmstadt: Dr. Heinz-Dieter Böcker

Abstract: 

This “Praxisbericht“ has its main focus on the description of the Transport Protocol 

and the Transport Control Protocol for Real-Time Applications as described in RFC 

1889. This knowledge has been necessary in order to extend in the source code of the 

open source project Komssys (KOM(S) RTSP/RTP streaming system). The protocol 

specification was invented 1996 by the Audio-Video Transport Working Group 

within the Network Working Group of the Internet Engineering Task Force (IETF). 

The Inventors are H. Schulzrinne (GMD Fokus), S. Casner (Precept Software, Inc), R. 

Frederick (Xerox Palo Alto Research Center) and V. Jacobson (Lawrence Berkeley 

National Laboratory). 

My special work in the Komssys project was “to examine the Komssys RTP stack, to 

isolate media handling code that can be moved into loadable modules and to compare 

KOMS’ Multimedia File System Minorca to SGI XFS”. 

This means I had to analyse the existing Komssys RTP Stack and its support for the 

following media formats: PCMU, AVI, H.261, MPEG, MPA and MP3. The main 

focus of my work was to improve the API. Also those codecs can now be easily 

implemented, which must be used with a wrapper because the sources are not 

available. It was my task to find a way to divide the existing and well working sourcetree 

into an encoder and a decoder part for each currently supported codec separately. 

In addition, a new layer that instantiates codecs has been integrated. It is implemented 

as factory pattern. The now existing stack is encapsulated in separate modules for 

encoding and decoding for each codec separately. 

In contrast to the transmission of conventional data such as mails or websites, 

particular demands must be met to transmit multimedia data. This “Praxisbericht“ also 

describes transport problems of audio- and videostreams and give a brief overview of 

existing solutions. 

In some cases it can make sense to combine data streams coming from several 

participants and forward them as one single data stream. This is the task of a so-called 

mixer. If the bandwidth of a participant or a participant group in an audio conference 

is low, a mixer can be put at the starting point of this network segment. 

Participant 3 

Audio 3 

Participant 1 

Audio 1 

PCM 

Audio 2 

Participant 2 

RTP-Data Packet 

SSRC: Audio 1 

Datatyp: PCM 

Sequenceno.: 3231 

Timestamp: 84922 

PCM-Header 

PCM-Payload 


SSRC: Audio 2 

Datatyp: PCM 



PCM-Header 

PCM-Payload 

Figure of a Mixer as explained in chapter 5.3 

Mixer 

SSRC: Audio M 

SSRC: Audio 1 

SSRC: Audio 2 

SSRC: Audio 3 

Datatyp: PCM 



PCM-Header 

PCM-Payload 

Audio M RTP-Data Packet 

Audio 4 

Participant 4


Studiengang: Dipl. Ing. Informationstechnik 

Kursbezeichnung BA-Mannheim: TIT 99 BGR 

Praxisbericht zur 4. Praxisphase (02.07.2001 - 28.09.2001) 

Firma dieser Praxisphase: University of Oslo, Department of Informatics 

Ausbildungsbetrieb: Fraunhofer IPSI Darmstadt 

Thema: “Operating system and protocol enhancements for increased 

performance in distributed interactive multimedia 

presentations” 

Fachliche Ausbildungsbetreuung Oslo: 

Dr. Ing. Carsten Griwodz 

Administrative Betreuung Oslo: Prof. Dr. Thomas Plagemann 

Administrative Betreuung FhG-IPSI Darmstadt: Dr. Heinz-Dieter Böcker

Ehrenwörtliche Erklärung Praxisbericht 4 


TIT 99 BGR 

Ehrenwörtliche Erklärung 

Hiermit erkläre ich, Olaf Beier, gemäß den Vorgaben der Berufsakademie Mannheim, 

diesen Praxisbericht eigenhändig angefertigt zu haben. 

Mannheim, 10.09.2001 


Seite 2 von 25

Table of Contents Praxisbericht 4 


TIT 99 BGR 

Table of Contents 

Ehrenwörtliche Erklärung..............................................................................................2 

Table of Contents...........................................................................................................3 

List of Figures ................................................................................................................4 

1 Introduction............................................................................................................5 

1.1 General Information on UIO-IFI-KOMS.......................................................5 

1.2 My function within the UIO-IFI Research Group KOMS.............................5 

2 Transport problems for multimedia data................................................................7 

2.1 Introduction....................................................................................................7 

2.2 Methods of resolution: ...................................................................................7 

3 The Real-time Transport Protocol (RTP) ..............................................................8 

3.1 Tasks of RTP..................................................................................................8 

3.2 RTP as service for real time data ...................................................................8 

3.3 RTP Protocol Architecture.............................................................................8 

3.4 RTP fixed header fields .................................................................................9 

3.5 RTP Header Extension.................................................................................10 

4 The RTP Control Protocol (RTCP)......................................................................11 

4.1 Tasks of RTCP.............................................................................................11 

4.2 RTCP CNAME Identifier ............................................................................11 

4.3 RTCP Source Description............................................................................12 

4.4 RTCP Sender-/Receiver Report...................................................................13 

4.5 RTCP Goodbye packet ................................................................................15 

4.6 Application-defined RTCP packet...............................................................16 

5 Application scenarios...........................................................................................17 

5.1 Encapsulation of H.263................................................................................17 

5.2 Simple Audio conference.............................................................................17 

5.3 Multiplexing of several media streams ........................................................18 

5.4 Mixer............................................................................................................19 

5.5 Translator .....................................................................................................20 

6 What is Komssys?................................................................................................21 

6.1 Open Source.................................................................................................21 

6.2 General Overview ........................................................................................21 

6.3 Other RTSP/RTP based systems..................................................................22 

References....................................................................................................................23 

HTTP References.........................................................................................................25 

Seite 3 von 25

List of Figures Praxisbericht 4 


TIT 99 BGR 

List of Figures 

Figure 1 RTP Protocol Architecture [Boo00] ..........................................................9 

Figure 2 RTP Packet Header [RFC1889].................................................................9 

Figure 3 RTP Header Extension [RFC1889] .........................................................10 

Figure 4 CNAME: Canonical end-point Identifier [RFC1889] .............................11 

Figure 5 RTCP Source Description packet [RFC1889] .........................................12 

Figure 6 RTCP Sender-/Receiver Report packet [RFC1889] ................................15 

Figure 7 RTCP Goodbye packet [RFC1889] .........................................................16 

Figure 8 Application-defined RTCP packet [RFC1889]........................................16 

Figure 9 RTP data over UDP in an IP packet [Chu97] ..........................................17 

Figure 10 Simple Audio conference [Boo00] ..........................................................18 

Figure 11 Multiplexing of several media streams [Boo00]......................................19 

Figure 12 Transatlantic session as example for low bandwidth connections...........19 

Figure 13 Mixer [Boo00] .........................................................................................20 

Figure 14 Translator [Boo00]...................................................................................20 

Figure 15 Client-server configuration overview [GZ01] .........................................21 

Figure 16 Screenshot of the QT GUI (currently version 0.2 is the latest) ...............22 

Seite 4 von 25

Introduction Praxisbericht 4 


TIT 99 BGR 

1 Introduction 

1.1 General Information on UIO-IFI-KOMS 

The University of Oslo is Norway’s largest and oldest institution of higher education. 

It was founded in 1811 when Norway was still under Danish rule. Today, the 

University of Oslo has approximately 33,000 students, 4,500 employees and four 

Nobel Prize winners, who indicate the quality of the research at the University. 

The communication systems group (KOMS) is one out of ten research and interests 

groups at the Department of computer science and consists of twenty persons; KOMS 

is also operating an IPv6 Laboratory. KOMS is discussing the following topics: 

o Next generation Internet protocols 

o Distributed multimedia systems and applications 

o Quality-of-Service 

o Middleware 

o Routing in multiprocessor systems an on the Internet 

o High-speed Local and Metropolitan Area Networks 

o Close cooperation with MMDBMS systems 

Currently, the scientific staff members of KOMS are working in the following 

projects: 

o NetSim: a project based on the UCB/LBNL/VINT Network Simulator. 

o OPNET: Improving server-network performance and reliableness focussing on 

TCP/IP Protocol based on the OPNET Network Simulator. 

o Distributed Media Journaling: a research project focussing on capturing and 

indexing distributed multimedia applications in real time. 

o ENNCE: WP1: Enhanced Next-Generation Networked Computing 

Environment 

o ENNCE: WP2 MULTE: Multimedia Middleware for Low-Latency High- 

Throughput Environments. 

o INSTANCE: Intermediate Storage Node Concept to support asynchronous 

communication in server-based systems. 

o OMODIS: Object Oriented Modelling and Database Support in Distributed 

Systems. 

1.2 My function within the UIO-IFI Research Group KOMS 

My scope of duties comprised several different tasks and activities. My vocational 

adjustment to the following topics was my major task: multimedia networks, 

multimedia streaming, VoD [ZGS01] (using relevant project reports and technical 

literature such as RFCs [h:RFC], manuals and articles), along with the main features 

of professional software engineering under Linux. For this reason, my main point of 

interest was to gain insight into the Open Source project Komssys which I will 

introduce shortly in chapter 6. 

My special work in this project was “to examine the Komssys RTP stack [RFC1889], 

to isolate media handling code that can be moved into loadable modules and to 

compare KOMS’ Multimedia File System Minorca [WGP99] to SGI XFS [h:sgixfs]”. 

This means I had to analyse the existing Komssys RTP Stack and its support for the 

following media formats: PCMU, AVI, H.261, MPEG, MPA and MP3. The main 

focus of my work was to get a “nicer” Application Programming Interface (API). This 

Seite 5 von 25

Introduction Praxisbericht 4 


TIT 99 BGR 

means a more flexible and well-designed interface to easily implement new codecs - 

also those, which must be used with a wrapper because the sources are not available. 

It was my task to find a way to divide the existing and well working source-tree into 

an encoder and a decoder part for each currently supported codec separately. In 

addition, a new layer that instantiates codecs has been integrated. It is implemented as 

factory pattern [h:facpat]. The now existing - also stable working - stack is 

encapsulated in separate modules for encoding and decoding for each codec 

separately. 

Besides this, I supported the department with my expertise on the acquisition of 

hardware and software and organized a freelancer writing a press article about several 

of their current projects. 

Seite 6 von 25

Transport problems for multimedia data Praxisbericht 4 


TIT 99 BGR 

2 Transport problems for multimedia data 

2.1 Introduction 

In contrast to the transmission of conventional data such as mails or websites, 

particular demands must be met to transmit multimedia data. 

The data should, for example, be transmitted in real time, so that the sender receives 

the multimedia stream without interruption in order to avoid any dropout in the 

process of decoding the audio or video signal. The most frequent reasons for 

interruptions are: 

o varying delay (called jitter) 

o excessive packet loss 

o in synchronous communication such as IP-telephony also delay 

In most cases, this is caused by insufficient bandwidth and/or hardware or software 

problems or failure. 

Another transport feature for multimedia data is the possibility to make connections 

not only point-to-point but multicast like in the case of a conference. Additionally, 

transmission ought to be adapted to the different performance of client hardware and 

networks. 

2.2 Methods of resolution: 

Currently there are several different opinions about the way to solve these problems. 

For example ST2 [DB95], XTP [SDW92] or ATM [T1.627] are such solutions 

propagated by a minority of researchers. Another possibility is DiffServ [RFC2474], 

[RFC2475] which is favoured by IP-router manufacturer. Also the Resource 

ReSerVation Protocol (RSVP) [RFC2205] is a possibility, which provides the clients 

to coordinate the reservation of bandwidth. 

The original transport of the real time data between the participants will be warranted 

by the Real-time Transport Protocol (RTP) [RFC1889]. 

In the following I will present a closer look on the functionalities and mechanisms of 

RTP, as I have concentrated on this part of the Open Source Project Komsys - 

KOM(S) RTSP/RTP Streaming System. A more detailed description of Komsys can 

be found in chapter 6. 

Seite 7 von 25

The Real-time Transport Protocol (RTP) Praxisbericht 4 


TIT 99 BGR 

3 The Real-time Transport Protocol (RTP) 

3.1 Tasks of RTP 

RTP is a Transport Protocol for Real-Time Applications invented 1996 by the Audio- 

Video Transport Working Group within the Network Working Group of the IETF 

[h:IETF]. The Inventors are H. Schulzrinne (GMD Fokus), S. Casner (Precept 

Software, Inc), R. Frederick (Xerox Palo Alto Research Center) and V. Jacobson 

(Lawrence Berkeley National Laboratory). 

In order to hold a videoconference, it appears to suffice to build up a network 

connection, reserve the resources needed and send the data. This is not the case for the 

connectionless IP based networks, as only the following chain of mechanisms can 

accomplish the task: 

o In the first step the data stream is divided into packets that can be transmitted 

separately. The transmission can be unicast (one receiver) or multicast (several 

receivers). 

o At the side of the receiver, the received packets have to be resequenced. It may 

also be necessary to resynchronize them with other incoming data streams. 

o In addition, the receiver should be able to adapt to varying network conditions 

during the transmission. 

o Furthermore, the receiver needs meta data, which provide information on 

participating stations. 

These are not the tasks of the payload protocol suite but the data serve as input for the 

Real-time Transport Protocol, which wraps up the payload. 

3.2 RTP as service for real time data 

As indicated above, the actual purpose of RTP is to offer a service for the 

transmission of multimedia data between the end points of a unicast or multicast 

session. Major parts of this service are the marking of the payload and their source, 

the allocation of sequence numbers and time stamps for data packets, the monitoring 

of network conditions and the transmission of information on all session members. 

However, monitoring and meta data are not provided by RTP itself, but by the RTP 

Control Protocol (RTCP). RTP cannot enforce a certain QoS or give explicit 

guarantees for it. Neither can RTP warrant for the packets‘ arrival at the receiver, their 

synchronization and correct order. Sequence numbers and time stamps provided by 

RTP have to be used in order to enable the resequencing of the session by the 

receiver. 

3.3 RTP Protocol Architecture 

The specification of the most recent protocols allows the definition of optional fields 

or similar mechanisms for future extensions. However, this flexibility also has 

disadvantages, as the overhead caused by the more sumptuous parsing of the protocol 

headers is undesirable for real time data. For this reason RTP’s architecture differs 

fundamentally from other protocols in this point. RFC 1889 explicitly allows 

extensions of the RTP header in order to adapt it to certain application scenarios. 

These particular interpretations of the RTP header are defined in different Profile 

Specifications and apply for specific classes of applications (e.g. audio and video 

conferences [RFC1890]). 

Seite 8 von 25



TIT 99 BGR 

Protocol Specification 

Profile Specifications 

. . . 

. . . GSM MPA PCMA 

Payload Format Specifications 

RTP / RTCP 

AV Profile 

Figure 1 RTP Protocol Architecture [Boo00] 

. . . 

JPEG MPV H.263 . . . 

As displayed above, a Profile Specification is a link between the RTP kernel and the 

Payload Format Specification. It defines how the payload (e.g. H.263 [RFC2190]) is 

wrapped up in order to be transported via RTP. 

3.4 RTP fixed header fields 

A normal RTP Header has the following format; where the picture below shows the 

network byte order (i.e. BIG ENDIAN format): 

0 1 2 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|V=2|P|X| CC |M| PT | sequence number | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| timestamp | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| synchronization source (SSRC) identifier | 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

| contributing source (CSRC) identifiers | 

| .... | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Figure 2 RTP Packet Header [RFC1889] 

The first twelve octets are present in every RTP packet, while the list of CSRC 

(contributing source) identifiers is present only when inserted by a mixer. The 

individual fields have the following meaning: 

o Version (V): 2 bits. Version of RTP. (currently, version 2 is the latest) 

The version number defined by [RFC1889] is two (2). (The value 1 is 

used by the first draft version of RTP and the value 0 is used by the 

protocol initially implemented in the "vat" audio tool.) 

o Padding (P): 1 bit. If set, the packet contains one or more additional 

padding octets at the end which are not part of the payload. The last 

Seite 9 von 25



TIT 99 BGR 

octet of the padding contains a count of how many padding octets 

should be ignored. 

o Extension (X): 1 bit. If set, the fixed header is followed by exactly one 

header extension. 

o CSRC count (CC): 4 bits. The number of CSRC identifiers that follow 

the fixed header. This number exceeds one if the payload of the RTP 

packet contains data from several sources. 

o Marker (M): 1 bit. Defined by a profile, the marker is intended to allow 

significant events such as frame boundaries to be marked in the packet 

stream. 

o Payload type (PT): 7 bits. Identifies the format of the RTP payload. 

Some numbers are defined by the RFC but most can be assigned 

dynamically by the profile or by externally provided meta information. 

o Sequence number: 16 bits. Increments by one for each RTP data packet 

sent, may be used by the receiver to detect packet loss and to restore 

packet sequence. The initial value should be set randomly and wraps to 

0 after 2 16 -1. 

o Timestamp: 32 bits. The sampling instant of the first octet in the RTP 

data packet. May be used for synchronisation and jitter calculations. 

The initial value should be set randomly and wraps to 0 after 2 16 -1. 

o SSRC: 32 bits. Randomly chosen number to distinguish 

synchronisation sources (different host, users or applications) within 

the same RTP session. It indicates where the data has been combined, 

or the source of the data if there is only one source. 

o CSRC list: 0 to 15 items, 32 bits each. Contributing sources for the 

payload contained in this packet. The number of identifiers is given by 

the CC field. 

3.5 RTP Header Extension 

RFC 1889 describes an extension mechanism that is provided to allow individual 

implementations to experiment with new payload-format-independent functions that 

require additional information to be carried in the RTP data packet header. 

Interoperate implementations should be designed in a well-behaving manner, to 

ignore these header extensions, which have not been extended to them. 

0 1 2 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| defined by profile | length | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| header extension | 

| .... | 

Figure 3 RTP Header Extension [RFC1889] 

Seite 10 von 25

The RTP Control Protocol (RTCP) Praxisbericht 4 


TIT 99 BGR 

4 The RTP Control Protocol (RTCP) 

4.1 Tasks of RTCP 

RTCP is the control protocol that belongs to RTP. RTCP has four tasks: 

o RTCP’s main task is to inform the participants regularly on the quality of the 

data distribution on the network. This feedback enables the participants to 

adapt the data stream they generate to the network conditions. In case of bad 

network conditions, this can be done by reducing the data rate in order to 

reduce network congestion. For these purposes RTCP periodically transmits 

so-called Sender Reports (SR) and Receiver Reports (RR). 

o The next important task is the repeated transmission of unambiguous markers 

for each participant (Canonical Name, CNAME). These markers enable the 

receiver to reassemble several data streams (e.g. audio and video) that have 

been transmitted in separated sessions. 

o The periodic transmission of the control data is important, but this must not 

restrict the payload’s transport if there is a large number of participants. 

However, as each participant receives all RTCP packets, because he is 

listening at a multicast address, which means simultaneous communication 

between groups of computers and is known generically as multipoint 

communications, so every client can locally calculate the rate of control 

packets that have to be sent from the sum of the participants. For further 

details on calculating control packet rates have a look at [RFC1889]. 

o Last but not least RTCP offers each participant the option to send a Source 

Description (SDES) of his own system. 

4.2 RTCP CNAME Identifier 

The CNAME identifier (Canonical end-point identifier SDES item) has the following 

properties: 

o The SSRC identifier is randomly allocated, so it may change if a conflict is 

discovered or if a program is restarted. For this case the CNAME item is 

required to provide the binding from the SSRC identifier to an identifier for 

the source that remains constant 

o CNAME and SSRC should be unique among all participants within one RTP 

session 

o The CNAME should be fixed for each participant. In this way a binding across 

multiple media tools used by one participant in a set of related RTP sessions is 

possible. 

o To facilitate third-party monitoring, the CNAME should be suitable for either 

a program or a person to locate the source. 

0 1 2 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| CNAME=1 | length | user and domain name ... 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Figure 4 CNAME: Canonical end-point Identifier [RFC1889] 

Seite 11 von 25



TIT 99 BGR 

In accordance to these prerequisites the CNAME item should have the format 

"user@host", or "host", if a user name is not available. The formatting should be done 

in accordance to the rules specified in RFC 1034 [RFC1034], RFC 1035 [RFC1035] 

and Section 2.1 of RFC 1123 [RFC1123] or the standard ASCII representation of the 

host's numeric address. 

4.3 RTCP Source Description 

RTCP requires every participant to send Source Description (SDES)-packets 

periodically, which can contain additional information about his system. In order to 

reduce overhead, several data sources (Synchronization Sources, SSRCs) can be 

described within one single packet. 

The unambiguous marker of each participant (Canonical Name, CNAME see chapter 

4.2) has to be given for each source, as it is important for linking different data 

streams of one participant. The other elements are optional, though, and should only 

be transmitted within larger intervals in order to save bandwidth. Their meaning is 

mostly self-descriptive. Short messages can be sent to all participants via the Short 

Message Element. In addition, an element for application specific extensions is 

provided. 

The available items are: 

o Version (V): 2 bits, which means Version of SDES. (Currently, version 2 is 

the latest) 

o Padding (P), length 1 bit: as described for the SR packet see chapter 4.4. 

o Packet type (PT): 8 bits, which contains the constant 202 to identify this as an 

RTCP SDES packet. 

o Source count (SC): 5 bits the number of SSRC/CSRC chunks contained in this 

SDES packet. A value of zero is valid but useless. 

0 1 2 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|V=2|P| SC | PT=SDES=202 | length | header 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

| SSRC/CSRC_1 | chunk 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 

| SDES items | 

| ... | 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

| SSRC/CSRC_2 | chunk 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 

| SDES items | 

| 

Figure 5 RTCP Source Description packet [RFC1889] 

The auxiliary seven SDES items as described in RFC 1889 are: 

o NAME: User name of the current session participant 

o EMAIL: Electronic mail address of the session participant 

o PHONE: Phone number of session participant 

o LOC: Geographic user location 

o TOOL: Application or tool name 

Seite 12 von 25



TIT 99 BGR 

o NOTE: Notice/status 

o PRIV: Private extensions 

4.4 RTCP Sender-/Receiver Report 

Each participant periodically sends Sender and Receiver Reports (SR, RR) to inform 

the other participants about the quality of the data transmission. 

Besides technical information such as flags and counters, the header contains the 

unambiguous marker or the data source (Synchronization Source, SSRC), which has 

generated this report. If packets have been sent from this source since the last Sender 

or Receiver Report has been sent, the header is followed by a Sender Info Block (in 

this case the packet is called „Sender Report“; without the info-block, the packet is 

called „Receiver Report“). The Info-Block contains a time stamp containing the local 

time when the report has been sent and an equivalent time stamp in the unit the RTP 

protocol uses for this stream. Additionally, the number of packets that have been sent 

since the start of the transmission is given. 

This is followed by a Report Block for each external data source from which this 

participant has received payload since the last Sender or Receiver Protocol has been 

sent. It contains the percentage rate and number of packets received from each 

individual data source (which is identified unambiguously by its SSRC). Furthermore, 

it contains the biggest sequence number received, the variance of the time slice 

between the arrival of two data packets, the time stamp of the last Sender Report 

received as well as the time since then. Additional application specific fields can be 

defined in profile specifications. 


o Version (V): 2 bits version of RTP (currently, version 2 is the latest) 

o Padding (P): 1 bit padding may be needed by some encryption algorithms with 

fixed block sizes. 

o Reception report count (RC): 5 bits, the number of reception report blocks 

contained in this packet. 

o Packet type (PT): 8 bits, contains the constant 200 to identify this as an RTCP 

SR packet. 

o Length: 16 bits, the length of this RTCP packet in 32-bit words minus one, 

including the header and any padding. 

o SSRC: 32 bits, the synchronization source identifier for the originator of this 

SR packet. 

o The second section, the sender information, is 20 octets long and is present in 

every sender report packet. It summarizes the data transmissions from this 

sender. 

The fields have the following meaning: 

o NTP timestamp: 64 bits, indicates the wallclock time (localized 

specified time-zone, non – coordinated time of sender) when this report 

was sent 

o RTP timestamp: 32 bits, corresponds to the same time as the NTP 

timestamp (above) 

o Sender’s packet count: 32 bits, the total number of RTP data packets 

transmitted by the sender since starting transmission up until the time 

this SR packet was generated. The count is reset if the sender changes 

its SSRC identifier. 

Seite 13 von 25



TIT 99 BGR 

o Sender’s octet count: 32 bits The total number of payload octets (i.e., 

not including header or padding) transmitted in RTP data packets by 

the sender since starting transmission up until the time this SR packet 

was generated. The count is reset if the sender changes its SSRC 

identifier. This field can be used to estimate the average payload data 

rate. 

o The third section contains zero or more reception report blocks depending on 

the number of other sources heard by this sender since the last report. 

These statistics are: 

o SSRC_n (source identifier): 32 bits The SSRC identifier of the source 

to which the information in this reception report block pertains. 

o Fraction lost: 8 bits The fraction of RTP data packets from source 

SSRC_n lost since the previous SR or RR packet was sent, expressed 

as a fixed point number with the binary point at the left edge of the 

field. 

o Cumulative number of packets lost: 24 bits The total number of RTP 

data packets from source SSRC_n that have been lost since the 

beginning of reception. 

o Extended highest sequence number received: 32 bits The low 16 bits 

contain the highest sequence number received in an RTP data packet 

from source SSRC_n, and the most significant 16 bits extend that 

sequence number with the corresponding count of sequence number 

cycles. 

o Interarrival jitter: 32 bits An estimate of the statistical variance of the 

RTP data packet interarrival time, measured in timestamp units and 

expressed as an unsigned integer. The interarrival jitter is defined to be 

the mean deviation (smoothed absolute value) of the difference in 

packet spacing at the receiver compared to the sender for a pair of 

packets. 

o Last SR timestamp (LSR): 32 bits The middle 32 bits out of 64 in the 

NTP timestamp received as part of the most recent RTCP sender report 

(SR) packet from source SSRC_n. If no SR has been received yet, the 

field is set to zero. 

o Delay since last SR (DLSR): 32 bits The delay, expressed in units of 

1/65536 seconds, between receiving the last SR packet from source 

SSRC_n and sending this reception report block. If no SR packet has 

been received yet from SSRC_n, the DLSR field is set to zero. 

Seite 14 von 25



TIT 99 BGR 

0 1 2 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|V=2|P| RC | PT=SR=200 | length | header 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| SSRC of sender | 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

| NTP timestamp, most significant word | sender 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ info 

| NTP timestamp, least significant word | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| RTP timestamp | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| sender's packet count | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| sender's octet count | 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

| SSRC_1 (SSRC of first source) | report 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 

| fraction lost | cumulative number of packets lost | 1 

-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| extended highest sequence number received | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| interarrival jitter | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| last SR (LSR) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| delay since last SR (DLSR) | 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

| SSRC_2 (SSRC of second source) | report 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ block 

: ... : 2 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

| profile-specific extensions | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Figure 6 RTCP Sender-/Receiver Report packet [RFC1889] 

4.5 RTCP Goodbye packet 

The BYE packet indicates that one or more sources are no longer active. If a mixer 

(have a look at chapter 5.4) receives a BYE packet, the mixer forwards the BYE 

packet with the SSRC/CSRC identifier(s) unchanged. If a mixer shuts down, it should 

send a BYE packet listing all contributing sources it handles, as well as its own SSRC 

identifier. 


o Version (V) 2 bits, currently version 2 is the latest 

o Padding (P) 1 bit, length: as described for the SR packet (have a look at 

chapter 4.4) 

Seite 15 von 25



TIT 99 BGR 

o Packet type (PT): 8 bits contains the constant 203 to identify this as an RTCP 

BYE packet. 

o Source count (SC): 5 bits the number of SSRC/CSRC identifiers included in 

this BYE packet. A count value of zero is valid, but useless 

0 1 2 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|V=2|P| SC | PT=BYE=203 | length | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| SSRC/CSRC | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

: ... : 

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 

| length | reason for leaving ... (opt) 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Figure 7 RTCP Goodbye packet [RFC1889] 

4.6 Application-defined RTCP packet 

The APP packet is intended for experimental use as new applications and new 

features are developed, without requiring packet type value registration. APP packets 

with unrecognised names should be ignored. 


o Version (V) 2 bits, currently version 2 is the latest 

o Padding (P) 1 bit, length: as described for the SR packet in chapter 4.4 

o Subtype: 5 bits allow a set of APP packets to be defined under one unique 

name, or for any application-dependent data. 

o Packet type (PT): 8 bits Contains the constant 204 to identify this as an RTCP 

APP packet. 

o Name: 4 octets A name chosen by the person defining the set of APP packets 

to be unique with respect to other APP packets this application might receive. 

The name is interpreted as a sequence of four ASCII characters, with 

uppercase and lowercase characters treated as distinct. 

0 1 2 3 

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

|V=2|P| subtype | PT=APP=204 | length | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| SSRC/CSRC | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| name (ASCII) | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| application-dependent data ... 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

Figure 8 Application-defined RTCP packet [RFC1889] 

Seite 16 von 25

Application scenarios Praxisbericht 4 


TIT 99 BGR 

5 Application scenarios 

5.1 Encapsulation of H.263 

As an introductory example, we will look at the encapsulation of H.263 video data 

into RTP packets. 

The RTP header consists of the fields that have already been explained in 3.4 and thus 

describes the payload transmitted (i.e. the H.263 video stream). The fields are defined 

according to the Payload Format Specification [RFC2190]. 

The H.263 payload header is followed by the video stream itself. The format of the 

video stream is also described in the Payload Format Specification. The ideal solution 

would be to divide the output of the encoder into packets immediately. For this 

purpose, the H.263 bit stream itself is stored including a picture header in the RTP 

payload area. It is possible to transport RTP data over UDP, TCP or ATM. 

IP header UDP header RTP header RTP payload 

Figure 9 RTP data over UDP in an IP packet [Chu97] 

5.2 Simple Audio conference 

In order to build up an audio conference, all participants must agree on a multicast 

address and two port numbers for the RTP and RTCP packets. As RTP cannot 

negotiate this, other means like SIP, Mail, RTSP, H.323 are needed. 

During the conference, each participant wraps the audio data stream he generates in 

RTP packets of a fixed size. The RTP packets are then sent to the multicast address 

and forwarded to all participants by the network. Using the additional information 

each RTP packet contains besides the payload, the receiver puts the packets back into 

the correct order, synchronizes them, identifies the encapsulated data format and thus 

synthesizes the payload stream for the play back. For this purpose, each data source 

can be identified via its unambiguous marker (Synchronization Source, SSRC). 

As the bandwidth available for each participant can vary during the conference, each 

station sends RTCP packets periodically, conveying statistics on the QoS. 

Besides, every participant sends Metadata in certain time slices (unambiguous 

participant marker, real name, e-mail address, actual position, software etc.). As a 

result, data sources can be linked to participants and everyone recognizes other 

participants entering and leaving the conference. For security reasons, it is important 

to know, that listening in is possible if this transmission of reports is suppressed. 

Seite 17 von 25



TIT 99 BGR 

Participant 3 

Audio 3 

RTCP-SR-Packet 

SSRC: Audio 3 

Send Statistic 

Receive Statistic 1 



Participant 1 

Audio 1 

PCM 

Audio 2 

Participant 2 

Figure 10 Simple Audio conference [Boo00] 


SSRC: Audio 4 

Datatyp: PCM 



PCM-Header 

PCM-Payload 

5.3 Multiplexing of several media streams 

If each participant generates a data stream of individual media types (e.g. audio and 

video in a video conference), these are transmitted in separate RTP sessions. The 

streams are not multiplexed via a field in the RTP header as the “payload type“ or 

synchronization source“, but via their destination address (IP-address and port). This 

has technical reasons, as the implementation of the protocols would become more 

sumptuous, if it was required to provide a multiplexing mechanism by itself. As a 

result, if a participant sends another stream, this requires another pair of ports (one for 

RTP and one for RTCP). During the whole communication, different network paths 

and resources can be used. In addition, the data processing can be implemented in 

different processes. Besides, participants who cannot dispose of sufficient bandwidth 

can decide to forego one medium completely and e.g. receive only audio. 

Although the video and audio signals in our example are transmitted in separate 

sessions, they must be linked for the play back. They are linked to a certain participant 

via the unambiguous marker that is conveyed regularly via RTCP; the streams are 

synchronized using the time stamp in each RTP packet. 

Audio 4 

Participant 4 

Seite 18 von 25



TIT 99 BGR 

RTCP-SDES-Packet 

SSRC: Audio 3 

CNAME: Participant 3 

PRIV: Carsten Griwodz 

Participant 3 

Video 3 Audio 3 

RTCP-SDES-Packet 

SSRC: Video 3 

CNAME: Participant 3 

PRIV: Carsten Griwodz 

Audio 2 

Participant 1 

Video 1 

H.263 

Participant 2 

Audio 1 

Video 2 


SSRC: Video 4 

Datatyp: H.263 



H.263-Header 

H.263-Payload 

Figure 11 Multiplexing of several media streams [Boo00] 

5.4 Mixer 

In some cases it can make sense to combine data streams coming from several 

participants and forward them as one single data stream. This is the task of a so-called 

mixer. 

If the bandwidth of a participant or a participant group in an audio conference is low, 

a mixer can be put at the starting point of this network segment. 

Atlantic Ocean 

USA Europe 

Mixer 

Mixer 

Participant 4 

Video 4 Audio 4 

Figure 12 Transatlantic session as example for low bandwidth connections 

It combines the streams it receives by decoding the audio signals, mixes them and 

encodes the resulting data in a more compressed form before it forwards them in a 

new stream and also synchronizes them. The receiver of the newly generated stream 

can be a single participant or another multicast group. 

Thus the mixer itself becomes a data source and registers as Synchronization Source 

in the RTP header of each packet. Since the original packets are lost, the mixer adds a 

list of Contributing Sources (CSRC) to each packet, so that the receiver knows, where 

the mixed data originally came from. 

Seite 19 von 25



TIT 99 BGR 

Participant 3 

Audio 3 

Participant 1 

Audio 1 

PCM 

Audio 2 

Participant 2 

Figure 13 Mixer [Boo00] 


SSRC: Audio 1 

Datatyp: PCM 



PCM-Header 

PCM-Payload 


SSRC: Audio 2 

Datatyp: PCM 



PCM-Header 

PCM-Payload 

Mixer 

SSRC: Audio M 

SSRC: Audio 1 

SSRC: Audio 2 

SSRC: Audio 3 

Datatyp: PCM 



PCM-Header 

PCM-Payload 

Audio M RTP-Data Packet 

5.5 Translator 

Another element that can be used in RTP networks is a translator. It can change RTP 

packets in several ways, but in contrast to a mixer, it maintains their identity. 

Translators can for example change the payload format of streams packet wise 

without mixing them in order to serve connections with poor bandwidth or 

participants using different technologies. Another application area is the bypassing of 

firewalls: e.g. if a firewall does not allow multicast packets, an outside translator 

transmits incoming packets via unicast to an inside translator which forwards them via 

multicast to the internal participants. 

Participant 3 

Audio 3 

Participant 1 

Audio 1 

PCM 

Audio 2 

Participant 2 

Figure 14 Translator [Boo00] 


SSRC: Audio 1 

Datatyp: PCM 



PCM-Header 

PCM-Payload 

Translator 


SSRC: Audio 1 

Datatyp: MP3 



MP3-Header 

MP3-Payload 

Participant 4 

Audio 4 

MP3 

Audio 5 

Participant 5 

Audio 4 

Participant 4 

Participant 6 

Audio 6 

Seite 20 von 25

What is Komssys? Praxisbericht 4 


TIT 99 BGR 

6 What is Komssys? 

6.1 Open Source 

Komssys [h:komssys] is the nickname for “KOM(S) RTSP/RTP streaming system”, 

while KOM is the nickname for KOM - Industrial Process and System 

Communication at Darmstadt University of Technology, Germany. This is combined 

with KOMS, the nickname for the Communication Systems research group at the 

University of Oslo, Department of Informatics, Norway. 

Because of its claim to be interoperable, based on open standards and build as state of 

the art technology, Komssys is released as GPL2 based Open Source Software. So 

anyone is able to use, redistribute and/or modify the source code to its own purposes. 

6.2 General Overview 

The KOM(S) Streaming System provides a server, a client, and a proxy cache for 

audio/video streaming. 

o The first and foremost encoding format that is used is MPEG-1 System. 

o The primary platform is Linux, but it also runs on AIX, Solaris, NetBSD, 

OpenBSD and Windows (Cygwin environment). 

o The whole project configuration is kde [h:kde] make and autoconf based. 

o It does not handle data in pull mode (i.e. HTTP and FTP) but uses RTSP/RTP 

(and Files). It uses RTSP as control protocol to communicate with possible 

streaming servers. The video data is transported via RTP. 

Figure 15 Client-server configuration overview [GZ01] 

o The proxy cache provides caching, patching [Bec01] and gleaning [Gri00] 

functionality. 

o It uses LC-RTP, which is an extension of RTP/RTCP, instead of simple RTP. 

LC-RTP enables the recipient to detect packet loss and complete contents by 

reordering the lost packets via Loss Collection (LC) for further details see 

[Jon99] and [The01]. 

o On all working platforms, a rudimentary, but functional streaming server is 

available. On AIX 4.3, the server is able to act as a replacement RTSP server 

for IBM's VideoCharger [h:IBMchar]. 

Seite 21 von 25

What is Komssys? Praxisbericht 4 


TIT 99 BGR 

o As Figure 15 shows, the architecture is based on a finite state machine and a 

graph manager for dynamically handling the stream handlers as described in 

[GZ01]. 

o The server can handle unicast as well as multicast sessions. 

o The client Graphical User Interface (GUI) is QT [h:trollqt] based. 

Figure 16 Screenshot of the QT GUI (currently version 0.2 is the latest) 

o The most recent version also supports RealPlayer 8 [h:real] in addition to 

PCMU- and MPEG-Systemstreams. 

o The greatest part of the project is documented with Doc++ [h:Doc++]. 

o For reasons of versioning and quality assurance the project uses IBM 

Teamconnection [h:IBMTea]. 

6.3 Other RTSP/RTP based systems 

Currently there are only a few well-implemented RTSP/RTP based streaming 

systems. Some of the RTSP based systems are listed at [h:rtsp]. Some RTP based 

streaming systems can be found at: [h:gstrm], [h:HGS] and [h:pmayo]. 

Seite 22 von 25

References Praxisbericht 4 


TIT 99 BGR 

References 

[Bec01] Ralf Becker, Konzeption und Implementation eines 

patchingfähigen Proxies für die KOM-Videostreaming-Umgebung, 

Studienarbeit, Technische Universität Darmstadt, März 2001. 

[Boo00] Matthias Book, Resource Reservation Protocol / Realtime 

Transport Protocol, Seminar Multimedia-Netzwerke, Universität 

Dortmund, Juli 2000. 

[Chu97] Chunlei Liu, Multimedia over IP: RSVP, RTP, RTCP, and RTSP, 

August 1997. 

http://www.cis.ohio-state.edu/~cliu/ipmultimedia/ 

[DB95] L. Delgrossi and L. Berger, "Internet stream protocol version 2 

(ST-2) protocol specification - version ST2+," Request for 

Comments RFC 1819, August 1995. ST2 Working Group. 

[GZ01] Carsten Griwodz, Michael Zink, Dynamic Data Path 

Reconfiguration, In: International Workshop on Multimedia 

Middleware 2001, October 2001. 

[Gri00] Carsten Griwodz, Wide-area True Video-on-Demand by a Decentralized 

Cache-based Distribution Infrastructure, Dissertation, 

Fachbereich Informatik, Technische Universität Darmstadt, Juni 

2000. 

[GZ01b] Carsten Griwodz, Michael Zink, Cache Placement Optimization for 

Video Delivery Systems. Technical Report TR-KOM-2001-04, 

Darmstadt University of Technology, April 2001. 

[Gud00] Gunnar Gudmundsson, Design of a Multiformat Capable Cache for 

Videostreaming, Diplomarbeit KOM-D-0121, Technische 

Universität Darmstadt, September 2000. 

[Kar00] Martin Karsten, Design and Implementation of RSVP based on 

Object-Relationships, Technische Universität Darmstadt, May 

2000. 

[Jon99] Alex Jonas, Integration von Loss-Collection-RTP (LCRTP) in eine 

VoD-Architektur, Diplomarbeit KOM-D-0093, Technische 

Universität Darmstadt, November 1999. 

[Mit96] Joan L. Mitchell, MPEG video compression standards, Chapman 

and Hall, 1996. 

[RFC1034] P. Mockapetris, Domain names - Concepts and Facilities, RFC 

1034, IETF, November 1987. 

[RFC1035] P. Mockapetris, Domain names – Implementation and 

Specification, RFC 1035, IETF, November 1987. 

[RFC1123] R. Braden, Requirements for Internet Hosts -- Application and 

Support, RFC 1123, IETF, Oktober 1989. 

[RFC1597] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot, Address 

Allocation for Private Internets, RFC 1597, IETF, March 1994. 

[RFC1738] T. Berners-Lee, L. Masinter, M. McCahill, Uniform Resource 

Locators (URL), RFC 1738, IETF, December 1994. 

Seite 23 von 25

References Praxisbericht 4 


TIT 99 BGR 

[RFC1889] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A 

Transport Protocol for Real-Time Applications, RFC 1889, IETF, 

Januar 1996. 

[RFC1890] H. Schulzrinne, RTP Profile for Audio and Video Conferences with 

Minimal Control, RFC 1890, IETF Januar 1996. 

[RFC2190] C. Zhu, RTP Payload Format for H.263 Video Streams, RFC 2190, 

IETF, September 1997. 

[RFC2205] R. Braden, Ed., L. Zhang, S. Berson, S. Herzog, S. Jamin, 

Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 

Specification, RFC 2205, IETF, September 1997. 

[RFC2474] K. Nichols, S. Blake, F. Baker, D. Black, "Definition of the 

Differentiated Services Field (DS Field) in the IPv4 and IPv6 

Headers", RFC 2474, IETF, December 1998. 

[RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, 

"An Architecture for Differentiated Services", RFC 2475, IETF, 

December 1998. 

[SDW92] W.T. Strayer, B.J. Dempsey, A.C. Weaver, "XTP: The Xpress 

Transfer Protocol", Addison-Wesley, Reading, Mass 1992, ISBN 

0-201-56351-7, more recent documents still available at 

http://www.ca.sandia.gov/xtp/biblio.html 

[Ste00] Ralf Steinmetz, Multimedia-Technologie: Grundlagen, 

Komponenten und Systeme,3. überarb. Aufl., Springer-Verlag, 

2000. 

[T1.627] ATM: ANSI Standard T1.627, Broadband ISDN - ATM Layer 

Functionality and Specification. 

[Tan98] Andrew S. Tanenbaum, Computernetzwerke,Prentice-Hall, 1998. 

[The01] Steffen Theiß, Konzeption und Implementierung eines Multiformatfähigen 

Proxycaches für die KOM-VoD-Umgebung, Studienarbeit, 

Technische Universität Darmstadt, Juni 2001. 

[WGP99] Wang, C., Goebel, V., Plagemann, T.: Techniques to Increase Disk 

Access Locality in the Minorca Multimedia File System (short 

paper), to be published in Proceedings of the seventh ACM 

Multimedia Conference (ACM Multimedia'99), Orlando, Florida, 

USA, October 1999. 

[ZGS01] Michael Zink, Carsten Griwodz, Ralf Steinmetz. KOM Player - A 

Platform for Experimental VoD Research. In: Proceedings of the 

6th IEEE Symposium on Computers and Communications, July 

2001. 

[ZJGS00] Michael Zink, Alex Jonas, Carsten Griwodz, and Ralf Steinmetz. 

LC-RTP (Loss Collection RTP): Reliability for Video Caching in 

the Internet. In: Proc. of 7th Int'l Conf on Parallel and Distributed 

Systems (ICPADS): Workshops, pages 281-286. IEEE, Piscatay 

Way, NJ, USA, July 2000. ISBN 0-7695-0571-6. 

Seite 24 von 25

HTTP References Praxisbericht 4 


TIT 99 BGR 

HTTP References 

[h:Doc++] http://www.linuxsupportline.com/~doc++/ 

[h:facpat] http://sern.ucalgary.ca/~kebrown/seng60904/wk4/factory.htm 

[h:gstrm] http://www.gstreamer.net 

[h:HGS] http://www.cs.columbia.edu/~hgs/rtp/ 

[h:IBMchar] http://www-4.ibm.com/software/data/videocharger 

[h:IBMTea] http://www-4.ibm.com/software/ad/teamcon/ 

[h:IETF] http://www.ietf.org/ 

[h:kde] http://www.kde.org/ 

[h:komssys] http://www.kom.e-technik.tu-darmstadt.de/kom-player/ 

[h:komrsvp] http://www.kom.e-technik.tu-darmstadt.de/rsvp/ 

[h:pmayo] http://www.projectmayo.com 

[h:trollqt] http://www.trolltech.com/ 

[h:real] http://www.real.com/ 

[h:RFC] http://www.ietf.org/rfc.html 

[h:rtsp] http://www.rtsp.org 

[h:sgixfs] http://oss.sgi.com/projects/xfs/1.0_source.html 

[h:strserv] http://www.streamingserver.com/ 

Seite 25 von 25

Olaf Beier Studiengang: Dipl. Ing. Informationstechnik - IfI

Create successful ePaper yourself

Delete template?

Save as template?