Endpoint Lifecycle

Each SIP endpoint in a CallMeter test run or probe execution is tracked by two orthogonal fields: phase (where it is in the call lifecycle) and outcome (how it ended). This dual model replaces the previous single-status approach, providing clearer diagnostics and eliminating ambiguity between progression and result.

Endpoint phase and outcome are visible in real time during test execution on the test run detail page, and are recorded for post-run analysis.

The Dual Model

Phase (endpointPhase)

The phase represents the endpoint's current position in the SIP call lifecycle. Phases advance forward only -- an endpoint never moves backward. There are 8 phases in strict order:

INITIALIZING --> REGISTERED --> CALLING --> RINGING --> NEGOTIATING --> INCALL --> DISCONNECTING --> CLOSED

Outcome (endpointOutcome)

The outcome represents the terminal result of the endpoint's lifecycle. It is nullable (not set until the endpoint completes) and follows set-once semantics with severity priority: once set, it can only be overwritten by a higher-severity outcome. There are 8 possible outcomes:

Severity priority rule: An outcome with severity 10 (error) cannot be overwritten by one with severity 0 (success). If an endpoint encounters a teardown error after a successful call, the outcome is TEARDOWN_ERROR, not SUCCESS.

Auto-set rule: When an endpoint reaches the CLOSED phase with no prior outcome set, the platform automatically assigns SUCCESS.

Phase Reference

INITIALIZING

The endpoint has been created and assigned to a worker. The worker is initializing the endpoint's SIP stack and preparing to send the first SIP message.

• Ordinal: 0
• Triggered by: Worker receives endpoint allocation from the platform
• What happens next: The endpoint sends a SIP REGISTER request and advances to REGISTERED on success. If registration fails, the phase still advances (the failure is captured in the outcome).
• Duration: Typically under 1 second. Longer durations may indicate worker resource contention under high load.

REGISTERED

The endpoint has successfully registered with its assigned SIP registrar. The registrar accepted the REGISTER request and returned a 200 OK response. The endpoint's SIP address is now active and reachable.

• Ordinal: 1
• Triggered by: Successful SIP REGISTER with 200 OK response (after any required authentication challenge-response)
• What happens next: The endpoint advances to CALLING when the call phase begins. For both caller and callee endpoints, the CALLING phase is entered when they begin their respective call setup operations.
• Duration: The endpoint remains in this phase until the test's buildup timer allows the call phase to begin. Buildup staggering prevents all endpoints from calling simultaneously.

CALLING

The endpoint has begun the call setup process. For callers, this means a SIP INVITE has been sent. For callees, this means the endpoint is actively waiting for an incoming INVITE.

• Ordinal: 2
• Triggered by: The test's buildup timer allows this endpoint to initiate its call setup
• What happens next: The endpoint advances to RINGING when a 180 Ringing or 183 Session Progress response arrives (caller), or when an incoming INVITE is received (callee). If no response or INVITE arrives within the timeout, the outcome is set (CALL_FAILED or TIMEOUT) and the phase advances to CLOSED.
• Duration: Should be brief (under 5 seconds in healthy environments). Long CALLING durations indicate SIP routing delays or unresponsive peers.

RINGING

The call is in the alerting phase. For callers, a 180 Ringing or 183 Session Progress response was received. For callees, an incoming INVITE was received and the endpoint is signaling that it is alerting.

• Ordinal: 3
• Triggered by:
  • Caller: Receives 180 Ringing or 183 Session Progress from callee
  • Callee: Receives incoming INVITE from caller
• What happens next: The endpoint advances to NEGOTIATING as the SDP offer/answer exchange proceeds toward call establishment.
• Duration: Brief. The RINGING phase corresponds to the ring time metric. Unusually long ringing may indicate delayed answer behavior on the callee side.

NEGOTIATING

The SDP offer/answer exchange is in progress. The endpoints are agreeing on media parameters (codecs, ports, IP addresses, RTP profiles).

• Ordinal: 4
• Triggered by: The SDP exchange begins during the INVITE transaction
• What happens next: Advances to INCALL if negotiation succeeds (codecs agreed, media ports established). If no common parameters can be found, the outcome is set to NEGOTIATION_FAILED and the phase advances to CLOSED.
• Duration: Typically under 1 second. Longer durations may indicate complex proxy chains modifying SDP.

INCALL

The call is established and media is flowing. RTP packets are being sent and received, and real-time quality metrics are being collected. This is the primary data-gathering phase of the test.

