VoIP traffic is light on bandwidth — roughly 80–88 Kbps per call — but extremely sensitive to latency, jitter, and packet loss. Even a short delay can lead to echo, choppy audio, or dropped calls.
A correct draytek voip qos configuration ensures your voice packets always get top priority, even when your network is under heavy load.
This guide walks you through a draytek qos setup for VoIP on all DrayTek Vigor models, from home routers to enterprise-grade devices. We’ll cover quick methods, advanced class-based setups, firmware variations, and troubleshooting tips.
DrayTek routers manage bandwidth using Quality of Service (QoS).
For VoIP, there are two main options:
Before starting your draytek qos setup, make sure you have:
192.168.1.1)
Log into your DrayTek router at 192.168.1.1 to begin the QoS configuration process.
Enable QoS for the WAN interface carrying VoIP traffic, then set accurate inbound/outbound bandwidth values.
Steps:
💡 Tip: Incorrect speeds will break QoS effectiveness.
Enable “First Priority for VoIP” to automatically reserve bandwidth for SIP and RTP traffic.
Steps:
How it works:
Use App QoS to assign VoIP traffic to a high-priority class for more granular control.
CLI Commands (Telnet/SSH):
qos setup -I [value] # Min download bandwidth for non-VoIP traffic
qos setup -O [value] # Min upload bandwidth for non-VoIP traffic
qos setup -v 1 # Apply limits immediately when VoIP detected
DSCP Tagging:
If your phones mark packets with DSCP EF (46), enable DSCP-based QoS to automatically prioritise them.
VLAN Segregation:
Place VoIP devices on their own VLAN and apply per-VLAN QoS rules.
If calls are still choppy:
If rules don’t match traffic:
Whether you choose the quick First Priority option or a custom class-based draytek qos setup, these steps will ensure your draytek voip qos configuration delivers crystal clear calls under any network load.
DrayTek VoIP QoS is a Quality of Service configuration that prioritises SIP and RTP voice traffic on your network, ensuring clear and stable calls even when other devices are using bandwidth heavily.
To set up VoIP QoS on a DrayTek router, log in to the web interface, enable QoS for the WAN interface, set accurate bandwidth values, and either enable “First Priority for VoIP” or configure class-based rules for SIP and RTP traffic.
First Priority for VoIP is faster to set up and works well for most home and small office setups. Class-based QoS offers more control, letting you prioritise multiple traffic types alongside VoIP.
Most VoIP providers use SIP on UDP port 5060 and RTP on UDP ports 16384–32767. Always confirm the exact ports with your provider before setting up QoS rules.
Yes. Once enabled, your DrayTek QoS setup will manage traffic for all devices on the network, prioritising VoIP packets while controlling lower-priority traffic during congestion.
If you’re having call issues it may also be NAT issues such as SIP ALG issues or because you haven’t enabled rport.
If you’ve ever experienced choppy VoIP calls, conversations where the other person can’t hear you, or the dreaded “dead silence” when you answer the phone, there’s a good chance you’ve run into one of the most common yet least obvious culprits: SIP ALG. This router feature, often buried deep in the settings, can cause symptoms like calls cutting off mid-sentence, no inbound calls ringing through, or frustrating one-way audio issues.
The problem? Many routers ship with SIP ALG enabled by default. While it was designed to help with VoIP call setup and NAT traversal, in practice it often rewrites data in a way that breaks more than it fixes. Most VoIP providers recommend disabling SIP ALG for a smoother, more reliable calling experience.
Think of it as a “helpful” friend who keeps rewriting your letters before they get sent—sometimes they improve the message, but more often they just make it unreadable.
Plain English:
SIP ALG stands for Session Initiation Protocol Application Layer Gateway. It’s a router feature designed to help VoIP calls work behind firewalls and NAT (Network Address Translation) by inspecting and altering SIP packets as they pass through. In theory, it’s supposed to make sure your phone system can connect smoothly to the internet by “fixing” the addressing inside those packets.
Technical:
SIP ALG operates at the application layer, intercepting SIP signalling traffic, rewriting packet headers, and modifying the SDP (Session Description Protocol) payload. The intention is to solve NAT traversal problems by ensuring that private IP addresses inside SIP messages are replaced with the public IP of the router. Unfortunately, in many implementations, this process is buggy or overly aggressive, leading to broken call setup, missing audio streams, and dropped connections.
It’s worth noting that there are alternative, cleaner ways to handle NAT traversal without rewriting SIP headers at all. For example, rport ensures NAT reply routing is maintained while leaving the original SIP message intact—avoiding many of the problems caused by SIP ALG.
SIP ALG wasn’t invented to make life harder for VoIP users—it was originally designed to solve very real networking challenges. In certain environments, especially those with symmetrical NAT or with SIP servers that lack built-in NAT traversal mechanisms, VoIP traffic can fail outright without some form of packet modification.
By intercepting SIP signalling and rewriting the addresses inside, SIP ALG can, in theory, help phones and PBXs register successfully, even when they’re sitting behind tight corporate firewalls or in networks where the router is the only device aware of the public IP. In some rare edge cases—such as legacy SIP servers that aren’t NAT-aware—it can be the difference between a working call and no call at all.
These scenarios are increasingly uncommon thanks to modern SIP servers and features like STUN, ICE, and rport, but they do still exist. Knowing when SIP ALG helps—and when it hurts—separates network troubleshooting guesswork from informed, precise fixes.
While SIP ALG is meant to help, in practice it often causes more problems than it solves. Here are the most common ways it disrupts calls:
SIP ALG is just one approach to solving NAT traversal issues—but it’s also the most invasive, since it rewrites packet data in-flight. Modern VoIP environments typically use less disruptive, standards-based methods. Here’s how they compare:
Why These Alternatives Work Better
Where SIP ALG modifies SIP messages on the fly—risking broken headers and mangled media paths—tools like rport, STUN, and TURN operate within established SIP and RTP standards. They focus on ensuring packets reach their destination without altering the original signalling content.
For example, rport is specifically designed to fix reply routing issues by letting the server send responses to the correct external port, all without rewriting your SIP headers. STUN and keep-alives help devices maintain accurate connection details, while TURN and outbound proxies handle more restrictive environments by providing controlled relay points.
Together, these techniques provide reliable NAT traversal without the unpredictable side effects that make SIP ALG infamous in VoIP troubleshooting.
For most modern VoIP setups, the safest and most reliable configuration is to turn off SIP ALG and enable standards-based NAT traversal tools instead. Here’s the checklist we recommend:
If you use Plexatalk preconfigured phones or adapters, SIP ALG is already off and NAT-friendly settings like rport, STUN, and keep-alives are enabled by default—no manual tweaks needed. That means you can skip the guesswork and get straight to clear, reliable calls. This being said… your router may have SIP ALG turned on.
Disabling SIP ALG varies by router brand. Use the links below to jump directly to your model’s instructions:
Netgear | TP-Link | Asus | DrayTek | Mikrotik | BT Hub | Virgin Hub | Others
192.168.0.1 or 192.168.1.1).192.168.0.1).192.168.1.1).Some routers don’t expose a toggle for SIP ALG, or their “off” setting still interferes with VoIP. If you can’t disable it, try these proven workarounds:
Good to know: Plexatalk supplies VoIP-friendly routers and adapters preconfigured — SIP ALG is off and NAT-safe settings (rport, STUN/keep-alives, outbound proxy) are enabled, so you don’t need to tweak anything.
Although SIP ALG was never designed as a security feature, its packet inspection and modification can have knock-on effects for network security — both positive and negative.
Potential Benefits
Security Risks
The takeaway? SIP ALG is not a replacement for VoIP security best practices. Proper security comes from TLS/SRTP encryption, strong authentication, and well-configured firewalls. If anything, disabling SIP ALG and relying on standards-compliant NAT traversal tools gives you a more predictable, auditable security posture.
Case 1 – The Legacy PBX in a Corporate LAN
A manufacturing company still ran an early-2000s SIP-based PBX that had no NAT awareness. With symmetrical NAT in place, calls simply failed without ALG rewriting headers. In this scenario, enabling SIP ALG restored basic call functionality — though long-term, replacing the PBX was the real fix.
Case 2 – The Modern Hosted VoIP Deployment
A marketing agency moved to a cloud VoIP service with rport, STUN, and keep-alives already enabled by the provider. SIP ALG was left on in their Netgear router, resulting in intermittent one-way audio and dropped calls. Disabling ALG fixed the issue immediately — no other changes needed.
Case 3 – The ISP-Locked Router
A small business using an ISP-supplied hub found SIP ALG could not be disabled. Outbound calls worked, but inbound calls often went straight to voicemail. Switching the hub to modem mode and adding a VoIP-friendly router with ALG disabled resolved the problem and improved call quality.
These examples underline the rule of thumb: ALG can help in very specific, usually outdated setups, but it’s far more likely to interfere in modern VoIP environments.
No. Many consumer and ISP-supplied routers include SIP ALG (often enabled by default), but not all do, and implementations vary widely between brands and firmware versions.
Generally, no. Disabling SIP ALG simply stops the router from rewriting SIP/SDP messages. Other services are unaffected. If your network relied on ALG to work around strict NAT, you can use rport, STUN, keep-alives, or your VoIP provider’s outbound proxy instead.
No. SIP ALG actively modifies SIP traffic, whereas SIP passthrough usually means the router allows SIP traffic to pass untouched or opens related ports. Some vendors confuse the terminology, so check whether the feature rewrites headers—if it does, it’s effectively ALG.
Sometimes. Some ISP routers allow support staff to disable ALG remotely or enable modem/bridge mode. Others don’t offer this option at all. If they can’t switch it off, use your own VoIP-friendly router in place of—or in addition to—the ISP’s equipment.
It can affect both. SIP controls call setup for voice and video, and RTP carries the media streams. SIP ALG header or SDP rewriting can cause one-way audio, frozen video, or failed call setup for either media type.
It was originally intended to help older SIP systems that couldn’t handle NAT traversal on their own. Many manufacturers still enable it by default for “compatibility,” even though modern VoIP setups work better without it.
Typical symptoms include one-way audio, calls dropping after a fixed time, missed inbound calls, and registration failures. You can confirm by disabling SIP ALG temporarily and testing call quality—or by using a packet capture to see if headers are being rewritten.
Using rport, STUN, keep-alives, or your provider’s outbound proxy. These methods comply with SIP standards and maintain NAT traversal without altering SIP signalling content.
No. Some routers (especially ISP-branded ones) don’t provide a SIP ALG toggle. In those cases, you can use modem/bridge mode, replace the router, or use workarounds like TLS encryption for signalling.
No. SIP ALG is not a security feature—it’s a NAT traversal helper. It doesn’t encrypt calls or protect against attacks; in fact, it can reduce reliability by modifying packets unexpectedly.
SIP ALG was created to solve older networking problems, but in today’s VoIP environments it’s more often a source of dropped calls, one-way audio, and frustrating troubleshooting sessions. While it can help in rare edge cases, most modern systems work best when SIP ALG is disabled and standards-based NAT traversal tools take its place.
With Plexatalk, you can skip the headaches. We supply preconfigured, tested hardware with SIP ALG disabled and NAT-safe settings enabled, including rport, STUN, keep-alives, and outbound proxy support. That means your VoIP setup works reliably right out of the box — even on tricky networks.
Contact us if you want a VoIP solution that works from day one, without the trial-and-error.
If you’ve ever set up VoIP and run into problems where:
…then you’ve likely encountered a NAT traversal issue.
NAT (Network Address Translation) is what most home and office routers use to let multiple devices share one public IPv4 address. It’s great for security and address conservation, but it changes packet headers in ways that can confuse SIP — the protocol VoIP uses to set up calls.
When SIP gets confused, call signalling packets can vanish, incoming calls fail to arrive, and audio streams may get lost.
That’s where the rport parameter comes in. Defined in RFC 3581, it’s a small change in SIP behaviour that can make the difference between unreliable and rock-solid VoIP.
At Plexatalk, most customers never need to think about rport. We preconfigure the phones and VoIP adapters we supply so they’re ready for NAT handling from the moment you plug them in. But if you’re bringing your own device, using a third-party softphone, or troubleshooting another provider’s service, understanding rport can save you hours of frustration.
In plain English:
rporttells a SIP server to send responses back to the IP address and port that your request actually came from — not the ones written in your SIP headers.
This matters because behind NAT, your device’s internal IP and port (e.g., 192.168.1.50:5060) are not reachable from the internet. Your provider needs to send packets to your router’s public IP and the actual source port NAT assigned (e.g., 81.2.3.4:32415).
Without rport, the server may try to send packets to your private address — and those packets never make it back.
RFC 3581 definition (simplified):
The
rportparameter requests that the server send the response back to the source IP address and port from which the request originated.
Example of rport in a SIP Via header:
Without rport:
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-123456
With rport:
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-123456;rport
When you’re on a public IP:
Via: header.Everything works fine because the address in the header is valid.
Behind NAT:
192.168.1.50:5060.81.2.3.4:32415).81.2.3.4:32415 but still reads 192.168.1.50:5060 in the Via: header.If the server replies to 192.168.1.50:5060, the packet never arrives — NAT doesn’t know where to send it.
With rport:
;rport (empty) to its Via: header.32415).That means the NAT device can forward the packet back to your phone.
RFC 3581 introduced Symmetric Response Routing for SIP over UDP.
rport present but empty.rport parameter with the observed port.In a chain of SIP proxies:
received= parameter (observed IP) to the Via: header.rport is present, it also appends the observed port.Before processing:
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-111111;rport
After proxy sees packet from 81.2.3.4:32415:
Via: SIP/2.0/UDP 192.168.1.50:5060;branch=z9hG4bK-111111;received=81.2.3.4;rport=32415
rport is not a cure-all. It:
Does not replace the need for an outbound proxy in some complex topologies.
Does not solve RTP (media) traversal — you still need STUN, TURN, ICE, or symmetric RTP.
Does not keep NAT bindings open — use SIP keep-alives or periodic REGISTERs for that.
If you’re using Plexatalk-supplied hardware (ATAs, IP phones), rport is already set.
If you bring your own device or app, your VoIP provider or even us depending on config – might recommend enabling rport if you:
Without rport:
Via: 192.168.1.50:5060.81.2.3.4:32415.192.168.1.50:5060 — lost.With rport:
Via: 192.168.1.50:5060;rport.81.2.3.4:32415.rport=32415, replies to 81.2.3.4:32415 — delivered.Plexatalk ships VoIP devices pre-tuned for UK ISPs and NAT environments. That includes:
You plug in, it works.
If you bring your own hardware, we’ll guide you — but preconfigured gear removes guesswork.
rport is a SIP parameter defined in RFC 3581 that tells a VoIP server to send responses to the IP address and port where your request actually came from, instead of relying on the internal IP and port in your SIP headers. It helps SIP signalling work correctly when your device is behind NAT.
Without rport, SIP servers may send call signalling to your device’s private IP address, which can’t be reached from the internet. This can cause missed calls, one-way audio, or dropped registrations. rport ensures replies go to your real public IP and NAT-mapped port.
Not directly. rport only affects SIP signalling (call setup messages), not the RTP media stream that carries voice. For audio issues, you may also need to configure STUN, TURN, ICE, or symmetric RTP.
In most cases, yes — it’s safe and can improve reliability. If you’re a Plexatalk customer using our supplied phones or VoIP adapters, rport is already enabled. If you’re using your own device or softphone, you may need to turn it on in the SIP settings.
No. rport is a low-risk setting that usually improves NAT compatibility. Disabling it is more likely to cause issues than enabling it.
No. rport is complementary to other NAT traversal tools. STUN helps discover your public IP/port mapping, while keep-alives maintain NAT bindings. For best reliability, use them together.
Your provider may ask for rport if you’re experiencing inbound call issues, using mobile broadband, behind double NAT, or moving between Wi-Fi and mobile networks.
Not if you use our preconfigured hardware — it’s already set. If you bring your own device, we’ll guide you through enabling rport along with other recommended NAT-friendly settings.