Asterisk VPS Location: Latency, Jitter and Routing

Host your Asterisk VPS in the region that gives the cleanest combined route between your phones, the PBX, and the SIP carrier's media gateways. The nearest datacenter on a map is only a candidate. Test latency, packet delay variation, loss, and route stability from every important office and toward the carrier's RTP addresses. For a European workforce and European trunk, Germany is the logical first test. For North American users, test Utah and Quebec. When users and carriers are split across continents, one central PBX may be the wrong architecture.

Written by the ServerSpan Technical Team

The complete media path decides where Asterisk should run

An Asterisk call often has two separate network legs:

• The phone or softphone to the Asterisk VPS.
• The Asterisk VPS to the SIP carrier, gateway, or other endpoint.

You need to keep both legs short and stable. Choosing a VPS next to your office can still produce poor calls when the SIP carrier sends RTP through a distant media gateway. Choosing a VPS next to the carrier can create the opposite problem for remote phones.

ServerSpan currently offers container and KVM VPS hosting in Utah, Quebec, and Germany. Treat those regions as test candidates. Do not choose one from geography alone.

Ask your SIP carrier where signaling terminates and where RTP media normally originates. These may be different locations. A registrar hostname may resolve to one region while calls use media gateways elsewhere. Some carriers also change the media gateway according to the destination number.

The decision rule is direct: optimize the route carrying audio, then verify that SIP signaling remains reliable. A fast SIP registration does not prove that the RTP path is good.

Asterisk may leave the RTP path when direct media succeeds

Asterisk does not always relay every audio packet. The PJSIP direct_media option determines whether media may flow directly between endpoints. When direct media succeeds, the phones or gateways exchange RTP without sending it through the PBX.

In that case, the VPS location mainly affects SIP signaling, initial call setup, and any media that Asterisk must process. The audio path may instead run directly between the phone and the carrier.

Do not assume direct media is active because it appears in the configuration. NAT, incompatible SDP, provider policy, codec differences, recording, transcoding, conferences, call queues, and other PBX features may keep Asterisk in the media path.

Inspect the current configuration before evaluating regions:

sudo grep -RniE '^[[:space:]]*direct_media[[:space:]]*=' /etc/asterisk/

sudo asterisk -rx "pjsip show endpoints"
sudo asterisk -rx "pjsip show contacts"
sudo asterisk -rx "pjsip show registrations"

The first command shows explicit direct-media settings. No result means the effective default or generated configuration still needs to be checked. The PJSIP commands show endpoint, contact, and trunk-registration state. Contact qualify results are useful for SIP reachability, but they do not measure RTP quality during a call.

When the PBX records calls, transcodes codecs, injects audio, or hosts conferences, plan as though the RTP stream will cross the VPS. That is the safer location decision.

Latency is a budget shared by both call legs

Conversational delay includes network transit, packetization, codec processing, jitter buffering, and any media processing performed by Asterisk or the carrier. A low ping to the VPS does not guarantee a low mouth-to-ear delay.

The following bands are conservative screening targets for business voice. They are not Asterisk limits and must be confirmed with real calls.

Measurement	Preferred test result	Result requiring investigation	What it usually means
Endpoint-to-VPS round-trip time	Below 80 ms and stable	Repeatedly above 150 ms	The user hears greater conversational delay, especially when the second call leg is also long
Packet delay variation	Single-digit or low tens of milliseconds	Sustained variation above roughly 30 ms	The receiver needs a larger jitter buffer or begins discarding packets that arrive too late
Packet loss	0% during sustained tests	Any recurring loss, especially near or above 1%	Clicks, missing syllables, robotic audio, or brief silence
Route stability	Similar path and latency throughout the day	Frequent path changes or large peak-hour jumps	Congestion, weak peering, or unstable upstream routing
VPS-to-carrier path	Comparable to or better than the phone-to-VPS path	A distant media gateway or indirect intercontinental route	The carrier leg cancels the benefit of placing the PBX near the users

Evaluate the worst normal period, not the quietest five minutes of the day. A route that performs well at 03:00 but develops loss and delay variation during office hours is not suitable for a production PBX.

Routing matters more than straight-line distance

Internet traffic follows routing policy, peering relationships, and available transit. It does not follow the shortest geographic line. A datacenter 300 kilometres away can have a worse route than one 1,000 kilometres away.

