Capture the request that received 485
Record the timestamp and timezone, method, entered and expected destination, direction, endpoint and visible symptom. Use an authorized, narrowly timed pjsip set logger on reproduction and preserve the request that received 485 plus its response. Disable protocol logging afterward and protect credentials, identities, telephone numbers, directory entries, Contact alternatives and SDP.
Identify the response source, Request-URI, Call-ID, CSeq and top Via branch. Asterisk may receive an endpoint-facing request and create a different provider-facing request, so correlate the PJSIP channel and both legs. Do not assign the ambiguity to Asterisk because it relayed the response, or to a provider because the call used a trunk.
Keep wire response and translated cause separate
Asterisk's current mapping groups SIP 404, 485 and 604 under AST_CAUSE_UNALLOCATED, Q.850 cause 1. That translation is useful for cross-technology handling but discards the distinction between not found, ambiguous and globally nonexistent, as well as the responder, URI and optional Contacts. Preserve the wire response before acting on the Asterisk cause.
After Dial(), use HANGUPCAUSE_KEYS() and the per-channel technology and Asterisk values to keep parallel called channels separate. A single calling-channel variable can hide which branch produced 485, and a later translated cause is not proof that the currently inspected PJSIP leg received that response.
Separate RFC ambiguity from Asterisk object multiplicity
An RFC 485 says the responder found the Request-URI ambiguous. It is not the name of every Asterisk situation involving more than one endpoint, identify match or AOR contact. Asterisk documents an endpoint as a behavior profile linked to AOR objects, while an AOR can contain static or registered Contact URIs. Loaded object state answers where Asterisk can send a request; it does not prove why another server returned 485.
Inspect pjsip show endpoint, pjsip show aor and the relevant contacts for the selected endpoint. Record whether the dial string uses the first AOR contact, PJSIP_DIAL_CONTACTS() to fork to all contacts, or an explicit URI. Do not delete a legitimate multi-device registration merely because an external address was ambiguous.
Reconstruct the outbound address and target owner
Trace endpoint input through the loaded context, extension and priority, then record every normalization, directory lookup, substring, prefix and route choice that produces the outbound Request-URI. Asterisk documents Dial(PJSIP/${EXTEN}@mytrunk) as inserting a user into the trunk AOR contact and an explicit PJSIP/mytrunk/sip:user@host form as constructing the URI directly. Capture the actual outbound request instead of inferring it from the source extension.
Separate the Request-URI user and domain from From, To, P-Asserted-Identity and caller ID. If the 485 responder is external, obtain its authoritative target policy and redacted lookup result. If Asterisk itself sent 485, prove which loaded route or application made that decision before changing local configuration.
Handle returned alternatives as privacy-controlled data
A 485 response may contain possible unambiguous addresses, but RFC 3261 allows them to be suppressed and requires a 404 alternative because disclosure can infringe privacy. Preserve any Contact fields as sensitive evidence. Absence of Contacts is not a parsing failure, and their presence is not an instruction to dial every entry.
Do not rewrite 485 into a 3xx response or use parallel Dial() branches as a universal repair. A deliberate user-choice workflow needs an authorized display policy, a selected complete address and a new bounded request. For ordinary business dialing, prefer correcting the authoritative directory or normalization record so the original request identifies one intended target.
Correct one owner and test negative paths
Change only the demonstrated address-book record, dialplan transformation, directory mapping, trunk URI construction or external route rule. On FreePBX, use supported route and trunk controls rather than editing generated dialplan. Keep a rollback target and reload only the running configuration whose change requires it.
Repeat the intended full address, a deliberately ambiguous value, a nonexistent address and an unauthorized target. Confirm the exact Request-URI and response owner, and verify that privacy-suppressed cases remain suppressed. For a successful call, test answer, two-way media, required DTMF and release separately; absence of 485 proves none of those later stages. No PBX, endpoint, proxy, provider, directory, address, contact, dialplan or live call was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: 485 Ambiguous ↗
- Asterisk hangup cause mappings ↗
- Asterisk hangup cause inspection ↗
- Asterisk PJSIP configuration relationships ↗
- Asterisk dialing PJSIP channels ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk dialplan contexts, extensions and priorities ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.