?Having seen GSXs knocked over with 100-200 CPS, I'd be inclined to even question that, though I don't doubt Sonus and friends make a big enough box for those walking in with a lotter winner-sized novelty check. ? -- Alex?Balashov?|?Principal?|?Evariste?Systems?LLC 1447?Peachtree?Street?NE,?Suite?700 Atlanta,?GA?30309 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. ? Original Message ? From: Paul Timmins Sent: Wednesday, April 20, 2016 23:36 To: Brooks Bridges Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Recommendations for high-cps SS7 OC-X gear?

?That is a fun fact, indeed. This I did not know! -- Alex?Balashov?|?Principal?|?Evariste?Systems?LLC 1447?Peachtree?Street?NE,?Suite?700 Atlanta,?GA?30309 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.

Avoid Meta at all cost. Sent from my iPhone

On Apr 20, 2016, at 10:35 PM, Paul Timmins <paul at timmins.net> wrote:

You're going to handle 500CPS of legacy sonet based TDM and question dropping 7 figures on the solution? *cringes*

This is literally what platforms like metaswitch, sonus and many others are made for. If you're looking for low cost, Taqua's solution is decent, and if you need to take that entire OC-48, you're all but eyeballs deep in Sonus or Metaswitch land.

-Paul

...

On Apr 20, 2016, at 17:54, Brooks Bridges <bbridges at o1.com> wrote:

Looking for suggestions for NEBS compliant gear that can support SS7, handle OC-3 or higher levels of channels, and can support (in aggregate) up to around 500 cps through a *good* (key word) SIP interface. I?m willing to entertain the idea of a single larger device that can take a full OC-48 and support the full 500 cps, but I?d prefer spread the load across multiple devices and smaller interfaces for load balancing and redundancy.

Any pointers? Obviously there are products out there by the really big players, but I?d really rather not have to drop 7 figures on this project unless I have to.

Thanks!

Brooks Bridges | Sr. Voice Services Engineer O1 Communications 5190 Golden Foothill Pkwy El Dorado Hills, CA 95762 office: 916.235.2097 | main: 888.444.1111, Option 2 email: bbridges at o1.com | web: www.o1.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

Anyone using TelcoBridges gear? Regards, *Calvin Ellison* Voice Operations Engineer calvin.ellison at voxox.com +1 (213) 285-0555 ----------------------------------------------- *voxox.com <http://www.voxox.com/> * 5825 Oberlin Drive, Suite 5 San Diego, CA 92121 [image: Voxox] On Fri, Apr 22, 2016 at 10:47 AM, Brandon Buckner <brandon at kamikos.com> wrote:

Just curious: Is there a reason to avoid Metaswitch?

My main experience is in Metaswitch and Sonus, but in Metaswitch it was limited to the 2510 and 3510 gateways and the accompanying servers up to 7.4 software and none of the newer blade platforms. At the time I would have said that Metaswitch would have worked quite well for what is being asked, especially if wanting to split across many smaller gateways and geographically distributed. Is there something with the new hardware and/or software I don't know about quality-wise?

