Honours Thesis
at the
Australian National University

Organisational and technical basis for community media streaming on a broadband metropolitan-area network.

Alexander Gray Pollard
Student 3099177

Dr Chris Johnson

June 2001


Broadband metropolitan area networks offer households high bandwidth internet access. Ordinary households should be capable of being the broadcasters of live broadband streamed content (audio, video etc), and not just its consumers. A technology is required to achieve this.

One solution is multicast-aware routers, such as those used by MBone. Such technology may not be available on a network or requires specialised software on the viewer's machine, inhibiting the take-up of the streamed content.

Instead, a community of household content broadcasters and other participants may contribute their surplus outgoing bandwidth to a common pool. This would enable streaming presentations to be transmitted to many more viewers than a single low-cost connection would allow on its own. A streamed presentation would be repeated by a tree or chain of household computers.

Software to achieve this is specified, designed and constructed, based upon published industry standards. How the software might work in a community is imagined and the circumstance under which participants could be paid for their spare bandwidth. The software's potential for enabling participatory media and evading internet censorship is examined.


Many thanks to my supervisor, Dr Chris Johnson, for his recommendations and for keeping me on track. Thanks also to Bob Edwards and the rest of the Technical Services Group for establishing and maintaining the facilities in the Software Engineering lab. Thanks to the folks in the Software Engineering lab for their help in solving the little technical problems that arise from time to time.

And thanks should go to TransACT for the opportunity which motivates this project.


Except where otherwise stated, the content of this thesis is my original work.

Alex Pollard



The project is entitled:
Organisational and technical basis for community media streaming on a broadband metropolitan-area network.

The software developed is Transmission Repeaters Enabling Virtually Bandwidth-Unlimited Streaming, abbreviated as TREVBUS.

Streaming media today

As greater bandwidth becomes available and costs fall, streaming media will become an ever more important area of the internet. Streaming media technologies are finding applications in video-on-demand and live broadcasts on digital TV networks. One such network is TransACT1, which is being rolled out in the ACT.

There are a number of streaming media technologies in widespread use. Notable examples are QuickTime, Windows Media, RealMedia and Shoutcast.

Project motivation

for the people
by the people

The media today seems closed and cliquey. It is not participatory, let alone democratic. It is commercially driven and too often sacrifices the public interest to corporate interest. The most successful economies and societies foster freedom of expression and a diffusion of power. This enables the replacement of those who do not deserve power.

But in the unregulated media, power tends to concentrate in fewer and fewer hands. There is an increasing need for this trend to be reversed.

The internet offers opportunities to provide alternative viewpoints and sources of information. Perhaps existing media can be prodded toward improvement or have their dominance undone. This is already starting to happen. People with common interests are engaging in discussions across the internet, by means of email, web-based forums, and it can be contended, by merely sharing music using software such as Napster or Gnutella.

However, there are barriers preventing ordinary people becoming the broadcasters of audio and video, rather than its mere consumers. This is especially so if one wishes to reach a large audience.

The barriers are cost, expertise and regulation:

TREVBUS aims to break these barriers down:

TREVBUS could create a community of content providers which, in order to expand its audience, must grow its broadcasting capacity by attracting participants. A virtuous circle of growth could be created, in contrast to existing closed and cliquey media organisations.

These issues will be addressed in greater detail in section 6.

Project aims

The aims of the project were:

It is not proposed to determine if the system successfully facilitates a growing community of content providers, since this will take longer than the project's time-frame. Such a large-scale test may occur after the project's completion.

Figure 1: a) Shows a chain of repeaters broadcasting a live streamed presentation from the generator, coordinated by a director. Likewise, b) shows a tree of repeaters.

Achieving the project aims

The project aims were achieved with a review of existing streaming media technologies (Section 2: Background); a detailed examination of both the streaming media software TREVBUS interoperates with (Section 3: QuickTime Streaming Server and Player), and the definitive protocol implementation TREVBUS is adapted from (Section 4: Real-Time Streaming Protocol reference implementation); the specification and design of the software, together with the required alterations made to the reference implementation (Section 5: TREVBUS) and finally, the issues that would need to be confronted for real-world use of TREVBUS (Section 6: Organisational issues).

The methodology for creating the software system was based upon IEEE standards of software requirement specification (SRS) and design (SDD) as defined by IEEE standards 830-1998 and 1016-1998 respectively.

To promote the adoption of the software, it is published under the GNU General Public License and requires the free software operating system, GNU/Linux, on participants' machines. The software is written to conform with the standard protocols for streaming media.

TREVBUS 1.0 and associated documentation can be found on the thesis CD and via the TREVBUS website:


Existing solutions

Presently multicasting is the usual way of streaming to many clients from a single low-bandwidth connection. The essence of multicasted streaming is that a presentation is allocated a unique multicast IP address. Those contributing to the presentation send the data to the IP address. The network routers they are connected to must be multicast aware. Their router then sends this data to all other routers involved in this presentation. Those viewing the presentation then receive data from the same multicast IP address.

Most internet routers do not support multicast. MBone (Multimedia Backbone) is a work-around that enables multicast-enabled networks to link together by tunneling multicast packets over the internet as normal unicast packets. Unfortunately, it relies upon multicast-capable routers being provided with the local network infrastructure2. In the absence of such routers, there is software from LIVE.com, which can take a multicast stream (MPEG or text) and re-transmit it as a unicast stream on the local network.

