QoS Configuration Guide for VoIP and Microsoft Teams

You upgraded to a business VoIP phone system. Your NBN connection has plenty of headroom on paper. But calls are choppy. Words drop out mid-sentence. Conversations have that half-second delay that makes people talk over each other. Video calls freeze at exactly the wrong moment.

This is not a bandwidth problem. It is a prioritisation problem.

Your network does not know that a live phone call is more time-sensitive than someone downloading a file or streaming a video. Without Quality of Service configuration, every packet competes equally for network resources. When the network gets busy – and on a shared business connection, it will – voice and video traffic loses that competition constantly, because the consequences of a late packet in a file download are invisible, but the consequences of a late voice packet are immediately audible.

QoS configuration is the process of teaching your network to treat different types of traffic differently. Voice packets get processed first. Video conferencing gets guaranteed bandwidth. Background file transfers wait their turn. The result is clear, consistent call quality regardless of what else is happening on your network.

This guide explains everything Australian businesses need to know to configure QoS properly – what it is, how it works at the technical level, how to configure it for VoIP and Microsoft Teams, how to handle it over WiFi, how NBN connections factor in, and how to troubleshoot call quality problems when they persist after QoS is in place.

At CodeHyper, we deploy and manage business VoIP and network infrastructure for organisations across Sydney. QoS configuration is one of the most consistently underimplemented parts of a VoIP rollout – and one of the most impactful when done correctly. Our VoIP services and business internet solutions are built on properly engineered QoS from the start.

What Is QoS and Why Does It Matter for VoIP?

Quality of Service (QoS) is a set of network technologies that manage how bandwidth is allocated and how different types of traffic are prioritised when the network is under load.

Without QoS, your network operates on what is called best-effort delivery. Every packet – whether it belongs to a live phone call, a large file upload, a software update running in the background, or a video stream – is treated identically. The network does its best to deliver everything, but under congestion, packets are queued and delivered in the order they arrive, with no consideration for which traffic type can tolerate a delay and which cannot.

Voice and video conferencing traffic cannot tolerate delay. Voice is a real-time application – the conversation is happening live, and packets that arrive late are simply discarded, because playing them out-of-sequence or long after they were sent would create worse audio than silence. This is fundamentally different from data traffic, where a packet that arrives 200 milliseconds late is completely imperceptible to the end user.

The three enemies of voice call quality:

Latency is the delay between a packet being sent and being received. One-way latency above 150 milliseconds begins to feel like a noticeable lag in conversation. Above 300 milliseconds, conversations become dysfunctional – people regularly interrupt each other because they cannot tell when the other person has stopped speaking. Microsoft’s recommended maximum one-way latency for Teams audio is under 50 milliseconds within your network.

Jitter is variation in packet arrival timing. Even if average latency is acceptable, if packets arrive in bursts – some very quickly, some with significant delays – the receiving endpoint’s jitter buffer cannot smooth it out, and audio quality suffers. Jitter above 30 milliseconds is perceptible; above 50 milliseconds it significantly degrades call quality. Microsoft recommends keeping jitter below 15 milliseconds for Teams.

Packet loss is packets that never arrive at all. TCP-based traffic will retransmit lost packets automatically – the user just experiences a slight slowdown. Voice traffic uses UDP, which does not retransmit. A lost voice packet is a missing audio fragment. Packet loss above one per cent is noticeable; above five per cent, calls become unreliable. Microsoft’s recommended maximum sustained packet loss for Teams audio is below one per cent.

QoS directly addresses all three by ensuring voice packets are served ahead of non-time-sensitive traffic, reducing queue wait times (latency), smoothing out delivery variation (jitter), and reducing the probability that voice packets will be dropped under congestion (packet loss).

How QoS Works: Classification, Marking, and Queuing

Understanding the mechanism helps you configure it correctly and troubleshoot it when something is not working as expected. QoS operates through three sequential steps: classifying traffic, marking it, and queuing it appropriately.

Classification

Before a packet can be prioritised, the network needs to know what type of traffic it is. Classification is the process of identifying packets by their characteristics – source or destination IP address, protocol (UDP or TCP), port number, or DSCP value already present in the packet header.

For VoIP, classification typically matches on:

• SIP signalling traffic: UDP/TCP port 5060 and 5061 (standard SIP ports)
• RTP voice media traffic: UDP port ranges, typically 10000–20000 or 16384–32767 depending on your VoIP provider and PBX configuration
• For Microsoft Teams specifically: UDP ports 50000–50019 (audio), 50020–50039 (video), 50040–50059 (application sharing), or DSCP values already marked by the Teams client

