JANET Videoconferencing Service (JVCS)
JVCS-IP
- Introduction to the JANET Videoconferencing Service (JVCS)
- Overview of the Service
- Service Policies
- Using the Service
- Centralised Equipment
- Registering for JVCS-IP
- Fault Reporting
- Further Information
Introduction to the JANET Videoconferencing Service (JVCS)
JVCS provides videoconferencing services to the JANET community. At present it consists of centralised equipment and scheduling services to facilitate videoconferences using both Integrated Services Digital Network (ISDN) H.320 and Internet Protocol (IP) H.323 as transport technologies. The service is split into two distinct areas. These are JANET Videoconferencing Service over IP (JVCS-IP) and JANET Videoconferencing Service over ISDN (JVCS-ISDN). The service also provides gateway support for multipoint videoconferences that use both IP and ISDN. This document is intended to outline how organisations can use JVCS-IP, provide an overview of the service and outline recommendations for organisations wishing to use the service. Some familiarity with videoconferencing and IP networking is assumed. For an introduction to H.323 videoconferencing see:
http://www.ja.net/documents/services/video/vtas/323intro.pdf
The JVCS-IP infrastructure complies with the International Telecommunications Union Standardisation Sector (ITU-T) H.323 umbrella of protocols for IP videoconferencing. The service consists of three elements:
- Multipoint Control Unit (MCU) and IP-ISDN gateway capacity;
- gatekeepers, that provide call admission control (allowing IP videoconferencing to be managed on user organisation networks) and call routing (allowing users to simply dial other users across the network in a similar way to making phone calls);
- Global Dialling Scheme (GDS), that works in conjunction with the local, national and international gatekeepers to route calls appropriately.
Security of IP videoconferences can be improved through the use of proxy gatekeepers or H.323 aware firewalls. It should be noted that, as part of the IP videoconferencing service, IP videoconferences will be automatically initiated from the MCU and offered on a dial-out basis. To facilitate this operation both point-to- point and multipoint videoconferences will use an MCU.
MCU, gateway, and gatekeeper equipment has been deployed centrally on the JANET backbone at separate remote locations to facilitate the operation of JVCS-IP.
To ensure that an acceptable level of audio and video quality is provided by the centralised JVCS-IP service, all organisations using it must undergo a registration procedure that includes passing a quality assurance test.
To manage the resources of the service and to ensure no conflicts occur, a booking service is in operation and must be used. Details of this service can be found here.
JANET organisations with a primary connection are able to register to use JVCS-IP. This involves registration of their videoconferencing venues (studios, desktop systems and all other end-points) with the JANET Videoconferencing Service - Booking Service (JVCS-Booking Service). Each organisation is required to successfully complete a quality assurance test. The test is carried out in conjunction with the JANET Videoconferencing Management Centre, and involves measuring the objective audio and video quality and network connectivity of an organisation’s videoconferencing venue. These tests are repeated at six month intervals after initial registration.
Venues not registered with the JVCS-Booking Service may take part in videoconferences with organisations that have a Primary Connection to JANET as ‘guest venues’. Guest venues are unable to make bookings using the JVCS-Booking Service. Guest venues undertake a connectivity test rather than a quality assurance test, to ensure that the venue is able to connect to the videoconference.
Only requests from organisations with a videoconference venue registered with the JVCS-Booking Service will be accepted to make videoconferencing bookings. Because JVCS-IP operates on a dial-out basis and all videoconferences, including point-to-point, are initiated from the MCU, it is a requirement to book all videoconferences via the JVCS-Booking Service.
Software only Coder/Decoders (CODECs) are CODECs that operate without any direct hardware assistance and they are unable to use JVCS-IP at this stage. Tests undertaken as part of the UKERNA Video over Internet Protocols (VIP) Demonstrator Project found that software only CODECs did not function correctly during MCU conferences. Software only CODECs include Microsoft® NetMeeting®, CUseeMe® and Open H.323 CODECs (an Open Source version of the H.323 suite of protocols).
To register for, and use JVCS-IP, organisations need to ensure they have a primary JANET connection with bandwidth capable of supporting the IP videoconference(s) they are proposing. Currently JVCS-IP supports call speeds of 128 kbit/s to a maximum of 2 Mbit/s. During an IP videoconference bandwidth can peak at double the call speed being used, for example during a 768 kbit/s videoconference the actual bandwidth required can reach approximately 1.5 Mbit/s. Organisations should also factor in regular network traffic when considering videoconferencing call speeds.
Depending on network quality, higher bandwidth videoconferences can provide a higher quality of video and audio.
It is recommended that careful consideration be given to the physical network path between CODECs and site access routers, and the amount of traffic traversing the link. Links should ideally be 10/100 Mbit/s full duplex, thus avoiding potential local network load issues.
Diagram 1: A typical local network set-up for organisations wishing to deploy IP videoconferencing.
Studio set-up and layout should be considered carefully. Factors to consider include:
- wall coverings;
- curtains;
- table layout;
- microphone positioning;
- camera positioning.
An in-depth report on this topic is available from the Video Technology Advisory Service (VTAS) website at:
http://www.ja.net/services/video/vtas/rooms
The gatekeeper is a call set-up and management device that allows organisations to control the level of H.323 IP videoconferencing traffic on their networks. Within the H.323 standard is the concept of ‘zones’. A gatekeeper manages a zone that has a number of venues registered within it by using admission control, address translation, address resolution and bandwidth control. A single physical gatekeeper can, in some implementations, support multiple logical zones.
The distribution of gatekeepers/zones allows for devolved management, increased security, and a scaleable service. It should also reflect the management and organisational structures of the service and the topology of the network over which the service will operate. The logical distribution of gatekeepers and their associated zones is on an organisational basis. Thus, in the majority of cases, each organisation should have a single gatekeeper that will communicate with other organisations’ gatekeepers via the national or world directory gatekeeper, to set-up and manage calls. (See Global Dialling Scheme section.)
It is possible, however, that some organisations may not want to run their own gatekeeper. In this case gatekeeper facilities are provided from the centrally located and managed JANET gatekeeper. Another case may be a research group, for example, spread over multiple organisations who may prefer to be part of the same zone for addressing reasons. In this case gatekeeper facilities should be provided from a local or remote organisation, or alternatively from the centrally located and managed JANET gatekeeper.
Organisations that have H.323 IP videoconferencing systems and wish to use the JANET service have the option of deploying their own organisation gatekeeper or using the JANET gatekeeper. The JANET central gatekeeper is provided to allow sites to participate in IP videoconferencing if they have not yet deployed their own gatekeeper.
Each organisation'’s gatekeeper must be registered with JVCS-IP in order to be able to send and receive calls using the Global Dialling Scheme and to take part in multipoint conferences. Upon registering for the service, a zone prefix will be allocated for that zone and information on how to configure the organisation’s gatekeeper to access the service will be provided. In order to use the service, all venues within an organisation must use the registered gatekeeper.
CODEC choice is an extremely important area to consider. Ideally, CODECs should be capable of supporting videoconferences at 2Mbit/s although JVCS-IP is able to support speeds of between 128 kbit/s and 2Mbit/s.
Organisations wishing to use JVCS-IP must ensure that all CODECs are compliant with the ITU-T H.323 series of recommendations. Information on the H.323 standard can be found at:
http://www.ja.net/services/vtas/stan
Some H.323 compliant CODECs have been evaluated by the Video Technology Advisory Service (VTAS), details of these can be found at:
http://www.ja.net/services/vtas/evaluation
CODECs can take a wide range of hardware and software formats. Some of the most popular CODECs are:
- rack based CODECs with ancillary camera(s), monitors and microphone equipment;
- room based CODECs with ancillary camera(s), monitors and microphone equipment;
- desktop hardware CODECs with built-in camera and microphone equipment and ancillary monitor (these are usually standalone devices);
- desktop hardware CODECs with ‘bubble camera’ and ancillary microphone. (These are usually Peripheral Component Interconnect (PCI) based CODEC cards utilising standard PCs.)
As mentioned previously, (Service Policies)software only CODECs will not be able to use JVCS-IP.
There are a number of security issues related to IP videoconferencing, particularly concerning H.323 in relation to firewalls and conference interception.
The H.323 protocol suite includes a range of individual protocols. For all these to function correctly an H.323 CODEC requires a number of reachable Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) ports. The port numbers used for some of these protocols, including the Real Time Protocol (RTP) audio and video streams, are negotiated at connection time, making it impossible to know in advance which port numbers an H.323 session will use.
It is becoming increasingly popular for organisations to run firewalls, and it is becoming more common for these firewalls to use default deny inbound policies. Unless the firewall is H.323 aware (where the ports used can be determined in real time by monitoring the call control and set-up channel) organisations need to open all ports above 1023 to enable the H.323 data to flow properly. The UKERNA VIP Demonstrator Project and H.323 Architecture Group have both found that H.323 aware firewalls are suitable for deployment, e.g. Check Point® Firewall-1 v4.1. These firewalls (as opposed to those that do only basic packet filtering) may be relatively expensive to acquire. Not every site operates a firewall (for H.323 or regular traffic), and thus it is not feasible to stipulate that all H.323 CODECs must be placed behind a firewall - but it is certainly good practice to do so.
An alternative method for allowing H.323 traffic into a site is to deploy an H.323 proxy. The proxy resides on the organisation’s border network, and communicates with the H.323 CODECs within the organisation. H.323 sessions into or out of the network operate via the proxy. Inbound H.323 connections are received by the proxy, which then initiates the final leg of the connection to the internal CODEC. If a firewall is used, the proxy can be chosen to be the only source trusted for inbound H.323 sessions, as all such sessions will effectively be routed through it. (see Diagram 1)
In order to ensure standardised H.323 videoconferences can take place both within the UK and world wide, an H.323 GDS has been developed. SURFnet in the Netherlands, HEAnet in Ireland and ViDeNet in the US have also implemented this scheme. The GDS has been developed because a standardised H.323 addressing scheme is yet to be created. The GDS uses standards based E.164 addressing.
The GDS is based on numeric addressing which allows the greatest flexibility in interfacing with other communication devices e.g. ISDN based videoconferencing systems and conventional or mobile phones. The GDS comprises four components:
- an international dialling prefix, which is specified as 00;
- the ITU-T country telephone code, that is between one and three digits, in the case of the UK 44;
- a zone prefix, which is five digits starting with a zero e.g. 01100 that is the zone prefix for an organisation;
- a three to five digit extension number.
Here is an example number that might be used to dial a system in a university:
| 00 | 44 | 01100 | 12345 |
| International prefix | UK dialling code | Zone prefix | Extension number |
Zone prefixes are assigned by UKERNA in the UK and by other National Education and Research Networks in other countries. Once an organisation has installed a gatekeeper it can apply to the JANET Videoconferencing Management Centre to register it. After successfully completing the registration a zone prefix will be assigned. The organisation can then assign its own three to five digit extension number. The only restriction to the allocation of extension numbers is that they cannot start with a zero.
The diagram below shows how a UK call would take place between Swansea University and Edinburgh University (grey arrows), and how an international call would take place between Swansea University and SURFnet in the Netherlands.
Diagram 2: The gatekeeper hierarchy on which the dialling scheme operates.
To ensure that faultfinding and fault diagnosis can be undertaken, the JVCS Management Centre will monitor elements of JVCS-IP. On registering, organisations will be requested to give permission to the Management Centre to monitor their videoconferencing equipment. Any network faults should be reported using local fault reporting mechanisms. Sites that do not wish to have their videoconferencing equipment monitored should be aware that the Management Centre will be unable to provide fault finding and diagnostic services, and non-centralised issues will have to be resolved at a local level.
MCU equipment capable of providing 2 Mbit/s IP based videoconferencing for up to 48 sites is deployed as a key part of JVCS-IP. The equipment consists of two fully populated Polycom MGC-100TM MCUs used for both point-to-point and multipoint videoconferences to facilitate the dial-out service.
Many videoconferences taking place within the JANET community use different networking protocols and call speeds. To ensure that the majority of videoconferences are supported, IP to ISDN gateways and rate matching capabilities are built-in to the core centralised videoconferencing equipment.
While the introduction of IP videoconferencing is seen as a catalyst for growth in service usage within the JANET videoconferencing community, it is perceived that the use of ISDN videoconferencing will continue to grow over the next five years.
To accommodate this likely growth, a significant amount of IP to ISDN (H.323 to H.320) gateway equipment has been deployed as part of the service. IP to ISDN gateways enable a seamless integration of videoconferences using both IP and ISDN as transport technologies.
The ability to support videoconferences with CODECs operating at different call speeds is a key factor to the success of the JANET Videoconferencing Service. Over the last two years the capabilities of IP based H.323 CODECs have increased significantly and the maximum bandwidth capabilities have risen from 768kbit/s to 4Mbit/s. This growth has resulted in organisations deploying CODECs capable of operating at a variety of different call speeds. The maximum speed of JVCS-IP is currently 2Mbit/s, the maximum currently supported by the MCU.
Another reason for offering rate matching as part of the overall service concerns network connectivity. While some organisations may have CODECs capable of operating at 2Mbit/s, their network connections may not allow it. Organisations with lower bandwidth connections to JANET may therefore stipulate that their videoconferences be limited to suit their network connections.
To register for JVCS-IP please go to the Booking Service
Sites already registered to use JVCS-ISDN have the option to add an IP CODEC to their existing videoconferencing information.
Follow the CODEC Operations link after logging in. Enter the details of the CODEC you are adding and your chosen gatekeeper option.
New institutions that are not registered to use JVCS-ISDN must create an account by selecting add new institution
Newly registered organisations are required to create a login account and provide general information on CODECs and gatekeeper options. The online prompts are designed to guide you through this process.
If at any time during the registration process you have any questions or need further assistance, please contact the JANET Videoconferencing Management Centre.
Tel: 0131 650 4933 E-mail:vidconf@jvcs.ja.net
To report a fault associated with any element of JVCS-IP contact the JANET Videoconferencing Management Centre:
Tel: 0131 650 4933
E-mail:vidconf@jvcs.ja.net
For further information on JVCS-IP please contact the JANET Videoconferencing Management Centre:
Tel: 0131 650 4933
E-mail:vidconf@jvcs.ja.net
NB
Microsoft and Netmeeting are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Polycom MGC-100TM is a trademark of Polycom in the U.S. and various countries.