Interoperability with V/VoIP protocols will still require a translation layer somewhere. That can be on the browser, or on the server, but you will still need some server-side component to relay the signaling information through (eg, websocket proxy), or a browser-interoperability mechanism (for xmpp, BOSH). If the remote endpoint doesn't support WebRTC's flavor of SRTP, then you're going to have to relay media through your server.
If SDP offer/answer is still being considered for WebRTC, then that should simplify interop a bit since media negotiation shares a common denominator with most other V/VoIP protocols (which is really the only relevant part when we're talking about WebRTC). Of course, all that is moot if both endpoints can't agree on a codec to support. Opus is brand new, and no one cares about VP8. Hardware devices are not likely to be compatible anytime soon (without a transcoding layer in between), which leaves softphones.
That's what I meant - most probably some server support will be required. I hope ejabberd and others will address this. Until that WebRTC won't be useful for building web based XMPP/Jingle clients.
Regarding codecs - most XMPP/Jingle clients support VP8 and Opus is catching up too. It's not like there are many of them around anyway. Farstream supports both if corresponding gstreamer components are present.
IIRC, ejabberd is agnostic about the XMPP messages going through, you should be able to use strophe.js to craft the proper Jingle packets from the browser's offer/answer session description.
Given codec and SRTP compatibility with clients, eg GTalk (which I don't know about), you should be good to go.
But ejabberd still had to enable support for BOSH or WebSockets first. Without it Strophe was of no use. So I assumed that similar thing has to happen with in this case in order to be able to route the Jingle stream from the browser over WebRTC. If the server modifications won't be needed at all - then of course it'll simplify things. Also, clients don't always use SRTP - there can be other methods like ZRTP for example.
If SDP offer/answer is still being considered for WebRTC, then that should simplify interop a bit since media negotiation shares a common denominator with most other V/VoIP protocols (which is really the only relevant part when we're talking about WebRTC). Of course, all that is moot if both endpoints can't agree on a codec to support. Opus is brand new, and no one cares about VP8. Hardware devices are not likely to be compatible anytime soon (without a transcoding layer in between), which leaves softphones.