Another option is VideoLAN3 which emulates multicasting on a Local Area Network (LAN) using ethernet. But this is not useful on a metropolitan area network.

The technologies above solve the problems of connecting multicast sessions together across the world and on ethernets. But on a metropolitan network, one may wish to stream content

Broadband metropolitan area networks offer high bandwidth to households. However this alone is not sufficient to broadcast streaming content across the internet. Household internet connections have limited bandwidth, especially for outgoing traffic sent to the rest of the metropolitan network and elsewhere. The potential audience is limited to a mere handful.

The unused bandwidth of participants can be exploited by using their computers as repeaters. A new technology is required to enable households to become broadcasters by pooling spare local bandwidth. A chain or tree structure of repeaters could be established, multiplying or exponentiating the potential audience size. In figure 1 illustrates. The director and each repeater are processes running on computers in different households connected to a metropolitan network.

Organisational issues

Increasingly, discussion of internet technologies must include their effect on society. A prime example is Napster, the significance of which grew far beyond that of a mere piece of software. Accordingly, the social, legal and economic aspects of the system have been examined with a view to increasing the likelihood of the uptake of the software.

The issues to be addressed are:


There are a handful of alternative approaches to streaming media across the internet. In order to maximise the prospects for the project, a survey was conducted of existing streaming media technologies which might form the foundation of TREVBUS.

An examination was made of the underlying protocols used by these technologies. It turned out that a set of industry-standard protocols existed which were used in many of these technologies. The interoperability of these implementations was examined.

Software for streaming live presentations

There are a number of existing software packages for streaming and viewing content:

There are also a number of packages which do not make up a complete system but may work with other packages.

The protocols

The published internet protocols relevant to the project are briefly described below:

Real-Time Streaming Protocol

RTSP enables the orderly establishment, control and ending of streaming presentations between a server and a client.

The client sends requests and each request results in a response with the same sequence number from the server.

To establish a streaming presentation, the client will open a TCP connection on a pre-determined port. The client may issue a DESCRIBE request for the presentation. The presentation consists of one or more streams of data (perhaps audio, video, captions or other data), each requested with a SETUP request.

Once the presentation is setup, the client issues a PLAY request. The streams are then simultaneously sent separately by whatever transport protocols were negotiated.

The client can PAUSE a presentation, in which case the presentation can be again PLAYed without re-issuing the SETUP commands.

The client finally issues a TEARDOWN request, which ceases any current streaming. Upon receiving a reply from the server, the client closes the connection.

RTSP can handle both live streams and streaming-on-demand. PAUSE may have a different effect in each case - a PAUSEd live presentation would not be resumed where it left off.

In addition, RTSP features the REDIRECT method for pointing a client to another server for a presentation, the OPTIONS method for setting and negotiating parameters and ANNOUNCE for announcing miscellaneous information.

Session Description Protocol

The Session Description Protocol may be used by a Real-Time Streaming Protocol server to describe a streaming presentation in response to a DESCRIBE request.

The session description consists a meta-data such as copyright notices together with the number, name and transport protocol of each stream.

Real-time Transport Protocol

A non-reliable protocol for sending a logically continuous stream of data as a series of packets. Each RTP packet contains meta-data including the payload data type and a sequence number.

RTP has been designed to be independent of particular network and transport layers. When used with RTSP it is generally carried over UDP and IP.

Included in RTP is RTCP, the RTP Control Protocol. This protocol specifies how basic control information may be sent from the server to the client and from the client to the server, in order to optimise the transmission. The RTP and RTCP packets are sent in separate streams. This is usually achieved by having different UDP port numbers for each stream.

HyperText Transfer Protocol

The hypertext transfer protocol is used to reliably transport web pages and other associated data. HTTP is relevant to the project because, in order for the software to be used by the general public, there must be any easy way to start a streaming media session. As with most streaming media technology, sessions are initiated via HTTP.

Criteria for use in project

Making TREVBUS interoperable with as many existing streaming software implementations is clearly an important objective. Reasons include the likelihood of finding developer support, improving the prospects of TREVBUS becoming widely-used and the certainty that implementing within a well-defined specification provides.

The various real-time and session-description protocols above are clearly the best option. RTSP and RTP also have the advantage of not just being well-documented and widely used, but also of being well-designed, meaning that previous design issues have already been encountered and dealt with by the RFC authors.

One example of this is streaming multiple synchronised streams constituting a single presentation. This is critical for the ability to stream video with sound, an important objective for TREVBUS. Streaming technologies which use HTTP alone, such as Shoutcast, are able only to send a single stream to each client, limiting the broadcast to sound only.

QuickTime Streaming Server and Player

Interoperability of streaming software with TREVBUS

While a number of existing technologies use RTSP/RTP, they each only operate with another specific RTSP/RTP implementation. The only exception found was the ability of the RealServer to stream to the QuickTime Player.

TREVBUS had to be developed to operate with at least one implementation of RTSP/RTP.

Why QuickTime was chosen

Initially, the Real suite of software appeared to be the best option. This was because the client and server were both available for many platforms and Real is a popular choice for streaming media.

However, close examination of the interaction between the RealServer and RealPlayer revealed the use of hashing to authenticate clients. This was presumably done by Real to limit use of the free version of the server to just 25 clients.

