What is the difference between WebRTC offer and answer?

Viewed 1171

I am trying to add audio/video chat feature using WebRTC to existing text chat app. Chat room participants already are chatting, but when they decide they need audio/video, they press a button to start audio/video. Whichever client presses a button, I am calling myPeerConnection.createOffer().then(function(offer){setLocalDescription(offer)} and then sending the offer (JSON.stringified) to the server along with clientID. After X seconds, I disable the button to join the audio/video chat, send a notice to the server to distribute all the offers to the participants. At this point, all the clients willing to join audio/video chat have entire set of SDPs from all the remaining peers.

My question is, do I need to send answers to each offer from each client? My understanding is that SDP describes capabilities of the client to handle audio/video. Can I use the offer SDPs from others to setRemoteDescription(SDP)? All the examples, tutorials, questions, and posts I came across are using the paradigm of offer/answer and none of them are talking about what the difference between offer and answer is. Any information or pointers are appreciated.

Here is a jsFiddle code segment simplified from my code. Please take a look at the console output, which shows nothing other than media capabilities. All the ICE and networking information which might distinguish SDPs comes after exchanging this offer SDP and the answer, so that is not yet part of this offer (and answer) exchange done through signaling channel.

PS: Strictly speaking, my scenario does not have any initiator or sender that is starting the channel. All participants are equal. No way to determine or sequence them either. When capabilities and network info are exchanged properly, they start audio/video chat.

1 Answers

The SDP contains some elements which are the same for all participants -- like the supported codecs. There are other elements (or rather lines) which are specific to the peerconnection instance. The ice candidates (ip/port) and ice-ufrag/ice-pwd in particular. These can not be shared across peerconnection.

(partly that is an implementation detail; see the webrtc forking group interim meeting slides/recording on ice-forking)

Related