I think the key is “comprehensive”. I find the level of true ICE and TURN support offered in pre WebRTC clients to be sub par.

This movement has envigorated the attitude towards promulgation and adoption of these standards.

@Warren,

The mechanisms that WebRTC is using for NAT traversal, ICE, TURN, STUN, have all been available and used by SIP and XMPP products well before WebRTC appeared.

The only piece of NAT related work that is happening within the context of WebRTC is “Trickle ICE” and this does make NAT traversal more reliable, it just makes the negotiation faster.

@Aswath

Downloading the signaling makes you compatible with yourself … so not much of win. You get the same level of compatibility when you download and install the same client on two machines.

The one true advantage of the WebRTC *model* is ease of deployment but that is still a promise that WebRTC has to live up to given its support by “only” two major browsers (i.e. when you are deploying web RTC apps, you still need to worry about the other browsers or require your users to install stuff … as with rich clients).

There is of course a side effect to the WebRTC work which is to get the community to agree on improving, adopting and deploying a number of protocols such as bundle, trickle ice (and ICE actually), SRTP, RTCP-MUX and many others. This is of course very positive but it is not exclusive to WebRTC and web pages.

I actually think the network compensation is better than most other implementations and certainly much better than any of the low to mid tier VC products.

To me though, the biggest breakthrough is the comprehensive NAT traversal that allows the peer to peer set up. If this had been available previously with non-browser soft clients over existing SIP signalling, WebRTC may not seem quite so special now.

Aswath,

You are of course correct. The whole point here is a request to stop evangelizing WebRTC for providing better media quality.