Even if you do the Free IP PBX or Twilio API, you're only calling from one
carrier.  In the scenario you described, you mentioned:

"Verizon wireless customers cannot call Sprint toll free numbers from area
code 555"

Which is very specific.  Would you imagine that you would have owned a 555
number on Verizon to have caught that scenario faster?  What if the area
code was 666?  Or the originating carrier was AT&T?  The different
combinations you would have to account for are very high.

If you only care about your edge service and inward, and not far end
carriers, then a Twilio API app sounds like a good plan.  Heck, you could
even just write a UCCX script to call out and back in via tromboning off
the PSTN.

I'm curious, what did you mean by "prone to issues," when referring to the
API?

On Wed, Mar 7, 2018 at 1:57 PM Nick Barnett <nicksbarn...@gmail.com> wrote:

> A client has a need for an off site solution that will make test calls to
> their numbers and report when there are issues. I understand that this is
> very vague, but they are interested in hearing about any and all solutions.
>
> They have several SIP carriers and a nationwide presence, but the SIP
> trunking is centralized. They've had enough issues with one DID service
> failing and their customers having to report the issue. Ideally, the SIP
> providers would be able to automatically do "something" when they stop
> receiving options pings, or when a certain sip response is received... but
> it doesn't work that way with the behemoth phone companies.
>
> The way it works now is that MOST issues are able to be caught
> successfully with internal monitoring... but others such certain NPA-NXX
> can't call another NPA-NXX, or carrier interconnects such as "Verizon
> wireless customers cannot call Sprint toll free numbers from area code
> 555"  These odd scenarios are what we are looking to solve. I understand
> this is potentially huge, but I think if we could automate calls to about
> 10 different numbers, that would cover enough of the ingress and carrier
> combinations that it would make a HUGE difference.
>
> I've thought of spinning up an Asterisk and somehow automating the echo
> test feature. I've also thought about using the Twilio API to test if calls
> are successful. Both of these are complicated and prone to issues... so if
> there is a hosted or cloud solution that is already available, please let
> me know.
>
> Any suggestions or more than welcome.
>
> Thanks,
> Nick
> _______________________________________________
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Reply via email to