This document discusses issues with video conferencing across two schools connected through different Local Authorities on the West Midlands Regional Broadband Network. Each school has a private IP addressing scheme that overlaps. Gatekeepers are required to translate E.164 numbers to IP addresses to locate endpoints, but each gatekeeper only knows endpoints in its own Local Authority. This prevents direct calls between endpoints in different authorities. Using public IP addresses would allow direct calls but route all traffic through firewalls. The best solution is to use H.323 proxies at each authority's network edge to proxy calls between authorities. However, this requires additional equipment for each pairing of authorities and coordination on administration as the network scales.

1. Video Conferencing Between Local Authorities
Introduction
This document highlights the issues associated with video conferencing across the West Midlands
Regional Broadband Network between two schools connected through two different Local Authorities.
Network Layout
In the hypothetical network layout below each school has an overlapping private addressing scheme, a
situation that is very likely since most Local Authorities or Broadband Consortia have opted for a
private 10.x.x.x addressing scheme for the internal network.
WMRBN Public IP addressing only
Local Authority WMRBN Edge WMRBN Edge Local Authority
Edge router router router Edge router
Local Authority Local Authority Local Authority Local Authority
Firewall Gatekeeper Gatekeeper Firewall
Local Authority Local Authority
WAN WAN
Local Authority A Local Authority B
School Feed School Feed
Router Router
School Network School Network
10.0.0.1 /24 10.0.0.2 /22
VC Endpoint A VC Endpoint B
School A School B
The following assumptions are made:
• Each school within the Local Authority has an internal network configured using a private
addressing scheme as required for connection to the Local Authority WAN
• Each Local Authority has the use of a RIPE registered public address range for connection to
the WMRBN

2. • Each Local Authority provides a gatekeeper with which any video conferencing endpoints
within that Local Authority network register. Each gatekeeper sits in a DMZ and has a public
IP address
• All video conferencing endpoints conform to the E.164 addressing scheme as set out by
UKERNA
The Requirement for Gatekeepers
If no gatekeepers were used and each endpoint is NATted at the LEA firewall to a public IP address.
This is a one-to-one NAT (thus allowing inbound connections) and all appropriate TCP/UDP ports
have been permitted through the firewall.
This would allow a point-to-point video conference between the two endpoints but that is the limit of
service. Multipoint conferencing units and IP telephones would be much more difficult to deploy and
manage and each and every device on an internal network would require a one-to-one NAT to allow
inbound connections.
From this it is safe to assume that gatekeepers are a requirement and that an E.164 addressing scheme
is required which fortunately UKERNA have already provided.
Issues With This Network Layout
Two seemingly unrelated problems are presented by in the given network – how the remote endpoint is
located (that is how the E.164 number is translated into an IP address) and how a connection is
established between the two endpoints.
Each endpoint is registered with the gatekeeper using its unique E.164 number and its internal IP
address.
To place a call the E.164 number of the remote endpoint is entered and the location request (LRQ) is
sent to the gatekeeper. The gatekeeper checks its database and returns the IP address of the remote
endpoint. The call then proceeds between the two endpoints.
The first problem is that each gatekeeper needs to be aware of all of the other remote gatekeepers and
the E.164 prefixes associated with those remote gatekeepers. Ignoring the scaling issue that clearly
arises from this, assume that Local Authority A’s gatekeeper has been configured with all of the
information required to communicate successfully with Local Authority B’s gatekeeper.
Endpoint A places a call to Endpoint B’s E.164 address. Gatekeeper A forwards the LRQ to
Gatekeeper B which responds with the IP address of Endpoint B. Endpoint A attempts to call Endpoint
B which is, as far as Endpoint A is concerned, on the local subnet. The call fails.
This problem may be fixed by each endpoint registering with its global public IP address. Since the IP
address of the endpoint is embedded within the registration request (RRQ) the endpoint software needs
to be NAT aware and ‘fix’ the contents of the RRQ with the correct global public IP address.
In the situation above the call would now proceed successfully. However, each Local Authority
Gatekeeper would now return the global public IP address for each endpoint registered with it, even to
those endpoints within the same Local Authority. This means that all traffic would flow via the firewall
in the best case, and in the worst case would be blocked by the firewall (for example, the Cisco PIX
will not route traffic out of the interface from which it entered).
Resolution of these Issues
The only realistic option is to use a H.323 application proxy at the edge of each Local Authority
network, configured with a public IP address. This H.323 proxy would be configured to proxy any call
that is not within the Local Authority zone. In the case of a Cisco router running the MCM IOS the
H.323 proxy and Gatekeeper functions may be performed on the same device though this need not
necessarily be the case.
There are however drawbacks to this:
• Each gatekeeper needs to be aware of all other gatekeepers. As the network grows,
particularly with Local Authorities joining the SuperJANET backbone this may become a vast
administrative task merely keeping track of the changes*.
• Each Local Authority will require additional equipment in order to make this work. More
specifically, each pair of Local Authorities that wish to video conference require additional
equipment for this to work.

3. * The Cisco MCM IOS supports the concept of a Directory Gatekeeper – a central Gatekeeper that is
aware of all the other Gatekeepers within the network and to which all LRQs for out of zone calls are
forwarded. This moves the administration to a single, central point. This is a Cisco implementation and
may not be supported by other Gatekeeper implementations.
Summary
There are ways of resolving the video conferencing across the WMRBN issue and is relatively straight
forward between two individual sites. However to build a truly broad and scalable solution will require
agreement between all parties involved on the issues of equipment, policy and administration.