Marking

Once traffic is classified, it is marked with a priority value that all downstream network devices can read and act on. There are two marking systems, operating at different layers of the network:

DSCP (Differentiated Services Code Point) operates at Layer 3 – it is a 6-bit value written into the IP header of each packet. DSCP is the standard for modern enterprise QoS and is the marking system used for VoIP and Microsoft Teams. DSCP values are preserved as packets travel through routed networks, including across the internet – unless a device in the path deliberately strips or ignores them.

The standard DSCP values for voice and unified communications traffic are:

CoS (Class of Service / 802.1p) operates at Layer 2 – it is a 3-bit priority value embedded in the Ethernet frame header (in the VLAN tag). CoS is relevant on switched LAN segments and is typically mapped from DSCP values at each switch. A VoIP phone or IP desk phone that sends 802.1p priority-tagged frames will have those tags stripped at the router if the router does not translate them to DSCP – so ensuring the mapping between CoS and DSCP is consistent across your switching and routing infrastructure is important.

Queuing

Once packets are marked, network devices use queuing disciplines to serve them in order of priority. The most common queuing method for voice traffic is Strict Priority Queuing (SPQ) or Low-Latency Queueing (LLQ). Under strict priority, packets in the voice queue are always served before packets in any other queue – the voice queue is emptied completely before any lower-priority traffic is processed.

This is effective for voice because voice packets are small and arrive at a steady, predictable rate. The risk is starvation – if voice traffic is extremely high volume, lower-priority queues may never be served. In practice, for business voice traffic, strict priority queuing for voice with weighted fair queuing for other traffic classes is the standard approach that prevents starvation while ensuring voice latency targets are met.

VoIP QoS Configuration: What You Need to Enable and Where

Effective QoS requires consistent configuration at every point in the network path – not just the router. A common failure mode is configuring QoS at the edge router but having unmanaged switches in the middle of the network that strip DSCP markings, or a WiFi access point that does not honour priority values. When any device in the path ignores QoS markings, the traffic reverts to best-effort delivery from that point forward.

The network points that require QoS attention for a business VoIP deployment are:

The router or firewall (edge device): This is the most critical point. The router is where inbound and outbound internet traffic is prioritised, and where upstream NBN traffic shaping occurs. QoS must be configured on both inbound and outbound interfaces. Outbound QoS is straightforward – you are shaping traffic you are sending. Inbound QoS on shared internet connections is more complex because you cannot directly control how traffic arrives from the internet – most implementations use traffic shaping with bandwidth reservation rather than strict priority for inbound flows.

Managed switches (LAN layer): Business-grade managed switches should be configured to trust DSCP markings from known devices (VoIP phones, servers) and to map those markings to appropriate Class of Service priority queues. On edge access ports connecting VoIP phones, configure the switch to trust the DSCP value from the phone. On uplink ports, configure DSCP trust to pass markings upstream.

VoIP phones and endpoints: Hardware IP phones (Yealink, Grandstream, Poly, Cisco) can typically be configured to mark their RTP traffic with DSCP 46 and SIP traffic with DSCP 26 directly from the phone’s web interface or provisioning settings. This endpoint marking is important because it identifies voice traffic at the source rather than relying on the network to classify it by port number.

Softphones and PC-based VoIP clients: Windows and macOS softphones mark traffic through the operating system’s QoS layer. For Microsoft Teams specifically, QoS marking requires either Windows Group Policy configuration (for domain-joined devices) or a Teams client policy applied via the Microsoft Teams admin centre.

WiFi access points: Wireless QoS introduces additional complexity because the 802.11 wireless protocol has its own QoS mechanism called WMM (Wi-Fi Multimedia). WMM maps DSCP values to wireless access categories (Voice, Video, Best Effort, Background). For VoIP over WiFi to work correctly, the access point must have WMM enabled, and the DSCP-to-WMM mapping must be consistent with the wired network QoS configuration. We cover WiFi QoS in more detail below.

Configuring QoS for VoIP: Router-Level Setup

The specific interface for QoS configuration varies by router brand and model, but the underlying configuration logic is the same across all platforms. Here is what needs to be configured and how the key business router platforms approach it.

General Configuration Principles (All Platforms)

Regardless of your router model, the QoS configuration for VoIP follows this pattern:

Step one: Enable QoS on the router. Most business routers have QoS disabled by default. Find the QoS section in your router’s administration interface and enable it.

