<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="">Ah, but how would you know what IPs your inbound call should be trusted from for your SBCs? It's hard enough to get people properly interopped when the calling activity is planned, let alone have random endpoints hit your network. Are they going to use E.164? Should they send npdi/rn data? Should you trust the calling party information being sent? How do you know the original caller is even a legitimate telco and not some telemarketer going on a rampage connecting directly with everything? If you are getting problematic (abusive, illegal) inbound calls, how do you look up that IP to know who to complain about? Is WHOIS enough?<div class=""><br class=""></div><div class="">-Paul<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 5, 2015, at 15:14, Erik Flournoy <<a href="mailto:erik@eespro.com" class="">erik@eespro.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Additionally to come to Neustar NPAC extremely LATE proposal rescue of using the IP and SMS fields in the NPAC to packet route calls instead of via the TDM/SS7 Path that would kinda remove IQ from the path and allow carriers to directly connect via packets. Put the call on the IP packet path if it's voice and use TDM only for faxing which I wish would disappear for goodness sakes.<div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Dec 5, 2015 at 12:09 PM, Alex Balashov <span dir="ltr" class=""><<a href="mailto:abalashov@evaristesys.com" target="_blank" class="">abalashov@evaristesys.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/05/2015 05:05 PM, Erik Flournoy wrote:<br class="">
<br class="">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If a packet transverses your entire network as a packet then it's never<br class="">
a toll charge. It's a packet.<br class="">
</blockquote>
<br class=""></span>
Well, right. :-) No provider of voice networks wants value-added services to go away and be replaced by OTT applications for whom they're just a low-margin, flat-rate, 95% percentile-billed transport layer.<br class="">
<br class="">
To a point, you can understand where they're coming from. They do the hard, capital-intensive work of building out the network, while some clever mobile app out of Silicon Valley pockets all the profits. That wasn't the assumption from which they built anything.<div class="HOEnZb"><div class="h5"><br class="">
<br class="">
-- <br class="">
Alex Balashov | Principal | Evariste Systems LLC<br class="">
303 Perimeter Center North, Suite 300<br class="">
Atlanta, GA 30346<br class="">
United States<br class="">
<br class="">
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)<br class="">
Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank" class="">http://www.evaristesys.com/</a>, <a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank" class="">http://www.csrpswitch.com/</a><br class="">
_______________________________________________<br class="">
VoiceOps mailing list<br class="">
<a href="mailto:VoiceOps@voiceops.org" target="_blank" class="">VoiceOps@voiceops.org</a><br class="">
<a href="https://puck.nether.net/mailman/listinfo/voiceops" rel="noreferrer" target="_blank" class="">https://puck.nether.net/mailman/listinfo/voiceops</a><br class="">
</div></div></blockquote></div><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=""></div></div></body></html>