The hashing algorithm presented a technical obstacle not worth dealing with. Such a mechanism served to ensure that the server software had a record of all clients playing the data it sent. This would have forced a change in the design of TREVBUS, because splitting a stream in to a number of streams for many clients without the knowledge of the server is central to TREVBUS.

TREVBUS could have been re-designed so that a control connection existed directly from the server to every client. However this would limit the scalability of TREVBUS merely for the conformance of the project to one commercial product.

Essentially, the hashing introduced far too much fear, uncertainty and doubt (FUD) in to the project. Even if the hashing mechanism was circumvented, there is no guarantee that other mechanisms did not exist which would prevent the completion of the project.

The clear alternative to Real was QuickTime. Apple's Darwin Streaming Server is open-source, which is a potential advantage, because risks are reduced by the ability to delve in to the server code to solve problems.

QuickTime was also a good option because the RTSP/RTP implementation is straightforward and simple. It uses fewer of the RTSP methods than RealMedia. Finally, RealMedia appears to use a proprietary transport protocol instead of RTP. It may be that this was a default and RTP could be used if required, but this was another issue not worth investigating.

In contrast, Apple has a ``no server tax'' policy, which means they QuickTime Streaming Server and QuickTime Player are not encumbered with authentication mechanisms. The project objective of running code was more likely to be reached with QuickTime, and stay reached as QuickTime changes.

The downside to QuickTime is that the player software is only implemented for MacOS and Windows. However, these platforms are popular. Also, by at least having a working implementation of TREVBUS, a foundation exists for adjusting TREVBUS to work with the Free Software implementations of RTSP/RTP which are presently under development.

Aspects of the Server and Player

The QuickTime implementation of RTSP/RTP is clean and simple. Idiosyncrasies were detected, however. These included:

Live QuickTime presentations can be joined at any point, however streaming video is initially degraded, as the current frame usually relies upon data from previous frames. To compensate for lost data a refresher frame is sent periodically.

The main limitation of the QuickTime format is that in order to stream a movie, it must first be ``hinted''. Hinting is done by software which must be purchased. Truly live broadcasts, as opposed to the broadcast of a looped movie, requires Sorenson broadcaster, also a commercial product. Nonetheless, the Apple's software has fewer technical limitations making it the most attractive product to develop with.

Real-Time Streaming Protocol reference implementation

Why it was chosen as the foundation

A number of options existed for implementing TREVBUS. The riskiest option was to base the project upon one or more RTSP or RTP libraries, such as the live.com libraries for RTP and the Danubio Streaming Architecture, which is under development. However, working software was preferred. It is all very well to base a project upon a software library, but it adds certainty to have the various pieces already working together.

There were two working open-source implementations on which to build the TREVBUS repeater. The RTSP Reference Implementation by Progressive Networks is an implementation of a draft version of RTSP. It it licensed under the GPL. The Darwin Streaming Proxy which comes with Darwin Streaming Server had the advantage of already being compatible with QuickTime Streaming Server and of being able to handle multiple simultaneous connections. However, it was licensed under the Apple Public Source License which meant the objective of publishing under the GPL would not be fulfilled were it used.

For licensing reasons, the RTSP Reference Implementation was chosen as the basis for TREVBUS.

The Reference Implementation consists of two parts, rtsp-player and rtsp-server. They complement each other. They implement RTSP version 0.6, a draft version. They do not interoperate with any other known RTSP/RTP server or player software.

What it does - requirements

The RTSP Reference Implementation is a simple player and server which interact. Once started, the server will accept one RTSP connection from the player software.

The player accepts commands from the user to open, get and play. open opens an RTSP connection to the specified URL. get sends a DESCRIBE request, followed by the SETUP request for a single stream. The play command causes a PLAY request to be issued to the server, which sends the requested file as a RTP stream.

The close command sends a TEARDOWN request to the server, which closes the connection and exits.

The implementation can only handle one session per server instance. There is a limit of one RTP stream for this session. The player and server can only handle a couple of types of audio data. Notably, the implementation does not support RTCP transmissions at all, either from server to client, nor from client to server. In this sense, the implementation can be seen as merely a RTSP implementation, not a complete RTSP/RTP implementation. However, this does not present a major obstacle to building a TREVBUS repeater based upon it. To repeat the RTCP stream in both directions, the repeater need only relay RTCP packets as if they were RTP packets.

How it does it - design

The RTSP Reference Implementation comes in five sub-directories, common, server, player, unix and win32. The functionality, however, is most easily described in modular terms.

It should be noted that when examining the code, that some of the RTSP specification changed during writing of the implementation, so that, for example, the HELLO request is now OPTIONS, the GET request is now DESCRIBE and the CLOSE request is now TEARDOWN. The Reference Implementation implements draft 0.6 of RTSP. The major difference between version 0.6 and version 1.0 is the first line of a RTSP message. The draft version placed a transaction sequence number at the end of the line. In version 1.0, the transaction sequence number is denoted by a CSeq: in the message header. So, for example:

DESCRIBE rtsp://foo.bar:7070/ RTSP/0.6 1
DESCRIBE rtsp://foo.bar:7070/ RTSP/1.0
Cseq: 1


Figure 2 represents the functional modules within the server. These are supported by a number of modules for message parsing, socket manipulation, and other basic functionality.

Figure 2: Functional modules comprising the RTSP Reference Implementation

