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.
Related
When we are working in firebase using javascript which event is triggered after we insert data using ref.push or ref.set.
I wanted to know if my data is inserted or not
I also wanted to throw an error when user have disconnected from internet while inserting data in firebase
I haven't seen any function or any method in internet which tells me about if data is successfully inserted or not.
This functions Promise-based, so you can use try/catch:
try {
firebase.push(data) // or set
} catch (error) {
console.log(error) // here is error
}
The Firebase Realtime Database doesn't consider a lack of internet connection an error condition. Instead it continues to work to its best ability in the given conditions.
When you perform a write operation (with set, push, update, or remove) while there is no internet connectivity:
The first client fires local events immediately, so that your app can update the UI for the new/updated data.
It then queues the write operation for delivery once the connection is restored.
Once the connection is restored, the client sends any pending write operations it has in the order in which the client performed them.
It then handles the response from the server, which (if the server rejects the operation because of security rules) may lead to firing more local events so that the app can put the UI back into the correct sate.
And it then finally calls any completion listeners, and resolves or rejects the promise for the set(), push(), update(), or remove() method.
You'll note that there is no error raised at any point for a lack of an internet connection.
If you don't want to send any data to the local queue when the app has no internet connection, it's best to detect if the Firebase client is connected to the server. You can do this by listening to the .info/connected pseudo-node. This covers more than just having an internet connection btw, but also cases where the internet connections works but the client can't reach Firebase. The best practice here is to use a "global" listener for this status, and disable the relevant UI elements if the client is not connected.
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.
Use Case: three peers are in video chat with other two in same room, server sends a message and all three change mode to audio,
for now, only chrome supports renegotiation, so for firefox, i just close the connection and create new peer connection, but after I check both sides are chrome and change mode,
If I am changing mode of only one peer at a time, it works smoothly.
but when, message comes from server, both peers try to renegotiate simultaneously and it didn't work, I got something like wrong state : STATE_SENTINITIATE
To handle that problem, I did a workaround where, whenever peerconnection has to renegotiate, it checks if it is the caller
if yes, it goes ahead with renegotiation.
else(if it is answerer), it would change the offered stream and signal the caller to renegotiate.
The above workaround works for few renegotiations, but for some cases, it throws error at setting local description on the answerer's side, claiming wrong state to be either STATE_INPROGRESS or STATE_SENTACCEPT.
how do I resolve this issue?
Since renegotiation is a state-machine, having both sides initiate renegotiation at the same time can collide, and you end up with invalid-state errors. This is called glare.
Your workaround is one way to deal with glare, essentially using signaling to make sure renegotiation is always initiated from the same end (typically the offerer's side).
You say you're still seeing occasional invalid-state errors even with this workaround. Since renegotiation is a round-trip between peers, there's a window of time where if you're also responding to signaling requests for new renegotiation, I suppose you could still get invalid-state errors if you try to renegotiate again too soon.
You can check the pc.signalingState attribute to know what state your peerConnection is in at any time. I would look at that when you receive incoming messages, to see if this is the problem. If it is, I would hold off on renegotiating until your connection is in the "stable" state again. You can use pc.onsignalingstatechange to react to state changes.
Another solution I've heard of (but not tried) to solve glare would be to let peers renegotiate independently, and when they do glare, let the offerer always win. e.g. the answerer would cancel any attempts it was making on receiving an incoming offer (by somehow reverting itself back to its previous stable state), whereas the offerer would ignore any incoming offers during its own attempt.
By the way, renegotiation is supported in Firefox as well now (38+) so you could try it there as well to see if you get the same problems.
Is it mandatory for the WebRTC sequence of events be allowed to execute in the order depicted in this diagram?
WebRTC Flow
The reason I ask is that my one on one WebRTC chat performs flawlessly, however when a third participant enters the video conference, frequently I find one of the RTCPeerConnection shows iceConnectionState: "failed".
I do find that the remote stream is received before I process the Answer and before ICE Candicates are received.
How the following sequence be strictly enforced:
1) Send offer from caller.
2) Receive offer on callee.
3) Process offer on callee, generate answer and send to caller.
4) Receive and process offer on caller.
5) Send ICE candidates from caller to callee.
6) Process ICE candidates on callee.
7) Send ICE candidates from callee to caller.
The debug console shows that ICE candidates start getting generated as soon as the localmedia stream is added to the RTCPeerConnection. Should they be sent over immediately or wait till the sequence allows for sending?
May be too late but for the records:
Yes, the RTCPeerConnection is based on sequence. You can refer here for good explanation. I too struggled to control the flow and errors didn't mean much.
Based on my successful research/implementation (Chrome v74), to enforce sequence do (you can also see any sample online or here):
Send CreateOffer from Caller (signalling part; custom transport to the other users); enable PeerConnection.onnegotiationneeded => CreateOffer() only for Caller
Callee can be ready with video/audio streams added it to RTCPeerConnection on its side, then accepts offer and sends answer to Caller (signalling part)
Caller gets the answer and adds the video/audio streams to RTCPeerConnection conditionally when PeerConnection.connectionState == "new", the tricky parts: condition connectionState == "new" ensures it does not add again as offer / answer might be exchanged many times with state being connecting etc. Another is, if you add video/audio streams before this step, it will be hard to control the ice sdp flowing and raising errors at wrong states (relates to comment from Benjamin Trent, here) (signalling part)
since offer, answer is exchanged, now many ice events flows are exchanged (signalling part)
Connection should be established (assuming STUN configured and if peer to peer not possible, TURN required)
I hope I have highlighted few points missing online when you get hands on into this.
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.