MultimediaInternet Broadcasting and Distributed Conferencing

Lecture 2

Internet broadcasting and TV

Terrestrial and satellite TV – broadcasts to large audiences– has “economy of scale”– provides popular programmes and events

Internet broadcasting (IB)– allows small events to be broadcast– can reach small but global audience – provides low-cost, user-level broadcasting

What is out there?

Internet broadcasts (Audio and Audio/Video) are now common practice

Some are – well-designed– easily accessible– widely available

Others are difficult to access and view/hear

Access to IB In general all users can access IB shared links cause capacity shortfall variable capacity broadcast lowest quality at 28.8 kbps

– small picture– low frame rate– low bandwidth audio

Home-based users need special attention

The home-based user

low bandwidth connection shared links between Internet service

providers (ISPs) limit bandwidth IB allows home user to be active in

“production” - not solely consume! Quality of Service (QoS) is dependent

on the provider - there are few user options

Software

Many now available– CuSeeMe/WhitePine Video conferencing – Real Networks – RealPlayer G2– Microsoft Media Player – Quicktime

Either– two way communication (conferencing)– one-way communication (broadcasting)

Real Systems

rtsp or http– rtsp - real time streaming protocol (RFC 2326)– works over TCP or UDP (and could use RTP)– uses URL rtsp://host.domain/dir/file as in http– rtsp and request channel separate

– (out-of band control)

– port 554 is standard– Uses Real’s Surestream encoding

Surestream (RealPlayer G2)

Embeds a number of bit-rate versions in an encoding

Rates from 28.8 kbps up to corporate LAN capacities

Switches rate based on network congestion/capability– i.e. Adaptive/dynamic streaming of data

Servers

Broadcasting is generally done with servers

Servers (Reflectors in CUSeeMe) allow– a number of users to connect to a single

source– links to other servers to reach

larger audience geographically-dispersed audience

Infrastructure issues

Configuration of servers and inter-server links determines network QoS for individuals

Home-based users can choose server but a (network) local server usually performs best

For broadcasting to be an important tool the delivery infrastructure needs careful design.

Example events Concert broadcast

– Wolverhampton and Aberystwyth Universities joint venture (concert in Machynlleth, Wales)

– used CUSeeMe with reflectors in– UK (3), France, US(2), and Australia

OECD Seminar - Turku, Finland– broadcast by EUNet– linked servers in various EU countries

Infrastructure models

Various models Each has its own application area Choice depends upon

– QoS required– Audience– Network operator participation– other factors

Single server

Server

User

User

User

User

User

ISP netcasting

Server

Users

Users

Users Users

User

Server Server

Server

Event

ISP domain

Linked individual sites

Server

Users

Users Users

User

Server Server

Server

Event

Domain A

Domain B Domain C

Co-operation agreements

Server

Server Server

ServerDomain A

Domain B

Domain C

Permanent links

Working practices

Event-dependent– Video/Audio need to be useable – and should account for

small picture size limited bandwidth typical user terminal

New technical solutions may be needed Higher bandwidth networks will help

Protocols

Current protocols are mainly not optimised for use in broadcast environments

Use of multicasting can help Reservation protocols will improve QoS Home-based users (in particular) are

reliant on many outside factors to provide good QoS.

Multicasting Depends on multicast routers (see

RFC 1112) Routers maintain multicast groups and

deliver messages to individual hosts Cuts down on duplication of messages

except for low-use wide-spread connections Multicasting is useful if audience is grouped

Reservation protocol - RSVP

RSVP (RFC 2205) Uses control messages to reserve capacity along a TCP

connection Works with TCP/IP - IPv4 and v6 RSVP provides transparent operation through routers that do

not support it. RSVP makes resource reservations for both unicast and many-

to-many multicast applications,

– adapting dynamically to changing group membership as well as to changing routes

RSVP is receiver-oriented,

– i.e., the receiver of a data flow initiates and maintains the resource reservation used for that flow.

RSVP characteristics summary RSVP is simplex, i.e., it makes reservations for

unidirectional data flows. RSVP maintains "soft" state in routers and hosts,

providing graceful support for dynamic membership changes and automatic adaptation to routing changes.

RSVP is not a routing protocol but depends upon present and future routing protocols.

RSVP transports and maintains traffic control and policy control parameters that are opaque to RSVP.

RSVP provides several reservation models or "styles" to fit a variety of applications.

Future use

Higher bandwidth will help but – it will be more expensive– not available to all– inter-ISP links are also factors in QoS– infrastructure and configuration is still

relevant Wider use will use available bandwidth

– so broadcasts need planning

Other areas

Computer supported co-operative work (CSCW)

Teleteaching Video conferencing

Conferencing

Conferencing or two-way video/audio introduces new problems.

Many possible solutions ISABEL architecture allows

– Distributed conferences– Multi-point access for send and receive

ISABEL

A management platform– Scalable architecture covering large

geographical areas and many sites– global event management from a single

point– services can be defined and tuned– heterogeneous networks

Isabel service model

Type of service,

site, role etc

Network configuration etc

ISABEL sites

1. Interactive site– send and receive, audio, video and data

2. Main Interactive site– An IS but with special privilege e.g bigger screen.

(It may have a local audience)

3. Control site– the most important site which controls the event

4. Watch point– receive-only site

ISABEL layered architecture

Typical configuration

Summary Different models of broadcast infrastructure have

been proposed with different application areas Home-based users rely on ISPs to provide QoS New developments may not be the solution Providers should develop infrastructures to

support broadcasts to (and from) homes Conferencing is a much more complex activity

References

Broadcasting– RSVP - RFC2205 (ietf web site)– Multicasting - RFC 1112 (ietf web site)– Sloane A (2000), “ Infrastructure issues for Internet

broadcasting to home-based users”, in Beardon, Munari and Rasmussen (Eds.), “Computers and Networks in the Age of Globalisation”, Kluwer, Boston, ISBN0-7923-7253-0, pp187-196

Conferencing– Robles et al “Distributed Global Conferences over

heterogeneous networks” in Sloane A and Lawrence D (2001), Multimedia Internet Broadcasting, Springer, London Chapter 4