The big telecom story today certainly seems to the be launch of Ray Ozzie’s new “Talko” application for iOS. Tons of attention in the tech media, and many of my friends on social media have been trying it out. There’s a brilliant article posted on Medium about the “Brave New Phone Call” along with a great blog post from Ray Ozzie about how this new app will revolutionize the voice experience.
I think Talko has great potential to do so, particularly after using it.
But…
… I had to change my firewall rules in order to make Talko work. 🙁
And I don’t know how long it will continue to work.
Perhaps worse than that… it wasn’t clear initially that I had a firewall problem. Frequent testing partner Jim Courtney sent me a message and after installing the Talko app on my iPhone I tried to talk to him, but all I seemed to be able to do was send him a voice message or a text message.
Subsequently I tried connecting to Tim Panton and again could only send voice messages. It made for a very asynchronous “walkie-talkie” style of communication that clearly seemed to not be what was described in the article.
At that point my many years in VoIP kicked in and I realized the firewall at the edge of my network was probably blocking something. Sure enough, when I pulled up the live firewall log and filtered on my iPhone’s IP address I could see blocked connections from my iPhone that were intended for an IP address in Amazon’s EC2 cloud. These blocked connections happened when I tried to initiate a voice conversation within Talko.
I first tried to create a firewall rule that would allow specific ports through, just by guessing from the firewall logs what ports Talko might be using. However, they jumped around and what I ultimately had to do was create a rule allowing any connection from inside my network to the specific IPv4 address of what I assume is one of Talko’s servers on Amazon EC2.
Once I did this, I was able to have a voice conversation with Tim perfectly fine. It was actually rather cool how it would record the conversation and let me easily go back, listen again, advance through it, etc.
But…
… poking a hole in my firewall to a specific IP address is very definitely NOT the way to have a telecom application work.
And… Talko will only work on my network as long as that destination IP address doesn’t change. If they add more servers or change their architecture, it’s dead to me. At least… dead on my home WiFi network. Presumably it could still work on my mobile data network (at a cost to me).
Now, to be fair, I’m a bit more security-paranoid than the average home user and so I run a Linux-based firewall/server/gateway on the edge of my home network with a fairly restrictive set of firewall rules. The default policy is to deny outbound connections unless they fit into various rules. I’ve had to add rules allowing VoIP and IM protocols… and it’s not uncommon for me to have to add new rules for applications like this. For instance, I had to do so for Tox when I was playing with it a few months back.
Odds are Talko will probably work fine for the vast majority of connections from WiFi networks with less paranoid firewall rules.
But… for an app like this to really challenge the existing telecom infrastructure, it needs to work from almost anywhere. This is why Skype usage is so ubiquitous – Skype “just works” and has its ways to work around firewalls. Within the SIP and WebRTC communities there are all the STUN / TURN / ICE servers and technologies that enable this kind of transit of a firewall. The technology is out there. And there will certainly be some enterprises and other businesses that set up firewalls at least as restrictive as mine is.
I realize today’s news is the initial public launch and that this is early days for the app. I hope the Talko team can figure out a way to make the voice conversation work through firewalls. I really like what I see inside the app.
Meanwhile… I’m just hoping they don’t change the IP address of the server with which my app is communicating!
If you found this post interesting or useful, please consider either:
- following me on Twitter;
- adding me to a circle on Google+;
- following me on App.net
- subscribing to my email newsletter; or
- subscribing to the RSS feed
Dan, decided to move the discussion here, since I will be able to ask/say longer statements.
You mentioned that the real issue is your FW rule nominally blocks UDP traffic and you have opened ports to a specific AWS instance. My first observation is that Talko is using that instance as a place to capture voice, so it can be recorded. Then I suspect, as the service grows, more such instance will be added. For your scheme to work, they should be using this IP address to distribute traffic to these instances.
The second one is really a question: for some admin reason you are blocking UDP, but willing to allow services like Skype or WebRTC app tunneling that UDP traffic thru TCP (port 80?). Isn’t that undermining your admin policy?
Aswath,
> My first observation is that Talko is using that instance as a place to capture voice, so it can be recorded.
Curiously, it seems that I can still record voice messages. I’m not sure if the voice is being recorded locally on my iPhone and then being uploaded to their server, or if Talko is connecting to a server and the recording is happening there.
The issue seems to be with LIVE connections. Those don’t work without the firewall hole.
> For your scheme to work, they should be using this IP address to distribute traffic to these instances.
Right. Which is why this scheme is broken. My firewall rule works today, but we can’t rely on an IP address to always be fixed.
> for some admin reason you are blocking UDP,
I am blocking UDP that doesn’t conform to one of my existing rules. I have rules, for instance, that allow most VoIP and IM protocols through, so my SIP-based softphones work fine. Talko is doing something different that doesn’t fit in one of the buckets of ports that I’m allowing.
> but willing to allow services like Skype or WebRTC app tunneling that UDP traffic thru TCP (port 80?). Isn’t that undermining your admin policy?
Sure, but the goal of my admin policy has historically been really more to prevent apps from opening up connections on unknown ports than it has been to restrict specific types of connections. To do that I’d have to start doing packet inspection and I am not that paranoid. I started doing it that way a number of years back when I was concerned about potential botnet clients.
Of course, those botnet clients could just do everything over port 80 and my firewall wouldn’t block it… so on a certain level perhaps it is time for me to revisit my firewall policies and just allow most outbound connections.
The recording you are referring to is voice message, but the one I am referring to is related to “hypervoice” aspect where the whole RTC voice (what you call LIVE connection) is recorded and can be accessed at a later time. That is best done at the conference bridge. I suspect that is what that AWS instance is.
I do not follow how your policy is able to manage other VoIP services if they use ephemeral ports for RTP flow. So I am not following something here.
Lastly, I asked about your views on admin policy being undermined because there is an attempt to standardize tunneling RTP thru TCP port 80 (a la Skype). On principle, I think it is wrong for a standard to suggest a scheme that undermines another standard. If I were an admin, I will take strong exception. So I am curious on your take, since you are sensitive this issue.
As fair disclosure mI am deeply interested in this issue since I have taken (in my service) the heretical position that if the LAN policy is to prohibit a flow then my service/app shouldn’t find a way out even if that means my service/app will not work.