Scenario Actions Failed

What It Measures

Scenario Actions Failed counts the number of scenario steps that did not complete successfully during a call. A step fails when it times out waiting for a response, receives an unexpected SIP response, encounters a media negotiation error, or the call terminates before the step can execute.

This is the failure-side complement to Scenario Actions Executed. While executed tells you how many steps ran, failed tells you how many broke — and since steps execute sequentially, a failure at step 3 often causes steps 4 and 5 to never run.

Why It Matters

This metric answers the question every VoIP engineer dreads: "Which step broke?"

Production SIP infrastructure is tested on basic call metrics — answer rate, MOS, packet loss. But when a complex IVR fails under load, those metrics look fine. Calls are completing. MOS is acceptable. Packet loss is low. But 40% of callers are never reaching the billing department because step 4 of the IVR — the one that triggers a SIP REFER for the transfer — is timing out.

Scenario actions failed is what finds this. Instead of "something is wrong with the IVR," you get "step 4 is failing at 300 concurrent calls."

Common failure patterns:

DTMF detection failures: The remote endpoint is not detecting DTMF digits sent during the scenario. A failed DTMF action (step 2) means the IVR never received the menu selection.

Hold/resume failures: A hold action that fails mid-call leaves the call in an undefined media state. The RTP stream may be muted, the other party hears silence, and the test call artificially inflates Call Duration while producing no useful media metrics.

Transfer failures: A REFER or blind transfer that fails produces a specific SIP response code. Failed transfer actions paired with the Final Status Code gives you the exact failure classification.

Codec renegotiation failures: A mid-call re-INVITE for codec change that fails returns a 488 Not Acceptable Here or a timeout. Failed actions here indicate SDP incompatibility or SBC capacity limits.

Thresholds

How to Fix It

1. Identify the failing step. Use the step-level breakdown alongside this counter to determine which action type is failing (DTMF, hold, transfer, codec change). Different step types point to different components.
2. Check response codes at failure time. SIP responses during a failing scenario step are captured in Final Status Code if they terminate the call, or in call logs if the call continues. A 408 timeout means the remote side is not responding; a 488 means codec mismatch.
3. Test the step in isolation. If step 4 is failing, write a scenario that only executes step 4. If it succeeds in isolation but fails under concurrent load, you have a capacity problem at that step's target component.
4. Review timeouts. Scenario steps have configurable timeout windows. If the timeout is too short for your infrastructure's response time under load, steps will fail prematurely. Measure the expected response time at zero load first.
5. Correlate with media metrics. A hold step that fails will show up as a sudden change in Packet Loss Rate or Audio Bitrate at the exact timestamp of the failure.

Related Metrics

• Scenario Actions Executed — Successful steps; use ratio of failed to executed to find failure rate
• Final Status Code — SIP response code if the failure terminates the call
• Final Reason Phrase — Human-readable description of SIP failure
• Call Duration — Short durations often indicate early scenario failure