Information for Computer Officers

These are suggested configurations for network equipment to support the University phone system. If you have any suggestions or questions about the information here, please contact the Telecoms Helpdesk on phones@uis.cam.ac.uk

• General
• 3Com/HP Comware Switches
• HP ProCurve & HPE/Aruba
• Cisco IOS
• BGP Connected Institutions
• Power Over Ethernet
• DSCP
• Multicast
• Firewalls
• Setting An ATA's voice VLAN
• Troubleshooting
• Jabber
• Proximity
• Spectralink
• Web Dialler API

General

(The original requirements for supporting the VoIP phone system can be found a www.ucs.cam.ac.uk/network/rules/instnetvoip.html)

Quality of Service (QoS) is the means where the data network can prioritise certain network traffic over all other traffic. As voice (and video) traffic is real-time and very sensitive to delays, lost packets, jitter, etc. then QoS is essential to ensure a good experience for the end users.

As such, institution networks must be configured to support (QoS). If an institution's network does not have QoS configured, and users report poor call quality, Telecoms will not perform any investigations until QoS is configured. Institution's should only need to configure their networks to honour QoS markings. There should be no need to (re-)mark packets as the packets should be correctly marked by the phones and the phone system.

All Cisco devices (except VG224s) require the voice VLAN presented as tagged. There was some confusion in the early days about ATAs, but these do require tagged VLANs.

Phones (& ATAs) can pick up their voice VLAN via either:

• CDP
• LLDP-MEP
• Static assignment on the device

Not all phones support all configuration options, and support for CDP & LLDP-MED varies among switches and vendors. Use the Handset Comparison page to see what protocol a particular phone supports.

In all the configurations below, replace the number 9999 with your local voice VLAN number. If you are unsure what this is, contact the Telecoms Helpdesk.

3Com/HP Comware Switches

In the early days of the CallManager installation, institutions had to manually configure OUIs into the switches for them to work with the Cisco handsets. Since around 2009 this has not been necessary.

We have seen several different ways to configure the 3Com/HP Comware switches for the Cisco phones (With even more options on the web). They all appear to work. If there are any HP Comware gurus out there who would like to comment on any of this, please get in touch.

Methods 1 & 2

At the global level, enter the command

# lldp enable

On each port you have to define the port as either trunk

# port link-type trunk

or hybrid

# port link-type hybrid

Then you have to add the voice VLAN as tagged:

# port hybrid vlan 9999 tagged

or

# port trunk vlan 9999 tagged

Next we need some mechanism for the switch to tell the phone what the VLAN is.

Method 1 (Only)

At the global level, enter the command

# lldp compliance cdp

On each port enter the commands:

# undo voice vlan mode auto# voice vlan 9999 enable

Method 2 (Only)

On each port, enter the command

# lldp voice-vlan 9999

Method 3

This is a new addition to this page from a Comware 5510 switch.

At the global level do:

lldp global enablelldp compliance cdp

On each port, enter the commands:

port link-mode bridgeport link-type hybridvoice-vlan qos trustvoice-vlan 9999 enablestp edged-portcdp voice-vlan 9999lldp tlv-enable med-tlv network-policy 9999qos trust dscpqos wrr ef group spqos gts queue 5 cir 9984 cbs 626688 poe enable

3905 Phones

We've had reports that 3905 phones can sometimes cause issues. Entering the command

# lldp admin-status rx

on each port has been known to help.

HP & HPE/Aruba

At the global level, enter the following commands:

  (config)# vlan 9999  (vlan-9999)# name "Voice VLAN"  (vlan-9999)# voice  (vlan-9999)# tagged 1-20 (or whatever ports you require)  (vlan-9999)# exit

All that this does is allows the switch to tell the phone, via LLDP, what VLAN the phone should use.

By default, the HPs have 4 queue QoS model, which puts the voice signalling traffic in with normal data. HPs have an 8 queue QoS model which does separate the voice signalling from bulk data, which you may want to consider. This can be enabled by the command:

(config)# qos queue-config 8-queues

NOTE: This will cause a switch reboot!

3905 Phones

We've had reports that 3905 phones can sometimes have issues. Entering the command

# lldp admin-status <PORT> rxonly

for each port has been known to help.

Cisco

First, at the global level, enter the command

(config)# auto qos

