Asterisk PJSIP 484 Address Incomplete: trace the constructed URI

Prove who sent 484 and for which request

Record the timestamp and timezone, method, entered and expected destination, direction, endpoint and visible result. Use an authorized, narrowly bounded pjsip set logger on reproduction and preserve the request that received 484 plus the response. Disable protocol logging after the capture and protect credentials, identities, telephone numbers, addresses and SDP.

Identify the response source, request URI, Call-ID, CSeq and top Via branch. Asterisk can terminate one SIP leg and create another, so the phone-facing and provider-facing messages may carry different URIs and identifiers. Do not assign the response to Asterisk because the phone displays it, or to the provider because the call used a trunk.

Keep wire response and translated cause separate

Current Asterisk documentation maps SIP 484 to AST_CAUSE_INVALID_NUMBER_FORMAT, Q.850 cause 28. That mapping is useful for cross-technology handling but does not retain the responding server, method, URI or reason phrase. Use HANGUPCAUSE_KEYS() and per-channel HANGUPCAUSE(...,tech) or translated cause information after Dial() when the dialplan needs evidence from a called channel.

A translated invalid-number-format cause is not proof that Asterisk received 484 on the leg now being viewed. A local dial-string error, another channel technology or a later translation can present a related failure. Correlate channel names, timestamps and the PJSIP exchange before choosing the repair.

Trace input through the running dialplan

Record the endpoint's incoming context and the loaded CONTEXT, EXTEN and PRIORITY values for the failing call. Follow exact extensions, patterns, includes and switches in their documented search order, then record every substring, prefix, database lookup, route selection or other transformation that produces the outbound user part. Compare a nearby working destination without changing authentication, codecs, NAT or transport.

Review wildcard patterns carefully. Asterisk documents . as one or more characters and ! as zero or more characters with special early-match behavior. A broad pattern can accept input earlier than intended or route an incomplete value. Tighten the demonstrated pattern and keep denied destinations denied; do not turn a 484 into an unrestricted catch-all.

Reconstruct the outbound PJSIP URI

Inspect the loaded endpoint, AOR, contacts and selected dial string. Asterisk documents that Dial(PJSIP/${EXTEN}@mytrunk) inserts the user into a contact whose AOR may contain only a domain, while an explicit PJSIP/mytrunk/sip:user@host form constructs the URI directly. Capture the actual outbound request rather than inferring it from the source extension or saved configuration.

Separate the Request-URI user and domain from From, To, P-Asserted-Identity and caller ID. A provider can accept the identity but reject an incomplete request target, or vice versa. Obtain the destination owner's exact current format before changing country codes, access prefixes, symbols, domains or URI parameters.

Treat overlap dialing as an explicit capability

RFC 3261 allows 484 to support overlap dialing, and RFC 4504 describes an endpoint collecting more input and retrying. Do not assume that Asterisk, the endpoint and the remote server have negotiated one shared overlap workflow. Most managed calling plans should construct and validate a complete destination before sending the outbound INVITE unless the exact interworking design intentionally supports overlap.

If overlap behavior is required, test the endpoint digit map, Asterisk overlap context and remote policy together. Keep successive attempts as new transactions with complete logs, and bound timers and digit collection so an abandoned handset does not create an open-ended or misrouted call.

Correct one transformation and test negative paths

Change the demonstrated endpoint digit map, dialplan transformation, route pattern, trunk dial string, AOR contact or external number policy. On FreePBX, use supported route and trunk controls rather than editing generated dialplan. Preserve a rollback target and reload only the configuration whose running state must change.

Repeat the original destination, a nearby valid destination, a deliberately incomplete value and an unauthorized value. Confirm the intended Request-URI, response owner and bounded rejection; then verify answer, media, DTMF and release separately for the successful call. No PBX, endpoint, provider, number plan, pattern, URI, route, overlap workflow, media path or live call was tested for this guide.

Check URI parsing before changing address-completion policy

Use the PJSIP_PARSE_URI diagnostic to preserve the complete Request-URI, selected component and absence sentinel before rewriting digits or widening patterns.