C cenaly.com
Start free

Network, router and internet for telephony

Ports, SIP ALG and where to turn it off on popular routers, NAT, Wi-Fi and VLANs, how much bandwidth a call needs

21 min read Open this screen in the demo
On this page 18

Network, router and internet for telephony

An IP phone is a device on the venue network just like the till or a computer: it goes out to the internet through your router to our PBX. It almost always “just works”, and when it does not, the culprit is three or four router settings that are the same across brands. This page covers exactly what the network needs, where to turn off the troublesome SIP ALG “helper” on popular routers and how much internet a call needs.

What to enter in the phone itself (server, username, password) is in the overview “SIP Phone Setup”. To check audio after any network change, use the *43 echo test (see “How to check the network”).

Short version: five rules#

  1. No port forwarding is needed. The phone connects to the PBX from inside your network — there are never incoming connections from outside.
  2. Turn off SIP ALG on the router (also called “SIP Helper”, “SIP Passthrough”). It is the most common cause of “the call drops after 30 seconds” and “they can't hear me” — where to find it on your brand.
  3. Phones go on the staff network, preferably by cable. Not on guest Wi-Fi: devices there are isolated from each other, and there is often a login page the phone cannot pass.
  4. You need little internet, but stable: about 100 kbit/s each way per conversation. What matters is not speed but that the link does not hit its ceiling — especially the upload.
  5. After any network work, dial *43. The green dot in the admin panel tells you about registration, not audio.

How a call travels through the network#

 IP phone ──► venue router ──► internet ──► Cenaly PBX
 (192.168.x.x)  (NAT: swaps the     provider    sip.<your domain>
                 address for the                or a dedicated machine
                 external one)

All traffic is started by the phone:

  1. The phone sends the PBX a registration (port 5060). The router remembers: “packets arriving at this external port are for phone 192.168.x.x” — this is network address translation (NAT).
  2. The PBX replies and later sends incoming calls to the same place the registration came from — through the same “hole” in the router. That is why no port forwarding is needed: the phone opened the door itself.
  3. The phone also starts sending voice (RTP) itself, and the PBX sends voice back to the address and port it arrives from.

Hence two conditions without which calls break: the router must not rewrite the contents of SIP packets (that is what SIP ALG does) and must not forget the “hole” while the phone is silent between calls (that is what keep-alive is for). Both are covered below.

For the network administrator: what the PBX does about NAT itself

For every extension the PBX has these enabled (shared/sip/advanced-options.json, group nat):

  • force_rport — replies go to the address and port the request came from (RFC 3581), not to the one written in the Via header;
  • rewrite_contact — the PBX remembers the phone by the real external source address of the registration, not by the private 192.168.x.x address in the Contact header;
  • rtp_symmetric — voice is sent to where the phone's voice comes from (symmetric RTP), not to the address in the SDP;
  • direct_media=no — voice always passes through the PBX, even between two phones of the same venue; phones never try to connect to each other directly.

That is why the phone does not need STUN, TURN or ICE, and the venue does not need a static external IP. A phone may request registration for 60–3600 s (less than 60 is rejected with 423 Interval Too Brief, 120 s by default); the PBX checks every registered device with an OPTIONS request every 60 s.

Ports for the network administrator#

There is one rule: allow outbound traffic to the PBX address and the replies to it (an ordinary stateful firewall does this by itself). No inbound rules or port forwarding are needed.

What Protocol and port on the PBX side Direction from the venue
Registration and calls (SIP) UDP 5060; TCP 5060 — if the phone is switched to TCP outbound to the PBX address
Voice (RTP) UDP 10000–20000 (the shared PBX uses 10000–10200, a dedicated machine the whole 10000–20000 range) outbound to the PBX address
Names (DNS) UDP/TCP 53 to your ISP's or your own DNS server
Time (NTP) UDP 123 to time servers — otherwise call history shows the wrong time

The PBX address is a name, not an IP: it is shown in the “Extension credentials” window (sip.<your domain> for the shared PBX or the name of your dedicated machine). Do not put an IP “from memory” into the rules and do not look for it on this page — it is deliberately not here.