Step two: Set your total available bandwidth. QoS must know the total bandwidth available on your connection to make correct queuing decisions. Enter your NBN plan’s upload and download speeds. Deliberately set this slightly below your actual plan speed – typically 85 to 90 per cent of your contracted rate – to leave headroom for overhead and prevent the router’s QoS queues from being bypassed when the upstream link is saturated.

Step three: Create a traffic class for VoIP. Define a classification rule that matches your SIP and RTP traffic. Use the following port configuration:

• Protocol: UDP
• Destination ports: 5060 and 5061 (SIP signalling)
• Protocol: UDP
• Destination ports: 10000 to 20000 (RTP voice media – confirm this range with your VoIP provider, as some providers use different ranges)
• Priority: Highest / Critical

Step four: Assign DSCP marking. Mark matched voice traffic with DSCP 46 (EF) for RTP and DSCP 26 (AF31) for SIP signalling. This ensures downstream devices in the path honour the priority you have set.

Step five: Reserve minimum bandwidth. Allocate guaranteed minimum bandwidth for the voice class. Calculate how many simultaneous calls your business makes at peak and multiply by 100 Kbps per call (the conservative estimate that accounts for codec overhead and protocol headers). Reserve that bandwidth for the voice traffic class.

Step six: Assign remaining traffic to lower-priority classes. Business-critical applications (ERP, CRM, cloud file access) should be classified as high but below voice. General browsing and video streaming should be normal or low priority. Large file transfers and backup traffic should be lowest priority.

DrayTek Router QoS Configuration

DrayTek routers are widely deployed in Australian businesses, and their QoS implementation is straightforward. Navigate to Bandwidth Management > Quality of Service. Enable QoS on your WAN interface. DrayTek uses a class-based system – Class 1 is the highest priority (alongside Auto-VoIP), followed by Class 2, Class 3, and unclassified traffic.

Enable the Auto-VoIP setting if your DrayTek supports it – this automatically identifies and prioritises common VoIP protocols. For custom VoIP applications or Microsoft Teams:

• Go to Bandwidth Management > Quality of Service > Class Rule
• Add a new rule for your VoIP application
• Set LAN to All
• Set Port Range to 5060–5061 (UDP) for SIP
• Add a second rule for Port Range 10000–20000 (UDP) for RTP
• Set Priority to Class 1 (highest)
• Enable DSCP marking with value 46 for RTP rules

Ubiquiti UniFi QoS Configuration

Ubiquiti UniFi network equipment is common in Australian small and medium businesses due to its centralised management via the UniFi controller. For VoIP QoS in a UniFi environment:

In the UniFi Network controller, navigate to Settings > Traffic Management. Create a new Traffic Rule for VoIP traffic. Match on the port ranges for your VoIP provider (5060–5061 for SIP, your RTP port range). Set the priority to Highest. Enable DSCP marking with the appropriate DSCP values.

For the switch layer, in the UniFi switch configuration, navigate to Ports > QoS and set the trust mode to DSCP on ports connected to VoIP phones and upstream network devices. This ensures DSCP markings set at the phone or router are preserved as they traverse the LAN.

Fortinet FortiGate QoS Configuration

FortiGate firewalls are used in many Australian business environments, particularly those with higher security requirements. QoS on a FortiGate is implemented through Traffic Shaping Policies.

Navigate to Policy & Objects > Traffic Shapers. Create a shared shaper for VoIP traffic with maximum and guaranteed bandwidth values appropriate for your call volume. Set the priority to High.

Navigate to Policy & Objects > Traffic Shaping Policy. Create a policy matching your firewall security policy for VoIP traffic. In the Source and Destination fields, match on your VoIP server IP ranges and port ranges. Apply your VoIP traffic shaper. Enable DSCP marking with DSCP value 46.

For Microsoft Teams traffic specifically, FortiGate supports application-based traffic shaping using FortiGuard Application Control signatures. Create a traffic shaping policy matching the Microsoft Teams application signature and apply your priority shaper.

pfSense / OPNsense QoS Configuration

For businesses running open-source firewall solutions: in pfSense, QoS is implemented through the Traffic Shaper under Firewall > Traffic Shaper. Use the HFSC (Hierarchical Fair Service Curve) or PRIQ (Priority Queuing) scheduler. Create a queue for voice traffic with a high priority value and guaranteed bandwidth allocation. Create a floating rule that matches SIP and RTP traffic and assigns it to your voice queue.

Microsoft Teams QoS Configuration

Microsoft Teams is the dominant unified communications platform in Australian businesses, combining VoIP calls, video conferencing, and collaboration. Teams requires specific QoS configuration that differs from generic VoIP setup, and Microsoft provides detailed official guidance for it.