• Ordinal: 5
• Triggered by: Successful SDP negotiation and 200 OK / ACK exchange
• What happens next: The endpoint remains in INCALL for the configured call duration, then advances to DISCONNECTING when the test initiates call teardown (BYE).
• Duration: Matches the configured call duration in the test. All quality metrics (MOS, jitter, packet loss, RTT, etc.) are measured during this phase at one-second intervals.
• What is happening: Both endpoints are exchanging RTP media packets and RTCP quality reports. The platform collects send-direction and receive-direction metrics independently.

DISCONNECTING

The call teardown has begun. A BYE request has been sent or received, and the endpoint is waiting for confirmation before fully closing.

• Ordinal: 6
• Triggered by: The test duration timer expires, or the remote side sends a BYE
• What happens next: The endpoint advances to CLOSED after receiving the 200 OK response to the BYE, or after a timeout if the BYE is not acknowledged. If the BYE fails to send, the outcome is set to TEARDOWN_ERROR.
• Duration: Should be very brief (under 1 second). Extended DISCONNECTING durations may indicate a non-responsive remote endpoint or proxy.

CLOSED

The endpoint has completed its lifecycle. All SIP dialogs are terminated, media sessions are closed, and the endpoint's metrics are finalized.

• Ordinal: 7
• Triggered by: Successful call teardown, or any failure that terminates the endpoint's lifecycle
• What happens next: No further phase changes. The endpoint's metrics and SIP traces are available for review. If no outcome was previously set, the platform automatically assigns SUCCESS.
• This is a terminal phase. Every endpoint eventually reaches CLOSED, whether through successful completion or failure.

Phase Flow Diagram

The diagram below shows all possible phase transitions. The happy path flows straight through. Failures set an outcome but the phase still advances to CLOSED.

                     INITIALIZING
                          |
                     REGISTERED
                          |
                       CALLING
                          |
                       RINGING
                          |
                     NEGOTIATING
                          |
                       INCALL
                          |
                    DISCONNECTING
                          |
                       CLOSED

Any phase can transition directly to CLOSED on fatal error. The outcome field captures the reason for early termination.

Outcome Reference

SUCCESS

The endpoint completed its full lifecycle without errors. The call was established, media was exchanged for the configured duration, and teardown completed cleanly.

• Severity: 0
• Set by: Auto-set when the endpoint reaches CLOSED with no prior outcome

COMPLETED_WITH_WARNINGS

The endpoint completed its lifecycle, but non-fatal issues were detected (e.g., minor packet loss spikes, brief jitter excursions, or transient RTCP anomalies).

• Severity: 1
• Set by: Quality monitoring during the INCALL phase

REGISTRATION_FAILED

The endpoint's SIP REGISTER request was rejected or timed out. The endpoint cannot proceed to the call phase.

• Severity: 10
• Set by: SIP registrar responds with an error (401, 403, 404, 408, etc.) after authentication attempt, or the REGISTER times out with no response
• Common causes:
  • Invalid SIP credentials (401 Unauthorized after challenge)
  • Account blocked or IP not on allow list (403 Forbidden)
  • Incorrect registrar domain or DNS failure (no response / timeout)
  • Registrar overloaded (408 Request Timeout, 503 Service Unavailable)
• Diagnosis: Open the endpoint detail view and check the SIP message trace for the REGISTER exchange. The response code and headers identify the exact failure. See SIP Registration Errors.

CALL_FAILED

Call setup failed. The endpoint could not establish a call due to routing errors, callee unavailability, or SIP-level rejection.

• Severity: 10
• Set by: SIP response indicating call failure (404 Not Found, 480 Temporarily Unavailable, 486 Busy Here), or no INVITE received by callee within the expected window
• Common causes:
  • Callee not registered or unreachable
  • SIP routing failure between caller and callee registrars
  • Cross-group targeting misconfiguration
  • All callers in the targeting group failed to register

NEGOTIATION_FAILED

The SDP offer/answer exchange failed. The endpoints could not agree on media parameters. No call was established.

• Severity: 10
• Set by: SIP response 488 (Not Acceptable Here) or 606 (Not Acceptable), or the SDP answer contains no matching codec
• Common causes:
  • No common codec between caller and callee
  • Media type mismatch (audio-only offer to a video-only endpoint)
  • SDP manipulation by an intermediate proxy that removes all acceptable codecs
• Diagnosis: Check the SDP bodies in the SIP message trace. Compare the offered codecs with the answer. See Supported Codecs.

TIMEOUT

An operation exceeded its configured time limit. This covers both INVITE transaction timeouts (caller sent INVITE but received no final response) and receiver wait timeouts (callee waited but no INVITE arrived).