Firewall details
  • The phone's local ports (which port it sends SIP and RTP from) differ between brands — there is no need to filter outbound traffic by source port; filter by destination address and port.
  • Two ports per conversation on the PBX side: RTP takes an even port, RTCP (quality reports) the next odd one. This is the PBX's internal business, but it explains why the range is wide.
  • If the firewall needs an IP address, resolve it from the name (nslookup <SIP server>). A dedicated machine has a static IP; for the shared PBX it is more reliable to allow by name or all outbound UDP to it.
  • TCP 5061 (SIP over TLS) is open on a dedicated machine for encrypted signalling. A phone needs it only if the transport in the credentials window is TLS; by default it is UDP.
  • There is no audio encryption (SRTP) — if a “VoIP inspection” on the firewall requires SRTP, turn it off for the PBX address.

SIP ALG — turn it off on the router#

What it is. SIP ALG (Application Layer Gateway; called “SIP Helper”, “SIP Passthrough” or “ALG for SIP” by different brands) is a router function that “helps” telephony: it looks inside SIP packets and rewrites the addresses in them. It was invented for old phones that could not cope with NAT. Our PBX does this itself (see the block above), and the router's “help” only gets in the way.

How it breaks things. It often rewrites incorrectly or only half of the packets. Typical signs:

  • the call drops after ~30 seconds from answering — the acknowledgement of the answer (ACK) went to the wrong place, and one side hangs up on a timer;
  • only one side is heard or there is no audio at all — the address in the description of the voice stream has been replaced;
  • the phone registers on and off, incoming calls arrive every other time.

The mechanics of these faults are explained in “Calls drop” and “No audio, one-way audio”. Here — where to turn it off.

Brand Where to turn it off Factory default
Keenetic (and Netcraze) General System Settings → Component options → untick “Application-layer gateway (ALG) for SIP” → Update KeeneticOS. On Keenetic SIP ALG is not a checkbox but a separate system component: you remove it. The router needs internet access, will update the system to the latest version and restart by itself — do it at a quiet time not stated in the docs
MikroTik (RouterOS) the NAT helpers menu /ip firewall service-port → the sip entry → disable: /ip firewall service-port disable sip not stated in the docs
TP-Link Archer (Wi-Fi 6) Advanced → Security → ALG → turn SIP ALG off not stated in the docs
TP-Link xDSL and LTE modems (Archer VR/VX/MR, TD-W) Advanced → NAT Forwarding → ALG → turn SIP ALG off not stated in the docs
TP-Link Deco Deco app → More → Advanced → NAT Forwarding → SIP ALG → turn off not stated in the docs
D-Link DIR (Russian firmware) Дополнительно → ALG/Passthrough (Advanced → ALG/Passthrough) → slide the SIP switch to the left → Применить (Apply) not stated in the docs
D-Link DIR (English firmware) Advanced → Firewall → Advanced Settings… → SIP → turn off not stated in the docs
Zyxel VMG/XMG (ISP modems) Network Setting → NAT → ALG → turn SIP ALG off not stated in the docs
ASUS WAN → NAT Passthrough → SIP Passthrough → Disable → Apply (on ASUS SIP ALG is called SIP Passthrough ⚠️ verify) enabled
NETGEAR (Nighthawk, Orbi RBR50/40/20) ADVANCED → Setup → WAN Setup → tick Disable SIP ALG → Apply enabled
DrayTek Vigor NAT → ALG → untick Enable SIP/RTSP ALG (firmware 3.8.5 and later); in the console — sys sip_alg 0 disabled
AVM FRITZ!Box AVM's documentation has no separate SIP ALG switch. But for an external PBX you need to remove a protection: Telefonie → Eigene Rufnummern → Anschlusseinstellungen → untick “Nutzung von Internettelefonie aus dem Heimnetz unterbinden” (block internet telephony from the home network) — otherwise the FRITZ!Box will not let phones reach our PBX —
Ubiquiti UniFi (Cloud Gateway) nothing to do: per Ubiquiti's documentation UniFi gateways do not apply SIP ALG. Check the ISP router in front of it no ALG
Tenda Tenda's home Wi-Fi router guides have no SIP ALG item. On Tenda DSL modems: Advance → Services → ALG → untick SIP —
Huawei, ZTE (ISP fibre terminals: HG8245H, HG8145V, F660, F670L…) no path in the manufacturer's public documentation; the menu is usually cut down by the ISP — ask your ISP —
Sagemcom, Technicolor, AirTies (ISP boxes) no such item in the manufacturer's documentation — ask your ISP —
Xiaomi / Redmi no such item in the manufacturer's documentation — check with *43 and a call longer than a minute —

