Asterisk PJSIP 403 Forbidden diagnosis

Identify the responder, method and rejected leg

Capture one failed exchange and record the 403 source and destination, Request-URI, Call-ID, CSeq method and number, top Via branch, To and From values, and any reason or warning fields. Establish whether Asterisk sent the response to an endpoint, received it from a registrar or provider, or passed a rejection from another SIP leg into local call handling.

RFC 3261 defines 403 as a server understanding a request and refusing to fulfill it; the same request should not be repeated unchanged. The code does not identify one universal bad-password, blocked-number, caller-ID or billing cause. Preserve the issuer's logs and account evidence before assigning one.

Separate authentication from authorization

A normal digest sequence begins with a 401 server challenge or 407 proxy challenge, followed by a new request carrying the appropriate authorization header. Asterisk documents inbound auth separately from outbound_auth, and recommends separate auth objects because realm handling differs. Compare the challenge realm, algorithm, username and the next request without exposing the secret.

A request can authenticate successfully and still lack permission for the requested registration, identity, destination or service. RFC 3261 specifically requires a registrar to return 403 when the authenticated user is not authorized to modify that address-of-record. Replacing a secret, disabling authentication or removing a policy does not test that distinction.

For inbound REGISTER, inspect the loaded AoR policy

When Asterisk is the registrar, bind the REGISTER to the identified endpoint, its inbound auth object and its associated AoR. Use read-only views such as pjsip show endpoint <name>, pjsip show auth <name>, pjsip show aor <name> and pjsip show contacts. The Asterisk troubleshooting guide documents two local 403 cases: an AoR without max_contacts, and an attempt that would exceed the configured maximum.

Preserve the CLI warning and current contacts. Decide whether the intended model is one contact, multiple contacts, or replacement of an existing contact before changing max_contacts or remove_existing. Raising a limit or evicting an active binding without that decision can hide a provisioning, duplicate-identity or device-replacement problem.

For outbound REGISTER, do not turn refusal into a retry loop

When Asterisk receives 403 from an external registrar, inspect pjsip show registrations, the exact client_uri, server_uri, selected transport, challenge sequence and provider account record. Asterisk documents 403 as a permanent failure by default. The optional forbidden_retry_interval can make chan_pjsip retry after that response, but the documentation warns that a non-zero value goes against RFC 3261's SHOULD NOT repeat guidance and exists for buggy registrars.

Do not enable periodic retries merely to make the status change. Correct a demonstrated account, address-of-record, realm, identity or provider-policy issue, then restart the registration state through the supported managed path and confirm a 200 response and the expected expiry.

For calls and other methods, compare one allowed control

For an INVITE, SUBSCRIBE, REFER or other method, preserve the exact rejected request and compare one known-allowed case from the same endpoint and route. Change only one dimension at a time: destination class, source account, asserted identity, time policy or method. A provider-issued 403 requires that provider's account or trace evidence; an Asterisk-issued 403 requires the matching endpoint, context, dialplan or application evidence.

Do not assume that inbound endpoint identification, digest identity, caller identity and authorization identity are interchangeable. Likewise, a successful REGISTER proves a binding and does not prove permission to place every call or use every identity.

Prove the narrow correction and preserve the denial case

Correct the identified policy or configuration in its authoritative system. On FreePBX, use the managed extension or trunk fields and Apply Config rather than editing generated PJSIP files. Retest the same method, route and identity, and also confirm that a deliberately unauthorized case remains rejected.

Enable PJSIP protocol logging only for the shortest useful capture, protect authorization headers and account identifiers, and remove or narrow it afterward. No PBX, endpoint, provider, account, password, realm, algorithm, registration, caller identity, destination policy or live-call behavior was tested for this guide.

On CompanyFlex, separate REGISTER Contact from INVITE identity

Deutsche Telekom's 1TR119 defines the CompanyFlex SIP-PBX interface. When a CompanyFlex 403 follows REGISTER, preserve the rejected REGISTER and compare its Request-URI, To, From, Contact user, transport, route and authorization identity with the current handoff. In Asterisk 22, the outbound-registration object's client_uri, server_uri, contact_user, transport, outbound_proxy and outbound_auth have separate roles. Do not change an endpoint's caller-ID fields to repair a rejected REGISTER.

When REGISTER succeeds but an INVITE receives 403, preserve the exact Request-URI and originating identity headers. The endpoint from_user and contact_user options affect outbound requests in different places, while channel caller identity can also drive the From value. 1TR119 says numbers in P-Preferred-Identity or P-Asserted-Identity that are not assigned to the SIP-PBX are rejected with 403. Prove which header and number the provider rejected before changing identity or dialplan policy.

Do not convert a CompanyFlex 403 into blind retry

Asterisk documents forbidden_retry_interval for an outbound registration but warns that a non-zero value goes against the SIP guidance not to repeat an unchanged forbidden request. First correct a demonstrated Contact, account, route, transport, authorization or assigned-identity mismatch in the system that owns it. On FreePBX, change the managed trunk or custom PJSIP fields and Apply Config rather than editing generated files.

Retain a before-and-after REGISTER or INVITE, the loaded registration and endpoint views, and a deliberately unauthorized identity that remains rejected. A 200 registration response does not prove that every CompanyFlex number is authorized for outbound presentation, and a successful call does not prove the registration Contact is correct after restart or expiry.

Map Asterisk PJSIP evidence to the Twilio transaction stage

When the carrier is Twilio, apply the provider-specific diagnostic to distinguish an initial source-address rejection from a credentialed retry failure and later caller-ID or permission policies.

Retain the request and responding hop without permanent tracing

The PJSIP History guide provides a bounded in-memory evidence path when the module is present and a short post-reproduction inspection is appropriate.