AWAITING FEEDBACK Anveo - Clipped audio from signalling delay in call setup

[Bradley Cooper]

On a recommendation from this forum I am trying Anveo as a replacement for a current termination provider. Call quality is fine, but I get odd delay behavior when the call is connecting. If I call a number with an outbound IVR, I lose the first few seconds of the IVR audio. With the same setup on other providers I measure from .66 to 1.0 seconds delay between TRYING and OK during call setup. No problem with that audio. I used Anveo (retail) and got about 2.5 seconds delay and lost audio. I posted a ticket and in the response I was advised to use anveodirect since there will be no rtp proxy. This does not look like an rtp proxy issue to me, but I switched over to anveodirect and all prime/high tier routes and on my first test it was worse - I got 4.2 seconds of delay and lost even more IVR message. This is so different from my other providers despite Anveo getting high marks on this forum. Anybody seen this?

 

[Bradley Cooper]

Ok - I have a solution of sorts on a recommendation from their support - maybe this will help someone else. By not using their LCR provider selection criteria I can select my own. I went down the list one-by-one and found a few providers that do not exhibit this behavior. I think this limits me to anveodirect where I have the option of selecting carriers (rather than Anveo retail). On with the testing....

 

[Hyksos]

Seem like a diagnosis in the sky to me. -> Logs
It sound like a NAT issue. You don't get audio before you sent some and opened the pin holes in the NAT device. Before that the audio is dropped somewhere in the path.
The other end would not start sending audio before it knew it could start and had obtained the location to send it. But it doesn't mean the flow is actually open all the way.
Do you get "received RTP packet" before the first "sent RTP packet" ?

 

[atsak]

Yep - what kind of router/firewall are you using . . .

 

[Bradley Cooper]

Thanks for your comments. The firewall is a NSA class Sonicwall (I am certified) that has been used for about 5 years with the current voice environment (no recent fiddling). NAT is worth a look, although that does not explain why some providers on the Anveo checklist exhibit this problem and some don't. This is easy to test because if it is a closed NAT problem I will see dropped RTP packets inbound. Note, however, that the loss of audio is directly related to the delay between TRYING and OK that I get from the provider so it's hard to imagine how this could be only a NAT problem. My server is just sitting there waiting for the OK and when it comes it ACKs and audio starts immediately. When it's delayed, audio is truncated. It's as if the SBC sends the ACK to the far end before I send the ACK to the SBC. Anyway, I have some providers selected that work fine so I'm not going to drill into this any more right away. Maybe over the holidays. Thanks again.