<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">
Hi Nick,
<div class=""><br class="">
</div>
<div class="">We (UnifiedFX) are exposing AXL/JTAPI and a few other CUCM API’s via a simple REST API and have created a Python SDK to make it easy to get up and running.</div>
<div class=""><br class="">
</div>
<div class="">AutomationFX Overview and placeholder for further libraries/docs:</div>
<div class=""><a href="https://github.com/unifiedfx/awesome-automationfx" class="">https://github.com/unifiedfx/awesome-automationfx</a></div>
<div class=""><br class="">
</div>
<div class="">AutomationFX Python SDK</div>
<div class=""><a href="https://github.com/unifiedfx/automationfx-python" class="">https://github.com/unifiedfx/automationfx-python</a></div>
<div class=""><br class="">
</div>
<div class="">So as long as you have some spare IP Phones you can perform automated calling with a simple Python script (<a href="https://github.com/unifiedfx/automationfx-python/blob/master/example_tests.py" class="">Example Tests</a>). It supports multi-cluster
(including mixed CUCM versions) so you could get some test trunks to septette CUCM cluster with some ‘PSTN’ phones and co-ordinate calls from the PSTN to on-net, answer/hold/transfer etc.</div>
<div class=""><br class="">
</div>
<div class="">Obviously scaling up is more of a problem, currently you need real phones, but at some point we shall provide CTI Ports too ;)</div>
<div class=""><br class="">
</div>
<div class="">We have not released AutomationFX for public download yet, happy to let you give it a spin if you like.</div>
<div class=""><br class="">
</div>
<div class="">Kind Regards</div>
<div class=""><br class="">
</div>
<div class="">Stephen Welsh</div>
<div class="">CTO</div>
<div class="">UnifiedFX</div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 8 Mar 2018, at 20:13, Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" class="">nicksbarnett@gmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">Thanks. I am aware of the multiple carriers... but I think being able to cover the edge services would be a huge help in this situation. I'm just anticipating what they will ask for. I kind of cast a wide net with this email because I was not
sure what kind of services were out there. If some provider offered a prepackaged, automated testing service that featured multiple carrier numbers, I'd buy it in an instant. I just need to remember baby steps :)<br class="">
<br class="">
</div>
By "prone to issues", I just mean that it will test connected calls, but getting that next layer of "it connected, but is it working" would be difficult. Not necessarily "issues". I suppose "obstacles" would have been a better word. The issues I see with the
freePBX would be similar, but also includes perimeter security and things of that nature.
<br class="">
<br class="">
I don't have UCCX, but I'm fairly ok at cobbling together AXL and JTAPI to do some stuff... maybe I'll just start there since it's basically free.<br class="">
</div>
<div class="gmail_extra"><br class="">
<div class="gmail_quote">On Wed, Mar 7, 2018 at 9:33 PM, Anthony Holloway <span dir="ltr" class="">
<<a href="mailto:avholloway+cisco-voip@gmail.com" target="_blank" class="">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr" class="">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:<span class="">
<div class=""><br class="">
</div>
<div class="">"Verizon wireless customers cannot call Sprint toll free numbers from area code 555"</div>
<div class=""><br class="">
</div>
</span>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">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.</div>
<div class=""><br class="">
</div>
<div class="">I'm curious, what did you mean by "prone to issues," when referring to the API?<br class="">
<div class="">
<div class="">
<div class=""><br class="">
<div class="gmail_quote">
<div class="">
<div class="h5">
<div dir="ltr" class="">On Wed, Mar 7, 2018 at 1:57 PM Nick Barnett <<a href="mailto:nicksbarnett@gmail.com" target="_blank" class="">nicksbarnett@gmail.com</a>> wrote:<br class="">
</div>
</div>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
<div class="h5">
<div dir="ltr" class="">
<div class="">
<div class="">
<div class="">
<div class="">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.<br class="">
<br class="">
</div>
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.<br class="">
<br class="">
</div>
<div class="">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.<br class="">
</div>
<div class=""><br class="">
</div>
<div class="">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.<br class="">
</div>
<div class=""><br class="">
</div>
Any suggestions or more than welcome.<br class="">
<br class="">
</div>
Thanks,<br class="">
</div>
Nick<br class="">
</div>
</div>
</div>
<span class="">______________________________<wbr class="">_________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" target="_blank" class="">cisco-voip@puck.nether.net</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" target="_blank" class="">https://puck.nether.net/<wbr class="">mailman/listinfo/cisco-voip</a><br class="">
</span></blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
_______________________________________________<br class="">
cisco-voip mailing list<br class="">
<a href="mailto:cisco-voip@puck.nether.net" class="">cisco-voip@puck.nether.net</a><br class="">
https://puck.nether.net/mailman/listinfo/cisco-voip<br class="">
</div>
</blockquote>
</div>
<br class="">
</div>
</body>
</html>