<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This is similar to a solution that I designed and implemented at a former client. Like you, we needed to support a variety of call destinations (mobile phone, office A, office B, phone system A, phone system B) with a consistent range of DIDs, using a 1:1 DID:destination mapping. We wound up putting all of the customer-facing numbers at our most trusted telephony vendor, and using their web-based customer dashboard to control call routing as need be. We gained some price concessions because we were already a long-time internet services customer, and by being an early adopter of their business-grade telephony services. One of the huge advantages of this vendor (<a href="http://Sonic.com" class="">Sonic.com</a>) was their long history of transparency and plain-English ownership of inevitable problems. They earned and continually retained our trust and respect, which really made everything simpler and operationally more efficient. It still resulted in paying more per delivered call-minute, but we also gained a lot by having that much more leverage with our secondary vendors. In the end, it was well worth it.</div><div class=""><br class=""></div><div class="">Two downsides we faced, the mitigations we employed, and ideas for next time:</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Downside #1: At least at first, an increased tendency toward finger-pointing (by the secondary vendors) when call quality/completion issues arose.</div><div class=""><br class=""></div><div class="">Mitigation: I implemented a lot of network monitoring, within some constraints agreed to with Legal so as to stay on the right side of the law (and on the safe side of risk management). Key ingredients: Ownership+management of key network hardware (so as to implement port mirroring), properly-configured tshark on the capture device, properly-sized capture hardware, Cloudshark for its great UI, and some auto-pruning for risk management. At the first couple of iterations of reflexive finger-pointing by the secondary vendors, with me declining to accept that as a solution, everyone learned that they had to actually troubleshoot the problem.</div><div class=""><br class=""></div><div class="">Ideas for improving next time: Greater use of SIP.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Downside #2: More complex network+telecom operations on our end.</div><div class=""><br class=""></div><div class="">Mitigation: This forced us to create and maintain great processes and documentation, particularly around the telecom side. Someone I originally hired as a project manager ended up owning all things telecom, and really shone there. Her documentation and procedures were so strong that we were able to hand off a lot of the workload to lower-level techs and even to non-technical business unit managers.</div><div class=""><br class=""></div><div class="">Ideas for improving next time: Increased emphasis on automation, perhaps by using a vendor with a strong API such as Twilio.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">good luck,</div><br class=""><div apple-content-edited="true" class="">
Graham Freeman, Principal Nerd<br class=""><a href="http://NerdVentures.com" class="">NerdVentures.com</a><br class="">+1-510-898-6772<br class="">graham@nerdventures.com<br class="">https://www.linkedin.com/in/grahamfreeman<br class="">Twitter: @get_nerdy
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 15 Sep 02015, at 08:58, Rafael Possamai <<a href="mailto:rafaelpossa@gmail.com" class="">rafaelpossa@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello all,<div class=""><br class=""></div><div class="">I was tasked to design a system that would give each end user a unique DID from a pool of about 1,000 DIDs total. Every inbound call to a DID would then be forward to the end-users actual phone number (office, mobile, etc..).</div><div class=""><br class=""></div><div class="">We would then make data driven decisions based off of the data collected from all these inbound calls: duration, originating area codes, how many calls, frequency, etc.This of course would have previous authorization of each end-user.</div><div class=""><br class=""></div><div class="">WIth that in mind, to me it looks like a big waste of DIDs, and I could use custom extensions instead, with a single DID for everyone. Each end-user is assigned a 5 digit code (an extension pretty much) and gets re-routed accordingly. I believe using Asterisk and/or FreePBX I could still collected all the data that is needed.</div><div class=""><br class=""></div><div class="">Estimated inbound minutes is 500,000 a month, so that requires another 500,000 outbound minutes because each call is forwarded. One million minutes a month does turn out to be expensive, close to U$8,000/month from some quotes that I have gotten.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">With all of this in mind, I'd like to know if anyone here has done a similar project and would be willing to share their experience. I am trying to accomplish everything with the minimum amount of resources as possible (money and DIDs, etc).</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thank you in advance!</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">Rafael </div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div>
_______________________________________________<br class="">VoiceOps mailing list<br class=""><a href="mailto:VoiceOps@voiceops.org" class="">VoiceOps@voiceops.org</a><br class="">https://puck.nether.net/mailman/listinfo/voiceops<br class=""></div></blockquote></div><br class=""></body></html>