Asterisk PJSIP receives SIP 481 for an in-dialog request

Identify the rejected method and SIP leg

Capture the complete exchange containing 481 and preserve the method, request URI, response direction, Call-ID, From tag, To tag, CSeq, Route set and responding address. RFC 3261 defines 481 as a request that matches no existing dialog or transaction. That status does not identify whether Asterisk, a phone, an SBC or a remote service lost or rejected the state.

Asterisk acts as a back-to-back user agent and can maintain independent dialogs on its endpoint and trunk legs. Follow the leg that actually received 481 instead of searching for one end-to-end Call-ID. Record the user-visible symptom separately: a late BYE, failed hold refresh and failed attended transfer have different operational impact.

Match the complete dialog identity

A SIP dialog is identified by Call-ID plus the local and remote tags. Compare those three values in the failing request with the original INVITE and the response that established that same leg. Then check CSeq and the stored route and remote target. A matching Call-ID alone is insufficient, especially after forking or transfer.

Use a narrowly timed pjsip set logger on trace and the Asterisk log correlation identifier for the incident. Asterisk's channel identifier can group related internal events, while ${CHANNEL(pjsip,call-id)} can expose the SIP Call-ID for a PJSIP channel. These identifiers solve different correlation problems; do not equate them.

Test state loss and request routing

RFC 3261 identifies a restart, a request delivered to a different failed-system replacement and simple misrouting as possible reasons that a tagged request finds no matching dialog. Check whether Asterisk, an SBC, a proxy or a clustered peer restarted or changed ownership during the call. Compare the route followed by the initial dialog-establishing exchange with the failing mid-dialog request.

Do not create an extension or broaden a trunk route to recreate missing dialog state. If a load balancer or failover path sends in-dialog traffic to a node without the dialog, repair the state-affinity or recovery design. If the original call had already ended, classify a delayed request or retransmission separately from a reproducible live-call failure.

Interpret the method-specific result

For a BYE, RFC 3261 says a receiver that finds no matching dialog should return 481; the sender then treats the session and dialog as terminated. A 481 to a re-INVITE is a stronger mid-call state-loss signal than an isolated cleanup request after teardown. Preserve the earlier signaling before deciding whether media, hold or session refresh was affected.

Do not tune SIP timers or registration intervals merely because the event occurred late in a call. Demonstrate the missing dialog, misrouted request or process transition first. A 481 is not the same failure as a 491 overlapping-request collision.

Preserve transfer and Replaces relationships

An attended transfer can introduce a consultation call, a REFER and a new INVITE carrying a Replaces reference. Asterisk documents that Replaces identifies a dialog by Call-ID and both tags, and that the referenced dialog may live on another server. Keep the original dialog, consultation leg, REFER, Replaces values and replacement INVITE together.

A missing referenced dialog is not repaired by changing the called extension alone. Follow the REFER transfer investigation to separate request acceptance, the replacement call and its final notification. Review Asterisk's external_replaces path only when the trace demonstrates a remote attended-transfer scenario.

Validate recovery without hiding the evidence

Make one controlled correction, then repeat the exact action that produced 481 and a normal answer/hangup path. For transfer incidents, test blind and attended transfer separately. For a clustered path, confirm that established-dialog requests continue to reach an owner that can process them during the intended failure scenario.

Disable extra protocol logging after the bounded reproduction. SIP traces and logs can contain credentials, network addresses and personal calling data; redact shared extracts without removing the identifiers needed to correlate the dialog. No PBX, endpoint, proxy, cluster, transfer or live-call behavior was tested for this guide.

Use dialog identifiers before filtering a 481 exchange

The PJSIP History diagnostic keeps Call-ID, tags, CSeq, branch, direction and separate back-to-back legs attached to the observed messages.