Core engineering model
Find the response-generating hop first. Each decision must be verified against the deployed Asterisk version, peer requirements and packet evidence rather than copied as a universal setting.
Correlate Call-ID and CSeq across captures. Each decision must be verified against the deployed Asterisk version, peer requirements and packet evidence rather than copied as a universal setting.
Treat signaling success and media success independently. Each decision must be verified against the deployed Asterisk version, peer requirements and packet evidence rather than copied as a universal setting.
Guides in this cluster
SIP 403 Forbidden: How to Find Who Rejected the Call
Locate the hop that generated a 403, correlate the transaction and evaluate identity, authorization and policy evidence without assuming one universal cause.
GuideSIP 488 Not Acceptable Here: SDP and Codec Troubleshooting
Read the offer and answer, compare codecs and media security, and find the endpoint that could not accept the proposed session.
GuideSIP 503 Service Unavailable: Routing, Capacity and Upstream Diagnosis
Separate local routing, peer reachability, overload and upstream policy when a SIP transaction returns 503 Service Unavailable.
GuideHow to Debug SIP Calls with Asterisk, sngrep and tcpdump
Capture only what is needed, correlate a call across Asterisk and the network, protect sensitive headers and turn verbose logging back off.
Operational boundary
Troubleshooting is evidence correlation across transaction, dialog and media layers. The same status phrase can be generated locally, by the immediate peer or by a normalized downstream response. Preserve the original request, response source and Call-ID before interpreting a code.
Field workflow
State the directional symptom, record UTC time, place one controlled call, enable the narrowest logger, follow Call-ID and CSeq, identify the first divergent hop, then capture only the signaling or RTP needed to test that hypothesis. Turn debugging off promptly.
pjsip set logger on
# place one controlled call
pjsip set logger offVerification standard
A resolved case has a reproducible baseline, one bounded correction and an end-to-end retest. Document what changed, which direct observation changed with it, and whether signaling, media and release all passed. A new response code is new evidence, not automatic success.
Failure patterns
Avoid shotgun changes, uncontrolled retries, broad captures and comparing unrelated calls. Do not equate Registered with call admission, Available with media, a Q.850 translation with the original SIP cause, or a packet source with an internal policy owner.
Security and governance
Traces can expose digest material, telephone numbers, PAI, Identity tokens, SDP addresses and media. Limit access, redact before sharing, use short collection windows and apply retention policy. Never weaken TLS just to make tcpdump readable.
Hypothesis control and comparison tests
Write one hypothesis that predicts a specific observation at a specific boundary. If the hypothesis is “Asterisk advertises an unreachable media address,” the prediction is that SDP contains that address and the peer sends RTP toward it. A capture showing the correct address falsifies that hypothesis and should stop NAT option changes. This method keeps troubleshooting reversible.
A comparison call is useful only when policy-relevant variables are controlled: same route, transport, source identity class, destination class, codec/encryption profile and time window. Comparing a domestic authorized number on route A with an international number on route B does not isolate a cause. Record differences explicitly.
Close the case with a timeline, direct evidence, eliminated hypotheses, bounded correction, verification and rollback status. If the cause remains external, state the boundary observation and missing evidence. Avoid conclusions stronger than the capture point supports.
Operational assurance
Use stop conditions. If the required evidence is unavailable, do not compensate with riskier production changes. If one change fails its predicted observation, roll it back before the next hypothesis. If captures contain unexpected real traffic, stop and narrow the filter. Maintain a known-good baseline call with protected reference fields, but revalidate it after topology or policy change. Train escalation around reproducible evidence: what was sent, what returned, at which boundary, during which UTC interval, and which local conditions were verified.
Review cadence
Maintain sanitized known-good examples for INVITE, registration, SDP and RTP direction, tied to the current architecture version. They help identify the first divergence but must not contain reusable credentials or customer identifiers. Retire examples when transports, proxies or policy change. A stale baseline can mislead an investigation more effectively than having no baseline.
Exit criteria
End the investigation by turning off loggers and captures, restoring changed controls and checking disk use. Preserve only necessary evidence with access and retention labels. Document any remaining uncertainty so it is not later repeated as a verified root cause.
Readiness check
Measure diagnostic readiness before incidents: UTC synchronization, log retention, capture access, runbook ownership and escalation contacts. If a team cannot correlate one synthetic Call-ID across its boundary, address that observability gap before relying on the service for higher-volume or higher-risk traffic.