WebRTC Server side Signaling

2
votes

I am new to WebRTC.
I am looking to develop an Application on GAE Java infrastructure. Its a large application but I am looking to solve

Communication between Peer to Peer ie Browser to Browser

Goal : When a user draw a line on HTML 5 canvas, it should get updated on the canvas of the other user who is watching it. There will be one writer and multiple watchers, who only see the changes that writer is making. ( This is business logic )

Some links : http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/#how-can-i-build-a-signaling-service. I went through through these links which gives some knowledge on WebRTC but does not demonstrate or give any clue regarding (metadata) that need to be maintain on Server side in order to develop Signaling Server. I am looking to develop Signaling server using Channel API (Java)

My confusion : How address negotiation should be done on server side to make browsers talk to each other. Little code example or Algorithm in English sentences will really help..

Please let me know if I am in wrong direction. Few guidance will make things easier for me and even help me develop it better.

Thanks for your help. I really appreciate. Thanks, Shashank Pratap

1
javagoogle-app-enginewebrtcchannel-api
essentially, it is just a signalling server that will just forward messages between the parties. You may want to indicate what is being sent with each message but JSON is your friend in this regard – Benjamin Trent

1 Answers

3
votes

WebRTC is P2P communication. Media data transfer is all handled by PeerConnection library. For this p2p connections, each peer carry out ICE process. In 'ICE process', I mean sending/receiving ICE candidate information (usually a small JSON message). To do this, each peer need another direct communication channel. We just need some kind of "Chatting" rooms.

Suppose: peer1, peer2, server

  1. peer1 connects to server, wait for the other
  2. peer2 connects to server
  3. server internally makes a 1:1 communication channel for peer1, 2
  4. peer2 start ICE procedure
  5. peer2 sends ICE candidate message to server
  6. server blindingly forward this message to peer1
  7. peer1 receives ICE message and then send reply
  8. server forward this message to peer2
  9. steps 5~8 repeats until peer1,2 establish p2p channel

And then, real data transfer begins.

I think, above is the most simplistic scenario.