How to make use of IceConnectionState and IceGatheringState while sending the icecandiates to the peer in webrtc ?
ice gathering is the generation of the local candidates you will send to the remote peer either in the offer sdp (full ICE) or separately (trickle ICE).
ice gathering state is the state of the connection with the remote peer based on your trying of the remote candidates received through your chosen signaling method.
The ice gathering state is not so important, as the application logic does not care usually about those (the application might monitor the candidates and know if the gathering is done when a null candidate surfaces), the ice connection states are VERY important to know if a connection was established and your application should focus on that. The peer connection state can be stable, and all the handshake done, without media flowing if the ICE connection state is failed.
Related
What I wish to achieve:
When establish a connection, prevent user from sending any message until the connection had finished all the setup (with STUN/TURN server etc)
When there is a sudden disconnect, prevent the user from sending any message until the connection is re-established.
My best guess is either one of the event handler below will do the trick, but I don't know which one, and don't know what are the differences between the two.
onconnectionstatechange()
oniceconnectionstatechange()
oniceconnectionstatechange doesn't include the establishment of the DTLS handshake on top of the ice connection.
Use onconnectionstatechange to detect when the connection is fully established and also to detect disconnections.
If a client is behind NAT, when does STUN/TURN come into play?
1. After Peer connection object is created?
2. After setting local SDPs and sending it to the other client?
3. Before sending ice candidates?
(2) -- setting the local description causes the ice process to kick off and that process includes gathering srflx candidates from the stun server and relay candidates from the turn server.
It is possible to kick this off at the peerconnection creation -- see iceCandidatePoolsize in the specification.
This sample page illustrates the process.
I have started to look into WebRTC a bit and I am using it to build a simple peer to peer chat application using the data channel. I have the following questions:
Do I need to establish a RTCPeerConnection to each peer I want to talk to? So if there are three peers they each need 2 RTCPeerConnections (unless I use one of the peers as a sort of ad-hoc server).
If peer A sends out a candidate and sdp when creating a offer to peer B. Can peer B connect to peer A using that info and send its answer (with candidate and its sdp) over the RTCPeerConnection, i.e. using the RTCPeerConnection (before it's been completely established) as a signaling channel? I would assume that when the offer is created by peer A it starts to listen for connections on some port.
My understanding of WebRTC is a bit limited so if I've missunderstood some concept of WebRTC in my questions above please point them out!
Yes, as a direct P2P protocol everybody must be directly connected to everybody else if they want to communicate; unless you create some kind of mesh network in which one peer forwards messages to other peers.
No, the SDP offer and answer and ICE candidates all need to be exchanged through a signalling server; the connection cannot be established until both peers have actually agreed on a specific session configuration and ICE route to use, so you cannot send the SDP answer over a connection which isn't complete yet.
Especially for a simple text-only chat, going through a server is often easier than using P2P; the processing and bandwidth requirements are so minimal that the complications of P2P connections are probably not worth it. And you need a signalling server anyway. P2P only becomes really interesting once you start sending large files or audio/video streams.
In principle it is possible to establish a WebRTC connection without a signalling server, but that requires an out of band exchange of session tokens between the peers. I.e. the user would have to copy a token from the application, somehow send it to another user and the other user would have to paste it.
Additionally those tokens cannot be reused, so this procedure would have to be repeated every time peers want to establish a connection.
So while theoretically possible webrtc is not distributed in practical terms.
There is some noise about specifying support for incoming connections and reusable peer contacts, but the progress on that is unclear.
What are the possible reasons of ICE failure ?
I am particularly interested in the case of failure- when all remote candidates are added( with relay candidates ), remote offer/answer SDP set.
One of the reasons of P2P connection failure between two peers is that peer failed in gathering the suitable ice candidates and this is what we called "ICE failure"
So if you mean by ICE failure that the client application not able to get the suitable ice candidates from the ice server so that could happen for many reasons. For Example:
ICE server down
P2P connections blocked by Firewall
Symmetric NAT which does not reuse session address binding. This results some NAT Traversal techniques failing in traverse packets through NAT devices
I'm converting an application over from GameKit to Multipeer Connectivity and can't seem to find a method that would allow the browser device to disconnect another peer from the session . With GKSession, we could disconnect a single peer from the session using disconnectPeerFromAllPeers:, but I can't find anything like that in MPC. Of course, MPC does have the disconnect: method, but that takes the local peer out of the session..not what I want.
The closest I've found is:cancelConnectPeer: but that seems more focused on canceling a connecting attempt...not post connection.
Anyone know how to do this of if it is even possible with MPC?
Thanks!
A peer can leave a session by calling [MCSession disconnect].
If you want the browser to disconnect another peer, you could make the browser send a message to that peer, and make the peer disconnect from the session upon receiving that message.
I am working on MPC too, but find annoying by API too. Therefore I move the logics, such as disconnecting a specific peer, up to app logic level, from physical connection level. E.g. Session/connection is always on, and just do soft-disconnection by not sending any message to specific peer.
Bluetooth does not perform stably as we all experienced in GKSession. With MPC, we most time used Wifi, therefore connection stability and cost does not matter so much.