One amazing fact about communication is its constant evolution. And this fact makes me very excited and passionate about working with it. What feeds this fantastic evolution is the crossing of frontiers — communication evolves every time one barrier is breached and a frontier is crossed.
We are very proud and happy to announce that Jive will cross its IM frontier and arrive in Real Time Collaboration land in the next major releases. In particular, I’m working on adding VoIP and other P2P services in Wildfire and Spark to become a complete Enterprise communication solution.
Every new technology has its own barriers that provide implementation challenges. NATs are very important for almost every company for security and networking reasons since IPv4 topology isn’t sufficient for current network demands. NAT provides mechanisms to allow an internal network with many internal IPs have access to an external network (Internet) using just one valid IP. NAT also increases security control since you just need to monitor and manage a single external IP.
Well, not everything is perfect. NAT creates some limitations for P2P applications because it generally prevents clients from knowing their own public address. It is crucial for P2P applications to be able to address one another (by definition). In a P2P model a point must send and receive packets directly to the another point without being relayed or redirected by another host.
Like strong winds were a signal barrier for smoke signal-based communication, distorting the smoke clouds and causing the messages to get lost, network NAT sometimes doesn’t know which internal IP it should deliver some packets to on internal networks. In this way NAT is the new barrier for real time collaboration, making some hosts unreachable.
There is another similarity between these barriers. Just as we can’t remove wind, we can’t just remove NAT, because we need them both. We have to pass through the barrier, or go around it using some mechanism that solves the issues caused by the barrier without removing the barrier. In the next version of Wildfire we will provide some of these mechanisms, starting with a STUN Server and a Media Relay Proxy. These services enable clients that are behind NAT to chat, talk and collaborate with other clients even if these other clients are behind NAT. For more on this topic, check out a recent blog entry by Jean-Louis.
P2P collaboration architectures are very important for the enterprise scenario. In the near future these kind of services will open a wide range of capabilities such as file sharing, video conferencing and much more, all without consuming server resources, which is our next frontier. Over the next several weeks, I’m looking forward to providing more in-depth information on the implementation work I’ve been busy with.
I can understand VoIP and I can’t wait until that is released. But what’s the idea behind P2P? What are the USE cases for it within an Instant Message server?
Nathan — great question. Applications like VoIP take a large amount of bandwidth and can be sensitive to network latency. Therefore, it’s almost always better to do the actual communication directly between the two clients (unless a firewall prevents that from working). So, it’s a “peer to peer” network connection, but not a “peer to peer” application. There are examples of this already in XMPP. For example, file transfers always try a peer to peer connection first and only resort to using a proxy if that fails. Jingle is the protocol extension in XMPP that unifies this network approach and will be used for voice, video, files, and other realt-time features that require a lot of bandwidth.
-Matt
That makes sense. I assumed that the VoIP call would be done directly between the two clients. Consuming the bandwidth from all users on the server would be ridiculous.
I don’t know if you guys know any of this yet. But I’m assuming it would support calling other Google Talk clients? Also does this lay the ground for integration with other services? For example calling out through an Asterisk server directly to PSTN?
Google Talk uses their own form of Jingle. As soon as they update to the official spec, interoperability should work (I’m told they’re looking to update relatively soon).
We’re actually building two VoIP technologies at the same time:
* Jingle for PC to PC calling, which will be Open Source.
* SIP softphone for PBX integration like Asterisk for placing regular phone calls from your IM client. This will be a commercial feature in Wildfire Enterprise.
We’re working on a roadmap page for the site that should help to make all of our plans clearer.
Thanks for the clarification. I look forward to the roadmap.
Are you guys looking for Beta Testers???? I would love to help you test these added features….. p2p voip and sip softclient
-CP
Clint Perry
We really like testers. As soon as we can, we will release an alpha version of Spark with Jingle Support for p2p, so you can help us to test it.
Regards,
Thiago