Bind 429 to the protocol before interpreting the phrase
IANA registers SIP response code 429 as Provide Referrer Identity, with RFC 3892 as its defining reference. HTTP also has a 429 number, but RFC 6585 defines that HTTP status as Too Many Requests. The shared number does not give the two protocols a shared meaning.
Preserve the complete response start line, transport, sender, request method, Call-ID and CSeq. SIP/2.0 429 Provide Referrer Identity and HTTP/1.1 429 Too Many Requests belong to different registries and state machines. A dashboard that shows only 429 has removed decisive evidence.
Follow the registered SIP meaning through REFER
RFC 3892 defines 429 for a referee or refer target that requires a valid Referred-By token. A referee can return it directly to a REFER. A refer target can return it to the request triggered by the referral, after which the referee reports that result to the referrer in a NOTIFY carrying a message/sipfrag body.
Capture the REFER, Referred-By header, token body, triggered request and NOTIFY sequence. The response is about referrer-identity evidence and admission policy, not a general authentication challenge and not proof that a call-transfer feature is unsupported.
Validate the identity evidence without inventing it
RFC 3892 permits 429 when the Referred-By token is absent, stale or invalid under the receiving policy and requires an invalid token to be rejected. A new REFER with a valid token can be attempted when the participating implementations support the mechanism.
Do not fabricate a Referred-By token, copy one from an unrelated referral, remove transfer security policy or treat ordinary From identity as an equivalent repair. The RFC's S/MIME-based token, covered fields, signing identity, date and target relationship have their own validation rules.
Recognize a provider-local conflicting use
Some services reuse SIP code 429 with the HTTP-style phrase Too Many Requests. Skyetel's current registration guide is one documented example: it says REGISTER attempts more frequent than 100 seconds cause the PBX to be blocked and produce 429 - Too Many Requests, while registrations expire automatically after 300 seconds. That is a provider-specific interface rule, not the registered SIP meaning.
Use the provider's current documentation and the exact method, reason phrase and responding system. Do not apply Skyetel's interval, phrase or block behavior to another carrier, and do not redirect an over-frequent REGISTER investigation into REFER token handling merely because the number is 429.
Treat Asterisk registration state as observed behavior
Asterisk's current outbound-registration guide lists no response, 408, 500, 502, 503, 504 and any 600-class response as temporary. It says unlisted responses are treated as permanent, apart from the documented 403 retry option. SIP 429 is not in that temporary list.
Confirm the installed branch and preserve the actual PJSIP trace, loaded registration, status and NextReg before changing a timer. Do not assume that a provider's Too Many Requests phrase makes Asterisk honor an HTTP Retry-After rule or schedule a SIP retry. Use the focused diagnostic for the provider-conflict branch.
Retest the correct state machine
For registered SIP 429, retest the referral with supported valid identity evidence and confirm both REFER acceptance and the triggered request's final result. For a documented provider registration throttle, stop duplicate registrars or an excessive refresh schedule, wait through the provider-authorized recovery window and observe one bounded REGISTER cycle.
Keep registration refresh, INVITE calls per second, simultaneous channels, authentication, number routing and service availability as separate quantities. No provider policy, referral, token, registration, retry or call was tested for this reference.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IANA SIP response-code registry ↗
- IETF RFC 3892: SIP Referred-By and 429 Provide Referrer Identity ↗
- IETF RFC 6585: HTTP 429 Too Many Requests ↗
- Skyetel SIP Registration limitations ↗
- Asterisk outbound-registration failure handling ↗
- Asterisk debug-information collection guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.