Asterisk PJSIP receives SIP 422 Session Interval Too Small

Bind 422 to the exact session-refresh transaction

Capture the rejected INVITE or UPDATE, its Session-Expires and Min-SE headers, the Supported or Require: timer option, the 422 response and its mandatory Min-SE. Record the Call-ID, tags, CSeq, request direction, responding address and PJSIP channel. SIP 422 says that the proposed session interval was below the responder's minimum; it does not identify a codec, RTP, registration or NAT failure by itself.

Separate an initial INVITE rejection from an in-dialog re-INVITE or UPDATE rejection. If no dialog exists yet, a corrected request is a new transaction for the same attempted session. Inside a dialog, preserve which participant was the current refresher and which request failed. Do not read a registration Expires header as Session-Expires; use the 423 investigation for a REGISTER lifetime rejection.

Identify which Asterisk endpoint and leg supplied the policy

Asterisk is a back-to-back user agent, so the endpoint object and timer policy can differ on its phone-facing and trunk-facing channels. Inspect the channel and exact loaded endpoint with pjsip show endpoint <name>, then compare the displayed session-timer values with the wire request. A 422 received from a carrier does not prove that the internal phone proposed the same interval, and a 422 generated toward a phone does not prove that the carrier leg was rejected.

In Asterisk's current reference, timers controls session-timer use, timers_min_se is the minimum expiration period and timers_sess_expires is the maximum. The documented defaults are respectively yes, 90 and 1800 seconds, but the loaded endpoint and actual messages are the evidence for this incident.

Verify the RFC retry rather than repeating the failed request

RFC 4028 allows the user agent client to retry after 422. The corrected request is a new transaction with an incremented CSeq and must retain the largest applicable Min-SE learned for that attempt or dialog. Its Session-Expires cannot be lower than that bound. Distinguish this retry from a retransmission of the original transaction; identical CSeq and branch evidence usually points to transport retransmission rather than negotiated correction.

If Asterisk repeatedly sends the same unacceptable value, confirm the intended endpoint loaded and that the call used it. In FreePBX, identify the supported setting owner, apply the generated configuration and inspect the running endpoint; do not edit generated files as a durable repair. Change one timer policy at a time and preserve the other call leg.

Do not disable timers before establishing the dependency

Turning session timers off can hide the initial negotiation while removing a peer or intermediary's stale-session detection requirement. Likewise, lowering a responder's minimum may increase refresh frequency and signaling load. Align the affected leg with documented provider, endpoint and intermediary policy after identifying who returned Min-SE; do not apply a global minimum from one trunk to unrelated devices.

Keep session timers separate from registration refresh, OPTIONS qualification, RTP timeout, transaction timers and ordinary re-INVITEs for codec or hold changes. Their clocks and failure consequences differ even when values happen to match. Use a bounded PJSIP logger capture and redact addresses, identities and authorization material before sharing it.

Prove establishment, negotiated role and later refresh

After one controlled change, capture the corrected request and successful final response. Record the accepted Session-Expires interval and refresher parameter separately on each Asterisk leg. Keep the call active long enough to observe the designated UA send a re-INVITE or UPDATE and receive a successful response; confirm media continues and ordinary BYE handling still works. Removing the first 422 does not prove the scheduled refresh will traverse the same route.

Retest representative inbound and outbound calls, because endpoint selection and policy can differ by direction. Restore the prior setting if the expected negotiation or refresh fails. No PBX, endpoint, provider, proxy, timer policy, retry, refresh, media path or live call was tested for this guide.

Continue beyond an accepted retry

Clearing the initial 422 proves only that a proposed interval was accepted. The Asterisk session-timer guide follows the named refresher and later request; use the drop diagnostic when the call still ends at refresh time.