Home  Objectives  Partners  Publications
Google

WWW mecca.noc.uth.gr
Technical Stumbling Blocks


 
mecca.noc.uth.gr Formal CoursesInstructor CoursesWeb-based Courses Presentation Technique 3 Lesson 2  

2. Technical Stumbling Blocks

Whenever technology is involved, there's always the chance of technical problems. In this section we look at some common technical stumbling blocks, and how to avoid them.

Bandwidth restrictions

Whenever you send or receive video, data is transmitted between you and the other party. The rate at which data is transferred is called the bandwidth of the connection, and this is typically measured in bit/s (bit per second) or kbit/s (kilobit per second.

Every network has an upper limit to the amount of data that can be transferred over the network at any given time. This is called the network bandwidth.

If the bandwidth of your video connection is, say, 768 kbit/s (which gives high-quality video and sound), whereas the network bandwidth is just 512 kbit/s, you exceed the capacity of the network, and the result is jerky video and distorted sound (this is known as packet loss: data packets are "lost" on the way from one party to the other).

The morale: make sure your network has sufficient bandwidth for video conferencing applications, which are fairly bandwidth-consuming.

Firewalls

Firewalls are devices (hardware or software) that monitor the traffic in and out of your local area network (LAN). A firewall can be configured to block certain kind of traffic, in an attempt to keep hackers at bay. If the firewall is configured to be very restrictive, it may not allow video traffic to pass through, and this would make video conferences impossible.

A firewall configured to allow video traffic to pass through. This configuration makes video conferencing through the firewall possible.

A restrictive firewalls which is set up to block video traffic. With this configuration, the video signal from the far end is blocked, and no video will be received from the far end.

Doing video conferences by IP connection (i.e. by a LAN or WAN connection) is a great asset, because there are no hourly costs associated with this type communication. Because IP communication is cheap (discounting installation costs), you should by default hold a video conference by IP, and only use ISDN if no IP connection is available.

If you need to use an ISDN connection (i.e. using the telephone lines), you pay by the minute, and you have to pay for each communication channel (à 64 kbit/s) you're going to use.

For instance: If you're holding a multi-part conference with 3 external parties (+ yourself), and each party has a 256 kbit/s connection (that is, 4 * 64 kbit/s connections), you'll have to pay for 3 * 4 ISDN lines. Assuming that the call rate is  0,10 euro per minute, the hourly costs add up to 3 * 4 * 0,10 euro/min * 60 min/hour= 72 euro/hour (!).

In short: costs associated with ISDN can be prohibitive. In addition to the hourly costs, subscription and installation costs need to be taken into account.

ISDN has one great advantage: it totally bypasses firewalls .

If you or the far end party is behind a firewall, IP connection may not be possible. A firewall is a device (either in the form of hardware or software) which monitors data traffic coming in and out of your network. Some firewalls are very restrictive and only allow certain kinds of data to pass through. In fact, some firewalls only allow traffic through port 80 (HTTP traffic), meaning you can get on the internet, but not much else.

Videoconferencing equipment uses a rather substantial range of ports, and if you're behind a corporate firewall, company policy may prevent the relevant ports from being opened (each and every open port is a liability, due to risk of network attacks from crackers).

The upshot of all this: don't put your videoconferencing equipment behind a firewall. Use a dedicated network segment reserved for video conferencing traffic. Having a dedicated network for your videoconferencing equipment also reduces the risk of overloading your network.

Dynamic vs. static IP addresses

Each and every computer (or video conferencing codec) connected to the internet needs a public IP address. Since there are a limited number of public IP addresses available, a scheme called DHCP (dynamic host control protocol) was designed. If you're on a network which uses DHCP, then every time you turn on your computer, you're assigned a public IP address from a pool of available addresses.

If you restart the computer, you're assigned a different IP address. This is called a dynamic IP address (i.e. one that changes each time you log on), as opposed to a static IP address, which never changes.

What would happen if your telephone number changed every time you switched off and on your mobile phone? Well, you would be able to make calls, but it would be impossible for other people to call you. For precisely the same reason, a video conferencing codec should not be assigned a dynamic IP address.

Always use static IP addresses for codecs.

Network address translation (NAT)

NAT allows many computers on the same network to access the internet using only one public IP address. If you have a broadband connection at home (e.g. ADSL), you're using NAT. Your internet service provider (ISP) provides you with 1 &ndash one – public IP address (this is typically a dynamic IP address; you usually have to pay extra for a static one). But it's still possible for you to have, say, 3 different computers in your home connected to the internet at the same time. In that case, the 3 computers share the public IP address between them, and a router keeps track of which computer made which particular request. This sharing of one public address is called NAT.

In this diagram, 3 computers share one public IP address. One of the computers with a dummy IP address (10.0.0.3 is not a valid public IP address) requests the webpage www.google.com. The request first goes to the NAT router, which provides a public IP address, and then the request if forwarded to the website. The response from www.google.com is then relayed back to the relevant computer.

 

Making video conferencing codecs work with NAT is not a trivial matter, however. It can be done, but that requires assistance from a computer administrator. The best solution is not to use NAT at all, and instead have one public IP address for each codec.

Limitations to video conferencing

It's easy to get excited about new technology, but don't forget that video communication is just a limited, stop-gap substitute for human contact. Don't ever think that video conferencing can replace physical meetings.

Bear in mind that video conferencing does have its limitations:

· If you're holding a video lecture, make sure your studies have realistic expectations to this new medium. They should be made aware that TV quality is still some way off, and that technical problems may occur

· Image distortions and sound imperfections should be anticipated and expected

· Unless rules of conduct are established, everyone ends up talking at the same time, and you can't get a word in edgeways. This is particularly important in multipart conferences

· Video conferencing lacks the intimacy and personal touch of a physical meeting

Handling technical difficulties during a video conference

If you hold a lot of video lectures, it's not a question of "if" technical problems eventually will occur; it's a question of "when". However, a technical glitch is no disaster, if you know how to handle it properly.

This video demonstrates how not to do it. The video should open in Windows Media Player when you click on the picture below.

VIDEO CLIP

DESCRIPTION

This video shows that even highly experiences lecturers are liable to panic in the event of technical problems, and this serves as an example of how not to do it

You simply can't expect your mind to be several places at once. That's what happened to the lecturer in the video: doing several things at once (concentrating on the lecture and solving the problem) just doesn't work.

Therefore: whenever technical problems occur, simply pause the lecture. Then identify the problem (or call a technician), solve it and resume the lecture.

 

copyright 2005-2007 MECCA Consortium webmaster