Sonus killed off the GSX4000 which would have lent better to spreading around a bunch of smaller boxes. They still have the GSX9000 which goes up to single OC-3 cards (so you'd have to have a couple to split an OC-48 still), but their main push seems to be the SBC5210 and SBC7000 which are IP only, no TDM. But spread across gateways the call processing can easily do the 500 CPS.

On 4/21/2016 5:00 AM, Anthony Orlando via VoiceOps wrote:

Avoid Meta at all cost.

Sent from my iPhone

On Apr 20, 2016, at 10:35 PM, Paul Timmins < <paul at timmins.net> paul at timmins.net> wrote:

You're going to handle 500CPS of legacy sonet based TDM and question dropping 7 figures on the solution? *cringes*

This is literally what platforms like metaswitch, sonus and many others are made for. If you're looking for low cost, Taqua's solution is decent, and if you need to take that entire OC-48, you're all but eyeballs deep in Sonus or Metaswitch land.

-Paul

On Apr 20, 2016, at 17:54, Brooks Bridges <bbridges at o1.com> wrote:

Looking for suggestions for NEBS compliant gear that can support SS7, handle OC-3 or higher levels of channels, and can support (in aggregate) up to around 500 cps through a **good** (key word) SIP interface. I?m willing to entertain the idea of a single larger device that can take a full OC-48 and support the full 500 cps, but I?d prefer spread the load across multiple devices and smaller interfaces for load balancing and redundancy.

Any pointers? Obviously there are products out there by the really big players, but I?d really rather not have to drop 7 figures on this project unless I have to.

Thanks!

*Brooks Bridges | *Sr. Voice Services Engineer *O1 Communications* 5190 Golden Foothill Pkwy El Dorado Hills, CA 95762 *office:* 916.235.2097 | *main:* 888.444.1111, Option 2 *email:* <bbridges at o1.com>bbridges at o1.com | *web:* <http://www.o1.com/> www.o1.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 listVoiceOps at voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

I agree. A distributed Architecture, geographically dispersed, is the best design for what is being asked of. The only issue I would see with the Sonus deployment is they are very expensive. MetaSwitch would be able to handle this load, as far as I know. Probably not as expensive as Sonus but... not free either. There are other options as well. Some would be checking out Squire, GenBand and AudioCodes. Each of these vendors brings good things to the table and I believe they could all handle the BH traffic you are looking at. Kidd On Fri, Apr 22, 2016 at 11:47 AM, Brandon Buckner <brandon at kamikos.com> wrote:

Just curious: Is there a reason to avoid Metaswitch?

My main experience is in Metaswitch and Sonus, but in Metaswitch it was limited to the 2510 and 3510 gateways and the accompanying servers up to 7.4 software and none of the newer blade platforms. At the time I would have said that Metaswitch would have worked quite well for what is being asked, especially if wanting to split across many smaller gateways and geographically distributed. Is there something with the new hardware and/or software I don't know about quality-wise?

Sonus killed off the GSX4000 which would have lent better to spreading around a bunch of smaller boxes. They still have the GSX9000 which goes up to single OC-3 cards (so you'd have to have a couple to split an OC-48 still), but their main push seems to be the SBC5210 and SBC7000 which are IP only, no TDM. But spread across gateways the call processing can easily do the 500 CPS.

On 4/21/2016 5:00 AM, Anthony Orlando via VoiceOps wrote:

Avoid Meta at all cost.

Sent from my iPhone

On Apr 20, 2016, at 10:35 PM, Paul Timmins < <paul at timmins.net> paul at timmins.net> wrote:

You're going to handle 500CPS of legacy sonet based TDM and question dropping 7 figures on the solution? *cringes*

This is literally what platforms like metaswitch, sonus and many others are made for. If you're looking for low cost, Taqua's solution is decent, and if you need to take that entire OC-48, you're all but eyeballs deep in Sonus or Metaswitch land.

-Paul

On Apr 20, 2016, at 17:54, Brooks Bridges <bbridges at o1.com> wrote:

Looking for suggestions for NEBS compliant gear that can support SS7, handle OC-3 or higher levels of channels, and can support (in aggregate) up to around 500 cps through a **good** (key word) SIP interface. I?m willing to entertain the idea of a single larger device that can take a full OC-48 and support the full 500 cps, but I?d prefer spread the load across multiple devices and smaller interfaces for load balancing and redundancy.

Any pointers? Obviously there are products out there by the really big players, but I?d really rather not have to drop 7 figures on this project unless I have to.

Thanks!

*Brooks Bridges | *Sr. Voice Services Engineer *O1 Communications* 5190 Golden Foothill Pkwy El Dorado Hills, CA 95762 *office:* 916.235.2097 | *main:* 888.444.1111, Option 2 *email:* <bbridges at o1.com>bbridges at o1.com | *web:* <http://www.o1.com/> www.o1.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 listVoiceOps at voiceops.orghttps://puck.nether.net/mailman/listinfo/voiceops

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

FYI... U.S. carriers mum on 60 Minutes report on vulnerability in SS7 - http://www.fiercewireless.com/story/us-carriers-mum-60-minutes-report-vulner... Regards, Peter Radizeski RAD-INFO, Inc. 813.963.5884 http://rad-info.net * Need bandwidth or colocation? call me

There is no VOICE traversing the SS7 network, so you cannot possibly record a conversation by having access to the SS7 network only. On Thu, Apr 21, 2016 at 9:36 AM, Matthew Yaklin <myaklin at firstlight.net> wrote:

In other words the hacker has to have working SS7 trunks or access to someone who does? That is how I understood it.

Not exactly a remote hack from mom's basement sort of thing.

Matt

________________________________________ From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Peter Rad. < peter at 4isps.com> Sent: Thursday, April 21, 2016 11:25 AM To: voiceops at voiceops.org Subject: [VoiceOps] SS7

FYI...

U.S. carriers mum on 60 Minutes report on vulnerability in SS7 -

http://www.fiercewireless.com/story/us-carriers-mum-60-minutes-report-vulner...

Regards,

Peter Radizeski RAD-INFO, Inc. 813.963.5884 http://rad-info.net * Need bandwidth or colocation? call me _______________________________________________ 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

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

In a strictly TDM world, or conversation... having access to the SS7 network gets you nothing but what and where the call traversed. NO audio is carried and without End Office controlling software for call routing, just dropping it into some IP connection is not going to afford you anything other than what you already have. You still need access to the audio carrying infrastructure of the network to get the audio. I cannot comment on CALEA Kidd On Thu, Apr 21, 2016 at 10:56 AM, Chris Aloi <ctaloi at gmail.com> wrote:

It looked like they had access to SS7 links (likely A links terminated to a physical server) and were using FreeSWITCH to somehow fork the media from the call and record it. Just a guess based on the quick console recording.

Correct, SS7 doesn't carry the actual voice it handles the signaling to bring up the voice channels (by identifying be point code and CICs) and various other signaling bits. Not sure if there are provisions for CALEA in SS7 that could fork a media stream or exactly how that would work.

So I guess the barrier to entry would be access to the SS7 network, not as easy as hopping on the Internet, but certainly not much of a challenge.

--- Christopher Aloi Sent from my iPhone

On Apr 21, 2016, at 11:52 AM, Kidd Filby <kiddfilby at gmail.com> wrote:

There is no VOICE traversing the SS7 network, so you cannot possibly record a conversation by having access to the SS7 network only.

On Thu, Apr 21, 2016 at 9:36 AM, Matthew Yaklin <myaklin at firstlight.net> wrote:

...

In other words the hacker has to have working SS7 trunks or access to someone who does? That is how I understood it.

Not exactly a remote hack from mom's basement sort of thing.

Matt

________________________________________ From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Peter Rad. < peter at 4isps.com> Sent: Thursday, April 21, 2016 11:25 AM To: voiceops at voiceops.org Subject: [VoiceOps] SS7

FYI...

U.S. carriers mum on 60 Minutes report on vulnerability in SS7 -

http://www.fiercewireless.com/story/us-carriers-mum-60-minutes-report-vulner...

Regards,

Peter Radizeski RAD-INFO, Inc. 813.963.5884 http://rad-info.net * Need bandwidth or colocation? call me _______________________________________________ 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

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

The part I was curious about and perhaps someone can clarify who has more knowledge than I is... It appears in order to record calls the attacker has to be in very close proximity to the target. Like radio/tower range. You cannot record a conversation half way across the world. Matt ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Matthew Yaklin <myaklin at firstlight.net> Sent: Thursday, April 21, 2016 2:09 PM To: Kidd Filby; Chris Aloi Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] SS7 Here is a paper that may shed some light on the discussion for the curious. https://www.sans.org/reading-room/whitepapers/critical/fall-ss7--critical-se... SANS Institute InfoSec Reading Room<https://www.sans.org/reading-room/whitepapers/critical/fall-ss7--critical-se...> www.sans.org The Fall of SS7 ? How Can the Critical Security Controls Help? 4 " #$$#%!&'()#*+!"#$$#%,-')#*./-#01,2'-! area notices this registration and transfers to a Visitor ... ________________________________ From: Kidd Filby <kiddfilby at gmail.com> Sent: Thursday, April 21, 2016 2:01 PM To: Chris Aloi Cc: Matthew Yaklin; voiceops at voiceops.org Subject: Re: [VoiceOps] SS7 In a strictly TDM world, or conversation... having access to the SS7 network gets you nothing but what and where the call traversed. NO audio is carried and without End Office controlling software for call routing, just dropping it into some IP connection is not going to afford you anything other than what you already have. You still need access to the audio carrying infrastructure of the network to get the audio. I cannot comment on CALEA Kidd On Thu, Apr 21, 2016 at 10:56 AM, Chris Aloi <ctaloi at gmail.com<mailto:ctaloi at gmail.com>> wrote: It looked like they had access to SS7 links (likely A links terminated to a physical server) and were using FreeSWITCH to somehow fork the media from the call and record it. Just a guess based on the quick console recording. Correct, SS7 doesn't carry the actual voice it handles the signaling to bring up the voice channels (by identifying be point code and CICs) and various other signaling bits. Not sure if there are provisions for CALEA in SS7 that could fork a media stream or exactly how that would work. So I guess the barrier to entry would be access to the SS7 network, not as easy as hopping on the Internet, but certainly not much of a challenge. --- Christopher Aloi Sent from my iPhone On Apr 21, 2016, at 11:52 AM, Kidd Filby <kiddfilby at gmail.com<mailto:kiddfilby at gmail.com>> wrote: There is no VOICE traversing the SS7 network, so you cannot possibly record a conversation by having access to the SS7 network only. On Thu, Apr 21, 2016 at 9:36 AM, Matthew Yaklin <myaklin at firstlight.net<mailto:myaklin at firstlight.net>> wrote: In other words the hacker has to have working SS7 trunks or access to someone who does? That is how I understood it. Not exactly a remote hack from mom's basement sort of thing. Matt ________________________________________ From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> on behalf of Peter Rad. <peter at 4isps.com<mailto:peter at 4isps.com>> Sent: Thursday, April 21, 2016 11:25 AM To: voiceops at voiceops.org<mailto:voiceops at voiceops.org> Subject: [VoiceOps] SS7 FYI... U.S. carriers mum on 60 Minutes report on vulnerability in SS7 - http://www.fiercewireless.com/story/us-carriers-mum-60-minutes-report-vulner... Regards, Peter Radizeski RAD-INFO, Inc. 813.963.5884<tel:813.963.5884> http://rad-info.net * Need bandwidth or colocation? call me _______________________________________________ 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 -- Kidd Filby 661.557.5640<tel:661.557.5640> (C) http://www.linkedin.com/in/kiddfilby _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops -- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

It's been a decade since I've touched SS7, and I barely remember what I had for breakfast, so it's like it's all new to me again.

From what I read, it sounds like there may be a "proxy" function that can be injected which would bring both endpoints back to you so you can record both legs. The 60 Minutes piece shows exactly that. And, while it was done in seconds for TV, we all know there was a lot of prep work required ahead of time to make it that simple.

Question, though: does the proliferation of SMS gateway services open a security risk since they may be bridging IP to SS7? On Apr 21, 2016, at 14:13, Paul Timmins <paul at timmins.net> wrote: You could do it by saying "hey, this handset is roaming on me" then directing the call back to the handset in question, I figure. It would be inbound only intercept, but i could see that working. -Paul

On 04/21/2016 02:12 PM, Matthew Yaklin wrote:

The part I was curious about and perhaps someone can clarify who has more knowledge than I is...

It appears in order to record calls the attacker has to be in very close proximity to the target. Like radio/tower range.

You cannot record a conversation half way across the world.

Matt

From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Matthew Yaklin <myaklin at firstlight.net> Sent: Thursday, April 21, 2016 2:09 PM To: Kidd Filby; Chris Aloi Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] SS7