The event handlers deal with RTSP input and output and are located in server/server.c. The event handler dispatch function implements a state machine. The three states are INIT_STATE, READY_STATE and PLAY_STATE. The state of the server decides what actions are taken in response to the various RTSP requests received. Figure 3 illustrates.

Figure 3: The state machine for the RTSP Reference Implementation server. Transitions are only shown for the valid events in the given state that do not lead to error conditions. In addition, DESCRIBE requests and OPTIONS requests and responses can be handled in any state but do not cause a transition.

Essentially, INIT_STATE is the state during which DESCRIBE and SETUP requests are received.

READY_STATE signifies that the server is ready to PLAY the presentation upon receiving a PLAY request. READY_STATE is entered after a SETUP request has been handled and after a presentation has been PAUSEd.

When the server is PLAYing a presentation it is in PLAY_STATE. During PLAY_STATE the server has an active streamer object which uses the scheduler module to schedule the transmission of RTP packets to the rtsp-player. When a TEARDOWN request is received, the server sends a reply and stops execution.


The rtsp-player shares most of its code with rtsp-server and essentially has the same design. The significant differences between the two are that the rtsp-player does not use the scheduler, has a different set of event handlers and has a reader function associated with each input file descriptor for handling the arrival of RTP packets.

The rtsp-player does not need a scheduler because all events are externally triggered, either by the user issuing commands through the user interface, or by the arrival of RTSP or RTP packets.

The event handlers for the rtsp-player are primarily concerned with issuing requests and responding to the replies which the rtsp-server sends. They are located in player/player.c. The state machine has same three states as above. When a TEARDOWN response is handled, the player closes the connection to the server, it does not stop executing. The state machine is illustrated in figure 4.

Figure 4: The state machine for the RTSP Reference Implementation server. Transitions are only shown for the valid events in the given state that do not lead to error conditions. In addition, DESCRIBE requests and OPTIONS requests and responses can be handled in any state but do not cause a transition.


What TREVBUS must do - requirements

The Software Requirements Specification for TREVBUS can be found in the appendices. In summary, the TREVBUS software has two roles:

The same piece of software accomplishes both tasks, though the network load may make it difficult to do both at the same time.

A user who wishes to view a streamed presentation will click on a hypertext link. This download a QuickTime reference movie from the TREVBUS director. The reference movie launches the QuickTime plugin in the web browser which accesses the RTSP URL supplied in the movie.

How TREVBUS does it - design

For a complete description of how the fully-implemented TREVBUS system would operate, see the Software Design Description attached.

The TREVBUS repeater in essence acts as an RTSP proxy cache and as a RTP multiplexer. The complexity in TREVBUS arises from the proxy and cache roles.

TREVBUS extracts essential information from the interaction between a downstream node (ultimately a client) and the upstream node (ultimately a streaming server). It uses this information to set up connections with subsequent downstream nodes.

The essential information extracted in each RTSP request and response and the use of that information is summarised below. Note that all requests come from downstream and all responses come from upstream, except in the case of the REDIRECT request, which comes from upstream. The CSeq is extracted from most requests and responses.

RTSP Message Data to extract Purpose
DESCRIBE request The RTSP URL requested To determine the director's URL
  The complete request The request may be resent upon
    a REDIRECT to another URL
DESCRIBE response The complete response Cache the response
    for the downstream session
  Number of streams in presentation For setting up stream
SETUP request The stream name Uniquely identifies the stream
  Downstream RTP/RTCP ports To create a stream multiplexer
SETUP response The complete response Cache it for downstream session
  The upstream IP address Send RTCP packets here
  The upstream port numbers Send RTCP packets here
PLAY request Nothing except CSeq  
PLAY reply The complete response Cached for downstream session
PAUSE request Nothing except CSeq  
PAUSE response Nothing except CSeq  
TEARDOWN request Nothing except CSeq  
TEARDOWN response Nothing except CSeq  
REDIRECT request The new RTSP URL So a connection can be made

In addition to extracting the above information, many pieces of information in the RTSP messages are altered to make the message appear to originate from the repeater. These changes are based upon the above data.

Alterations made to the RTSP Reference Implementation

The TREVBUS repeater is substantially based upon the rtsp-server and rtsp-player.

The most basic change made is to enable multiple simultaneous sessions. The rtsp-server and rtsp-player only supported a single session each at a time. All data structures pertaining to a session were altered. An array of SESSION_STATEs was implemented and global variables placed in struct SESSION_STATE. Unused functions which were present in the rtsp-server and rtsp-player were used to manage the multiple sessions.

The repeater is essentially rtsp-server and rtsp-player linked together, back-to-back. The server code is now the downstream side of the repeater (main/downstream.c) and the player code is the upstream side (main/upstream.c). The repeater responds to externally triggered events only, so the scheduler module is not used. The repeater listens for RTSP requests. The downstream side responds by creating a downstream session. A distinct upstream connection is then created to a server for the presentation specified in the DESCRIBE request, unless such an upstream session already exists.

The central functionality of most event handlers has been changed. Downstream event handlers parse RTSP requests only for essential details such as the sequence number of the request and other data relevant to the downstream session. Because the repeater merely repeats, it need not extract much data. For DESCRIBE, SETUP and PLAY requests the downstream session then passes the request to the upstream session request handlers, unless the upstream session has already handled such a request, in which case the downstream session uses a cached response from upstream. For PAUSE and TEARDOWN requests, the downstream session immediately parses the request and sends a response downstream.

