Time to Trying

Understand the Time to Trying metric — how CallMeter measures the delay from SIP INVITE to 100 Trying, and what slow response times reveal about server health.

Time to Trying measures the delay between sending a SIP INVITE and receiving the first 100 Trying response, in milliseconds. The 100 Trying is the SIP server's acknowledgment that it received the call request and is working on it. It does not mean the phone is ringing yet — just that the server is alive and processing.

Think of it as the time between pressing a doorbell and hearing a click that confirms the doorbell is connected. You have not heard anyone inside yet, but you know the button worked.

One-shot metric

Time to Trying is captured once per call, not as a time-series. It appears in the Call Timing Overview cards on the endpoint detail page rather than as a chart.

How It Works

When CallMeter initiates a test call, it records the exact timestamp of the outgoing SIP INVITE message. It then waits for the first provisional response. The 100 Trying is typically the first response in the SIP transaction — it is generated by the first SIP entity that processes the INVITE (usually a SIP proxy or Session Border Controller).

The time-to-trying value is: trying_at - invite_sent_at

In a well-functioning VoIP infrastructure, this value is very small (typically under 100ms within the same network), because the 100 Trying is generated locally by the first SIP hop rather than requiring the call to reach the final destination.

Why It Matters

Time to Trying is a health indicator for the immediate SIP infrastructure:

Fast response (under 100ms) — The SIP proxy or SBC is reachable and responsive
Slow response (100-500ms) — Server under load, DNS resolution delays, or network latency to the first hop
Very slow or no response (above 500ms) — Server overloaded, unreachable, or misconfigured
No response at all — The SIP server is down, unreachable, or the INVITE was blocked

Unlike Time to Ringing, which depends on the entire call routing chain, Time to Trying only measures the first hop. This makes it a precise diagnostic for the immediate SIP infrastructure.

Common Causes of Slow Time to Trying

Cause	Explanation
SIP server overload	Server processing queue is backed up, delaying responses
DNS resolution delay	SIP URI requires DNS lookup before the INVITE can be routed
Network latency	High latency between the test endpoint and the first SIP hop
Firewall delays	Stateful firewalls inspecting SIP traffic before forwarding
Server misconfiguration	Server not sending 100 Trying provisionally, waiting for downstream response

How to Fix It

Check SIP server health — Monitor CPU, memory, and connection counts on the SIP proxy or SBC receiving the INVITE.
Review DNS configuration — If the SIP URI uses DNS, ensure DNS responses are fast. Consider DNS caching or using IP addresses directly for testing.
Measure network latency — Ping or traceroute to the SIP server to establish baseline network latency. Time to Trying should not be much higher than network RTT.
Inspect firewall behavior — SIP-aware firewalls may add processing delay. Test with and without the firewall to measure its impact.
Compare across test runs — Increasing Time to Trying over successive tests suggests growing server load or degrading infrastructure.

Time to Ringing — Time until the remote phone rings, covers the full routing chain
Post-Dial Delay (PDD) — End-to-end delay until the caller hears ringing
Call Setup Time — Total signaling duration from INVITE to answer
Final Status Code — If 100 Trying never arrives, the final status code reveals why

RFC Reference

The 100 Trying provisional response is defined in RFC 3261 (SIP: Session Initiation Protocol), Section 21.1.1. Per RFC 3261 Section 16.2, a SIP proxy SHOULD generate a 100 Trying response upon receiving an INVITE to suppress retransmissions from the UAC.