• Severity: 10
• Set by: Timer expiration during CALLING or REGISTERED phase
• Common causes:
  • Network connectivity issue between worker and registrar
  • Callee overwhelmed and unable to process INVITE in time
  • Timing mismatch where the callee's wait timer is shorter than the caller's buildup delay
  • SIP routing delays exceeding the transaction timeout

OSERROR

An infrastructure-level error occurred outside the SIP protocol layer. This covers OS-level failures, network stack errors, and resource exhaustion on the worker.

• Severity: 10
• Set by: Worker detects a system-level error affecting the endpoint
• Common causes:
  • Worker out of memory or CPU
  • Network interface failure
  • File descriptor exhaustion
  • Socket creation failure

TEARDOWN_ERROR

The call was active but teardown failed. The BYE request could not be sent or was not acknowledged.

• Severity: 10
• Set by: BYE send failure or BYE response timeout during the DISCONNECTING phase
• Common causes:
  • Remote endpoint became unreachable after the call was established
  • Proxy failure during teardown
  • Network interruption during the DISCONNECTING phase

Path Summary

Aggregate Counts

The test run summary page shows real-time counts of endpoints in each phase and outcome. This provides an at-a-glance view of test progression:

• During buildup: Endpoints move from INITIALIZING to REGISTERED in waves
• During the call phase: Endpoints advance through CALLING to INCALL
• During teardown: Endpoints move from INCALL through DISCONNECTING to CLOSED
• At completion: All endpoints should be in CLOSED phase

A healthy test run shows a smooth wave pattern through the phases. Sudden spikes in error outcomes (REGISTRATION_FAILED, CALL_FAILED, NEGOTIATION_FAILED) indicate infrastructure issues at the corresponding phase.

Interpreting Outcome Distributions

When analyzing a completed test run, look at the distribution of outcomes:

Troubleshooting by Outcome

REGISTRATION_FAILED

Registration failures prevent the endpoint from participating in any call. Start with the SIP message trace.

1. Check the SIP response code. Open the endpoint detail view and look at the REGISTER exchange. A 401 after a valid challenge-response means bad credentials. A 403 means the account is blocked or the source IP is not authorized. A 408 or no response means network-level connectivity failure.
2. Verify SIP credentials. Confirm the username, password, and realm match what the registrar expects. A typo in the SIP account configuration is the most common cause.
3. Check registrar reachability. If no SIP response is received at all, verify that the registrar domain resolves correctly and that the worker can reach the registrar on the configured transport (UDP/TCP/TLS) and port.
4. Look at registrar capacity. If some endpoints register successfully but others fail under load, the registrar may be rejecting requests due to rate limiting or resource exhaustion. Reduce the buildup speed or endpoint count to test this theory.

CALL_FAILED

The call could not be established due to SIP-level errors or routing failures.

1. Check if the callee registered. If the callee group has many REGISTRATION_FAILED outcomes, callers in the targeting group will have no one to call. Fix registration first.
2. Verify cross-group targeting. Ensure the caller group is configured to call the correct callee group. Mismatched targeting is a common configuration error.
3. Check SIP routing. If caller and callee are on different registrars, the SIP routing between those registrars must be configured correctly. Look at the caller's SIP trace for any error response (404, 480, 486) that indicates why the call was not answered.

TIMEOUT

An operation exceeded its time limit -- either the INVITE transaction or the callee's wait for an incoming call.

1. Check caller status. If all callers failed to register or received CALL_FAILED, no INVITE was ever sent toward this callee. Fix the caller-side issues first.
2. Verify group targeting. The callee's group must be the target of at least one caller group. Check the test configuration.
3. Check endpoint pairing. In large tests, the endpoint pairing algorithm distributes callers across callees. If there are more callees than callers, some callees will naturally time out. Ensure your caller-to-callee ratio is balanced.
4. Increase timeout. If the callee is behind a slow network path, the default timeout may be too short.

NEGOTIATION_FAILED

The SDP offer/answer exchange completed, but the endpoints could not agree on media parameters.

1. Compare codec lists. Open the SIP trace and compare the codecs in the SDP offer (INVITE body) with the codecs in the SDP answer (200 OK body). If there is no overlap, the negotiation fails.
2. Check for SDP manipulation. Some SBCs or proxies modify SDP bodies in transit, potentially removing codecs. Compare the original offer with what the callee received.
3. Verify media type compatibility. If your test offers audio+video but the callee only supports audio, the negotiation may fail depending on the callee's handling of unsupported media lines.

Related Pages

• Test Run Statuses -- Overall test run lifecycle
• SIP Response Codes -- Interpreting SIP error codes
• Common Test Failures -- Troubleshooting failed tests
• Analyzing Results -- How to read test run results