Teams uses the following default port ranges for its media traffic:

There are two components to Teams QoS: client-side marking and network-side enforcement.

Client-side marking means configuring the Teams application to mark its own packets with the correct DSCP values before they leave the endpoint. Without client-side marking, the network cannot reliably identify Teams traffic by port number alone, because Teams uses dynamic port allocation and its traffic may be encapsulated in ways that make port-based classification unreliable.

Configuring Teams QoS via Group Policy (Windows, Domain-Joined Devices)

For organisations using Active Directory or Microsoft Entra ID with domain-joined Windows devices, Group Policy is the recommended method for configuring Teams client-side QoS marking.

Create a new Group Policy Object and navigate to Computer Configuration > Windows Settings > Policy-based QoS. Right-click and select Create new policy.

For Teams audio:

• Policy name: Teams Audio QoS
• DSCP value: 46
• Application name: Teams.exe
• Source IP: Any
• Destination IP: Any
• Protocol: UDP
• Source port range: 50000:50019

For Teams video:

• Policy name: Teams Video QoS
• DSCP value: 34
• Application name: Teams.exe
• Source IP: Any
• Destination IP: Any
• Protocol: UDP
• Source port range: 50020:50039

For Teams application sharing:

• Policy name: Teams Sharing QoS
• DSCP value: 18
• Application name: Teams.exe
• Source IP: Any
• Destination IP: Any
• Protocol: UDP
• Source port range: 50040:50059

Apply this GPO to the organisational unit containing your user computers and verify application using the Get-NetQosPolicy PowerShell cmdlet on a test machine.

Configuring Teams QoS via Microsoft Teams Admin Centre

For Microsoft 365 organisations managing Teams via the Teams Admin Centre (admin.teams.microsoft.com), navigate to Meetings > Meeting Settings. Under Network, enable Insert Quality of Service (QoS) markers for real-time media traffic and configure the port ranges and DSCP values as documented above.

This policy applies to Teams traffic on Windows and Mac endpoints managed through the Teams service. Note that this approach requires the network infrastructure to honour the DSCP markings set by the client – the network-side QoS configuration on your router, switches, and access points must be in place for the client-side marking to have any effect.

Confirming Teams QoS is Working

Use the Microsoft Call Quality Dashboard (CQD) at https://cqd.teams.microsoft.com to review audio and video quality metrics across your organisation. CQD provides stream-level metrics including packet loss, jitter, and round-trip time, broken down by network segment, user group, and time period. Poor streams can be investigated by stream direction (inbound or outbound), which helps identify whether the problem is in your LAN, your WAN, or in Microsoft’s network.

For individual call quality verification, during a Teams call navigate to the ellipsis menu > Call Health. This displays real-time metrics for the current call including bit rate, packet loss, jitter, and round-trip time. These metrics should show packet loss below one per cent, jitter below 30 milliseconds, and round-trip time below 200 milliseconds for acceptable call quality.

VoIP Over WiFi: QoS for Wireless Networks

WiFi-based VoIP – whether through wireless IP phones, laptops running Teams, or mobile devices – introduces additional QoS complexity because the wireless medium is shared and contention-based. Configuring DSCP marking on your router and switches does not automatically extend that prioritisation to wireless clients.

WiFi QoS is governed by the 802.11e standard, implemented as Wi-Fi Multimedia (WMM). WMM defines four access categories that map to the 802.11 wireless protocol’s contention-based access mechanism:

• Voice (AC_VO): Highest priority, shortest contention windows
• Video (AC_VI): Second priority
• Best Effort (AC_BE): Standard data traffic
• Background (AC_BK): Lowest priority, longest contention windows

For VoIP traffic to receive Voice priority on the wireless network, the access point must have WMM enabled, and the DSCP values in voice packets must be correctly mapped to the AC_VO access category. The standard mapping is DSCP 46 (EF) → AC_VO, which most enterprise access points implement correctly by default when WMM is enabled.

However, there are several common failure points in wireless VoIP QoS:

Consumer-grade or budget access points often have WMM enabled in name only, implementing it inconsistently or ignoring DSCP-to-WMM mapping entirely. For serious VoIP-over-WiFi deployments, business-grade access points (Cisco Meraki, Ubiquiti UniFi, Aruba, Ruckus) with verified WMM implementation are required.

DSCP stripping at the access point. Some access points do not preserve DSCP markings in packets as they cross from the wired to the wireless network. Verify that your access point is configured to trust and pass DSCP values rather than resetting them to zero at the wireless interface.

