General API Usage

[ajsuydam]

Hey there!

Thanks for writing this library, it looks to be very helpful for my use case. I'm new to all of this, but I wanted to make sure that I understood how to use your library correctly. I want to stream from a libdatachannel endpoint to my browser, so I went and looked at the streamer example, but I had trouble following the code fully. Generally, I understand the WebRTC protocol working as follows:

Both ends create a PeerConnection
Both pc's create local session descriptions.
These session descriptions are exchanged via a signaling method of your choice (http, socket.io, websockets, etc)

After this however, I get confused. Does creating a local session description automatically begin the ICE candidate discovery in your implementation? Do I need to have my signaling server help peers exchange candidates?

If this is a dumb question I apologize, but I would appreciate any clarification you could offer! I looked at #857, but I didn't feel that it answered my question.

[paullouisageneau]

You should look at the media-sender example as it is way simpler.

Both ends create a PeerConnection
Both pc's create local session descriptions.
These session descriptions are exchanged via a signaling method of your choice (http, socket.io, websockets, etc)

That's right but the signaling process involves an offer and an answer, so the offering peer creates a connection, adds data channels and/or tracks, generates a local offer description, sends it to the remote peer. The remote peer creates a connection, sets the offer as remote description, generates a local answer description and sends it. Finally the offering peer sets the answer as remote description.

After this however, I get confused. Does creating a local session description automatically begin the ICE candidate discovery in your implementation?

Yes it does.

Do I need to have my signaling server help peers exchange candidates?

It's your choice, either you wait for GatheringState to be Complete to send the local description with candidates, or you send the local description when the onLocalDescription callback is called, then the candidates one by one as they arrive in the onLocalCandidate callback. The second way allows peers to connect faster.

[ajsuydam]

Sweet! I took a look at the sender example you suggested, you're absolutely right, it is way simpler. I implemented a signalling mechanism to automatically exchange the sdp's because I want to avoid my users having to do that. when the sender application receives the remote description (it has already sent over it's description, it is receiving the answer from the browser) it complains with the following error:

[rtc::impl::Channel::flushPendingMessages@76] Uncaught exception in callback: Remote description has no ICE user fragment

I was wondering if you could shed some light on what might be causing this error. I am just streaming locally, from the sender app running on my computer to a browser open on the same system. I made sure to exchange both the sdp string and the type, just as the stock example code does.

[paullouisageneau]

The error means that the remote description is invalid, more specifically it lacks the mandatory a=ice-ufrag line. The description is possibly truncated, or you inverted description and type at some point.