A local ISP may send traffic through a distant exchange before it reaches the destination network. A SIP carrier may announce its media subnet through a different upstream than its signaling service. Routes can also change during congestion or an upstream outage.

This is why a location comparison needs at least three paths:

• Each important office or remote-user network to the candidate VPS.
• The candidate VPS to the SIP carrier's signaling service.
• The candidate VPS to the carrier's actual RTP media addresses.

A route test in one direction does not reveal every asymmetric-routing problem. Ask the carrier for test endpoints or packet captures when its return path appears different.

Use the three ServerSpan regions as measured candidates

The table below is a starting filter. The measured route remains the final authority.

Candidate region	Test it first when	Also verify	Common bad design
Utah, United States	Most phones and carrier media are in the western or central United States	Routes from eastern offices and the carrier's RTP gateways	European phones crossing the Atlantic twice for each anchored call
Quebec, Canada	Users are concentrated in eastern Canada or the northeastern United States	Whether the carrier keeps media in eastern North America	Choosing Canada for users in Europe because it looks geographically central
Germany	Most users and the SIP carrier are within Europe	Routes from branch offices, mobile networks, and any non-European trunk	Hosting in Europe while the carrier anchors all RTP in North America
More than one region	Important users and trunks are divided between North America and Europe	Call routing, configuration synchronization, numbering, and failover	Forcing every call through one intercontinental PBX to avoid operating a second node

A multinational deployment may need regional PBX or session-border-controller nodes rather than one compromise location. Keep local calls local where possible. Route only the calls that genuinely need to cross regions.

Measure every candidate from the networks that carry real calls

Run tests from each office, not from your laptop on an unrelated connection. Remote staff using residential broadband, Wi-Fi, or mobile data need separate measurements because their access network may be the dominant problem.

ping -c 100 <candidate-vps-ip>

mtr -rw -c 200 <candidate-vps-ip>

tracepath <candidate-vps-ip>

ping shows basic round-trip delay and loss. A clean result has no repeated packet loss and a narrow spread between minimum, average, and maximum latency. Large maximum values indicate delay spikes even when the average looks acceptable.

mtr combines path discovery with repeated measurements. Focus on the final destination and on latency changes that continue through every later hop. An intermediate router may deprioritize diagnostic packets while forwarding voice traffic normally, so loss on one middle hop is not proof of a problem when later hops and the destination remain clean.

tracepath shows the route and path MTU. Compare its path from several offices and at several times of day. A large route change accompanied by worse final latency is more meaningful than a different router name alone.

Repeat the tests from the VPS toward the carrier:

ping -c 100 <carrier-media-ip>

mtr -rw -c 200 <carrier-media-ip>

tracepath <carrier-media-ip>

Use the carrier's media IP, not only its SIP hostname. Do not run high-rate UDP tests against infrastructure you do not control. When both ends are yours, an iperf3 UDP test can help measure loss and variation under a controlled load.

The ServerSpan guide to network troubleshooting on a Linux VPS provides a broader workflow for routes, sockets, DNS, firewall rules, and packet captures.

Confirm the RTP addresses during a real call

SIP messages contain SDP that tells each side where media should be sent. Capturing one controlled test call confirms whether RTP is passing through the VPS and identifies the carrier's current media address.

First inspect the configured RTP range:

sudo grep -E '^[[:space:]]*(rtpstart|rtpend)[[:space:]]*=' \
  /etc/asterisk/rtp.conf

sudo ss -lunp | grep asterisk

The first command should show the UDP port range assigned to RTP. The second should show Asterisk listening only on the expected signaling and media sockets. A missing RTP range may mean defaults are in use or the configuration is generated elsewhere.

For a brief test, enter the Asterisk console:

sudo asterisk -rvvv

pjsip set logger on
rtp set debug on

# Place one short test call, then stop the verbose output.

rtp set debug off
pjsip set logger off

The PJSIP logger shows signaling and SDP. RTP debug shows packet source and destination addresses. It can generate substantial output and reveal endpoint addresses, so enable it only for a short controlled call.

If the RTP addresses belong to the phones and carrier rather than the VPS, direct media is active for that call. If both media legs terminate on the VPS, its location directly affects audio in both directions.

A jitter buffer can smooth variation but cannot repair the route