This will add a lot of commands to your configuration. The exact commands vary slightly between IOS versions. For most people, you can ignore the differences.

Next, on each port to support a Cisco VoIP device, enter:

(config)# int f1/0(config-if)# auto qos voip cisco-phone(config-if)# switchport mode access(config-if)# switchport voice vlan 9999(config-if)# spanning-tree portfast(config-if)# mls qos trust device cisco-phone

BGP Connected Institutions

With BGP, instead of getting a voice VLAN, you just get a voice subnet. If you are migrating to BGP from a traditional PoP connection, Network Systems can allocate you a temporary test subnet so you don't have to worry about breaking your current working voice infrastructure. As such, BGP Connected institutions have extra work to do, above getting their edge switches configured in that they have to configure their routers too.

At a minimum, institutions need to set the DHCP relay address on their routers. This needs to be:

• 172.18.8.3
• 172.18.9.3

We do not support institutions running their own DHCP server for the voice subnets/VLANs.

In addition to this, you may wish to add an access list to the subnet to restrict access to the phones. For traffic TO the VoIP phones, a suggestion is:

!Allow the rest of the phone system to talk to the phonespermit ip 172.18.0.0 0.1.255.255 X.X.X.X Y.Y.Y.Ypermit ip 131.111.110.0 0.0.0.255 X.X.X.X Y.Y.Y.Ypermit ip 128.232.130.224 0.0.0.31 X.X.X.X Y.Y.Y.Y!Allow .12 subnet (As per CUDN rules)permit ip 131.111.12.0 0.0.0.255 X.X.X.X Y.Y.Y.Y!Allow PINGspermit icmp any X.X.X.X Y.Y.Y.Y echo!Allow access from UIS Staff VPN Addresses (Helps with troubleshooting)permit ip 172.16.56.0 0.0.0.255 X.X.X.X Y.Y.Y.Y!Allow media from Jabber clientspermit udp any range 16384 32767 X.X.X.X Y.Y.Y.Y range 16384 32767

You will then have to write an appropriate access for traffic going the other way (Traffic FROM the VoIP phones).

