Did you actually get into the internals of WebRTC on your project? That is when you notice the overengineering.
In our product, our customers generally want the session recorded, which doesn't seem possible with WebRTC. Also we need to provide group video, which peer-to-peer isn't very useful for (in terms of efficiency).
That's not to say that WebRTC isn't useful in other use-cases (such as your product). However getUserMedia is more generic because it can be used in web conferencing products like ours. That is why I say that if browser developers don't want to implement the full WebRTC, they should at least implement getUserMedia.
Ah, now I see what you mean. I agree--getUserMedia is useful on its own, with or without WebRTC.
Personally, I do hope they implement the full stack, though, because WebRTC--or ObjectRTC--is useful on its own, too (this is why I was saying they were orthogonal.) WebRTC using pure Data Channels is wonderful for enabling things like BitTorrent-like data sharing and realtime LAN gaming, whether or not there's any videoconferencing going on.
In our product, our customers generally want the session recorded, which doesn't seem possible with WebRTC. Also we need to provide group video, which peer-to-peer isn't very useful for (in terms of efficiency).
That's not to say that WebRTC isn't useful in other use-cases (such as your product). However getUserMedia is more generic because it can be used in web conferencing products like ours. That is why I say that if browser developers don't want to implement the full WebRTC, they should at least implement getUserMedia.