Fingers crossed that someone can assist on this. We're looking for a way to test toll free numbers bound to attendant profiles. So for instance every 5-10 minutes place a call to one of our toll frees to confirm an attendant call flow answers. Reason for this test is we have ran into issues occasionally with a toll free number is not in service or not routing to us correctly and want to identify those in advance. Was thinking of something like using a web service that initiates a handler that places a call to one of our toll free's. It seems I ran across a thread on here about testing attendant call profiles but cannot seem to find it. Has anyone done anything similar to this? Hope this makes sense. Thanks all, Shane

If you want to test at, say, 10-minute intervals, I recommend using the Timer initiator to run a handler every 10 minutes and have logic in the handler to verify whether the call is answered properly, and send an email if you get an error (I think Extended Place Call tool has the failure paths you would need for Busy, Tone, SIT, etc., but double-check me on that).

This may be more work than you are looking for, but as it's something that we do a lot of in our environment, I thought I'd describe our process.. We have around 6500 toll free numbers that route to us, and we have a need to test each of them every so often to confirm that our upstream carriers haven't done anything stupid. In our case, we also want these test calls to completely skip the normal call routing that would occur for these TFNs, whether that would go to Attendant or to our custom workgroup logic. The way we do this is by defining a specific "test" ANI that the test calls will come from. Then, inside of the CustomAnswer handler, one of the first things we do is check whether the call is coming from that ANI. If it is, we redirect the call to a handler that saves the result of the test call. In our case, what we actually do is publish an event via a Redis pub/sub instance, which a different process is listening for -- but it would be easy to just use the ODBC steps to write the test call result into a database somewhere instead. We then choose to return busy to the caller instead of even connecting the call, so that we don't incur any toll free charges for the attempt. As for how we trigger the test call itself, in our case we use a custom application which uses Twilio to place the call -- though you could easily do it via a handler on a timer basis or through an IceLib application. We chose to use Twilio directly to place the call primarily because Twilio is not a part of our carrier infrastructure, and so it made a good test of how our calls route for "everyone else". Depending on the carrier, sometimes if you dial a TFN that is provisioned on that carrier they will short-circuit the SMS/800 lookup and not pay attention to the call routing record. Saves them some money, but for our use case was not a valid test. Hence our use of Twilio to dial. Not sure if this helps at all -- it wouldn't end up testing whether the call routes to Attendant, but I assume your concern is more carrier level than I3 level anyway. Cheers, Joe

I've seen some customers set up dialer to call the different 800 numbers they own to test the 800 numbers. They and even used the outbound IVR to navigate the inbound IVR and record the results. Alternately there is a product called Hammer from Empirix which I've played around with a bit and it can be set up to run on a schedule to test your 800 numbers. Obviously using a 3rd party product to test may be a better solution as the calls are coming in from the outside so it will be as close to a real customer call as you can get.

Thank you all for the suggestions. We'll begin looking at some of these options here shortly. As some have mentioned we are more testing to confirm the carrier isn't having routing issues vs. an Interactive Attendant call flow type issue/navigation. Thanks again, Shane