Packet delay variation means audio packets do not arrive at regular intervals. A jitter buffer holds packets briefly and plays them at a steadier rate. The cost is additional delay.

Asterisk provides fixed and adaptive jitter buffers through the JITTERBUFFER dialplan function. An adaptive buffer changes its behaviour according to the incoming stream.

Inspect the current dialplan before adding another buffer:

sudo grep -Rni 'JITTERBUFFER(' /etc/asterisk/

A simple adaptive example is:

same => n,Set(JITTERBUFFER(adaptive)=200,,40)

This example allows a maximum buffer of 200 milliseconds and 40 milliseconds of adaptive padding. Do not apply it globally without call tests. A larger buffer may reduce late-packet gaps while making conversation feel slower. It does not recover packets that never arrived.

If the buffer repeatedly needs to absorb large variations, fix the route, office congestion, Wi-Fi, or carrier path. Buffering should handle modest variation, not conceal a persistently poor network.

QoS markings help only on networks that honour them

Asterisk can mark SIP signaling and RTP audio with different DSCP values. Its documentation recommends CS3 for signaling and EF for audio.

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
tos=cs3

[office-phone]
type=endpoint
tos_audio=ef

Merge these options into existing transport and endpoint sections rather than creating incomplete duplicate objects. PJSIP transport changes require an Asterisk restart, so schedule them during a maintenance window.

DSCP markings are valuable inside an office, private WAN, or carrier network that has matching queue policies. They do not guarantee priority across the public internet. A marked packet can still follow a congested or indirect route.

Call symptoms reveal whether location is the real problem

Symptom	Likely area	First check
Both parties talk over each other because responses arrive late	End-to-end latency or oversized jitter buffers	Measure both RTP legs and inspect active jitter-buffer settings
Robotic, broken, or choppy audio	Packet loss, delay variation, Wi-Fi, or congestion	Run sustained path tests during the affected period
Audio works in only one direction	NAT, firewall, SDP, or incorrect media address	Inspect SIP SDP and RTP source and destination addresses
Calls drop after a predictable interval	RTP timeout, NAT state, SIP session timer, or firewall timeout	Check Asterisk logs, PJSIP messages, and rtp_timeout settings
Slow ringing but acceptable audio after answer	SIP signaling, DNS, trunk response, or dialplan processing	Use the PJSIP logger and compare signaling timestamps
Problems occur only when someone uploads a large file	Office-edge congestion or bufferbloat	Test during upload load and apply QoS at the access router

One-way audio is rarely fixed by moving the VPS to another city. Choppy audio may be location-related, but it can also originate on the user's Wi-Fi or broadband uplink. Diagnose the symptom before migrating the PBX.

Choose the virtualization type after proving the network path

Asterisk can run in a conventional Linux container or a KVM virtual machine. The virtualization choice does not compensate for a poor route.

A container VPS can suit a native Asterisk installation with a straightforward Linux stack. KVM is the safer choice when you require Docker, custom kernel-level networking, stronger virtual-machine separation, or a larger appliance-style PBX stack.

The ServerSpan comparison of KVM VPS and container VPS explains the infrastructure differences. Choose the region first, verify the RTP path, then select CPU, RAM, and virtualization according to concurrent calls, recording, conferences, and transcoding.

Monitor call paths after deployment

A route that is good during deployment can change later. Monitor the VPS from the outside and collect server-side metrics for CPU, memory, interface errors, service status, and disk space.

For voice systems, add endpoint reachability, trunk registration, certificate expiry, call failures, RTP inactivity, and periodic path tests to the carrier. Keep the measurements by region and time of day so that route changes can be distinguished from application changes.

The ServerSpan article on VPS uptime and health monitoring explains how external checks and internal metrics cover different failure modes.

If you need a candidate VPS in Utah, Quebec, or Germany, ServerSpan's VPS hosting plans let you deploy the same application stack in the region that performs best during your tests. Run the network comparison before moving production numbers or changing carrier routes.

The final rule is simple. Place Asterisk where the combined phone-to-PBX and PBX-to-carrier media path is shortest, cleanest, and most stable during real business hours. Prefer Germany for a European deployment only after the carrier path agrees. Prefer Utah or Quebec for North America only after testing the actual offices and RTP gateways. When no single region keeps every critical leg acceptable, use regional voice infrastructure instead of forcing one VPS to serve the entire world.