Reputation: 389
The signalling mechanism which we have implemented requires to send the icecandidates in the sdp itself.
Do you have any idea how to embed icecandidates in sdp?
Also, if the icecandidates are embedded in sdp then how the PeerConnection will initiate p-2-p connection?
Or does the PeerConnection can initiate p2p connection just after setting the remote sdp or something else has to be done?
Also, can you suggest something on how we can use webrtc for video communication between 2 devices in the same wifi network (without the use of STUN/TURN)?
I tried setting the iceservers to null but then the app doesn't works!
I have collected the generated sdp for both the devices from logs.
I have the ice candidates generated for both peer. I combined the sdp and icecandidates into a single sdp. With this, I have set the iceservers to RTCConfiguration as NULL. But now the app doesn't works!
What I wanna know is that if we have a SDP embedded with icecandidates, how can we initiate the p2p connection? Is the p2p connection initiated when Remote IceCandidate are set or the RemoteDescription is set?
Thanks!
Upvotes: 2
Views: 2305
Reputation: 21360
The ICE candidates are included in the SDP offer/answer. So just wait until the ICE gathering process is complete and then send the SDP offer/answer.
I'm not sure if you can use WebRTC without a STUN/TURN server, but you can use yours or a public one. It seems that on the local environment, everything works fine without a STUN/TURN server - just pass an empty array to iceServers
.
And for the last question - it depends. If TrickleICE is implemented (and in Chrome and Firefox is) the connection is initiated when the first good ICE candidate is found. And you can set the description before that. Otherwise, you need to wait until the ICE gathering process is complete and then send offer/answer and set it on the other peer as remote description. Then the connection will be initiated.
Upvotes: 4
Reputation: 636
I couldn't fit this in a comment so I'm going to post it as an answer.
We run local WebRTC test fairly often with no STUN/TURN servers configured and it works fine. It will just limit your ability to connect via NAT'd firewalls. Can't promise it will connect in your environment but it shouldn't crash. Have yet to try it with Android so no comment there.
As for disabling Trickle ICE, we've run into a few problems with that (mainly on Chrome). You basically have to wait until you receive a NULL ICE candidate before sending the OFFER or ANSWER. This is how the WebRTC engine tells the application the ICE collection process has completed. When we configure to use the google STUN/TURN servers there is a long delay (> 10 sec) between when the last viable candidate event occurs and the NULL candidate event occurs. I've also seen cases where the NULL candidate event is never received and the call just times out.
Our plan is to add a timer to break out of the ICE collection process after a few seconds when Trickle ICE is disabled. I haven't tried it yet but I see no reason why this wont work and should be much more useable. From my experience, all the candidates are collected within the first second or two.
Upvotes: 1