Band selection matters. The 2.4 GHz band is more congested and has higher interference susceptibility than 5 GHz, particularly in office environments with multiple overlapping networks. VoIP clients should be guided to the 5 GHz band through band steering configuration on your access points. For the 6 GHz band (WiFi 6E and WiFi 7 networks), interference from legacy devices is absent entirely, providing the cleanest environment for wireless VoIP.

Sufficient signal strength. VoIP calls need a stable WiFi connection. Moving between access points during a call triggers a re-association that typically drops the call or causes a quality disruption. For office environments with mobile VoIP users, ensure adequate access point coverage with good signal overlap to allow seamless roaming, and consider enabling 802.11r (Fast BSS Transition) for faster roaming handoffs between access points.

QoS on NBN Connections: What Australian Businesses Need to Know

The NBN introduces specific considerations for QoS configuration that are important for Australian businesses to understand.

NBN traffic shaping operates upstream of your router. Your NBN connection is subject to traffic management policies set by your retail service provider (RSP). Most business NBN plans are provided with best-effort data, meaning your QoS configuration controls prioritisation within your site but cannot influence how your RSP handles the traffic on the NBN network. Voice traffic marked with DSCP 46 at your router may have those markings preserved, partially preserved, or stripped by your RSP’s network equipment – this varies by provider and plan type.

Bandwidth headroom is critical on NBN. NBN connections, particularly fixed wireless and some FTTN connections, can exhibit variable throughput depending on network congestion, time of day, and weather conditions for fixed wireless. Configuring QoS bandwidth limits at 80 to 85 per cent of your contracted plan speed, rather than 100 per cent, provides a buffer that prevents voice quality from degrading when NBN throughput is slightly below your contracted rate.

Upload bandwidth is the critical constraint. On most asymmetric NBN plans (NBN 100/20, NBN 250/25, NBN 1000/50), the upload speed is significantly lower than the download speed. Voice calls use roughly equal upload and download bandwidth. If you have 20 simultaneous employees on calls using 100 Kbps per call each direction, that is 2 Mbps of upload bandwidth consumed by voice alone. On an NBN 100/20 plan, that leaves only 18 Mbps for all other upload traffic. Calculate your peak concurrent call capacity and verify your upload bandwidth is sufficient before assuming QoS will resolve your quality issues.

Business-grade NBN plans with SLA-backed performance provide more reliable throughput and typically better support for VoIP traffic compared to residential-grade plans resold as business connections. If your business relies heavily on cloud-based VoIP – Microsoft Teams calling, a hosted PBX, or a cloud contact centre – a business NBN plan or dedicated fibre connection is worth evaluating. CodeHyper’s business internet solutions include options appropriate for VoIP-intensive environments.

Hosted PBX and SIP trunk providers vary in their network handling. Some Australian VoIP providers route traffic through their own MPLS networks or have QoS agreements with major NBN RSPs that preserve DSCP markings end-to-end. Others send traffic over the public internet with no end-to-end QoS guarantee. Understanding your provider’s network architecture is important context for how much QoS configuration at your end can improve call quality. Our hosted PBX service is designed to deliver consistent voice quality over business NBN connections.

Voice VLANs: Isolating Voice Traffic at Layer 2

A voice VLAN is a dedicated virtual LAN segment used exclusively for VoIP traffic. Implementing a separate voice VLAN alongside your data VLAN provides several benefits for voice quality and network management.

Traffic isolation. Separating voice traffic onto its own VLAN prevents voice packets from competing with data broadcast traffic at Layer 2. Large broadcast domains with high broadcast rates can introduce latency and jitter in voice traffic – voice VLANs eliminate this by keeping voice traffic in a smaller, quieter Layer 2 domain.

Simplified QoS policy application. When all voice traffic is on a dedicated VLAN, your managed switch can apply QoS prioritisation based on the VLAN tag rather than needing to inspect port numbers or DSCP values for every frame. This is simpler to configure and more reliable.

Security benefits. Voice traffic that is network-accessible from general data VLANs is potentially vulnerable to eavesdropping, toll fraud, and denial-of-service attacks. A dedicated voice VLAN, with firewall rules restricting which devices can reach VoIP servers and SIP trunks, significantly reduces this attack surface. Our network security services include VoIP security assessments that cover VLAN segmentation and SIP security hardening.

Implementation. On managed switches, configure the voice VLAN on access ports connecting IP phones as a tagged VLAN alongside the untagged data VLAN. Most business IP phones support 802.1Q VLAN tagging and can be provisioned with the voice VLAN ID through their configuration interface or auto-provisioning settings. The switch then applies different QoS policies to frames arriving with the voice VLAN tag compared to untagged data frames.

Note that a voice VLAN alone does not enforce traffic prioritisation – it must be paired with QoS policies that map the voice VLAN to a high-priority queue on the switch.

Bandwidth Planning for VoIP

QoS manages available bandwidth more effectively, but it cannot substitute for having sufficient bandwidth in the first place. Before configuring QoS, verify that your internet connection can physically carry the voice traffic you need.

Per-call bandwidth requirements vary by codec:

For planning purposes, use 100 Kbps per simultaneous call in each direction as a conservative estimate that accounts for codec overhead, RTP headers, SRTP encryption, and protocol overhead.

Calculate your concurrent call capacity:

Identify the maximum number of calls your business handles simultaneously during peak periods. Multiply by 100 Kbps per call and by 2 for bidirectional traffic. This is the bandwidth that must be available for voice traffic at all times, regardless of other network activity. Your total available bandwidth must comfortably exceed this figure with room for data traffic.

For example: a business with 20 staff, where a realistic peak of 10 are on calls simultaneously, needs at least 10 × 100 Kbps × 2 = 2 Mbps of dedicated voice bandwidth. On an NBN 100/20 plan with an upload speed of 20 Mbps, voice uses 10 per cent of available upload bandwidth at peak – very manageable. QoS ensures that 10 per cent is always available even when other traffic is competing for the connection.

Reserve bandwidth at 85 per cent of the contracted rate. NBN connections do not always deliver 100 per cent of the contracted speed, particularly FTTN and fixed wireless connections. Configuring QoS to assume 85 per cent of your plan speed prevents a situation where QoS bandwidth allocations exceed actual available bandwidth, which can cause queuing failures.

Troubleshooting VoIP Call Quality After QoS Is Configured

If call quality problems persist after QoS is in place, use this structured approach to identify the cause.

Verify QoS is actually being applied. Use a packet capture tool (Wireshark on a PC, or the built-in capture tool on many business routers) to capture voice traffic and verify that DSCP 46 is present in the IP header of RTP packets. If the DSCP field is zero, QoS marking has not been applied – check whether the problem is at the endpoint (Teams client not marking packets), at the switch (DSCP being stripped), or at the router (QoS rules not matching traffic correctly).

Check whether the problem is local or external. Use Microsoft’s Call Quality Dashboard (for Teams) or your VoIP provider’s quality reporting portal to determine whether call quality issues are occurring on the local LAN, on the WAN connection, or in the service provider’s network. Problems isolated to specific subnets or switch segments point to local network issues. Problems consistent across all users point to the WAN or provider.

Test latency, jitter, and packet loss explicitly. Use a VoIP quality testing tool or ping-based jitter test to measure your actual network metrics against the targets: latency under 150 ms one-way, jitter under 30 ms, packet loss under one per cent. If any metric fails, that narrows the diagnosis significantly.

Common causes of persistent issues after QoS configuration:

The router QoS bandwidth limit is set too high, allowing the queue to be bypassed under congestion. Set it to 85 per cent of actual NBN throughput.

Intermediate devices are stripping DSCP markings. Check every device in the path – unmanaged switches do not honour DSCP and may strip markings; some older firewalls reset DSCP values; some NBN network termination equipment modifies packet headers.

WiFi is the bottleneck, not the wired network. A client on WiFi experiencing poor call quality despite correct router QoS often has a wireless-specific problem – insufficient signal, 2.4 GHz congestion, or WMM not functioning correctly. Test the same client on a wired connection to isolate the wireless variable.

Upload bandwidth is exhausted. Run a speed test during a call quality incident and compare actual upload throughput to contracted speed. If throughput is significantly below plan, contact your RSP – NBN line quality issues, particularly on FTTN connections, require the RSP to investigate rather than anything you can resolve through QoS tuning.

SIP ALG is interfering with VoIP signalling. Many consumer and some business routers include a feature called SIP ALG (Application Layer Gateway) that is designed to help VoIP traffic traverse NAT but frequently introduces problems with modern hosted VoIP systems. If your VoIP system exhibits one-way audio, calls dropping after a defined time (typically 30 seconds), or registration failures, disable SIP ALG on your router and test again.

A Real-World Example: QoS Deployment for a Sydney Professional Services Firm

A professional services firm in Sydney with 45 staff engaged CodeHyper after their switch from a legacy on-premise PBX to a cloud-hosted VoIP system. The firm’s NBN 250/25 connection had more than adequate bandwidth for their 12-person peak concurrent call estimate, but within a week of going live, complaints about choppy calls, dropped words, and occasional disconnections were common across the office.