Here is a paper that may shed some light on the discussion for the curious.

https://www.sans.org/reading-room/whitepapers/critical/fall-ss7--critical-se...

SANS Institute InfoSec Reading Room www.sans.org The Fall of SS7 ? How Can the Critical Security Controls Help? 4 " #$$#%!&'()#*+!"#$$#%,-')#*./-#01,2'-! area notices this registration and transfers to a Visitor ...

From: Kidd Filby <kiddfilby at gmail.com> Sent: Thursday, April 21, 2016 2:01 PM To: Chris Aloi Cc: Matthew Yaklin; voiceops at voiceops.org Subject: Re: [VoiceOps] SS7

In a strictly TDM world, or conversation... having access to the SS7 network gets you nothing but what and where the call traversed. NO audio is carried and without End Office controlling software for call routing, just dropping it into some IP connection is not going to afford you anything other than what you already have. You still need access to the audio carrying infrastructure of the network to get the audio.

I cannot comment on CALEA

Kidd

...

On Thu, Apr 21, 2016 at 10:56 AM, Chris Aloi <ctaloi at gmail.com> wrote: It looked like they had access to SS7 links (likely A links terminated to a physical server) and were using FreeSWITCH to somehow fork the media from the call and record it. Just a guess based on the quick console recording.

Correct, SS7 doesn't carry the actual voice it handles the signaling to bring up the voice channels (by identifying be point code and CICs) and various other signaling bits. Not sure if there are provisions for CALEA in SS7 that could fork a media stream or exactly how that would work.

