RTPEngine Failure Reasons Are Better Than One Failure Total

Media sessions can close for rejection, timeout, silent timeout, final timeout or offer timeout, and those reasons point to different failure paths. The monitoring mistake would be to read one metric in isolation. rtpengine_closed_sessions_total grouped by reason is useful because it narrows the question, and reason labels turn a generic media-failure count into actionable evidence about negotiation, inactivity or lifecycle problems.

In software operations this falls under cause-coded media monitoring. A dashboard becomes much more valuable when the operator knows what a rising line can prove, what it cannot prove, and which second signal should confirm the hypothesis.

My prevention rule is: Alert on a combined failure-rate threshold but preserve reason breakdown in Grafana so troubleshooting starts from the dominant failure class. That keeps false positives lower without weakening visibility into real degradation.

The hserver source evidence is b65d5d4. Keeping that provenance matters because monitoring logic changes over time; the article should remain connected to the exact engineering decision it describes.