Bind 485 to one request and one responder
SIP 485 means that the Request-URI was ambiguous to the responding server. Preserve the request method, Request-URI, Call-ID, CSeq, top Via branch, response source and call leg. A PBX or B2BUA can terminate one leg and create another, so the code shown by a phone does not by itself identify the system whose address policy found several possible targets.
Compare the exact URI received by that responder with a nearby known-working address. Keep user, domain, URI parameters and any earlier rewrite separate from display name, From, To, P-Asserted-Identity and caller ID. The ambiguity belongs to the target-address lookup, not automatically to the caller identity.
Treat Contact alternatives as optional and sensitive
RFC 3261 permits a 485 response to include possible unambiguous addresses in Contact header fields, but does not require that list. It also requires a server to be configurable to suppress the choices or answer 404 because revealing alternatives can expose personal or organizational information. An empty Contact set therefore does not disprove ambiguity.
Protect any returned names, addresses and domains as directory data. Do not publish an unredacted response in a ticket or use the absence of alternatives as a reason to broaden a directory search. Obtain the responsible system's privacy and address-resolution policy before changing disclosure behavior.
Do not turn 485 into automatic redirection
RFC 3261 distinguishes 485 from 300 Multiple Choices. A 300 response assumes the choices reach the same person or service and can support automated or sequential handling; 485 requires user intervention to choose the intended resource. Do not automatically dial every returned Contact or convert the list into failover targets.
If an application is designed to present choices, authorize what can be displayed, preserve the selected complete URI and start a deliberate new request under the product's policy. Test cancellation, timeout and denied choices as well as the chosen target.
Separate neighboring status codes
A 485 is not the same as 484 Address Incomplete, 404 Not Found, 300 Multiple Choices or 486 Busy Here. Incompleteness says the address needs more information; not-found hides or lacks a resource; 300 offers equivalent locations; busy describes the selected endpoint's current willingness or capacity. Preserve the original code and responder before assigning a repair.
Authentication, codec, SDP, NAT and RTP changes do not disambiguate a Request-URI. Investigate them only if separate evidence shows an additional failure after a target has been selected and the request advances.
Correct the authoritative directory rule
Identify the component that owns the ambiguous lookup: endpoint address book, PBX dialplan, enterprise directory, proxy location service, provider normalization or another route service. Compare the input and target set, then change the narrowest demonstrated record or transformation with rollback prepared.
Retest the intended full address, a deliberately ambiguous form, a nonexistent address and an unauthorized target. The repaired request must reach only the intended resource, while privacy and denial behavior remain intact. For Asterisk PJSIP, the focused 485 investigation keeps the received wire response, coarse translated cause, AOR contacts and external target policy distinct.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.