So I guess the barrier to entry would be access to the SS7 network, not as easy as hopping on the Internet, but certainly not much of a challenge.

--- Christopher Aloi Sent from my iPhone

On Apr 21, 2016, at 11:52 AM, Kidd Filby <kiddfilby at gmail.com> wrote:

...

There is no VOICE traversing the SS7 network, so you cannot possibly record a conversation by having access to the SS7 network only.

...

On Thu, Apr 21, 2016 at 9:36 AM, Matthew Yaklin <myaklin at firstlight.net> wrote:

In other words the hacker has to have working SS7 trunks or access to someone who does? That is how I understood it.

Not exactly a remote hack from mom's basement sort of thing.

Matt

________________________________________ From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Peter Rad. <peter at 4isps.com> Sent: Thursday, April 21, 2016 11:25 AM To: voiceops at voiceops.org Subject: [VoiceOps] SS7

FYI...

U.S. carriers mum on 60 Minutes report on vulnerability in SS7 - http://www.fiercewireless.com/story/us-carriers-mum-60-minutes-report-vulner...

Regards,

Peter Radizeski RAD-INFO, Inc. 813.963.5884 http://rad-info.net * Need bandwidth or colocation? call me _______________________________________________ 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

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

_______________________________________________ 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 generally true if the calls are *unencrypted* on VoIP... On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com> wrote:

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice. WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats. In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 ) The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before. Interesting times, Dan -- Dan York dyork at lodestar2.com +1-802-735-1624 Skype:danyork My writing -> http://www.danyork.me/ http://www.danyork.com/ http://twitter.com/danyork

Joseph, I noticed that in Gmail (and perhaps other email systems), the longer reply I wrote for Kidd was hidden because it appeared after his text. Here's what I wrote... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice. WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats. In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 ) The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before. Interesting times, Dan On Thu, Apr 21, 2016 at 3:45 PM, Joseph Jackson <jjackson at aninetworks.net> wrote:

I don?t know many places that encrypt their voice traffic.

*From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Dan York *Sent:* Thursday, April 21, 2016 2:45 PM *To:* Kidd Filby *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] SS7

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com> wrote:

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times,

Dan

--

Dan York

dyork at lodestar2.com +1-802-735-1624 Skype:danyork

My writing -> http://www.danyork.me/

http://www.danyork.com/

http://twitter.com/danyork

-- Dan York dyork at lodestar2.com +1-802-735-1624 Skype:danyork My writing -> http://www.danyork.me/ http://www.danyork.com/ http://twitter.com/danyork

I purposely didn't even start down that road. But, Yes, they most certainly could, and for the most part would be easier. All of the same info rides the SigTran deployment as an SS7 A/E/F-Link, plus possibly more.... depending on what type of messaging you're talking about. However, it also lacks voice content, like the SS7 network. Kidd On Thu, Apr 21, 2016 at 4:27 PM, Jared Geiger <jared at compuwizz.net> wrote:

I haven't used SS7 in the voice world, only touched briefly on the messaging side of it. Would hackers be able to do the same similar attack via SIGTRAN? I would think it would be easier to get access to a poorly managed SIGTRAN device which would then give you SS7 access.

Or even an Asterisk box running SS7 trunks.

On Thu, Apr 21, 2016 at 1:00 PM, Dan York <dyork at lodestar2.com> wrote:

...

Joseph,

I noticed that in Gmail (and perhaps other email systems), the longer reply I wrote for Kidd was hidden because it appeared after his text. Here's what I wrote...

what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times, Dan

On Thu, Apr 21, 2016 at 3:45 PM, Joseph Jackson <jjackson at aninetworks.net

...

wrote:

...

I don?t know many places that encrypt their voice traffic.

*From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Dan York *Sent:* Thursday, April 21, 2016 2:45 PM *To:* Kidd Filby *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] SS7

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com> wrote:

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times,

Dan

--

Dan York

dyork at lodestar2.com +1-802-735-1624 Skype:danyork

My writing -> http://www.danyork.me/

http://www.danyork.com/

http://twitter.com/danyork

--

