<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Honestly, I think the proper balance
here (my 2c) would be creating a rolodex of properly maintained
carrier contact information (with controlled distribution) so we
could reach out to carriers we exchange a useful amount of traffic
with, and working out privately the contortions necessary to
connect to each other over SIP, and deciding then to route the
intercarrier calls to each other over a private trunk group. My
switches look up the LRN, and I can add anything to the
translations for a particular LRN, including ISDN PRI, MF, SS7, or
SIP. I can probably do H.323 to a carrier but you'll never hear me
admit that (ugh!).<br>
<br>
We have all the parts we need to convert the PSTN to SIP already.
We don't need FCC permission to do this, we just need to take it
upon ourselves to reach out, exchange information, and set up our
interconnections accordingly.<br>
<br>
The biggest concern for me would be keeping that rolodex out of
the hands of sales departments so I don't get endless calls
offering me LD termination, etc etc. Or looney end users
complaining about spoofed numbers or collections agencies calling
them from our codes and making legal threats that nobody but their
pretend internet lawyers would take as a case.<br>
<br>
-Paul<br>
<br>
<br>
On 12/07/2015 12:00 PM, Pete E wrote:<br>
</div>
<blockquote
cite="mid:CAHm=SaK8Lfc2-74ee43QuUE67dW9HYPdSjreeitwLAQJdmRJig@mail.gmail.com"
type="cite">
<div dir="ltr">These are the crux of the issue. If there were a
cooperative group willing to peer to circumvent the PSTN, and if
the group were large enough, then it could offer *some*
competitive pressure to get the ILEC's to change. In fairness,
Verizon and AT&T have been petitioning and hit some
roadblocks by the FCC to retire their legacy networks. Some of
these concerns are legit, some are not. Now, I'm not naive
enough to believe these petitions are for the good of the
consumer or for anyone other than Verizon and AT&T. But
technologically, it's a step in the right direction.
<div><br>
</div>
<div>But for the signaling issue mentioned above, there could
potentially be a new DNS record type created which defines
accepted signaling. </div>
<div><br>
</div>
<div>Trust is a whole different problem. Without a central
authority, it could be chaotic and really difficult to manage.
But I think the BGP analogy is a good one. If there could be a
method of passing info and then either allowing or blocking it
would be ideal, but it is a really big shift in VoIP security,
as was pointed out.</div>
<div><br>
</div>
<div>That said, anyone interested in setting up a lab
environment to hash this out?</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, Dec 5, 2015 at 5:19 PM, Paul
Timmins <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:paul@timmins.net" target="_blank">paul@timmins.net</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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?<span
class="HOEnZb"><font color="#888888">
<div><br>
</div>
</font></span>
<div><span class="HOEnZb"><font color="#888888">-Paul</font></span>
<div>
<div class="h5"><br>
<div><br>
<div>
<blockquote type="cite">
<div>On Dec 5, 2015, at 15:14, Erik Flournoy
<<a moz-do-not-send="true"
href="mailto:erik@eespro.com"
target="_blank">erik@eespro.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">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>
<div class="gmail_quote">On Sat, Dec 5,
2015 at 12:09 PM, Alex Balashov <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:abalashov@evaristesys.com"
target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:abalashov@evaristesys.com">abalashov@evaristesys.com</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin:0 0 0
.8ex;border-left:1px #ccc
solid;padding-left:1ex"><span>On
12/05/2015 05:05 PM, Erik Flournoy
wrote:<br>
<br>
<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>
a toll charge. It's a packet.<br>
</blockquote>
<br>
</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>
<br>
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>
<div><br>
<br>
-- <br>
Alex Balashov | Principal |
Evariste Systems LLC<br>
303 Perimeter Center North,
Suite 300<br>
Atlanta, GA 30346<br>
United States<br>
<br>
Tel: <a moz-do-not-send="true"
href="tel:%2B1-800-250-5920"
value="+18002505920"
target="_blank">+1-800-250-5920</a>
(toll-free) / <a
moz-do-not-send="true"
href="tel:%2B1-678-954-0671"
value="+16789540671"
target="_blank">+1-678-954-0671</a>
(direct)<br>
Web: <a moz-do-not-send="true"
href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>,
<a moz-do-not-send="true"
href="http://www.csrpswitch.com/"
rel="noreferrer"
target="_blank">http://www.csrpswitch.com/</a><br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org"
target="_blank">VoiceOps@voiceops.org</a><br>
<a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
rel="noreferrer"
target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
_______________________________________________<br>
VoiceOps mailing list<br>
<a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org"
target="_blank">VoiceOps@voiceops.org</a><br>
<a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a moz-do-not-send="true"
href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br>
<a moz-do-not-send="true"
href="https://puck.nether.net/mailman/listinfo/voiceops"
rel="noreferrer" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</body>
</html>