One tricky aspect of getting automated call testing to work properly across different switches and deployments is that different delays and timeouts are required in various places throughout the script library. This is even harder when targeting different international phone systems.

For example, when we take a phone port off-hook, we sometimes have to be careful to avoid immediately performing operations on that port. It needs a slight delay when we’re on a VoIP system to give the RTP stream a chance to start. Otherwise if we slam it with DTMF right away we’ll lose a digit or two. On a pure POTS system, we can reduce the delay.

Sprinkling these delays throughout the script libraries would be a nightmare…

Click here to read this article…

Sometimes a feature is broken in a way that is not immediately detectable by the call generator. For instance, let’s say some call flow causes a memory leak in the switch. The call will work hundreds or thousands of times, but at some point the entire switch will stop working — and the cause won’t be obvious.

You want your switch to crash and burn in your lab, not in the field. Let’s look at three types of robustness testing.

Click here to read this article…