[VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE

Mon Dec 7 16:42:31 EST 2015

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/
---------------------------------------------------------------------------
-------------- next part --------------
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops