Videoconferencingv 3

Videoconferencing – Draft
DfES
Network Services Project
Videoconferencing
Draft v3.1
Copyright © 2004 The JNT Association
NDD/NSP/RS/VC/3.1 2 June 2004 Page 1 of 66

UKERNA manages the networking programme on behalf of the higher and further education and
research community in the United Kingdom. JANET, the United Kingdom's education and re-
search network, is funded by the Joint Information Systems Committee (JISC).
For further information please contact:
JANET Customer Service
UKERNA Tel: 0870 850 2212
Atlas Centre, Chilton, Didcot +44 1235 822 212
Oxfordshire, OX11 0QS Fax: 0870 850 2213
+44 1235 822 397
E-mail: service@janet.ac.uk
Copyright:
This document is copyright The JNT Association trading as UKERNA. Parts of it, as appropri-
ate, may be freely copied and incorporated unaltered into another document unless produced for
commercial gain, subject to the source being appropriately acknowledged and the copyright pre-
served. The reproduction of logos without permission is expressly forbidden. Permission should
be sought from JANET Customer Service.
Trademarks:
JANET®, SuperJANET® and UKERNA® are registered trademarks of the Higher Education
Funding Councils for England, Scotland and Wales. The JNT Association is the registered user
of these trademarks.
The term Linux® is a registered trademark of Linus Torvalds, the original author of the Linux®
kernel.
Macintosh is a trademark of Apple Computer, Inc., registered in the U.S. and other countries.
Microsoft®, Windows®, NetMeeting®, and NT® are either registered trademarks or trademarks of
Microsoft Corporation in the United States and/or other countries.
Polycom®, People and Content, ViaVideo®, VSX and ViewStation® are of registered trademarks of
Polycom in the U.S. and various countries.
Disclaimer:
The information contained herein is believed to be correct at the time of issue, but no liability
can be accepted for any inaccuracies.
The reader is reminded that changes may have taken place since issue, particularly in rapidly
changing areas such as internet addressing, and consequently URLs and e-mail addresses should
be used with caution.
The JNT Association cannot accept any responsibility for any loss or damage resulting from the
use of the material contained herein.
Availability:
Further copies of this document may be obtained from JANET Customer Service at the above
address.
© The JNT Association 2004 NDD/NSP/RS/VC

Videoconferencing
1 Purpose...............................................................................................................5
1.1 Scope.....................................................................................................5
1.2 Target Audience.....................................................................................6
1.3 Strategic Issues......................................................................................6
1.4 Summary of Responsibilities..................................................................7
1.4.1 Schools.....................................................................................7
1.4.2 Local Authorities/RBCs............................................................8
1.5 National Education Network.................................................................11
1.6 Interoperability and Standards.............................................................12
2 Videoconferencing...........................................................................................13
2.1 Overview..............................................................................................13
2.2 Equipment............................................................................................14
2.2.1 Essential Equipment..............................................................14
2.2.2 Optional Equipment................................................................15
2.3 Videoconferencing Systems................................................................16
2.3.1 Desktop Systems...................................................................16
2.3.2 Roll-about Systems................................................................17
2.3.3 Room-based Systems............................................................18
2.4 Collaboration........................................................................................18
2.4.1 Data and Application Sharing.................................................19
2.4.2 Interactive Whiteboards and Projectors.................................20
2.4.3 Media Integration...................................................................20
2.5 Recording Conferences.......................................................................20
3 Infrastructure....................................................................................................21
3.1 Overview..............................................................................................21
3.2 H.320 ISDN Videoconferencing...........................................................22
3.3 H.323 IP Videoconferencing................................................................22
3.4 Call Admission and Control for IP Videoconferencing.........................23
3.4.1 Gatekeepers and Addressing.................................................23
3.4.2 Directory Gatekeepers...........................................................24
3.4.3 Proxy Issues...........................................................................24
3.4.4 Global Dialling Scheme..........................................................25
3.5 Local Network Configuration for IP Videoconferencing.......................25
3.5.1 Firewalls and Network Address Translation...........................26
3.5.2 Physical Separation of H.323 Traffic......................................26
3.5.3 Virtual Separation of H.323 Traffic.........................................28
3.5.4 Broadcast Traffic....................................................................29
3.6 IP Quality of Service.............................................................................29
3.6.1 Overview................................................................................29
3.6.2 Regional and National Implementation..................................30
3.6.3 Classes of Service ................................................................31
3.7 Multipoint Control Units (MCU) and Gateways....................................31
3.7.1 Overview................................................................................31
3.7.2 Gateways...............................................................................32

3.7.3 Deployment of MCUs.............................................................32

3.8 Directory Services................................................................................33
4 Quality...............................................................................................................34
4.1 Standards.............................................................................................34
4.1.1 Minimum Standards...............................................................34
4.1.2 Common Standards...............................................................34
4.1.3 Additional Features/Standards...............................................35
4.1.4 Audio Levels...........................................................................35
4.2 Quality Assurance................................................................................36
4.3 Videoconferencing Environment..........................................................36
5 Security.............................................................................................................37
5.1 Overview..............................................................................................37
5.2 Network Security..................................................................................38
6 Services............................................................................................................40
6.1 Support Services..................................................................................40
6.1.1 Advice and Guidance.............................................................40
6.1.2 Training...................................................................................40
6.2 Operational Services............................................................................41
6.2.1 Initiation of Calls.....................................................................41
6.2.2 Booking and Scheduling of Conferences...............................41
6.2.3 Resilience...............................................................................42
6.2.4 ISDN Call Charges.................................................................42
6.2.5 Fault Reporting and Resolution.............................................42
6.2.6 Technical Development and Upgrades..................................42
6.3 Management Services.........................................................................43
6.3.1 Maintenance Contracts..........................................................43
6.3.2 Capacity Planning and Procurement.....................................44
6.3.3 Liaison....................................................................................44
6.3.4 Reporting................................................................................45
6.3.5 Review....................................................................................45
6.4 The JANET Videoconferencing Service...............................................45
6.4.1 Overview................................................................................45
6.4.2 Relevant Development Projects.............................................46
7 References........................................................................................................47
Appendix A: Glossary........................................................................................51
Appendix B: Market Survey of Videoconferencing Systems........................66
Appendix C: Interoperability Testing of Videoconferencing Systems.........66

Purpose
Educational establishments are increasingly using videoconferencing to enhance, or in
some cases enable, their teaching, learning, research and administrative activities.
Schools, colleges and universities in the UK are finding that videoconferencing provides
an efficient means of delivering education and facilitating communication within their
organisations and beyond.
Implementing reliable videoconferencing services for schools can be complex, with a
number of different organisations involved in providing the essential underlying end-to-
end network services. There are networks on school premises, regional networks, Internet
connectivity and the National Interconnect via JANET. The whole forms the National
Education Network. At least three layers of educational management are involved:
schools, local authorities and national oversight. Suppliers include commercial network
and Internet services suppliers, local authorities, regional broadband consortia and
national agencies such as UKERNA. These agencies must work together to produce a
consistent, functional, secure IP network and interoperable videoconferencing
infrastructure across the various management domains.
This document sets out a number of recommendations for the successful deployment of a
reliable videoconferencing service of a consistently good quality across the educational
network.
A number of other existing documents are referenced. Some of these are examples of
technical design and some highlight best practice.
1.1 Scope
The document builds on the needs of the schools sector, highlighting the essential and
optional equipment; the necessity for a secure and well-engineered local, regional and
national network infrastructure and the importance of management, operational, training
and support services.
Videoconferencing is a real-time application, and the service quality is largely dependent
on the underlying network design. To be reliable, the requirements for videoconferencing
must be built in at all stages of the procurement, configuration and management of a
network. This document therefore contains recommendations that will need to be taken
into account at all these stages.
The main beneficiaries of a reliable videoconferencing service will be schools and their
pupils. The recommendations therefore apply directly to local and central equipment and
network configuration within schools, Local Authorities (LAs) and Regional Broadband
Consortia (RBCs). However, videoconferencing is an end-to-end service and it
requirements must also be considered in all procurements of products and services related
to the network infrastructure, whether bought by individual schools or on a regional or
national basis. The recommendations are therefore directly relevant to suppliers to
schools, including LAs, RBCs and commercial network and service providers.

Much of the discussion draws on the significant experience, which the United Kingdom
Education and Research Networking Association (UKERNA1) has gained over a number
of years in providing and managing high quality videoconferencing services for the UK
Higher and Further Education sectors.
The document also reflects the recent discussions, which UKERNA has had with the
Local Authorities, Regional Broadband Consortia, Becta and other agencies, and
equipment manufacturers and suppliers.
A Glossary of terms is provided in Appendix A.
The report of a recently commissioned Market Survey of Videoconferencing Systems
is included as Appendix B. The reports of subsequent Interoperability Testing of
Videoconferencing Systems are included as Appendix C.
1.2 Target Audience

This document should be of interest to four principal audiences:
• Staff in schools involved with their school's internal network;

• LA or RBC staff designing, building or operating their wide area network; also
those coordinating the networking activities of schools;
• Suppliers and service providers involved in the provision and management of
local or regional schools' networks;
• Content providers who are making bodies of media-rich materials available to
schools online.
1.3 Strategic Issues

Implementing and managing a videoconferencing service is a collaborative effort, so
anyone with management responsibility for any part of the ICT service should be aware
of most of the contents of this document.
Schools take ultimate responsibility for the purchase of videoconferencing systems

(Section 2 and Appendix B); so will need to take the leading role in ensuring that any
equipment purchased meets the relevant standards to ensure satisfactory interoperation
with equipment at other organisations and operates in an optimum environment (Section
4 and Appendix C), and that all those using and operating the network are aware of and
trained in their responsibilities for security (Section 5.1).
In the areas covered by the remaining sections of this document: Infrastructure (Section
3); Network Security (Section 5.2) and Services (Section 6); schools and Local
Authorities will need to work together to determine the most effective way to deliver a
secure and reliable videoconferencing service that meets the requirements of education.
1
UKERNA manages the Joint Academic Network (JANET) and the JANET Videoconferencing Service
(JVCS), which is described in section 6.4.

1.4 Summary of Responsibilities

This checklist itemises a number of activities that will be required to ensure a reliable
videoconferencing infrastructure and effective service. Some of these are primarily the
responsibility of schools, others the responsibility of the managers of the regional or local
authority networks. The most likely division of these responsibilities is summarised here,
based on information from a number of regional schools networks.
The relevant sections in the main document are indicated in parentheses.
1.4.1 Schools
School managers will normally be responsible for ensuring that:
• Schools and Local Authorities work together to determine the most effective way
to deliver a secure and reliable videoconferencing service that meets the
requirements of education. (Section 1.3)
• Careful thought is given, at the planning stage, to what videoconferencing will be
used for, to ensure the appropriate videoconferencing equipment and peripherals
are purchased. (2.4.3)
• All equipment purchased meets the relevant ITU-T international standards to
ensure satisfactory interoperation with equipment at other organisations. (4.1)
• Systems based on proprietary non-standard solutions are not procured. (1.6)
• Data sharing is separated from the video and audio. (2.4.1)
• For schools that do not have Broadband connectivity, the costs of ISDN provision
for videoconferencing is carefully considered, as these costs vary widely between
suppliers. (3.2)
• Unless ISDN is used through a PABX, the ISDN lines are dedicated to
videoconferencing. (3.2)
• All school IP videoconferencing systems are registered with their local authority
gatekeeper. (3.4.1)
• For IP videoconferencing, a 100Mbps, full-duplex, switched environment is
provided, and that no hubs are deployed. (3.5)
• The local distribution and proliferation of CODECs is well within the capacity of
the upstream links. (3.5)
• The NIC (Network Interface Card) configuration is explicitly set, rather than trust
auto-sensing. (3.5)
• The network path is not in contention with any other IP equipment and avoids the
local area network. (3.5)
• Testing is carried out to maintain agreed quality standards for videoconferencing.
(4.2)
• Room design and layout are given due consideration, as they play a large part in
enhancing the quality of the videoconference experience. (4.3)
• Conferences are not recorded without the explicit agreement of all participants.
(5.1)

• Conference booking systems or other databases or systems, which contain data of

a personal nature, are registered and that the appropriate permissions are obtained,
as required and specified by the Data Protection Act. (5.1)
• Distribution of live or recorded conferences conforms to the requirements of the
Data Protection Act and Intellectual Property Rights. (5.1)
• The appropriate security risk analyses are carried out to identify the measures to
maintain a service and the measures are implemented as necessary. (5.1)
• The size of the risk to traffic on an IP network are considered and the impact
gauged. (5.2)
• Videoconferencing systems have local passwords set to protect system settings.
(5.2)
• All default usernames and passwords are removed. (5.2)
• Calls that are initiated by the MCU to a videoconferencing system participating in
a conference can be answered. (6.2.1)
• All essential equipment has maintenance cover. (6.3.1)
• Growth in the use of videoconferencing is encouraged by the adoption and use of
the technology by senior managers. (6.3.2)
• All contracts, including those with manufacturers and suppliers of both goods and
services, have a review period incorporated into them. (6.3.5)
1.4.2 Local Authorities/RBCs

Local Authority/RBC managers are normally responsible for ensuring that:
• Schools and local authorities work together to determine the most effective way to
deliver a secure and reliable videoconferencing service that meets the
requirements of education. (1.3)
• The requirements for videoconferencing are built in at all stages of the
procurement, configuration and management of a network. (1.1)
• All of those using and operating the network are aware of and trained in their
responsibilities for security. (5.1)
• The network is well engineered with sufficient bandwidth provision. (2.1, 3.3,
3.5)
• The number of devices (switches and routers) on the path between H.323
videoconferencing endpoints is minimised. (3.3)
• A gatekeeper is provided for the registration of videoconferencing endpoints.
(3.4.1)
• All school IP videoconferencing systems are registered with their local authority
gatekeeper. (3.4.1)
• The Global Dialling Scheme, based on E.164 numbers, is used for all H.323
videoconferencing systems. (3.4.4)
• Each local authority deploys an H.323-aware firewall or proxy server as part of
their IP network infrastructure. (3.4.1, 3.4.3, 3.5.1)

• All videoconferencing sessions are routed through the proxy, if one has been
deployed. (3.4.3)
• Each local authority’s gatekeeper is registered with the National Gatekeeper. (3.4)
• Directory Gatekeepers should not be deployed at organisation (LA) level or
below. (3.4.2)
• The network is configured and maintained by appropriately skilled technical staff.
(3.5)
• All technical staff receive appropriate technical support and regular training and
updating. (3.5)
• Broadcast traffic is minimised. (3.5.4)
• An MCU is provided to support conferences involving more than two
videoconferencing systems. (3.7.1)
• Point-to-point IP conferences can be initiated by the MCU for multipoint ease of
use and security. (3.7.1)
• Service-class MCUs and gateway facilities are provided to support all scheduled
multipoint conferences. (3.7.3)
• MCUs are deployed regionally for intra-RBC conferences, as and when demand is
sufficient. [MCUs are deployed in the core of the network for all inter-RBC
conferences including IP-ISDN gatewayed conferences] (3.7.3)
• As videoconferencing becomes ‘mission critical’, MCUs are deployed in a
resilient architecture, with redundant capacity. (3.7.3)
• MCUs are not cascaded, as this is not part of the H.323 standard. (3.7.3)
• Initially service-class MCUs are deployed centrally in order to aggregate and
stimulate demand. (3.7.3)
• All centrally provided videoconferencing equipment conforms to the relevant
ITU-T Standards. (4.1).
• The appropriate security risk analysis is carried out to identify the measures to
maintain a service and the measures are implemented as necessary. (5.1)
• The size of the risk to traffic on an IP network is considered and the impact
gauged. (5.2)
• Security risks are kept to minimum by using an H.323 architecture in which the
centrally managed MCUs call out to videoconferencing systems. (5.2)
• Best practice in software updates and firewall configurations is applied to all
systems. (5.2)
• Filtering is used at a border firewall to block external access to management
interfaces where not required from external locations. (5.2)
• Videoconferencing systems have local passwords set to protect system settings
(5.2)
• All default usernames and passwords removed. (5.2)
• General advice and guidance about videoconferencing is provided to schools.
(6.1.1)
• There is a publicised means of fault reporting and that technical assistance is
available to ensure that the conferences can continue. (6.1.1)

