VoIP in Tower Networking Inc. [beta] is tricky because it does not behave like a normal HTTP/DNS service. The main issue is that VoIP phones generate broadcast udp/5060 traffic. If routing is wrong, VoIP either will not work at all, or it will create a broadcast storm across your network.

1. How VoIP works in this game

The basic flow seems to be:

VoIP phone
↓
generates phone connection traffic over udp/5060
↓
voip-server accepts accept-voip-phone-connection
↓
voip-server converts it into stream-voice
↓
customer/user consumes stream-voice

Important point: the customer who wants stream-voice does not need a phone next to them.

The phone is needed by the VoIP server as the source of accept-voip-phone-connection.

2. What you need

Minimum setup:

1. A server with voip-server installed
2. A domain, for example voip.net
3. DNS mapping voip.net to the VoIP server
4. A VoIP phone generating udp/5060 traffic
5. Routing for udp/5060 toward the voip-server

Example:

@core-voip = VoIP server
@core-dns  = DNS server
voip.net   = stream-voice service domain

DNS example:

dns map voip.net @core-voip on @core-dns

If the game requires registering a domain with a provided use, make sure the domain provides:

stream-voice

3. Trace is not enough

This may work:

trace voip.net from @floor1/phone with udp/5060

But that only proves that a route exists.

It does not always prove that the real VoIP phone traffic is being consumed by the server.

You can have this situation:

trace works
voip-server sees udp/5060 packets
but stream-voice is still not produced

Check the VoIP server with:

dstat @core-voip

If you see something like:

[accept-voip-phone-connection] = 10
voip-server load: 0/10

then the server is ready to accept phone connections, but it is not receiving valid active phone usage yet.

4. Best setup without VLANs

Before VLANs are unlocked, the cleanest approach is to build a separate physical network for VoIP phones.

Recommended layout:

VoIP phones → voice switch → @core-voip

customers/users → normal network → core-router → @core-voip

So @core-voip can have two sides:

port0 = normal customer/user network
port1 = dedicated VoIP phone network

This is the closest substitute for VLANs early in the campaign.

5. If the phone is on a normal floor network

Assume:

@floor1/router port2 = uplink to core/backbone
@floor1/router port3 = local floor switch
@core-router port0   = backend/core where @core-voip is located

On the floor router where the phone exists, add:

route add traffic udp/5060 via port2 on @floor1/router using @dbg

Do not rely only on a destination-based route like:

route add @core-voip traffic udp/5060 via port2 ...

Why? Because VoIP phone traffic is broadcast-based and may not yet have @core-voip as its destination.

A better rule is:

route add traffic udp/5060 via port2 on @floor1/router using @dbg

6. On the core router

If @core-voip is behind port0, add:

route add traffic udp/5060 via port0 on @core-router using @dbg

Also add a normal route to the VoIP server:

route add @core-voip via port0 on @core-router using @dbg

Example core-router setup:

route add @floor1/ via port4 on @core-router using @dbg
route add @floor2/ via port5 on @core-router using @dbg
route add @core-voip via port0 on @core-router using @dbg
route add traffic udp/5060 via port0 on @core-router using @dbg

7. Be careful with broadcast

This is the main trap.

If you use:

route enable broadcast on @core-router

VoIP may start working, but you can easily create a:

broadcast storm

Symptoms:

high network load
random timeouts
DNS/DHCP instability
VoIP works, but the whole network becomes unstable

General rule:

drop broadcast on the main network
use a separate VoIP path, or route udp/5060 very carefully

8. Pro tip: default drop + enable broadcast

Some players use this trick:

route default drop on @router using @dbg
route enable broadcast on @router using @dbg
route add traffic udp/5060 via portX on @router using @dbg

The idea:

broadcast is enabled,
but there is no default port for it to leak through,
so only explicitly routed udp/5060 goes out.

Downside: with default drop, you must manually define routes for everything else:

DNS
DHCP
VoIP
traffic to core
local prefix traffic
other services

It can work, but it becomes annoying to maintain without VLANs.

9. Common mistakes

Mistake 1: Route to @core-voip, but no udp/5060 traffic route

This alone may not be enough:

route add @core-voip via port0

Also add:

route add traffic udp/5060 via port0

Mistake 2: Destination-based VoIP route only

For broadcast VoIP traffic, this is often better:

route add traffic udp/5060 via port0

than this:

route add @core-voip traffic udp/5060 via port0

Mistake 3: Broadcast drop blocks the phone

If the VoIP phone is on a floor network and broadcast is dropped, stream-voice may never be created.

Test:

route enable broadcast on @floor1/router using @dbg

If stream-voice appears after enabling broadcast, the issue is confirmed.

But do not leave broadcast open everywhere, because it can cause a storm.

Mistake 4: Phone behind a router instead of a switch

VoIP phones are better placed behind a switch:

phone → switch → core/voip

rather than:

phone → router → router → core

Routers can mishandle the phone broadcast traffic.

Mistake 5: Confusing accept-voip-phone-connection with stream-voice

On the VoIP server, you may see:

accept-voip-phone-connection = 10

That does not mean customers are receiving stream-voice.

It means the server has capacity to accept phone connections. stream-voice appears only when the phone actually provides the connection.

10. Debugging checklist

Step 1: Check DNS

dns show on @core-dns

You should see:

voip.net → @core-voip

Step 2: Trace from the phone

trace voip.net from @floor1/phone with udp/5060

It should reach:

@core-voip

Step 3: Trace from the customer

trace voip.net from @floor2/customer with udp/5060

It should also reach:

@core-voip

Step 4: Watch the VoIP server

watch @core-voip

or:

dstat @core-voip

Look for:

voip-server load
accept-voip-phone-connection
stream-voice
network load
udp/5060

If udp/5060 reaches the server but voip-server load stays 0/10, the packets are reaching the machine but are not being consumed as valid VoIP usage.

11. Recommended early-game setup

Without VLANs, I recommend:

Normal network:
customers → floor router → core-router → @core-voip port0

Voice network:
VoIP phones → voice switch → @core-voip port1

On the main routers:

route drop broadcast on @floor1/router using @dbg
route drop broadcast on @floor2/router using @dbg
route drop broadcast on @core-router using @dbg

Keep VoIP broadcast outside the main network on a dedicated physical switch/path.

12. After VLANs are unlocked

Then you can do it properly:

VLAN voice = VoIP phones
VLAN users = customers/users
VLAN infra = DNS/DHCP/routers

Example idea:

vlan tag port1 with #voice on @msw
vlan tag port2 with #users on @msw
vlan tag port3 with #voice #users on @msw

Then VoIP broadcast stays inside the voice VLAN and does not flood the whole network.

Conclusion

VoIP in this game needs a different mindset than DNS or HTTP.

Key rules:

1. VoIP phone traffic is broadcast udp/5060.
2. voip-server converts phone connection into stream-voice.
3. A route to @core-voip alone is not enough.
4. You must handle udp/5060 as a traffic type.
5. Broadcast can easily cause a storm.
6. Without VLANs, use a separate physical VoIP network.

Best early-game architecture:

VoIP phones on a dedicated switch
normal customers on the normal network
@core-voip as the meeting point
no VoIP broadcast through the core-router