!Allow the phones to talk to the phone systempermit ip X.X.X.X Y.Y.Y.Y 172.18.0.0 0.1.255.255permit ip X.X.X.X Y.Y.Y.Y 131.111.110.0 0.0.0.255permit ip X.X.X.X Y.Y.Y.Y 128.232.130.224 0.0.0.31!Allow the phones to DHCP.permit udp any eq 68 host 255.255.255.255 eq 67!Allow .12 subnet (As per CUDN rules)permit ip X.X.X.X Y.Y.Y.Y 131.111.12.0 0.0.0.255!Allow access from UIS Staff VPN Addresses (Helps with troubleshooting)permit ip 172.16.56.0 0.0.0.255 X.X.X.X Y.Y.Y.Y !Allow PINGspermit icmp X.X.X.X Y.Y.Y.Y any echo-reply!Allow media from Jabber clients!(Phones are on RFC1918 CUDN Private address, so any destination can't leak!outside of the CUDN)permit udp X.X.X.X Y.Y.Y.Y range 16384 32767 any range 16384 32767

You need to change the "X.X.X.X Y.Y.Y.Y" to the subnet & mask for your voice subnet.

If you decide to use your own filter configurations, we STRONGLY advise you to heavily restrict access to ports 80 & 22 on the phones. You also need to remember that voice traffic can come from anywhere on the CUDN, not just 172.18.0.0/15 (See uis.help.cam.ac.uk for details of the current list of IPv4 Subnets in use on the CUDN). Voice traffic should not arrive with IP addresses from outside the CUDN.

As of April 2020 the filter requirements are being updated. The changes are:

1. The phones will now use the central CUDN name servers (131.111.8.42 & 131.111.12.20)
2. The phones will now use the central CUDN time servers (131.111.110.10,131.111.110.80 & 131.111.110.129)
3. At a minimum, video devices will need to be able to make HTTPS connections to the public Internet. The CUDN Central NAT service is configured to allow this.

As of April 2023 the following change was made to the filters:

1. Added 128.232.130.224/27 to the list of public subnets for the phone system

As of the Feb 2026 the following change was made to the filters:

1. Changed the UIS subnets to be the UIS VPN subnet rather than the RNB Office subnets.

The phone system does not currently use IPv6.

Power Over Ethernet

Here's a quick summary of the different Power over Ethernet standards

796x phones ALWAYS require a power brick when they have a sidecar attached.

8851s require a power brick if more than one side car is attached.

8861 & 8865 handsets do not require power bricks when connected to a PoE+ (802.3.at) network port.

NOTE: Not all network switches are able to supply power to all their ports at the same time.  Consult the data sheet/specifications for your switch to determine the available PoE power budget.

DSCP

If you wish to manually config QoS policies on your routers and switches, you need to make sure you correctly identify the voice traffic.

The RTP voice traffic uses DSCP 46, and the signalling uses DSCP 24.

If you spot a Cisco VoIP device using values other than this, please let us know so we can investigate and correct it. (There were bugs in some ATA firmware versions where they use the wrong DSCP values.)

The CUDN PoPs clean up some of the QoS markings as they enter the CUDN backbone. (So don't bother marking your BitTorrent download with a voice DSCP setting - the PoP will remove it)

Multicast

Currently, the phone system does not require or make use of multicast. However, we can see that sometime in the future it will be required for some new services/features. Institutions are asked to not make any setups that would preclude the use of multicast. For reference, we anticipate that the multicast system would be PIM Sparse Mode.

We do NOT anticipate that multicast will be a requirement to have a Cisco VoIP phone.

Firewalls

We advise against running the voice traffic through firewalls. Firewalls tend to introduce unacceptable delays and jitter in the voice traffic.

Another problem is that firewalls try and inspect the signalling and block anything they don't recognise. This can result in difficult to track down problems.

Manually setting an ATA's voice VLAN

ATA 191

Cisco's instructions for manually setting the VLAN on an ATA 191 can be found here.

In summary, all you will need to do is to plug an analogue phone into the new ATA, then go off hook and press the star key 4 times. It will ask for a password, which is 24726, and then you should be given a list of options.

Option 231 (followed by the # key) is the one you need to change, and this should be set to XXXX followed by #  (XXXX should be substituted with your VLAN ID which we can provide to you if you do not know it - email phones@uis.cam.ac.uk for this).

You then need to save this setting (option 1).

Once this is set you *may* need to power cycle the ATA, but sometimes they do just come online after a few minutes.

Troubleshooting

These are some general troubleshooting tips and suggestions for Cisco phones. If you have any more, feel free to let the Telecoms Helpdesk phone and we'll update this page.

On institution PoPs, ports 19 & 20 are configured as edge ports for testing Cisco handsets. This can be useful to identify if a phone is at fault or if there's a local switch configuration issue.

7911 Phones

These phones are obsolete and are now causing problems. Institutions should remove these devices as soon as practicable from the network.

PoE powered phone not powering up.

A very trivial reason for this, is plugging the network cable into the wrong socket on the phone. The phone will only draw power from the Network socket, not from the Computer socket.

Another reason for not powering up, is if the phone has a side car, but a power brick is not being used or has become disconnected.

78xx Phones

Prior to December 8th 2014, there was a bug in 78xx phones where if the phone could not get an IP address, you couldn't configure the VLAN information. The way round this, is to plug the phone into a known working port (e.g. the PoP test ports), configure the VLAN, then move the phone to where you need it.

On December 8th, we uploaded a new version of firmware in which this bug is now fixed. Any 78xx phones dispatched from Telecoms after this date should have this new version of firmware installed. Any installed phones will update automatically when they reboot.

VLANs

Cisco phones can either pickup their VLAN information via CDP or LLDP, or you can manually configure the voice VLAN on the phone itself. Phones are slightly unusual to normal networking equipment in that the dynamic CDP/LLDP configuration methods override the static configuration method. To see what a phone is currently doing (The exact steps vary based on phone model), go to Settings -> Network Configuration -> Operational VLAN ID & Admin VLAN ID.

The Admin VLAN ID setting is what has been statically configured into the phone as the voice VLAN to use.

The Operational VLAN ID is the VLAN ID the phone is using. In the case of LLDP/CDP, this is the VLAN transmitted from the switch to the phone.

If the Operational VLAN is not what you expected (and not what is set in Admin VLAN) then some device on your network is transmitting errant CDP or LLDP information. Some institutions don't run CDP or LLDP at all, and statically configure everything. In itself, that is fine. But if a new switch is added anywhere on the network, it could affect phones several hops away if it starts transmits CDP or LLDP information. A switch which does not run CDP or LLDP will pass these packets through untouched, whereas a switch running CDP or LLDP will not propagate these packets at all, but instead, transmit its own CDP/LLDP packets.

Configuring IP

This message on a Cisco phone can hide a multitude of sins. It basically means that IP connectivity to CallManager isn't working. This could be because:

• The phone isn't on the correct VLAN
• The phone can't get an IP Address via DHCP
• The phone can't talk to CallManager. (e.g. Network/Firewall/Routing issues)

DHCP

Phones can only get their IP address via DHCP and Telecoms run the DHCP servers for the University CallManager. Institutions often run DHCP snooping as a security measure. Occasionally, DHCP snooping breaks and it does not pass the DHCP packets (in or out). For a normal network device, this is detectable as the device's DHCP lease expires and the device stops being able to communicate. However Cisco phones are naughty: when their DHCP lease expires they carry on using the expired DHCP lease! To double check if the phone really is talking to the DHCP server, go to the network settings on the phone, release the IP address and wait and see if it gets a fresh address from our DHCP server.

Call Not Being Answered

There are three common causes for calls not being answered when the handset is lifted.

1. Dirt. Dirt can often build up around the hook switch causing it to not work properly. Cleaning the phone with a wet-wipe/computer cleaning wipe usually removes the built up dirt quite easily.
2. Handset not being replaced. If the handset is not properly replaced after ending the previous call, the phone won't detect you picking up the handset. One common cause of this is the handset wall hook being in the wrong position. (The handset wall hook is the bit of plastic that can be removed and rotated to stop the handset falling off the phone when the phone is wall mounted).
3. Faulty Hook Switch. There is a design fault in the 7941 & 7961 handsets where the hook switch (the bit which detects when you've lifted the handset) breaks. The symptom of this, is that you lift the handset, but the call continues ringing. If you experience this, contact the Telecoms Helpdesk.

Voice Quality

Before getting too technical with troubleshooting poor voice quality, a common source of poor voice quality is a faulty bottom or curly cord. These frequently get damaged. The Telecoms Helpdesk will replace these free of charge. Wiggling the cord whilst on a call, or just swapping it with one from another phone will usually identify this cause.

On the Cisco phones with displays, there is usually an option to see call statistics. The exact location of this varies based on phone model. On a 796x phone, you can find this under Settings -> Status -> Call Statistics. This shows the network statistics for the current or last call made.

Things to look at in the list are:

Codec & packet size.

If the send and receive values for these are different, this indicates a fault on the phone system and should be reported to the Telecoms Helpdesk.

Sent & Received packet counts.

These should be almost identical. A few packets difference shouldn't matter.

Average & Max Jitter.

These should both be fairly low. A large difference between the average and maximum values can be an indicator of network problems.

Discarded and Lost Packets.

These should both be low (ideally zero). If these are increasing during a call, it is an indication of network issues.

Factory Resetting Phones

We sometimes ask you to factory reset a phone to try to fix a fault before we swap the phone out. Whilst the key sequence to do this is not a closely guarded secret, we would ask that you only perform this on the instruction of the Telecoms Helpdesk and only use a network point known to be working normally for Cisco handsets. If the phone is stuck trying to upgrade its firmware, trying plugging into the PoP phone test ports.

Some people may try and be helpful and Google their problem before calling the Telecoms Helpdesk. You may find a different reset key sequence (Which starts 349) This is a deeper reset than the standard key sequence. As such, the phone may require a special network configuration for it to successfully boot and we strongly recommend that you don't try this sequence.

Proximity

Cisco are deprecating Proximity.

Cisco Jabber

Cisco Jabber is the soft-phone application that Cisco supply for CallManager. Jabber is deprecated and users should be using MS-Teams instead if they still require PSTN connectivity.

Spectralink DECT System

The Spectralink DECT Access Points do not support CDP or LLDP-MED. Either the network point they plug into must have the voice VLAN sent untagged, or the access point has to have the voice VLAN statically configured. The VLAN can only be configured via the access point's web interface. It is much easier if you specify at order time if you want the voice VLAN tagged or untagged. By default we will ship the DECT Access Points tagged.

To support call roaming between access points, the local network needs to support ethernet link local multicast.

Web Dialler API

This is now deprecated.