The upstream request handlers have been changed. They now parse the requests sent from downstream for essential details. They also rewrite the requests, adjusting the request URL and such things as RTP/RTCP port numbers. This is in order that the server upstream ``believe'' that it is communicating with a client and not a repeater.

The upstream response handlers receive the replies from the server. In the cases of DESCRIBE, SETUP and PLAY responses, the upstream session merely parses for some details and then copies the response in to a cache.

The downstream response handlers receive the replies by reading from the cache when it is filled. Again, essential details are parsed and substitutions made so it appears the repeater is a server. The response is sent downstream to the client.



TREVBUS 1.0 has been written. To use it, a repeater process is started on each computer which will repeat streaming presentations. The port to which RTSP connections are made is specified in a configuration file. Each repeater may be configured to also act as a director for some particular streamed presentation. Such configuration information must be compiled into the software at present, though minor alterations would enable this information to be obtained from the configuration file.

The development process

The development process went fairly smoothly. It could have been made easier with better use of debugging tools. A very useful tool was ngrep, for monitoring network traffic between RTSP/RTP servers and clients. Project deadlines were generally met, and slippage was not a substantial problem since the plan provided for it. Revision Control System (RCS) logs were maintained and are available for inspection on the CD in trevbus_1.0_devel.tgz. In dealing with a multitude of files it may have been easier to use Concurrent Versioning System (CVS). The risk was that a bug might develop that required going back a number of versions. RCS is not suited to doing this with multiple files. Fortunately, no such bug arose.

Published protocols are useful

Chains and trees of any number of TREVBUS repeaters can be created by a TREVBUS director. This is achieved by means of standard RTSP requests and replies. This demonstrates the usefulness of well-designed protocols. Some kind of control channel was required in TREVBUS that is absent from less sophisticated systems such as ShoutCast. Without RTSP and the related protocols the development of TREVBUS might well have been a messy evolution as new requirements emerged one by one.

TREVBUS should not be restricted to operating with QuickTime. TREVBUS can be adapted to interoperate with Free Software RTSP/RTP servers and clients as they developed.

Quality vs Bandwidth

An important consideration in a discussion of TREVBUS is the quality of the transmission that can be achieved given the available bandwidth. To give a rough idea, the minimum bandwidth for video is around 35kbit/s. The sound is less than telephone quality and the small image changes at about one frame per second.

A QuickTime video having adequate sound quality with a smoothly displaying image 240 x 180 pixels is around 100kbit/s14.

Unfortunately, the compression required to achieve this must be done in real time. Unless a latency is not an issue, streaming video will require hundreds of kilobits of bandwidth per second for each session.

Taking TransACT as the typical metropolitan-area network, the usual outgoing bandwidth from a household will be 128kbit/s. This is only enough to repeat one session to another node on the network. This would require the bundling of the client and repeater software so that all clients of the streaming presentation are also repeaters15. This may inhibit the growth of the audience for the system, since clients would need to download specialised viewing software, which may be available only for some platforms.

However, for audio streams, the situation is different. A poor-quality audio stream only takes around 8kbit/s. A fairly good quality stream takes around 32kbit/s. With the typical household's outgoing bandwidth, around 3 such streams can be repeated.

TREVBUS is therefore best suited to streaming audio in current conditions. As more bandwidth becomes available at each household, video streaming will become more achievable.

Number of repeaters required

A calculation of the number of repeaters required to serve the audience is needed. Assume that a broadcast is to reach l client (leaf) nodes and that each repeater may transmit a presentation to m other locations on the network. So for n tiers in the repeater tree, starting with the bottom tier of repeaters, the total number of repeaters r equals

As the number of tiers increases, ratio of repeaters to clients increases. The worst case scenario is with n approaching infinity.

Then the ratio of repeaters to clients as a function of m is

For m = 2, the number of repeaters r approaches the number of clients l. For larger m, the number of repeaters approaches a particular fraction of l.

The implication of this is that binary trees (m=2) require a new repeater for each additional client. The pool of available repeaters would be drained very quickly. Only if each repeater node were also a client node would this situation be tolerable. Otherwise, m=3 is the minimum number of transmissions that should be made from a fully utilised repeater.

Future Features

There many improvements to be made to TREVBUS. Those of greatest priority are to

Another possibility is to port TREVBUS to set-top boxes used on broadband networks. Then TREVBUS would not require a home computer to be switched on all the time and so could be installed in many more households. This would vastly expand the virtual bandwidth available. In this scenario, TREVBUS could not just operate over IP, but also over ATM (Asynchronous Transfer Mode, which is used in many optic fibre systems). This might allow video of a vastly higher quality, perhaps up to 6Mbps, compared to less than 100kbps which is likely for the time being.

Organisational issues

The issues that would be encountered by a community of broadcasters, participants and viewers using TREVBUS need to be examined. For the software to be adopted in the ``real-world'', problems need to be identified and dealt with, while opportunities should be explored and exploited.


Many believe that liberating the masses from the grip of the existing media, things will improve by themselves. A critic of this view is Stephen L. Talbott who sarcastically wrote16 :

``So where the industrial tycoons and TV station owners blew it, unaccountably tempted by crass gain, the rest of us - once we grab power for ourselves - will save the day ... We're no longer going to let those TV moguls keep us down and reveling in smut.'' (p68)

