BGP relies on physical interconnections that have large contracts behind
them. You don't just get a full BGP feed from your upstream and they accept
all your announcements blindly.
You can broadcast to your upstream that you are a route for all IPs in
AS701, but if you are directly connected to me and I only gave you a single
Class C , that doesn't make sense, so I'll blackhole your announcement
because "I know better." At least the good ISPs do that. And when they
don't, AS701 says "hey we didn't do that fix it now" and AS701 shuts down
interconnects, it gets fixed quickly.
Phone numbers and phone calls are an entirely different realm.
Who owns the phone number? Who is allowed to publish that "Hey send calls
to this number directly here!" Level3? Their reseller? Their reseller's
reseller? Who's right if there are conflicting announcements? How do you
make sure that the route that is correct today is correct tomorrow? Do you
verify with an automated phone call? [1]
Now Level3 could publish a record that says "Ask the reseller for where to
send calls." And the reseller could publish a record that says "Ask OUR
reseller where to send calls." But they won't because that would rob them
of billable inbound minutes and potentially outbound minutes.
You think fraudulent number ports and snapbacks are a pain...
How do I know I can trust people in the group? What if we let someone in
and then they publish a bunch of records and they are valid today but it
was part of a mass port out tomorrow, and now some "cooperative group" is
sending all the calls to this person but they no longer "own" the numbers.
If this is to be done successfully, it must be done without trust.
Beckman
[1] I have some ideas here. You make an API call to "the cooperative
group." They tell you a phone call will come to you from CallerID X to
Phone Number Y to verify that you are in the series of hops when terminated
through the PSTN to verify that you would get the call. If it succeeds,
your record is published (or continues to be published) by the group, for
group consumption for routing.
But this has a flaw. What if the reseller does this, and the reseller's
reseller does this. Who wins? As a reseller, I'd want the calls hitting me
first, so I can bill my reseller for minutes. But my reseller wants calls
going straight to them so they don't have to pay me for minutes.
On Mon, 7 Dec 2015, 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
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 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
---------------------------------------------------------------------------
Peter Beckman Internet Guy
[email protected] http://www.angryox.com/
---------------------------------------------------------------------------
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/voiceops