Dan York dyork at lodestar2.com +1-802-735-1624 Skype:danyork My writing -> http://www.danyork.me/ http://www.danyork.com/ http://twitter.com/danyork

_______________________________________________ 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

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

Dan; I totally agree with you on where the industry is headed and we will get there. Encryption has definitely become a MUST-HAVE with the technology change to connectionless vs. timeslot-oriented network. However, we are not there yet. Where there is a will, there is a way... on both sides of the coin, unfortunately. Although some individuals are just seeing the light, security is king, in communications, and it has been for a long time. I recall designing VSAT systems for major corporations in the 80's, for both voice and data applications. Their #1 priority was encryption on both. Along with this, network isolation and ingress points MUST be key components to the design of the deployment &/or service offering to protect both your customer and YOUR network. This has been a great discussion on a very important topic. Kidd On Thu, Apr 21, 2016 at 1:44 PM, Dan York <dyork at lodestar2.com> wrote:

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com> wrote:

...

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times, Dan

--

Dan York dyork at lodestar2.com +1-802-735-1624 Skype:danyork My writing -> http://www.danyork.me/ http://www.danyork.com/ http://twitter.com/danyork

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

Very well said Mike. Back In The Day... Interconnection between 2 companies had to occur via a 3rd party, like Illuminet. Their had to be SS7 gateway providers and that's all they were allowed to do. Route SS7 traffic between LEC/ILEC/CLEC networks. Oh... do I remember the pains... Gateway-Screened... CNAM database corruption, LIDB services not provided.... Still makes my head hurt. Kidd On Fri, Apr 22, 2016 at 12:28 PM, Mike Ray, MBA, CNE, CTE < mike at astrocompanies.com> wrote:

It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that?s been going on for the past? two decades or so. There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier. Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them. Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker?s point code(s) and it therefore would not exist.

If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier?s network would not compromise my network. (in response to the nation-state issue) To get a call to Germany, I signal to the access tandem or IXC switch I?ve chosen to interconnect with in the US and that switch signals upstream, etc.

If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn?t be here. At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place.

If the drumbeat of ?solve everything with IP!? continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers. That certainly wouldn?t bode well for reliability or security.

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 *Dan York *Sent:* Thursday, April 21, 2016 3:45 PM *To:* Kidd Filby <kiddfilby at gmail.com> *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] SS7

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com> wrote:

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times,

Dan

--

Dan York

dyork at lodestar2.com +1-802-735-1624 Skype:danyork

My writing -> http://www.danyork.me/

http://www.danyork.com/

http://twitter.com/danyork

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

I didn?t realize that either until we switched SS7 providers recently. Our former one (Whom I am beginning to miss, truth be told) made it impossible to exchange signaling traffic with anything that you didn?t have a route built (and paid) for, which is how it?s been as far as I know since I got into this biz nearly two decades ago. However, our new SS7 provider apparently lets any SS7 point code communicate with ours, as we started seeing random traffic from unknown point codes shortly after we switched providers. We reported it and they blocked that traffic, but in the process it became clear that they let anything through until and unless we ask them to block it. There?s also language in our ICA with them that says that if we are communicating with any point code that we haven?t purchased a route for, they have the right to back-bill it one they discover it. We?re in a contract now for three years, but at the end of it we may switch back to the original provider for this and other reasons. SS7 certainly feels a lot less secure than it did before. Luckily, our Class 5 End Office switch does not provide any data nor redirection capabilities over SS7 such as those exploited in the article. We also found that while we received the traffic from the unknown point code, our switch did not respond because we did not have a route built for it on the switch. But it still means that a DOS attack may be possible, and it feels like assigning our switch a public IP without a firewall in place, which makes me crazy. 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> http://www.astrocompanies.com From: Christopher Aloi [mailto:ctaloi at gmail.com] Sent: Friday, April 22, 2016 9:28 PM To: Kidd Filby <kiddfilby at gmail.com>; Mike Ray, MBA, CNE, CTE <mike at astrocompanies.com> Cc: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] SS7 I didn't realize you can now connect to another company without ordering the route-set from a third party. How does this work ? I feel old ! On Fri, Apr 22, 2016 at 2:40 PM Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote: Very well said Mike. Back In The Day... Interconnection between 2 companies had to occur via a 3rd party, like Illuminet. Their had to be SS7 gateway providers and that's all they were allowed to do. Route SS7 traffic between LEC/ILEC/CLEC networks. Oh... do I remember the pains... Gateway-Screened... CNAM database corruption, LIDB services not provided.... Still makes my head hurt. Kidd On Fri, Apr 22, 2016 at 12:28 PM, Mike Ray, MBA, CNE, CTE <mike at astrocompanies.com <mailto:mike at astrocompanies.com> > wrote: It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that?s been going on for the past? two decades or so. There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier. Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them. Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker?s point code(s) and it therefore would not exist. If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier?s network would not compromise my network. (in response to the nation-state issue) To get a call to Germany, I signal to the access tandem or IXC switch I?ve chosen to interconnect with in the US and that switch signals upstream, etc. If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn?t be here. At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place. If the drumbeat of ?solve everything with IP!? continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers. That certainly wouldn?t bode well for reliability or security. 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 <tel:941%20600-0207> <http://www.astrocompanies.com> http://www.astrocompanies.com From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org> ] On Behalf Of Dan York Sent: Thursday, April 21, 2016 3:45 PM To: Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] SS7 This is generally true if the calls are *unencrypted* on VoIP... On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote: Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-) ... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice. WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats. In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 ) The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before. Interesting times, Dan -- Dan York <mailto:dyork at lodestar2.com> dyork at lodestar2.com +1-802-735-1624 <tel:%2B1-802-735-1624> Skype:danyork My writing -> http://www.danyork.me/ <http://www.danyork.com/> http://www.danyork.com/ http:// <http://twitter.com/danyork> twitter.com/danyork _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops -- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops

It works because the party you're connected to is the one that provides the PSTN switching. Trunks and Point Code routes are ordered to their switch and they're just letting you home your NXXs on their switch so you are an underlying carrier. Mary Lou Carey BackUP Telecom Consulting Marylou at backuptelecom.com Office: 615-791-9969 Cell: 615-796-1111

On April 22, 2016 at 8:28 PM Christopher Aloi <ctaloi at gmail.com> wrote:

I didn't realize you can now connect to another company without ordering the route-set from a third party. How does this work ? I feel old !

On Fri, Apr 22, 2016 at 2:40 PM Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote:

...

...

Very well said Mike.

Back In The Day... Interconnection between 2 companies had to occur via a 3rd party, like Illuminet. Their had to be SS7 gateway providers and that's all they were allowed to do. Route SS7 traffic between LEC/ILEC/CLEC networks. Oh... do I remember the pains... Gateway-Screened... CNAM database corruption, LIDB services not provided.... Still makes my head hurt.

Kidd

On Fri, Apr 22, 2016 at 12:28 PM, Mike Ray, MBA, CNE, CTE <mike at astrocompanies.com <mailto:mike at astrocompanies.com> > wrote: > > >

...

It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that?s been going on for the past? two decades or so. There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier. Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them. Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker?s point code(s) and it therefore would not exist.

If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier?s network would not compromise my network. (in response to the nation-state issue) To get a call to Germany, I signal to the access tandem or IXC switch I?ve chosen to interconnect with in the US and that switch signals upstream, etc.

If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn?t be here. At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place.

If the drumbeat of ?solve everything with IP!? continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers. That certainly wouldn?t bode well for reliability or security.

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 <http://www.astrocompanies.com>

From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org> ] On Behalf Of Dan York Sent: Thursday, April 21, 2016 3:45 PM To: Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] SS7

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote:

> > > >

...

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

> > >

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times,

Dan

--

Dan York

dyork at lodestar2.com <mailto:dyork at lodestar2.com> +1-802-735-1624 Skype:danyork

My writing -> http://www.danyork.me/

http://www.danyork.com/ <http://www.danyork.com/>

http://twitter.com/danyork <http://twitter.com/danyork>

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops

...

...

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby _______________________________________________ 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

You can get SS7 through any of the ILECs as well but there are two things to remember with them. 1. They don't usually offer SigTran so in addition to the SS7 ports, you also have to pay for the transport to the STPs. 2. They will usually only cover routes in their territory so if you go into another LEC territory they will tell you that you need a second set of links for those areas. Companies like Syniverse and Neustar are connected to pretty much everyone and while some routes are off-net and cost more, they will only require one set of SS7 links. Mary Lou Carey BackUP Telecom Consulting Marylou at backuptelecom.com Office: 615-791-9969 Cell: 615-796-1111

On April 23, 2016 at 12:15 PM Kidd Filby <kiddfilby at gmail.com> wrote:

It is now possible to do it. I'm not sure when it started but, I know PB/SBC/ATT in CA. offered me SS7 connectivity many years ago. I'm pretty sure all of the Baby Bells now offer the service. I am sure SNET does as well. Now the choice is up to you if you want them to see all of your PSTN-bound traffic. The technology still holds true that your SS7 provider is all or nothing. You can't have multiple SS7 providers yet.

Kidd

On Fri, Apr 22, 2016 at 7:28 PM, Christopher Aloi <ctaloi at gmail.com <mailto:ctaloi at gmail.com> > wrote:

...

...

I didn't realize you can now connect to another company without ordering the route-set from a third party. How does this work ? I feel old !

On Fri, Apr 22, 2016 at 2:40 PM Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote: > > > Very well said Mike.

...

Back In The Day... Interconnection between 2 companies had to occur via a 3rd party, like Illuminet. Their had to be SS7 gateway providers and that's all they were allowed to do. Route SS7 traffic between LEC/ILEC/CLEC networks. Oh... do I remember the pains... Gateway-Screened... CNAM database corruption, LIDB services not provided.... Still makes my head hurt.

Kidd

On Fri, Apr 22, 2016 at 12:28 PM, Mike Ray, MBA, CNE, CTE <mike at astrocompanies.com <mailto:mike at astrocompanies.com> > wrote: > > > >

...

It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that?s been going on for the past? two decades or so. There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier. Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them. Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker?s point code(s) and it therefore would not exist.

If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier?s network would not compromise my network. (in response to the nation-state issue) To get a call to Germany, I signal to the access tandem or IXC switch I?ve chosen to interconnect with in the US and that switch signals upstream, etc.

If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn?t be here. At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place.

If the drumbeat of ?solve everything with IP!? continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers. That certainly wouldn?t bode well for reliability or security.

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 <http://www.astrocompanies.com>

From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org> ] On Behalf Of Dan York Sent: Thursday, April 21, 2016 3:45 PM To: Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com>

...

Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] SS7

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote:

> > > > >

...

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

> > > >

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times,

Dan