Talbott is challenging the assumption that the wants of millions of individuals are more sophisticated than the media moguls assume. He takes the media corporation as an example of an organisation composed of many individuals and suggests the internet with millions of net-users is no different:

``We already have in the corporation (including the entertainment corporations ... ) an example of emergent, human-like behavior arising from myriad, complex unanalyzable interactions. Is that behaviour somehow more automatically responsible than the individual entrepreneur's? ... Did the old-fashioned neighborhood gossip network, with its extensive, peep-to-peer connectivity, automatically generate reliable news?

He rubbishes the notion of peer-to-peer information dissemination by associating it with ``gossip''. It is a loaded word, expressing a fear of social opprobrium more than a fear of untruth. In general, gossip is the best way of finding out what's going on in order to ask more questions. You're not obliged to believe gossip.

Talbott is assuming here that we should all have second thoughts about hearing something that may well be true, but lacks a reliable source. He raises the fear of ``irresponsible'' behaviour. Responsibility is his benchmark. But in a democracy, who is finally ``responsible''? The people, voting. So is Talbott saying he doesn't trust people? Would he rather trust profit-seeking corporations and moguls?

Talbott is showing undeserved faith in the corporate media. The corporate media has a great deal to lose from telling the truth. Corporatism lacks disinterest17. As media corporations merge and grow they assume interests beyond mere information dissemination. Often, rocking the boat is simply not in their self-interest or the interests of their employees.

So in response: The media, dominated by corporations and moguls, is decrepit and becoming more so. The issues that the media skips over and fails to address are often eminently news worthy, but just don't seem to make the headlines. One may then reasonably ask ``Why not try media without corporations and moguls?''.

The antidote is disinterest, and the best place to get that is from the broadest base possible, from the populace in general. Let the latent talent emerge from the crowd. Give power to the people so that they might become information disseminators.


Voluntary participation

In the first instance, using TREVBUS is voluntary, so potential participants would need to see benefits of reciprocally sharing their bandwidth. Such benefits are envisioned as:

Being able to stream live presentations to many viewers simultaneously at low cost.
The warm inner glow that comes from helping to smash monopolies in information dissemination.

Broadcasters could be individuals or community groups who want to stream music, talk-back audio, re-transmit weak or unavailable radio signals or perhaps even set up a TV broadcast with digital video cameras. The cost of participation must be low. The TREVBUS system requires use of the metropolitan-area network to be at close to zero marginal cost.

Audience interaction with live broadcasts would require a low latency connection between the generator and each user. The optimal latency would be achieved by having a tree of repeaters, and dynamically reorganising this tree after some users disconnect to reduce the number of repeaters between the generator and each user.

The expertise required to be a participant is not great, since one merely needs a computer connected to the metropolitan area network at all hours which has the repeater software on it. A broadcaster would need familiarity with video and audio streaming technology. A viewer need only be able to use the World Wide Web and be able to install components such as QuickTime Player.

It is expected that the first broadcasters and participants will be enthusiasts who will provide the critical mass required to build an audience and pool of virtual bandwidth. From then on, the average participant will hopefully become less and less technically literate as the opportunities afforded by TREVBUS become more widely appreciated.

In order to increase the broadcasting capacity of TREVBUS, broadcasters must recruit more participants to donate their bandwidth. In constrast, the corporate media tends to be closed. Mere citizens are invited in to the media club strictly on the terms the media demands. In contrast TREVBUS, instead of excluding by default, would include by default. As new participants gain access to the pooled bandwidth, they too can become broadcasters, and a virtuous circle of growth is established.

Some kind of central directory would be needed to show all the presently available broadcasts. This would serve to promote interest in TREVBUS, using the range of content to attract participants, broadcasters and a larger audience. A domain name has been registered for this purpose.

Economics of paid participation

However, there are opportunities to make the TREVBUS system more than voluntary, attracting audiences with high quality content and attracting participants with cash payments.

Many broadcasters would like to break in to new markets. In Australia, this is especially the case with radio. For instance, in the ACT, there has not been a new commercial FM license issued for over a decade.

A radio broadcaster may wish to transmit their signal in to this market. Without obtaining a license, they can stream their broadcast in to the households and workplaces in the ACT via the internet.

There are problems with this. The user must pay to access this high-bandwidth content. TransACT offers free on-network traffic, but off-network traffic will cost the user. This is a disincentive to listen.

As a solution to this, the commercial broadcaster could pay for streaming servers connected directly to TransACT, so that their listeners need not pay for listening to the broadcast. It is likely that this will be not be a high cost.

There may be a less expensive solution, for those whose budgets are tighter. Participants in TREVBUS could establish a ``bandwidth union''. The union would then negotiate with the broadcaster to obtain exclusive rights to repeat the digital broadcast in the ACT, in return for money. The money would be dispersed amongst participants as payment for their surplus bandwidth.

The bandwidth union, would then be able to expand its pool of available bandwidth by monetary incentive. The pool of bandwidth could also be put to use by participants for their own broadcasts. For this to work, the commercial broadcaster would have to pay for more pooled bandwidth than they would actually use. This could be seen as the ``profit margin'' of the bandwidth union, enabling the union members to carry out their own broadcasting.

However, there are risks for both the union and the financiers. For the union they stem from a dependence on funding.

