Comments on: Asking Google: WebRTC is …

By: Aswath Rao

Aswath Rao — Mon, 25 Mar 2019 16:00:34 +0000

First of all, it is important to note that WebRTC can handle only incoming sessions. In other words, in your scenario A can not be notified of an offer. Only B can initiate a session and the app notifies A. The app can do this because the app has a persistent connection to A via Websocket or some such a mechanism. In SIP world this is called rendezvous service.

B initiates a session by clicking on a “call URL” that A has otherwise shared with B. This action connects B to the app server, which could establish a Websocket (or an equivalent) connection to B. The app server can use these connections and broker exchange of SDP Offer/Answer between B and A.

Finally, the app server can also broker exchange of other control messages related to the session, like the far end has placed mic on mute or far end has ended the session. I hope this clarifies.

By: Tsahi Levent-Levi

Tsahi Levent-Levi — Mon, 28 Jan 2019 21:59:47 +0000

In reply to Roudy.

Roudy,

WebRTC is definitely confusing.

The point you are missing is that there’s no signaling in WebRTC, so your question is irrelevant to WebRTC. It is up to you to answer this question. WebRTC starts when both users can send the SDP messages to each other *somehow*. That somehow can be an email, a push notification, a message in an app or on a web page you are on, etc.

If we were to meet, I’d probably send you a calendar invite with a link for example.

By: Roudy

Roudy — Mon, 28 Jan 2019 21:36:52 +0000

WebRTC is… still just a little confusing…Tsahi, i’m reading the book recommended by Loreto & Romano but the examples are outdated. With regards to the SDP signal – if peer A is on a webRTC application, but peer B is surfing youtube – How does peer B get notified of an offer? It would have to go to peer B’s email address right? — because there is no way of knowing peer B’s IP address. Please help.