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

[Pete E]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20151207/7278821d/attachment.html>