Bind 425 to one MESSAGE and PJSIP leg
Record the timestamp and timezone, generating sensor or application, Request-URI, Asterisk endpoint or trunk, Call-ID, CSeq, top Via branch, Call-Info, Geolocation, Content-Type, Content-Length, MIME boundaries, responder and complete AlertMsg-Error. Determine whether Asterisk generated 425 for an inbound MESSAGE or received it on an outbound leg. Do not assign the rejection to a CAP document, Asterisk or the emergency-services peer from a dashboard label alone.
With authorization, use pjsip set logger on only for one bounded integration-lab reproduction, then disable it and protect identities, credentials, location and alert bodies. Do not reproduce against a production PSAP or send an uncoordinated emergency alert.
Prove the profile before editing headers
Confirm the failed request is the RFC 8876 non-interactive profile: SIP MESSAGE, no interactive media session, and Call-Info with purpose EmergencyCallData.cap. An INVITE, an Alert-Info ringtone reference or an ordinary text MESSAGE is a different protocol problem. Preserve the Request-URI and routing owner because an aggregator, emergency-services routing proxy or PSAP can reject different legs.
Asterisk's PJSIP_HEADER() can read headers on an inbound PJSIP channel and add, update or remove headers on an outbound channel. It does not establish that Asterisk validates CAP. In normal dialplan execution it acts on the incoming channel; outbound changes belong in a pre-dial handler. Do not repair 425 by injecting Call-Info on the wrong leg.
Walk Call-Info to the exact CAP bytes
For by-value delivery, match the Call-Info CID to Content-ID, require the CAP MIME type, and preserve multipart boundaries, transfer encoding and the exact XML bytes. For by-reference delivery, retain the URI, transport, authorization and retrieval outcome. Keep the CAP block separate from PIDF-LO and proprietary sensor data.
Use the peer's numeric error to choose the next check: general processing for 100, missing or unresolved payload for 101, insufficient alert purpose for 102, and corrupted payload for 103. Validate CAP against the agreed profile and integrator requirements without inventing fields or converting a failed reference into guessed alert content.
Separate peer acceptance from alert acceptance
A 200 response can include AlertMsg-Error when useful request information was accepted but the CAP alert was bad. Conversely, 425 means the responder could not determine a reasonable emergency response from any usable information. Preserve the final SIP response and AlertMsg-Error independently rather than reducing both to MESSAGE success or failure.
Keep 415 media-format refusal, 501 unsupported method or function and 500 server processing failure separate. If Asterisk or another back-to-back user agent originates a new MESSAGE, compare each leg's Call-Info, MIME body and response instead of assuming transparent forwarding.
Correct in a lab and verify the integration contract
Correct only the demonstrated owner: the generating application, CID or MIME assembly, URI hosting and retrieval, CAP profile content, Asterisk dialplan transformation or peer integration rule. Preserve the original message, prior configuration and rollback trigger. Do not loop automatic retries; RFC 8876 notes that SIP has no standardized rate limiting and automated alerts commonly involve a human call-taker.
Use the emergency-services integrator's current lab or approved non-live acceptance path. Confirm the outbound MESSAGE bytes, exact peer response, any AlertMsg-Error, monitoring and operational escalation without sending a production emergency alert. No sensor, aggregator, PBX, proxy, PSAP, CAP payload, emergency route or live alert was tested for this guide.
pjsip show endpoint <endpoint>
pjsip set logger on
# Reproduce one authorized lab MESSAGE and capture Call-Info, MIME, 425 and AlertMsg-Error.
pjsip set logger offSources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 8876: Non-interactive Emergency Calls ↗
- IANA SIP response and AlertMsg-Error registries ↗
- Asterisk PJSIP_HEADER dialplan function ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk collecting debug information ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.