skip to primary navigationskip to content

Network policies

Requirements for an institution's network to carry UTN VoIP traffic

This is a briefing note for institutional (i.e. College or departmental) Computer Officers to make them aware of the technological requirements for the data network in their institution to be able to support Voice-over-IP (VoIP) compatibly with that proposed for the University Telephone Network (UTN). The document does not deal with the issues of support of VoIP by institutional Computer Officers or with issues of VoIP over Wi-Fi (IEEE 802.11).

The document has been produced for the JTMC Technical Working Group as the result of collaboration between the University Telecommunications Office and the University Computing Service.

The word must is used to indicate an absolute requirement, without which service will be impossible; the word should is used to indicate a recommendation without which service is likely to be degraded, even to the point of being practically unusable in some situations.

1. The minimum requirement

1.1 The cabling should conform to category 5 or better.

1.2 The network must be ethernet and all links carrying VoIP traffic should run at 100 Mbps or more.

1.3 The active network equipment should consist only of switches and possibly routers - that is, the network should not contain any repeaters (hubs).

1.4 Use of private IP addresses must conform to Private (RFC1918) IP addresses within the University of Cambridge and the CUDN. Note that the addressing scheme on centrally managed VoIP VLANS will be prescribed centrally.

1.5 VLAN numbering within the institution must conform to that described in VLAN number allocation within the CUDN. Note that centrally managed VoIP-only VLANs will not normally be local to the institution.

1.6 Centrally managed VoIP-only VLANs should bypass any institutional firewall as firewalls can be a significant source of latency and jitter.

Such a network will be able to carry UTN VoIP traffic but, without provision for QoS, the speech quality may be noticably inferior to that provided by the existing analogue UTN. In particular, short gaps may appear in speech at times of heavy use of the institution's network.

2. Additional requirements recommended by the JTMC's Technical Working Group

For the avoidance of doubt, all the requirements in 1. above also apply.

2.1 The network equipment should support IEEE 802.1p Quality of Service (QoS). The implication of supporting QoS is that the equipment will have adequate buffering and priority queuing mechanisms so that packet loss and jitter will not be an issue.

2.2 The network equipment should support IEEE 802.1q VLANs. Voice and data traffic should be transported on separate VLANs as, at present, QoS facilities are insufficiently well developed; note that this may not be feasible for softphones, but should be possible for dedicated VoIP instruments. Security concerns for the voice service are mitigated somewhat by using separate VLANs for voice and data traffic.

2.3 Where VoIP traffic is not carried on VoIP-only VLANs, there should be provision for marking data packets to indicate that enhanced quality of service is required for packets carrying voice traffic. There should be provision for policing that no data packets, other than those which are to be given an enhanced quality of service (e.g. UTN VoIP data packets), are so marked.

2.4 Barring pathological 'network storm' conditions, latency is unlikely to be a problem within institutional networks. However, the number of routers employed within an institutional network should be kept small unless those routers also provide wire-speed routeing.

Subject to VLAN separation, such a network will generally be able to carry UTN VoIP traffic and the speech quality will be comparable to that provided by the existing analogue UTN.

3. Reliability/availability options for improved service

3.1 Electrical power

The existing analogue UTN provides a high degree of reliability and availability, in particular providing 2-hour capacity uninterruptible power supplies for all equipment, other than for those handsets and associated equipment (such as Ambassador systems) that are powered from the institution's mains supply. Institutions will be accustomed to expect this degree of reliability and availability from the UTN.

The VoIP UTN service is provided using a range of infrastructure (CUDN, telephony equipment, institutional networks) that is more diverse than that used by the existing analogue UTN. In addition, that infrastructure is provided at present via several different management domains, which is not the case for the existing UTN.

Power for the central CUDN equipment is supplied by a UPS, backed up with a diesel generator with a 24-hour tank of fuel. The CUDN core switch/routers each have a 20-minute UPS (it is intended that these should be upgraded to match the current 2-hour capacity of the UTN). The CUDN Point of Presence (PoP) at each institution is not provided with a UPS as part of the standard installation, although a few institutions have provided uninterruptible power facilities for their PoP.

If an institution wishes its VoIP telephone instruments to be capable of operation during a local power failure, it will need to ensure that the instrument remains powered, e.g. by one of the following means:

a) battery back-up in the instrument;

b) UPS supplying the instrument;

c) power is supplied to instrument using Power-Over-Ethernet (POE) from the network equipment or from separate POE injectors (adaptors), provided for network equipment that does not have POE capability; (see, for example, background information on POE; the JTMC Technical Working Group views support of POE as highly desirable).

The institution will also need to ensure that its network equipment and the CUDN PoP are protected by UPSs of capacity sufficient for the institution's requirements.

