WebRTC concepts

WebRTC is a bundle of standards and technologies that enable peer-to-peer audio, video and data acquisition, streaming and exchange. Its first "killer app" is video calls and videoconferencing. Its first implementation is in web browsers (more than one billions WebRTC compatible browsers out there), its technology is already in use by many of smartphones' apps, and is predicated to be the base for Internet of Things (IoT) multimedia communication (will be many billions IoT devices WebRTC enabled).

In the most straightforward and popular implementation, the browser will access a website and load a page that contains Javascript. That script functions use WebRTC APIs (see below) to interact with the local computer multimedia hardware (microphone and camera) and to stream audio and video to/from peers.

The emphasis here is on peer-to-peer.WebRTC does not prescribes or support anything that goes beyond grabbing, sending, receiving, and playing streams. No signaling, no user directory or location services, no protocol to negotiate a communication session establishment and tear down, etc.

WebRTC is NOT a protocol, nor a service. Using only WebRTC technologies you must hardcode addresses in your application, on both the peers, and hope to find them listening, and the application will only work for those peers.

For anything but the simplest demo WebRTC needs some form of signaling and session management protocols. For your WebRTC service you can adopt a ready made protocol, or invent your own.

The most established signaling session management protocol is obviously SIP, which runs the entire world telecommunication network, from PSTN carriers to mobile operators to PBXs and calling services. Another signaling protocol in wide usage is XMPP, mostly for the management of instant messaging and presence services.
There are plenty of proprietary closed protocols, most notably the one behind Skype.
And there are open source alternatives geared toward Web Developers and JavaScript programmers such as FreeSWITCH's Verto. You will have to choose one, or write your own.

WebRTC technologies are embodied in three groups of Application Programming Interfaces (APIs) software developers use to build applications: GetUserMedia (GUM), RTCPeerConnection (RTCPC or PC), and RTCDataChannels (RTCDC or DC).

* GetUserMedia is about enumerating multimedia hardware on the local machine, asking user permission to control the microphone and camera, getting their streams, and playing streams through local screen and speakers

* RTCPeerConnection is about moving those audio and video streams between defined peers

* RTCDataChannels is about moving arbitrary data (even structured data) between defined peers

WebRTC RTCPeerConnection can (and must) use ICE, STUN and TURN to pass through firewalls and NATs, and eventually reach its peer.

ICE is a technique that has been popularized by WebRTC itself, and is gaining enormous traction. It is the real silver bullet for all networking problems, and works kind of perfect, being the distilled wisdom of many years of engineering VoIP services.

ICE will use a STUN server to tell the application what is its public address as seen from the Internet (eg, from outside NAT and firewall), and will use a TURN server as in-the-middle relay in the case peer-to-peer communication is not possible or fails.

So, a functional WebRTC application will need to:

* Use GetUserMedia API to control mic and camera

* Use a session protocol and possibly external auxiliary servers to locate the peer and establish a session

* Use ICE (and STUN and TURN) to find the network path to the peer

* Use RTCPeerConnection to stream audio and video to/from the peer