--

Dan York

dyork at lodestar2.com <mailto:dyork at lodestar2.com> +1-802-735-1624 Skype:danyork

My writing -> http://www.danyork.me/

http://www.danyork.com/ <http://www.danyork.com/>

http://twitter.com/danyork <http://twitter.com/danyork>

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops > > >

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops

...

...

...

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby _______________________________________________ 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

ABSOLUTELY!!!! On Sat, Apr 23, 2016 at 9:28 AM, Hiers, David <David.Hiers at cdk.com> wrote:

People tend forget the existence and benefit of physical and administrative security controls until they disable them. Sure, they are an expensive speedbump at times, but you can?t hack what you can?t touch.

David

*From:* VoiceOps [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Mike Ray, MBA, CNE, CTE *Sent:* Friday, April 22, 2016 11:28 *To:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] SS7

It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that?s been going on for the past? two decades or so. There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier. Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them. Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker?s point code(s) and it therefore would not exist.

If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier?s network would not compromise my network. (in response to the nation-state issue) To get a call to Germany, I signal to the access tandem or IXC switch I?ve chosen to interconnect with in the US and that switch signals upstream, etc.

If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn?t be here. At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place.

If the drumbeat of ?solve everything with IP!? continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers. That certainly wouldn?t bode well for reliability or security.

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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrocompanies.com&d...>

*From:* VoiceOps [mailto:voiceops-bounces at voiceops.org <voiceops-bounces at voiceops.org>] *On Behalf Of *Dan York *Sent:* Thursday, April 21, 2016 3:45 PM *To:* Kidd Filby <kiddfilby at gmail.com> *Cc:* voiceops at voiceops.org *Subject:* Re: [VoiceOps] SS7

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com> wrote:

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.whatsapp.com_10000...> ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__wire.com&d=CwMFaQ&c=N13-...> ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_csoghoian_s...> )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times,

Dan

--

Dan York

dyork at lodestar2.com +1-802-735-1624 Skype:danyork

My writing -> http://www.danyork.me/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.danyork.me_&d=CwMFaQ...>

http://www.danyork.com/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.danyork.com_&d=CwMFa...>

http://twitter.com/danyork <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danyork&d=Cw...> ------------------------------ This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

There are really only two large companies that will do SS7 via SigTran and they are Syniverse and Neustar (formerly TNSi / Verisign / Illuminet), They don't really like to give out their pricing publicly so you have to sign an NDA to get it, but I would budget about $1,000 per month to be safe. You pay for each ISUP route as well so that price depends on how many routes you have. Are you asking which carriers provide SS7 links or which ones will do the host switch product? Mary Lou Carey BackUP Telecom Consulting Marylou at backuptelecom.com Office: 615-791-9969 Cell: 615-796-1111

On April 23, 2016 at 1:21 PM Erik Flournoy <erik at eespro.com> wrote:

Hey since we're on this topic what's the average cost for SigTran and who would you guys recommend? Who actually has SS7 and would be interested in interconnecting.

On Apr 23, 2016 7:21 AM, "Kidd Filby" <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote:

...

...

ABSOLUTELY!!!!

On Sat, Apr 23, 2016 at 9:28 AM, Hiers, David <David.Hiers at cdk.com <mailto:David.Hiers at cdk.com> > wrote: > > >

...

People tend forget the existence and benefit of physical and administrative security controls until they disable them. Sure, they are an expensive speedbump at times, but you can?t hack what you can?t touch.

David

From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org> ] On Behalf Of Mike Ray, MBA, CNE, CTE Sent: Friday, April 22, 2016 11:28 To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] SS7

It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that?s been going on for the past? two decades or so. There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier. Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them. Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker?s point code(s) and it therefore would not exist.

If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier?s network would not compromise my network. (in response to the nation-state issue) To get a call to Germany, I signal to the access tandem or IXC switch I?ve chosen to interconnect with in the US and that switch signals upstream, etc.

If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn?t be here. At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place.

If the drumbeat of ?solve everything with IP!? continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers. That certainly wouldn?t bode well for reliability or security.

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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrocompanies.com&d...>

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Dan York Sent: Thursday, April 21, 2016 3:45 PM To: Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] SS7

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote:

> > > >

...

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

> > >

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.whatsapp.com_10000...> ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__wire.com&d=CwMFaQ&c=N13-...> ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_csoghoian_s...> )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times,

Dan

--

Dan York

dyork at lodestar2.com <mailto:dyork at lodestar2.com> +1-802-735-1624 Skype:danyork

My writing -> http://www.danyork.me/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.danyork.me_&d=CwMFaQ...>

http://www.danyork.com/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.danyork.com_&d=CwMFa...>

http://twitter.com/danyork <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danyork&d=Cw...>

--------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops

...

...

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

_______________________________________________ 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

I am by no means an expert on who offers what and at what price. Just sharing my experience as a consultant who helps carriers get their networks turned up. If you have a list of smaller SS7 providers that are not re-sellers of the big ones I would love to get a list from you! Having as many options to give out as possible is always a good thing! Mary Lou Carey BackUP Telecom Consulting Marylou at backuptelecom.com Office: 615-791-9969 Cell: 615-796-1111

On April 24, 2016 at 7:43 AM Jay Patel <clecny at gmail.com> wrote:

This is not 100% accurate, there are other small STP operators who can offer you cheaper option ( < $500/month price point) for Sigtran connectivity. Feel free to contact me off list.

