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 [email protected]
- General
- 3Com/HP Comware Switches
- HP ProCurve
- Cisco IOS
- BGP Connected Institutions
- DSCP
- Firewalls
- Setting An ATA's voice VLAN
- Troubleshooting
- Jabber
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 amongst 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.
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
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
On each port, enter the command
# lldp voice-vlan 9999
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
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
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
BGP Connected institutions have extra work to do, above getting their edge switches configured: they have to configure their routers too.
At a minimum, institutions need to set the DHCP relay address on their routers. Currently, these need to be:
- 172.18.1.3
- 172.18.1.39
In addition to this, you may wish to add an access list to the subnet to restrict access to the phones. For outbound traffic (Traffic TO the VoIP phones), a suggestion is:
!Allow the rest of the phone system to talk to the phones permit ip 172.18.0.0 0.1.255.255 any !Allow the phones to DHCP & Boot. permit udp 172.18.1.0 0.0.0.63 eq bootps any eq bootpc !Allow .12 subnet (As per CUDN rules) permit ip 131.111.12.0 0.0.0.255 any !Allow PINGs permit icmp any any echo !Allow access from UCS CUDN Private Addresses (Helps with troubleshooting) permit ip 172.24.192.0 0.0.7.255 any !Allow access from UCS CUDN Public Addresses (Helps with troubleshooting) permit ip 131.111.56.0 0.0.1.255 any
!Allow audio from Jabber clients
permit udp any range 16384 32767 any range 16384 32767
You should change the destination "any" to a suitable network & subnet mask. You will then have to write an appropriate access for traffic going the other way (Traffic FROM the VoIP phones). This is left as an exercise for the reader.
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)
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 trace down problems.
Manually setting an ATA's voice VLAN
ATA 186
You will need an analogue phone plugged into the first port on the ATA. Lift the telephone handset, and press the clear red-lit button on top of the ATA 186. You will hear an American robotic voice say "Configuration Menu". On the phone dial 323#. Next dial 82#. Press 3 to save the value.
Next, dial 324#. Take your voice VLAN number, multiply it by 262144 and add 18. This is the value you type into the ATA as the VLAN number - and finish with # and then press 3 to save.
You can then hang up, and after a few seconds the ATA should start using the new VLAN.
To put the ATA back into automatic discovery mode for the voice VLAN, go back into the configuration menu, enter 323#2#3 and hang up.
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.
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.
ATA190
The firmware that is currently installed on ATA190s from the factory has CDP disabled. The only way to get these devices to work, is to plug them into a port with the voice VLAN presented as untagged first. Once the ATA auto upgrades to the latest firmware, it will work on a normal tagged LLDP/CDP configured port.
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.
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.
- 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.
- 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).
- 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.
Cisco Jabber
Cisco Jabber is the soft-phone application that Cisco supply for CallManager. It has clients for Windows, Mac, Apple iOS and Android. Cisco Jabber presents some challenges as it is a soft phone that runs on peoples normal desktop PCs and is not on the normal voice VLANs. This presents problems for both the phone system and institution PCs as these two systems are usually kept very separate by firewalls.
In a typical deployment, Cisco assume that people's Jabber devices are inside the same firewall as the CallManager phone system and that all Jabber devices (Macs, Windows PCs, etc) can all talk to each other. Unfortunately, at the University this is not the case, so we have had to configure Jabber so that it assumes everyone is outside the corporate firewall.
When Jabber is "outside" some features are unavailable. These include:
- File Transfer
- Sending Screen Captures
Jabber & DNS
Jabber clients decide whether they are "inside" or "outside" via DNS. If they are "inside", the DNS name _cisco-uds._tcp.cam.ac.uk should have some SRV records.
$ nslookup -type=srv _cisco-uds._tcp.cam.ac.uk Server: 131.111.8.42 Address: 131.111.8.42#53 Non-authoritative answer: _cisco-uds._tcp.cam.ac.uk service = 0 0 8443 cucmpub-a01.phone.private.cam.ac.uk. _cisco-uds._tcp.cam.ac.uk service = 0 0 8443 cucmsub-b01.phone.private.cam.ac.uk.
If they are "outside" the system, then the record _collab-edge._tls.cam.ac.uk should have some SRV records.
$ nslookup -type=srv _collab-edge._tls.cam.ac.uk Server: 131.111.8.42 Address: 131.111.8.42#53 Non-authoritative answer: _collab-edge._tls.cam.ac.uk service = 0 0 8443 vcs-e-a01.phone.cam.ac.uk. _collab-edge._tls.cam.ac.uk service = 0 0 8443 vcs-e-b01.phone.cam.ac.uk.
Jabber clients need one of these domain names to resolve to some SRV records. If neither resolves, then Jabber is unable to find the CallManager system and hence login.
Institution NAT/Firewall Configuration
If the NAT/Firewall that your Jabber devices sit behind restricts outbound connections, then you need to allow the following outbound traffic (and obviously the replies to these connections too!):
- TCP
- 8443
- 5060
- 5061
- 5222
- UDP
- 24000 to 29999
- 36002 to 59999
Ideally, we would like you to allow the traffic with 131.111.110.0/25. If this range makes you unhappy then you need to put in the following individual IP addresses - and periodically check back here in case the list of addresses changes.
- 131.111.110.14
- 131.111.110.84
Non Firewalled/NATed PCs
If your institution's Jabber devices are not behind any NAT or firewall (CUDN private addresses are fine) then you can ease the load on our servers by slaving the zone "_cisco-uds._tcp.cam.ac.uk". If you're already slaving zones, you can add the following zone to your BIND configuration.
zone "_cisco-uds._tcp.cam.ac.uk" {
type slave;
file "db.jabber";
masters { 131.111.110.22; 131.111.110.92; 193.60.95.84; };
};
We would appreciate feedback on how this works for an institution.
Jabber Cache
Jabber maintains a cache for details of contacts. Occasionally, this may have erroneous information stored in it, and will need clearing. The way to do this, is to delete the directory C:\Users\<User>\AppData\Local\Cisco\Unified Communications\ on the user's Windows computer. For Mac users, the necessary directory is /Users/<userid>/Library/Caches/com.cisco.Jabber/<user_email>