Testing and Telephony
• Saturday, August 28, 2010 - I love test tools that don't hold my hand
Sometimes I just want to run a simple call quickly, and then Hammer's Testbuilder interface is great - just click on the actions needed, and it takes care of all the details, correctly, for you. Other times, I need to control the signalling details - the exact millisecond when a bit gets asserted on a CAS line, particular values in some of the more obscure ISDN SETUP IEs, forcing a release collision, that sort of thing. The low-level scripting features of Hammer's HVB rarely let me down, but every once in a while, I can get pretty close to what I want, but not exactly. The Hammer is a splendid voice-app test tool, it is not a protocol tester. But it's what I have, and generally I can do a pretty good job of making it fake being a protocol tester when I have to.
SIP and related protocols are a lot more complicated, and the SIP world being what is is, every so often one has to deal with interop problems. We've been trying to figure out and fix a problem our SIP implementation has in an environment (equipment plus configuration) we've never encountered before. So, as my developer fed me information about exactly what mattered in the relevant messages, I was able to use SIPp to turn my desktop system into a simulation of that new environment. The Record-Route headers need to look like *that*? We don't have any equipment in-house that supports that, but it doesn't matter, with SIPp I can fake it, SIPp doesn't care that those IP addresses don't exist. So my developer can test his fixes in house instead of having to do experiments in the customer's network, and we are all much happier because of it. I can build any message I like with SIPp because the scripts are XML, if the syntax is legal, it doesn't care about the content. Making a message your target system can do something useful with is your lookout.
SIPp is my friend.
It doesn't hurt that it's free.
|
:: Send to a Friend!
|
|
|
|
|
