Don't know if this example is correct
The process, call new RTCPeerConnection() then createOffer() then setLocalDescription()
Then I wait for onicecandidate take what it gives and first send the offer and second the icecandidates through the signal server to the other peer
Then the other peer takes the received offer into setRemoteDescription(offer) then the received icecandidates into addIceCandidate(icecandidates) then calls createAnswer() this gives an answer to put in setLocalDescription(answer) this triggers onicecandidate take these icecandidates with the answer=offer and send them back to the other peer
The other peer takes the answer into setRemoteDescription(answer) then the received icecandidates into addIceCandidate(icecandidates)
I think in this example the connection will work when testing inside local network but what if it doesn't because its not a local network, at what step in this example will the API call the STUN server and what other functions do I need to call if it does call the STUN server?
I've found that one way to generate BIND requests to be sent to the STUN server right away is to set the iceCandidatePoolSize option in the configuration to be > 0.
config = {iceServers: [{urls:stun:stunserver.stunprotocol.org}], iceCandidatePoolSize: 1};
peerConnection = new RTCPeerConnection(config); // pretty much starts to resolve the DNS name and sends BIND requests right away.
Hope this helps.
Also: this link is chock-full of great suggestions to troubleshoot webrtc connections.
You need to specify a STUN server in the peer connection's configuration. E.g.:
pc = new RTCPeerConnection({iceServers: [{urls: "stun:stun.1.google.com:19302"}]});
There are no other methods to call, provided it works on a LAN already. You should see additional calls to onicecandidate from this, compared to before. That's it.
Note that a couple of the things you describe happen in parallel, but in short, what triggers the browser to connect to the STUN server is setLocalDescription. It causes the browser's built-in ICE agent to kick off its candidate gathering process for this connection, and STUN is part of that.
Related
I have two peers that want to connect to each other via WebRTC. Typically the first peer would create an offer and send it to the second via a signalling channel/server, the second peer would respond with an answer. This scenario works fine.
However, is it possible to support the case where both peers happen to try to connect to each other simultaneously both sending SDP offers to one another concurrently via the signalling server.
// Both peers do this simultaneously:
const conn = new RTCPeerConnection(null);
const sdpOffer = await conn.createOffer();
await conn.setLocalDescription(sdpOffer);
signalingService.send(peerId, sdpOffer);
// At some point in the future both peers also receive an SDP offer
// (rather than answer) from the other peer whom they sent an offer to
// via the signaling service. If this was an answer we'd call
// RTCPeerConnection.setRemoteDescription, however this doesn't work for an
// offer:
conn.setRemoteDescription(peerSDPOffer);
// In Chrome results in "DOMException: Failed to execute 'setRemoteDescription' on 'RTCPeerConnection': Failed to set remote offer sdp: Called in wrong state: kHaveLocalOffer"
I even tried to "convert" the received peer offers into answers by rewriting the SDP type from offer to answer and setup:actpass to setup:active but that doesn't seem to work, instead I just get a new exception.
So the question is, is this simultaneous connect/offer use case supported in some fashion - or should I close one side/peer RTCPeerConnection & instantiate a new one using RTCPeerConnection.createAnswer this time?
This situation is known as "signaling glare". The WebRTC API does not really define how to handle this (except for something called "rollback" but it is not implemented in any browser yet and nobody has missed it so far) so you have to avoid this situation yourself.
Simply replacing the a=setup won't work since the underlying DTLS mechanism still needs the concept of a client and a server.
The answer for how to avoid glare these days is to use the Perfect Negotiation Pattern: https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Perfect_negotiation
However, what OP described does work with the slight modification of setting setup:active on one peer and setup:passive on the other:
https://codepen.io/evan-brass/pen/mdpgWGG?editors=0010
It might not work for audio / video connections (because those may require negotiating codecs), but I've tested it on Chrome / Firefox / Safari for DataChannel only connections.
You could choose which peer is active and which is passive using whatever system you use to determine 'politeness' in perfect negotiation. One possibility would be to compare the DTLS fingerprints and make whichever one is larger the active peer.
In WebRTC, there seems to be a very well-defined order in which things happen.
Locally I use getUserMedia to get my local stream, and save the stream to a variable. I create an RTCPeerConnection object, which I name pc, and I add the local stream to it. I add an onaddstream event handler to pc, so that I can save the remote user's stream to a variable, and eventually set it as the src attribute of an HTML element like audio. I also set onicecandidate event handler on my pc to handle ice candidates.
At this point, there is an RTCPeerConnection, but no remote user "connected yet". This is where the "offer/answer" starts. Let's say I'm using websockets for signaling and I receive an offer, which is a message called 'offer' and containing an SDP object. How do I reject it and how should this be dealt with on both endpoints?
For instance, I could send a message 'reject' that would be relayed to the other user. My RTCPeerConnection still exists, and maybe I want to be able to receive other calls. As is, I don't have to do anything to my RTCPeerConnection, correct? Does the other user, who sent the offer, have to do anything? Does he have to close that particular RTCPeerConnection? I would think not, since all he did was create an SDP object, and then outside of WebRTC, through websockets, sent the object over to the other user. He did add the offer using setLocalDescription though. When the offer is rejected, does he need to do anything about this?
When I create an offer, and send it to the other user, if I never get an answer back, can I just send an offer to a third user and then if he sends an answer I'm connected with him?
I haven't found anything about the lifecycle of an RTCPeerConnection.
Proper (spec) way to reject media
The "proper" way to "reject" offered media in an answer hasn't been implemented in any browser yet:
pc.ontrack = e => e.transceiver.stop();
Basically, the WebRTC 1.0 spec has changed quite significantly in this area. In short, a transceiver is an object combining one sender and one receiver, each sending or receiving a single track.
transceiver.stop() lets you reject a single bidirectional m-line (negotiated media) in the signaled SDP media description. E.g. you can reject parts of an offer in your answer, without rejecting the whole thing.
Today
Today, the only way to reject individual m-lines is through mangling the SDP offer/answer manually.
But it sounds like you're not actually asking about that at all. Instead, it sounds like you're asking how to bail out of incomplete signaling and roll a peer connection back to "stable" state.
Rollback to stable state
The offer/answer negotiation cycle is a state machine. The state is pc.signalingState:
You asked if one side walks away from the negotiation, does either side need to do anything before they can re-purpose their connection object for a new attempt with the same or different peer. Well, it depends.
If you've only called createOffer then no rollback of state is necessary, since createOffer is not in the above diagram.
If you've called setLocalDescription however, then you're now in "have-local-offer" state, which means you do need to somehow get back to "stable" state before you can reuse the connection.
Your options are to either finish the negotiation, delete the connection, or rollback to stable state (currently only supported in Firefox, though it is in the spec):
let pc = new RTCPeerConnection();
pc.onnegotiationneeded = async e => {
try {
await pc.setLocalDescription(await pc.createOffer());
console.log(pc.signalingState); // have-local-offer
await pc.setLocalDescription({type: "rollback"});
console.log(pc.signalingState); // stable
} catch(e) {
console.log(e);
}
}
pc.createDataChannel("dummy");
<script src="https://webrtc.github.io/adapter/adapter-latest.js"></script>
Of course, you should also let the peer know, usually through out-of-band signaling.
Why this is typically not a problem.
In typical cases, you own the JavaScript on both ends, so this doesn't come up. In other words, the desire to have a connection usually precedes one being made.
I've a client to server Websocket connection which should be there for 40 seconds or so. Ideally it should be forever open.
The client continually sends data to server and vice-versa.
Right now I'm using this sequence:
var socket;
function senddata(data)
{
if (!socket)
{
socket = new WebSocket(url);
socket.onopen = function (evt) {
socket.send(data);
socket.onmessage = function (evt) {
var obj = JSON.parse(evt.data);
port.postMessage(obj);
}
socket.oneerror = function (evt) {
socket.close();
socket = null;
}
socket.onclose = function(evt){
socket = null;
}
}
}
else
{
socket.send(data);
}
}
Clearly as per current logic, in case of error, the current request data may not be sent at all.
To be frank it sometimes gives error that websocket is still in connecting state. This connection breaks often due to networking issues. In short it does not work perfectly well.
I've read a better design : How to wait for a WebSocket's readyState to change but does not cover all cases I need to handle.
Also I've Googled about this but could not get the correct procedure for this.
So what is the right way to send regular data through Websockets which handles well these issues like connection break etc?
An event you don't seem to cover is onclose. Which should work really well, since it's called whenever the connection terminates. This is more reliable than onerror, because not all connection disruptions result in an error.
I personally use Socket.IO, it enables real-time bidirectional event-based communication between client and server.
It is event driven. Events such as
on connection :: socket.on('conection',callback);
and
on disconnect :: socket.on('disconnect',callback);
are built in with socket.io so it can help you with your connection concerns. Pretty much very easy to use, check out their site if you are interested.
I use two-layer scheme on client: abstract-wrapper + websocket-client:
The responsibilities of the websocket-client are interacting with a server, recovering the connection and providing interfaces (event-emitter and some methods) to abstract-wrapper.
The abstract-wrapper is a high-level layer, which interacts with websocket-client, subscribes to its events and aggregating data, when the connection is temporary failed. The abstract-wrapper can provide to application layer any interface such as Promise, EventEmitter and so on.
On application layer, I just work with abstract-wrapper and don't worry about connection or data losing. Undoubtedly, it's a good idea to have here information about the status of connection and data sending confirmation, because it's useful.
If it is necessary, I can provide some code for example
This apparently is a server issue not a problem in the client.
I don't know how the server looks like here. But this was a huge problem for me in the past when I was working on a websocket based project. The connection would continuously break.
So I created a websocket server in java, and that resolved my problem.
websockets depend on lots of settings, like if you're using servlets then servlet container's settings matter, if you're using some php etc, apache and php settings matter, for example if you create a websocket server in php and php has default time-out of 30 seconds, it will break after 30 seconds. If keep-alive is not set, the connection wont stay alive etc.
What you can do as quick solution is
keep sending pings to a server after a certain amount of time (like 2 or 3 seconds, so that if a websocket is disconnected it is known to the client so it could invoke onclose or ondisconnect, I hope you know that there is no way to find if a connection is broken other than failing to send something.
check server's keep-alive header
If you have access to server, then it's timeouts etc.
I think that would help
in about:webrtc in firefox my IceState is always "in progress" until it fail.
If i use the website in local it works, but if a friend try to call me it doesn't work the remote starts but it's blank.
my turn stun server:
{ "iceserver":{url:'stun:stun01.sipphone.com'},
{url:'stun:stun.ekiga.net'},
{url:'stun:stun.fwdnet.net'},
{url:'stun:stun.ideasip.com'},
{url:'stun:stun.iptel.org'},
{url:'stun:stun.rixtelecom.se'},
{url:'stun:stun.schlund.de'},
{url:'stun:stun.l.google.com:19302'},
{url:'stun:stun1.l.google.com:19302'},
{url:'stun:stun2.l.google.com:19302'},
{url:'stun:stun3.l.google.com:19302'},
{url:'stun:stun4.l.google.com:19302'},
{url:'stun:stunserver.org'},
{url:'stun:stun.softjoys.com'},
{url:'stun:stun.voiparound.com'},
{url:'stun:stun.voipbuster.com'},
{url:'stun:stun.voipstunt.com'},
{url:'stun:stun.voxgratia.org'},
{url:'stun:stun.xten.com'},
And i'm using an AWS server as STUN and signaling.
in about:webrtc errors:
INFO setting pair to state FAILED
ERR specified too many components
WARNING specified bogus candidate
ERR pairing local trickle ICE candidate srflx
Your setup seems to require TURN and you have not provided working TURN servers.
By having ten stun servers, you're trying to get an opinion about your public IP address from ten different people. The answer won't change. Just use a single STUN server...
Using other people's TURN credentials is not something you should do without permission. If you test the credentials using http://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ you will notice that you don't get relay candidates.
For turn:numb.viagenie.ca the credentials are incorrect and 192.158.29.39 doesn't seem to be running a TURN server anymore.
I am working on webRTC video calling. I got datachannel successfully implemented. Now I would like to add video stream to the same peer connection.
I have read that stream should be added before answer and offer. Is there a way to add stream after answer or offer?
In case I have added stream before offer or answer, how could I stop streaming and start it again when needed?
Could there be any issues in maintaining so many streams?
To add stream after creating complete signalling, the Peer connection should renegotiate with stream.
pc1.addstream(stream)
Then once again create offer and send it to other Peer.
Remote peer will add stream and send answer SDP.
To stop streams:
stream.stop();
pc1.removeStream(stream);
In my experience, what Konga Raju advised didn't work. I couldn't send an "updated offer" and have the video streaming actually happen.
I found that this sequence of events works for my case, in which I wish to stream video from peer 1 to peer 2.
set up some way for the peers to exchange messages. (The variance in how people accomplish this is what makes different WebRTC code samples so incommensurable, sadly.)
On each side, set up handlers for the important signalling events. (Some folks have reported that you need to create these handlers at special times, but I haven't found that to be the case.
) There are 3 basic events:
an ice candidate sent from the other side ==> call addIceCandidate with it
an offer message ==> SetRemoteDescription & make an answer & send it
an answer message ===> SetRemoteDescription
On each side, create the peerconnection object with the event handlers we care about: onicecandidate, onremovestream, onaddstream, etc.
ice candidate pops out of the peerconnection object ===> send it to other side
When both peers are present and all the handlers are in place, peer 1 gets a trigger message of some kind to start video capture (the getUserMedia call)
Once getUserMedia succeeds, we have a stream. Call addStream on the peer connection object.
Then peer 1 makes an offer
Due to the handlers we set up earlier, peer 2 sends an answer
Concurrently with this (and rather opaquely), the peer connection object starts producing ice candidates. They get sent back and forth between the two peers and handled (steps 2 & 3 above)
Streaming starts by itself, opaquely, as a result of 2 conditions:
offer/answer exchange
ice candidates received, exchanged, and handled
I haven't found a way to add video after step 9. When I want to change something, I go back to step 3.
MediaStream should be added to peerconnection first only then exchange of offer, answer ,candidates should be done. If the onAddStream() is called ,that mean you are receiving the remote video.