Copy and Paste troubles about datachannel-wasm HOT 5 CLOSED

I think the issue comes from the way you handle candidates: each side outputs one description but multiple candidates. It seems your code will override each candidate by the next in the candidate box and as a result only display the last one.

There is a semantic subtlety in the API: the methods are called setRemoteDescription (as there is only one so it will replace the remote description) and addRemoteCandidate (as it will add one more candidate to the list, not replace existing candidates).

This seems to be because the ICE candidates are already enumerated in the localdescription SDP. When I call WEBRTC.peerConnection[1].localDescription.sdp from the console I also get this version of the answer. However, I am unable to obtain the same localdescription using this library. Is there a way this is easily achieved?

This can be done. You just need to wait for GatheringState to be Complete, then you can retrieve the local description with all candidates by calling pc->localDescription(). This method, called non-trickle ICE, allows for an simpler signaling as it does not require exchanging candidates, only the descriptions, but it could introduce delays if a STUN/TURN server is unreachable.

from datachannel-wasm.

Indeed by appending the candidates to the textbox I was able to set up a working datachannel.

I also now check the GatheringState if it is complete after which the description is automatically put in the textbox.

pc->onGatheringStateChange([](rtc::PeerConnection::GatheringState state) {
std::cout << "[Gathering State: " << toString(state) << "]" << std::endl;

if(state == rtc::PeerConnection::GatheringState::Complete) {
	std::optional<rtc::Description> desc = pc->localDescription();
	if(desc.has_value()) {
		putDescriptionInOfferBox(rtc::string(desc.value()).c_str());
	}
}
});

from datachannel-wasm.

Did you publish the working example?

from datachannel-wasm.

@paullouisageneau could you explain that into a little more detail?

The original issue was that only the last candidate was displayed in the candidate textbox, other candidates were dropped. This is unrelated to what you experience here as your example is not copy paste, and you don't trickle candidates, you wait for gathering complete to send descriptions with candidates.

I tried to make a similar connection establishment based on your copy-paste example, with the only difference that I use a WebSocket server and no copy/paste. My connection works on Firefox, but not on Chrome (same issue as above).

My code in a simplified version: [...]

The code has a bunch of issues but I don't know if it's because it's "simplified" or not: pc is a local object so it will be destroyed as soon as you leave the init_peer_connection() function, the type is not sent over the websocket but it is received it somehow, anser is written instead of anwser, a callback is set on dc instead of _dc...

You have to debug your code and check you transmit the descriptions back and forth correctly. Note it is not good practice to assume and hardcode description type, instead you should get it from description.typeString() and transmit it.

from datachannel-wasm.

These issues are just because of trying to simplify the code. So I guess you can't see an obvious mistake in the way i handle candidates, ... etc.
Thank you for your input and response.

from datachannel-wasm.