• Those providing such support should be given (remote) access to the

videoconferencing systems and/or the MCUs participating in the conference.
(6.1.1)
• Technical and user training are provided, as they are necessary to ensure the
effective operation and use of videoconferencing systems. (6.1.2)
• Training in effective strategies for the use of videoconferencing as a tool for
teaching and learning, is provided to schools. (6.1.2)
• Operational services facilitate the opportunity for users to participate in
videoconferences with a wide range of other users. (6.2)
• Both point-to-point and multipoint conferences are possible, regardless of the type
of connection (IP or ISDN) and the audio or video protocols used by the systems.
(6.2)
• The infrastructure necessary to allow seamless connection across IP and ISDN
networks between systems is deployed. (6.2)
• Operations staff with appropriate expertise are available locally, regionally [and
nationally] to maintain the network infrastructure, videoconferencing equipment
and services. (6.2)
• Services encompass support, guidance, fault reporting and resolution, and
management of maintenance contracts. (6.2)
• Management and operations staff within different management domains co-
operate to ensure the interoperation of infrastructure, equipment and services.
(6.2)
• Calls that are initiated by the MCU to a videoconferencing system participating in
a conference can be answered. (6.2.1)
• Users can book conferences well in advance of the time they take place. (6.2.2)
• An on-line booking service is provided, enabling authenticated users to book
conferences with any other videoconferencing user or system. (6.2.2)
• The booking service provides reports of usage. (6.2.2)
• Conferences are automatically or manually scheduled on the MCUs, which can
hold future reservations, and automatically initiate and tear down conferences.
(6.2.2)
• MCUs and other operationally critical equipment are deployed with resilience in
mind, keeping single points of failure to a minimum or removing them entirely.
(6.2.3)
• Single points of failure are identified, with effective workarounds and recovery
plans drawn up. (6.2.3)
• ISDN billing information is generated from either a booking service or MCUs, so
invoices for ISDN call charges can be generated, if required, and sent either to
LAs or RBCs. (6.2.4)
• All central equipment is managed, to ensure the timely reporting and resolution of
faults, both with conferences and with the equipment itself. (6.2.6)
• A central telephone number is published, for the reporting of faults with
videoconferences. Calls to this number should be answered in person during the
hours of service operation. (6.2.6)

• Upgrades are thoroughly tested in a non-service environment and issues resolved,

prior to deployment in a service environment. (6.2.6)
• Roll-about and room-based systems are kept under maintenance. Centralisation of
maintenance agreements should be considered, as it tends to be more cost
effective and allow for a more rapid response time. (6.3.1)
• The cost of maintenance is factored into the ongoing costs for the operation of the
service. (6.3.1)
• Contingency planning documents how the service will continue when equipment
fails and is being repaired and that maintenance agreements include software
upgrades and patches. (6.3.1)
• ISDN lines installed where necessary to provide a backup for the IP network.
(6.3.1)
• Growth in the use of videoconferencing is encouraged by the adoption and use of
the technology by senior managers. (6.3.2)
• Support services and central equipment are scaled to cope with increased demand.
(6.3.2)
• Capacity of the central equipment is kept under continual review, to ensure
scaling of the service to meet demand. (6.3.2)
• Time and resources to carry out procurements are factored into capacity upgrades.
(6.3.2)
• Provision for MCU hardware upgrades are factored into the cost of service
operation. (6.3.2)
• Roadmaps from manufacturers and suppliers are made available in a timely
manner, allowing for the planning of upgrade paths and timescales. (6.3.3)
• The overall service provision is reviewed regularly. (6.3.5)
• All contracts, including those with manufacturers and suppliers of both goods and
services, have a review period incorporated into them. (6.3.5)
1.5 National Education Network

The National Education Network, connecting schools to each other and to the Internet,
comprises a number of different management domains, shown in the following diagram.
At the ends of the network are the computers and networks on school premises, for which
schools themselves are responsible.
Connecting schools in a geographic area are systems and networks controlled by a Local
Authority network, which may be combined with, or a client of, a more general-purpose
Regional Network. Connecting these regional networks together is the National
Interconnect via JANET.
Connection to the Internet should be provided at the LA/RBC or higher level; Internet
connections lower down the network are likely to cause serious operational, management
and security problems. Internet connection aggregation has clear benefits and it is
recommended that this be considered by Local Authorities.

This structure reflects the management domains within the network: who is responsible
for systems and networks at each level. It is likely that the physical network will have the
same organisation, though the locations of the boundaries may vary between different
regions and schools depending, for instance, on networking technology and management
arrangements.
1.6 Interoperability and Standards

As described above, the National Education Network consists of a number of different
domains, managed by different organisations. However, for a reliable videoconferencing
service to be put in place, the policies and technologies used in the different domains
must inter-operate. This will only be achieved by all parties working to formal
international standards. The purchase of proprietary videoconferencing systems is highly
likely to lead to interoperability issues. In networking, an arbitrary decision in one
management domain can affect the operation and security of all others.
Where they exist, International standards are to be preferred as they are better understood
and more likely to be supported by readily available products compliance to international
standards maximises interoperation. In this document, such standards are therefore
highlighted when appropriate. Before equipment is purchased, potential systems should
be thoroughly assessed for their adherence to standards to ensure interoperability with
other systems, and their appropriateness to provide the required functionality in the
desired environment. To assist the education community in this respect, UKERNA has
commissioned two reports from the Video Technology Advisory Service (VTAS): a
Market Survey of Videoconferencing Systems and a report on Interoperability Testing of
Videoconferencing Systems. The reports of these studies are included as Appendices B
and C respectively.
The UK Government’s e-Government Interoperability Framework (e-GIF) makes

recommendations with respect to the adoption of IP conferencing standards. These
include the H.323 Standard, for the assembly of audio, video, data and control, and can
be found at: http://www.govtalk.gov.uk/interoperability/egif.asp.
It must be emphasised that the procurement of systems based on proprietary non-standard

solutions is strongly discouraged. Proprietary products may appear to be more feature-
rich and cost effective and appear in some circumstances to provide a satisfactory short-
term solution, perhaps for a specific need or project in a group of schools. It is most likely

that future growth would be impeded, as links could only be made with other
organisations deploying the same proprietary equipment.
There will also be a need for locally agreed standards, particularly regarding the
management and configuration of the network. For example if a school does not allocate
IP addresses to computers in a way agreed with the authority that runs the regional
routers, then the network is unlikely to be able to transfer packets as intended. The Video
Technology Advisory Service publishes a document about videoconferencing standards,
which can be found at: http://www.video.ja.net/stan/
There are numerous bodies defining telecommunications standards, but the principal ones
relevant to videoconferencing are:
• International Telecommunication Union (ITU)

http://www.itu.int/ITU-T/publications/
• International Organization for Standardization (ISO)
http://www.iso.ch/iso/en/ISOOnline.openerpage
• International Electro technical Commission (IEC)
http://www.iec.ch/
• Internet Engineering Task Force (IETF)
http://www.ietf.org/
• European Telecommunications Standards Institute (ETSI)
http://www.etsi.org/
Videoconferencing
2.1 Overview
Much of our communication is visual, and being able to see as well as hear each other
significantly enhances the interaction between people. Videoconferencing enables
participants at distributed geographical locations to interact in much the same way as they
would if they were in the same location. Videoconferencing can also be used to develop
communications skills and curriculum links, as currently being explored in some local
authorities including, for instance, Hertfordshire2. Although videoconferencing can be
disconcerting for some initially, with a little experience the equipment becomes
unobtrusive and the focus of a session moves to the human interaction.
Videoconferencing takes place via the ISDN (Integrated Services Digital Network) using
the H.320 Standard, or over the IP (Internet Protocol) network, using the H.323 Standard
or Session Initiation Protocol (SIP). H.320 and H.323 are standards from the ITU series
of recommendations. SIP is a relatively new protocol that is still under development and
is therefore not yet widely deployed. For the purposes of this document, discussion of IP
videoconferencing is restricted to the H.323 Standard. An overview of the relevant
2
Using Video to Develop Communications Skills
Hertfordshire, East of England Broadband Consortium
http://www.e2bn.net/e2bn/web/e2bn_tng/e2bn_main/acon_devcomm.htm

standards is provided in Section 4.1 and details of the Videoconferencing Standards are
provided at the VTAS Web site: http://www.video.ja.net/stan/
Schools that are Broadband-enabled can use the IP network for videoconferencing,
whereas those that are not yet Broadband-enabled will need to continue to use ISDN
videoconferencing. ISDN provides guaranteed digital telephone line speeds in multiples
of 64Kbps and is widely deployed, being readily available almost everywhere in the UK.
Commonly used data rates for videoconferencing are 128Kbps (ISDN2) and 384Kbps
(ISDN6), which provides good quality. However, ISDN call charges and line rental can
prove expensive. IP videoconferencing within the education sector is currently free at the
point of use and is conducted at various data rates, most commonly 384Kbps, 768Kbps
and 1.5 or 2Mbps. Conferences at call speeds above 768Kbps will generally be of higher
quality than those at ISDN6. ISDN videoconferencing and IP videoconferencing are
discussed in more detail in sections 3.2 and 3.3 respectively.
Videoconferencing may be point-to-point, between just two systems, or multipoint,
connecting three or more systems. Multipoint conferences, and in specific cases point-to-
point conferences, require the use of a Multipoint Control Unit (MCU). Large
conferences, or those that need to be gatewayed (or ‘bridged’) between the IP and ISDN
networks, require significant MCU resources and gateway facilities. Provisioning of
MCUs is addressed in section 3.7.
Videoconferencing for teaching and learning can be implemented at a number of levels of
sophistication: from basic PC-based desktop videoconferencing systems for one-to-one
conferences, through roll-about systems for groups, to elaborate room-based fixed
systems for larger classes, see section 2.3. Each of these may also incorporate extra
functionality, such as collaboration equipment, enabling the sharing of data, video,
applications, paper documents and artefacts, considered in more detail in section 2.4.
Interactive whiteboards, when connected to a networked PC, can also be used for
standards based T.120, interactive data and application sharing during a videoconference.
Each of these three main approaches is discussed in Section 2.4: Videoconferencing
Systems. It is assumed that, in all cases, the network is well engineered with sufficient
bandwidth provision. Networking aspects are discussed in Section 3: Infrastructure.
2.2 Equipment
2.2.1 Essential Equipment
To hold a videoconference, each location must be equipped with a videoconferencing
system or ‘endpoint’. A summary of the minimum facilities required for
videoconferencing is as follows:
• COder-DECoder (CODEC) system (H.323 and/or H.320 compliant)

• Video: camera and monitor
• Audio: microphone and speaker
• Connections to the IP (H.323) and/or ISDN (H.320) networks (IP connection may
be wireless)

These basic components must be present in every system, from desktop to room-based.
Desktop systems are likely to utilise the monitor, microphone and speakers, supplied as
part of the PC. All that is required to complete such a system is a CODEC and a camera,
which may be integrated into a single compact unit. For roll-about and small room-based
systems the speakers may be integrated with the monitor, and the camera and microphone
may be integrated with the CODEC.
Careful consideration should be given to screen and image sizes, to ensure they are ap-
propriate for the type of activity and size of audience. A small image on a PC screen may
be adequate for individuals or small groups to participate together in a conference. If a
large audience is watching a remote presenter, or long frequent conferences are taking
place, then a large, high quality image is recommended. Such an image could be achieved
by projection. In this scenario, the remote presenter would only require a relatively small
image of the remote audience, particularly if a camera with a zoom function were used,
so an individual asking a question would be clearly visible.
If a presenter remains seated and just talks, a smaller image is more acceptable than if the
speaker is moving around or carrying out a demonstration. In these instances, a large,
higher resolution image is required to enable to audience to gain most value from the con-
ference.
A clock and a telephone, with an attention light rather than a bell/buzzer, are also viewed
as essential items of ancillary equipment and are often overlooked.
2.2.2 Optional Equipment

A wide range of optional equipment can also be incorporated into the videoconferencing
environment. These include, but are not limited to:
• System integration and control facility with touch screen;

• Audio mixer and amplifier;
• Additional microphones and speakers;
• Additional cameras and monitors, including confidence3 monitors;
• Wireless tie-clip microphone;
• Visualiser/document camera;
• DVD and/or Video Cassette Recorder;
• Data/video projector;
• Interactive whiteboard;
• Data and application sharing facilities;
• Video and audio streaming facilities;
• Studio lighting, sound proofing and air conditioning;
• Security: locks, surveillance and alarm systems.
3
Confidence monitors are extra monitors, usually positioned at the back of the room behind the local
audience, often smaller than the main monitors, used in a teaching environment so that a teacher/presenter
can see the local and remote view. This gives the teacher/presenter the confidence that they are in shot and
enables them to see the remote audience.

2.3 Videoconferencing Systems

2.3.1 Desktop Systems
Systems based on standard PC (Personal Computer or Macintosh) platforms are
widespread throughout the Higher, Further and Secondary Education sectors. Until the
last few years these have been of fairly poor quality, but, with the increase in locally
available processing power, some of these are now of acceptable quality for one-to-one
conferences and small groups of perhaps two or three people. Traditionally these systems
used ISDN2 and, as a result of relatively poor quality, were little used, but relatively low
cost UPnP™ (Universal Plug-and-Play) systems using the IP network have become
available and are proving popular and of acceptable quality.
Assuming a well-engineered network with adequate bandwidth provision, the quality of a

desktop solution depends primarily on two factors:
• Quality of the CODEC, software or hardware

• Quality of the camera
Software CODECs, which use PC hardware for coding and decoding video, are being
constantly improved and, coupled with increasing processing power, are gradually
becoming an attractive cost-effective solution for desktop videoconferencing. However,
inexpensive ‘Web-conferencing’ solutions based on software CODEC and a WebCam
costing around £50, tend to be of inferior quality. Such solutions when associated with a
good quality camera, perhaps costing £200-£300, which might include pan, tilt and zoom
functionality, can produce improve quality. Hardware-assisted solutions are generally of
superior quality to software CODECs and currently retail from around £500, although
these don’t always incorporate a good quality camera. This may take the form of a PCI
card or a stand-alone unit.
The advantages of desktop systems are:

• Low capital cost; little or no recurrent cost; readily available;
• Subject to minimum specification, may use an existing PC;
• Convenient for individual PC users;
• Relatively easy to install and configure, especially for more experienced users;
• Include integrated data and application sharing facilities.
The disadvantages of desktop videoconferencing systems are:

• Recommended for one-to-one use or small groups only. However, with a high
quality CODEC and camera, the picture quality should be satisfactory for
projection for larger groups;
• Dedicated to one PC – may be difficult to move and be shared by other users,
unless available to all;

• Unless a good quality camera is part of the solution, there will be little or no
control of the camera pan, tilt and zoom. Low quality cameras with small
aperture, will result in a poor quality picture;
• May be poor quality audio, if using PC microphone;
• No echo-cancellation built into the system, necessitating the use of headphones;
• Requires a recent high-specification PC with USB support, which may be a
budgetary constraint;
• Environmental requirements are not normally addressed;
• Some types are insecure (USB versions) and can be stolen easily;
• Inadequate technical knowledge on the part of the user can lead to increased
requirement for local support;
• Can be a poor experience if low quality equipment is used.
2.3.2 Roll-about Systems

These tend to be higher quality systems, which are associated with a wheeled cart or
stand. The CODECs are often similar to those used in room-based systems. These
systems are likely to stay predominantly in one location, but could be moved to any other
location, whether environmentally suitable or not. They generally incorporate a CODEC,
a monitor, a microphone, speakers and two separate remote controls for operating the
CODEC and the monitor. Such systems are likely to cost at least £3,000.
The advantages of roll-about systems are:

• Moderate capital and recurrent cost; easy to buy;
• Suitable for individuals or groups;
• Can be shared, thus providing a cost saving;
• Ease of control via a remote control and simple graphical user interface;
• Higher quality camera, usually including pan, tilt and zoom;
• Location-independent – doesn’t take up a room when not in use.
The disadvantages of roll-about systems are:

• Inconvenient – they are frequently locked away and have to be brought to the
videoconferencing location, set up and tested in advance, which requires technical
expertise and support;
• No control over the room environment;
• Day-to-day care and maintenance of the system is difficult:
o Parts, cables, remote controls may be lost more easily;
o Remote control batteries may not be monitored adequately;
o The system may have been left in an unusable state by the previous user;
• Unless they are locked away, they may not be secure and can be rolled off the
premises;
• Require network connectivity in all locations where they will be used.

2.3.3 Room-based Systems

Room-based fixed systems are widespread in the UK Higher Education community, and
the Further Education sector in Wales. These utilise all of the basic equipment and much,
if not all, of the optional equipment outlined in Section 2.2. They usually include
CODECs that can use either the IP and/or ISDN networks. Such systems are likely to cost
at least £5,000. With appropriate adaptation and furnishing the total cost of a
videoconferencing facility may well exceed £15,000.
Roll-about systems may be permanently located and used as room-based systems,

providing a lower cost option.
The advantages of room-based systems are:

• Large numbers of participants possible at each location (in the HE sector
videoconferencing is used in lecture theatres seating from 30 to over 100);
• Integration of videoconferencing and collaboration tools;
• Users are not required to set up, configure or connect the system;
• Little or no experience or technical knowledge required by users;
• Ease of control via touch screen;
• Higher quality camera, including pan, tilt and zoom;
• Best environmental quality control, designed for the task;
• Secure environment;
• Predictable and reliable;
• Provides a high quality experience.
The disadvantages of room-based systems are:

• High capital and recurrent costs;
• Fixed systems may be inaccessible if the room is being used for other purposes;
• Complex and thus time-consuming to specify, procure and implement properly;
• If a control touch screen is not included, there may be too many remote controls;
• Requirement for local technical support staff.
2.4 Collaboration
Various tools for collaboration can be deployed, to enrich a videoconferencing experience
beyond just ‘talking heads’, which can be monotonous and limit learning opportunities.
Collaboration tools can be as straightforward as a VCR or document camera, where the
recorded video or image is transmitted from one videoconferencing system to all the oth-
er participants in the videoconference. Alternatively more sophisticated alternatives are
available, such as networked PCs and interactive whiteboards, can be deployed, facilitat-
ing the real-time sharing and collaboration of a wider range of materials and information.
Some manufactures have developed their own proprietary solutions to enable both a
video stream of one videoconferencing system and of content, such as a Microsoft®
PowerPoint® presentation to be sent simultaneously, known as ‘in-band data sharing’.
Notable among these solutions are Polycom®’s People and Content™, and Tandberg’s

DuoVideo, which do not interoperate with each other. These solutions can be used in a
point-to-point conference providing both videoconferencing systems are from the same
manufacturers and have support for the solution. FVC™ Click to Meet™, which is
deployed in some RBCs, also provides in-band data sharing. Other equipment deployed
in the path of the videoconferencing traffic, such as gatekeepers and firewalls must also
provide support for the proprietary standard, which is unlikely. Use of these proprietary
solutions in a multipoint conference can be more problematic, as the MCU must also
support the solution being used.
A new standard, H.239, has recently been agreed for in-band data sharing. Manufacturers
will start to make this standard available in videoconferencing systems during the course
of 2004.
2.4.1 Data and Application Sharing

Data and application sharing means the simultaneous display of the desktop (screen) of
one computer (or of an application running on one computer), on another display at a
different location, with changes updated on both displays in real time. A practical
example would be the sharing of a Microsoft® PowerPoint® presentation, where the
lecturer shares the presentation by running it simultaneously on a local and a remote
monitor. The students at the remote location(s) can see the presentation, but not alter it, or
change slides, etc.
Interactive data sharing means the same as above, but with the additional possibility of
either/any location being able to take control of the desktop or application, and thus
update it in real-time, so that both ends see the changes. A practical example would be a
meeting in which a Microsoft® Word document under development was shared so that all
users could enter, delete or review text.
Videoconferencing applications are real-time applications that generate large amounts of

data, which need to be transported across networks very quickly to be of use. Even slight
delays in the transmission of data can result in impairments to picture or audio quality.
For these reasons it makes sense to provide the audio and video with a clear path. Data
sharing is not quite so time-sensitive. A delay of half a second on the update of a
presentation can in most situations be tolerated without affecting the quality of the
interaction. For this reason it makes sense to separate the data sharing information from
the video and audio, so that it is not competing with them for precious network resources,
so a separate connection is made for the data-sharing element of the conference. This is
termed ‘out-of-band’.
A PC that is attached to a Local Area Network (that is in turn able to access the Internet)
has become so ubiquitous that it provides the simplest and most cost-effective solution to
setting up a separate, parallel connection over the Internet for the data sharing session.
This data-only Internet session can complement an audio/video conference irrespective of
whether the conference is using the Internet or ISDN as its network connection.
The out-of-band method gives a level of flexibility and interactivity. This method helps to
avoid potential problems caused by incompatibilities between videoconferencing systems

or their software. It also allows network engineers to apply appropriate support within the
network to optimise the quality of each conference.
2.4.2 Interactive Whiteboards and Projectors

It is becoming increasingly common for videoconferencing studios to include projection
facilities. Where these facilities are available at both local and remote venues,
presentations running on a data sharing PC in the local studio can be displayed locally,
while simultaneously being displayed in the remote studio (via a data sharing PC in that
studio). This means that participants in a studio can see the image of the remote speaker
on their terminal as s/he addresses them; and simultaneously view a projection of the
presentation, document or web page that is being discussed.
When an interactive whiteboard is used in conjunction with videoconferencing system,

careful thought should be given to the layout of the equipment. This is so that the
presenter can see the local and remote audiences, and the audiences in all locations can
see the presentation and the presenter face-on, and possibly the other audiences, if the
session is to be fully interactive. It may be necessary to deploy a second camera at the
presenter’s location, so both they and the local audience can participate.
2.4.3 Media Integration

As with all teaching, videoconferences can be made more engaging by the use of other
resources. Using a range of peripheral equipment it is possible to share a range of media.
Using a document camera, images, paper documents and 3-D artefacts can be shared.
Play back of video clips is possible using a VCR or DVD player. Electronic documents or
a presentation on the laptop of a visiting speaker can be shared by connecting the laptop
to the videoconferencing system.
Careful thought should be given, at the planning stage, to what videoconferencing will be
used for, to ensure the appropriate videoconferencing equipment and peripherals are
purchased.
2.5 Recording Conferences

If recording equipment (e.g. VCR or DVD writer) is deployed along side a
videoconferencing system, the recording of conferences will be possible. Careful
consideration is required to ensure the correct video is recorded. In ‘voice-switched’
mode (all participants see the current speaker, who sees the previous speaker) the
recording device will record incoming video and will only record the audio of the local
speaker, not the video. It may be necessary to run the conference in ‘continuous presence’
mode (the screen is divided up and all participants are visible throughout the call), to
ensure all required video streams are recorded.
If a conference is being recorded, thought should be given to Intellectual Property Rights

and compliance with the requirements of the Data Protection Act. These are outlined
briefly in section 5.1 Security Overview.

Infrastructure
3.1 Overview
When a videoconferencing system is installed and operational, it does not automatically
mean that the system will be able to join even a simple point-to-point conference. The
appropriate local, regional and national network infrastructures also need to be in place.
Standards compliance and interoperability with local, regional and national resources are
also essential.
A videoconference link requires:

• Transmitting and receiving equipment at each site;
• An intervening network to carry the signals.
Traversal can involve one, or a mix of, the following:

• ISDN (Integrated Services Digital Network)
• Local Area Network (LAN), e.g. a school, college or university;
• Regional Network, supporting a city or a region;
• Wide Area Network (WAN), extending to national and international sites.
These networks may comprise a number of physical transmission methods including:

fibre-optic cables, co-axial transmission lines, copper twisted pair cable, satellite and high
frequency radio. To enable transmission of information over these networks different data
transmission methods are available that may broadly be broken down into Switched
Circuit Networks that include ISDN used to transfer data over digital telephone lines, and
Packet Based Networks (PBN) that include IP (Internet Protocol). The ITU-T has
produced several umbrella videoconferencing standards; collectively these are known as
the H.3xx videoconferencing standards.
These are described in detail in ‘Videoconferencing Standards’ available at

http://www.video.ja.net/stan/.
In the case of IP conferences, other network related equipment is normally required to

establish a connection, namely ‘gatekeepers’. The role of these devices is explained fully
in Section 3.4.
It is frequently a requirement to ‘bridge’(or gateway) more than one network type to

achieve a link, e.g. one organisation with IP capable equipment may need to
communicate to another that only has an ISDN connection. Gateways are pieces of
equipment that can transparently translate the communication between different network
types, and are described in Section 3.7.
When a videoconferencing system is installed it has to be connected to either an IP net-

work or ISDN lines. If the system is to be used in various locations, then the appropriate
connectivity must be provided in each place. Most videoconferencing systems deployed
in the schools sector will use the IP network, however, in some instances it is likely that
use will be made of ISDN.

3.2 H.320 ISDN Videoconferencing

Historically, bandwidth limitations and the multi-service non-dedicated nature of the In-
ternet have meant that it has not been reliable enough to support voice and video traffic
which led to the widespread use of ISDN for videoconferencing. There are still a signific-
ant number of organisations in the schools, FE and commercial sectors that do not have
access to the IP bandwidth required for videoconferencing traffic. If these organisations
want to participate in videoconferences, one option is to consider the use of ISDN video-
conferencing. In some instances installation of ISDN lines, annual rental charges and call
charges are more affordable, both in terms of time and cost, than upgrading and re-engin-
eering LANs and links to the high-speed IP backbone,
ISDN lines are leased from a telecomms provider. ISDN circuits are switched, which
means a dedicated connection is established between the videoconferencing systems for
the duration of the conference, as with a telephone call. Typically ISDN operates at or
ISDN6. The costs of ISDN provision should be carefully considered, as they vary widely
between suppliers.
As well as the call charges associated with ISDN videoconferencing, there are also in-
stallation and line rental charges. Unless ISDN is used through a PABX, the lines have to
be dedicated to videoconferencing, which can make the on-going costs significant. It is
worth noting that some users have reported difficulties when using ISDN videoconferen-
cing through a PABX.
ISDN videoconferencing tends to be associated with room-based systems, as it is unlikely

that ISDN connectivity will be available in multiple locations within a site.
3.3 H.323 IP Videoconferencing

Real-time applications such as videoconferencing generate large amounts of traffic,
which is sensitive to delay as it traverses the network. Overall delay should be as small as
possible and thought should be given as to where the videoconferencing system is located
on the network, thus it is recommended that the number of routers on the path between
the H.323 terminals is minimised.
Ideally the delay caused by the local network should remain constant, as jitter (varying
delay) can result in the significant degradation of the quality of a conference.
H.323 is not very robust in the face of traffic loss. Packet loss should be below 1% for
point-to-point conferences and 0.75% for multipoint conferences. From these require-
ments it is clear that H.323 traffic must not be run over heavily congested IP networks,
(heavy congestion is considered to be a switched network running at more than 40% ca-
pacity).
Section 3.5 addresses the network requirements for IP videoconferencing systems, to

avoid bottlenecks and congestion. However, videoconferencing traffic will also traverse
networks in other management domains, such as the Local Authority, RBC and JANET.
Every effort should be made to ensure these are adequately provisioned in terms of band-
width.

SIP is a relatively new protocol; it is used by Windows® Messenger. In the future SIP
may replace H.323 as the standard for videoconferencing over IP networks, however, it is
not yet widely used in videoconferencing systems and is not addressed in this document.
3.4 Call Admission and Control for IP Videoconferencing

3.4.1 Gatekeepers and Addressing
Gatekeepers are required for IP videoconferencing and every H.323 videoconferencing
system must be registered with a gatekeeper. Each organisation's gatekeeper must be
registered with the National Gatekeeper to send and receive calls using the addressing
scheme and to take part in multipoint conferences.
A gatekeeper is not an H.323 videoconferencing system itself, but is an entity on the

packet-based network that provides admission and call control services to
videoconferencing systems. A zone is the collection of all terminals, gateways and MCUs
managed by a single gatekeeper. A zone has a single gatekeeper at any given time,
although a gatekeeper may be able to manage multiple H.323 zones. Products being sold
as H.323 gatekeepers may have restrictions on the number of videoconferencing systems
and other H.323 devices that can be registered.
The services that a gatekeeper provides include:

• Address translation – between H.323 and transport level addresses;
• Address resolution – for calling videoconferencing systems to locate the destination
videoconferencing system;
• Access to the network – authorisation and admission control;
• Bandwidth management – responding to requests from the videoconferencing systems
for access to shared bandwidth;
• Zone management – these services are provided for videoconferencing systems
registered in its zone
• Support for E.164 dialling.
A gatekeeper may also provide additional managerial services for videoconferencing

systems in its zone. Gatekeepers and zones are optional elements of an H.323 architecture
but any large-scale implementation will need the managerial and ‘policing’ services that
they provide. The division of the network into H.323 zones also provides for devolved
management of elements, and will reflect (to some extent) the physical topology of the
network.
Gatekeepers may be deployed at organisational, local authority or regional level. A school

is unlikely to need a gatekeeper. It is recommended that each local authority deploys a
gatekeeper/proxy server as part of their IP network infrastructure. School IP
videoconferencing systems should be registered with their local authority gatekeeper and
it is also recommended that, unless the local authority firewall is H.323-aware, all
schools’ videoconferencing traffic pass through a local authority gatekeeper/proxy server.
Each RBC has already deployed a regional gatekeeper, without a proxy, for call setup.

3.4.2 Directory Gatekeepers

UKERNA manages a national hierarchy of Directory Gatekeepers on behalf of the
education community. This enables destination videoconferencing systems’ addresses to
be resolved, and calls routed, without, as is often the case, every gatekeeper being aware
of all others, i.e. without having to implement a full mesh of gatekeepers. This solution is
aligned with other National Research and Educational Networks (NRENs) worldwide
who are collaborating to provide world gatekeeper facilities. Directory Gatekeepers are a
specific implementation of gatekeepers that do not provide services such as registration
etc. directly to H.323 videoconferencing systems. Directory Gatekeepers provide only
address resolution (LRQ forwarding) for other gatekeepers.
Calls between videoconferencing systems registered on the same gatekeeper, i.e. within
the same H.323 zone, are resolved within that zone's gatekeeper. Calls to
videoconferencing systems outside the local zone are forwarded as appropriate to the UK
National Gatekeeper or to the World Gatekeeper. The key to the UK implementation of
the hierarchy is the UK National Directory Gatekeeper. This allows organisations within
the UK to dial each other, and to dial into, or be called from, core resources such as
MCUs and gateways.
Organisation-level (local authority and below) Directory Gatekeepers are not needed as
part of this scheme. It has been shown that these could actually hinder the correct
functioning of the addressing scheme.
3.4.3 Proxy Issues

H.323 is an insecure protocol requiring a large number of TCP and UDP router ports to be
constantly available. Port allocation is dynamic at the time of connection and it is
impossible to know in advance which ports will be used. Opening all likely ports to
network traffic is a major security risk.
It is increasingly common for organisations to run firewalls and it is common for these
firewalls to use default deny inbound policies. If a firewall is ‘H.323-aware’, ports can be
determined in real-time by monitoring the call control and setup channel. However, these
firewalls are expensive and complex to configure. If a non-H.323 aware firewall is
deployed, then a proxy should be deployed, often (but not always) supplied together with
a gatekeeper as a single composite product.
Although not formally an entity that is described in the H.323 standard, the proxy can sit
on a local authority’s border network and communicate with all of its registered H.323
CODECs. The proxy can be chosen to be the only source trusted for inbound H.323
sessions. All sessions are routed through the proxy, which translates videoconferencing
system IP addresses, effectively masking the addresses to external networks and act as
intermediaries between videoconferencing systems to provide them with a layer of
security. Proxies can also be used to allow H.323 systems to use IPv6 services on the
LAN. Both firewalls and proxies add minimal latency, but this is not significant and the
benefits outweigh the extra delay.
Further discussion of firewall and proxy issues is provided in Section 3.5.1.

3.4.4 Global Dialling Scheme

