VoIP.infoThe independent guide to business communications.
VoIP.info Diagnostic

A provider returns SIP 429 Too Many Requests

Preserve the method, reason phrase and responder, then separate a provider-local registration throttle from SIP 429's registered referrer-identity meaning.

Reviewed 2026-10-08IANA's SIP response-code registry, RFC 3892, RFC 6585, Skyetel's current SIP Registration limitations and Asterisk's current outbound-registration and diagnostic guidance were reviewed October 8, 2026; no provider account, PBX, registration object, referral, token, credential, request rate, response, retry timer, availability result or call was inspected or testedAdvancedDocumentation based · not lab tested

Capture the full protocol event, not the number

Collect one bounded exchange with the response start line, request method, Request-URI, Call-ID, CSeq, Via branch, source and destination, timestamp, transport and all response headers. State whether the response followed REGISTER, REFER, INVITE or another method and which provider, proxy, PBX or endpoint sent it. Protect credentials and personal calling data.

Confirm that the message is SIP rather than an HTTP management or API response. A portal, REST client and SIP logger can all display 429, but their recovery rules are not interchangeable. A customized reason phrase is evidence about that responder's implementation, not a new IETF registration.

Check the registered SIP meaning before using a rate-limit remedy

The IANA SIP registry assigns 429 to Provide Referrer Identity, defined by RFC 3892 for a missing, stale or invalid Referred-By token around REFER and its triggered request. If the exchange belongs to that flow, retain the REFER, token, triggered request and NOTIFY sipfrag and follow the SIP 429 reference.

Do not insert arbitrary delays, raise channel capacity or edit registration timing when the responder is asking for referral identity. Conversely, a provider-local Too Many Requests response to REGISTER is not repaired by manufacturing a Referred-By header or token.

For REGISTER, identify the provider's exact local rule

Obtain the current provider handoff or support record for the selected account. Determine whether the limit applies to one credential, source address, registrar, region, account or platform and whether it measures initial REGISTER attempts, authenticated retries, refreshes or failed challenges. Record the permitted interval, binding expiry, block duration, recovery process and whether a Retry-After header is actually present.

Skyetel currently documents a minimum 100-second registration interval and 300-second automatic expiry, with a 429 - Too Many Requests error when REGISTER is too frequent. Use those values only for the documented Skyetel registration interface. They do not define SIP-wide behavior or another account's current policy.

Find duplicate or prematurely scheduled registrars

Compare every system using the credential with the provider rule: active and standby PBXs, restored virtual machines, SBCs, test instances, high-availability peers and any device incorrectly given trunk credentials. Correlate the provider's count window with challenge/retry pairs, refreshes, reboot bursts, DNS targets and failover transitions.

One registration object's configured expiration is not necessarily its transmitted refresh cadence, and multiple clients can make individually reasonable timers exceed a shared limit. Stop only the unauthorized or duplicate owner; do not rotate a valid secret, shorten expiry or increase retry frequency to chase a rate-limit rejection.

Read Asterisk's loaded registration and retry classification

On an owned Asterisk system, preserve a short PJSIP trace plus pjsip show registrations and the detail for the affected registration. Record the loaded server URI, client URI, expiration, retry interval, maximum retries, status and NextReg. Use the supported configuration owner rather than editing generated files.

Asterisk's current guide says responses outside its temporary list are treated as permanent, and 429 is not in that list. Confirm the installed branch and observed state instead of assuming automatic backoff. Do not make an unlisted response retry aggressively: first correct the provider-documented cadence or duplicate-client condition, then use the supported lifecycle to re-establish the registration.

Keep request rate, call rate and concurrency separate

A registration refresh limit does not establish INVITE calls per second or simultaneous-channel capacity. Skyetel's same page documents those as separate limits: one outbound call per second and 100 concurrent outbound calls per region for its registration service. Preserve each metric's direction, region, credential scope and enforcement response.

After the documented recovery window, observe one authorized REGISTER cycle, the expected binding lifetime and at least one later refresh without another 429. Confirm inbound and outbound call service separately under the provider's approved test plan. No account, PBX, registration, request rate, channel limit, response, recovery or live call was tested for this diagnostic.

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.

Continue your research

SIP response reference · IANA's SIP response-code registry, RFC 3892, RFC 6585, Skyetel's current SIP Registration limitations and Asterisk's current outbound-registration and diagnostic guidance were reviewed October 8, 2026; no provider account, PBX, registration object, referral, token, credential, request rate, response, retry timer, availability result or call was inspected or tested

SIP 429 Provide Referrer Identity

The registered SIP 429 asks for valid referrer identity; it is not HTTP 429 Too Many Requests, even when a provider reuses the number for a local registration policy.

Read guide →
Troubleshooting · RFC 3261 and current Asterisk res_pjsip registrar, authentication, outbound-registration and troubleshooting documentation reviewed October 5, 2026; no endpoint, PBX, registrar, binding, transport, packet path or call was inspected or tested

SIP registration loops after an apparent success

Classify normal refresh, repeated authentication, binding replacement, transport restart and outbound-registration retry before changing timers.

Read guide →
Guide · Asterisk 22 LTS

Asterisk outbound registration: what it proves

Distinguish a carrier registration from endpoint configuration and successful incoming or outgoing calls.

Read guide →
Troubleshooting · Asterisk 22 LTS documentation reviewed September 26, 2026; verify options on the installed branch

Asterisk outbound registration stopped retrying

Separate an unloaded registration, a temporary failure and a permanent rejection before changing retry policy.

Read guide →
Provider research · First-party public documentation reviewed September 30, 2026; no account, endpoint, call, rate deck or support response was tested

Skyetel SIP Trunking: endpoint groups, registration and failover research

Keep IP-group delivery, credential registration, failover handling, emergency identity and unverified service claims separate.

Read guide →
Guide · Operational guidance; Asterisk 22 / FreePBX 17 where applicable

SIP scanning, failed registration and rate limits

Distinguish routine authentication challenges from abuse and contain bursts without locking out a site.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP REFER and transfers: acceptance versus completion

Follow transfer requests and their outcome notifications without assuming a 202 response means the transfer succeeded.

Read guide →
Troubleshooting · RFC 3515, RFC 5589 and current Asterisk transfer documentation reviewed October 5, 2026; the September 16, 2026 Asterisk issue is an open single-environment report, not a reproduced or universal defect

SIP REFER transfer accepted but the call does not connect

Trace the actual transfer mechanism, REFER authorization, accepted request, notification subscription, referred call leg, attended-dialog replacement and final bridge separately.

Read guide →