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 enable
lldp compliance cdp
On each port, enter the commands:
port link-mode bridge
port link-type hybrid
voice-vlan qos trust
voice-vlan 9999 enable
stp edged-port
cdp voice-vlan 9999
lldp tlv-enable med-tlv network-policy 9999
qos trust dscp
qos wrr ef group sp
qos 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 phones
permit ip 172.18.0.0 0.1.255.255 X.X.X.X Y.Y.Y.Y
permit ip 131.111.110.0 0.0.0.255 X.X.X.X Y.Y.Y.Y
permit 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 PINGs
permit icmp any X.X.X.X Y.Y.Y.Y echo
!Allow access from UIS CUDN Private Addresses (Helps with troubleshooting)
permit ip 172.24.192.0 0.0.7.255 X.X.X.X Y.Y.Y.Y
!Allow access from UIS CUDN Public Addresses (Helps with troubleshooting)
permit ip 131.111.56.0 0.0.1.255 X.X.X.X Y.Y.Y.Y
!Allow media from Jabber clients
permit 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 system
permit ip X.X.X.X Y.Y.Y.Y 172.18.0.0 0.1.255.255
permit ip X.X.X.X Y.Y.Y.Y 131.111.110.0 0.0.0.255
permit 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 CUDN Public Addresses (Helps with troubleshooting)
permit ip X.X.X.X Y.Y.Y.Y 131.111.56.0 0.0.1.255
!Allow access from UIS CUDN Private Addresses (Helps with troubleshooting)
permit ip X.X.X.X Y.Y.Y.Y 172.24.192.0 0.0.7.255
!Allow PINGs
permit 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:
- The phones will now use the central CUDN name servers (131.111.8.42 & 131.111.12.20)
- The phones will now use the central CUDN time servers (131.111.110.10,131.111.110.80 & 131.111.110.129)
- 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:
- Added 128.232.130.224/27 to the list of public subnets for the phone system
The phone system does not currently use IPv6.
Power Over Ethernet
Here's a quick summary of the different Power over Ethernet standards
Name | Standard | Type | Max Power |
---|---|---|---|
Cisco PoE | Cisco Propriety | 10W | |
Universal PoE | Cisco Propriety | 60W | |
PoE | 802.3af-2003 | Type 1 | 15W |
PoE+ | 802.3at-2009 | Type 2 | 25.5W |
802.3bt | Type 3 | 55W | |
802.3bt | Type 4 | 90-100W |
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.
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.
- 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.
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
Proximity is used to allow wireless screen sharing with Cisco video conferencing devices. Proximity works by the video conference unit (via the attached screen) transmitting an ultrasonic signal which identifies the video conference unit. The client device picks up this ultrasonic signal and uses the information to connect back to the video conference unit.
For the client device to connect to the video conference unit, the client must be able to connect to CUDN private IP addresses. If you're using the UIS Wireless service, this is already enabled.
Some people have experienced problems with their device picking up the ultrasonic signal. We've noticed that the directionality on some client device's microphones can be too good. So just turning the device's screen to face the video display can help in picking up the signal. Once the client has picked up the signal, you can turn the client device back around again.
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
- Lookup Integration
- Control of desk phones.
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 (and provide more Jabber features to your end users) 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; 131.111.110.131; };
};
We would appreciate feedback on how this works for an institution. We would also appreciate feedback on configuring the Windows DNS service.
NOTE: If an institution does slave the _cisco-uds._tcp.cam.ac.uk domain, you MUST make sure that your DNS servers do NOT leak answers to clients outside your network.
Client Update Notifications
There is a mailing list for notifications of when new Jabber Windows & Mac client software is released (uis-jabber-announce@lists.cam.ac.uk)
To request to be added to the list, please contact the Telecoms Helpdesk.
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>
Jabber Logs
- On Windows, the Jabber log files are in AppData\Local\Cisco\Unified Communications\Jabber\CSF\Logs
- On Macs, the Jabber logs files are in ~/Library/Logs/Jabber
Jabber Problem Reports
If a user is having problem with Jabber, please ask them to create a problem report to send to us along with their log files.
The problem report can be created as follows:
- In Jabber, click the settings icon (the cog wheel), then select "Help" and click "Report a Problem"
- Complete the form and click "Save" to save the file. Do NOT check the "Include Memory Dump" checkbox.
- If there is no "Save" button then click "Send", the sending should fail and you will then be given the option to save the file.
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
We don't (yet..) have a formal API for making calls via a web page. You can, however, (ab)use My.Phone.
You can make a HTTP POST request to https://my.phone.cam.ac.uk/myphone/speeddial/dial and supply the parameter "number" with the phone number that you wish to dial.
There's also a hang up API too: https://my.phone.cam.ac.uk/myphone/speeddial/hangup.
Caveats
- The "api" is really expecting a web browser, so errors will come back as HTML, rather than anything machine readable.
- The client must already be Raven authenticated
- The client must either have the cookie DIAL_DEVICE set or you must supply the device name as a parameter called "device"
"I don't want to use HTTP POST. Why can't we do a HTTP GET?"
The RFCs for HTTP clearly say that HTTP methods such as GET must be "safe" and have no side effects. If a web crawler discovers your phone directory you'll suddenly find lots of phone calls being made!
Don't try and plead your special case.
When a more formal API is done, it will still only support POST for dialing & hanging up.