Add dial/receive signalling mechanism for AppRTCDe

Question

Hi I am using AppRTCDemo and its working on their server. How ever the current mechanism is for exchanging chat-rooms name and entering the same room connects the peers.

But I want to dial a call from one device to receive a call from other device and then peers should enter a room for video session ,

I have searched a lot , I have come up with for that I need signalling-server which I don't have and don't want to put hands on it ,

Now in this situation how can the other device know that device one is dialing and sharing particular room name to accept and enter the same room for video call at client side in Android .

https://github.com/njovy/AppRTCDemo

Answer 1

There are two android apk available for WebRTC, appRtcDemo and webRtcDemo. appRtcDemo apk can be used for android device to browser connectivity. You need to provide room id to connect to one room. If you are the room initiator then you have to enter -1. If you want to connect two android device then you have to compile and install webRtcDemo apk. This apk interface provide place to enter ip address of another device and vice versa then both device will be connected.

Please go through -> http://www.webrtc.org/reference/getting-started

For more information. Both the apks i've compiled and installed and checked how it works.

I was able to make calls successfully between two android device using webrtcdemo. But I tested using WLAN of my office network. I did not use it further because I was using apprtcdemo for app reference. My suggestion is when you enter remote ip in webrtcdemo,just check if loop-back is unchecked. I guess for you loop-back is enabled, so you are receiving your own video packet, though you have entered remote ip. Make sure loop-back is disabled while making call.

Answer 2

A very good explanation can be found in this book http://chimera.labs.oreilly.com/books/1230000000545/ch03.html#STUN_TURN_ICE which provides the fundamentals on how WebRTC uses ICE technology.

In particular assuming the IP address of the STUN server is known, the WebRTC application first sends a binding request to the STUN server. The STUN server replies with a response that contains the public IP address and port of the client as seen from the public network.

Now the application discovers its public IP and port tuple which can send to the other peer through SDP. (note that SDP are sent over an external signalling channel, f.i. websocket established through a web service)

With this mechanism in place, whenever two peers want to talk to each other over UDP, they can then use the established public IP and port tuples to exchange data.

Unfortunately, in some cases UDP may be blocked by a firewall. To address this issue, whenever STUN fails, we can use the Traversal Using Relays around NAT (TURN) protocol as a fallback, which can run over UDP and switch to TCP if all else fails.

WebRTC gives SDP Offer to the client JS app to send (however the JS app wants) to the other device, which uses that to generate an SDP Answer.

The trick is that the SDP includes ICE candidates (effectively "try to talk to me at this IP address and this port"). ICE works to punch open ports in the firewalls; though if both sides are symmetric NATs it won't be possible generally, and an alternative candidate (on a TURN server) can be used.

Once they're talking directly (or via TURN, which is effectively a packet-mirror), they can open a DTLS connection and use it to key the SRTP-DTLS media streams, and to send DataChannels over DTLS.

Edit: Acronyms here: http://blog.1click.io/10-jargons-abbreviations-for-webrtc-fans/ for the rest, there is Google. Most of these are defined by the IETF (http://ietf.org/)

Edit 2: Firefox and Chrome (and the spec) have moved to using "trickle" for ICE candidates, so the ICE candidates are generally added after-the-face to the PeerConnection and exchanged independently of the initial SDP (though you can wait until the initial candidates are ready before sending an offer, and bundle them together). See https://webrtcglossary.com/trickle-ice/ and https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/