The investigation revealed three compounding problems. First, the existing Ubiquiti UniFi router had QoS configured but the bandwidth limit was set to the full contracted plan speed of 25 Mbps upload rather than the recommended 85 per cent threshold. During periods when background cloud backups were running – typically mid-morning – upload bandwidth briefly exceeded 21 Mbps, causing the QoS queues to fail and voice traffic to compete with backup traffic on equal terms.

Second, two unmanaged switches that had been retained from the old network were sitting between the managed UniFi switches and a wing of the office housing the accounting team. These unmanaged switches do not support DSCP – all traffic arriving with DSCP markings was silently stripped and passed as best-effort. Every call originating from the accounting team’s VoIP phones was arriving at the router without priority markings.

Third, SIP ALG was enabled on the router, causing intermittent SIP signalling corruption on calls that traversed NAT. This was responsible for the calls that dropped after exactly 30 seconds – a classic SIP ALG symptom.

The remediation was straightforward: QoS bandwidth limits adjusted to 85 per cent of plan speed, the two unmanaged switches replaced with managed switches configured with DSCP trust, SIP ALG disabled. Call quality complaints dropped to zero within 48 hours.

If your business has deployed VoIP and is experiencing persistent call quality problems despite apparent QoS configuration, contact our team for a network quality assessment.

QoS Configuration Checklist

Use this before signing off on a VoIP or Microsoft Teams network deployment.

Preparation:

• Total available bandwidth documented (upload and download separately)
• Peak concurrent call count estimated and bandwidth requirement calculated
• All network devices in the path identified (router, switches, access points, firewall)
• Managed switches confirmed on all voice traffic paths – no unmanaged switches in the voice path
• Business-grade access points with verified WMM support confirmed for WiFi VoIP

Router / firewall:

• QoS enabled on WAN interface
• Bandwidth limit set to 85 per cent of contracted plan speed
• VoIP traffic class created, matching SIP (5060–5061 UDP) and RTP (provider-specific UDP range)
• Microsoft Teams audio class created, matching UDP 50000–50019
• DSCP marking enabled: DSCP 46 for RTP/Teams audio, DSCP 26 for SIP, DSCP 34 for Teams video
• Minimum guaranteed bandwidth reserved for voice traffic class
• SIP ALG disabled

Switches:

• DSCP trust mode enabled on access ports connected to VoIP phones and servers
• DSCP trust mode enabled on uplink/trunk ports
• Voice VLAN configured on ports serving IP phones (where applicable)
• QoS queue mapping verified: DSCP 46 → highest priority queue

WiFi:

• WMM enabled on all access points serving VoIP clients
• DSCP-to-WMM mapping confirmed (DSCP 46 → AC_VO)
• DSCP preservation confirmed across wired-to-wireless boundary
• Band steering configured to guide VoIP clients to 5 GHz

Microsoft Teams (if applicable):

• Teams QoS Group Policy configured on all Windows endpoints
• Port ranges configured in Teams Admin Centre
• DSCP values confirmed: 46 audio, 34 video, 18 sharing
• Configuration verified with Get-NetQosPolicy on test endpoints

Verification:

• Packet capture confirmed: DSCP 46 present in RTP packet headers
• Test call metrics reviewed: latency < 150 ms, jitter < 30 ms, packet loss < 1%
• Microsoft CQD reviewed (Teams): no persistent poor-quality streams
• Peak load test performed: call quality under simulated concurrent call load verified

Related Reading

These CodeHyper resources cover the VoIP and network infrastructure topics that work alongside QoS configuration:

• What Is VoIP Technology – A foundational explanation of how VoIP works and why it requires specific network treatment
• Why Business VoIP Provider Saves More Than Money – The business case for moving to cloud-based VoIP
• Hosted PBX – CodeHyper’s hosted PBX service for Australian businesses
• VoIP Number Australia – How Australian VoIP numbers work with hosted phone systems
• Business Internet – NBN and dedicated fibre options for VoIP-intensive business environments
• DNS and SSL – Supporting network services for VoIP infrastructure
• Network Security – Securing VoIP infrastructure alongside QoS configuration
• IT Infrastructure Optimisation – Broader network and infrastructure performance guidance

Frequently Asked Questions

What is QoS configuration and why does VoIP need it?

QoS (Quality of Service) configuration is the process of setting up your network equipment to treat different types of traffic with different levels of priority. VoIP needs it because voice calls are real-time applications – voice packets that arrive late or out of order cannot be replayed and are simply discarded, resulting in choppy audio, dropped words, or call disconnections. Unlike file downloads or video streaming, where a brief delay is imperceptible, voice communication requires consistent, low-latency packet delivery. QoS ensures voice packets are processed before less time-sensitive traffic, even when the network is busy.

