With the release of the latest rtc.debian.org portal update, there are numerous improvements but there are still some known problems too.
The good news is that if you have a web browser, you can probably make successful WebRTC calls from one developer to another without any need to install or configure anything else.
The bad news is that not every permutation of browser and client will work. Here I list some of the limitations so people won't waste time on them.
Just about any SIP client can connect to the proxy server and register. This does not mean that every client will be able to call each other. Generally speaking, modern WebRTC clients will be able to call each other. Standalone softphones or deskphones will call each other. Calling from a normal softphone or deskphone to a WebRTC browser, or vice-versa, will not work though.
Some softphones, like Jitsi, have implemented most of the protocols to communicate with WebRTC but they are yet to put the finishing touches on it.
The new WebRTC frontend supports SIP chat messaging.
There is no presence or buddy list support yet.
You can even use a tool like sipsak to accept or send SIP chats from a script.
Chat works for any client new or old. Although a WebRTC user can't call a softphone user, for example, they can send chats to each other.
On a wheezy system, the most recent Iceweasel update is version 24.7.
This version supports most of WebRTC but does not support TURN relay servers to help you out of a NAT network.
If you call between two wheezy machines on the same NAT network it will work. If the call has to traverse a NAT boundary it will not work.
Wheezy users need to either download a newer Firefox version or use Chromium.
Internet Connectivity Establishment (ICE, RFC 5245) is meant to prevent calls from being answered with missing audio or video streams.
ICE is a mandatory part of WebRTC.
When correctly implemented, the JavaScript application will exchange ICE candidates and run the connectivity checks before alerting anybody that a call is ringing. If the checks fail (for example, with Iceweasel 24 and NAT), the caller should be told the call can't be made and the callee shouldn't be disturbed at all.
JsSIP is not operating in this manner though. It alerts the callee before telling the browser to start the connectivity checks. Then it even waits for the callee to answer. Only then does it tell the browser to start checking connectivity. This is not a fault with the ICE standard or the browser, it is an implementation problem.
Therefore, until this is fully fixed, people may still see some calls that appear to answer but don't have any media stream. After this is fixed, such calls really will be a thing of the past.
Although these glitches are not ideal for end users, there is a clear roadmap to resolve them.
There are also a growing collection of workarounds to minimize the inconvenience. For example, JSCommunicator has a hack to detect when somebody is using Iceweasel 24 and just refuse to make the call. See the option require_relay_candidate in the config.js settings file. This also ensures that it will refuse to make a call if the TURN server is offline. Better to give the user a clear error than a call without any audio or video stream.
require_relay_candidate is enabled on freephonebox.net because it makes life easier for end users. It is not enabled on rtc.debian.org because some DDs may be willing to tolerate this issue when testing on a local LAN.
To find out more about practical integration of WebRTC into free software solutions, consider coming to my talk at xTupleCon in October.
More news and policy statements regarding my campaign for Dublin Bay South:
Please print my brochure if you want Ireland to change