What is the proper way to reject a WebRTC offer?

Question

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.

Answer 1

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.