Telephony network preparation
How to get your network ready for Telephony
Network preparation for telephony
Notice: Telephony replacement project
In response to BT switching off analogue lines in late 2025, the Telephony Replacement Project is currently coordinating the replacement of centrally managed analogue and critical phone lines. In future (likely later in 2025) the project will also be reviewing the Chorus VOIP (digital line) service. For more information see the Telephony replacement project webpage.
Before you can use Chorus telephony or Teams desk phones on your site there will be some changes that need to take place within your unit's local network.
There are two ways a unit can adopt the University's telephony services – using either converged or separated networking. Both options are described below.
Each Frodo should already have an access port for your data connection, but as part of the preparation a separate Chorus access port will be enabled on your FroDo.
You can use whatever vlan number you want internally, but using 341 would make it easier to set up DECT and Polycom phones on Chorus. Devices using Teams Telephony will use vlan 340.
A converged network is one where all of your network ports can be used for voice and data connections because the edge switches are setup to recognise if a phone or a computer is connected. This is done through the addition of a voice VLAN and some QoS settings.
For example, assume that you are using VLAN 100 for your internal data network, that you have created a Chorus voice network on VLAN 200, and a Teams voice network on VLAN 300. In this scenario your internal main switch is configured to understand VLANs 100, 200, and 300 and it must present these three VLANs as three separate access ports (not trunk ports) as uplinks to the FroDo.
To deliver the Chorus and Teams voice networks to other downstream switches, the trunk ports between switch 1 and 2, and beyond, will need to be 'tagged' to include voice VLANs 200 and 300 alongside VLAN 100.
On Switch 2 you could have a mix of purely access ports for data and voice, or hybrid ports. Most modern switches support hybrid ports nowadays. A hybrid port is recommended – as it will carry the data traffic as untagged and any voice traffic as tagged (hence "converged network").
_
Your switches would also need to be setup for QoS as the voice traffic is sharing network ports and switch trunk links with the data network, there is more QoS information further on in this guide.
Option for switches without LLDP/LLDP-MED capabilities
If there are enough patch ports at the required location then separating the phone network and using 'access' ports which don't require LLDP to function is an option, see below for details on a separated network.
If you choose to operate physically separated internal networks for the services you provide you can have switches and Ethernet points dedicated solely to telephony, while others are reserved solely for data. You may need to label them appropriately to avoid end-user confusion.
For example, consider a scenario in which you use VLAN 100 for your current data network, and VLAN 200 as the new voice network. Instead of relying on the current data network infrastructure to handle an extra VLAN, a second physical network is added (but which also runs on a different VLAN).
The standard FroDo data access ports would connect to the data network on switch 1, and the Telephony port would connect to the voice network on switch 2.
Here, switch 1 and 2 would each present their respective network (VLAN 100 or 200) as an access port for the FroDo connection. Downstream, all ports would be presented as access ports, as only one VLAN is being carried (unless perhaps you're using a management VLAN on your switches). In this setup one network can only serve data and the other can only serve voice.
An End-to-end QoS enabled network is required for stable telephony. This is to mitigate issues during busy times of day, or perhaps in the future, when large amounts of data traffic will affect the delivery of voice packets (as voice packets need to arrive in the correct order and in-time).
If you are using a separate physical network for your VoIP phones this is less of a priority, however if you are using a converged network, or passing through a shared core switch, then QoS is important.
The proposed QoS packet marking (DSCP Class Selectors) is as follows:
| Traffic Type | DiffServe | DSCP | Layer 2 COS | Drop Precedence |
|---|---|---|---|---|
| Voice Payload | EF | 46 | 5 | Strict Priority |
| Signalling | CS3 | 24 | 3 | Low |
| Video | AF41 | 34 | 4 |
Low |
| Network Control | CS7 | 56 | 7 | Network Control |
ITSS must identify the device types in their network. In Chorus there can be three types of devices:
- Untrusted – usually a workstation where the user can interfere try to send traffic marked with increased priority.
- Trusted – A physical phone device that sets the priority for the voice and signalling packets itself.
- Conditionally trusted – where a single physical connection hosts both trusted and an untrusted device
When Chorus phones are used via the voice VLAN, the packets are already marked according to the scheme given above, hence the only thing that needs to be configured is the DSCP trust settings on the switch port. You will also need to configure the queue for voice payload and network signalling as strict priority. You can plan the rest of the queues according to your needs.
Get support
If you cannot find the solution you need here then we have other ways to get IT support
Submit a suggestion, compliment or complaint
