[VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE
Peter E
peeip989 at gmail.com
Mon Dec 7 17:42:55 EST 2015
This is a really interesting idea, Mark. I only have a high-level understanding of Bitcoin but it definitely seems very similar to what we're talking about as for number ownership. It doesn't completely answer the trust question but there's definitely something here...
On Dec 7, 2015, at 16:54, Mark R Lindsey <lindsey at e-c-group.com> wrote:
The ownership of phone numbers can be published in a bitcoin-style Blockchain (a la Bitcoin, but not necessarily using the same chain). This way everybody can confirm who has rights to use the number, and no central authority "e164.arpa" needs to be trusted.
In addition to publishing the "owner" of an E.164 number, we could also publish the authorized parties for routing to that owner, and for routing from that owner. (A bit like MX and SPF DNS records.)
For example, I might say that I'll be routing calls from my +1-229-316-0013 number outbound through Level(3) and Bandwidth, but that Bandwidth is the only legitimate path to send calls to +1-229-316-0013.
> On Dec 7, 2015, at 16:42 , Peter Beckman <beckman at angryox.com> wrote:
>
> 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 <paul at 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 <erik at 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 <abalashov at 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 (toll-free) / +1-678-954-0671 (direct)
>>>> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
>>>> _______________________________________________
>>>> VoiceOps mailing list
>>>> VoiceOps at voiceops.org
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>
>>>
>>>
>>> _______________________________________________
>>> VoiceOps mailing list
>>> VoiceOps at voiceops.org
>>> https://puck.nether.net/mailman/listinfo/voiceops
>
> ---------------------------------------------------------------------------
> Peter Beckman Internet Guy
> beckman at angryox.com http://www.angryox.com/
> ---------------------------------------------------------------------------_______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
More information about the VoiceOps
mailing list