What DSCP value should I use for VoIP traffic?

RTP voice media packets should be marked with DSCP 46, which corresponds to the Expedited Forwarding (EF) per-hop behaviour – the highest priority classification in the DSCP standard, reserved for real-time traffic that cannot tolerate delay. SIP signalling traffic should be marked with DSCP 26 (AF31). For Microsoft Teams specifically, Microsoft recommends DSCP 46 for audio, DSCP 34 (AF41) for video, and DSCP 18 (AF21) for application sharing. These values should be consistent across all devices in the network path – router, switches, and access points – for end-to-end prioritisation to function correctly.

What ports does VoIP use for QoS classification?

Standard SIP signalling uses UDP/TCP ports 5060 (unencrypted) and 5061 (encrypted / TLS). RTP voice media uses UDP in a dynamic port range – commonly 10000 to 20000, though this varies by VoIP provider and PBX configuration. Always confirm the exact RTP port range with your VoIP provider, as using incorrect port ranges in your QoS classification rules means voice traffic will not be identified and prioritised correctly. For Microsoft Teams, the recommended port ranges are UDP 50000–50019 for audio, 50020–50039 for video, and 50040–50059 for application sharing.

Does QoS work on NBN connections in Australia?

QoS configuration on your local network equipment always improves traffic prioritisation within your site. Whether those QoS markings are honoured by your NBN retail service provider varies by provider and plan type. Business NBN plans from reputable providers are more likely to preserve DSCP markings and apply traffic management policies that favour voice traffic. However, the most reliable improvement from QoS comes from correct configuration at your router and switches – controlling how traffic competes for your NBN connection’s upload bandwidth – rather than from end-to-end DSCP preservation across the NBN network itself.

What is the difference between DSCP and CoS for QoS?

DSCP (Differentiated Services Code Point) operates at Layer 3 – it is a value written into the IP header of each packet and is used by routers and Layer 3 switches to make prioritisation decisions. CoS (Class of Service, also called 802.1p) operates at Layer 2 – it is a 3-bit priority value in the Ethernet frame’s VLAN tag, used by Layer 2 switches on LAN segments. In a typical business network, IP phones mark their traffic with both DSCP and CoS values. Switches use CoS for within-LAN prioritisation; routers use DSCP for WAN-level prioritisation. When traffic crosses a router, the Layer 2 frame header is discarded and a new one is created – DSCP in the IP header persists across this boundary, while CoS does not.

What is SIP ALG and should I disable it?

SIP ALG (Application Layer Gateway) is a feature on many routers that intercepts SIP signalling packets and modifies them to help VoIP traffic traverse NAT. In theory, it helps; in practice, SIP ALG implementations on most consumer and many business routers are poorly designed and interfere with modern hosted VoIP systems, causing symptoms including one-way audio, registration failures, and calls dropping after exactly 30 seconds. The universal recommendation from VoIP engineers is to disable SIP ALG on your router. Modern hosted VoIP and SIP trunk providers handle NAT traversal themselves through techniques including STUN, TURN, and ICE – SIP ALG interference actively breaks these mechanisms.

How much bandwidth does each VoIP call use?

A VoIP call using the G.711 codec (the standard codec used by most SIP trunks and equivalent to traditional PSTN quality) uses approximately 64 to 87 Kbps per call per direction. For planning purposes, use 100 Kbps per call per direction as a conservative estimate that accounts for headers and overhead. Microsoft Teams audio using the Opus codec uses variable bandwidth depending on network conditions, typically 20 to 100 Kbps per call. Plan your NBN connection to accommodate your peak concurrent call volume plus all other traffic, and use QoS to ensure voice traffic always has access to the bandwidth it requires.

Why does my VoIP quality only become a problem during certain times of day?

VoIP quality that is acceptable most of the time but degrades during specific periods – mid-morning, lunchtime, end of day – is a classic symptom of bandwidth contention. Something is consuming a significant portion of your available bandwidth at those times, leaving insufficient headroom for voice traffic even with QoS configured. Common causes include cloud backup jobs running on a schedule, large file sync activity (OneDrive, SharePoint, Dropbox), Windows Update downloads, or staff streaming video during breaks. Use your router’s traffic monitoring or a network monitoring tool to identify what is consuming bandwidth during problem periods. Once identified, schedule bandwidth-intensive tasks for off-hours and ensure QoS rules correctly de-prioritise those traffic types relative to voice.