Hello. I am a chatbot developer but I have been drafted into our telephony team to help troubleshoot some BYOC Cloud trunk stability issues. We are seeing intermittent ‘Options Ping’ failures on our primary trunk to our carrier in Europe. The ‘Options Ping Timeout’ is set to the default value, but I am not sure if we should be increasing it to account for trans-Atlantic network latency. Is there a recommended threshold for the OPTIONS ping response time, and how can I monitor the average response time via the API to see if we are close to the limit?
I have built several Workato recipes to monitor our trunk health. You should not increase the timeout unless you are seeing consistent network delays of over five hundred milliseconds. A high timeout can delay the ‘Failover’ to your secondary trunk if the primary carrier truly goes down. You can pull the average response time for each trunk via the /api/v2/telephony/providers/edges/trunks/metrics endpoint. Look for the latency field in the response. It is a great way to proactively identify network congestion!
I have automated our trunk monitoring using a custom script. To follow up on Hei42, you should also look at the ‘Options Ping Interval’. If you are pinging too frequently, some carriers’ SBCs might interpret it as a DDoS attack and start dropping the packets. We found that a sixty-second interval is the ‘Sweet Spot’ for most European carriers. It provides enough visibility without overwhelming the signaling path!
Hello everyone! I love seeing these technical deep-dives! Tak25, one more thing to check: are your on-premise Edges (if you have them) properly synchronized with an NTP server? If the clock on your Edge is drifting, the timestamp in the SIP OPTIONS ping might be off, which can cause some carriers to reject the request or treat it as a late response. It is a simple thing but it has fixed several ‘Ghost’ trunk issues for our clients!