Like a trade union, a bandwidth union should have sufficient espirit de corps to head off attempts to censor or divide.

The risk in attracting membership with cash is that of disappointing and losing participants if the money fails to come through. Talking about money may dull the imagination of participants, so that if there is no monetary motivation for remaining involved, no other motivation remains.

However, cash incentives and high-quality content could get attention and attract an audience for the system and gives participants more than just a warm inner glow to justify involvement.

Similarly, trade unionism is not based on pure selflessness, it is based upon enlightened self-interest.


The legal issues can be expected to stem from:

It should be noted that none of the following comes from a lawyer, these are my legal opinions.


Many users of TREVBUS may wish to set up their internet broadcasts of their favourite MP3s. A music company may then be annoyed because it is not receiving royalties for the broadcast of the music.

Who is then liable? The obvious comparison to make is with Napster. Napster is a directory service which enables music-lovers to locate and download MP3s. Napster, a private company, does not store the MP3s on its servers. Users themselves make MP3s available on their own computers by means of the Napster software, which informs the Napster directory of their location. Music-lovers use the same software to lookup their favourite songs on other people's computers.

Though a Napster user may be individually liable for breach of copyright, it is very costly to pursue millions of people individually. Instead, the Recording Industry Association of America pursued Napster, and succeeded in obtaining an agreement from them to filter out copyrighted songs from their directory.

Napster was therefore vulnerable because it was an identifiable target which was central to file sharing.

There are alternative methods of file sharing besides Napster, such as Gnutella18. Gnutella is a completely decentralised technology. Essentially, when a search is made for a file on Gnutella, a call is sent out to Gnutella servers known to the first computer. These servers send the search request on to their known neighbours, and so on. In this way, MP3s, or anything for that matter, can be located, without a need for centralised directory. Indeed, according to the Napster case, any internet directory service is liable in the same way as Napster if they give information enabling the illegal downloading of music. Gnutella evades this problem by effectively devolving the search process to millions of individuals, making legal remedies near futile.

For Napster and Gnutella, the location from which a file can be downloaded is identifiable. A technology called FreeNet is under development which would allow anonymous file sharing.

Like Napster and Gnutella, TREVBUS will not prevent the identification of a broadcaster. However, if a sufficiently large number of people became broadcasters with TREVBUS, pursing individual ``wrong-doers'' would be futile.

Essentially, TREVBUS broadcasters need not violate copyright. But if they do, their best protection is that they are individuals with personal wealth sufficiently small that legal costs would outweigh the benefits of taking action. There would be too many such individuals, so ``making an example'' of someone would be pointless.

Defamatory material

Defamation law is an undue restriction on public debate (at least in Australia). However, its effectiveness in preventing the truth emerging stems from the centralised nature of the media. Economies of scale have created a centralised media. Centralised media is vulnerable in that it presents easy targets for legal action, as with Napster. Large media companies have lots of money, and plaintiffs want lots of it.

New technologies offer the hope of decentralised, participatory media. The World Wide Web is an example, along with Gnutella, FreeNet and discussion forum Slashdot19. As with copyright, devolving power to individuals solves much of the problem.

Defamation law, in particular, presents a challenge to a system such as TREVBUS. In defamation law, it is no defence to be an ``innocent disseminator''. There is an expectation that the disseminator will have made a reasonable effort to assure themselves that nothing they disseminate is defamatory. This even applies to live telecasts. The case in point is Thompson v Australian Capital Television Pty Ltd & Ors20. In this case, a Canberra TV station broadcast a live interview conducted in the studios of the Nine Network in Sydney21. One of the legal issues was whether the Canberra station could be liable for a live broadcast. In their wisdom, the judges pointed out that the ``Today Show'' could reasonably be expected to entail discussions about people, and that therefore defamatory material might be present. The real difficulty that Australian Capital Television faced was the lack of an agreement with Nine which would indemnify them against the civil claim.

Defamation law reform is needed, but so is the indemnification of TREVBUS participants.


TREVBUS participants whose computers are used to illegally repeat copyrighted or defamatory material need assurance they cannot be held liable. To this end, broadcasting via TREVBUS would require an agreement to indemnify participants whose computers are used as repeaters against civil claims.

Such an agreement must be enforceable. The best way to do this is by contract. There are various possible parties to such a contract, including myself as one of the software's copyright owners (albeit under the GPL). However, I do not want to have to enforce such a contract. The best option is for the contract to be between participants. So, upon running the TREVBUS software, the following legal agreement appears:

By running TREVBUS (this software and past and future revisions thereof), you understand that any person responsible for the use of TREVBUS to direct the broadcast of a presentation indemnifies you against any civil claim arising from such a presentation, in exchange for their use of your bandwidth and/or equipment for the broadcast.

Reciprocally, by directing the broadcast of a presentation by means of this software, you agree to indemnify all persons responsible for the operation of a TREVBUS repeater against all civil claims arising from the presentation, in exchange for the use of their bandwidth and/or equipment for the broadcast.

Such civil claims could include:
  • Copyright violation
  • Defamation or libel

Unfortunately, this may not be adequate. It is technically possible to cause a client to connect to a repeater and request a presentation that is not being directed by the current version of the TREVBUS software. In this situation, there is no indemnification. The legal question is whether the person responsible for the repeater could claim to have acted responsibly in allowing their computer to be used to disseminate the presentation.

