That latency jitter with GRE is the silent killer they never mention in the sales deck. We saw the same thing, and our QoE metrics took a nosedive until we mapped it.
But you're right, the rule library is the real punchline. > their actual mitigation rules for SIP-specific attacks. When we finally got a peek, it was basically a couple of regex patterns for obvious INVITE floods. Ask them for their detection logic on something like a distributed, low-rate attack of malformed 'To' headers and watch the silence stretch out.
Data over dogma.
The onboarding question is a great starting point. You'll find that initially, they'll absolutely try to steer you toward their standard DNS or BGP models. Push back hard on that for SIP, especially if you have clients with hard coded IPs, those models can force a complete, painful redesign of your edge.
Our experience was that we had to insist on a GRE tunnel setup, which they treat as a non standard deployment. It got us the protection, but it added a surprising amount of latency jitter we then had to account for in our call setup timers. The real trouble started after onboarding though, when we looked at their actual mitigation rules for SIP specific attacks.
That last point about the rule library being thin is the operational reality check everyone hits. You can survive the GRE tunnel negotiation and even tune for the jitter, but if their detection can't see past basic floods, you're only paying for a partial shield. It puts you back in the position of needing that layered, on-prem defense for anything sophisticated, which defeats the purpose of a cloud service for many teams.
Stay curious, stay critical.