Clearly, if softphones (implementations of telephony handsets using software in personal computers) are to remain usable during a local power failure, the power supply to the personal computer must be maintained: it is envisaged that many institutions will decide that there is insufficient cost-benefit to provide UPSs for personal computers.

3.2 Environmental issues

An increasing amount of network and other IT infrastructure installed in institutions is installed in locations that are inadequate from the point of view of environmental conditions. This has usually arisen because the amount of of equipment and the amount of electrical power consumed by the equipment has grown over the years. Institutions should initiate a regular review of the environments in which their IT infrastructure is located to ensure that the environment remains suitable for the equipment and should take steps to rectify any inadequacies, in particular:

a) the ambient temperature should not exceed 25 deg C and must not exceed 30 deg C, even in summer conditions (much modern equipment is rated for operation at ambient temperatures of up to 40 deg C; some modern equipment will switch itself off when its temperature limit is exceeded; the recommendation of 30 deg C is to give a measure of headroom for hot-spots and temporary fault conditions);

b) the humidity should be between 20 and 90 % R.H.;

c) the location should be free from contaminants, including dirt.

If the equipment is protected by a UPS and housed in an environment that is cooled or ventilated artificially, the effects of a failure of the local electrical supply may be that the equipment is kept running but without the necessary cooling.

3.3 Physical security

The main point of presence should be in a physically secure location - this is a very strong recommendation - to prevent unauthorised access to (e.g. tapping into) the ends of network cables and any management console ports on the equipment. The same applies to other locations of network equipment within the institution, but with marginally less strength as rather less of the institution's installation would be vulnerable. It is possible to tap into copper network cabling, much less so fibre-optic cabling, and use of trunking (rather than cable tray) is recommended in areas that are accessible.

It is conceivable that changes in the application of data protection legislation in the future might mandate a stricter approach to the physical security of networks. Institutions might wish to consider this when planning upgrades to their networks.

