Skype Gives In: Group Video Chat Now Free, Like Hangouts
Hurray for the free market and its few remaining giant members.Because of pressure from Google Hangouts, which has offered free group video calls for a while now, Skype has announced they'll begin rolling out free group video calls. Unfortunately they're starting with desktop clients first.
Lifehacker has a brief writeup here , with more information available via the Skype blog .
This is good news for me since I have an Android phone on which I've thus far completely avoided registering a Google account (though I was just about to, since I found out that you can do two-way Hangout chat with a GMail address but WITHOUT having to succumb to Google+).
This is a nice alternative for those who'd rather sell this part of their identities to Microsoft instead of Google, and who have still managed to avoid the incessant +ing of Google.
Score one for heterogeneity.
[Ed. note: Coincidentally, this comes very close on the heels of Google pulling back on Google+ and supposedly moving its Hangouts dev team to Android.]
From the Jitsi FAQ:
_________
Why can't I connect to ekiga.net?
NB: the problems described in this section also apply to other providers such as 1und1.de
Short Answer: The ekiga.net SIP servers are configured in a way that prevent Jitsi (and many other SIP user agents for that matter) to register with the service. Please use iptel.org or ippi.com instead.
Slightly Longer Answer: The service at ekiga.net is configured to only accept SIP REGISTER requests that contain a public IP address in their Contact header. This means that registration from Jitsi would fail unless you actually have a public IP address. The Ekiga client circumvents this by using STUN to learn the address and port that have been allocated for the current session. It then uses the pair in the SIP Contact header. This kind of use was common for the first version of the STUN protocol defined in RFC 3489 which was sometimes referred to as "classic STUN".
The IETF has since significantly reviewed the way STUN should be used. The new version of the protocol is now defined in RFC 5389 which, among other things, advises against the use of STUN as a standalone NAT traversal utility:
However, experience since the publication of RFC 3489 has found
that classic STUN simply does not work sufficiently well to be
a deployable solution.
Today STUN represents one of the tools used by complete traversal mechanisms such as SIP OUTBOUND (RFC 5626) or ICE (RFC 5245). Neither of these includes sending a STUN obtained address in a Contact header.
So, where does Jitsi currently stand on all this? At the time of writing, we support the ICE protocol but only use it with XMPP. Use with SIP is likely to come in the near future. The reason we haven't implemented it yet is that most SIP servers currently open to use over the Internet, use a technique called latching. When such servers detect you are connecting from behind a NAT, they would start acting as a relay, receiving media from your peers and then forwarding it to you (and vice versa). While this is by far the most reliably way of traversing NATs, it does indeed imply some scalability constraints.
ICE on the other hand would only fall back to relaying if no other way was found to connect the two participants. This is why it is considered as a more optimal solution and why it's also on our roadmap.
Note however that the constraints on ekiga.net would continue preventing Jitsi from connecting even when we do implement support for ICE.
___________