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!).
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.
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.
-Paul
On 12/07/2015 12:00 PM, Pete E wrote:
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.
But for the signaling issue mentioned above, there could potentially
be a new DNS record type created which defines accepted signaling.
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.
That said, anyone interested in setting up a lab environment to hash
this out?
On Sat, Dec 5, 2015 at 5:19 PM, Paul Timmins <p...@timmins.net
<mailto:p...@timmins.net>> wrote:
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?
-Paul
On Dec 5, 2015, at 15:14, Erik Flournoy <e...@eespro.com
<mailto:e...@eespro.com>> wrote:
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.
On Sat, Dec 5, 2015 at 12:09 PM, Alex Balashov
<abalas...@evaristesys.com <mailto:abalas...@evaristesys.com>> wrote:
On 12/05/2015 05:05 PM, Erik Flournoy wrote:
If a packet transverses your entire network as a packet
then it's never
a toll charge. It's a packet.
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.
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.
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 <tel:%2B1-800-250-5920> (toll-free) /
+1-678-954-0671 <tel:%2B1-678-954-0671> (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
