What a SIP 403 establishes
A 403 Forbidden means the responding SIP hop understood the request and refused it. It does not, by itself, reveal whether the refusal concerns authentication, caller identity, destination policy, STIR/SHAKEN treatment, account state or another rule. Find the response source and correlate the exact INVITE before changing configuration.
Preserve the rejected INVITE
INVITE sip:+12025550123@sip.example.net SIP/2.0
Via: SIP/2.0/UDP 198.51.100.20:5060;branch=z9hG4bK-403a
From: <sip:+12025550123@example.com>;tag=from403
To: <sip:+12025550123@sip.example.net>
Call-ID: call-403-001@example.com
CSeq: 101 INVITE
Contact: <sip:pbx@198.51.100.20:5060>
P-Asserted-Identity: <sip:+12025550123@example.com>
Content-Type: application/sdpRequest-URI identifies the requested destination at this hop. From is dialog identity, Contact describes a signaling target, and P-Asserted-Identity is meaningful only inside an agreed trust domain. Call-ID binds the dialog; CSeq identifies this INVITE transaction; the Via branch links the response. Redact user parts and Identity tokens when sharing.
Read the response and Reason separately
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 198.51.100.20:5060;branch=z9hG4bK-403a
From: <sip:+12025550123@example.com>;tag=from403
To: <sip:+12025550123@sip.example.net>;tag=peer403
Call-ID: call-403-001@example.com
CSeq: 101 INVITE
Reason: Q.850;cause=21;text="Call rejected"
Content-Length: 0The matching Via branch, Call-ID and CSeq show that the response belongs to the preserved INVITE. Q.850 cause 21 offers additional “call rejected” context but still does not identify the business rule. A response received from 203.0.113.10 proves that address supplied it to this capture point; it does not prove which internal component made the decision.
Attribute the first rejecting hop
sudo tcpdump -ni any host 203.0.113.10 and port 5060
asterisk -rvvv
pjsip set logger on
# one controlled test
pjsip set logger offCompare packet source, top Via, Record-Route, received/rport parameters and configured outbound proxy. A locally generated 403 appears in Asterisk logs before any outbound response from a peer. An upstream 403 arrives as a network packet. If a proxy normalizes downstream errors, escalation requires that proxy’s protected correlation record.
Test competing explanations
| Possible layer | Evidence required | Do not infer from 403 alone |
|---|---|---|
| Authentication/authorization | Challenge history, authenticated retry, realm and account policy. | That any password is wrong. |
| Caller identity | Approved CLI/PAI format and authorization record. | That From and PAI must always match. |
| Destination policy | Exact Request-URI and allowed destination class. | That the destination is globally invalid. |
| STIR/SHAKEN policy | Identity presence/verification result and documented policy. | That a missing Identity header universally causes 403. |
| Account state | Authorized service record and timestamped platform evidence. | That balance or suspension is the cause. |
| Source/IP policy | Observed source and approved interconnection addresses. | That DNS or NAT is necessarily wrong. |
Correlate in Asterisk
sudo asterisk -rx "pjsip show endpoint carrier-endpoint"
sudo asterisk -rx "pjsip show registrations"
sudo grep -F 'call-403-001@example.com' /var/log/asterisk/fullEveryone is busy/congested at this time (1:0/0/1)
DIALSTATUS=CHANUNAVAIL
HANGUPCAUSE=21
# Illustrative local channel outcome; preserve the SIP response too.DIALSTATUS and HANGUPCAUSE describe Asterisk’s channel outcome and translation; retain the original SIP response because mappings can lose detail. Registration success does not prove INVITE admission. Endpoint availability proves OPTIONS reachability only.
Do not assume
Verify a resolved 403
Repeat the same authorized destination and identity after one bounded change. Confirm the INVITE reaches the same hop, no 403 returns for the same reason, progress and answer messages occur as expected, and two-way media works. A different final response is new evidence, not necessarily success. Record the change, approval and rollback point.
Rollback
If the bounded change does not alter the responsible evidence, restore the prior caller identity, auth, routing or source policy. Turn off PJSIP logging and stop packet capture. Preserve sanitized Call-ID evidence for escalation, and remove sensitive temporary traces according to retention policy.
Related engineering resources
Build a defensible 403 escalation record
A useful escalation states the UTC timestamp, sanitized source and destination, Call-ID, selected route, immediate 403 source, whether a challenge preceded the INVITE, and whether From, PAI and any Identity header were present. Include the exact Reason value without claiming it is authoritative beyond the responding hop. Note a known-good comparison only when it used the same route and policy-relevant identity.
Exclude passwords, digest responses, full PASSporT tokens and unrelated calls. Ask the responsible team to identify the policy category and correlation record for that transaction. If the response was locally generated, inspect dialplan authorization and endpoint selection before contacting an upstream party. This evidence boundary shortens resolution and avoids unsafe trial changes.
Use controlled comparisons
Compare the failed call with a known-good call only when route, account, source address, transport, caller-identity authorization and destination class are equivalent. Change one variable—such as the authorized test destination—and preserve both transactions. If the response source and policy outcome change, that is evidence; if multiple variables changed, the comparison cannot isolate the rule.
When the 403 follows an authentication challenge, inspect whether the authenticated INVITE was actually sent and whether the rejecting hop is the challenger. When no challenge appears, do not invent a credential problem. Similarly, Identity absence becomes relevant only when the receiving policy and obligation for that call are established.
Security impact of 403 troubleshooting
Broadening an identify match, removing PAI, weakening caller-ID authorization or cycling credentials can expose fraud and does not prove the response cause. Keep the original trust boundary and test with an approved identity. If a temporary exception is authorized, give it an owner, expiry, monitoring condition and explicit reverse procedure.
Authoritative references
Implementation closure
Rejected INVITE, complete 403 response, immediate source hop, Call-ID/CSeq, account state, authorized identity and destination policy.
Only the policy, credentials, identity, or route proven responsible; a 403 investigation does not justify broad configuration changes.
Correct the identified input or rule, use the system-specific safe apply mechanism, and place one controlled comparison call.
The same request intent reaches the expected next state without a 403 from the previously rejecting hop.
Preserve the new response and compare source hop, Reason/Q.850, authentication, identity, destination, and account evidence.
Stop if the rejecting hop is unknown, identity authorization is unverified, or repeated tests could trigger fraud controls or rate limits.
The generating hop and rule are documented, a controlled call verifies the correction, and no identity or security control was bypassed.