I want to create something similar like chat roulette:
There are two peers. Both peers send an SDP offer to the signaling server asking it to get connected with someone. The signaling server uses the offer of peer A to send it as an answer to peer B and vice versa.
Both peers could setLocalDescription() and setRemoteDescription() without using createAnswer().
Could they now go to the next step and exchange candidates? Or is it necessary that at least one is sending a real answer created with createAnswer()?
No. An offer is not an answer. An answer builds on an offer, it's a refinement, an iteration on it, a negotiation.
The offer-answer exchange is inherently asymmetric, so your peers will be in incompatible states if they've both sent out offers.
Instead, solve discovery (pairing) of A and B first, then do WebRTC from A to B.
Related
I would like to send messages between two peers using WebRTC without a signaling server. I'm using QR codes to send over the connection descriptions, and I found an example implementing exactly this:
https://github.com/TomasHubelbauer/webrtc-qr-signaling-channel
However, it requires scanning the QR code both ways. I'm wondering if it's possible to only have to scan a QR code from the phone, but still establish a connection?
Conceptually, I'm thinking like this:
ClientA shows QR code, essentially saying "here's how to connect to me."
ClientB scans it, and now knows how to find ClientA.
ClientB sends "here's how to connect to me" to clientA.
They now both know how to find and talk to eachother.
However, this doesn't seem possible when looking through the WebRTC documentation. If this isn't possible to do - then why?
I strongly doubt it is possible.
During the offer/answer exchange, each of the peers generates a self-signed (D)TLS certificate and includes its cryptgraphic hash ("fingerprint") in the SDP. Without the answer's SDP, the offering peer would be unable to authentify the answering one.
You might be able to achieve the same user experience, however, by implementing a signalling server on one of the peers. The QR code would contain the URL of the signalling server together with authentication data, and once connected the two peers could perform a traditional offer/answer SDP, and even trickle ICE candidates.
it might seem like this question can be easily found in google, however all I can see are theoretical answers and not practical ones.
When an SDP offer or answer is created, my clients start releasing ICE Candidates, which I save into an array and send to the other client I want to connect with, and vise versa.
Now, both clients have access to their own ICE Candidates, and the ICE Candidates of the client they want to connect with. But how do I choose the best one, and if not so, how can I try all of them and see which one works?
Thank you.
You shouldn't keep ICE candidates in array, but send each candidate immediately. WebRTC has own logic to select the best pair of candidates depending on various factors, like network cost (for example, WiFi candidate is more preferable than LTE).
I'm building a video calling app using WebRTC which allows one peer to call another by selecting someone in the lobby. When peer A sends a call request, the other peer B can accept. At this point, WebRTC signaling starts:
Both peers get their local media using MediaDevices.getUserMedia()
Both peers create an RTCPeerConnection and attach event listeners
Both peers calls RTCPeerConnection.addTrack() to add their local media
One peer A (the impolite user) creates an offer, calls RTCPeerConnection.setLocalDescription() to set that offer as the local description, and sends it to the WebSocket server, which forwards it to the other peer B.
The other peer B receives this offer and adds calls RTCPeerConnection.setRemoteDescription() to record it as the remote description
The other peer B then creates an answer and transmits it again to the first peer A.
(Steps based on https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity)
This flow is almost working well. In 1 out of 10 calls, I receive no video/audio from one of the peers (while both peers have working local video). In such a case, I have noticed that the answer SDP contains a=recvonly while this should be a=sendrecv under normal circumstances.
I have further determined that by the time the other peer receives the offer and needs to reply with an answer, the localMedia of this side has sometimes not yet been added, because MediaDevices.getUserMedia can take a while to complete. I have also confirmed this order of operations by logging and observing that the offer sometimes arrives before local tracks were added.
I'm assuming that I shouldn't send an answer before the local media has been added?
I'm thinking of two ways to fix this, but I am not sure which option is best, if any:
Create the RTCPeerConnection only after MediaDevices.getUserMedia() completes. In the meantime, when receiving an offer, there is no peer connection yet, so we save offers in a buffer to process them later once the RTCPeerConnection is created.
When receiving an offer, and there are no localMedia tracks yet, hold off on creating the answer until the localMedia tracks have been added.
I am having difficulties to decide which solution (or another) matches best with the "Perfect Negotiation" pattern.
Thanks in advance!
Yes, it is good to add the stream before creating an offer if you do it 'statically', but the best way to do it is to do it in the onnegotiationneeded event because the addtrack event triggers an onnegotiationneeded event. So you should add the stream and then use the createoffer inside onnegotiationneeded. As far as the answer you can do it before with no issues, but remember that a well-established connection will let you add/remove tracks with no problems (even after the SDP has been set). You didn't post any code but remember that you also MUST exchange ice candidates.
The last piece of advice, remember that all of the above IS asynchronous! so you should use promises, and await until the description is set, only THEN create an offer/answer.
Hopefully, this will help
In a Webrtc call, I am using sip signalling and sdp for media parameter negotiation.
Before call start, I do a stun-bind transaction and get reflexive candidates. I have put those reflexive candidates in sdp in addition to base and host candidates.
As soon as we get 200 OK for Invite, we need to start media. For media start, I need to know which candidate pair I need to use.
I hope to determine which candidate pair I need to use, we need to do connectivity check. I am not sure how to do connectivity check (like which message to send.. etc).
Can somebody help me in this to understand.
Also is there an open source (c, linux based), that gives ice/stun/turn support.
This information is given on RFC 5245. You need to read this RFC for implementing ICE. For your query about doing ICE connectivity check, read this section of the RFC.
Also is there an open source (c, linux based), that gives
ice/stun/turn support.
Search google for this and you will get your answer.
Related WebRTC, ICE protocol gives the which pair of addresses will work for direct media transfer between the pairs.
Let A and B are two endpoints
To choose which address will work for direct communication between A and B, Person A first gather candidates, encode candidate attribute, encode the SDP offer message, and send it to another endpoint.
When B get offer message from A,then person B gather candidates, encode the SDP answer message with its own list of candidates and send it to person A.
At this end of this process, each agent has a complete list of local candidates and Remote candidates. Its pairs them up, resulting in CANDIDATE PAIRS. To see, which pair work, each agent performs the connectivity checks using STUN req/resp.
How many connectivity checks are performed, to nominate valid candidate pair?
What are the remaining ICE connectivity checks are performed regarding webRTC call?
To develop ICE module for webRTC call, I have to follow each step in RFC5245 or any thing else?
How many connectivity checks are performed, to nominate valid
candidate pair?
The number of candidate pairs are the number of connectivity checks done by each side.
What are the remaining ICE connectivity checks are performed regarding
webRTC call?
There are no extra ICE connectivity checks for webRTC.
To develop ICE module for webRTC call, I have to follow each step in
RFC5245 or any thing else?
You have to implement or use existing implementation of DTLS protocol, RFC5763 and RFC5764. DTLS implementation can be found on OpenSSL library.
All these seems a lot of work but if you use openssl then its easy enough.