A WebRTC-compatible endpoint must be able to communicate with a WebRTC endpoint, but apparently need not understand it, at least that is what I make of it.
WebRTC-compatible are things that do not implement the Javascript API. These include things like single-purpose smartphone apps. A "WebRTC doorbell" was an example given at the IETF.
With this proposal, any WebRTC-compatible device can communicate with any browser with video.
These are video codecs. Presumably an audio-only app (e.g. IP phone) would be compatible too, so that would explain using neither of the two video codecs. WebRTC also has datachannels that use neither audio nor video.
This was already-existing terminology in the IETF working-group. A "WebRTC-compatible" device is one that does not conform to the standard, but which can talk to something that does conform to the standard )in whatever limited way it supports). By definition no codec requirements can be placed on it. This was spelled out clearly in the original proposal: http://www.ietf.org/mail-archive/web/rtcweb/current/msg13432...
I'm reading that as WebRTC endpoints have to implement those two, but there's nothing precluding them from negotiating to use H.265 or Sorenson or Mpeg-1.
https://tools.ietf.org/html/draft-ietf-rtcweb-overview-12#se... mentions one concrete example of a WebRTC-compatible endpoint: a WebRTC Gateway that mediates between a WebRTC endpoint and a non-WebRTC endpoint.
Vague? Yes. Poor choice of words? Yes (both IMHO)