Videoconferencing with schools abroad

Tim Arnold and Steve Cayley have been working as lead consultants on the TDA’s Videoconferencing project which has involved the setting up of videoconferencing systems in schools in England, Germany, France and Spain. Initially these systems were connected using ISDN however more recent systems have been set up for IP videoconferencing using broadband connectivity.  

A number of technical issues have arisen during installations. This document outlines the requirements for IP based videoconferencing and is designed to inform technical engineers who support schools locally. The aim is to raise issues early in the process and hopefully simplifying installations.

IP Based Videoconferencing

• The project has been setting up dedicated, group, videoconferencing systems. To date these have been Polycom Viewstations (see www.polycom.com) however the information contained in this document would generally apply to any make of system. The systems are self contained and do not require the use of a PC.
• The systems are IP devices and connect directly to a local LAN in the same way as a desktop PC or laptop using standard CAT 5/6 Patch Cable with RJ45 termination.
• The system can be used anywhere on the LAN provided it is a Switch based LAN and congestion is not a problem on the network.
• Configuration of the system includes standard IP settings including IP Address, Subnet Mask, Gateway and DNS.

Bandwidth

• Dedicated IP based videoconferencing systems can link at any speed from 128kb/s up to 1.5Mb/s and beyond.
• Actual bandwidth will be constrained by a number of factors including:
• Broadband bandwidth available
• Broadband contention
• Activity on the LAN
• Videoconferencing systems usually establish calls with equal incoming and outgoing bandwidth. This can be a problem with ADSL where the Upstream bandwidth is less than Downstream.
• Videoconferencing requires 20% headroom over and above the connection bandwidth requested when the call is established. For example on an ADSL broadband link with 2Mb/s downstream and 256 kb/s upstream the maximum bandwidth for the call would be 192kb/s upstream – leaving 25 % headroom.
• Quality of Service (QoS) systems can be used to guarantee dedicated bandwidth for videoconferencing but needs to be end to end. As most calls between countries traverse the open Internet, for at least part of the route, end to end QoS is impossible to achieve. However successful conferences have taken place without QoS.
• Often use of the broadband bandwidth by other applications (access to websites, downloading files, using streaming media) in the school will degrade the performance of a videoconference. Some schools have to ensure that other uses are stopped for the duration of the conference.
• With a heavily used LAN or a poorly designed LAN local traffic on the network can affect videoconferencing.
• Congestion of any sort shows in poor quality video and in extreme cases freezing of the video image and break-up of the audio.
• Most schools in France and Germany currently use ADSL broadband however there is a huge variety of upstream and downstream bandwidth.

The situation in the UK

• Most schools in the UK have enough bandwidth to handle videoconferencing. The school may be linked to one of the Regional Broadband Consortia (RBC) networks or a LA network.
• RBC and LA networks are connected to form the National Education Network (NEN).
• Most RBCs/LAs support videoconferencing which is controlled through the use of Gatekeepers. These control access and provide directory services to the schools within their own regional network. Videoconferencing systems have to be registered with the local Gatekeeper before calls can be made. Rules may control calls into and out of a regional network via the Gatekeeper.
• Ukerna provides national Gatekeeper services and most regional gatekeepers have a trusted relationship with the national gatekeepers to enable calls to be made between schools across the UK .

The situation abroad

• The situation abroad varies from country to country and often from region to region within each country. It is sometimes the case that schools within the same region will have different systems.
• In France the majority of schools use Wanadoo as their ISP and most have ADSL links. In some schools the ADSL lines have very limited bandwidth, particularly upstream (128Kb/s). Most do not have fixed IP addresses. Schools will often have a Linux based Firewall/Proxy in the school and there is evidence of regional control and decision making.
• In Germany a very wide range of services and providers is evident. Local ISPs have been particularly helpful in providing services to schools. In the Cologne area NetCologne upgraded the connection for two schools in the project to 1Mb/s SDSL with 6 fixed IP addresses. This made configuration straightforward and the additional bandwidth has resulted in very good quality conferences.
• To date we have found no evidence of the use of videoconferencing Gatekeepers by schools abroad.

Linking schools abroad

• Rules governing registration with Gatekeepers in the UK vary between RBCs/LAs. The ability to register systems external to the regional network are required if links to schools abroad are to be enabled. It may be possible to register a school abroad with the regional Gatekeeper or the national gatekeeper. For the TDA project schools in Germany and France have been registered with the national Gatekeepers. One of the drawbacks is that the schools in Germany and France then have UK registered E164 numbers.
• Ideally systems in schools abroad should be registered with a Gatekeeper in their own country and trusted relationships set up between that Gatekeeper and UK Gatekeepers. To date this has not been possible to achieve due to a lack of infrastructure in each country.

IP Addressing

• With most schools in Germany and France using ADSL a number of additional problems have been encountered. Ideally a videoconferencing system should have a unique, public IP address however the majority of ADSL systems allocate a private address to each IP device on the network and using a system called Network Address Translation translate from the private addresses to a single public address. That public address may be the same each time or may be dynamically allocated from a range (we have even found public IP addresses allocated from a range of ranges!

All this works fine for most applications but causes problems for videoconferencing:

• It may not be possible to make calls with video and audio
• It may not be possible to received incoming calls
• It may not be possible to register with a Gatekeeper

• On some makes of videoconferencing system it is possible to tell the system that it is behind NAT and either allow the system to discover the public IP address automatically or to enter it manually.

If the system can find the public address automatically then it doesn’t matter if the public address changes on a regular basis.

Routers that support UPnP NAT traversal can allow discovery of the Public IP address. Some routers do not allow discovery of the public address, if this is the case and the IP address is not fixed the system cannot work.

The allocation of a fixed pubic IP address by the ISP solves this problem.

In practice the best solution is the allocation of a number of fixed IP addresses to a school by the ISP, this enables the school to allocate a public IP address to the system directly taking away the need to configure for NAT. Most ISPs will charge extra for this.

Ports, Routers and Firewalls

• For videoconferencing to work behind a firewall a number of Ports need to be opened. When traversing a firewall, the H.323 protocol requires the use of certain static ports as well as a number of dynamic ports that are selected at random from a very wide range. Network managers are naturally reluctant to open such a range of ports. Some manufacturers allow you configure the system to use a specific, more limited range of ports which can be programmed into the firewall. Ports have to be opened for call initiation, video, audio, gatekeeper registration and data collaboration.
• UPnP NAT Traversal is implemented on some routers and discover the public IP address and dynamically open requested ports on request from a specific application.
• Routers / Firewalls can be configured with Port forwarding to open specific ports for a particular network device such as a videoconferencing system. Alternatively the device can be place in a DMZ.

Ports required for videoconferencing

• Port 389 (TCP): ILS registration
• Port 1503 (TCP): Microsoft NetMeeting T.120 data sharing
• Port 1718 (UDP): Gatekeeper discovery
• Port 1719 (UDP): Gatekeeper RAS (must be bidirectional)
• Port 1720 (TCP): H.323 call setup (must be bidirectional)
• Port 1731 (TCP): Audio call control (must be bidirectional)

Port 5060 (TCP and UDP): SIP