The Matterhorn Webcast

A Technological Perspective

The Challenge

1. To use a mix of 'genuinely-domestic-level' technologies to bring Lorenzo's climb right here to us (wherever we are in the world). So no satellite or video phones, a genuinely tight budget and very short timescale!

2. To test (in extremis) Macromedia's new MX serving of AV technologies.

Critical Research Topics

Presence - Where are you (physically and virtually)? And what "state" are you in?

Telepresence - Can you and I share this experience over a distance?

The Technologies

The Phone
What is it? A Nokia 7650 GSM/GPRS phone with an integrated camera. A new-to-the-high-street item costing about 200gbp.
How does it work? Lorenzo will take a picture or two before he makes a voice call and mail them in to the server. If he labels the picture (in the email subject line) with his height above sea level (via a pre-agreed code) then the Flash movie can not only show the latest picture but put a dot on his current map location. The Phone Server
What is it? A PhonePro Server - running on an Apple Macintosh with a GeoPort modem and executing sundry AppleScripts to communicate with the voice processing and file transport apps.
How does it work? Lorenzo calls in, the phone server will pick up his call. If someone is in the lab, then you will hear the conversation, otherwise you will just hear the 'audio diary' of the climb. The call will be fed to the live broadcast Flash 6 client, and converted for instant-replay. After he hangs up, the phone server will produce an MP3 version and upload it to the web server. So even if you miss the live call, you can hear what he says within seconds of him having said it, anyway!

The Client
What is it? A Macromedia Flash 6 movie which can handle both external data and connections to the Macromedia Flash Communication Server MX.
How does it work? The Flash movie picks up data, like location, latest pictures, latest audio messages and displays it dynamically and automatically. Flash allows us to do all this in a single application and handle the data flexibly and quickly.
To speed development we decided to make use of Macromedia's free pre-built Comunication Components.
These are drag and drop items that allow a connection to be made with a suitably configured Macromedia Flash Communication Server MX.
Five were chosen for this project:
• A log on component
• A chat component
• A colour picker component
• A status component
• A streaming audio/video component
These are relatively easy to use in their standard format, although somewhat harder to re-configure or re-skin to any major degree, possibly because we were using the available downloads. A simple reworking of some of the component's assets was however used to conform to the overall page design. The streaming component was positioned off-stage as only it's audio streaming function was required.
A painting of the Matterhorn formed the background to the Flash movie. Positioned on this, along the proposed route, are a series of movies containing a 'dot' and a button. These only appear if a picture has been sent from the location they mark and provide the user with a way of viewing the pictures in context. The url's to the pictures are dynamically updated for each button. The latest photograph sent from the Matterhorn is inserted at the time the user first loads the page. If an older photograph is chosen to be viewed by the user, a button appears allowing the reloading of the latest picture. This is achieved by comparing the picture's file name which is 'time-stamped'.
The live audio message from the Matterhorn is streamed straight into the browser via the Flash component. It is recorded at the same time 'at source' and an MP3 file created. This information is sent to the user's Flash movie. When new sound information is received, a button with the correct url appears in the 'Audio Replay' submovie. This movie contains a dynamic list of the ten most recent sound files. When the user clicks on a button, the main streaming audio is muted and the recording streams from the server. This movie also contains a 'Mute All' button for the user's convenience.
The dynamic nature of the Flash content is 'driven' by the periodic request for a string of variables. If a 'key' variable has altered within this file, then all the relevant variables and sub-movies contained within the Flash are updated.
The result is a good 'fit-for-purpose' application created within the project's time constraints, greatly aided by the Macromedia Communication Components. Given more time the interface could be made more 'flashy' and 'animated', although of course the user would have to download the extra graphics...

Chatlogger and Broadcaster Flash Movies
What is it? Two Flash movies running in the background back at KMi.
How does it work? The Chatlogger Flash movie monitored the 'Chat' progress. When a predefined number of lines of text was reached an auto save facility was triggered to save the chat text to the chat log file that was accessible as a html page from a link on the main web page. It also provided a way to clear unwanted chat.
The Broadcaster Flash movie containing suitable Macromedia Communication Components, took the live audio from the telephone and 'broadcast' it those listening on-line. Interestingly we had to remove the 'Chat Window' Component from this movie as its inclusion interfered with the audio stream making the sound break-up. The AV Server
What is it? A Macromedia Flash Communication Server MX (maximum of 500 connections).
How does it work? The Server handles all the communication data between the clients and server. In this particular project five of it's component features were utilized; the live sound broadcast, the client logon process, the chat facility, the chat colour picker and the connection information icon.

The Web Server
What is it? An Apache web server with PHP installed, running on a Windows 2000 Server.
How does it work? Most of the clever stuff on the server is driven by PHP scripts which permit the dynamic generation of web pages and the live updating of the client's Flash movie with the latest picture and audio status.
The server is configured to regularly run a PHP script which retrieves emails from the webcasts email account. If a new email has been received with a picture attached (i.e. sent from the Nokia 7650 phone which Lorenzo is using during his ascent of the Matterhorn), the PHP saves the image, creates thumbnail copies, and updates a status text file. The client's Flash movie regularly accesses another PHP script on the server, which gathers together the latest information (i.e. pictures, audio file lists etc) and returns this to the client's Flash movie.
Another function performed by PHP scripts is to create the 'Chat History'. A Flash movie was created specifically for this purpose. This Flash movie is connected to the webcast via the Flash Communications Server MX, and as a result receives all the Chat messages like any normal client, however, it also regularly calls a PHP script with the latest messages. This PHP script appends the new messages to a text file to create a permanent record of the chat.
Other PHP scripts are used to dynamically generate the 'Gallery' of photographs, 'Phone Replays' and 'Chat History' web pages.

Some obvious questions

Why didn't we use video?

Are you kidding! Video over GSM!?! Not in my current dreams (yet).
Seriously, the data-rate we are likely to get for the piccies will mean that each photo will take maybe 1-2 minutes to reach us ... we need all the available datarate of live for voice. We werent confident that GPRS will work on the mountain (keeping our fingers crossed about GSM connection!) and we aint holding our breath for 3G features ... but one day ...

Why didn't we use the classical KMi Stadium technologies for this event?

For the challenge! We thought that, if we were going to do this, we should try to stretch Macromedia's new MX technologies - which are actually closely related to the systems we have based our own techhnologies upon. In the MX release of their servers, Macromedia have stressed the (smaller scale) multi-party features - esp. plug and play multi-party audio/video. This is potentially so cool, that it was worth setting aside our own scalable broadcast systems for this gig, to see what MX could do for us - right out of the box! Actually, in our development we found that this particular application was much more suited to our own KMi Stadium architecture, but we persevered and are extremely pleased with the results!

Why the Nokia phone?

It is a single unit (very important not to muck about with lots of fiddly extra plug-together pieces for a climber), released in the UK the week before the actual climb. The lens aint great - but hey, it is a phone! - and we felt that good lighting up the mountain might compensate for this. Also, it is robust, good battery life and simple to use - especially, it involves remarkably few button-presses to send a photo. Definitely, a must have piece of kit - which I can already think of a dozen other cool uses for - (I just need to figure how to switch off that annoying and cheezy photo-click sound it makes when you hit the capture-photo button ;-). Initially, I liked the 'totally handsfree with bluetooth-headset' concept for 'talking with ones hands full of rock'; but then this just sounded way too dangerous! So we compromised, and asked him to only consider using it when he could relax and was quite, quite safe!

Why use a Phone Server?

Lorenzo will be setting off up the mountain (and have some interesting things to say) when all of us back home will be asleep! We need to capture what he is up to on the server (for when we wake) AND send it out live (automatically) for those folks in the world who aint as sleepy as us. We have successfully used a variety of phone-the-web servers for other projects such as 'read the news' systems for Rostra News and most especially for 'yearbook entries' in the Virtual Degree Ceremony. So a system that could answer the phone for Lorenzo, take his chat and pump it to the live server plus archive it to the web, was a piece of cake.