On Sat, Apr 23, 2016 at 2:59 PM, Mary Lou Carey <marylou at backuptelecom.com <mailto:marylou at backuptelecom.com> > wrote:

...

...

There are really only two large companies that will do SS7 via SigTran and they are Syniverse and Neustar (formerly TNSi / Verisign / Illuminet), They don't really like to give out their pricing publicly so you have to sign an NDA to get it, but I would budget about $1,000 per month to be safe. You pay for each ISUP route as well so that price depends on how many routes you have.

Are you asking which carriers provide SS7 links or which ones will do the host switch product?

Mary Lou Carey BackUP Telecom Consulting Marylou at backuptelecom.com <mailto:Marylou at backuptelecom.com> Office: 615-791-9969 Cell: 615-796-1111

> > > On April 23, 2016 at 1:21 PM Erik Flournoy <erik at eespro.com > > > <mailto:erik at eespro.com> > wrote:

...

Hey since we're on this topic what's the average cost for SigTran and who would you guys recommend? Who actually has SS7 and would be interested in interconnecting.

On Apr 23, 2016 7:21 AM, "Kidd Filby" <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote: > > > > ABSOLUTELY!!!!

...

On Sat, Apr 23, 2016 at 9:28 AM, Hiers, David <David.Hiers at cdk.com <mailto:David.Hiers at cdk.com> > wrote: > > > > >

...

People tend forget the existence and benefit of physical and administrative security controls until they disable them. Sure, they are an expensive speedbump at times, but you can?t hack what you can?t touch.

David

From: VoiceOps [mailto:voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org> ] On Behalf Of Mike Ray, MBA, CNE, CTE Sent: Friday, April 22, 2016 11:28 To: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] SS7

It seems to me that this SS7 vulnerability issue is just the latest result of all of the de-regulation that?s been going on for the past? two decades or so. There was a time that you could not buy commercial access to the SS7 network; to get that access you had to be a real carrier. Also, back at that time, inter-company SS7 signalling could only occur on established, ordered signaling routes where both parties placed an order to open the route between them. Therefore, this would not have been possible back then because the carrier would not have ordered a route to the hacker?s point code(s) and it therefore would not exist.

If I am a US local carrier in 2001, I have no need to order a signaling route to a German carrier either so even the hacker having full access to a German carrier?s network would not compromise my network. (in response to the nation-state issue) To get a call to Germany, I signal to the access tandem or IXC switch I?ve chosen to interconnect with in the US and that switch signals upstream, etc.

If we were not on this path of de-regulation where whatever makes commercial sense for one company can open up the whole SS7 network to un-trusted parties, we likely wouldn?t be here. At some point, a decision was made somewhere to allow this loosy-goosy inter-company signaling over the SS7 network between two point codes that would not, under the original implementation of SS7, be able to talk to each other in the first place.

If the drumbeat of ?solve everything with IP!? continues, I hope that at least it gets solved by establishing something close to what the VPF was supposed to be, and not just a general dumping of all voice traffic across the internet between carriers. That certainly wouldn?t bode well for reliability or security.

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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.astrocompanies.com&d...>

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Dan York Sent: Thursday, April 21, 2016 3:45 PM To: Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > Cc: voiceops at voiceops.org <mailto:voiceops at voiceops.org> Subject: Re: [VoiceOps] SS7

This is generally true if the calls are *unencrypted* on VoIP...

On Thu, Apr 21, 2016 at 2:20 PM, Kidd Filby <kiddfilby at gmail.com <mailto:kiddfilby at gmail.com> > wrote:

> > > > > >

...

Also folks, don't forget, the same outcome of recording someone's call is MUCH easier to accomplish once it is VoIP. IMHO, of course. ;-)

> > > > >

... BUT... what's fascinating is the recent rise in end-to-end (e2e) encryption among IP-based communications platforms that include voice.

WhatsApp, for instance, just completed the rollout of e2e encryption on April 5, and not just for messaging, but also for voice and video calls as well as file transfers ( https://blog.whatsapp.com/10000618/end-to-end-encryption <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.whatsapp.com_10000...> ). Just yesterday the team behind Viber announced that they will soon have e2e encryption for all clients. The app Wire ( http://wire.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__wire.com&d=CwMFaQ&c=N13-...> ) also does e2e encryption for voice, video and group chats.

In a US Congress hearing this week, a Congressman asked a Dept of Homeland Security representative if e2e encryption available in apps would have prevented this interception that happened via SS7. The DHS answer was that it would mitigate the interception of the content, although the location meta-data would still be available. (You can view the exchange via the link in this tweet: https://twitter.com/csoghoian/status/722854012567969794 <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_csoghoian_s...> )

The end result is that we're definitely moving to a space where the communication over IP-based solutions will wind up being far more secure than what we had before.

Interesting times,

Dan

--

Dan York

dyork at lodestar2.com <mailto:dyork at lodestar2.com> +1-802-735-1624 Skype:danyork

My writing -> http://www.danyork.me/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.danyork.me_&d=CwMFaQ...>

http://www.danyork.com/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.danyork.com_&d=CwMFa...>

http://twitter.com/danyork <https://urldefense.proofpoint.com/v2/url?u=http-3A__twitter.com_danyork&d=Cw...>

--------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.

_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops > > > >

-- Kidd Filby 661.557.5640 (C) http://www.linkedin.com/in/kiddfilby

_______________________________________________ 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

...