Monday, December 22, 2008

Introducing Recqual

I've been waiting to talk about this one for a while.

Several months ago Star2Star was having problems with one of our upstream SIP carriers. We were starting to notice a large increase in the number of one way audio calls our customers were reporting.

When most people think of one way calls their first reaction is to blame SIP. Must be NAT! Must be a firewall! SIP sucks! Etc, etc.

I knew that wasn't the case. I just had to prove it.

I was convinced the problem wasn't SIP/UDP/IP related at all. We had multiple pcaps where we were sending RTP to the appropriate gateway. It just wasn't getting to the PSTN. Where was it going? When was this happening? Which gateways (out of hundreds) were the most problematic? We needed to know and we needed to know quickly.

I came up with and "wrote" recqual over a couple of days. After a few runs we were noticing patterns with problematic RTP endpoint IP addresses. Long story short, once these were identified we worked with the carrier to replace various bits of equipment (DSPs, line cards, etc). The one way audio problem has largely disappeared and we continue to run recqual. If this starts happening again we should know /BEFORE/ our customers do.

Of course I'm using Asterisk to place the calls. The best part of using Asterisk is it's multi-protocol flexibility. You should be able to test just about any combination of voice technologies - G.279a, G711, GSM, SIP, IAX, PRI, FXO, FXO, gtalk/jabber/jingle, skype, etc. The possibilities boggle the mind.

I've just been too busy to get it together and release this to the community - until now.

Tarball with instructions here.

Questions? Comments? Suggestions? Drop me a line.

1 comment:

Paul Miller said...

I have been looking to adapt your technique to use for our network. I would like it to test a call that would originate and terminate on the same asterisk server, which is how I gather your tool works. When testing I have been trying to understand your method and getting quite confused. Is the tool supposed to call a number using a DDI on a provider, then the DDI called is sent by the provider back to the same asterisk server?
This what I have been assuming so far.
When asterisk originates a call I also assume to Plays the tones to the terminating point on the asterisk server. if this is the case is it not only testing one way audio?
is there any chance of a better explaination of how this tool woorks.