|
|
|
Posted
3 months
ago
“Voice Isn’t Dying” - Voice isn’t Dying It seems like everywhere you look these days, someone is killing the voice network. ReadWriteWeb says “Microsoft’s Skype owns 1/3rd of a dying network” and Facebook has
... [More]
a mobile client that now does free phone calls, but all of these projects are missing the point. It is precisely this dogmatic approach to annihilating voice that assures the long life of telephony. How? Because the phone network has a few qualities that a company like Facebook will never offer.
One of the key features of the phone network is interoperability. If I pick up a phone in San Francisco and call a phone number in Zimbabwe, I know the phone in Zimbabwe will ring. I don’t care what equipment that network operator runs, we both don’t have to be logged into Facebook to connect, and I know that the call is routed over a secure connection that is regulated by the governments. Further, I know that the phone number will route because of the ubiquitous international directory we call the NANP (North American Numbering Plan) which most of the world has adopted, along with e164, both standards.
Let’s contrast this with any free voice application. In order to have free calls on a mobile phone, we both have to use the same app and the call is routed over the public internet with best-effort service. If the call drops, no one can be blamed, and if service is out, well, good luck. In fact, when we talk about the idea of interoperability, it is actually antithetical to Facebook’s business, and the business of most application-based telecom companies. What benefit does Facebook derive from interoperating with companies like Voxer? The answer is none and that’s why Voxer lost access to the Facebook API.
In reality, the phone network won’t die any time soon because of the ubiquitous address book we call phone numbers, the advantages of interoperability and because of the extremely low barrier to entry. While Facebook may have between 500M and 1B active users, the phone network is many times larger than that (with Cellular penetration exceeding 200% in places like Hong Kong). Facebook is massive, but the telephone network is more massive still.
So if Voice isn’t dying, what is changing?
A lot of folks argue Voice is dying, but when you get down to the nitty gritty, most of the time what they’re actually arguing is that copper is dying. This very well might be true, especially in light of AT&T attempting to have the FCC relinquish its requirement that AT&T maintain the copper networks in the US. If that happens, the only copper networks that will remain active are those that are profitable, which is certainly not ubiquitous connectivity.
At the same time, we perceive fewer folks to be using voice as alternative non-synchronous methods of communication become more common place (SMS, email, etc.). That being said, Synchronous methods of communication, like Phone calls, will continue to exist so long as time sensitive activities are necessary. The market is changing, migrating away from copper, but voice is hardly dying. In fact, part of the perception of lower voice usage comes from the fact that IP communications are much harder to measure, due to the nature of IP.
Essentially, companies like Skype and Facebook and all of the other upstarts won’t kill Voice because Voice is a necessary evil. And, let’s be honest, just because the last mile of the connection is turning into wireless doesn’t mean all that core switching infrastructure is suddenly useless. In fact, quite the contrary; that core switching infrastructure becomes many times more important as the quantity of data, and the stochasticity, increases.
No, Voice isn’t dying; it is evolving.
If talking about Voice Networks and the evolving communications needs of society gets you hot under the collar, we’re hiring! Looking for Senior engineers and Sales folks to help scale out 2600hz, the Cloud telecom company. We’re building amazing Open-Source Telecom infrastructure and changing the world, one call at a time. Join us today!! [Less]
|
|
Posted
5 months
ago
2013 is just getting started and so is 2600hz! We’re proud to announce that we’re the recipients of the Communications Technology ‘Innovator Award’ at DeveloperWeek! We’re also giving away 5 passes to DeveloperWeek starting in
... [More]
February! Here’s how you can win a free conference pass ($120 value):
TO WIN: Tweet a message with the hash tag #dev2600 and tell us how Technology makes your life better. We’ll pick the top 5 messages and send passes to Developer week!! [Less]
|
|
Posted
5 months
ago
“Kazoo and International Numbers: How to play nice with E.164” - This post comes courtesy of one of our Open-Source community users: Kiste. Check out the article on his site here. How to play nice with E.164 in
... [More]
Kazoo
This post is based on the docs one can find under kazoo API, To add some numbers via the API and curl:
1) Generate an X-auth-token
curl -X PUT http://YOURURL:8000/v1/api_auth -d ‘{ “data” : { “api_key” : “YOUR_API_KEY_HERE” }}’
(You can find the api-key in your couchdb => accounts)
This will give something like : “auth_token”:”555555c8d6f213098729999999999999″
2) Let’s have a look which numbers are already assigned to the account
curl -X GET http://YOURURL:8000/v1/accounts/YOURACCOUNTID/phone_numbers
-H “X-auth-token:555555c8d6f213098729999999999999″
3) Let’s add a number to an account
curl -X PUT http://YOURURL:8000/v1/accounts/YOURACCOUNTID/phone_numbers/43112345678
-H “X-auth-token:555555c8d6f213098729999999999999″
4) Let’s activate the number
curl -X PUT http://YOURURL:8000/v1/accounts/YOURACCOUNTID/phone_numbers/43112345678/activate
-H “X-auth-token:555555c8d6f213098729999999999999″
That’s it! We’ve successfully added an International Number to Kazoo. If you’re still having trouble, see below.
Security Protip: Never post your Auth Token online or any secure information.
If one will gets the error:
“wh_number_manager:349 () create number prematurely ended: not_reconcilable”
When one tries to add an international number one needs to change inside the doc of the system_config => number_manager into something like:
from
“reconcile_regex”: “^\+?1?\d{10}$”
to
“reconcile_regex”: “^((\+49)?[2-9]{2,5}[1-9][0-9]{5,10})$”,
This will allow Full E.164 numbering into Kazoo. [Less]
|
|
Posted
6 months
ago
Cisco Phones are completely compromised. More details soon. Check out the video above for the full presentation; if you don’t have an hour, check our blog next week for a piece on exactly what’s happening here.
Bottom line: Cisco Phones are eavesdropping devices and can be pwned remotely.
|
|
Posted
6 months
ago
This is what Disaster Recovery looks like for the folks on the ground after Sandy. This is a problem we can fix. Disasters don’t have to mean reverting to 100+ year old technology. We can do better and we will.
|
|
Posted
6 months
ago
“2600hz Speaking Events and Trainings for Q1 2013” - Happy New Year to one and all! 2600hz is getting rocking in the New Year. Check out the following places where we’ll be speaking: Speaking
... [More]
Engagements:
DeveloperWeek on February 2nd-7th in Downtown San Francisco. Awesome Panel featuring Darren and some of our friends!
ErlangDC on February 9th in Washington DC. Darren will be dropping knowledge on Telecom applications in our favorite functional language.
Channel Partners on February 27th-Mar 1st in Sunny Las Vegas. We’ll be causing trouble all over the Desert, come say hello!
IWCE also in Vegas on March 11th-15th. Darren will be moderating a Panel on evolving 4G wireless standards.
We’re also looking for additional speaking opportunities, so if you have somewhere you’d like us to attend, please drop a line to pr@2600hz.com.
Trainings:
2600hz will be doing multiple trainings in 2013. Here are a couple that we’re doing ASAP:
Evening School of Erlang with Erlang Solutions, starting on January 12th. This is an in-depth awesome crash course on all things Erlang. There’s only 5 tickets left so jump on this today!
We will be hosting a Kazoo Training in late February/Early March. We plan on hosting this training in New York and will finalize the date ASAP. Be on the look out for emails. We will be doing a West Coast training in the middle of the year.
It’s an exciting 2013. We can’t wait to be part of more amazing product launches, awesome events and fun times. See you on the wild side! [Less]
|
|
Posted
6 months
ago
“Top 10 2600hz Blog Posts of 2012” - Early one day as 2012 draws to a close, We sat and thought back on a year full of prose, The best of the best, check them out while you’re here, Ten posts we selected
... [More]
for a year full of cheer,
Lessons on Firewalls and SBCs,
A memoir of Sandy as she brought the East Coast to the seas,
BYOD and CYOD helped corporate IT erase frowns,
It’s all good, here’s how we stayed up while GoDaddy went down,
Enjoy these posts, picked and written with care,
We hope you’ll come back and enjoy more next year,
So to each a Happy Holiday and yuletide cheer,
To each one and all a Happy New Year.
-From the friends and family at 2600hz
TOP 10
[1] In our first post, we have our article discussing Firewalls and SBCs. Check out this detailed explanation of how these network devices differ and compliment eachother.
[2] In our second post, we have our article detailing BYOD versys CYOD. Emerging trends in Enterprise IT are a must-read for the network security and IT Professional.
[3] In our third selection, we have an analysis of disaster communication focusing on Sandy. It was a very rough season for our East Coast brethren but here are some tips on customer attention during disasters.
[4] In our fourth piece, we have a description of our change to Kamailio. OpenSIPS has served us well but we’re cutting over to Kamailio for a few specific reasons. Learn more about this change and our technical reasons for jumping over.
[5] In our Fifth offering, check out this writeup on how to stay up when GoDaddy is down. Hint: Distributed Systems Engineering and Fault-Tolerance.
[6] Our 6th top pick is our launch of Kazoo. It’s been a lot of work to bring out this technology and we’re only getting started!
[7] 7th is a great application for connecting users over social networks. One of our community developers wrote an awesome application to connect users on VK!, a large European social network.
[8] Next up, and 8th, was a hard piece to writesince it represented our only real downtime of the year. It’s important, if you’re going to be accountable, to present information in an honest and easy to understand format. We continue to better our network and our monitoring tools and we’ve had an awesome 2012 in terms of uptime. Lessons learned.
[9] Getting to the end, number 9 is our discussion of the connection between FreeSWITCH and OpenSIPS. This high-level overview will breakdown how our switch connects to our SBC and why we run both of them in our network.
[10] And the last article, number 10, is on the nature of Text Messaging. We’re revealing secrets about the SMS network.
Thanks and we can’t wait to see what this list looks like next year!
Like what you’re hearing? Learn more about 2600hz at http://www.2600hz.com. Or, if this sounds like fun, come build the future of Cloud Telecom with us. Email us at info@2600hz.com if you’d like to chat. [Less]
|
|
Posted
6 months
ago
We at 2600hz want to wish each and all of you a Happy Holiday Season and a wonderful New Year.
We’re going to keep building great technology in 2013, and we look forward to having a lot of fun while we continue to work hard on our software.
Thanks to one and all, and to each a Good Night.
|
|
Posted
6 months
ago
“To Have or Have Not: DPI, The ITU and what it means to You” - To Have or Have Not?: DPI, the ITU and what it means to You Ho Ho Ho! It’s time for the holidays around these parts but things aren’t quite as silent as one
... [More]
might hope. Thanks to a big holiday present from the International Telecom Union (ITU) the whole world is watching as operators drink eggnog and debate the free world as we know it. With this in mind, we’re tackling one of the biggest topics in networking today: DPI.
It seems that the whole world is in an uproar about Deep Packet Inspection (DPI). As many of our readers may know, DPI is about inspecting internet traffic as it transverses large networks (ISPs, DataCenters, Enterprises, etc.). In the case of this ITU ruling, we’re talking mostly about ISPs, and the big ones at that. It’s important to understand that DPI isn’t some big scary monster, in fact, if you’re using an SBC or a content-aware firewall, you’re already using DPI in your business today. Why then is it so scary?
What is DPI?
So before we go any further, let’s quickly talk about what Deep Packet Inspections (DPI from here on out) is. To understand DPI we have to understand how Switches and Routers work.
Switches and Routers connect computers together by exchanging packets of information between them. Simply put, switches and routers decide where information needs to go and how it should get there. You can think of switches like small intersections within a city. The roads are wires or lanes to your computer, with the intersection being the point where the traffic criss-crosses and gets directed on it’s way. Routers are more like large highway access ramps or interchanges. They often have rules about who can get on or off via that interchange (no trucks! one-way! keep left!) and how.
In today’s world, most routers and switches tasked with managing the flow of traffic do so with as little intelligence as possible. They look at where the driver wants to go and, as fast as possible and with as little effort as possible, sends them blindly on their way to the next point in their journey, which, depending on your application, may or may not be what you want. Then there’s DPI.
DPI is like an inspection of the traffic and analysis of it, before it goes on it’s way. Using the same analogies as above, DPI might be like a policeman at a freeway on-ramp inspecting every cargo load that was being taken onto the highway. There might be various reasons for this inspection – weight restrictions, terrorist threats, lost children, etc. This is a “deeper inspection” into your car, just like DPI is a deeper inspection into your computer’s data packets.
How Does DPI Work?
DPI is generally performed one of two ways: either by the Firewall which sits between the router and your switch or using a fiber tap to send the network traffic elsewhere for analysis. Today w’re focusing on Firewalls as the case for batched processing is much more murky. DPI enabled firewalls differ from Switches and Routers. Whereas switches are mainly concerned with frames (layer 2 OSI) and Routers are concerned with packets (layer 3 OSI), DPI-enabled Firewalls examine packets from frame to actual application structure (layers 2-7). The key difference here is that frames and packets have a set of directions which are supposed to be explicitly followed by the routing system. With the introduction of application sensitive filtering routing can be done not just on the basis of where the packets and frames want to be sent, but on the basis of where the administrator wants a given application sent. DPI represents one of the first times in history that packets can be diverted based not on a users commands but on the basis of a firewall segregating traffic. This sounds really bad. Why would anyone want this?
The Datacenter of Tomorrow
You sign up for access to the Datacenter of Tomorrow. You’re provisioned inside of the DC, you’re administrating your servers but you’re getting a sluggish response on your voice application. With the click of a mouse you’ve designated your firewall to pickup your voice traffic and prioritize it above other traffic you’re sending out. Now your voice is working great, but what about the rest of the DC? It turns out that the operator is able to control which applications get prioritization, not with packet tagging, but simply by entering the name of the app into their console and promoting it in a priority list. Let’s say one particular application is giving you trouble. Previously you’d isolate the packets and try to figure out what the heck was sending out so much trash on your network. Now, you grab the application ID from your console and those packets never make it past any of your firewalls. But what about today?
Toto, I don’t think we’re in Kansas Anymore
There is a sincere and real risk that content aware firewalls will damage the ability of individuals to communicate openly on the Internet. Repressive regimes, particularly in the middle east, use technologies like Blue Coat content filters to block “bad” traffic, identify dissidents and provide evidence in State-Sponsored inquisitions. These are not good side-effects of DPI, and for many parties these aren’t side-effects at all, but rather goals. This is the scary side of DPI, the idea that your ISP can know not just that you’re sending packets, but what those packets contain. This is the crux of why everyone is so up in arms, but how do we ensure that technology advances while still retaining personal freedom? We think of this from both a societal and economic perspective, and with the latter being easier to explain we’ll discuss this idea from that perspective. We believe that personal freedom and privacy are tremendously important but we’re focusing on the economics today.
The Datacenter of Today
2600hz is obsessed with VoIP, and one of the biggest issues in VoIP is fraud. There are so many different ways to defraud companies in VoIP, but one of the ones we see most often is attempting to steal credentials and create fraudulent calls. We leverage Kamailio as our Session Border Controller which leverages DPI to confirm packet intent against a set of heuristics. This dramatically reduces fraud on our network and would be impossible if we only used layers 2-3 for analysis. Because our border equipment supports analysis of packet intent, we can match the packet up against a registry (username/password) to authenticate them. Referencing a database inside of a firewall and applying a policy is hardly new, but doing it based upon the application signature instead of the header is a relatively recent innovation.
The Bottom Line
We at 2600hz believe that DPI is necessary for the evolution of the Web. As Spiderman’s Father once said “with great power comes great responsibility”. DPI has the power to make life a living hell for dissidents, but it also is key to moving massive networks forward. Understanding DPI is going to become an important portion of network engineering, but it has the potential to make many of the services we use today function in a better and more congruous manner. DPI is here to stay, and frankly it’s been here for a while. [Less]
|
|
Posted
6 months
ago
“The Difference Between a Firewall and an SBC” - Firewalls or SBC’s? What’s the difference to you and me? Seems like this question comes up a lot in our business. Controlling access to a site is critically important for most
... [More]
enterprises and the most common way to enforce policies is a firewall. Why then, do most Voice Operators use Session Border Controllers for access control? The Answer, like most things in VoIP communications, requires a bit of history and a little explaining. Let’s jump right into it!
What does a Firewall do?
Firewalls provide stageful control of interfaces (open or shut) for layers 2-4 of the OSI model (from the frame to the network segment). Newer firewalls have some Layer 7 (application) capabilities, but the majority of control is exercised on layers 2-4. In VoIP, there are two kinds of streams: media and signaling. Signaling is all about call setup and teardown (or any other action you’d like to perform) whereas the media is the actual audio being exchanged. While a firewall has to open only a couple ports for signaling, Media exchange requires opening a lot of ports, sometimes as many as 20,000. For Security Conscious Enterprises, this can be a deal killer, and so there are attempts to place Firewalls into the DMZ which can complicate things even more.
The gist of this is that Firewalls are great at enforcing port policies, but aren’t sensitive to the specifics of a particular application.
How does a Session Border Controller contrast with a Firewall?
If a firewall is a gate, a session border controller is a canal. Whereas a gate can only be opened or shut, canals have a series of trenches which are filled and then released. This buffer allows much more complex checks and adjustments than a simple open or shut gate. A Session Border Controller has some of the layer 2-4 port controls, but where they really shine is in their Layer 7 capabilities. SBC’s control port access based on signaling from the application. Whereas a firewall is either open or shut, an SBC can be adjust its availability based upon authentication and other criteria. Further, in certain circumstances (like NAT’d IP addresses) Session Border Controllers can rewrite SIP headers to private IP addresses, which helps internal to external routing mitigation (it makes it easier to get in/out of the firewall). Some firewalls do this natively in a way that damages the SIP packets (notably the SIP ALG transform on Cisco ASA’s for any Non-Cisco VoIP Packets).
Which one is better in a DDoS?
This is a little trickier. The heuristic analysis necessary to defeat mass packet attacks like a Distributed Denial of Service is different from the kinds of analysis one would want for countering malformed SIP headers. In certain cases (as exposed recently by the application SIP Vicious) a PBX can be attacked by rewriting the SIP address (similar to rewriting an IP Header) into a very long, or abnormal string. A normal Firewall would let such a packet into your system, which, depending on your PBX, could potentially disable the system for an extended period of time. As the firewall has no way of differentiating one SIP packet from another, this would be a case where an SBC’s application sensitivity would come in handy. On the other hand, if someone is pumping 50+ Gbps of traffic at your Public Facing IPs, you’re going to want a way to offload that traffic that an SBC may not be able to provide. For a large enough operation, the answer is that you’re going to want both, but an SBC is a critical portion of the infrastructure stack for VoIP, whereas a Firewall is something that is more general use and usually applied at scale in VoIP deployments.
So what’s the proper way to scale your boxes?
We suggest starting with Session Border Controllers and leveraging your hosting provider to deal with DDoS mitigation. Using Multi-homed DNS you can intelligently provide failover between multiple instances across the country with just a few clicks in an infrastructure like Amazon Web Services. At 2600hz we run Kamailio, which is our pick for best open-source SBC.
If this is interesting to you and distributed systems engineering makes you all warm and fuzzy inside, drop us a line at info@2600hz.com. We’re looking for a few good folks to come help us change the world by innovating Open Cloud Telecom. [Less]
|
Copyright
©
2013
Black Duck Software, Inc.
and its contributors, Some Rights Reserved. Unless otherwise marked, this work is licensed under a
Creative Commons Attribution 3.0 Unported License
. Ohloh
®
and the Ohloh logo are trademarks of
Black Duck Software, Inc.
in the United States and/or other jurisdictions. All other trademarks are the property of their respective holders.