First of all I define a "webrtc" term. Webrtc is a set of APIs for work with:
Secondly I describe two specials servers for establishing connection between peers.
Mostly devices in the Internet have gray IP addresses. They connect to the Internet via provides.
Providers have a lot of clients and small pool of public (white) IP addresses therefore they assign one public IP to one active client.
It can be done in various ways. This process is called NAT - network address translation. There are two big type of NAT - symmetric and asymmetric.
Both can translates IP address and ports. One assigns IP for a long time but second do it for each request.
There are two servers - STUN and TURN. First is necessary for discovering your public IP address if you have gray address.
For example - you send some special message to the STUN and it responses with your NAT.
In order that establish connection between peers in the Internet you must:
There are many public STUN/TURN servers - https://gist.github.com/zziuni/3741933.
Also there are many open source java implementation of STUN/TURN protocols and servers.
I'm using a public google stun server for demo app. It doesn't support TURN mode but work fine for my local provider.
To sum up for our webrtc scheme you need have two servers - STUN and TURN.
Establishing connection between peers demands one more public server - a Signal server.
It uses for transmit auxiliary data. The following steps are typical that connect two peers:
Alice is going to call (video/audio) to Bob.
This is a short description how to connect two peers because client must exchange ice candidates too but it's similar on offer/answer exchanging.
The following picture illustrates typical work-flow.
Our signal server.
Our signal server uses JSON format for message and work via web-socket's protocol.
Why have I used JSON and web-sockets? Because JSON is a native format for JS in browsers and the web-socket is the fastest protocol for reliable connections.
Also web-sockets are integrated into JS and are supported by all modern browsers.
A structure of particular packet you can see in the code. It's attached to the this documentation.
Our signal server works under red5 server and uses tomcat-embedded web-sockets.
The RTCPeerConnection API is oriented on p2p connections but our signal server also supports room.
You can create a new room just via sending createRoom message and you can connect to the room by id.
I've taken care about the flood attack on server so when you connect to the room you shouldn't create RTCPeer object and allocate any resources.
Signal server transmits your connecting message to all other clients in the room and they send your offer later.
A few words about demo client in browser - it's written on JS and supports our signal server.
It also can be improved via using some cross-browser library for RTCPeerConnection (https://github.com/otalk/rtcpeerconnection).
You also can test signal server - all instructions are in README file.
As I mention in Our signal server chapter the RTCPeerConnection API is oriented on p2p connections but It allows to create client-server solutions.
I need to implement server-to-client solution because OM works on server-client architecture.
For this purposes I've invented the next solution.
The solution is to add our native client into communication and dump video stream from native client on hard disk.
This will work because we use our signal server that can do anything for us.
I've tryed to create RTCPeerConnection on java but there aren't any java api for this purposes.
There are only js api and some abandoned demos in the Internet but I've found the repository with native (c++) webrtc peerConnection api for browsers.
This native implemenation includes java api for android. But It also broken, you can see explanation here - https://groups.google.com/forum/#!topic/discuss-webrtc/BUPq2UxIyq8.
I've implementing RTCPeerConnection api for java. I used the native webrtc source and JNI because implementing webrtc requires a lot of protocols (SRTP, SCTP, RTP etc).
I would have done this JNI stuff but I hadn't been stuck with one problem. I couldn't glue JNI and multi-threading native client. I've received JVM errors about damaged frame stack.
So I've implemented demo native client that works via console as signaling. The native client's code is attached to the this doc.
To build and test it you must do the following tasks:
$ ninja -C out/Debug
It can connect to the browser RTCPeerConnection and dump stream into hard disk.