I am developing a conference application using WebRTC and I have one issue which is pretty strange. More exactly, as the title says, onicecandidate doesn't gather all the needed candidates, or more exactly gathers only the null one, then the gathering state becomes completed. This happens only for the remote peer and depending on the PC I use in either Chrome or Edge (Chromium), on one PC working in Chrome well but not on Edge and in another working on Edge well but on in Chrome.
The icecandidates of the peer who creates the offer are gathered correctly, they are sent and the remote peer is setting them, only the remote peer never gathers any, except for a null one.
I configured the rtcpeerconnection to use a stun server from google (I am running on localhost for now) but nothing changed. Are there any special steps I must take to make everything work well in both browsers?
EDIT: I noticed this problem because the track that is sent by ontrack function to the remote peers isn't playing, the video.play() promise in the remote peer only staying forever in pending, neither continuing further nor crashing. The difference that I noticed between the browsers in which it works and the ones it doesn't is the lack of ICE candidates sent by remote, in places where all were sent the video playing remotely also.
Do you happen to set remote description before create answer?
As you know, exchanging sdp is 'negotiation'.
So when remote peer creates own answer sdp, remote peer have to set other peer's sdp.
Like this:
1) Peer A - Create Offer (offer sdp)
2) Peer A - Set Local Description (offer sdp)
3) Peer B - Set Remote Description (offer sdp)
4) Peer B - Create Answer (answer sdp)
5) Peer B - Set Local Description (answer sdp)
6) Peer A - Set Remote Description (answer sdp)
Related
I am using this example https://github.com/libp2p/js-libp2p/tree/master/examples/libp2p-in-the-browser and try to connect to a nodejs peer through the given hosted rendezserver ‘/dns4/wrtc-star2.sjc.dwebops.pub/tcp/443/wss/p2p-webrtc-star’ . The peer get found but the connection is not established. If i run the nodejs peer in the same machine as the browser peer they get connected but if the nodejs peer is on a different machine/network the peers find each other but they don’t get connected. Is this normal ?
Yes that's totally normal. WebRTC will only work if you can get through the NAT. IPv6 really helps with NAT traversal too, but it can be trickier with IPv4. So it will work over more than locally, but each peer must be able to directly reach each-other.
https://docs.ipfs.io/how-to/create-simple-chat-app/
We can use WebRTC-Star nodes to help discover other peers we can connect with directly browser-to-browser. If you're familiar with the concept of STUN, it might be helpful to think of them as conceptually similar. Effectively, each connecting node will be given a WebRTC-Star multiaddress that other nodes can use to discover and connect to your browser directly. This means that if you peer with someone using the star node, and the star node goes offline, you remain connected!
[...]
Tip
This is a very clean and effective method of P2P communications; however, sometimes NATs get in the way. We use p2p-circuit to get around that.
When creating webrtc peer connection, I passed in a list of STUN/TURN ICE servers (no trickling ICE). But when establishing the connection I only saw local ip address in ice candidates in the offer created. The same for the answer received. The connection worked sometimes. Was that expected? Where I could check if that was wrong?
It turned out that TURN server urls do exist in the sdp offer and answer. The issue in my case was I added the ICE servers after peer connection creation so it didn't add to the offer.
No, the STUN/TURN ICE urls will not be present offer/answer SDP.
These servers are meant to be used by a peer connection to generate ICE candidates. The peer you would like to connect to has nothing to do with how you gather your candidates, therefore it does not care about your stun/turn configurations. It only cares about your actual ice candidates and the metadata of the media you're about to send.
If you are interested enough, I recommend you take a look at WebRTC for the curious, it covers this topic in detail yet it is quite comprehensible.
Well I am studying about Web-RTC from its official documentation. I need to integrate live streaming in my website but after seeing this and studying about all its documentation. I only learn about streaming on locally like on same browser and same page. But this is not what i want. I want to start stream from my admin panel(This part has been completed) and broadcast that stream whoever has access to my website whatever the website is and whatever device. Whoever open my website if i m streaming then he should see that and if some of u have worked on live streaming then u should tell me. It will be a great help for me. All i did until now is to make a connection between two peers on same page. Now i want to make global peer to peer connection
I have done this implementation using simple-peer. Basically a wrapper for webRTC.
As soon as a new user connects a new webrtc connection should be made between the receiver and the caller. The receiver is firstly initialized and then sends a message to the sender to start the connection. This first connection is all done by your own server you should write.
Here is a working example. And here is the demo. Any connected devices will be automatically connected to the call. Multiple users supported. You'll find all the webrtc code in /public/js/main.js
You have to do signaling which mean that you have to exchange the PEER CONNECTIONS over the server and which required you to build a server page and client page so both of you can exchange the peer connection.
here is the complete procedure of exchanging the peer connection over the server.
find the heading
RTCPeerConnection plus servers
https://www.html5rocks.com/en/tutorials/webrtc/basics/
While troubleshooting my web app, I found draft-mdns-ice-candidates, which is about obfuscating addresses in host candidates by using mDNS.
And I found that when the two peer (agent L, agent R) is in a topology as in the Figure 7 below, the WebRTC peer connection fails because the host address of agent R is obfuscated and the srflx address of agent R is discarded since agent R is not behind a NAT. The relevant expressions in rfc8445 about discarding the srflx address of agent R are below.
5.1.3. Eliminating Redundant Candidates
Next, the ICE agents (initiating and responding) eliminate redundant
candidates. Two candidates can have the same transport address yet
different bases, and these would not be considered redundant.
Frequently, a server-reflexive candidate and a host candidate will be
redundant when the agent is not behind a NAT. A candidate is
redundant if and only if its transport address and base equal those
of another candidate. The agent SHOULD eliminate the redundant
candidate with the lower priority. - section 5.1.3 of rfc8445
(Figure 7 is from section 15.1 of rfc8445)
And in section 5 of draft-mdns-ice-candidates, I found no explanation about the case of Figure 7. When I tested the recent version of Chrome, Firefox, and Safari, the WebRTC peer connection failed in all of the browsers in the case of Figure 7, because of the reason I wrote above — the host address of agent R was obfuscated and the srflx address of agent R was discarded.
When turning off obfuscating local addresses by changing the browser setting (the obfuscating is done by default), the WebRTC peer connection is successfully established. (I tested this successful connection on Chrome, and FireFox. In Chrome, by disabling Anonymize local IPs exposed by WebRTC in "about:flags" page. In Firefox, by setting false media.peerconnection.ice.obfuscate_host_addresses in "about:config" page.)
Is this a problem of the IETF’s WebRTC spec? (Maybe a collision between draft-mdns-ice-candidates and rfc8445?) Or a problem of the implementations of the modern browsers? Is there a way to establish WebRTC peer connection in the case of Figure 7 without turning off the obfuscating host address? I want to know.
Good news!
This bug in implementation was fixed by a patch in upstream WebRTC repo (it's my contribution!):
https://webrtc.googlesource.com/src/+/7eea6672285f765599fd883a5737f5cae8d20917
The upstream WebRTC code with the patch applied begins to be included on Chromium with version 110.0.5452.0. Thus all Chromium browsers (including Chrome) at or above the version 110.0.5452.0 are supposed to be applied the patch.
Since the patch was committed on upstream WebRTC repo, we can also expect that other browsers (like Firefox or Safari) apply the patch sooner or later.
UPDATE:
The upstream patch was cherry-picked in Webkit.
It turned out that, for Firefox, a separate patch for itself was needed. (This patch also is my contribution.) Firefox uses a different library, other than from upstream WebRTC, for its ICE stack. So applying the patch in upstream did not work for Firefox. (Regarding this, it seems interesting Firefox had the same bug too.)
From draft-ietf-mmusic-mdns-ice-candidates-02, Section 3.1.2.2:
Regardless of the result, a server-reflexive candidate will be generated; the transport address of this candidate is an IP address and therefore distinct from the hostname transport address of the associated mDNS candidate, and as such MUST NOT be considered redundant per the guidance in [RFC8445], Section 5.1.3. To avoid accidental IP address disclosure, this server-reflexive candidate MUST have its raddr field set to "0.0.0.0"/"::" and its rport field set to "9", as discussed in [ICESDP], Section 9.1.
Omitting a SRFLX candidate because its server-reflexive IP address matches an IP address used to produce a local obfuscated candidate appears to be explicitly nonconforming.
I was read the turnserver rfc-5766. In this the figure 1 the following are the things are gets take placed.
Turn server
Turn client
Peer A
Peer B
My understanding is the peer A and peer B are used for the webrtc clients who wants to communicate each other behind a symmetric NAT. They uses the turn server to communicate.
But I don't know what is the use of turn client in here. Then I did not understand what is the use of send indication and data indication. They said the data is transfered using the allocated relayed address. But that address is not yet used. But the the data transferring is gets successful. I don't know how it gets succeed. Please explain me the flow of the coturn 4.5.0.3 turn server.