What this response means
RFC 3261 defines 484 Address Incomplete for a request whose Request-URI is incomplete. The reason phrase should provide more information, but it remains descriptive text rather than a stable machine-readable number plan. Bind the code to the exact request method, URI, transaction and responding server before deciding which digits or address component are absent.
The RFC also describes overlap dialing, where a client sends progressively longer strings until the server no longer returns 484. RFC 4504 says a SIP telephone receiving 484 should be prepared to collect more input and try again. That protocol history does not mean every endpoint, PBX or carrier uses overlap dialing, nor does it authorize an intermediary to guess a complete destination.
Inspect the Request-URI, not only the display number
Capture the request line, source, destination, From, To, Call-ID, CSeq and response direction for one bounded failure. Record the URI scheme, user part, domain, port, parameters and any Route headers. The user-visible dialed digits, asserted identity and Request-URI can differ after endpoint digit maps, PBX normalization, trunk rules or a B2BUA creates another leg.
Compare one nearby working destination through the same path. A missing country code, trunk prefix, leading symbol, extension suffix, domain or user part is an investigation possibility, not a conclusion from 484 alone. The responder's own numbering or URI policy determines what it considered incomplete.
Separate incomplete, unknown and ambiguous addresses
A 484 is not interchangeable with 404 Not Found, 416 Unsupported URI Scheme or 485 Ambiguous. An address can be syntactically parseable yet incomplete under the serving policy; a complete-looking number can still be unknown; and an address can identify several possible targets. Preserve the exact code and responder rather than reducing all of them to invalid number.
Authentication, codec, SDP, RTP and NAT changes do not complete a Request-URI. Investigate them only when separate evidence shows an additional failure after the address is accepted. Asterisk may translate 484 into its invalid-number-format cause, but that translated cause is coarser than the original SIP exchange.
Correct the owner of address construction
Determine where the address was built: endpoint digit map, PBX dialplan, normalization service, outbound route, trunk dial string, proxy rewrite or provider number plan. Change the narrowest demonstrated rule and keep emergency, premium, internal and international destinations within their intended permissions.
Do not add a blanket prefix, strip digits globally or broaden a catch-all route because one destination returned 484. Those changes can misroute valid numbers or create toll and emergency-calling risk. If the responder is external, obtain its current accepted format and escalate with a redacted request and timestamp rather than an assumed recipe.
Retest the full and incomplete cases
After one approved correction, repeat the original method and destination and confirm that the Request-URI matches the intended format. For a call, verify answer, two-way media, required DTMF and normal release separately; absence of 484 proves none of those later stages.
Test a valid nearby destination, a deliberately incomplete address and an unauthorized destination. Each should receive the designed, bounded treatment without a broad rewrite. For Asterisk PJSIP, the focused 484 investigation distinguishes the wire response, translated cause, dialplan value and outbound URI construction.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: 484 Address Incomplete ↗
- IETF RFC 4504: SIP telephony device dialing requirements ↗
- Asterisk hangup cause mappings ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.