“Factory default: not stated in the docs” means the manufacturer does not say whether ALG is on out of the box — log in and look. The paths are taken from the manufacturers' official manuals (listed in “Sources”); in other firmware the item names may differ slightly.

For the network administrator: business gateways
  • TP-Link Omada (gateway with its own web interface): Transmission → NAT → ALG — untick SIP.
  • Zyxel ATP/USG (ZLD): Configuration → Network → ALG — untick Enable SIP ALG (and Enable SIP Transformations).
  • Fortinet FortiGate: out of the box SIP is handled by the ALG (default-voip-alg-mode proxy-based) and the sip session helper (usually no. 13) is enabled. It can only be turned off in the console: config system session-helper → delete 13 → end; then config system settings → set default-voip-alg-mode kernel-helper-based → end; the policy must have no VoIP profile. Check with diagnose sys session list | grep sip.
  • MikroTik: the SIP service-port entry has the parameters sip-direct-media (yes by default) and sip-timeout (1 hour) — they do not apply once the helper is disabled.
  • OpenWrt: the SIP helper lives in the kmod-nf-nathelper-extra package; no package — no ALG. Per-zone helpers are enabled by the firewall's auto_helper option.

If the router belongs to your ISP (a fibre terminal, a “box” from the internet provider) and you cannot see the item — the menu is usually cut down. Call the ISP and ask: “turn off SIP ALG on my router” or “switch the terminal to bridge mode” if your own router sits behind it.

After turning it off, restart the router and the phones (old NAT entries live until a restart or until their timer expires), then dial *43.

NAT, double NAT and keep-alive#

