DrayTek documents SIP ALG as disabled by default on current supported configurations. First prove whether it is active; where the model exposes NAT > ALG, leave SIP ALG disabled, then clear only the affected sessions or restart the test endpoint and retest.
Confirm SIP ALG is actually involved
SIP ALG inspects and can rewrite SIP/SDP traffic. That rewriting can conflict with modern PBX NAT handling, TLS and encrypted media, but changing it will not fix bad credentials, a missing DDI route or unrelated packet loss.
- Record the router model, firmware, WAN type, PBX/phone address and current VoIP symptoms.
- Export the DrayTek configuration and arrange a short change window.
- Check whether another upstream modem or firewall is also performing NAT or SIP inspection.
- Capture a baseline registration and inbound/outbound test result before changing anything.
Verify or disable the DrayTek SIP ALG
- 1Sign in from the trusted LAN
Open the DrayTek management interface using its trusted management address. Do not enable WAN administration for this change.
- 2Open the ALG settings
On models and firmware that expose it, open NAT > ALG and locate SIP ALG. DrayTek states that SIP ALG is disabled by default, so record the existing state before editing.
- 3Leave SIP ALG disabled
If enabled, clear/disable SIP ALG and apply the change. Do not disable the stateful firewall, NAT or unrelated application controls.
- 4Use model-specific instructions where no toggle exists
Older firmware and some product families use different menus or CLI commands. Consult the exact DrayTek model guide or support article rather than pasting an unverified command.
- 5Renew only the affected traffic
Restart the SIP registration or endpoint, or clear only its affected states using the model-supported process. Avoid rebooting a production router unless planned.
Keep source allowlists, outbound policy, management restrictions and default-deny rules. SIP ALG is protocol rewriting, not the security boundary.
Review DrayTek NAT without adding broad forwards
Registered SIP devices normally originate their own sessions. Avoid forwarding UDP/5060 or placing a PBX/phone in DMZ merely to make a test work. For direct-IP delivery, allow only the UKDDI signalling/media sources and ranges issued for the account.
| Check | Safe outcome |
|---|---|
| Double NAT | Bridge or deliberately route the upstream device; know which firewall owns the public address |
| Port forwards | Only service-required, source-restricted rules; none for an ordinary direct handset registration |
| Session timeout | Long enough for the negotiated registration/keepalive design without opening permanent unsolicited access |
| QoS | Prioritises voice under congestion without masking packet loss or starving other critical traffic |
Test after changing the ALG state
- 1Confirm stable registration
Watch the account remain registered over more than one refresh interval.
- 2Test both call directions
Call in and out using numbers you control and confirm the approved caller ID.
- 3Check media and call features
Verify two-way speech, keypad tones, hold, transfer and a call longer than five minutes.
- 4Compare the evidence
If the symptom is unchanged, restore the recorded state if appropriate and investigate SIP response, DDI matching, DNS, TLS, RTP and upstream NAT rather than weakening rules.