Read 425 inside the non-interactive emergency profile
RFC 8876 defines 425 Bad Alert Message for a request whose CAP alert is malformed enough that no reasonable emergency response can be determined. Its defined transport is a SIP MESSAGE carrying a CAP alert for a non-interactive emergency call, without a SIP dialog or negotiated interactive media. Preserve the request method and Request-URI, sender, Call-ID, CSeq, top Via branch, Call-Info, Geolocation, Content-Type, MIME boundaries, response source and timestamp on the exact leg.
Do not confuse this code with HTTP 425, Alert-Info ring rendering, an ordinary instant-message body or an INVITE media failure. RFC 8876 does not define this CAP transport for other SIP transactions.
Resolve the CAP alert by value or by reference
The Call-Info value uses purpose EmergencyCallData.cap. It can point by CID to a MIME part of type application/emergencyCallData.cap+xml, or by URI to CAP data retrieved by the recipient. Match every CID, Content-ID and MIME boundary exactly, or retain the URI and retrieval result. Keep the CAP alert separate from PIDF-LO location and any additional sensor-specific data blocks.
Code 101 means the alert payload was absent or could not be found, which can identify a broken CID, missing part or unavailable reference without proving the CAP document itself was corrupt. For large data, RFC 8876 recommends HTTPS by-reference delivery rather than placing tens of kilobytes in MESSAGE; that does not authorize an arbitrary public URL or bypass retrieval security.
Use the registered AlertMsg-Error code
Every 425 response must include AlertMsg-Error, and the header contains only one error value. The initial codes are 100 cannot process the alert payload, 101 payload absent or not found, 102 insufficient information to determine the alert's purpose and 103 corrupted alert payload. The optional text is human-readable and operator-changeable; the numeric meaning is the stable boundary.
A responder can accept a useful MESSAGE with 200 while still returning AlertMsg-Error. A 425 is appropriate only when no other request information is usable for a reasonable emergency response and must not be sent when the request contains no CAP alert at all. Do not treat absence of 425 as proof that the alert was fully processed.
Keep nearby failures and transaction state separate
Use 501 when the server does not support the method or required function, 415 when it refuses the request body's media type or encoding and 500 when it cannot or chooses not to process the alert for another server reason. A 425 finalizes this transaction but must not terminate an existing dialog. AlertMsg-Error in a provisional response follows reliable-provisional-response rules or is repeated in the final response.
Correct only the demonstrated CAP, reference or processing owner, and validate through the responsible emergency-services integrator's approved non-live procedure. Do not generate an uncoordinated sensor alert or emergency MESSAGE toward a production PSAP. The Asterisk PJSIP investigation preserves body and header evidence without implying native CAP validation or deployed emergency acceptance.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.