Keep-alive. The router remembers the phone's “hole” while something passes through it. If the phone is silent longer than the router's UDP timeout, the entry is deleted — and an incoming call no longer reaches the phone, although the admin panel still shows a green dot for a few minutes (“outgoing calls work, incoming don't”). On Linux-based routers (many home and ISP models run Linux) the default timeout is 30 seconds for one-way UDP flows and 120 seconds for flows with replies; on MikroTik — 30 seconds and 3 minutes.

Therefore:

  • in the phone turn on NAT keep-alive (also “NAT Keep-alive”, “Keep Alive Interval”, “UDP keep-alive”) with an interval of 15–30 seconds, if there is such an item;
  • or switch the phone to TCP — routers keep a TCP connection much longer (our PBX accepts TCP on the same port 5060);
  • the PBX on its side polls every phone every 60 seconds — this helps, but on a router with a 30-second timeout it is not enough on its own.

Double NAT is when your own router sits behind the ISP's router or fibre terminal and both do NAT. Our PBX sees only the outermost address and works anyway, but SIP ALG must be turned off on both devices, and the keep-alive must fit within the shorter of the two timeouts. The best option is to switch the ISP device to bridge mode so there is only one NAT.

Mobile internet and the ISP's “shared” IP (CGNAT) are the same double NAT, except the outer layer belongs to the operator and cannot be configured. It works, but keep-alive is especially important: operators' timeouts can be short.

For the network administrator: timeouts and checks
  • Linux routers (OpenWrt and the firmware of many home and ISP models): nf_conntrack_udp_timeout = 30 s, nf_conntrack_udp_timeout_stream = 120 s — Linux kernel documentation. MikroTik: /ip firewall connection tracking → udp-timeout = 30 s, udp-stream-timeout = 3 min. If phones have no keep-alive, raise the UDP timeout to 180 s.
  • Sign of a stale NAT entry: outgoing calls always work, incoming calls stop arriving after a few idle minutes and “come back to life” right after an outgoing call.
  • The path to the phone can be checked the other way round from the admin panel: device card → “Check” tab → “Call this phone” (see the overview, “Checking call quality”).

Cable, Wi-Fi, PoE, VLAN and QoS#

  • Cable is better than Wi-Fi. Connect desk phones by cable. Wi-Fi adds delay and loss, especially in a dining room where guests share the network; moving between access points may interrupt a call.
  • The guest network is not for phones. It usually has client isolation enabled (devices cannot see each other — the computer will not open the phone's web interface), and sometimes a login page (“captive portal”) the phone cannot pass.
  • For walking around the floor — DECT, not a Wi-Fi phone. DECT handsets use their own radio, do not depend on Wi-Fi and keep their charge longer.
  • PoE power. Most office phones are powered from the switch via PoE 802.3af — no separate power supply is needed. If the switch has no PoE, the power supply is often sold separately. Video phones and phones with expansion modules may need PoE+ (802.3at).
  • A softphone on a smartphone on Wi-Fi loses its registration when switching to mobile data — see “Softphones”.
For the network administrator: voice VLAN and QoS

VLAN. In a venue with a managed switch it is convenient to put phones into a separate voice VLAN: guest and staff traffic does not disturb voice, and phones are invisible to guests. The phone gets the VLAN ID manually (in its network settings), via LLDP-MED from the switch or via a DHCP option — see the page for your brand. A computer plugged into the phone's PC port stays on the regular network. VLAN changes nothing for the PBX: the phone still goes out through the router's NAT.

QoS. Voice needs not a fat link but priority in the upload queue: when someone uploads camera video or a cloud backup, voice packets wait in the same queue as the files — hence the “robot” voice and the delay. What you can do:

  • enable prioritisation on the router (QoS / SQM / Smart Queue / bandwidth control) and give top priority to the phones' IP addresses or the voice VLAN;
  • limit bandwidth for “heavy” devices (cameras, NAS) slightly below the real link speed — then the queue does not fill up;
  • phones usually mark voice with DSCP 46 (EF) and signalling with 24–26 (CS3/AF31) themselves; the router can prioritise by that mark. On the internet beyond your router DSCP marks are usually not honoured — so it is your own upload that is worth managing.

How much internet you need#

One conversation through our PBX takes about 87 kbit/s each way — the same for G.711 (A-law/µ-law) and G.722. With a margin, plan 100 kbit/s per conversation — for both download and upload.

Talking at the same time Needed for upload and download (each)
1 phone 0.1 Mbit/s
2 0.2 Mbit/s
4 0.4 Mbit/s
8 0.8 Mbit/s
10 1 Mbit/s
20 2 Mbit/s

Two points people trip over:

  • A conversation between two phones inside the venue is two streams over the internet, not zero: voice always passes through the PBX (each phone to the PBX and back). Count phones talking at the same time, not calls.
  • The bottleneck is the upload. On ADSL, mobile internet and many plans the upload speed is several times lower than download. If the upload is busy with cameras, cloud backup or video uploads, voice starts breaking up even when “the speed test looks good”.

Quality matters more than speed. A normal conversation needs:

Metric Good Audibly bad
Packet loss up to 1 % over 3 % — “bubbling”, syllables drop out
Jitter (delay variation) up to 30 ms over 50 ms — the audio breaks up
Round-trip delay up to 150 ms over 300 ms — people talk over each other

The PBX shows these same numbers for every *43 check in the call log.

Mobile internet. A conversation uses about 0.6 MB per minute each way, i.e. about 1.2 MB per minute in total, or about 72 MB per hour of talk.

How it is calculated

Our PBX's codecs — G.711 (PCMA/PCMU) and G.722 — both carry 64 kbit/s of audio. The phone sends a packet every 20 ms (ptime 20 ms, the standard for these codecs), i.e. 50 packets per second.

  • Packet payload: 64,000 bit/s × 0.02 s = 1,280 bits = 160 bytes.
  • Headers: RTP 12 + UDP 8 + IPv4 20 = 40 bytes → the IP-level packet is 200 bytes.
  • At the IP level: 200 bytes × 8 × 50 packets/s = 80 kbit/s.
  • On an Ethernet cable another 18 bytes of frame header are added: 218 bytes × 8 × 50 = 87.2 kbit/s — that is the “about 87”.
  • RTCP (quality reports every few seconds) adds a fraction of a kbit/s — negligible. PPPoE at the ISP adds 8 bytes per packet (+3.2 kbit/s).

Formula: bandwidth = (payload + headers) × 8 × (1000 / ptime); for G.711 and G.722 at 20 ms: (160 + 40 + 18) × 8 × 50 = 87,200 bit/s.

Traffic: 80 kbit/s (at the IP level, as a mobile operator counts it) = 10,000 bytes/s × 60 = 600,000 bytes ≈ 0.6 MB per minute one way; ×2 directions = 1.2 MB/min; ×60 minutes = 72 MB/h.

How to check the network#

  1. The *43 echo test from the phone in question: a beep → your own voice. How to read the four outcomes (beep without voice, silence, choppy) is in the overview: “Checking call quality”. Speak for at least 10 seconds — then loss, jitter and delay appear in the call log.
  2. A call from the PBX to the device (device card → “Check” → “Call this phone”) checks the return path — the very “hole” in the router that incoming calls come through.
  3. The same check from another network (a phone or softphone on mobile data) quickly tells you whether the venue network is to blame.

If something is wrong — troubleshooting by symptom:

Security#

  • Do not expose a phone, ATA or gateway directly to the internet: do not forward 5060 to it, do not put it in a DMZ and do not give it a public IP. The internet is scanned by bots around the clock — an exposed device starts ringing at night from numbers like “100” or “1000”, and in the worst case it is used for paid calls. Our setup does not need port forwarding at all.
  • Change the factory password of the phone's web interface (admin/admin and the like) — otherwise anyone on the venue network, including guest Wi-Fi without isolation, can open the settings and read the account.
  • If the phone has an option to accept SIP only from the server/proxy (Allow SIP from proxy only, Accept SIP from registrar only), turn it on.
  • Update phone and router firmware from the manufacturer's official sources.

FAQ#

Does the venue need a static (public) IP address?#

No. The phone connects to the PBX itself, and the PBX remembers it by its actual external address, whatever it is. It works behind the ISP's shared IP and over mobile internet too.

Do ports 5060 and 10000–20000 need to be forwarded on the router?#

No, and do not try: forwarding 5060 to a phone makes it visible to scanners from the internet. It is enough for the router to allow outbound traffic (that is how it is set up at the factory).

I could not find SIP ALG in my router. What now?#

Look in the NAT, Firewall, Security, WAN and Components sections. If there is no such item, the model may have no ALG at all; check with *43 and a call longer than a minute. If calls drop after 30 seconds and the router belongs to the ISP, ask the ISP to turn off SIP ALG or switch the device to bridge mode.

Incoming calls only arrive in the first minutes after the phone is switched on#

The classic sign of a stale NAT entry on the router: the phone stays silent longer than the UDP timeout, and the router forgets where to deliver incoming calls. Turn on NAT keep-alive in the phone at 15–30 seconds or switch the transport to TCP. Details — “Calls drop” and the section “NAT, double NAT and keep-alive”.

Is a mobile router with a SIM card enough for us?#

For 1–3 simultaneous conversations it usually is: you need about 0.1 Mbit/s per conversation each way. The weak point is instability: with loss above 3 % and delay above 300 ms conversations become awkward. Run *43 at peak hour and look at the numbers in the call log.

Can phones go on the guest Wi-Fi?#

Better not. The guest network often has client isolation and a login page, and guests share the link with their videos — voice starts breaking up at the busiest hour. Give phones a staff network or a VLAN.

Sources#

Was this article helpful?
Network, softphones & reset
Guest demo menu Start free