SIP Registration Errors

SIP registration is the first step in any CallMeter test or probe execution. Each endpoint must successfully REGISTER with its assigned SIP registrar before it can place or receive calls. When registration fails, the endpoint's outcome is set to REGISTRATION_FAILED and its phase advances to CLOSED.

This guide provides step-by-step diagnosis for every common registration failure scenario.

Using the SIP Message Trace

The SIP message trace is your primary diagnostic tool for registration failures. To access it:

1. Open the test run or probe execution that contains failed endpoints
2. Click on an endpoint showing REGISTRATION_FAILED outcome
3. Navigate to the SIP Trace tab
4. Look for the REGISTER request and examine the server's response

The response code, headers, and timing information in the trace identify the exact failure cause.

401 Unauthorized

The SIP registrar rejected the authentication credentials after the challenge-response exchange.

How SIP Authentication Works

SIP authentication is a two-step process:

1. The endpoint sends an initial REGISTER request without credentials
2. The registrar responds with 401 Unauthorized and includes a WWW-Authenticate header containing a challenge (realm, nonce, algorithm)
3. The endpoint re-sends the REGISTER request with an Authorization header containing the response to the challenge (computed from the username, password, realm, nonce, and other parameters)
4. If the credentials are correct, the registrar responds with 200 OK

A 401 in the SIP trace after step 3 (after the endpoint sent credentials) means the credentials were rejected.

Diagnosis Checklist

Verify the username

Check that the SIP account username in CallMeter exactly matches the username configured on the registrar. Common issues:

• Extra whitespace characters before or after the username
• Case sensitivity (some registrars are case-sensitive for usernames)
• The username should be the SIP user part only, not the full SIP URI (e.g., alice, not alice@example.com)

Verify the password

Re-enter the SIP account password in CallMeter. Passwords are stored securely and cannot be viewed after entry. Common issues:

• Copy-paste errors (leading/trailing whitespace, invisible characters)
• The password may have been changed on the registrar side
• Special characters that need escaping in some configurations

Check the authentication realm

Examine the WWW-Authenticate header in the 401 response from step 2 of the trace. The realm parameter identifies the authentication domain. Some registrars require the client to use this specific realm in the Authorization response. If the realm does not match what the endpoint is using, authentication will fail.

Check the authentication algorithm

The WWW-Authenticate header specifies the digest algorithm (typically MD5 or SHA-256). Verify that the endpoint and registrar agree on the algorithm. Most implementations default to MD5.

Check for account lockout

Many SIP registrars lock accounts after a configurable number of failed authentication attempts. If the account is locked:

1. Verify credentials are correct
2. Unlock the account on the registrar
3. Wait for the lockout period to expire

403 Forbidden

The registrar understood the request and the credentials may be valid, but access is denied. Unlike 401, re-sending with different credentials will not help.

Diagnosis Checklist

Check IP address restrictions

Many registrars maintain an allow list of IP addresses or networks that are permitted to register. The worker's public IP address may not be on this list.

