What Is a Point of Presence (PoP), and Why Your SIP Anchorsite Matters

What a point of presence actually does

A point of presence (PoP) is the network location where your SIP traffic enters or exits a provider's backbone. When a call is placed, the audio packets travel from the caller's device across the public internet until they reach the provider's nearest PoP. From that point onward, the packets travel on the provider's private network rather than hopping across the public internet.

The PoP where this handoff happens is called the anchorsite. It is the fixed point where media is anchored, or pinned, for the duration of the call. Choose the right anchorsite and your audio takes a short, clean path to its destination. Choose poorly, or let the network decide by default, and your audio may detour through a distant data centre before reaching its endpoint.

This choice matters more than most teams realise. The ITU recommends one-way latency below 150ms for acceptable voice quality. When your anchorsite is thousands of kilometres from your callers, you can exceed that threshold before the AI pipeline even starts processing.

How anchoring works on a SIP call

Every SIP call has two legs: the signalling leg (SIP messages that set up, modify, and tear down the call) and the media leg (the actual audio packets carried over RTP). The anchorsite determines where the media leg enters the provider's network.

Auto-selection - By default, most providers, including Telnyx, automatically route your media to the PoP with the lowest measured latency from your endpoint. This works well for simple deployments where all your callers and servers are in the same region.

Manual selection - When you specify an anchorsite, you are telling the provider to pin media at a particular PoP regardless of where the lowest-latency path would naturally route. This is useful when you have multi-region infrastructure, compliance requirements, or when you are running latency-sensitive applications like conversational voice AI where every millisecond of transport delay compounds through the pipeline.

The key insight: auto-selection optimises for network latency in isolation. Manual selection lets you optimise for the full application, including where your STT, LLM, and TTS workloads run.

Why the anchorsite choice affects call quality

The anchorsite determines three things that directly impact call quality and application performance.

Transport latency - The distance between the caller and the anchorsite is the single largest source of avoidable latency on a voice call. A caller in Dubai whose traffic anchors in London adds roughly 55ms of round-trip transport latency in each direction, before any processing happens. For a SIP trunking deployment serving Gulf customers, that detour is the difference between responsive and sluggish.

Jitter - Every hop on the public internet introduces variability in packet arrival time. The more hops between the caller and the anchorsite, the more jitter. Jitter forces the receiving endpoint to buffer audio, which adds further delay. A nearby anchorsite means fewer public-internet hops and more consistent packet delivery.

Packet loss - Public internet routes are subject to congestion, peering disputes, and transient outages. When audio travels a long path over the public internet, packet loss increases, which degrades both call quality and speech recognition accuracy for voice AI applications. Anchoring locally keeps audio on the private backbone, where the provider controls the path and can enforce quality of service.

Read more about how reducing latency and jitter with virtual cross-connects can further tighten the path between your infrastructure and the provider's backbone.

When to choose a specific anchorsite

Auto-selection is the right default for most single-region deployments. But several scenarios call for manual anchorsite selection.

Multi-region voice AI - If your STT, LLM, and TTS workloads run in a specific region, you want to anchor media as close to those workloads as possible, not necessarily as close to the caller. A Dubai caller whose AI pipeline runs in Frankfurt should anchor in Frankfurt to minimise the gap between audio ingress and processing start. If the pipeline runs locally, anchor in Dubai. See our deep dive on why voice AI struggles in the Gulf for a worked example.

Compliance and data residency - Some jurisdictions require that call media stays within national or regional boundaries. If you operate in the UAE, for instance, the TDRA may require that traffic originating and terminating in-country does not unnecessarily traverse foreign networks. A local anchorsite ensures compliance.

Contact centres and UCaaS - Large contact centre deployments often have centralised media processing for recording, analytics, and quality monitoring. Anchoring at the PoP closest to the processing infrastructure keeps audio paths predictable and reduces the variable latency that degrades agent experience.

Peering and interconnect - If you have direct peering with a provider at a specific exchange point, anchoring at the PoP that shares that exchange eliminates the public-internet leg entirely. This is the lowest-latency, highest-reliability configuration available.

For a practical look at how this works in the UAE specifically, including regulatory context and the Dubai anchorsite, see SIP trunking in the UAE.

How to configure your anchorsite

On Telnyx, anchorsite selection is available both in the Mission Control Portal and via the API.

In Mission Control:

1. Navigate to the Connections panel
2. Select the SIP connection you want to configure
3. Under Anchorsite, choose from the available PoPs
4. Save and apply

The change takes effect on new calls immediately. Existing calls are not interrupted.

Via the API: Set the anchorsite_override field when creating or updating a SIP connection. The available values correspond to each PoP location. See the Telnyx API reference for the full list and current values.

Auto vs manual: If you set anchorsite_override to a specific PoP, all media for that connection anchors there. If you leave it unset or set it to the default, Telnyx continuously measures latency from your endpoint to each PoP and dynamically selects the best one. For most deployments, auto is the right starting point. Switch to manual when you have a specific reason, such as the scenarios above.

Our support documentation covers SIP connection settings in detail, including codec selection and encryption options that work alongside anchorsite configuration.

Telnyx PoP locations

Telnyx operates anchorsites across a global private backbone spanning North America, Europe, Asia-Pacific, and the Middle East. Recent additions include Dubai, UAE, the first MENA-region anchorsite, which brings local SIP anchoring to Gulf deployments for the first time.

Key anchorsite locations include:

• Chicago, IL — Primary US Midwest hub
• Ashburn, VA — US East Coast, major peering exchange
• London, UK — European gateway
• Amsterdam, NL — Continental European hub
• Frankfurt, DE — Central European exchange
• Sydney, AU — Asia-Pacific gateway
• Dubai, UAE — MENA region (new)

The full list of available PoPs grows as the network expands. Check the Mission Control Portal for the current set of anchorsite options when configuring your connections.

For the Dubai anchorsite specifically, see the Dubai, UAE anchorsite release note for configuration details and coverage information.

Getting started

Choosing the right anchorsite is one of the highest-impact, lowest-effort changes you can make to improve voice call quality. Here is how to approach it.

1. Audit your current routing - Check where your SIP connections currently anchor. If your callers are in a region where you have no local PoP, you are paying a latency penalty on every call.
2. Measure the impact - Compare round-trip times from your endpoints to each available PoP. The difference between your current anchorsite and a closer one is the latency you can eliminate with a configuration change, no code required.
3. Consider your application - For traditional voice calls, auto-selection is usually sufficient. For voice AI, Microsoft Teams Direct Routing, or compliance-sensitive deployments, manual selection gives you control over where media anchors relative to your processing infrastructure.
4. Configure and monitor - Set your preferred anchorsite in Mission Control or via the API, then monitor call quality metrics. If your deployment spans multiple regions, you may need different anchorsites for different connections.

The right anchorsite is not a global setting. It depends on where your callers are, where your infrastructure runs, and what your application tolerates. Start with auto, measure, and optimise from there.