Aloha Group, I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate. For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company. Erik F. CONFIDENTIALITY NOTICE This e-mail message, including any attachments from EESPRO.com - contain information which is CONFIDENTIAL AND/OR LEGALLY PRIVILEGED. The information is intended only for the use of the individual named above and may not be disseminated to any other party without written permission. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, disclosure, distribution, copying or taking of any action in reliance on the contents of this e-mailed information is strictly prohibited. If you have received this transmission in error, please immediately notify info at eespro.com, and permanently delete this e-mail and the attachments hereto, if any, and destroy any printout thereof.
It seems to me that even now, the central preoccupation of any VoIP ITSP is connection to the PSTN, and that the ILEC tandem is still the anchor of that supply chain. Not a year has gone by since ~2000 or so that some grandiose, cosmological reduced/free pure-IP peering/clearinghouse proposal hasn't appeared, but all of these are hollow when the PSTN is still the common denominator. Moreover, there are powerful inertial forces that aim to incentivise the continuation of the incumbent transit model - measured usage over SS7 - for as long as possible. There is a fairly large number of private interconnects that are technologically IP, of course, but they operate in a conceptually similar way. The next-generation walled gardens cropping up around VoLTE and mobile are conceptually similar, too; IMS is just a different kind of transport for the same old thing. So, the right question to ask isn't: "Is the PSTN dead yet?" It's more like, "Are you on PSTN 2.0 yet"? :-) -- Alex -- 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/
Are you ignoring the position Intelliquent has in the market?
On Dec 5, 2015, at 14:26, Alex Balashov <abalashov at evaristesys.com> wrote:
It seems to me that even now, the central preoccupation of any VoIP ITSP is connection to the PSTN, and that the ILEC tandem is still the anchor of that supply chain.
Not a year has gone by since ~2000 or so that some grandiose, cosmological reduced/free pure-IP peering/clearinghouse proposal hasn't appeared, but all of these are hollow when the PSTN is still the common denominator.
Moreover, there are powerful inertial forces that aim to incentivise the continuation of the incumbent transit model - measured usage over SS7 - for as long as possible. There is a fairly large number of private interconnects that are technologically IP, of course, but they operate in a conceptually similar way. The next-generation walled gardens cropping up around VoLTE and mobile are conceptually similar, too; IMS is just a different kind of transport for the same old thing.
So, the right question to ask isn't: "Is the PSTN dead yet?" It's more like, "Are you on PSTN 2.0 yet"? :-)
-- Alex
-- 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
On 12/05/2015 04:28 PM, Paul Timmins wrote:
Are you ignoring the position Intelliquent has in the market?
Am I? -- 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/
What's Inteliquent's Position? PSTN 2.0 is a great way to describe the upgraded regulation of a system that's not invented to be free to the masses but more so profited by one large mass. I just can't wrap my head around how the government supposedly broke up the bells years ago but for the past century Neustar has been the hub of all the numbering and telcordia the guideline to how you do telecom. A guideline that is licensed and not free to the masses. I continually see smaller CLEC get eaten alive by the ILEC or all the regulatory fees that are based around the telecom system of my great grandparents. Example to order services from most ILEC's you need access to telecordia to get CLLI codes or NC/NCI codes all information owned and licensed by one company. On Sat, Dec 5, 2015 at 11:29 AM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 12/05/2015 04:28 PM, Paul Timmins wrote:
Are you ignoring the position Intelliquent has in the market?
Am I?
-- 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
They operate a competing interconnection service that you can use to in some circumstances entirely replace interaction with the RBOC, save for doing things like LSRs for number portability. You can get an entirely VoIP handoff to them. As for any to any interconnection, without some sort of central authority this will take the already terrible security of the PSTN and make it even worse. Why pay a carrier to dump tons of fraud calls on and risk getting shut off when you can blast it out yourself, SMTP style? I mean, i love the concept in theory but in practice we need an arbiter of the trust relationships between us to maintain the integrity of the network, what little it even has at this point. -Paul
On Dec 5, 2015, at 14:41, Erik Flournoy <erik at eespro.com> wrote:
What's Inteliquent's Position? PSTN 2.0 is a great way to describe the upgraded regulation of a system that's not invented to be free to the masses but more so profited by one large mass. I just can't wrap my head around how the government supposedly broke up the bells years ago but for the past century Neustar has been the hub of all the numbering and telcordia the guideline to how you do telecom. A guideline that is licensed and not free to the masses.
I continually see smaller CLEC get eaten alive by the ILEC or all the regulatory fees that are based around the telecom system of my great grandparents. Example to order services from most ILEC's you need access to telecordia to get CLLI codes or NC/NCI codes all information owned and licensed by one company.
On Sat, Dec 5, 2015 at 11:29 AM, Alex Balashov <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote: On 12/05/2015 04:28 PM, Paul Timmins wrote:
Are you ignoring the position Intelliquent has in the market?
Am I?
-- 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.evaristesys.com/>, http://www.csrpswitch.com/ <http://www.csrpswitch.com/> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 12/05/2015 04:46 PM, Paul Timmins wrote:
They operate a competing interconnection service that you can use to in some circumstances entirely replace interaction with the RBOC
They do indeed, but when you look at their model, doesn't it ultimately redound to the benefit of the same old RBOC and wireless mafia? I don't see what Inteliquent is doing as effecting any material structural changes or, as Erik said, "new or more up to date solutions that allow smaller carriers to operate." -- 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/
On Dec 5, 2015, at 14:50, Alex Balashov <abalashov at evaristesys.com> wrote:
They do indeed, but when you look at their model, doesn't it ultimately redound to the benefit of the same old RBOC and wireless mafia?
Eh - their ITSP interconnection service which they don't really talk about on their website since the product is kind of new seems relatively interesting. It adheres to the same sort of centralized infrastructure that exists in the PSTN but there's many circumstances where many of us CLECs exchange calls across it without charging each other anything (bill and keep), even big ones like Comcast. I'd say probably 1/3 to 1/2 of our traffic ends up never touching RBOC equipment. (As for intralata and interlata traffic, well that's a different monster and we're gravitating toward bill and keep on that, kicking and screaming the whole time)
I don't see what Inteliquent is doing as effecting any material structural changes or, as Erik said, "new or more up to date solutions that allow smaller carriers to operate."
I think getting a combined trunk group with all your calls on it is a big enough game changer to at least call it PSTN 1.5. :)
On 12/05/2015 04:55 PM, Paul Timmins wrote:
I'd say probably 1/3 to 1/2 of our traffic ends up never touching RBOC equipment.
Oh, okay, so there's been some progress in this area since I last looked around. I suppose it's moderated by the degree to which the Tier 1 CLEC oligopoly that feeds the VoIP supply chain is willing to participate. And it sounds like their willingness may be higher than I imagined. -- 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/
T-Mobile is entirely switching away from TDM connectivity and using IQ for their entire TDM interop from what a little birdie told me. That alone seemed like a pretty big paradigm shift.
On Dec 5, 2015, at 15:00, Alex Balashov <abalashov at evaristesys.com> wrote:
On 12/05/2015 04:55 PM, Paul Timmins wrote:
I'd say probably 1/3 to 1/2 of our traffic ends up never touching RBOC equipment.
Oh, okay, so there's been some progress in this area since I last looked around.
I suppose it's moderated by the degree to which the Tier 1 CLEC oligopoly that feeds the VoIP supply chain is willing to participate. And it sounds like their willingness may be higher than I imagined.
-- 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
TDM only stands for faxing and paying FCC fees. If a packet transverses your entire network as a packet then it's never a toll charge. It's a packet. This is why they are pressing hard to tax the internet more because the voice money games are slowing decreasing. It's a data war now. On Sat, Dec 5, 2015 at 12:02 PM, Paul Timmins <paul at timmins.net> wrote:
T-Mobile is entirely switching away from TDM connectivity and using IQ for their entire TDM interop from what a little birdie told me. That alone seemed like a pretty big paradigm shift.
On Dec 5, 2015, at 15:00, Alex Balashov <abalashov at evaristesys.com> wrote:
On 12/05/2015 04:55 PM, Paul Timmins wrote:
I'd say probably 1/3 to 1/2 of our traffic ends up never touching RBOC equipment.
Oh, okay, so there's been some progress in this area since I last looked around.
I suppose it's moderated by the degree to which the Tier 1 CLEC oligopoly that feeds the VoIP supply chain is willing to participate. And it sounds like their willingness may be higher than I imagined.
-- 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
I'll just be happy when we come up with a safe way to handle T.38 and G.722 interop. Forward motion is being made on that too, thankfully. (I hate to keep talking inteliquent up, I don't work for them and don't get money from them, but they've been very forward looking any time I've worked with them. They support G.722 transport between enabled carriers, etc. If they transcoded to wireless wideband codecs i'd probably marry them.). -Paul
On Dec 5, 2015, at 15:05, Erik Flournoy <erik at eespro.com> wrote:
TDM only stands for faxing and paying FCC fees. If a packet transverses your entire network as a packet then it's never a toll charge. It's a packet. This is why they are pressing hard to tax the internet more because the voice money games are slowing decreasing. It's a data war now.
On Sat, Dec 5, 2015 at 12:02 PM, Paul Timmins <paul at timmins.net <mailto:paul at timmins.net>> wrote: T-Mobile is entirely switching away from TDM connectivity and using IQ for their entire TDM interop from what a little birdie told me. That alone seemed like a pretty big paradigm shift.
On Dec 5, 2015, at 15:00, Alex Balashov <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com>> wrote:
On 12/05/2015 04:55 PM, Paul Timmins wrote:
I'd say probably 1/3 to 1/2 of our traffic ends up never touching RBOC equipment.
Oh, okay, so there's been some progress in this area since I last looked around.
I suppose it's moderated by the degree to which the Tier 1 CLEC oligopoly that feeds the VoIP supply chain is willing to participate. And it sounds like their willingness may be higher than I imagined.
-- 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.evaristesys.com/>, http://www.csrpswitch.com/ <http://www.csrpswitch.com/> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
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/
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
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 <mailto: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.evaristesys.com/>, http://www.csrpswitch.com/ <http://www.csrpswitch.com/> _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 12/05/2015 05:19 PM, Paul Timmins wrote:
have random endpoints hit your network.
As SIP security currently works, this goes under "no. just no." So, "just route directly to each other via packets" is an understandable but very naive notion, IMHO. -- 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/
Even BGP is not a decentralised, democratic, peer-to-peer utopia. Routes are distributed down in a rather hierarchical fashion; effectively, an oligopoly of global Tier 1 backbone operators ends up the clearinghouse. And the weaknesses and vulnerabilities in BGP to the extent that it IS a very large "circle of trust" - though, as I said, the degree to which this is actually true is frequently exaggerated - suggest it's not a great model to emulate for voice/multimedia sessions. -- 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/
Using BGP VERY Broadly here just as a peering example is all not how it actually routes. On Sat, Dec 5, 2015 at 12:27 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
Even BGP is not a decentralised, democratic, peer-to-peer utopia. Routes are distributed down in a rather hierarchical fashion; effectively, an oligopoly of global Tier 1 backbone operators ends up the clearinghouse.
And the weaknesses and vulnerabilities in BGP to the extent that it IS a very large "circle of trust" - though, as I said, the degree to which this is actually true is frequently exaggerated - suggest it's not a great model to emulate for voice/multimedia sessions.
-- 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
On 12/05/2015 05:30 PM, Erik Flournoy wrote:
Using BGP VERY Broadly here just as a peering example is all not how it actually routes.
Alas, the devil is precisely in the details, not the broad examples. I don't think the rest of the industry agrees with you. As I said in my previous message, even in BGP, there is a de facto curation function performed by a relatively small number of Tier 1 players. If one of them doesn't bless your prefix announcement, it's not circling the globe. -- Alex -- 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/
Paul I think direct switch to switch would work great especially with IPv6. There would have to be a list kinda like the SS7 list that is maintained and updated but with the correct certificate exchanges it could work. You would essentially have to keep your upstream provider happy. Unless of course you own the entire network ;-) On Sat, Dec 5, 2015 at 12:22 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 12/05/2015 05:19 PM, Paul Timmins wrote:
have random endpoints hit your network.
As SIP security currently works, this goes under "no. just no."
So, "just route directly to each other via packets" is an understandable but very naive notion, IMHO.
-- 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/
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
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 <paul at timmins.net <mailto: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 <mailto: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 <mailto: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 <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 at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
I think you may have missed the main point of the ILEC proposals to ?modernize?. They still propose, post-?modernization?, to force CLECs to interconnect with TDM facilities and SS7 at each tandem as they have to today. That?s a huge revenue stream and they?re not going to willingly give that up. Their ?modernization? proposal is simply ?We want to get rid of all UNEs? in disguise. It?s totally anti-competitive. AT&T simply wants to take that wire that?s in the ground today that must be made available for UNEs and divest that wire to one of its subsidiaries which is not an ILEC. They will use that existing copper to provide both legacy and next-gen services but since it is no longer owned by the ILEC it?s no longer subject to being used for UNEs by CLECs. Viola! Network modernized! The old monopoly is new again and they didn?t even have to invest in new infrastructure. Today, both AT&T and Verizon are still claiming that they are not technically capable of interconnecting over IP. In a recent proceeding that I was involved in http://www.floridapsc.com/utilities/telecomm/naats/NAATS_results.aspx? <http://www.floridapsc.com/utilities/telecomm/naats/NAATS_results.aspx?&start...> &startDate=4/4/2014&endDate=5/4/2016&numCos=1&compcode1=TY058%20&agreementType=ARBITRATION AT&T/Bellsouth claimed that it was ?impossible? for it to provide our dispute IDs to us when it issues billing in response to our valid billing disputes. ?Impossible?. It made many similar claims as well in this proceeding. This is the same standard of ?impossible? that they claim about interconnecting over IP, even though it?s clear that AT&T has other subsidiaries that do it every day. They think they can define what terms mean, like ?impossible?. Beware of any such proposals from the ILECs. That term ?modernization? as they use it doesn?t mean what you think it means. Mike Mike Ray, MBA, CNE, CTE Astro Companies, LLC 11523 Palm Brush Trail #401 Lakewood Ranch, FL 34202 DIRECT: call or text 941 600-0207 http://www.astrocompanies.com From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Pete E Sent: Monday, December 7, 2015 12:01 PM To: Paul Timmins <paul at timmins.net> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE 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 <mailto: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 <mailto: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 <mailto: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 <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 at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
----- Original Message -----
From: "Mike Ray, MBA, CNE, CTE" <mike at astrocompanies.com>
I think you may have missed the main point of the ILEC proposals to ?modernize?. They still propose, post-?modernization?, to force CLECs to interconnect with TDM facilities and SS7 at each tandem as they have to today. That?s a huge revenue stream and they?re not going to willingly give that up. Their ?modernization? proposal is simply ?We want to get rid of all UNEs? in disguise. It?s totally anti-competitive. AT&T simply wants to take that wire that?s in the ground today that must be made available for UNEs and divest that wire to one of its subsidiaries which is not an ILEC. They will use that existing copper to provide both legacy and next-gen services but since it is no longer owned by the ILEC it?s no longer subject to being used for UNEs by CLECs. Viola! Network modernized! The old monopoly is new again and they didn?t even have to invest in new infrastructure.
Roughly akin to what they were trying to do after Sandy in NY, shifting customers from regulated copper to unreg subsidiary (read: FiOS) fiber, IIRC. Luckily, a statistically significant number of customers told them to fold it until it was all sharp corners, and shove it SO FAR UP their... er, what now? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
Pete Count me in for testing and development. On Dec 7, 2015 7:01 AM, "Pete E" <peeip989 at gmail.com> 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
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
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/ ---------------------------------------------------------------------------
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
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
On 12/07/2015 04:42 PM, Peter Beckman wrote:
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.
This would probably be fixable if all DIDs from ULCs were delegated out of larger blocks that fall on decimal boundaries, which would be analogous to an opaque BGP announcement of a shorter prefix by an upstream aggregator. But, because many numbers are ported in, this would be akin to announcing lots of /32s and, as you mentioned, without the critical component of physical connections constraining the routing topology. Any such scheme would have to incorporate the notion of a reseller chain into its mechanics and a security model that allows downstream resellers to modify the physical parameters of their receipt of the call but not the fundamental routing chain. -- Alex -- 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/
And who has the rights to announce? With IP, you are disincentivized from having all the traffic flow through one's network if it can be avoided, because that is additional cost that the customer doesn't want to pay and additional overhead and management for the IP provider. So they say "hey, this is our IP space, but we will delegate it to you and you can announce it to the Internet" and that way the traffic goes a hopefully more direct and cost-controlled route. With phone numbers, carriers get to charge a fee for the privilege of having calls flow through their network. They've always gotten a fee. The whole industry relies on that fee. And it is because they "own" the phone numbers from the central authority, NANPA. And that central authority holds the LRN database. Which is their carrier of record for a phone number. To be the carrier of record, you have to be a CLEC or ILEC and "pay" to be trusted by the central authority. But in reality, the LRN database isn't the business that provides the end-user service. What we could do is simply create a numbering space that worked on existing phones. What if we had a numbering system that enabled a device to have an address that worked everywhere? Hmmm... don't we have that? IPv6? "500" numbers? https://www.neustar.biz/blog/story-500-numbers Alas... the carriers have control of this industry. They won't delegate authority to their resellers because they would lose revenue, and they already have the infrastructure to handle the traffic. We can try and build a system to circumvent them, but it must automatically and cryptographically ensure that the company that says "Send calls to this number to this set of IP addresses" actually is responsible for the end-user termination. And since any customer in the chain can perform such a registration, with no real automated way to determine hierarchy, the system will be flawed. NANPA -> Level3 -> reseller A -> reseller B -> reseller C -> end-user Level3 could say "Send calls to me!" with this system Reseller A, B, or C (or all three!) could say "Send calls to me!" A sophisticated end-user could say "Send calls to me!" But unless we know that hierarchy above, who is right? Which company cuts out the most middle-men? And I'm pretty sure that any reseller chain would require the participation of all resellers, and frankly, they EACH get a tenth of a cent or more per minute, so WHY would they? And how would the purchaser know or determine the reseller chain? Most companies do not disclose their ULCs. Plus if any of the resellers offer value-add services to the receiver, those are lost in this scenario. Though many of us may do all the value-add on our ends, many do not. But if we can figure it out, man will it make troubleshooting calls a lot more simple (though simultaneously complicated because you have to call someone else for each problematic call, but at least no more "we're waiting on the ULC to respond"). Beckman On Mon, 7 Dec 2015, Alex Balashov wrote:
On 12/07/2015 04:42 PM, Peter Beckman wrote:
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.
This would probably be fixable if all DIDs from ULCs were delegated out of larger blocks that fall on decimal boundaries, which would be analogous to an opaque BGP announcement of a shorter prefix by an upstream aggregator.
But, because many numbers are ported in, this would be akin to announcing lots of /32s and, as you mentioned, without the critical component of physical connections constraining the routing topology.
Any such scheme would have to incorporate the notion of a reseller chain into its mechanics and a security model that allows downstream resellers to modify the physical parameters of their receipt of the call but not the fundamental routing chain.
-- Alex
-- 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
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
In this scenario: NANPA -> Level3 -> reseller A -> reseller B -> reseller C -> end-user Only reseller C and the end user knows where the chain ends. So, what about some OSPF-like mechanism? Let's say that in this scenario Level3 has direct connections with both resellers A and C. It would know that it has two paths to C (the terminating switch) but would prefer the direct link to C unless it became unavailable.
On Dec 7, 2015, at 21:09, Peter Beckman <beckman at angryox.com> wrote:
NANPA -> Level3 -> reseller A -> reseller B -> reseller C -> end-user
?I could also see the Tier 1s enthusiastically supporting a system that appears to rationalise anyone below themselves out of the supply chain. :-)? They're getting better and better at delivering smaller transactions. It started out with the stereotypical, "Level3 won't talk to you unless you've got at least $25k/mo to commit", but where we are today is that just about anyone can have MFN pricing with a $500 deposit and a miniscule commit. Soon anyone with $10 will be able to terminate US domestic at $0.001. The proposed system might just hasten this process along, as the big CLECs that feed the industry ask, "Why do we need resellers again?" -- 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/ Sent?from?my?BlackBerry.
On Mon, 7 Dec 2015, Alex Balashov wrote:
The proposed system might just hasten this process along, as the big CLECs that feed the industry ask, "Why do we need resellers again?"
Flattening out the tree sure would help with speed of ports and troubleshooting. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Reseller C and the end user knows where the chain ends, but how do WE know that reseller C and end-user are honest? And how do we know that when reseller B says "no no, send calls here!" they are being bad actors when really the calls should skip reseller B and go directly to reseller C or end-user, if they so choose? On Mon, 7 Dec 2015, Peter E wrote:
In this scenario:
NANPA -> Level3 -> reseller A -> reseller B -> reseller C -> end-user
Only reseller C and the end user knows where the chain ends. So, what about some OSPF-like mechanism? Let's say that in this scenario Level3 has direct connections with both resellers A and C. It would know that it has two paths to C (the terminating switch) but would prefer the direct link to C unless it became unavailable.
On Dec 7, 2015, at 21:09, Peter Beckman <beckman at angryox.com> wrote:
NANPA -> Level3 -> reseller A -> reseller B -> reseller C -> end-user
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Well, I think that's where Mark's Bitcoin-ish idea comes in. I'm sure he can explain it better than I can. On Dec 8, 2015, at 00:35, Peter Beckman <beckman at angryox.com> wrote: Reseller C and the end user knows where the chain ends, but how do WE know that reseller C and end-user are honest?
Can I get a count of how many folks have SPID? There is a process that some major carriers that were once small used to do exactly what we are describing. The routing issues happen all the time even if it's not a reseller amongst CLECs, ILEC everyday even when NPAC says the number goes to xyz the ILEC ultimately controls 75% of where the call goes on the tandem. On Tue, Dec 8, 2015 at 4:34 AM, Peter E <peeip989 at gmail.com> wrote:
Well, I think that's where Mark's Bitcoin-ish idea comes in. I'm sure he can explain it better than I can.
On Dec 8, 2015, at 00:35, Peter Beckman <beckman at angryox.com> wrote:
Reseller C and the end user knows where the chain ends, but how do WE know that reseller C and end-user are honest? _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Not us. Is this topic interesting enough to everyone to try and formalize and develop? (i.e. take it off the email list and do something more)? Maybe meet up at SIPNOC? (though that's 1/2 year away). We'd be happy to host something (say, a two-day meeting) here sooner, if there's interest. On Tue, Dec 8, 2015 at 11:57 AM, Erik Flournoy <erik at eespro.com> wrote:
Can I get a count of how many folks have SPID? There is a process that some major carriers that were once small used to do exactly what we are describing. The routing issues happen all the time even if it's not a reseller amongst CLECs, ILEC everyday even when NPAC says the number goes to xyz the ILEC ultimately controls 75% of where the call goes on the tandem.
On Tue, Dec 8, 2015 at 4:34 AM, Peter E <peeip989 at gmail.com> wrote:
Well, I think that's where Mark's Bitcoin-ish idea comes in. I'm sure he can explain it better than I can.
On Dec 8, 2015, at 00:35, Peter Beckman <beckman at angryox.com> wrote:
Reseller C and the end user knows where the chain ends, but how do WE know that reseller C and end-user are honest? _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
This is a slight topic change, but at SIPNOC for the last few years, FCC and FCC-connected people have come and talked about the plans for transitioning. My general sense is that the they're considering adding something like an IP address to the NPAC data structure. There's a new IETF working group, "Modern":
This list is for discussion of systems required to support the management of telephone numbers after traditional telephone functions have migrated to the Internet. In particular, this list considers Internet protocol interfaces needed to register, provision and audit data related to telephone numbers. It is expected that discussion will also involve ongoing development of experimental systems to implement these functions.
A big thrust there is to develop Internet protocols to talk to all the old-school telecom systems that have kept us going through the 1980s-present. They're also talking a lot there about who "owns" telephone numbers. Here are some good introductory slides from the IETF meeting in March: https://www.ietf.org/proceedings/92/slides/slides-92-modern-0.pdf
On Dec 9, 2015, at 10:46 , Pete Eisengrein <peeip989 at gmail.com> wrote:
Not us.
Is this topic interesting enough to everyone to try and formalize and develop? (i.e. take it off the email list and do something more)? Maybe meet up at SIPNOC? (though that's 1/2 year away). We'd be happy to host something (say, a two-day meeting) here sooner, if there's interest.
On Tue, Dec 8, 2015 at 11:57 AM, Erik Flournoy <erik at eespro.com <mailto:erik at eespro.com>> wrote: Can I get a count of how many folks have SPID? There is a process that some major carriers that were once small used to do exactly what we are describing. The routing issues happen all the time even if it's not a reseller amongst CLECs, ILEC everyday even when NPAC says the number goes to xyz the ILEC ultimately controls 75% of where the call goes on the tandem.
On Tue, Dec 8, 2015 at 4:34 AM, Peter E <peeip989 at gmail.com <mailto:peeip989 at gmail.com>> wrote: Well, I think that's where Mark's Bitcoin-ish idea comes in. I'm sure he can explain it better than I can.
On Dec 8, 2015, at 00:35, Peter Beckman <beckman at angryox.com <mailto:beckman at angryox.com>> wrote:
Reseller C and the end user knows where the chain ends, but how do WE know that reseller C and end-user are honest? _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I don't mean to be a Negative Nancy, but I am concerned that some of may not realise how many times this conversation has played out before, in various permutations. The PSTN is dead, long live the PSTN, etc. The enthusiastic proclamation of a forum/vehicle/working committee/consortium/federation/association for Truly Next Generation VoIP Peering, For Real This Time--sometimes with great fanfare--is at least a once-annual occurrence, if not more often. In the end, it always dies and withers away, because in the end, nobody really cares what a consortium of small operators think. Without buy-in from a major-league industry actor, the one-year survival rate on these visionary initiatives is extremely low. I'm not saying it shouldn't be tried again. I would just be realistic about the possibilities for large, cosmological-type change. The reality is that almost all ITSPs make and receive almost all of their calls to and from the PSTN, in one way or another. As long as that's the case, there won't be the critical mass for anyone to sponsor Truly Next Generation VoIP Peering, For Real This Time. -- Alex -- 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/
<delurks> Sigh, yes I recall sitting at an event hosted by Jeff Pulver in NYC, back in 2009. "The future is here!" cried one and all, just not yet. OTOH, at least the very backward looking have largely stopped the plaintive bleating about "spectral efficiency" and bandwidth constraints. I for one would love to have this discussion live in a podcast or hangout...if anyone else is interested. Michael Graves mgraves at mstvp.com http://www.mgraves.org o(713) 861-4005 c(713) 201-1262 sip:mgraves at mjg.onsip.com skype mjgraves </delurks> --------- Original Message --------- Subject: Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE From: "Alex Balashov" <abalashov at evaristesys.com> Date: 12/9/15 11:17 am To: voiceops at voiceops.org I don't mean to be a Negative Nancy, but I am concerned that some of may not realise how many times this conversation has played out before, in various permutations. The PSTN is dead, long live the PSTN, etc. The enthusiastic proclamation of a forum/vehicle/working committee/consortium/federation/association for Truly Next Generation VoIP Peering, For Real This Time--sometimes with great fanfare--is at least a once-annual occurrence, if not more often. In the end, it always dies and withers away, because in the end, nobody really cares what a consortium of small operators think. Without buy-in from a major-league industry actor, the one-year survival rate on these visionary initiatives is extremely low. I'm not saying it shouldn't be tried again. I would just be realistic about the possibilities for large, cosmological-type change. The reality is that almost all ITSPs make and receive almost all of their calls to and from the PSTN, in one way or another. As long as that's the case, there won't be the critical mass for anyone to sponsor Truly Next Generation VoIP Peering, For Real This Time. -- Alex -- 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
On 12/09/2015 01:07 PM, mgraves at mstvp.com wrote:
OTOH, at least the very backward looking have largely stopped the plaintive bleating about "spectral efficiency" and bandwidth constraints.
I don't know much of anything about wireless, and I assume spectrum and bandwidth concerns are still real factors. However, if the industry plans to shift calling to LTE, it clearly isn't too much of a limiting factor? -- 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/
--------- Original Message --------- Subject: Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE From: "Alex Balashov" <abalashov at evaristesys.com> Date: 12/9/15 12:10 pm To: mgraves at mstvp.com, voiceops at voiceops.org Cc: "Randy Resnick" <randulo at randulo.com> On 12/09/2015 01:07 PM, mgraves at mstvp.com wrote:
OTOH, at least the very backward looking have largely stopped the plaintive bleating about "spectral efficiency" and bandwidth constraints.
I don't know much of anything about wireless, and I assume spectrum and bandwidth concerns are still real factors. However, if the industry plans to shift calling to LTE, it clearly isn't too much of a limiting factor? There was a time where certain parties from a large wireless carrier were sounding the alarm about spectral waste, even as their very own marketing teams were extolling the virtues of watching television on your mobile phone. This sort of talking out of both sides tends to destroy credibility. That same company recently launched their own streaming video service...cuz how hard could it be, right? T-Mobile doesn't even count some streaming video against the customers data allocation. Of course there are very real constraints, but the sky has yet to fall. Michael Graves mgraves at mstvp.com http://www.mgraves.org o(713) 861-4005 c(713) 201-1262 sip:mgraves at mjg.onsip.com skype mjgraves
On 12/09/2015 01:16 PM, mgraves at mstvp.com wrote:
There was a time where certain parties from a large wireless carrier were sounding the alarm about spectral waste, even as their very own marketing teams were extolling the virtues of watching television on your mobile phone. This sort of talking out of both sides tends to destroy credibility.
Oh, I see. Well, makes sense to me! By the time the spectrum has been consumed by the wireless operator's own services, there's none left for third-party applications. -- 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/
Argh. I've come up with three different ideas in this email, and deleted them all. 1. Carriers do not want to disclose which DIDs they service. A company's customers might not want an easy way for callers to find out that the number is associated with that business, or that the number is temporary. 2. Carriers do not want to disclose how many DIDs they service. Competitive behind-the-curtain reasons. 3. Carriers are wary of smaller carriers, and are concerned with having to figure out who to deal with if incoming calls from their networks are failing and there isn't an SLA or guaranteed response time, unlike their bigger carriers. 4. We all generally agree that another "centralized" system is just replacing one for another. What I believe we agree on: 1. It's stupid for a phone call to go through 19 hops of carriers and resellers, it makes troubleshooting a pain, adds latency, and adds complexity. But it is only stupid if there is no value added by that hop. 2. The PSTN is too ingrained into our global society to replace it. 3. Ownership of a DID in NANP is so vague that it comes down to who answers the phone at a given point in time, wins. Maybe. 4. Porting should be unbelievably simple and easily automatable. 5. The data in the LERG should be free, since taxes and law pay for the data that lies within. 6. Centralized authorities and monopolies do not innovate. What we can do: 1. Write a contract template and make it public that: * Outlines the intent to send traffic directly, in either direction, destined for published DIDs at either carrier * Prohibits the payment, in either direction, for such traffic * Outlines the SLAs and Escalation Procedures for both parties * Clearly documents how to end the contract and remedies for lack of timely technical termination * Handles 90% of issues that may come up in the course of avoiding the PSTN for origination and termination traffic 2. Propose a standard non-public method of publishing a machine-readable and parsable configuration that includes: * DIDs available for direct termination * DIDs owned that SHOULD NOT be directly terminated * When the config was created/generated * The frequency of the config generation * The endpoints and rules for terminating calls to the carrier * Enforces the use of legally binding arbitration with a very small window to resolve disputes 3. Use the contract and standard to start sending traffic directly to each other. At some point we can get to the point of solving the "who is best suited to receive this call" problem. This moves the "trust" to between the two parties, not some centralized management. And while bad things can still happen, aren't they already? This instantly provides the ability to remove the cost of termination and origination, and while adding to the number of relationships that are required in order to reach all phone numbers, can move us toward decentralization of the telephony world. Beckman PS Man that last sentence sounds cheesy. On Wed, 9 Dec 2015, mgraves at mstvp.com wrote:
<delurks>
Sigh, yes I recall sitting at an event hosted by Jeff Pulver in NYC, back in 2009. "The future is here!" cried one and all, just not yet.
OTOH, at least the very backward looking have largely stopped the plaintive bleating about "spectral efficiency" and bandwidth constraints.
I for one would love to have this discussion live in a podcast or hangout...if anyone else is interested.
Michael Graves mgraves at mstvp.com http://www.mgraves.org o(713) 861-4005 c(713) 201-1262 sip:mgraves at mjg.onsip.com skype mjgraves
</delurks> --------- Original Message --------- Subject: Re: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE From: "Alex Balashov" <abalashov at evaristesys.com> Date: 12/9/15 11:17 am To: voiceops at voiceops.org
I don't mean to be a Negative Nancy, but I am concerned that some of may not realise how many times this conversation has played out before, in various permutations. The PSTN is dead, long live the PSTN, etc.
The enthusiastic proclamation of a forum/vehicle/working committee/consortium/federation/association for Truly Next Generation VoIP Peering, For Real This Time--sometimes with great fanfare--is at least a once-annual occurrence, if not more often.
In the end, it always dies and withers away, because in the end, nobody really cares what a consortium of small operators think. Without buy-in from a major-league industry actor, the one-year survival rate on these visionary initiatives is extremely low.
I'm not saying it shouldn't be tried again. I would just be realistic about the possibilities for large, cosmological-type change. The reality is that almost all ITSPs make and receive almost all of their calls to and from the PSTN, in one way or another. As long as that's the case, there won't be the critical mass for anyone to sponsor Truly Next Generation VoIP Peering, For Real This Time.
-- Alex
-- 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
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
Peter - This instantly provides the ability to remove the cost of termination and
origination, and while adding to the number of relationships that are required in order to reach all phone numbers, can move us toward decentralization of the telephony world.
Beckman
PS Man that last sentence sounds cheesy.
I dunno. You could add something about social necessity to cheese it up a bit but, given the amount of good sense and observation elsewhere in your email, I, for one, will forgive you a good deal more curdled milk than this. --Dave
I'd add a #7 to "what I believe we agree upon": 7. The current PSTN prevents and the new world order offers, or at least allows for, high def and video codecs, and other cool new things yet to be imagined. On Wed, Dec 9, 2015 at 1:58 PM, Peter Beckman <beckman at angryox.com> wrote:
Argh. I've come up with three different ideas in this email, and deleted them all.
1. Carriers do not want to disclose which DIDs they service. A company's customers might not want an easy way for callers to find out that the number is associated with that business, or that the number is temporary.
2. Carriers do not want to disclose how many DIDs they service. Competitive behind-the-curtain reasons.
3. Carriers are wary of smaller carriers, and are concerned with having to figure out who to deal with if incoming calls from their networks are failing and there isn't an SLA or guaranteed response time, unlike their bigger carriers.
4. We all generally agree that another "centralized" system is just replacing one for another.
What I believe we agree on:
1. It's stupid for a phone call to go through 19 hops of carriers and resellers, it makes troubleshooting a pain, adds latency, and adds complexity. But it is only stupid if there is no value added by that hop.
2. The PSTN is too ingrained into our global society to replace it.
3. Ownership of a DID in NANP is so vague that it comes down to who answers the phone at a given point in time, wins. Maybe.
4. Porting should be unbelievably simple and easily automatable.
5. The data in the LERG should be free, since taxes and law pay for the data that lies within.
6. Centralized authorities and monopolies do not innovate.
What we can do:
1. Write a contract template and make it public that: * Outlines the intent to send traffic directly, in either direction, destined for published DIDs at either carrier * Prohibits the payment, in either direction, for such traffic * Outlines the SLAs and Escalation Procedures for both parties * Clearly documents how to end the contract and remedies for lack of timely technical termination * Handles 90% of issues that may come up in the course of avoiding the PSTN for origination and termination traffic
2. Propose a standard non-public method of publishing a machine-readable and parsable configuration that includes: * DIDs available for direct termination * DIDs owned that SHOULD NOT be directly terminated * When the config was created/generated * The frequency of the config generation * The endpoints and rules for terminating calls to the carrier * Enforces the use of legally binding arbitration with a very small window to resolve disputes
3. Use the contract and standard to start sending traffic directly to each other.
At some point we can get to the point of solving the "who is best suited to receive this call" problem.
This moves the "trust" to between the two parties, not some centralized management. And while bad things can still happen, aren't they already?
This instantly provides the ability to remove the cost of termination and origination, and while adding to the number of relationships that are required in order to reach all phone numbers, can move us toward decentralization of the telephony world.
Beckman
PS Man that last sentence sounds cheesy.
On 12/05/2015 05:14 PM, Erik Flournoy wrote:
allow carriers to directly connect via packets
This is more complicated than it seems, although part of that is definitely because the incumbents want it to be. Still, see prior 2000s-era art on "federated domain peering policy control" and the like. Proceeding from the assumption that voice is a public utility and has regulatory involvement (e.g. public safety, civil emergencies), and not World of Warcraft, leads to the conclusion that some sort of systematic, integrated admission, egress and routing policy control is needed. There hasn't been anything like industry-wide agreement as to what those things should be. Eventually someone like Inteliquent shows up and decides for you, with a view to their bottom line, of course. -- Alex -- 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/
----- Original Message -----
From: "Alex Balashov" <abalashov at evaristesys.com>
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.
And my heart bleeds for them. But so has my wallet, for decades; they've gotten their ROI. And no company is guaranteed the right to continue to make a living, by the law, in whatever field it is currently engaged in. Didn't a Supreme Court Justice say that in an opinion? Cheers, -- jra -- Jay R. Ashworth Baylink jra at baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274
On 12/07/2015 02:22 PM, Jay R. Ashworth wrote:
And my heart bleeds for them.
But so has my wallet, for decades; they've gotten their ROI.
:-) I didn't mean to legitimate their crying poor house. I was just illuminating their reasoning for resisting OTT and commoditisation. -- 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/
On 12/07/2015 02:22 PM, Jay R. Ashworth wrote:
And no company is guaranteed the right to continue to make a living, by the law, in whatever field it is currently engaged in. Didn't a Supreme Court Justice say that in an opinion?
By that same token, though, there is some question as to whether companies have an obligation to streamline or make maximally convenient the process by which their competitors cannibalise their profit margins. :-) Of course, we've all churned through the rationale here. Inasmuch as the telecom majors take in billions in taxpayer subsidies of all sorts, they are something tantamount to a public utility, they are - notionally - required to open up their networks to uses we would otherwise expect them to reject. -- Alex -- 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/
Paul, Your description of Inteliquent makes a lot of since. It's essential how the internet was born via free interconnections at hub locations. Of course you paid to get to the location but once you built your fiber or back then copper path you just plugged in. On Sat, Dec 5, 2015 at 11:55 AM, Paul Timmins <paul at timmins.net> wrote:
On Dec 5, 2015, at 14:50, Alex Balashov <abalashov at evaristesys.com> wrote:
They do indeed, but when you look at their model, doesn't it ultimately redound to the benefit of the same old RBOC and wireless mafia?
Eh - their ITSP interconnection service which they don't really talk about on their website since the product is kind of new seems relatively interesting. It adheres to the same sort of centralized infrastructure that exists in the PSTN but there's many circumstances where many of us CLECs exchange calls across it without charging each other anything (bill and keep), even big ones like Comcast. I'd say probably 1/3 to 1/2 of our traffic ends up never touching RBOC equipment.
(As for intralata and interlata traffic, well that's a different monster and we're gravitating toward bill and keep on that, kicking and screaming the whole time)
I don't see what Inteliquent is doing as effecting any material structural changes or, as Erik said, "new or more up to date solutions that allow smaller carriers to operate."
I think getting a combined trunk group with all your calls on it is a big enough game changer to at least call it PSTN 1.5. :)
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 12/05/2015 05:01 PM, Erik Flournoy wrote:
Your description of Inteliquent makes a lot of since. It's essential how the internet was born via free interconnections at hub locations. Of course you paid to get to the location but once you built your fiber or back then copper path you just plugged in.
Yeah, but this idea isn't new. It's a very obvious logical leap for VoIP. You can find exciting! magnanimous! proposals! for VoIP peering going back to the turn of the century. They were all hampered by a lack of critical mass: so you connect to NexGenIPTopia, then what? Who are you going to pass traffic to? A handful of other no-name ITSPs? What makes Inteliquent more viable in this regard is that wireless majors and folks like Comcast - evidently - participate. However, I don't see what the small operator really gets out of it, especially if you're talking in big, paradigmatic change terms. So, it's another proprietary tandem, notionally more pleasant than the ILEC to deal with. Okay? -- Alex -- 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/
Alex I think if they remained NEUTRAL like their previous name it could work as an interconnecting place such as BGP peering. we are here to move packets. Now if they start to tax the packets or dig in and say hey that's VoIP we are taxinig the calls then things would change. They did change their name so maybe they aren't so neutral like a data center BGP meeting place. On Sat, Dec 5, 2015 at 12:07 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
On 12/05/2015 05:01 PM, Erik Flournoy wrote:
Your description of Inteliquent makes a lot of since. It's essential
how the internet was born via free interconnections at hub locations. Of course you paid to get to the location but once you built your fiber or back then copper path you just plugged in.
Yeah, but this idea isn't new. It's a very obvious logical leap for VoIP. You can find exciting! magnanimous! proposals! for VoIP peering going back to the turn of the century.
They were all hampered by a lack of critical mass: so you connect to NexGenIPTopia, then what? Who are you going to pass traffic to? A handful of other no-name ITSPs?
What makes Inteliquent more viable in this regard is that wireless majors and folks like Comcast - evidently - participate.
However, I don't see what the small operator really gets out of it, especially if you're talking in big, paradigmatic change terms. So, it's another proprietary tandem, notionally more pleasant than the ILEC to deal with. Okay?
-- Alex
-- 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
Erik, What you're advocating is the well-established notion that voice should be treated as just another Internet application, like HTTP or World of Warcraft, and billed according to the same model, not as a series of per-minute billable events. Technologically, it's rational, but it's an outcome to which the entire incumbent LEC industry is cholerically opposed. Their multibillion dollar lobbying and regulatory capture efforts represent their investment in that opposition. -- Alex -- 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/
You still have to go through Telcordia (now iconectiv) to get CLLI codes, but NC/NCI information is company specific so it's actually the ILEC that documents that information......you just have to know where to go to look for it! Mary Lou Carey BackUP Telecom Consulting 615-791-9969
On December 5, 2015 at 4:41 PM Erik Flournoy <erik at eespro.com> wrote:
What's Inteliquent's Position? PSTN 2.0 is a great way to describe the upgraded regulation of a system that's not invented to be free to the masses but more so profited by one large mass. I just can't wrap my head around how the government supposedly broke up the bells years ago but for the past century Neustar has been the hub of all the numbering and telcordia the guideline to how you do telecom. A guideline that is licensed and not free to the masses.
I continually see smaller CLEC get eaten alive by the ILEC or all the regulatory fees that are based around the telecom system of my great grandparents. Example to order services from most ILEC's you need access to telecordia to get CLLI codes or NC/NCI codes all information owned and licensed by one company.
On Sat, Dec 5, 2015 at 11:29 AM, Alex Balashov <abalashov at evaristesys.com <mailto:abalashov at evaristesys.com> > wrote:
On 12/05/2015 04:28 PM, Paul Timmins wrote:
> > > Are you ignoring the position Intelliquent has in the market?
Am I?
-- 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 <mailto: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
Mary Lou Carey BackUP Telecom Consulting Marylou at backuptelecom.com Office: 615-791-9969 Cell: 615-796-1111
On 12/06/2015 11:31 PM, Mary Lou Carey wrote:
NC/NCI information is company specific so it's actually the ILEC that documents that information......you just have to know where to go to look for it!
Technically, ILECs publish a lot of stuff publicly, to comply with the letter of regulations requiring them to do so. However, most of it is not digestible or usable to those who work outside the world of ILEC provisioning, so it has to be processed into commercial databases like the LERG and LCADS. The same mafia then charges for access to these, for reasons motivated by profit and creating systemic barriers to entry for small competitors. If anyone balks at the seemingly surreal cocktail of having to sell one's kidney for access to notionally public information, the ILECs can always say: "You can download the 90 page local tariff yourself right there from our web site, you just have to know where to look! The commercial databases are just adding value by composing it into readily machine-processable form!" This is one of the most common cop-outs of New Gilded Age sociopaths; "we're complying with the letter of the law, and we reserve the right to charge a reasonable fee for putting the information into a convenient form for you..." Except, there wouldn't be a need to take 90 pages of arcane prose and turn it into a few table rows of values if they did not themselves dictate the rules; there is no "value add" in the LERG because it is a response to a artificial contrivance, a purely invented problem of the ILECs' own deliberate making. It exploits information asymmetries and differences of power between big and small actors in the same way as pseudoscientific chemistry gibberish on early 20th century quack remedies, or the fine print on 264-page subprime mortgage issuance binders. I think that's really the essence of Erik's grievance, and it's a valid one. Sure, you can participate in the PSTN*. * Expensive semi-proprietary decoder ring and beaucoup bucks required. -- Alex -- 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/
Of course, there's a lucrative niche for select third parties that _do_ have the secret decoder ring, or pieces of it. That's summed up by: https://s-media-cache-ak0.pinimg.com/736x/0a/f8/f9/0af8f9ed1fe346266e6b614a8... -- 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/
Haha, that was a fun read! (and pretty accurate)
Technically, ILECs publish a lot of stuff publicly, to comply with the letter of regulations requiring them to do so. However, most of it is not digestible or usable to those who work outside the world of ILEC provisioning, so it has to be processed into commercial databases like the LERG and LCADS. The same mafia then charges for access to these, for reasons motivated by profit and creating systemic barriers to entry for small competitors.
If anyone balks at the seemingly surreal cocktail of having to sell one's kidney for access to notionally public information, the ILECs can always say: "You can download the 90 page local tariff yourself right there from our web site, you just have to know where to look! The commercial databases are just adding value by composing it into readily machine-processable form!"
This is one of the most common cop-outs of New Gilded Age sociopaths; "we're complying with the letter of the law, and we reserve the right to charge a reasonable fee for putting the information into a convenient form for you..." Except, there wouldn't be a need to take 90 pages of arcane prose and turn it into a few table rows of values if they did not themselves dictate the rules; there is no "value add" in the LERG because it is a response to a artificial contrivance, a purely invented problem of the ILECs' own deliberate making. It exploits information asymmetries and differences of power between big and small actors in the same way as pseudoscientific chemistry gibberish on early 20th century quack remedies, or the fine print on 264-page subprime mortgage issuance binders.
I think that's really the essence of Erik's grievance, and it's a valid one. Sure, you can participate in the PSTN*.
* Expensive semi-proprietary decoder ring and beaucoup bucks required.
-- Alex
I can only point out what I pointed out in the FCC comment period - iconnectiv already charges both sides for the LERG, which it solely maintains with an iron grip. It maintains many if not practically all of the standards documents, and now we're proposing (well, too late for future tense) to let them have control over number portability now. The LERG update system and all of its screens, and all the goofy identifiers each held behind their own paywalls and gatekeepers - nothing about it looks to be modernizing any time soon. If you're hoping for forward looking ideas out of this company, you're not going to find them. They have entrenched interest in maintaining the status quo. I'd love for it to be different, but I see this only as more consolidation around the dinosaurs that created this convoluted market to begin with. -Paul
On Dec 5, 2015, at 14:17, Erik Flournoy <erik at eespro.com> wrote:
Aloha Group,
I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
Erik F.
CONFIDENTIALITY NOTICE This e-mail message, including any attachments from EESPRO.com - contain information which is CONFIDENTIAL AND/OR LEGALLY PRIVILEGED. The information is intended only for the use of the individual named above and may not be disseminated to any other party without written permission. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, disclosure, distribution, copying or taking of any action in reliance on the contents of this e-mailed information is strictly prohibited. If you have received this transmission in error, please immediately notify info at eespro.com <mailto:info at eespro.com>, and permanently delete this e-mail and the attachments hereto, if any, and destroy any printout thereof. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Yep, I think we're saying the same thing. And while Inteliquent's role is undeniably interesting, I do think it ultimately fits squarely into PSTN 2.0. On 12/05/2015 04:41 PM, Paul Timmins wrote:
I can only point out what I pointed out in the FCC comment period - iconnectiv already charges both sides for the LERG, which it solely maintains with an iron grip. It maintains many if not practically all of the standards documents, and now we're proposing (well, too late for future tense) to let them have control over number portability now.
The LERG update system and all of its screens, and all the goofy identifiers each held behind their own paywalls and gatekeepers - nothing about it looks to be modernizing any time soon. If you're hoping for forward looking ideas out of this company, you're not going to find them. They have entrenched interest in maintaining the status quo.
I'd love for it to be different, but I see this only as more consolidation around the dinosaurs that created this convoluted market to begin with.
-Paul
On Dec 5, 2015, at 14:17, Erik Flournoy <erik at eespro.com <mailto:erik at eespro.com>> wrote:
Aloha Group,
I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
Erik F.
CONFIDENTIALITY NOTICE This e-mail message, including any attachments from EESPRO.com <http://eespro.com> - contain information which is CONFIDENTIAL AND/OR LEGALLY PRIVILEGED. The information is intended only for the use of the individual named above and may not be disseminated to any other party without written permission. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, disclosure, distribution, copying or taking of any action in reliance on the contents of this e-mailed information is strictly prohibited. If you have received this transmission in error, please immediately notify info at eespro.com <mailto:info at eespro.com>, and permanently delete this e-mail and the attachments hereto, if any, and destroy any printout thereof. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto: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
-- 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/
Paul ---- So Agreed. Voice in the US is a roadmap with profits created for the author to continually profit. I totally believe in standards, heck structure are built around building codes, but when the information is all centrally controlled and not freely available to the masses isn't it essentially another big BELL company? On Sat, Dec 5, 2015 at 11:41 AM, Paul Timmins <paul at timmins.net> wrote:
I can only point out what I pointed out in the FCC comment period - iconnectiv already charges both sides for the LERG, which it solely maintains with an iron grip. It maintains many if not practically all of the standards documents, and now we're proposing (well, too late for future tense) to let them have control over number portability now.
The LERG update system and all of its screens, and all the goofy identifiers each held behind their own paywalls and gatekeepers - nothing about it looks to be modernizing any time soon. If you're hoping for forward looking ideas out of this company, you're not going to find them. They have entrenched interest in maintaining the status quo.
I'd love for it to be different, but I see this only as more consolidation around the dinosaurs that created this convoluted market to begin with.
-Paul
On Dec 5, 2015, at 14:17, Erik Flournoy <erik at eespro.com> wrote:
Aloha Group,
I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
Erik F.
CONFIDENTIALITY NOTICE This e-mail message, including any attachments from EESPRO.com <http://eespro.com> - contain information which is CONFIDENTIAL AND/OR LEGALLY PRIVILEGED. The information is intended only for the use of the individual named above and may not be disseminated to any other party without written permission. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, disclosure, distribution, copying or taking of any action in reliance on the contents of this e-mailed information is strictly prohibited. If you have received this transmission in error, please immediately notify info at eespro.com, and permanently delete this e-mail and the attachments hereto, if any, and destroy any printout thereof. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I happen to have been putting my money where my mouth is in stern agreement with you for the last decade. I guess it's not a terrible time to ask if telcodata.us is lacking information others wish I'd dig up and provide? I've been wanting to get deeper into references and training videos, but indexing information is kind of an obsession of mine. -Paul
On Dec 5, 2015, at 14:45, Erik Flournoy <erik at eespro.com> wrote:
Paul ---- So Agreed. Voice in the US is a roadmap with profits created for the author to continually profit.
I totally believe in standards, heck structure are built around building codes, but when the information is all centrally controlled and not freely available to the masses isn't it essentially another big BELL company?
On Sat, Dec 5, 2015 at 11:41 AM, Paul Timmins <paul at timmins.net <mailto:paul at timmins.net>> wrote: I can only point out what I pointed out in the FCC comment period - iconnectiv already charges both sides for the LERG, which it solely maintains with an iron grip. It maintains many if not practically all of the standards documents, and now we're proposing (well, too late for future tense) to let them have control over number portability now.
The LERG update system and all of its screens, and all the goofy identifiers each held behind their own paywalls and gatekeepers - nothing about it looks to be modernizing any time soon. If you're hoping for forward looking ideas out of this company, you're not going to find them. They have entrenched interest in maintaining the status quo.
I'd love for it to be different, but I see this only as more consolidation around the dinosaurs that created this convoluted market to begin with.
-Paul
On Dec 5, 2015, at 14:17, Erik Flournoy <erik at eespro.com <mailto:erik at eespro.com>> wrote:
Aloha Group,
I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
Erik F.
CONFIDENTIALITY NOTICE This e-mail message, including any attachments from EESPRO.com <http://eespro.com/> - contain information which is CONFIDENTIAL AND/OR LEGALLY PRIVILEGED. The information is intended only for the use of the individual named above and may not be disseminated to any other party without written permission. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, disclosure, distribution, copying or taking of any action in reliance on the contents of this e-mailed information is strictly prohibited. If you have received this transmission in error, please immediately notify info at eespro.com <mailto:info at eespro.com>, and permanently delete this e-mail and the attachments hereto, if any, and destroy any printout thereof. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops <https://puck.nether.net/mailman/listinfo/voiceops>
It has very little to do with actual Technology... it is a lot to do with Money, which is used to influence politics, which is used to influence regulations, which is used to influence business which is used to influence Money. To try to explain it any other way would be naive. Telecom (PSTN) is typically one of the top 3 or top 5 sources of revenue, economic activity, 'economic engine' for any nation in the world... and as such it is very tightly controlled. Yes, Technology developments are challenging the way the industry has been managed, however the battle still goes on in try to make a shift... which is going to happening, and will happen when and only when the folks whose lively hood has been threatened by the technological change either make enough money and get out (very unlikely) or are able to secure their financial futures by shaping regulations and or the business... :) It is a very complicated chess game... and oh if you think the ILEC's are fighting the VOIP (technology change) then think again, they are torn between openly embracing VOIP while using the PSTN as a front for collecting subsidies and continued influence of being able to change the laws..... We are seeing all kinds of interesting shenanigans from the ILEC's.... e.g. delivering POTS services, while billing it as VOIP...... Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: Support at Snappytelecom.net
From: "Erik Flournoy" <erik at eespro.com> To: "voiceops at voiceops.org" <voiceops at voiceops.org> Sent: Saturday, December 5, 2015 4:17:26 PM Subject: [VoiceOps] Future of the Traditional PSTN vs VOIP and VoLTE
Aloha Group, I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
Erik F.
CONFIDENTIALITY NOTICE This e-mail message, including any attachments from EESPRO.com - contain information which is CONFIDENTIAL AND/OR LEGALLY PRIVILEGED. The information is intended only for the use of the individual named above and may not be disseminated to any other party without written permission. If you are not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that any dissemination, disclosure, distribution, copying or taking of any action in reliance on the contents of this e-mailed information is strictly prohibited. If you have received this transmission in error, please immediately notify i nfo at eespro.com , and permanently delete this e-mail and the attachments hereto, if any, and destroy any printout thereof.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 12/05/2015 07:05 PM, Faisal Imtiaz wrote:
It has very little to do with actual Technology
Agreed. I think that's the most important takeaway here. The technology itself is the last and least relevant factor. -- 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/
I hadn't heard of Iconectiv (one "n") before. I found this: http://www.ericsson.com/news/150326-fcc-authorizes-local-number-portability_... Was it Neustar prior to this change? I dream of a process for LNP that goes like this: 1. Customer goes to current carrier, requests a Porting Authorization Code for a number (or set of numbers), either online or over the phone. 2. Current carrier generates a Porting Authorization Code and provides it to the Customer. 3. Customer goes to new carrier, provides Phone Number, Current Carrier, and the Porting Authorization Code. 4. New carrier submits port request to Current Carrer with the Number and Porting Authorization Code. No name, billing address, PIN/SSN, just those three things. 5. Current carrier matches the Porting Authorization Code with their records for that Number and the port goes through. Since all of this is centralized, just have Iconectiv manage it -- the Current Carrier uses an API with Iconectiv to register the number and get a code back. The New Carrier uses the API with Iconectiv with the number and the code to verify porting. Codes expire after x days. Will Iconectiv bring this level of sanity to porting in the NANP? Or will it be more of the same, with rejections for an incorrect street abbreviation? I know it's more complicated than that to implement, but it really ticks me off how difficult it is to port numbers these days if you aren't a Tier 1 wireless carrier. Beckman On Sat, 5 Dec 2015, Erik Flournoy wrote:
Aloha Group,
I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
?No, Iconectiv is what Telcordia's called this week. -- 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/ Sent?from?my?BlackBerry.
No, it won't. The rejections the other side provides are largely optional, and in fact the FCC has issued strict guidance about the necessary level of matching on an LSR (I want to say it's telephone number, account number, PIN if applicable, and zipcode, but I know there's some conditional variations on this). Making the customer request a code from their losing carrier violates (at least the spirit, if not the letter of) current regulations by giving the current carrier a chance to market to an existing customer, threaten them, or make them pay a fee or contract termination price up front to get the code, or create undue levels of complexity on getting the code. Currently, you can create subscriptions against a number and force the issue, porting the number under hostile conditions is in fact technically possible (in fact, i've done it before, with a service provider placing a large quantity of numbers in conflict over a unrelated dispute, conflict expiration window can be your friend if you use it carefully). The only person who can complain about it is the customer themselves as long as the numbers are active, so if they're on your side and you're certain the number is active, the losing carrier has little recourse. Adding a step where your ability to port relies on the good graces of the losing carrier is going to create a far worse situation. -Paul On 12/07/2015 11:06 AM, Peter Beckman wrote:
I hadn't heard of Iconectiv (one "n") before. I found this:
http://www.ericsson.com/news/150326-fcc-authorizes-local-number-portability_...
Was it Neustar prior to this change?
I dream of a process for LNP that goes like this:
1. Customer goes to current carrier, requests a Porting Authorization Code for a number (or set of numbers), either online or over the phone.
2. Current carrier generates a Porting Authorization Code and provides it to the Customer.
3. Customer goes to new carrier, provides Phone Number, Current Carrier, and the Porting Authorization Code.
4. New carrier submits port request to Current Carrer with the Number and Porting Authorization Code. No name, billing address, PIN/SSN, just those three things.
5. Current carrier matches the Porting Authorization Code with their records for that Number and the port goes through.
Since all of this is centralized, just have Iconectiv manage it -- the Current Carrier uses an API with Iconectiv to register the number and get a code back. The New Carrier uses the API with Iconectiv with the number and the code to verify porting. Codes expire after x days.
Will Iconectiv bring this level of sanity to porting in the NANP? Or will it be more of the same, with rejections for an incorrect street abbreviation?
I know it's more complicated than that to implement, but it really ticks me off how difficult it is to port numbers these days if you aren't a Tier 1 wireless carrier.
Beckman
On Sat, 5 Dec 2015, Erik Flournoy wrote:
Aloha Group,
I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
---------------------------------------------------------------------------
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
You only need look at what the UNE circuit IDs are to know how the ILECs feel about them.......DS1s and DS3s both have FU in them! LOL! iconectiv used to be Telcordia, which was originally BellCore. In the past Telcordia only produced Telecom documentation, sold industry codes, and adminstered the BIRRDS database, which is what they produce the LERG and TPM reports from. Some of Telcordia's documentation like the ASOG, LSOG and NC/NCI list were not that helpful in the last 20 years because many of the fields could be changed by the carrier so every ILEC used them in a different way. When I said the ILEC published these codes on their website. I didn't mean it was easy to find! In my opinion, putting everything on the web but the kitchen sink and having it accompanied with a horrible search engine was their way of making it as hard as possible for the CLEC to operate. I happen to know where they hide most things because I've worked in the industry 19 years and documented their location as much as possible so I could help my clients. However, if you're new to the arena and trying to figure it out on your own it would be near impossible to get anything done. That's interesting that Ericsson is going to be taking over porting. I wonder if that means they are taking all the arms that NEUSTAR claims are separate entities. I've always described NEUSTAR's entities as kissing cousins because they are really just divisions who all share the same name in their e-mail communications(neustar.net, neustar,biz, etc). Those divisons include NANPA, the Pooling Administration, NPAC, and NECA. A year or so ago they bought out Targus (who handled CNAM storage) and TNSI who is one of the two largest SS7 providers. So I guess my question would be are they taking over ALL of NEUSTAR or just the the NPAC portion? Mary Lou Carey BackUP Telecom Consulting 615-791-9969
On December 7, 2015 at 11:06 AM Peter Beckman <beckman at angryox.com> wrote:
I hadn't heard of Iconectiv (one "n") before. I found this:
http://www.ericsson.com/news/150326-fcc-authorizes-local-number-portability_...
Was it Neustar prior to this change?
I dream of a process for LNP that goes like this:
1. Customer goes to current carrier, requests a Porting Authorization Code for a number (or set of numbers), either online or over the phone.
2. Current carrier generates a Porting Authorization Code and provides it to the Customer.
3. Customer goes to new carrier, provides Phone Number, Current Carrier, and the Porting Authorization Code.
4. New carrier submits port request to Current Carrer with the Number and Porting Authorization Code. No name, billing address, PIN/SSN, just those three things.
5. Current carrier matches the Porting Authorization Code with their records for that Number and the port goes through.
Since all of this is centralized, just have Iconectiv manage it -- the Current Carrier uses an API with Iconectiv to register the number and get a code back. The New Carrier uses the API with Iconectiv with the number and the code to verify porting. Codes expire after x days.
Will Iconectiv bring this level of sanity to porting in the NANP? Or will it be more of the same, with rejections for an incorrect street abbreviation?
I know it's more complicated than that to implement, but it really ticks me off how difficult it is to port numbers these days if you aren't a Tier 1 wireless carrier.
Beckman
On Sat, 5 Dec 2015, Erik Flournoy wrote:
Aloha Group,
I'm curious to know others thoughts on where they believe the traditional PSTN is going vs VOIP and VoLTE. Now that Iconnectiv will be administering the LNP in the US I feel as though it's the best time to try and propose new or more up to date solutions that allow smaller carriers to operate.
For example there is no charge to have the ability to port numbers in NPAC, but there is a monthly charge for the remote access to the NPAC. Then the interconnectivity at the LEC level. The archaic ways of telecom have not seemed to change much although VOIP is now in my opinion the standard of telecom. VOIP will soon be able to get code blocks and route via SIP vs SS7 and LERG. LERG, ASR/LSR, SS7 all systems owned by one monopolizing company.
--------------------------------------------------------------------------- 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 Mary Lou Carey BackUP Telecom Consulting Marylou at backuptelecom.com Office: 615-791-9969 Cell: 615-796-1111
participants (12)
-
abalashov＠evaristesys.com -
beckman＠angryox.com -
david.knell＠telng.com -
erik＠eespro.com -
faisal＠snappytelecom.net -
jra＠baylink.com -
lindsey＠e-c-group.com -
marylou＠backuptelecom.com -
mgraves＠mstvp.com -
mike＠astrocompanies.com -
paul＠timmins.net -
peeip989＠gmail.com