The Global Dialling Scheme (GDS), which facilitates communication through the
gatekeeper hierarchy, was developed by UKERNA in association with other European
Academic and Research Networks. The scheme is based on E.164 telephony numbers,
which are an element of the H.323 standard. Other European Academic Networks and the
U.S. based ViDeNet community (http://www.unc.edu/cavner/videnet/) have adopted the
GDS, allowing interoperation. The use of an E.164-based scheme will make the
integration of Voice over IP Services possible in the future. UKERNA is the GDS
numbering authority in the UK. The JANET Videoconferencing Management Centre is
responsible for the day-to-day management of the Global Dialling Scheme.
Reference: http://www.ja.net/schoolsbroadband/E164.pdf
3.5 Local Network Configuration for IP Videoconferencing

For H.323 videoconferencing, a 100Mb/sec, full-duplex, switched LAN environment is
recommended. It is usually wise to explicitly set the network interface card (NIC) ports
on the videoconferencing system and the switch to these settings, rather than trust auto-
sensing. However, there may be cases where equipment will not be capable of supporting
these settings; in this case, the corresponding port or terminal should be manually and
explicitly set to be at the same speed/duplex settings as the equipment to which it is
connected.
The entire path from terminal to site router should be at least 100Mb/sec over Cat5 (or
later) structured cabling and should include as few hops as possible. It should not be in
contention with any other IP equipment and should avoid the local area network, either
physically or, if this is not possible, by the use of VLANs (as described below, in Sections
3.5.2 and 3.5.3 respectively).
Non-switched networks (i.e. those using hubs), unless they are lightly loaded (10%
loading of a non-switched network is significant and will adversely affect performance),
are not suitable for the demands that real-time videoconferencing traffic places on them.
The major benefit of a purely switched environment over structured cabling is that they
enable the network to transport Ethernet frames efficiently, even when there is significant
traffic.
H.323 services can utilise substantial amounts of bandwidth, especially for video, and for
peaks of data and application sharing. In addition to pure ‘bandwidth’ considerations,
H.323 services are very sensitive to issues such as latency, jitter and loss. Local network
managers will need to take care that the distribution and proliferation of CODECs stays
well within the capacity of upstream links and that no congestion occurs on those
upstream links or within the LAN links feeding the H.323 systems. They may also wish
to consider dedicated links, carefully planned switched or routed networks or prioritising
H.323 traffic, as it is generally accepted that the end-to-end available bandwidth for an IP
videoconferencing session needs to be double the selected call speed.
In summary, a well-engineered secure network is paramount. Unless a fully managed

service has been procured, the network must be configured and maintained by skilled

technical staff. Such staff will require appropriate technical support and regular training
and updating.
The following sections go into more detail concerning the issues surrounding the
planning of a well-engineered network.
3.5.1 Firewalls and Network Address Translation

H.323 is one of the few protocols that dynamically allocate destination ports to traffic. It
is also one of the few protocols that embed IP address information within the packet’s
data payload, other than simply as source and destination addresses in headers. For these
reasons, H.323 has been traditionally viewed as incompatible with firewalls. However,
many firewalls are now ‘H.323-aware’ and have the ability to provide added security to
videoconferencing systems and other H.323 equipment.
It should be noted that H.323-aware firewalls tend to be expensive, and more complex to
configure and manage than a regular firewall. An alternative to the deployment of an
H.323-aware firewall is an H.323 proxy, along side the existing firewall. Proxy issues are
addressed in more detail in Section 3.4.3.
The availability of H.323-aware firewalls is matched by the H.323-aware Network

Address Translation in equipment, frequently in the same box as the firewall, allowing
organisations to deploy, or continue to use private IP addressing internally and still have
connectivity with the outside ‘public’ IP world.
Whilst in general there seem to be increasingly fewer problems in the firewall and NAT
areas, there have been instances where the introduction of one or the other system into an
organisation has had an impact on H.323 traffic. These cases have involved failure of
traffic throughput, rather than occasional instances of loading or packet loss, so are fairly
easy to trace. In some cases the failures have been highly irregular in nature, such as all
videoconferences from an organisation suddenly terminating after 30 minutes or so. In
this particular case, the fault was traced to the interoperation between the newly installed
firewall and the videoconferencing systems, and was quickly fixed with a patch from the
firewall manufacturer.
Where private IP networks are deployed and there is a need to videoconference between
videoconferencing systems using the internal private space and external
videoconferencing systems, then there are two options:
• An H.323-aware Firewall/NAT device; or

• An H.323 Proxy – similar to an HTTP/web proxy.
3.5.2 Physical Separation of H.323 Traffic

The topology illustrated below allows the H.323 traffic to bypass the core of the network,
so avoiding any potential LAN issues impacting on H.323 videoconferences. It also
allows maintenance work to be undertaken on the LAN without impacting any scheduled
videoconferences.

Figure 1: Physical Separation of H.323 Traffic

The H.323 network is separated from the LAN at the Site Access Router. A dedicated switch
provides connections for videoconferencing equipment and infrastructure elements such as the
H.323 gatekeeper and videoconferencing systems.
A number of refinements can be made to this topology if the Gatekeeper is also capable
of proxying H.323 traffic. To increase security, and in the cases where schools wish to use
private IP address space for videoconferencing systems, the gatekeeper/proxy can be
moved to be in line between the switch and the Site Access Router. Videoconferencing
calls are established based on E.164 number, which for local purposes are resolved at the
proxy.
In many cases it will not be possible to physically separate H.323 and LAN traffic, and it
will be necessary for all traffic to share the same physical links. In this case there are
some methods that can be used to provide some level of protection to H.323 traffic, above
that provided to other traffic.

3.5.3 Virtual Separation of H.323 Traffic

A VLAN (Virtual Local Area Network) is, in effect, an overlay network that uses the
underlying physical network to provide one or more virtual networks on top of it. When
initially configured, a physical LAN will map to the default VLAN, usually VLAN 1; any
broadcast traffic sent by any host will be forwarded to all other hosts on the network. The
physical network can then be reconfigured into a number of VLANs, such that broadcast
traffic will be restricted to a particular VLAN only. This traffic will be seen only by other
hosts in the same VLAN, not all of the hosts on the same physical LAN.
VLANs can be used to:

• Provide extra security;
• Create logical groups that reflect organisational structure;
• Cut down on unwanted or unnecessary traffic;
• Reduce the impact of broadcasts (see section 3.5.4);
• Ease network management.
However, VLANs are layer 2 constructs and any traffic that needs to exit a VLAN will
require a layer 3 routing decision to be taken, in the same way as if it was a collection of
separate physical LANs connected to a router. The figure below shows the use of a
VLAN to link H.323 videoconferencing systems together.
Figure 2: Simple VLAN Topology

The ports on the switch are put into different VLANs dependent on whether they are connected to
videoconferencing equipment or campus computers.

When a VLAN truck is employed between switches, Class of Service (CoS) can be ap-
plied to the videoconferencing packets, to ensure sufficient bandwidth is allocated to the
traffic. However, in many academic institutions VLANs are used primarily in the control
of broadcast traffic and the building of segmented, secure and sub-netted networks.
3.5.4 Broadcast Traffic

Broadcast traffic can have a sudden and detrimental effect on IP videoconferencing.
Hosts can send broadcast frames for a number of reasons, and the level of broadcast
traffic is almost directly proportional to the number of hosts on a network. Traffic
monitoring reveals that broadcast rates increase sharply above the 5% or 10% baseline for
the network. The worst-case situation is during a ‘broadcast storm’. These can have
various causes, such as wrongly configured equipment or faulty hardware, but the effect
can be catastrophic to traffic on the network; the system becomes overloaded with
broadcast traffic and fails to deliver normal traffic effectively, causing increased latency
and jitter and more severely, lost video frames.
3.6 IP Quality of Service

3.6.1 Overview
In order to keep pace with the increase in network traffic, increasing Internet bandwidth
on its own is not going to be sufficient, but clearly it must happen to avoid traffic
congestion. This effectively means making the transition from single service and best
effort service networks that exist now into multi-service networks, which provide
different levels of service.
IP design inherently provides a 'best effort' service, which is subject to unpredictable

delays and data loss. IP videoconferencing not only requires a lot of bandwidth, but also
has strict timing requirements requiring more than simple best efforts in a congested
networking environment.
Quality of Service (QoS) techniques exist in IP routing technology to mark packets; place
packets into queues that are given weighted priority; signal the network to reserve
network capacity for end-to-end QoS; match traffic to available network capacity (traffic
shaping); and perform network congestion anticipation. However, there is an issue with
scaling with some of these technologies.
Ultimately, such traffic engineering should provide a reliable end-to-end Quality of

Service to the user. End-to-end however means providing service delivery guarantees that
span multiple network management domains and, in the context of the education
network, the management domains are LANs, Regional Networks and the SuperJANET
backbone. In terms of implementing end-to-end QoS, it not only means that standard QoS
technologies must be deployed, but that service level agreements and operational
standards must be in place across the multiple management domains and multi-vendor
routing equipment.

Further information: http://www.ja.net/development/qos/.
3.6.2 Regional and National Implementation

Some Local Authorities and RBCs have implemented QoS for IP videoconferencing
and/or Voice over IP, although to date most IP videoconferencing between schools has
taken place point-to-point within a local authority.
Birmingham Grid for Learning (West Midlands RBC), for example, has enabled QoS
using Diffserv and an IP precedence of 4, with 512kbs reserved on the routers for video
traffic. This has been found to improve quality significantly, even when links and routers
appear to be only lightly loaded.
Reference:
http://www.wmnet.org.uk/wmnet/custom/files_uploaded/uploaded_resources/294/VC1.pd
f
JANET's national model for QoS is currently based on Differentiated Services Expedited
Forwarding (Diffserv EF), using custom queuing. A given percentage of each link on the
network is reservable on a hop-by-hop basis, including access links from the regional
networks.
Traffic marked for differentiated services is policed inbound from the regional networks;
traffic which exceeds the percentage allowance is dropped. It is therefore important for
regional networks to perform tight admission control to avoid problems due to dropped
packets.
QoS on JANET is still under development, and this model is likely to be amended or
changed based on experience. Reference: http://www.ja.net/development/qos/

3.6.3 Classes of Service
At the time of writing, it is anticipated that the following classes will be available:
• IP Premium
• Best Efforts
• Less than Best Efforts
The best efforts service is that which is generally available today, and less than best
efforts supplies a service, which will attempt to use all available bandwidth, until best
efforts or premium traffic requires it.
Typical uses for IP premium are expected to include IP videoconferencing (although this
can, and does, operate well without QoS, where no heavily congested network links are
involved. See Section 3.5 for more information about adequate provisioning of links).
3.7 Multipoint Control Units (MCU) and Gateways

3.7.1 Overview
An MCU is essential for enabling conferences involving more than two videoconferen-
cing systems. MCUs are available to support multipoint IP videoconferences and multi-
point ISDN videoconferences. The MCU acts as a hub to which all of the videoconferen-
cing systems connect, and distributes the audio and video received from each videocon-
ferencing system to the other videoconferencing systems involved. This can be done as
‘continuous presence’ (the screen is divided up and all participants are visible throughout
the call), ‘voice-switched’ (all participants see the current speaker, who in turn sees the
previous speaker), or ‘chair-controlled’ (the chairperson decides which videoconferencing
system sends a video stream). MCUs are sometimes combined with a terminal, gatekeep-
er or, most commonly, a gateway between different videoconferencing technologies, for
example IP and ISDN.
An MCU is either: specially developed hardware, running bespoke software; or software-

based running on a Microsoft® Windows® or Linux® server. Ideally, to enable encoding
and decoding in real time, the amount of compression required by video and audio signals
necessitates hardware processing assistance to the software, which is only possible when
using a hardware-based MCU. Use of a software-based MCU may lead to a reduction in
quality that is experienced in a multipoint conference, when contrasted with directly
linked videoconferencing systems in a point-to-point videoconference. A hardware MCU
is also likely to offer greater stability than a software MCU running on a server.
Some videoconferencing systems offer limited MCU capabilities within the videoconfer-
encing system (typically enabling up to 4 videoconferencing systems to participate in a
videoconference). Various types of hardware MCU are available, some of which are small
scale, usually a sealed unit. Others are chassis based and can be scaled to support a large
number of simultaneous large multipoint conferences. In some cases the scalability of
software MCUs is governed by the purchase of licences.
Depending on configuration, MCUs can allow videoconferencing systems operating at

different call speeds, and audio and video protocols to join the same conference. During
the conference the MCU holds the state of the call. This means if the MCU fails all con-
ferences running on it will be lost. As it is an unavoidable single point of failure, reliabil-
ity and vigilant management are paramount.
A management tool, usually supplied with the MCU, is required for the scheduling of
conferences, and to assist with resource allocation and management. This tool should al-
low conferences to be scheduled to take place in the future, and, to be torn down when
they are completed.
The MCU can either allow videoconferencing systems to dial into a scheduled conference
or the MCU can initiate the conference and dial-out to the videoconferencing systems. If
dial-in videoconferencing is used, a means of circulating dial-in numbers has to be found.
Some allow for the set-up of permanent conferences with a Conference ID (Identifier).
Users can dial-in when they want to participate in a conference. This scenario would be
difficult to operate on a heavily used MCU. There are also security issues associated with
this mode of operation as it is difficult to know who is in the conference. When videocon-
ferencing is taking place over IP, initiation by the MCU can facilitate ease of use and ad-
ditional security. When a conference uses ISDN, the organisation managing the equip-
ment that initiates the conferences will be sent the invoice from the telecomms operator
for the ISDN call charges.
In some instances it is preferable for point-to-point conferences to go through an MCU.

In the case of ISDN conferences, monitoring of the conference is facilitated, and can en-
sure that any technical difficulties encountered are addressed promptly. The difficulties
that are sometimes encountered during connection can be avoided, particularly if the con-
ference is dial-out. Monitoring by the MCU also enables reports to be generated. Such re-
ports can prove invaluable for capacity planning. For point-to-point IP conferences the ar-
gument for initiation by the MCU is the same as for multipoint - ease of use, as the video-
conferencing systems do not need to be operated by users, and additional security.
3.7.2 Gateways
A gateway is usually only required when one or more H.323 (IP) terminals are in a con-
ference with a non-H.323 terminal. The most common application is a gateway to an
H.320 (ISDN) network, although gateways to other types of network do exist. The gate-
way has an interface to both networks and translates the call signals in both directions,
enabling seamless communication. A gateway can be stand alone or incorporated into
MCU.
It is possible that a requirement will develop for gatewaying between H.323, H.320 and
the Access Grid, used by the e-science community. Information about Access Grid can be
found at: http://www.accessgrid.org/.
3.7.3 Deployment of MCUs

At the present time individual schools are unlikely to need, or be able to financially or
technically support, their own MCUs and gateways. Some local authorities or RBCs may

wish to deploy MCUs to stimulate local or regional demand for videoconferencing and to
identify the issues relating to booking and scheduling, technical support, operation and
management.
Service-class MCUs and gateway facilities are recommended for supporting all scheduled
multipoint conferences, especially those that are essential to the operation of an
organisation. Bearing in mind the sophistication and cost of service-class MCUs and
gateways, it is recommended that they be deployed in the core of the network for all
inter-RBC conferences including IP-ISDN gatewayed conferences, and regionally for
intra-RBC conferences as and when there is shown to be sufficient demand. As
videoconferencing becomes ‘mission critical’ it is imperative MCUs are deployed in a
resilient architecture, with redundant capacity, to keep downtime to a minimum.
When a conference is scheduled, if multiple MCUs are deployed, a decision is required

about which MCU is the most appropriate for the conference to run on. There is currently
no technological solution available that will facilitate the intelligent, automated booking
and scheduling of conferences on the most appropriate MCU within a distributed cluster
or hierarchy. At present, the only means of intelligently scheduling booked conferences
on multiple MCUs is to involve the effort of one or more human operators.
The cascading of MCUs, in order to interconnect geographically focused multipoint

conferences, is not part of the H.323 Standard and is not recommended at this stage.
It is envisaged that initially, especially for those regions that do not already have access to
MCU resources, service-class MCUs could be deployed centrally in order to aggregate
and stimulate demand. As regional and eventually local demand increases, additional
MCUs should be deployed appropriately. Throughout this process, issues of security,
resilience and scalability need to be reviewed and addressed. These will also need to be
accompanied by appropriately scaled operational and support services, as well as
management.
3.8 Directory Services

H.350 defines a directory-services architecture for multimedia conferencing for H.323,
H.320, SIP and generic protocols, and was ratified in August 2003 as the H.350 series of
Recommendations (standards).
H.350 is based on the commObject architecture developed by VidMid-VC, the Video

Middleware working group jointly sponsored by Internet2, ViDe and the ViDe.net project
funded by the National Science Foundation. Further information can be found at
http://lab.ac.uab.edu/vnet/.
The implementation of the H.350 standard is still in its infancy and collaboration between
a number of national research and education networks is currently underway. It is too
early to be prescriptive about the implementation of regional directory services. Further
work needs to be undertaken in collaboration with the Regional Broadband Consortia.

Quality
4.1 Standards
In order to ensure consistent interoperability between different CODECs and between the
CODECs and the MCU and Gatekeepers, conformance to the relevant ITU-T Standards is
an absolute requirement. The detail of these standards is provided at:
http://www.video.ja.net/stan/.
The UK Government’s e-Government Interoperability Framework (e-GIF) makes

recommendations with respect to the adoption of IP conferencing standards. These
include the H.323 Standard, for the assembly of audio, video, data and control, and can
be found at: http://www.govtalk.gov.uk/interoperability/egif.asp.
An overview of minimum and common standards, and additional features/standards,

associated with videoconferencing systems is provided in the following sub-sections. It
should be noted that standards-based equipment from different manufacturers might not
interoperate, at least initially, due in differing implementations of the standards. These
issues can usually be resolved with reference to the manufacturers. Experience has also
shown that systems from the same manufacturer, running different hardware versions,
may encounter issues with interoperation. When new equipment is being set up, time
should be allowed for troubleshooting, prior to operational use.
4.1.1 Minimum Standards

These are necessary for basic H.323 or H.320 conferencing:
• Support for the TCP/IP and ITU-T H.323 standards (preferably v.2 or higher);
• Support for the G.711 audio compression algorithm;
• Support for the ITU-T H.261 video compression algorithm;
• QCIF video format resolution (176 x 144 pixels);
• An Ethernet LAN 10/100 Mb/sec network interface; or
• H.320 compliance and a connection for ISDN2 conferencing at 128Kb/sec.
4.1.2 Common Standards

These are what you should expect to have on a modern videoconferencing system:
• For ISDN use: ITU-T H.320 standard compliance and an ISDN6 network interface;
• For IP use: ITU-T H.323 standard compliance;
• Support for additional audio compression algorithms: G.723, G.728;
• Support for the ITU-T H.263 or H.263+ video compression algorithms;
• CIF video format resolution (352 x 288 pixels);
• Up to at least 24 frames-per-second at CIF resolution, at 384 Kb/sec.;
• Video inputs/outputs: Composite video, S-Video, PAL/NTSC video formats, XGA;
• Audio inputs/outputs: handset, headset, external microphone, stereo, full duplex;
• RS-232 Serial and USB communications ports;
• Ethernet LAN 10/100/1000 Mb/sec full-duplex network interface;

• Remote management (over the network);

• Support for the T.120 standard (ITU-T Recommendation) for data sharing;
• Capable of operating at a minimum of 384Kbps (ISDN6) and up to 768Kb/sec
(H.323);
• Remote control unit.
4.1.3 Additional Features/Standards

These would be available on higher specification and/or the most recent systems:
• Web-based interface for remote management and configuration;
• Camera pan, tilt and zoom (up, down, left, right, zoom in, zoom out);
• Auto-tracking (focussing on the person who is currently speaking);
• Support for the H.264 low-bandwidth (based on MPEG 4) video compression
algorithm;
• Capable of operating at up to1920Kb/sec (or 2Mb/sec).
The number of frames per second (FPS) isn’t necessarily an indicator of picture quality,
as the video compression algorithms allow for a trade off between FPS (which gives
smooth movement) and picture definition. Some manufacturers use their own proprietary
encoding algorithms for audio or video compression when in a conference with their own
products, and these often give a higher quality. These systems use the open standards
when inter-working with other manufacturers’ equipment.
4.1.4 Audio Levels

There is no industry standard for audio levels, many new products do not have
adjustments for audio send levels and are set to a permanently low in level. Results of
testing by VTAS would indicate a wide and significant variation in videoconferencing
system audio levels; experience has shown this can have a detrimental impact of
multipoint videoconferences.
A consistent audio level transmitted from each videoconferencing system in a multi-site

conference is required to ensure that there is no tendency for a videoconferencing system
to adjust the received volume control, as some participants in the conference are
perceived as being louder or quieter than others. Adjusting the volume on a site-by-site
basis is time consuming and frustrating for the user and will have a detrimental effect on
the quality of echo cancellation. In addition a participant with a quiet output may not
cause voice switching to occur in a multi-site conference. During a point-to-point
conference the receiving participants could adjust their volume control to compensate for
a loud or quiet site, as this would only happen once during the call echo cancellation
could adjust for this.
Adjusting volume levels in an environment where there is excessive background noise

creates various problems, firstly it masks the intelligibility of the audio received at the
remote sites and increases fatigue during a conference, and in addition it may cause
random voice switching.

4.2 Quality Assurance

Consistent video and, more especially, audio quality are vital for a successful
videoconference. Clear audio at a standard volume level is necessary for all
videoconferencing systems to be heard without recourse to adjusting local speaker
volume levels. The user cannot adjust the audio input level; this is undertaken within the
CODEC, which amplifies the audio to the correct level before transmission. If this level
is not consistent for all systems in a multipoint conference, then the MCU may have
problems switching video, based on the audio cues in a voice-switched conference.
Undertaking regular Quality Assurance Tests is recommended to monitor that the

equipment is configured suitably for use with other systems and the MCUs. Such tests
can also identify issues associated with IP networking or ISDN lines. For example, the
following are assessed as part of the Quality Assurance Test that is currently in place for
the HE and FE communities:
• Mute, Microphone and Ambient Noise levels (quantitative)

• Echo and Doubletalk (qualitative)
• Audio (qualitative)
• Video (qualitative)
This test is undertaken at six-monthly intervals and takes 15 minutes.
It is recognised that such a test, while recommended, may not be appropriate or desirable
in all circumstances, especially ad hoc point-to-point conferences. In these cases, it is
clearly beneficial for those concerned to test the connection and their equipment in
advance of conferencing, in order to ensure that the conference will be of acceptable
quality. This is especially true for conferences involving international participants, where
there may be additional issues concerning equipment interoperability and different time
zones.
Whatever approach is adopted, it is essential that the expectations of those involved in the
conference be met satisfactorily. A strong deterrent to further videoconferencing is
presented if a conference is of unacceptable quality or presents technical challenges when
there is no technical support available.
4.3 Videoconferencing Environment

There is no doubt that room design and layout can play a large part in enhancing the
quality of the videoconference experience to a level at which the apparent distance
between the participants is minimised.
Videoconferencing should not take place near to sources of low frequency noise, such as
lift shafts. Nor should facilities be sited next to crowded corridors or busy entrances.

The addition of curtains, carpets and softer furnishings than normal, all contribute to
clarifying the audio by reducing the echo. Full-length curtains covering both windows
and walls, associated with additional artificial lighting, can also prevent the wide
fluctuations of natural light, which can adversely affect the video quality.
Room colours should be mid-tone, tending towards lighter shades. Blue is frequently
used. Patterns and strong contrasts should be avoided. Where paint is used it should have
a matt finish.
Building the videoconferencing equipment into a partition wall can hide the rear of the
equipment and most of the cabling, making it more secure and safer for all participants.
Providing ducting for all cables, including floor ducting, minimises the hazards.
Videoconferences involving desktop or roll-about systems are often undertaken in

unmodified environments, such as classrooms or offices, and their quality is unlikely to
be optimal in these circumstances. A few simple steps can be taken to enhance the audio
and video quality of these environments, such as closing curtains or blinds, or the use of
one or more mobile office partitions, which can also double as a simple plain backdrop.
Cost is the major constraint when considering room refurbishment, but the environmental
and safety issues should be given serious consideration before purchasing and locating
videoconferencing equipment.
Further information about videoconferencing room design can be found in the following
document: http://www.video.ja.net/rooms/. Please note that this document is intended for
guidance only.
Security
5.1 Overview
As with any equipment that is connected to the Internet, or is available for public use, the
deployment of videoconferencing equipment has security implications. Issues to be
considered include:
• Personal privacy
• Property security
• Network security
The Data Protection Act (1998) covers issues concerning personal data. Conferences
should not be recorded without the explicit agreement of participants. Conference
booking systems or other databases or systems, which contain data of a personal nature
must be registered, and those managing such systems should have sought and obtained
the appropriate permissions, as required and specified by the Data Protection Act.

Those distributing live or recorded conferences, whether by multicast or unicast

streaming or download or on physical media, should be sensitive to both the Data
Protection Act and Intellectual Property Rights.
All property is vulnerable to vandalism, theft or accidental damage. Conferencing and

collaboration equipment can be expensive and appropriate insurance should be
considered. Not having some or all of the equipment available for scheduled conferences
or teaching, while awaiting replacement and reconfiguration would be disruptive.
The following preventative measures should be considered:

• Securing windows and locking doors;
• Obscuring windows, so that equipment cannot be easily seen from outside;
• Locating equipment on floors other than the ground floor;
• Installation of Passive Infra Red movement detectors and alarms;
• Installation of video surveillance;
• Building the videoconferencing equipment into a partition wall.
Appropriate risk analysis should identify which measures would need to be implemented,
in order to maintain an uninterrupted service.
5.2 Network Security

As with all systems connected to the Internet, network security issues are important. The
risks to videoconferencing systems can be mitigated by taking similar steps to those taken
for other networked equipment, such as firewall implementation and software update
regimes etc.
Most networks are protected by firewalls running at the point of entry/egress to protect
PCs and other devices connected to the network. However, H.323 traffic creates problems
for firewalls, as not all call parameters are predictable in advance, as they are negotiated
during the call set-up at the beginning of each conference. There are options available for
allowing H.323 traffic to operate securely, including the use of an H.323 proxy, or an
H.323-aware firewall (see Section 3.6). It is possible to purchase H.323 modules for some
existing firewalls.
Some users may be concerned about the security of information discussed in a

videoconference; this risk is no greater than that to information contained in email
correspondence. Theoretically it would be possible for attackers to ‘snoop’ the
conferencing data in transit, or to attack the H.323 components themselves over the
Internet, leading to a loss of service or other undesirable consequences. For all risks, the
likelihood of the risk should be considered, and the impact gauged. While software tools
exist to capture and relay H.323 traffic, there are very few, if any, known cases of such
non-lawful interception.
There is a risk of unwanted participants joining a multipoint videoconference by dialling

into the MCU and listening in silently (muted). By using an H.323 architecture where the

centrally managed MCU calls out to conference participants, such a risk is dramatically
reduced.
There has been a growing number of denial-of-service security incidents on the Internet
recently, well-known examples being the Blaster and Nachi worms. Such infections may
cause severe network congestion, leading to systems failure (e.g. if a firewall cannot
handle the volume of new connections being made) or degradation in service (e.g. packet
loss leading to poor audio-visual quality in H.323 sessions). The risks and threats are no
greater for H.323 videoconferencing systems than any other desktop systems in a
network. Best practice in software updates and firewall configurations should be applied
to all systems. Many H.323 systems are dedicated units with less potential for
compromise, but the quality of ‘desktop’ systems that may run a more complete operating
system (e.g. Microsoft® Windows® XP) is rapidly improving.
Management of videoconferencing systems is generally offered by:

• Telnet access using a login and password;
• Web (HTTP) access with username and password;
• Trivial File Transfer Protocol (TFTP) uploads with username and password.
The use of Telnet or HTTP sessions, as opposed to SSH or Secure Hypertext Transfer
Protocol (HTTPS) sessions, means that usernames and passwords for equipment access
are sent in plain text over the network. An attacker may thus be able to snoop passwords
in transit and gain access to critical H.323 components. It is thus important that
management of the device(s) in question is performed locally, over some dedicated
infrastructure, or at least over a fully switched network where the chances of access
information being snooped are minimised. An organisation should use filtering at a
border firewall to block external access to management interfaces where not required
from external locations.
It is recommended that videoconferencing systems should have local passwords set to

protect system settings, where users are able to access such settings (e.g. via keyboard or
remote control). Other problems to look out for with passwords include the use of default
usernames and passwords, which are public knowledge, and a potential problem if not
changed when the equipment is installed, e.g. ‘admin’ and ‘GWrv’ is a combination used
in one particular piece of equipment.
In some cases devices may be upgraded or hold configurations served by TFTP, or

performed via FTP. In such cases the security of the TFTP server is important, lest default
settings on the equipment be changed.
A VTAS paper which focuses on H.323 videoconferencing security is available at:

http://www.video.ja.net/323security.pdf
A more detailed discussion of general network security is available in the Network

Security document.

Services
6.1 Support Services
6.1.1 Advice and Guidance
Setting up a videoconferencing environment and system to ensure all the requirements
are taken into account can be complex. Therefore advice and guidance services are
required to ensure all requirements are taken into account and an appropriate solution is
deployed. Advice and guidance should cover all aspects of:
• Choice of videoconferencing system;

• Compatibility and interoperability of systems;
• Choice of appropriate environment;
• Changes required to environment;
• Local networking issues;
• Set up and configuration of videoconferencing system and peripheral equipment;
• Configuration of gatekeepers.
Such advice and guidance should take the form of paper/web documents, an advisory
helpdesk and on-site consultancy. There is a requirement for this type of technical support
at all levels: locally, regionally and nationally. Local Authorities are best placed to
provide advice and guidance to schools.
It is well documented that it only takes one or two bad experiences to deter users from
videoconferencing. On occasions, when participating in conferences, users will
experience faults. Past records demonstrate that faults occur mainly at the start of a
conference, especially when connecting to a conference using an ISDN system. However,
other faults with conferences do occur infrequently. In all instances, it is essential that
there is a publicised mean of fault reporting and that technical assistance is available to
ensure that the conferences can continue. This can be provided locally, regionally and/or
nationally. Those providing such support should be given (remote) access to the
videoconferencing systems and/or the MCUs participating in the conference, in order to
provide fault diagnosis and re-start the conference if necessary.
6.1.2 Training
Both technical and user training are necessary to ensure the effective operation and use of
videoconferencing systems.
Technical training covering installation, configuration, maintenance, operation and

troubleshooting is required, with support generally provided by a Local Authority. This
should in turn be backed-up by a regional or national helpdesk. With room-based or roll-
about systems, remote access into the CODEC, from the helpdesk, should be set up to
assist with troubleshooting.

Users also require appropriate training in the use of videoconferencing systems, to ensure
their confidence with the operation of the equipment. Training in effective strategies for
the use of videoconferencing as a tool for teaching and learning, is also recommended for
teaching staff, as there are pedagogical issues, which may need to be highlighted. Local
Authorities should provide such training to schools.
6.2 Operational Services

Operational services should facilitate the opportunity for service users to participate in
videoconferences, not only with other users within their educational sector, both
nationally and internationally, but also with those outside that sector. For example,
schools may which to conference with those in other academic sectors, commercial
organisations, museums and other archive centres, both nationally and internationally.
Both point-to-point and multipoint conferences should be possible, regardless of the type
of connection (typically IP or ISDN) or the audio and video protocols used by the
videoconferencing systems.
The service should allow for the management and deployment of the infrastructure
necessary to allow seamless connection across both IP and ISDN networks between
systems.
Operations staff with appropriate expertise will be required at regional and national levels
to maintain the network infrastructure, videoconferencing equipment and services.
Infrastructure may include VLANs, switches and routers. Equipment comprises
gatekeepers, gateways, MCUs, and servers for booking and directory services. User
services should encompass support, guidance, fault reporting and resolution, and
management of maintenance contracts. Management and operations staff within different
management domains will be required to co-operate to ensure the interoperation of
infrastructure, equipment and services.
6.2.1 Initiation of Calls

For ease of use, calls should be initiated by the MCU to all the videoconferencing
systems participating in a conference. This removes the need for dial-in information to be
circulated to local users and for the participants to initiate their videoconferencing system
to join the conference. Providing the videoconferencing system is connected to the
network, local users only need turn it on and the conference will come up. (It is possible
to protect against unauthorised videoconferencing systems connecting to an
videoconferencing system in the configuration of the gatekeepers). This mode of
operation removes an unnecessary stress from participants at the beginning of a
conference, as they will not have to operate the videoconferencing system and facilitates
the increased likelihood of a smooth start to a conference.
6.2.2 Booking and Scheduling of Conferences

Service users should be able to book conferences well in advance (i.e. years) of the time
they take place. This will allow for local timetabling, and local and central resource
allocation. An on-line booking service should be provided, that will enable authenticated
users, from the education sector, to book conferences with any other videoconferencing

user or system. The booking service should allow for the modification and searching of
bookings; however, this should be limited to the conferences that the school is
participating in. The booking service should provide reports of service usage.
From these bookings, conferences should either be automatically or manually scheduled

on the MCUs. MCUs should be able to hold future reservations, and automatically initiate
and tear down conferences.
It is likely that if many heavily used MCUs are deployed in different management
domains, multiple booking services will be needed as well. Such a scenario would be
more complex for users, as they would need to understand how to use more that one
booking service and what type of conferences should by hosted on the various MCUs (for
example, local or international conferences.
6.2.3 Resilience
MCUs and other operationally critical equipment should be deployed with resilience in
mind, keeping single points of failure to a minimum or removing them entirely. Single
points of failure should be identified, with effective workarounds and recovery plans
drawn up.
6.2.4 ISDN Call Charges

Unlike IP calls, all ISDN calls incur call charges. Typically an ISDN2 call will cost twice
that of a single call; similarly an ISDN6 call will cost six times the cost of a single call.
The cost of outgoing calls made by a central service, whether national or regional, would
need to be recovered from the relevant organisation.
ISDN billing information should be generated from either the booking service or the
MCUs, so that invoices for ISDN call charges can be generated and sent either to LAs or
RBCs.
6.2.5 Fault Reporting and Resolution

All central equipment requires ongoing management, to ensure the timely reporting and
resolution of faults, both with conferences and with the equipment itself. A central
telephone number should be published, for the reporting of faults with videoconferences.
This telephone should be answered in person during the hours of operation of the service.
6.2.6 Technical Development and Upgrades

The development of videoconferencing technology continues to move very quickly, with
regular hardware and software upgrades. It is not possible for hardware or software
versions on central equipment to be frozen, as interoperability issues would be
encountered when conferences involve more up-to-date videoconferencing systems. Also,
service users want to use the latest features and standards that are available on their local
systems, which must be supported on the central service. Moreover, manufacturers and
suppliers do not provide support or maintenance on outdated systems. Issues and bugs are
frequently encountered with the upgrade of both hardware and software, which have the
potential to have an adverse effect on videoconferencing service performance (at worst

such bugs can cause equipment to fail). It is therefore essential that all upgrades are
thoroughly tested in a non-service environment and all issues resolved, prior to
deployment in a service environment.
6.3 Management Services

Initially, national management of aggregated MCU resources and support services is of
benefit to users, especially to those in areas of low demand or deployment. Users have a
single point of contact for all videoconferencing requirements, regardless of whom they
are conferencing with or the technology involved. Also, an overview of the wide area
network infrastructure, as well as all of the videoconferencing equipment, is required to
facilitate trouble-free national and international conferencing.
However, there is also scope for the deployment of regional videoconferencing services,
as and where regional demand is identified. A hierarchical approach to the deployment of
national and regional services leads directly to a reduction in duplication of effort. Global
recommendations about hardware and software are possible, and national or regional
purchasing arrangements can be put in place, which allows equipment to keep pace with
technological developments. This maintains standardisation, which in turn ensures the
interoperation of all hardware and software.
If demand is aggregated, nationally and regionally as appropriate, a scalable service can

be provided, with equipment that is resiliently deployed. Equipment can be deployed in
regions of highest demand, and regionally or nationally managed as appropriate, thus
preserving the scalability of the service. As demand further increases, more emphasis can
be placed on the deployment of regional or even local equipment and support services.
6.3.1 Maintenance Contracts

Some desktop systems are of such a low cost, that maintenance cover is neither offered
nor viable. Roll-about and room-based systems are more expensive and complex and
should be kept under maintenance. The centralisation of maintenance agreements tends to
be more cost effective and allow for a more rapid response time. Central maintenance
agreements can be managed regionally or nationally, and brokered by the support
helpdesk. If a number of videoconferencing systems of the same make and model are
being covered, an advance replacement service can be agreed, to minimise the impact of
a failure and reduce downtime. Maintenance arrangements should include free software
upgrades, which can be costly if purchased on a per system basis. All faults with systems
can be reported to the helpdesk, who can take the appropriate action to effect a resolution.
The equipment necessary to provide a central, resilient videoconferencing service to

support gatewayed and multipoint videoconferencing is complex and expensive.
Regardless of where it is located, central equipment should all be kept under maintenance
with a specialist contractor, who holds spares. The maintenance contract should be
carefully drawn up, to ensure all faults are fixed within a timescale that will not adversely
affect the quality and operation of the service. The maintenance agreement should include
software upgrades and patches. The cost of maintenance should be factored into the
ongoing costs for the operation of the service. Contingency planning should document

how the service will continue operations and resilience be provided when equipment fails
and is being repaired.
It should be noted that some organisations that typically use H.323/IP videoconferencing,
view it as business critical and have ISDN lines installed to provide a backup, in the event
of a failure of their network. In such cases ISDN lines have to be regularly tested and
brought into use, to ensure their continued availability.
6.3.2 Capacity Planning and Procurement

It is envisaged that the initial demand for videoconferencing and the associated support
services by the schools sector will be relatively modest. However, if the growth in use
reflects that of the HE and FE communities, use and demand will grow considerably.
Nevertheless, it may take some time for videoconferencing to be integrated into the
curriculum and issues such timetabling to be resolved. These are likely to be the major
challenges for schools.
Growth in the use of videoconferencing can be significantly encouraged by the adoption

and use of the technology by senior managers for administration purposes and meetings.
As demand and use grows, more videoconferencing systems will be procured locally, and
support services and central equipment must be scaled to cope with increased demand.
Registration of all systems and booking of conferences provides valuable statistical data
that can be used to predict growth and changes in usage trends. As the speed of such
growth is unknown, the capacity of the central equipment should be kept under continual
review, to ensure scaling of the service to meet demand.
Large-scale regional procurements are likely to take place through the European
procurement process, or a purchasing agreement that is put in place as an outcome of a
procurement exercise. Time and resources to undertake such procurements should be
factored into capacity upgrades.
H.323 videoconferencing, in particular, is an area where new standards still being agreed
and manufacturers are developing new hardware for MCUs. Provision for MCU
hardware upgrades should be factored into the cost of service operation. It is not usually
possible to freeze MCU hardware, as this may lead to interoperability issues between
hardware and software, and between MCUs and videoconferencing systems. It would
also mean that new, potentially useful features could not be offered to users.
6.3.3 Liaison
Aggregation of supply can bring about closer, more productive, working relationships
with manufacturers of all videoconferencing equipment. One outcome of which is an
improved response to feature requests. Liaison with the manufacturer and supplier
organisations ensures roadmaps are made available in a timely manner, which allows for
the planning of upgrade paths and timescales. Effective communication facilitates
appropriate engineering support during upgrades and timely bug fixes.

6.3.4 Reporting
Reporting requirements are dependent on the Service Level Agreements and monitoring
that have been put in place, and also on what the data is to be used for (e.g. capacity
planning, trend prediction). Statistical information can be provided by the MCU,
providing the software and licensing are in place, by a booking service and by a helpdesk
database. Information that can easily be made available, on a monthly basis, is:
• Number and duration of conferences;

• Purpose of conferences;
• Number of systems involved in conferences;
• Number of IP only, ISDN only and gatewayed conferences;
• Number of systems registered to use the service;
• Number of systems actively using the service;
• Availability of central equipment;
• Duration and reason for outages of central equipment;
• Number of failed conferences;
• Number and type of calls to the helpdesk.
6.3.5 Review
The overall service provision should be reviewed regularly, to ensure it meets the needs
and requirement of the users. The means of collecting feedback will vary according to the
aspect of the service under review.
All contracts, including those with manufacturers and suppliers of both goods and
services, should have a review period incorporated into them. The review period will vary
according to the nature of provision and size of contract.
6.4 The JANET Videoconferencing Service

6.4.1 Overview
Many institutions in the Higher and Further Education communities deploy
videoconferencing systems and most of these are actively used. Generally these
organisations do not deploy and manage MCU facilities locally or regionally, preferring
instead to benefit from the centrally provided JANET Videoconferencing Service (JVCS),
which supports multipoint conferencing and gateways. The principle elements of the
JVCS are:
• Scheduling of videoconferences on central multipoint and gateway equipment;

• Quality Assurance testing of videoconferencing venues;
• Management and resolution of videoconferencing faults and incidents;
• Day-to-day support of videoconferences and users of videoconferencing;
• Management and operation of a booking service;
• Support for out-of-band data and application sharing, including the management of an
ILS (Internet Locator Service) server;
• Operation of a multicast gateway;

• Monitoring;
• Reporting.
The JANET Videoconferencing Management Centre operates the JANET

Videoconferencing Service for registered videoconferencing systems, providing H.323
and H.320 multipoint services. Registered systems are those that have passed an initial
Quality Assurance test and are entered into the booking service as a bookable entity. Most
of these are located in suitably equipped rooms.
This service is provided to support videoconferencing principally from room-based or

roll-about systems. Every effort is made by both management and the operators to ensure
conferencing is high quality and trouble-free.
6.4.2 Relevant Development Projects

Conferencing on Demand (CoD)
The UKERNA Conferencing on Demand project is assessing the feasibility of providing

on-line self-administered IP videoconferencing MCU resources to the JANET com-
munity. IP MCU resources will be scheduled via an on-line scheduling interface, provid-
ing the capability of scheduling an IP videoconference instantly or up to 48 hours in ad-
vance.
It is anticipated that a Conferencing on Demand Service would not require sites to pass a
JVCS Quality Assurance Test, and would allow any H.323 compliant videoconferencing
system to use resources. The service would require sites to undertake a minimal initial re-
gistration, which will be limited to appropriate JANET connected sites. It is expected
that a Conferencing on Demand pilot will be launched in Q2 2004.
Automated QA Testing (Auto QA)
The UKERNA Automated QA Test Project is assessing the feasibility of providing a ded-
icated on-line audio and video analysis tool for use within the JANET community. The
system will provide feedback to users on their current audio and video levels. The Auto-
mated QA Test system will complement (not replace) the current JVCS Quality Assur-
ance procedure. The Automated QA Test system would be enabled via the Conferencing
on Demand scheduling tool.

References
DfES Standards Fund Guidance
ICT in Schools Standards Fund Grant 2004-05
Guidance for Schools and LEAs
http://www.dfes.gov.uk/ictinschools/funding/
UK Government’s e-Government Interoperability Framework (e-GIF)

http://www.govtalk.gov.uk/interoperability/egif.asp.
Videoconferencing Standards Authorities

ITU: http://www.itu.int/ITU-T/publications/index.html
ISO: http://www.iso.ch/iso/en/ISOOnline.openerpage
IEC: http://www.iec.ch/
IETF: http://www.ietf.org/
Videoconferencing Standards
JANET Video Technology Advisory Service
http://www.video.ja.net/stan/
Video Conferencing in the Classroom

Communications Technology across the Curriculum
Tim Arnold (Ed.), Steve Cayley and Mike Griffith
Devon County Council 2002
Video Conferencing in Education:

Meeting Teachers and Learners Support and Training Needs
Advisory Group on Computer Graphics - Support Initiative for Multimedia Applications
Chris Schnurr and Carmel Smith February 1995, ICBL, Heriot Watt University
http://www.agocg.ac.uk/reports/mmedia/video4/title.htm
What the research says about video conferencing in Teaching and Learning
Becta Research Report
http://www.becta.org.uk/research/reports/docs/wtrs_vidconf.pdf
Video conferencing in the curriculum

Becta ICT Advice
http://www.becta.org.uk/leas/leas.cfm?section=7_1&id=1137
Video Pals Videoconferencing Project

http://www.watlingview.herts.sch.uk/vc/
Using Video to Develop Communications Skills

http://www.e2bn.net/e2bn/web/e2bn_tng/e2bn_main/acon_devcomm.htm

How to choose a video-conferencing system

Becta ICT Advice
http://www.ictadvice.org.uk/index.php?section=te&rid=606&country=eng&pagenum=1
&NextStart=1
What is video conferencing?

Becta ICT Advice
http://www.ictadvice.org.uk/index.php?section=te&cat=005003&rid=188
Videoconferencing
Learning and Teaching Scotland
http://www.ltscotland.org.uk/services/videoconferencing.asp
Tips for successful videoconferencing

Learning and Teaching Scotland
http://www.ltscotland.org.uk/files/videoconferencingtips.pdf
E2BN Products & Practice

http://www.e2bn.net/e2bn/web/e2bn_tng/e2bn_prod_prac/index.htm
What is a virtual private network?

Becta ICT Advice
What is a firewall?
Becta ICT Advice
JANET H.323 Architecture Group Report

UKERNA, December 2001
http://www.ukerna.ac.uk/development/
VTAS Security Guide for H.323 Videoconferencing

http://www.video.ja.net/323security.pdf
H.264
http://www.lsilogic.com/products/islands/h264/H.264_MPEG4_Tutorial.pdf
http://www.wipro.com/insights/mpeg4videocoding.htm
MPEG-4
http://www.chiariglione.org/mpeg/standards/mpeg-4/mpeg-4.htm
Videoconferencing Audio and Video Equipment

VTAS Guide
http://www.video.ja.net/av/

H.323 Videoconferencing Components

JANET Factsheet
http://www.ja.net/documents/factsheets/038_IP_Components.pdf
Video Conferencing Between Local Authorities

Mark Eastham, Synetrix
West Midlands RBC
http://www.wmnet.org.uk/wmnet/custom/files_uploaded/uploaded_resources/291/VC.pdf
Videoconferencing over West Midlands RBC [Using QoS]

http://www.wmnet.org.uk/wmnet/custom/files_uploaded/uploaded_resources/294/VC1.pd
f
JANET QoS development

http://www.ja.net/development/qos/
Tandberg and Packet Loss

http://research.ihets.org/PDF/pdf_videoconferencing/D5016513_TANDBERG_and_Pack
et_Loss_120302.pdf
RSVP Protocol Overview

http://www.isi.edu/div7/rsvp/overview.html
Cisco TN3270 IP Precedence and TOS Configuration-IBM Presentation Services

http://www.cisco.com/en/US/tech/tk331/tk339/technologies_tech_note09186a0080093da
5.shtml
The Welsh Video Network

http://www.wvn.ac.uk/
Video Conferencing Guide

Fujitsu Services Ltd 2001,
East Midlands Broadband Consortium
Cisco Certified Network Associate Study Guide

Todd Lammle, Third edition. SYBEX Inc 2002
The Visual Communications Handbook

Amanda Azran, Radvision 2003
Cisco Glossary
http://whatis.techtarget.com/
Learn the net

http://www.learnthenet.com/english/index.html
FOLDOC - Free On-line Dictionary of Computing

http://foldoc.doc.ic.ac.uk/foldoc/index.html

Webopedia
http://www.webopedia.com/
Regional broadband Consortia (RBC)

http://buildingthegrid.becta.org.uk/index.php?locId=143
Network Design
DfES ICT in Schools Network Services Project
UKERNA, March 2004
Network Security
DfES ICT in Schools Network Services Project
UKERNA, March 2004

Appendix A: Glossary
This glossary explains the terms used in this document. An extensive videoconferencing
glossary can be found at the JANET Video Technology Advisory Web site:
http://www.video.ja.net/resources/glos.html. An extensive general networking glossary
can be found at the JANET National User Group Web site:
http://www.jnug.ac.uk/netglossary.html
Access Router
A router, commonly located on a customer site, which provides the connection
point to the service provider's network.
Address
In this document refers to an IP address. An IP address is the unique layer
identifier for a host on the local IP network.
Address Resolution
A means of converting the address of a videoconferencing system into the
corresponding IP address.
Admission Control
Controls configured on equipment in the videoconferencing network enabling a
videoconferencing system to make a call/receive calls or blocking these features.
Aperture
The camera lens opening, the size of which is either fixed or adjustable.
Auto-sensing
This procedure involves probing the capability of the network using low-level
signalling techniques to select compatible Ethernet speeds.
Auto-tracking
This describes a feature of video cameras that track and focus on the current
speaker, usually either by sensing movement or voice position.
Bandwidth
The capacity of a communication link (normally measured in bits per second).
Best Efforts
A network service where no packet is treated any differently from any other; no
guarantees about speed of delivery or even of actual delivery are made. Often
used in an IP QoS context to refer to the default network service.

Border
The boundary between one network management domain and another; the
connection between the RBC and the National Interconnect is the border between
the RBC and JANET.
Bridge
A connection between three or more conference sites, enabling traffic to pass
simultaneously between all the sites. Videoconferencing bridges are MCUs
(Multipoint Control Units) and Gateways.
Broadband
A transmission medium capable of supporting a wide range of frequencies. It can
carry multiple signals by dividing the total capacity of the medium into multiple,
independent bandwidth channels, where each channel operates only on a specific
range of frequencies. [Source: RFC1392]
The term has been adopted in common usage to refer to connections to the
Internet at speeds above 128Kbps.
Broadcast
A transmission to multiple, unspecified recipients. On Ethernet, a broadcast
packet is a special type of multicast packet which all nodes on the network are
always willing to receive.
Call Control
Refers to the signalling involved in setting up, monitoring, transferring and
disconnecting a videoconferencing session.
Cascading
Usually used to describe the cascading of MCUs, to support a large multipoint
videoconference, involving more participants than a single MCU will support.
Cat5
Category 5 cabling is an American National Standards Institute (ANSI) standard
for unshielded twisted pair cables.
Chair-controlled
In this mode of videoconference operation, one conference participant controls
who is allowed to speak by means of either hardware or software control.
CIF (Common Intermediate Format)

Refers to size of streamed video picture after encoding. CIF is 352 pixels by 288
pixels.

CODEC (COmpressor DECompressor)

The hardware or software that provides the compression, decompression and
signal processing. It enables high bandwidth analogue sound and vision signals to
be converted to digital code, and transmitted and received over limited bandwidth
transmission paths (also, CODer, DECoder.)
Collaboration
Various tools for collaboration can be deployed in a videoconferencing
environment to facilitating conference participants to work jointly on documents
that are shared electronically.
Composite Video
A type of video signal in which all information - the red, blue, and green signals
(and sometimes audio signals as well) - are mixed together. This is the type of
signal used by televisions in the United States.
CP (Continuous Presence)
Continuous presence allows a conference participant to view multiple participants
on one screen at the same time.
Data Sharing
Data sharing is the simultaneous display of the desktop (screen) of one computer
(or of an application running on that computer), on another display at a different
location, with changes updated on both displays in real time.
Decoding
The conversion of the digital code carrying the sound and vision, back into
analogue mode.
Default Deny Policy

This is a policy implemented on a firewall to block all undefined traffic it is
explicitly told to permit.
Delay
The time taken for a signal to pass through a network, from the sending
videoconferencing system to the receiving one.
Diffserv (Differentiated Services)

Differentiated Services is a protocol for specifying and controlling network traffic
by class so that certain types of traffic get precedence - for example, video traffic,
which requires a relatively uninterrupted flow of data, might get precedence over
other kinds of traffic.

Directory
The implementation of directory services can support the association of
individuals with videoconferencing systems, searchable pages, and clickable
dialling. Directory services can also assist in the configuration of
videoconferencing systems, and user authentication based on authoritative data
sources. H.350 defines a directory-services architecture for multimedia
conferencing for H.323, H.320, SIP and generic protocols has recently been
ratified.
Directory Gatekeeper
The deployment of directory gatekeepers in the videoconferencing network
enables videoconferencing systems’ addresses to be resolved and calls routed
without every gatekeeper being aware of all other gatekeepers. Gatekeepers are
deployed hierarchically, with the National Gatekeeper providing directory
services for international videoconferencing.
Domain
On the Internet, a domain consists of a set of network addresses. This domain is
organized in levels. The top level identifies geographic or purpose commonality.
The second level identifies a unique place within the top-level domain. Lower
levels of domain may also be used.
DOS (Denial-of-service attack)

An incident in which a user or organisation is deprived of services they would
normally expect to have. Typically, the loss of service is the inability of a
particular network service, such as e-mail, to be available or the temporary loss of
all network connectivity and services. A denial-of-service attack can destroy
programming and files in a computer system.
Doubletalk
When a number of participants speak simultaneously in a videoconference.
Videoconferencing systems should support doubletalk, to allow natural
conversation.
Echo Cancellation
The CODEC delays the vision signal by approximately 200 milliseconds. To
maintain sound/vision coincidence the audio signals are delayed by a similar
amount. This time delay produces unacceptable echo into the conference. Echo
cancellation is introduced electronically to reduce this echo to a workable level.
The conference environment also influences the amount of echo, so echo
cancellers need to adjust to the acoustics of the conference room in use: this
process is termed ‘training’.
Encoding
The conversion of the analogue sound and vision signals into digital code.

Endpoint
The network device at the end of a network connection, such as a
videoconferencing system. The local endpoint is the videoconferencing system
sending your video and audio signals, and receiving video and audio signals from
other, remote, endpoints involved in the videoconference.
End-to-end
A phrase used when reviewing the provision of a reliable service between two
hosts, usually across multiple management domains. All aspects of network
provision must be considered to ensure traffic passes between the hosts with as
little delay as possible.
Ethernet Frames
Used on a LAN to determine how a packet is put on the network. Ethernet
provides four different frame types. These are not compatible with each other. For
two hosts to communicate with each other they must use the same frame type.
Firewall
Router or access server, designated as a buffer between any connected public
networks and a private network. A firewall router uses access lists and other
methods to ensure the security of the private network.
Frames
A logical unit of information, sent by the Data Link layer over a transmission
medium. The term often refers to the header and trailer, employed for
synchronisation and error control that surround the data contained in the unit.
FTP (File Transfer Protocol)

An application protocol - part of the TCP/IP protocol stack, used for transferring
files between network nodes.
Full-duplex
A type of duplex communications channel which carries data in both directions at
once.
G.711
ITU.T standard for encoding audio signals for voice grade transmission (300-3400
Hz) encoded at data rates of 56 or 64 Kbps. This is the main encoding algorithm
for digital telephony.
G.723.1
ITU.T standard for the narrow-band encoding of audio signals with data rates of
5.3 Kbps or 6.4 Kbps.

G.728
ITU.T standard for the low bit rate coding of audio signals producing 3.4KHz
upper frequency limit but occupying only 16Kbps of bandwidth.
Gatekeeper
The component of an H.323 videoconferencing system that performs call address
resolution, admission control and bandwidth management. A gatekeeper maintains
a registry of devices in the multimedia network. The devices register with the
gatekeeper at start up and request admission to a call from the gatekeeper.
Gateway
A component of a videoconferencing network that provides conversion between
different videoconferencing standards, typically H.320 ISDN videoconferencing
and H.323 IP videoconferencing, enabling ISDN and IP systems to participate in
the same conference.
Gbps (Gigabits per second)

A unit of information transfer rate equal to one billion bits per second.
GDS (Global Dialling Scheme)

The Global Dialling Scheme (GDS) is a numbering plan for global
videoconferencing. It resembles the international telephone system numbering
plan, with some exceptions. With the GDS, each participating videoconferencing
endpoint, MCU conference and gateway is numbered. GDS provides easy,
uniform dialling throughout the world.
H.261
For audio visual services; this defines the way in which the picture information is
compressed and coded to enable transmission over low bandwidth networks. It is
the baseline coding which is mandatory for most videoconferencing systems to
ensure interoperability at a basic level.
H.263
For audio visual services, a variation of the H.261 CODEC but specifically
designed for low bit rate transmission, i.e. H.324 (GSTN) and H.323 (IP)
networks at 64-128Kbps.
H.264
Also known as MPEG-4 (AVC) Advanced Video Coding. The latest video
CODEC developed jointly between the ITU-T and ISO/IEC. It uses more
sophisticated compression techniques than H.263 coding and is designed to
require less bandwidth for an equivalent quality signal using other compression
algorithms.

H.320
The umbrella ITU-T standard for narrow band videoconferencing interoperability
over ISDN networks.
H.323
The umbrella ITU-T standard for narrow band videoconferencing interoperability
over IP networks.
H.350
H.350 defines a directory-services architecture for multimedia conferencing for
H.323, H.320, SIP and generic protocols.
Hop
Passage of a data packet between two network nodes (for example, between two
routers).
HTTP (HyperText Transfer Protocol)

The protocol used by Web browsers and Web servers to transfer files, such as text
and graphics. It conventionally uses port 80.
HTTPS (Secure HTTP)

When used as the protocol specifier in the first part of a URL (https://…) this term
indicates the use of HTTP enhanced by Secure Sockets Layer (SSL). The default
‘https’ port number is 443, as assigned by the Internet Assigned Numbers
Authority.
IETF (Internet Engineering Task Force)

The body which develops standards for the Internet and Internet services, which
are published mainly as RFC documents. Participation in the IETF is open to
anyone; further information is available at http://www.ietf.org.
In-band
A connection made to a device, such as a router, which uses the network of which
the device itself is a component. Failure of parts of the network may make in-
band connections to some devices impossible; out-of-band facilities are generally
provided to address this problem.
Internet
The global public network comprising many interconnected, but independently
operated, service provider networks.
IP (Internet Protocol)
The basic protocol for the transmission of information in the Internet. IP specifies
how data is fitted into packets and provides features for addressing, type-of-
service specification, fragmentation and reassembly, and security. Defined in
RFC 791.

IP Premium
IP Quality of Service (QoS) term for a network service offering priority treatment
of particular traffic over others.
ISDN (Integrated Services Digital Network)

An international communications standard for sending voice, video, and data over
digital telephone lines, analogue telephone wires, or optical fibre networks. Both
ISDN2 (two ISDN lines) and ISDN6 (six ISDN lines) are both used for ISDN
videoconferencing.
ITU (International Telecommunications Union)

An organisation established to set international telecommunications standards for
global networks.
ITU-T (International Telecommunications Union – Telecommunications

Section)
The standardisation sector of the ITU, developing standards for interconnecting
telecommunication equipment across networks.
JANET (Joint Academic Network)

The UK academic and research network, interconnecting higher and further
education institutions and providing them with connectivity to the global Internet.
JANET also provides the National Schools Interconnect.
Jitter
The inter-packet delay variance; the difference between inter-packet arrival and
departure. Jitter is an important QoS metric for voice and video applications. Jitter
can cause data loss, particularly at high speeds.
Kbps
Kilobits per second, a unit of transmission speed equivalent to 1024 bits per
second (bps).
LA (Local Authority)
A UK regional body which may operate its own local network providing service
directly to schools.
LAN (Local Area Network)

High-speed, low-error data network covering a relatively small geographic area
(up to a few thousand metres). LANs connect workstations, peripherals, terminals,
and other devices in a single building or other geographically limited area. LAN
standards specify cabling and signalling at the physical and data link layers of the
OSI model.
Latency
The time delay introduced into a videoconference by the time taken to code and
compress (and decode and decompress) the video and audio signals in the
CODEC.

Layer 2
A networking term referring to the network protocol operated immediately over
the layer 1 infrastructure. Ethernet or PPP are examples of layer two
technologies.
Layer 3
The protocols operated over the layer 2 network, such as IP.
Loss
This describes an error condition in which data packets appear to be transmitted
correctly at one end of a connection, but never arrive at the other. This might be
due to network conditions being poor and the packet becoming damaged in transit
or the packet being deliberately dropped at a router because of internet
congestion.
LRQ Forwarding (Location Request Forwarding)

Provides address resolution from a gatekeeper to other gatekeepers in the
hierarchy.
Management Domain
A discrete network, which may be connected to other networks, over which a
network administration team have responsibility for setting, implementing and
maintaining policy.
Mbps (Megabits per second)

A unit of transmission speed equivalent to 1024Kbps.
MPEG4
A low-bit-rate compression algorithm intended for 64Kbps connections.
Multipoint
Communication configuration in which several videoconferencing systems are
connected.
MCU (Multipoint Control Unit)

A device which enables a multi-site (i.e. more than two site) videoconference to
take place.
NAT (Network Address Translation)

A technology for translating IP addresses in the IP packet header. It is often used
where the IP addressing in use on a network is not globally unique (for example,
private IP addresses). Using NAT these internal addresses can be automatically
translated into valid public addresses when communication outside the local
network is required.

NIC (Network Interface Card)

An adapter circuit board installed in a computer to provide a physical connection
to a network.
NREN (National Research and Education Network)

A national private network, usually of gigabit speeds devoted to high performance
computing and communications, in pursuit of education and research. Usually
provided through central government funding.
NSF (National Science Foundation)

A US government agency that promotes the advancement of science by funding
science researchers, scientific projects and infrastructure to improve the quality of
scientific research.
NTSC (National Television Systems Committee)

The United States' system for coding colour information onto the composite video
signal.
Out-of-band
Method of connecting to devices providing a network service without using the
network itself. For videoconferencing out-of-band usually refers to data sharing,
so the videoconference and data sharing session establish separate connections.
PABX (Packet Based Exchange)

A telephone exchange operated within an organisation, used for switching calls
between internal lines and between internal and PSTN lines. A PABX can route
calls without manual intervention, based entirely on the number dialled. However,
not all PABXs can route external calls to internal numbers automatically.
Packet
The unit of data sent across a network. ‘Packet’ a generic term used to describe
unit of data at all layers of the network, but it is most correctly used to describe
application data units. [Source: RFC1392]
Packet Loss
The discarding of data packets in a network when a device is overloaded and
cannot accept any incoming data at a given moment.
Packet Filters
A tool provided on many routers and switches to control the flow of packets in a
router. Often used to implement a simple firewall by restricting access over an
interface to particular IP address ranges and/or services only.

PAL (Phase Alternating Line)

The video signal format used in the UK. PAL uses amplitude modulation for the
video information, and frequency modulation for the audio information. The
phase of the colour sub-carrier is reversed on alternate lines which (together with
the use of a delay line) allows the receiver to cancel any phase errors introduced
in the path between the studio and the end-user's receiver. Such phase errors are
quite common and would cause the displayed colours to shift in hue.
PBN (Packet Based Network)

A network across which data travels in segments, know as packets. Each packet
seeks out the most efficient route as connections become available. The packet
header address tells routers where it should and describes the sequence for
reassembly at the destination computer.
PCI (Peripheral Component Interconnect)

A standard for connecting peripherals to a personal computer, supported by most
major manufacturers. Technically, PCI is not a bus but a bridge. It includes buffers
to decouple the Central Processing Unit from relatively slow peripherals and
allow them to operate asynchronously.
Point-to-point
The simplest method of videoconferencing, where one site communicates with
one other.
Policing
Process used to measure the actual traffic flow across a given connection and
compare it to the total admissible traffic flow for that connection. Traffic outside
of the agreed upon flow can be tagged and can be discarded en route if congestion
develops. Also known as admission control.
Port
A logical channel or channel endpoint in a communications system. The
Transmission Control Protocol and User Datagram Protocol use port numbers to
distinguish between different logical channels on the same network interface on
the same computer. Some port numbers are defined in RFC 1700, divided into
well-known ports and registered ports.
Private Address
An IP address that is used within a network and is translated using NAT at some
boundary to give a level of anonymity to the source. Typically a Private Address
should be from a list defined in RFC 1918.
Private Peering
Interconnection between two service provider networks using a dedicated link;
for example, the connection between an RBC and JANET for the National
Schools Interconnect is a private peering.

Proxy
Intermediary program that acts as both a server and a client for the purpose of
making requests on behalf of other clients. Requests are serviced internally or by
passing them on, possibly after translation, to other servers. A proxy interprets,
and, if necessary, rewrites a request message before forwarding it.
PTZ (Pan, Tilt and Zoom)

Refers to a video camera’s ability to move from side to side, up and down, and
zoom in and out, depending on the requirements of the participants in a
conference.
Public Address
An IP address that is unique on the global Internet. Public addresses are usually
obtained from a network's Internet Service Provider, which in turn obtains blocks
of addresses from regional Internet registries.
QCIF (Quarter CIF)

The minimum vision quality used in H.320 conferencing systems, with a
resolution of 180 x 144 and a repetition rate of 15 or 7.5Hz.
QoS (Quality of Service)

Term referring to the treatment of traffic on a network. IP QoS is in its infancy,
however it is being trailed (or used) on some networks to provide differing levels
of service for different customers or customer traffic. IP QoS is often stated as a
requirement for real-time voice or video applications, as they are very sensitive to
packet loss. An IP QoS service providing priority treatment for these types of
applications can help to reduce packet loss.
RBC (Regional Broadband Consortium)

A consortium of Local Authorities providing network services to schools within a
defined region.
Real time
Describes an application which requires a program to respond to stimuli within
some small upper limit of response time (typically milli- or microseconds).
Router
Network layer device that uses one or more metrics to determine the optimal path
along which network traffic should be forwarded. Routers forward packets from
one network to another based on network layer information. Occasionally called a
gateway (although this usage is becoming outdated). Often used as a generic term
for an IP router, however the term may be used to refer to a device that is routing
other protocols in addition to IP.
RS-232
A standard interface for connecting serial devices.

SIP (Session Initiation Protocol)

A very simple text-based application-layer control protocol. It creates, modifies,
and terminates sessions with one or more participants. Such sessions include
Internet telephony and multimedia conferences.
Streaming
Playing sound or video in real time as it is downloaded over the Internet as
opposed to storing it in a local file first. A plug-in to a web browser decompresses
and plays the data as it is transferred to your computer over the World-Wide Web.
Streaming audio or video avoids the delay entailed in downloading an entire file
and then playing it. Streaming requires a fast connection and a computer powerful
enough to execute the decompression algorithm in real time.
Structured Cabling
A telecommunications cabling system that can support virtually any voice, video,
imaging, or data application that an end-user chooses.
SuperJANET
The national high speed backbone of the JANET network.
S-Video
S-Video, sometimes referred to as Y/C Video, or component video is a video
signal transmission in which the luminance signal and the chrominance signal are
transmitted separately to achieve superior picture clarity.
Switch
A device that channels incoming data from any of multiple input ports to the
specific output port that will take the data toward its intended destination.
T.120
An ITU-T standard that describes data conferencing.
TCP (Transmission Control Protocol)

Connection-oriented transport layer protocol that provides reliable full-duplex
data transmission. TCP is part of the TCP/IP protocol stack.
Telnet
The Internet protocol for remote login. Runs on top of TCP/IP. Defined in RFC
854 and extended with options by many other RFCs.
Terminal
Any device that terminates one end (sender or receiver) of a communicated signal.
TFTP (Trivial FTP)

A simple file transfer protocol used for downloading boot code to diskless
workstations.

Traffic
The term used to describe data as it traverses the network.
UDP (User Datagram Protocol)

Connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a
simple protocol that exchanges datagrams without acknowledgments or
guaranteed delivery, requiring that error processing and retransmission be handled
by other protocols. UDP is defined in RFC 768.
UKERNA (United Kingdom Education and Research Networking

Association)
The organisation responsible managing, operating and developing JANET.
UPnP (Universal Plug 'n' Play)

An architecture that provides compatibility among networking equipment,
software and peripherals. With UPnP, a new device can be added to your
computer without having to turn the computer off, hence plug and play.
See UPnP Forum: http://www.upnp.org/.
USB (Universal Serial Bus)

A PC interface. Sometimes used to directly connect a camera for
videoconferencing.
VCR (Video Cassette Recorder)

A device that can be used to record the output from a video camera or television,
and also display moving images, usually on a television.
ViDe
The Video Development Initiative in North America. See http://www.vide.net/
VLAN (Virtual Local Area Network)

A LAN operated using the same physical infrastructure as one or more other
LANs. Groups of ports on a switch are configured as part of the VLAN, with the
connected devices being unaware that the interconnecting network is not
dedicated to them. VLANs can be extended (or ‘trunked’) across several
switches, perhaps using LES technologies.
Voice-switched
This mode of conference control relies on the MCU switching to transmit the
video and audio streams of the current speaker to all conference participants (with
the exception that the speaker sees the video of the previous speaker).
WebCam
A video camera connected to a video capture card in a computer.

XGA (eXtended Graphics Array)

XGA supports a resolution of 1024 x 768 pixels with a palette of 256 colours, or
640 x 480 with high colour (16 bits per pixel).
Zone
An H.323 zone is a logical collection of videoconferencing systems, gateways and
MCUs, which are managed by a single gatekeeper. A zone must include at least
one videoconferencing endpoint and may include several LAN segments
connected by routers.

Appendix B: Market Survey of Videoconferencing

Systems
This survey is attached as a separate document and is also available at:
http://www.video.ja.net/
Appendix C: Interoperability Testing of

Videoconferencing Systems
This report is attached as a separate document. The results are also available at:
http://www.video.ja.net/

Videoconferencingv 3

Загружено:

Сведения о документе

Исходное описание:

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Videoconferencingv 3

Загружено:

Авторское право:

Доступные форматы

Videoconferencing – Draft

Copyright © 2004 The JNT Association

NDD/NSP/RS/VC/3.1 2 June 2004 Page 1 of 66

© The JNT Association 2004 NDD/NSP/RS/VC

NDD/NSP/RS/VC/3.1 2 June 2004 Page 2 of 66

NDD/NSP/RS/VC/3.1 2 June 2004 Page 3 of 66

3.7.3 Deployment of MCUs.............................................................32

NDD/NSP/RS/VC/3.1 2 June 2004 Page 4 of 66

NDD/NSP/RS/VC/3.1 2 June 2004 Page 5 of 66

1.2 Target Audience

• Staff in schools involved with their school's internal network;

1.3 Strategic Issues

Schools take ultimate responsibility for the purchase of videoconferencing systems

NDD/NSP/RS/VC/3.1 2 June 2004 Page 6 of 66

1.4 Summary of Responsibilities

The relevant sections in the main document are indicated in parentheses.

NDD/NSP/RS/VC/3.1 2 June 2004 Page 7 of 66

• Conference booking systems or other databases or systems, which contain data of

1.4.2 Local Authorities/RBCs

NDD/NSP/RS/VC/3.1 2 June 2004 Page 8 of 66

NDD/NSP/RS/VC/3.1 2 June 2004 Page 9 of 66

• Those providing such support should be given (remote) access to the

NDD/NSP/RS/VC/3.1 2 June 2004 Page 10 of 66

• Upgrades are thoroughly tested in a non-service environment and issues resolved,

1.5 National Education Network

NDD/NSP/RS/VC/3.1 2 June 2004 Page 11 of 66

1.6 Interoperability and Standards

The UK Government’s e-Government Interoperability Framework (e-GIF) makes

It must be emphasised that the procurement of systems based on proprietary non-standard

NDD/NSP/RS/VC/3.1 2 June 2004 Page 12 of 66

• International Telecommunication Union (ITU)

NDD/NSP/RS/VC/3.1 2 June 2004 Page 13 of 66

• COder-DECoder (CODEC) system (H.323 and/or H.320 compliant)

NDD/NSP/RS/VC/3.1 2 June 2004 Page 14 of 66

2.2.2 Optional Equipment

• System integration and control facility with touch screen;

NDD/NSP/RS/VC/3.1 2 June 2004 Page 15 of 66

2.3 Videoconferencing Systems

Assuming a well-engineered network with adequate bandwidth provision, the quality of a

• Quality of the CODEC, software or hardware

The advantages of desktop systems are:

The disadvantages of desktop videoconferencing systems are:

NDD/NSP/RS/VC/3.1 2 June 2004 Page 16 of 66

2.3.2 Roll-about Systems

The advantages of roll-about systems are:

The disadvantages of roll-about systems are:

NDD/NSP/RS/VC/3.1 2 June 2004 Page 17 of 66

2.3.3 Room-based Systems

Roll-about systems may be permanently located and used as room-based systems,

The advantages of room-based systems are:

The disadvantages of room-based systems are:

NDD/NSP/RS/VC/3.1 2 June 2004 Page 18 of 66

2.4.1 Data and Application Sharing

Videoconferencing applications are real-time applications that generate large amounts of

NDD/NSP/RS/VC/3.1 2 June 2004 Page 19 of 66

2.4.2 Interactive Whiteboards and Projectors

When an interactive whiteboard is used in conjunction with videoconferencing system,

2.4.3 Media Integration

2.5 Recording Conferences

If a conference is being recorded, thought should be given to Intellectual Property Rights

NDD/NSP/RS/VC/3.1 2 June 2004 Page 20 of 66

A videoconference link requires: