CallMeter Docs

Call Setup Time

Understand Call Setup Time — how CallMeter measures the total SIP signaling duration from INVITE to 200 OK, thresholds, and what affects the complete call establishment.

Call Setup Time measures the total duration from sending a SIP INVITE to receiving the 200 OK response, in milliseconds. The 200 OK signals that the remote party has answered the call and media can begin flowing. This metric captures the entire signaling chain — from initial request through routing, ringing, and answer.

Think of it as the total time from pressing "call" to hearing the other person say "hello." It includes the dialing delay, the ringing period, and the moment of answer.

One-shot metric

Call Setup Time is captured once per call. It appears in the Call Timing Overview cards on the endpoint detail page and in aggregate statistics on the test run summary.

How It Works

CallMeter records two timestamps:

  • INVITE sent — When the SIP INVITE leaves the test endpoint
  • 200 OK received — When the final 200 OK response arrives

Call Setup Time = 200_OK_at - invite_sent_at

This includes:

  1. Network transit to the first SIP proxy
  2. Proxy authentication and routing
  3. Carrier transit and routing
  4. Remote endpoint alerting (ringing period)
  5. User or auto-answer responding
  6. 200 OK transit back through the chain

The ringing period (between 180 Ringing and 200 OK) is often the largest component, especially when a human answers the call. In automated testing scenarios where auto-answer is used, the ringing period is minimal.

Why It Matters

Call Setup Time validates the entire signaling path from end to end. For enterprise VoIP testing:

  • Infrastructure validation — Confirms that all components in the call chain (proxies, SBCs, carriers, PBXs) are functioning correctly
  • SLA verification — Enterprise call quality SLAs often include maximum setup time requirements
  • Capacity testing — Under load, setup times increase as servers queue requests. Monitoring setup time at scale reveals capacity limits.
  • Regression detection — Comparing setup times before and after infrastructure changes catches performance regressions

Thresholds

LevelSetup TimeInterpretation
Good5000ms or lessNormal setup including a brief ringing period
Warning10000msExtended setup, possibly slow routing or delayed answer
CriticalAbove 15000msExcessively long, likely indicates a problem in the signaling chain

Auto-answer vs human answer

In automated test scenarios with auto-answer, call setup time is dominated by signaling processing and should be well under 5 seconds. When a human answers, the ringing period adds several seconds. Interpret thresholds accordingly based on your test scenario.

Common Causes of Slow Call Setup

CauseExplanation
Slow carrier routingSIP trunk provider taking too long to route the call
Authentication delaysMultiple authentication challenge/response round trips
DNS resolutionDNS lookups at multiple hops in the signaling chain
Overloaded SIP proxyProxy queueing INVITEs under heavy load
Complex call routingIVR systems, least-cost routing, or failover logic adding processing time
Remote auto-answer delayAuto-answer configured with a delay (e.g., "answer after 3 rings")

How to Fix It

  1. Break down the timing — Compare Time to Trying, Time to Ringing, and Call Setup Time to identify which phase is slow.
  2. Optimize the slowest phase — If trying is fast, ringing is fast, but setup is slow, the delay is in the answer phase. If trying is slow, focus on the first hop.
  3. Monitor under load — Run increasing call volumes and track how setup time scales. Linear growth indicates a scalable system. Exponential growth reveals a bottleneck.
  4. Review SIP traces — Examine the full SIP message exchange to identify which hop introduces the most delay.
  5. Compare carriers — Route identical test calls through different SIP trunks to benchmark carrier performance.

RFC Reference

The SIP INVITE transaction and its responses are defined in RFC 3261 (SIP: Session Initiation Protocol), Section 13. The 200 OK final response is defined in Section 21.2.1. The offer/answer model for establishing media parameters is described in RFC 3264.

On this page