As a precaution against this, TREVBUS would require a mechanism for ensuring that the persons responsible for a node, which a presentation is requested from, are contractually bound. This could be a check against a list of IP addresses or some kind of authentication between the TREVBUS programs.

Such a system may also be required to disclaim liability for the broadcast of a presentation in certain jurisdictions where the law is harsher. This may involve some kind of negotiation process between TREVBUS nodes.

Another complicating factor is that if different versions of the software are used, with different indemnification agreements, what contract is enforceable? A practical solution to this issue is to have TREVBUS users form an association in their locality and hammer out all these issues face to face.

All in all, it would be much simpler if the law itself were changed so that innocent dissemination is a defence.

Criminal speech

If a broadcast via TREVBUS is deemed to be criminal (perhaps incitement to some crime), is a participant liable if their computer is used to repeat material? Almost certainly not if they have no knowledge of the material. This is the most likely scenario if the streamed content is live. However, if a participant had foreknowledge of the criminal speech, there might be an issue. But in general, criminal law requires the finding of a guilty mind - this higher standard of proof makes TREVBUS participation safe from the speeches crimes of other participants.

Future versions of TREVBUS may enable a participant to prevent a particular broadcaster from using their repeater to transmit presentations.

Internet censorship laws

You've gotta break the law
to make the law.
In 1999 the Australian Parliament passed a unique law that purported to restrict the availability of restricted material online. The law has two main components:

an industry code of practice which obliges internet service providers to make filtering software available to their customers
a ban on restricted material being served from computers in Australia.
The first point is not relevant to TREVBUS. The second is not relevant either, as long as a TREVBUS broadcast is not stored by any means prior to transmission - that is, completely live material is exempt from the laws. The relevant section of the Broadcasting Services Act 1992 (amended 1999) is below. In schedule 5 we find the following definition of ``Internet content''22:

Internet content means information that:

(a) is kept on a data storage device; and
(b) is accessed, or available for access, using an Internet carriage service;

but does not include:

(c) ordinary electronic mail; or
(d) information that is transmitted in the form of a broadcasting service.

Point (a) uses the term ``kept'' rather than ``exists'', implying some kind of permanence. Thus, live streams broadcast via TREVBUS are not ``internet content''.

Some argument could be made about the exact meaning of (a) and (b) taken together. If a third party records it a live presentation, does it become internet content, and is it therefore not exempt? However, the use of the present tense for both (a) and (b) seems to preclude this. (c) and (d) are shown for completeness but (d) probably does not exempt TREVBUS.

The live transmission loophole opens up some very interesting possibilities for live streaming content. And because TREVBUS is less restricted than other internet technologies in Australia, viewers and participants should be attracted to TREVBUS, perhaps bringing media by the people for the people, to the people.


A piece of software has been designed, specified and implemented which enables householders to become broadcasters of streaming video and audio. The software uses widely-used standards for maximum compatibility. The present implementation only supports QuickTime but as other RTSP/RTP servers and players become available, TREVBUS can be adjusted to support them.

A detailed examination of RTSP and RTP implementations was made in preparation for the construction of the software. It was decided to implement the software by re-working existing Free software, the RTSP Reference Implementation by Progressive Networks.

Various aspects of the system as it would be used by a community have been explored. A philosophical basis for community media has been presented. Ways of motivating participation in the system have been outlined. In particular, TREVBUS creates the possibility of an expansive and inclusive media. The possibility of monetary incentives for participation are slim, but are worth trying to implement.

The legal aspects of the system are examined. Indemnification of participants by broadcasters is required to ensure the viability of a TREVBUS system. Live content broadcasting by means of TREVBUS also subverts Australian internet censorship law. Only by challenging the existing moral order will advances be made.

The project is, appropriately, part of a degree in Systems Engineering. Not just have technological issues been explored but also the critically important organisational issues. A technology cannot be completely understood or designed without exploring the social aspects of its use.


Specification of TREVBUS

Design of TREVBUS

Original project plan

About this document ...

Organisational and technical basis for community media streaming on a broadband metropolitan-area network.

This document was generated using the LaTeX2HTML translator Version 98.1p1 release (March 2nd, 1998)

Copyright © 1993, 1994, 1995, 1996, 1997, Nikos Drakos, Computer Based Learning Unit, University of Leeds.

The command line arguments were:
latex2html -split 0 -no_subdir -no_navigation thesis.tex.

The translation was initiated by Alexander Gray Pollard on 2001-06-28


... TransACT1
... infrastructure2
... VideoLAN3
... networks8
... kasenna.com9
... XMMS11
... 100kbit/s14
Such as the sample movie that comes with Darwin Streaming Server
... repeaters15
This is what FatCast proposes. See http://fatcast.sourceforge.net
... wrote16
Stephen L. Talbott,The Future Does Not Compute - Transcending the Machines in Our MidstO'Reilly & Associates, Inc, Sebastopol, 1995
... disinterest17
John Ralston Saul, The Unconscious Civilisation, Penguin Books Australia, 1997
... Gnutella18
... Slashdot19
... Ors20
... Sydney21
The reason for pursuing Australian Capital Television is that the defamation laws in the Australian Capital Territory are particularly favourable to complainants
... content''22
... RFC206823
... RFC188924
... RFC232625
... RFC232726

Alexander Gray Pollard