I have successfully connected clients A and B. Problem is I want to add new clients, C and D to build a group chat.
Do I need to spawn new RTC connection and exchange offer/answer/ICE candidates for each clients? For example:
A connects to B
A connects to C
A connects to D
B connects to C
B connects to D
C connects to D
Each of the above client combination spawns their own RTCPeerConnection and goes through the webrtc handshake (offer,icecandidate,answer)
Do I need to spawn new RTC connection and exchange offer/answer/ICE candidates for each clients?
Exactly. Each client just need to create new RTCPeerConnection, attach their unique audio and video tracks to them and exchange their SDP & ICE candidates every time a new client arrives.
An example is available here: https://webrtc.github.io/samples/src/content/peerconnection/multiple/
Source code: https://github.com/webrtc/samples/blob/gh-pages/src/content/peerconnection/multiple/js/main.js
Related
Suppose there are 2 users
user 1: 10 Ice candidates generated
user 2: 5 Ice candidates generated
And I know only 1 candidate is required to establish a connection. So any of the above user sends candidates to other user and the connection gets established.
My question is they should exchange all candidates, In order to agree on best connection route ?
If they exchange all candidates , all I have to do is feed all Ice candidates to my peerConnection as shown in dart code below, Am I right ?
RTCPeerConnection _peerConnection;
await _peerConnection.addCandidate(candidate);
You should exchange all the candidates and feed any candidates from the local onicecandidate event into the remote's addIceCandidate call.
ICE will figure out the best pair to use (by trying each and using what works)
If a client A, wants to connect to 2 other end points B and C. How does A initiates call with B and C using SFU. I mean, how will A communicate to SFU that it needs to connect to B and C? How is ICE working working in this setup?
Clients typically interact with SFUs in a publish/subscribe manner, so the signaling doesn't happen directly between them.
The workflow is usually as follows: client A publishes a stream to the SFU, then other clients, like B and C, may subscribe to A's feed. In either case (publishing or subscribing), the signaling is happening between the client and the SFU WebRTC agent. And, of course, since the client signals with the SFU, ICE candidates are exchanged with the SFU, not between themselves.
I am working on setting up group calls involving up to 8 peers using WebRTC.
Let's say a peer needs to set up 7 RTCPeerConnections to join a group call. Instead of relying on onicecandidate event for every single RTCPeerConnection, I was wondering if I can track the client's icecandidates in a central location and reuse it for each new RTCPeerConnection. (e.g. Signaling Server will keep track of a peer's full ICE candidates, and share them with other peers as soon as they need them).
I am unsure what the average number of 'icecandidates' each client will have, but with ice trickle process, it seems that many duplicate http or websocket calls will need to be made to a Signaling Server in oder to exchange ice candidates between any 2 peers.
So I was wondering if I could just "accumulate" ice candidates locally and reuse them when new RTCPeerConnection will need to be made with new peer.
You can not. ICE candidates are associated with the peerconnection and its ice username fragment and password.
There is a feature called ice forking that would allow what you ask for but it is not implemented yet. https://bugs.chromium.org/p/webrtc/issues/detail?id=11252#c3 has some details.
Let's say I have an application that has a list of live streamers who are currently broadcasting via WebRTC. In order for a device to plug into a particular broadcaster, they need to send their SDP to the specific broadcaster that they click on.
So I gather my local SDP information, and send that to the Signaling server to be transferred to the broadcaster and await the answer.
My question is, how does the signaling server know which broadcaster to send this SDP to? And where do you store this identifier?
My first thought was use the ip address as the unique identifier but that can change as I move around and change connections.
And is it normal to store this identifier on the web socket itself as a property? I don't know how else you would know which web socket to send along the SDP?
Sorry if this is a n00b question, very new to WebRTC.
I also faced same situation like you.
In my case, I used Socket.IO for bidirectional communication.
So what I did is using member's id and socket.io's room.
When socket.io client connected to server, this client joined specific room automatically.
That room's name is client's socket ID. You can check this doc.
For example, your service is broadcasting. right?
And maybe broadcasters in your service have unique id (in Database).
So when client is connected to server, escape from default room immediately, and join new room that name is client's unique id.
Then, now you can send some messages like sdp to specific client with client's unique id.
To establish WebRTC connections the ICE protocol is used with a signaling server which must send messages in both directions. I wonder why after the initiator sent its offer and candidates to the other participant, the participant needed to send back its answer and candidates using the signaling channel in the other direction. Cannot the participant open the connection to the initiator using candidates from both sides and send back its answer using the open connection?
I started reading ICE RFC and the only relevant part I found is in section 5.2 where the initiator must take the controlling role and nominates candidate pairs. But it does not explain why the other could not initiate connection.
To give some background, I am trying to build a webapp for which I want users to establish WebRTC connections without using a signaling server. I thought of having the app to generate a URL including the offer and candidates and providing this URL to other participants through other medium like instant messaging. The issue I got is that the participant need to send back its answer and candidates using the same medium, which is not practical. In the end I will go for a signalling server but I wonder the technical reason.
Yes, you can do that if caller is behind public IP or Full Cone NAT(in this case, router connection mapping needs not to be timed out).
You can able full fill above conditions rarely.
What's the problem with other NAT types?
For example , PRC(port restricted cone) NAT won't allow you to receive a packet from a IP:Port , if you didn't send any packet to that IP:Port before. So callee will never able to send you a packet.
So if callee sends her candidates list to you . you can send some dummy data(with low TTL) to her IP:Port to fool your PRC NAT (now it allow incoming packets from callee's IP:Port as it sends a packet to that IP:Port before).
To know more about different types of NAT:
https://en.wikipedia.org/wiki/Network_address_translation
http://think-like-a-computer.com/2011/09/16/types-of-nat/