The institution must make arrangements for access by University data and voice network staff for fault diagnosis, repair and upgrade purposes. These arrangements need to take the need for emergency access which might be required out of hours - consider the effect of local failure of all voice network communications at the start of a bank holiday weekend and might be required because failure of equipment in one institution may affect services in another. It is acceptable that access is provided indirectly via permanently staffed facilities (e.g. University Security Office or a College Porters' Lodge). Such access must be taken in to account when changes are made to access arrangements within an institution.

3.4 Reduction of single points of failure within the institution's network

Although modern network equipment is highly reliable, failures and accidents do occur. Consideration should be given to reducing single points of failure, for example, by the introduction of redundancy, both in equipment and network links. Network switches should support IEE802.1w Rapid Spanning Tree Protocol (RSTP - also known as Fast Spanning Tree Protocol, FSTP) to enable them to support multiple-path networks.

Although duplicate links from the CUDN point-of-presence switch within the institution to the relevant area switch-routers in the CUDN are planned, the CUDN PoP switch itself would remain a single point of failure. This is perhaps comparable with the Remote Peripheral Equipment (RPE) being a single point of failure in the existing analogue UTN. Institutions may wish to consider the cost and benefit of a second CUDN connection to eliminate this single point of failure.

Skype and the CUDN

Skype is a popular VoIP (Voice over IP) application that allows users to make free VoIP calls to other Skype users. The Skype company also provide charged services, thus providing them with a revenue stream, that allow users of the Skype software to call landline and mobile phones. Skype can also be used for group video call.

It is a feature of Skype that a machine running it may become a 'supernode'. This means that it may act as an exchange, routing calls between other Skype users, and the amount of traffic may be substantial - this should be of concern to University departments and Colleges because of the University's traffic-related usage charges.

Currently each College and department is charged for part of the cost of using the national academic network, JANET. That charge is based on the percentage of the University's aggregate network traffic used. The use of Skype (and other applications with similar properties) can cause a dramatic increase in network traffic and can therefore result in an increase in a department's or a College's charge.

The Information Services (UIS) does not ban Skype. However, individual departments and Colleges may impose their own bans on the use of Skype, and some have done so.


The UIS recommends that certain steps be taken if using Skype. To minimise excessive network traffic and the the risk of abuse Skype should be configured as follows.

  • Untick the Start Skype when the computer starts box.
  • Untick the Sign me in when Skype starts box, as that means anyone could use your Skype account from the computer you are on in the future without you knowing about it

Use of the CUDN/Janet by Conferences in Cambridge


The CUDN is one of the University's most valuable assets and provides access to various services and the JANET network to support the mission of its Departments, related Colleges, and other affiliated Institutions. The primary purpose of the network is to support teaching, learning, and research; however, the various roles of the University's Institutions, in some cases, require the use of the network for other University business. One such need is the use of the data network for conferences. The Computing Service supports the use of the CUDN and the provided JANET services for conference activities. This applies to conferences hosted by an Institution or an external hosting company renting an Institution's facilities.


The CUDN may be used to support the needs of conference delegates, coordinators, vendors, and guests while residing on University grounds and partaking in conference activities. The Computing Service should be advised or consulted about any conference in a timely manner if there are any special network requirements (e.g. large network bandwidth needs). In all cases, it is assumed that any equipment used will be either personal workstations belonging to the delegates connected to the local network or local workstations owned by the college/department. Network use is limited to physical data ports and authenticated wireless networks, i.e. open wireless networks are not supported on the CUDN for any purpose and therefore any wireless connection must have a controllable authentication method like the Lapwing Wireless Network. The Computing Service would not permit the connection of another network except in very exceptional circumstances. Any such requirement together with a supporting case should be discussed with the Computing Service well in advance.

Conference participants are not eligible for CRSids, but may be given visitor access via Lapwing visitor tickets, eduroam, or Summer School IDs (the latter are available on request from UCS for a modest administrative charge).

Note that those participating in the conference and using the CUDN are still subject to the CUDN Acceptable Use Policies found here:

Institutions that support the conference, e.g. a Department or College, are fully responsible for the enforcement of the Acceptable Use Policies and the conduct of those using the network. Use of the network by conferences hosted by external bodies will be covered by a JANET Proxy Licence that will be obtained by the Computing Service.

In all cases, there must be a registration mechanism in place that identifies an individual's usage and provides for sufficient authentication and authorisation to ensure that use can be audited and controlled. The authorisation mechanism should be such that, for each registration, only one user can use it at any given time. Except for access using eduroam, each individual delegate is to be issued with a unique userid/password which must be used before network access is obtained. Unless the users are using the UCS Lapwing Service either using eduroam or visitor tickets, it will be up to the sponsoring Institution to ensure that any network access is logged and records kept for a minimum of three months in case there are queries from JANET(UK) or any other external bodies.

Last updated: June 2010

University network access for external organisations

The CUDN is funded to provide facilities for institutions of the University of Cambridge and its Colleges, and for certain Research Council institutions. The policies for use of the CUDN are set by the University authorities on the advice of the Information Services Committee.

Janet is managed by Janet(UK) on behalf of JISC (Joint Information Systems Committee) for the UK Further and Higher Education Funding Councils. The policies for use of Janet are set by JISC.

The University of Cambridge has a Primary Connection to Janet. In the autumn of 2011 a policy change was announced whereby an organisation with a Janet connection may decide itself how it uses Janet in the area of business and community engagement.

Requests for CUDN and Janet access

CUDN and Janet access can be provided to outside organisations for the purpose of bona fide collaborative work with University institutions. Engaging in collaborative work with a University or College institution as a subterfuge for obtaining general Janet/Internet access will not be viewed favourably.

Requests for access for an outside organisation must be made by the Head, or their appointed deputy, of the University or College instititution with which the outside organisation is undertaking collaborative work. The request for the connection must state:

Requests should be addressed to Network Support at the University Computing Service.

Further information

Authorization for use of the CUDN

Janet Eligibility Policy.

The Janet Acceptable Use Policy.

In the above, University refers only to the University of Cambridge and College only to a College of the University of Cambridge.

Last updated: July 2012

Regulation of Investigatory Powers Act 2000

Regulation of Investigatory Powers Act 2000,
Lawful Business Practice Regulations
& Data Protection Act 1998

As required by the above-mentioned UK legislation, University Information Services advises all users of the Cambridge University Data Network (CUDN) that:

  • their communications may be intercepted as permitted by legislation;
  • statistics of network traffic broken down by individual local IP address will be published on the Web so that administrators of institutional networks and of individual computers can be aware of the charges incurred by use of their computers.

Users should also be aware that their communications may be intercepted, as provided for by the Lawful Business Practice Regulations, for the purpose of investigating or detecting unauthorized use of the CUDN or networks to which the CUDN is directly or indirectly connected. See the web page headed Authorization for Use of the CUDN.

The network traffic statistics will be accessible on the Web by anyone using a network-connected computer within the University, its Colleges, and other institutions connected to the CUDN. Computer users should also be aware that network traffic statistics relating to individual IP addresses may also be passed directly to institutional officers on request for purposes such as dealing with inappropriate use of the network. This information may include date and time of day, identification of the remote host, and the amount of incoming and outgoing traffic, which may be broken down by protocol.

Last reviewed: October 2014