These findings made the whole trip worth while. We now know that we can connect across the world and transfer live photo, video and VoIP data to give anyone on the Internet remote access to field locations.
The Twinkle VoIP client connecting a SIP call from the OU to Paul in Nicaragua (7.5MB Video - click to view). (video capture from screen)
The attached video shows the point at which we got our first audio contact at the Volcano. At this point the video was running at a quarter PAL resoluction (160 x 120 pixels) at five frames per second and a contstant bit rate of 200 Kbps.
Having done our usual set of ping and iperf tests on the BGAN connection at the Volcano, we tried accessing the webserver and downloading a photo (see post on ‘Photo downloads with and without audio’). All was going well so next we looked at accessing the live video stream. We started with the lowest frame size and frame rate and explored a range of settings (see post on ‘Video resolution configurations’). Part way through these we started a VoIP call (which ran for the reminder of the tests – 27 minutes).
A video of Paul counting down from five to one on his fingers - the audio and video are quite well synchronised (1.5MB Video).(video capture from screen)
To test how the audio and video streams are performing we do a simple five-finger test. This involves counting down from five to one using your fingers. The idea behind it is simple – the audio and video streams are being run but different processes so they can lag or get out of sync – in fact we might expect this to happen as different encoding algorithms are being used to process the audio and video data. However, as you can see from the attached video they seem to be in sync, this makes conversation a lot easier. Paul’s video camera is running at half PAL (320 x 240 pixels) and 5 frames per second, with a constant bit rate of 200Kbps.
A clip showing the view point area at the top of the volcano beside a crater with venting gases (Video - 4.2MB).(video capture from screen)
Here’s a clip showing the video stream stretched to it’s limits when Paul goes walkabout with the camera. We’re using MPEG-4 video and in this clip the resolution of Paul#s camera was set to half PAL (320 x 240 pixels) with a frame rate of 5 frames per second and a constant bit rate of 200Kbps. Between key frames the MPEG-4 encoder sends the changes between consecutive frames. This means that when there is a lot of movement the image quality can drop as more information needs to be sent for each frame. In this clip we can see lots of examples where the quality drops while the camera is moving, but as Paul pauses on an object the quality of the image improves.
Live video streams at varying resolutions and frame rates. (video capture from screen)
We’ve used quite a few different video resolutions and a couple of frame rates. In all cases we’ve kept a constant bit rate of 200Kbps – Richard at callmonitor.com recommended this setting and it has served us well. Higher bit rates are probably possible, but we’re using a ‘Standard’ BGAN data link configuration (rather than one of the Streaming configurations) so we don’t really want to push our luck. The following two sets of clips show the performance we had for video at different camera settings. The first set show Paul in front of the camera with a flag, the second set show the points where we made the video link after changing the camera settings. In both cases the smoothness of the video relates to the camera’s frame rate and the clarify of the image relates to the camera’s resolution.
A clip showing of the effect of downloading a photo during an active VoIP call (Video - 15.8MB).(video capture from screen)
The final test we did with Paul at the volcano yesterday was to download a photo while talking on the VoIP phone at the same time. The router currently gives no priority (or Quality of Service preferences) to audio data – all data gets treated with equal priority. As a result while we’re filling the bandwidth with photo information the audio drops out. This could be solved by setting a Quality of Service preference for audio data. The image would then download slower, but the audio conversation would be maintained. Another option is to self regulate the conversation and keep quiet while waiting for downloads or other priority data.
The first data to come from Nicaragua over the BGAN - thumbnail images of photos.
Yesterday as well as talking on Skype, Paul and Carlos set up the BGAN terminal on the hotel roof and sent us back the first set of photos.
Paul’s Asus Eee PC 901 was running as a web server (using LAMPP). The Linksys WRT54GL he was using as a router gave him a local wireless network and registered the IP address it was given by the BGAN terminal (operating on modem mode) with our DynDNS service.
IAx Dual Server - Peer to User configuration for registering an Asterisk server with a dynamic IP with a static IP Asterisk server.
We’ve been developing VoIP support for ERA in the Portable VoWLAN Project (funded by JISC). JANET, through their Portable WLAN Programme, are helping us to investigate backhaul links so that our field students could access resources over the internet.
We’ve recently been using IAX2 to connect two Asterisk servers. Initially, the two Asterisk machines were on fixed IP addresses and all was working well. However, we wanted to arrange things so that one of the servers could be running on a netbook and connecting to the internet with a dynamic IP address (either through ADSL, a 3G mobile broadband connection, or a satellite link).
After a little hunting we came across the Asterisk – dual servers page on the voip-info.org wiki. Following their guidelines for users and peers we now have a (dynamic IP) field site Asterisk server that can connect and register with our (fixed IP) base server. Now anyone in the field can talk to anyone on the OU network.