Scenario Actions Executed — VoIP Call Timing Metric
Scenario steps completed per SIP call — verifies IVR navigation, DTMF sequences, hold/resume, and codec-change steps executed as designed in load tests.
Scenario Actions Executed
| Property | Value |
|---|---|
| Key | scenario_actions_executed |
| Unit | Count |
| Type | Cumulative counter |
| Direction | Both |
What It Measures
Scenario Actions Executed counts the number of scenario steps that completed successfully during a call. A scenario is a sequence of scripted actions that simulate real-world call behavior — DTMF digit entry, hold/resume sequences, codec renegotiation, mid-call transfers, and custom timing delays. Each step that runs to completion increments this counter.
This metric is the success-side complement to Scenario Actions Failed. Together they tell you whether your test scenario ran as designed.
Why It Matters
VoIP infrastructure is more than dial-tone-to-hangup. Production systems handle DTMF menus, call holds, transfers, and codec changes throughout a call's lifecycle. A SIP stack that passes a basic call completion test may still fail on step 3 of a 5-step IVR sequence. Standard call metrics — MOS, packet loss, jitter — cannot detect this. Scenario actions executed can.
Common use cases where this metric is critical:
IVR and auto-attendant testing: Your IVR has 5 menus. At what load level does step 3 — the one that triggers the CRM lookup — start failing? Scenario actions executed drops from 5 to 2 as load increases, and you know exactly where your IVR breaks down.
Hold music and media hold: Does hold activate correctly? Does resume re-establish two-way audio without SSRC conflicts? A hold scenario with 3 actions (hold, wait, resume) validates the full hold lifecycle.
Codec renegotiation under load: Does a mid-call re-INVITE for codec change succeed at 500 concurrent calls? Scenario actions executed shows you whether the re-INVITE is completing or failing silently.
Regression testing: After an infrastructure upgrade, run the same scenario suite. Expected actions executed should equal total steps times call count. Any reduction pinpoints the step that the upgrade broke.
Thresholds
Thresholds depend on your scenario's total step count. The key ratio is:
| Condition | Meaning |
|---|---|
| Executed = total expected steps × call count | All scenario actions ran as designed |
| Executed < expected | Some steps failed or were skipped — check Scenario Actions Failed |
| Executed = 0 | Scenario did not start or immediate failure on step 1 |
How to Fix It
- Cross-reference with Scenario Actions Failed. The failed count tells you how many steps broke; the executed count tells you how many preceded them. The ratio tells you which step is the breaking point.
- Check step-level timing. If actions are being skipped rather than failing, the prior step may have timed out silently before the next step triggered. Review scenario timing configuration.
- Isolate by scenario type. Separate DTMF scenarios from hold/resume scenarios from codec-change scenarios. Different failure patterns often point to different infrastructure components.
- Monitor under load. Run scenarios at increasing concurrency levels and plot executed vs. expected. The CPS where executed starts dropping below expected is your effective infrastructure capacity for that scenario type.
Related Metrics
- Scenario Actions Failed — Count of steps that failed; pairs with this metric for step-level diagnosis
- Call Duration — Short durations may indicate early scenario failure before all steps ran
- Call Result — A successful call result with low executed count indicates mid-call scenario failure
- Final Status Code — SIP errors during scenario steps produce specific status codes