Keep the destination identity and next hop separate
An outbound proxy changes the next hop for a SIP request; it does not automatically replace the registrar, address of record, remote contact, Request-URI identity or authenticated account. Asterisk's proxy example leaves the AoR contact and outbound registration server_uri and client_uri in their provider-facing form, then adds the proxy URI separately.
Record the service identity, request owner, request URI, proxy URI, selected transport and final remote socket as separate facts. Pointing the server URI at a proxy merely to make packets move can change the registration identity or routing semantics and can hide the original design error.
Configure endpoint, AoR and registration as separate request owners
Asterisk documents outbound_proxy on several objects because they send different requests. The endpoint setting routes most dialog and out-of-dialog requests for that endpoint, the AoR or contact setting is used for qualification OPTIONS, and the outbound-registration setting routes REGISTER. The configuration wizard's shortcut expands to endpoint, AoR and registration proxy values; it does not merge the underlying objects.
Do not use a successful REGISTER as evidence that INVITE or OPTIONS followed the same path. Inspect the loaded endpoint, AoR contacts and registration independently, then correlate one request of each required method with the intended proxy. A proxy may also have method-specific policy, authentication or routing failures.
Preserve loose routing and configuration-file grammar
The Asterisk guide uses a full proxy SIP URI with the lr parameter and warns that omitting loose routing can produce a 404 from a modern proxy. In pjsip.conf, the semicolon must be escaped so the configuration parser does not treat it as the beginning of a comment: the configured value appears as sip:proxy.example\;lr.
Treat the backslash as configuration-file syntax and lr as a SIP URI parameter. Confirm the loaded value rather than copying the escape into a provider portal, database field or packet expectation without checking that owner's syntax. Preserve the actual Route headers and Request-URI from a bounded trace; a 404 can also come from the proxy's routing table or the upstream target.
Rework inbound identification when several services share one proxy
When a proxy forwards inbound requests, Asterisk sees the proxy's source address. The proxy guide therefore matches the proxy's internal address in the identify object rather than the remote carrier address. That identifies the hop, not necessarily the original provider or authorized destination.
One source address cannot select several different endpoints by IP alone. Asterisk documents registration line and endpoint parameters as an alternative only when the provider returns the unique line token on inbound calls. Otherwise the proxy, carrier and PBX need an explicit supported discriminator such as a request-URI or header design. Do not broaden one proxy match into an unrestricted context or assume a From value is trustworthy.
Apply topology, NAT and direct-media advice only to the documented design
Asterisk's worked example assumes a dual-homed proxy on the same private network as Asterisk and says that proxy also relays media. Within that design, it removes Asterisk-side external-address and NAT options and can direct media between phones and the proxy. Those instructions are not a universal SBC recipe.
Document whether the selected proxy is on the same network, whether it changes Record-Route, Contact, Via, SDP or RTP, and whether it anchors media. Preserve local subnets, advertised addresses, firewall rules, certificate identities and media owners for the actual topology. A signaling proxy does not automatically repair private SDP, symmetric RTP, certificate mismatch or an unreachable media address.
Verify loaded state and every required method before cutover
Use the supported configuration owner, then inspect the loaded endpoint proxy, AoR or contact proxy and outbound-registration detail. Asterisk's branch-22 event schema exposes OutboundProxy, ServerUri, ClientUri, transport, status and NextReg; keep those fields attached to the same named registration. Collect only a bounded PJSIP trace and protect credentials, numbers, addresses and calling data.
Test REGISTER when required, OPTIONS qualification, outbound INVITE, inbound identification, authentication, restricted dialplan entry, responses, two-way media, DTMF, transfer, failover and return to service. Include an unrelated negative control so the proxy address does not admit arbitrary traffic. No Asterisk host, proxy, carrier, request, media path, availability result or call was inspected or tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk PJSIP with proxies guide ↗
- Asterisk 22 res_pjsip configuration reference ↗
- Asterisk current outbound-registration reference ↗
- Asterisk outbound-registration architecture ↗
- Certified Asterisk 22.8 PJSIP wizard reference ↗
- Asterisk 22 OutboundRegistrationDetail event ↗
- Asterisk bounded debug-information collection ↗
- IETF RFC 3261: SIP loose routing ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.