CallMeter logoCallMeter Docs
MetricsCall timing

Total Hold Duration — SIP Hold Time Measurement

Measure cumulative time spent on hold during a call. Critical for call center quality assurance, hold time SLA verification, and music-on-hold testing.

Total Hold Duration

PropertyValue
Keytotal_hold_duration_ms
UnitMilliseconds (ms)
TypeCumulative counter
DirectionBoth
RFCRFC 3264 Section 8.4

What It Measures

Total Hold Duration measures the cumulative time an endpoint spent in hold state during a call, in milliseconds. Hold state begins when a re-INVITE sets the media direction to sendonly or inactive, and ends when a subsequent re-INVITE restores sendrecv.

If a call is placed on hold three times for 10 seconds each, the total hold duration is 30,000ms.

Why It Matters

For call center deployments, hold duration directly impacts customer satisfaction and SLA compliance. Many call centers have SLA targets for maximum hold time — exceeding them triggers escalation workflows or financial penalties.

During load testing, hold duration reveals whether the infrastructure maintains hold state correctly under load. Common failures include: hold state dropping prematurely (customer hears silence), hold lasting indefinitely (re-INVITE for resume is lost), and music-on-hold degrading as concurrent held calls increase.

Thresholds

ConditionMeaning
Duration matches scenario timingHold/resume working correctly
Duration < expectedHold ended prematurely — re-INVITE handling issue
Duration > expectedHold never released — resume re-INVITE may have been lost
Duration = 0 but Hold Count > 0Hold detected but duration not measured — timing issue

How to Fix It

  1. Compare with Hold Count. Duration / Count gives average hold time per event. If the average deviates from your scenario's configured hold duration, the SBC or PBX is modifying hold behavior.
  2. Check music-on-hold. If hold duration seems correct but no music plays, the MoH resource may be exhausted. This is common under load.
  3. Verify re-INVITE timing. The resume re-INVITE should fire exactly at the configured hold duration. Timing drift indicates scenario scheduling issues.

On this page