1. Identify the worker's public IP address (visible on the Workers page for cloud workers)
2. Add the worker's IP to the registrar's allow list
3. For user-owned workers, check the public IP of the host machine (which may differ from the container's IP)

Check account status

The SIP account may be:

• Suspended or disabled on the registrar
• Expired (time-limited accounts)
• Exceeded its maximum concurrent registration count
• Restricted to specific User-Agent strings

Check rate limiting

Some registrars enforce rate limits on REGISTER requests per source IP or per account. A CallMeter test with many endpoints may exceed this limit.

1. Increase the buildup time to stagger registration attempts
2. Check the registrar's rate limit configuration
3. Consider using multiple source IPs (deploy workers on multiple hosts)

Check domain and SIP URI restrictions

Some registrars restrict registrations to specific domains or SIP URI patterns. Verify that the endpoint's SIP URI matches the registrar's expected format.

404 Not Found

The registrar indicates that the user or domain does not exist. The address is syntactically valid but there is no account matching it.

Diagnosis Checklist

Verify the registrar domain

The domain used in the SIP URI must match a domain that the registrar serves. If the registrar serves sip.example.com but your CallMeter registrar configuration uses pbx.example.com, the registrar may return 404.

Verify the SIP account username

The username must exist as an account on the registrar. Check for:

• Typos in the username
• The account may not have been created on the registrar
• The account may have been deleted

Check domain routing

If your SIP infrastructure has multiple domains, ensure the REGISTER request is being routed to the correct registrar. A SIP proxy may be routing the request to a server that does not host the target domain.

408 Request Timeout

The REGISTER request reached the registrar but no response was received within the timeout period. The registrar accepted the request but could not process it in time.

Diagnosis Checklist

Check registrar load

The most common cause of 408 is an overloaded registrar. When a CallMeter test sends hundreds of concurrent registration requests:

1. The registrar's request queue fills up
2. Processing time exceeds the SIP transaction timeout
3. Older requests in the queue expire before being processed

Resolution:

• Increase the buildup time to spread registrations over a longer period
• Reduce the total number of endpoints
• Check the registrar's performance metrics for CPU, memory, and database load during the test
• If the registrar has configurable worker threads or process limits, increase them

Check SIP proxy chain

If the REGISTER passes through one or more SIP proxies before reaching the registrar, any proxy in the chain can introduce delays:

1. Check each proxy for resource constraints
2. Check for slow DNS lookups at each hop
3. Reduce the number of proxies in the path if possible

Check network latency

High network latency between the worker and the registrar can push the total round-trip time (request, challenge, re-request, response) beyond the SIP transaction timeout:

1. Check the RTT between the worker and the registrar
2. Deploy workers closer to the registrar
3. Consider increasing the SIP transaction timeout if your infrastructure supports it

500 Server Internal Error

The registrar encountered an unhandled error while processing the REGISTER request.

Diagnosis

This is a server-side issue, not a CallMeter configuration problem. Investigate the registrar:

1. Check the registrar's application logs for error details
2. Check the registrar's database (user directory) for connectivity issues
3. Check for disk space, memory, or other resource issues on the registrar
4. If the error occurs only under load, it may indicate a scalability issue

503 Service Unavailable

The registrar is temporarily unable to process requests, typically due to overload or maintenance.

Diagnosis

1. Check if the registrar is in a maintenance window
2. Check the registrar's load metrics
3. If the error occurs during stress tests, it indicates the registrar has reached its capacity limit
4. The Retry-After header in the 503 response may indicate when to retry

Connection Timeout (No Response)

The endpoint sent a REGISTER request but received no response at all. The SIP trace shows the request being sent but no reply from the registrar.

Diagnosis Checklist

DNS resolution

1. Verify the registrar domain resolves to a valid IP address from the worker's network
2. For user-owned workers, check nslookup or dig output from the worker host
3. If using SRV records, verify the SRV record structure is correct
4. Check for DNS propagation issues if the registrar's IP was recently changed

Firewall and network connectivity

1. Verify the worker can reach the registrar's IP address on the configured port:
   • UDP: port 5060 (default SIP over UDP)
   • TCP: port 5060 (default SIP over TCP)
   • TLS: port 5061 (default SIP over TLS)
2. Check firewalls on both sides (worker network and registrar network)
3. For user-owned workers, check the Docker container's network configuration
4. Verify that outbound SIP traffic is not being blocked by corporate firewall rules

Transport protocol mismatch

If the test is configured for UDP but the registrar only accepts TCP (or vice versa), the request will never reach the SIP application:

1. Verify the transport protocol in the CallMeter registrar configuration
2. Check the registrar's transport configuration
3. Try the AUTO transport option, which uses DNS SRV/NAPTR discovery (RFC 3263) to determine the correct transport

TLS certificate issues (for SIP over TLS)

When using TLS transport:

1. Verify the registrar's TLS certificate is valid and not expired
2. Check that the certificate's Common Name or SAN matches the registrar domain
3. Verify the certificate chain is complete (intermediate certificates included)
4. Self-signed certificates may require specific configuration on the worker

Registration Succeeds Then Expires

Endpoints register successfully but their registration expires during the test, causing call failures.

Diagnosis

1. Check the registration expiry value. If it is too short, the registration may expire before the call phase begins.
2. Some registrars override the requested expiry with a shorter value. Check the Contact header in the 200 OK response for the actual granted expiry.
3. If the granted expiry is very short (e.g., 30 seconds), the endpoint may need to re-register during the test. CallMeter handles re-registration automatically, but a very short expiry creates additional load on the registrar.

Multi-Registrar Issues

When testing with multiple groups targeting different registrars, failures may be isolated to one registrar:

1. Check the endpoint outcome summary grouped by group
2. If one group shows high REGISTRATION_FAILED outcome rates while others succeed, the issue is specific to that group's registrar
3. Apply the relevant diagnosis from above to the failing registrar only

DNS Resolution Failures

DNS issues are one of the most common causes of "no response" registration failures. The worker cannot send a REGISTER request if it cannot resolve the registrar's hostname to an IP address.

Symptoms

• SIP trace shows the REGISTER request was never sent
• Connection timeout with no response at all
• Intermittent failures where some endpoints register and others do not (DNS round-robin with one dead server)

Diagnosis Steps

1. Check the hostname: Verify the registrar hostname is spelled correctly. A single character typo means DNS returns NXDOMAIN.
2. Check DNS from the worker's network: For user-owned workers, run dig or nslookup from the Docker host. Corporate DNS servers may not resolve external domains (or vice versa).
3. Check SRV records: SIP uses DNS SRV records (RFC 3263) for service discovery. Verify that _sip._udp.example.com (or the appropriate transport variant) exists and points to the correct host and port.
4. Check DNS propagation: If the registrar's IP was recently changed, caches may still return the old IP. Wait for the TTL to expire or flush the DNS cache.
5. Check for split DNS: Different internal vs external DNS views may resolve the hostname to different IPs. Ensure the worker's DNS view resolves to the correct registrar IP.

TLS Certificate Issues

When using SIP over TLS (SIPS, port 5061), the TLS handshake must complete before any SIP messages are exchanged. Certificate problems cause the handshake to fail silently from the SIP perspective (no SIP response, because the connection was never established).

Symptoms

• Registration works on UDP or TCP but fails on TLS with connection timeout
• No SIP trace at all (the TLS handshake fails before SIP traffic begins)

Common Certificate Problems

Expired certificate: The certificate has passed its expiration date. Check with openssl s_client -connect registrar.example.com:5061 from the worker's network.

Certificate name mismatch: The CN or SAN in the certificate does not match the registrar hostname in CallMeter. For example, the certificate is for sip.example.com but CallMeter connects to pbx.example.com. Use the hostname that matches the certificate.

Incomplete certificate chain: The registrar presents the leaf certificate but not the intermediates needed to chain to a trusted root CA. Configure the registrar to serve the full chain.

Self-signed certificate: Not trusted by default. Contact the CallMeter team for guidance on custom CA trust configuration for user-owned workers.

SIP Account Lockout and Rate Limiting

Many production SIP registrars implement security measures that can block legitimate test traffic if not anticipated.

Account Lockout

SIP registrars commonly lock accounts after a configurable number of consecutive failed authentication attempts (typically 3-10 attempts). In a CallMeter test, a single wrong password can lock out all accounts in the pool within seconds because multiple endpoints attempt to register with the same credentials simultaneously.

Prevention: Always verify credentials with a single-endpoint test before running a large test. If you change a password on the registrar, update it in CallMeter immediately. Ask your registrar administrator what the lockout threshold and duration are.

Recovery: Unlock the accounts on the registrar (or wait for the lockout period to expire), fix the credentials in CallMeter, verify with a single-endpoint test, then run the full test.

IP-Based Rate Limiting

Some registrars limit the number of REGISTER requests from a single source IP within a time window. A test with hundreds of endpoints on a single worker sends all requests from one IP.

Symptoms:

• First batch of endpoints registers successfully, subsequent batches receive 403 or 503
• The number of successful registrations is consistent across test runs (matches the rate limit threshold)

Resolution:

1. Increase the buildup time to spread registrations over a longer window
2. Deploy multiple workers (each with a different IP) and distribute endpoints across them
3. Ask the registrar administrator to whitelist the worker's IP from rate limiting during testing
4. If the registrar returns a Retry-After header with 503 responses, the value tells you how long to wait

REGISTER Flood Protection

Enterprise SBCs often have flood protection that blackholes all SIP traffic from an IP that sends too many REGISTER requests in a short window (often banning the IP for 5-30 minutes). If registration works for small tests but completely fails for large tests, and even single-endpoint tests fail for several minutes after a large test, check the SBC's blacklist for the worker's IP. Whitelist the worker's IP in the SBC's flood protection rules, or use a longer buildup time to stay below the threshold.

Systematic Registration Debugging

If none of the above scenarios match your situation, follow this systematic approach:

1. Single endpoint test: Create a test with one endpoint, one SIP account, and minimal configuration. If this succeeds, the issue is load-related.
2. Manual SIP test: If possible, test the SIP account with a standard SIP client (softphone) from the same network. If the softphone registers, the issue may be specific to the worker or CallMeter configuration.
3. SIP trace analysis: Compare the SIP message trace from a failing endpoint with the expected message flow. Look for unexpected headers, modified URIs, or missing fields.
4. Incremental load: Start with 10 endpoints and increase gradually. Note the threshold at which failures begin to identify capacity limits.

Related Pages

• SIP Response Codes -- Full response code reference
• Common Test Failures -- Other failure types
• Adding a Registrar -- Registrar configuration
• SIP Accounts -- Account management
• Transport Protocols -- Protocol selection