skip to primary navigationskip to content
 

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 helpdesk@phone.cam.ac.uk

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 .

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

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

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. Currently, these need to be:

  • 172.18.1.3
  • 172.18.1.39
  • 172.18.2.240 (This one will be coming on line sometime in the future. It should be pingable)

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
!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
!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.

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 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.

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.

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.

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 .

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.

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

  1. The "api" is really expecting a web browser, so errors will come back as HTML, rather than anything machine readable.
  2. The client must already be Raven authenticated
  3. 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.