Answering the response is just as easy as offer
. We follow a similar pattern and let the clients do most of the work. Our server will simply let any message pass through as answer
to the other user. We can add this in after the offer
handling case:
case ""answer"": console.log(""Sending answer to"", data.name); var conn = users[data.name]; if (conn != null) { connection.otherName = data.name; sendTo(conn, { type: ""answer"", answer: data.answer }); } break;
You can see how similar the code looks in the preceding listing. Note, we are also relying on answer
to come from the other user. If a user were to send answer
first, instead of offer
, it could potentially mess up our server implementation. There are many use cases where this server will not be sufficient enough, but it will work well for integration during the next chapter.
This should be a good start to the offer
and answer
mechanism in WebRTC. You should see that it follows the createOffer
and createAnswer
functions on RTCPeerConnection
. This is exactly where we will start plugging in our server connection to handle remote clients.
We can even test our current implementation using the WebSocket client we used before. Connecting two clients at the same time allows us to send offer
and response between the two. This should give you more insight into how this will work in the end. You can see the results from running two clients simultaneously in the terminal window, as shown in the following screenshot:
In my case, my offer
and answer
were simple string messages. If you recall from Chapter 3, Creating a Basic WebRTC Application, in The WebRTC API section, we detailed the Session Description Protocol (SDP). This is what the offer
and answer
strings will actually be filled with when making a WebRTC call. If you do not remember what the SDP is, refer to the Session Description Protocol subsection under The WebRTC API section in Chapter 3, Creating a Basic WebRTC Application, and refresh your memory.
3.146.152.99