This is a multi-part series blog about PeerConnection state changes in WebRTC. This series of posts aims to support users who use a REST API integration to callstats.io. In the upcoming blogposts, we tell more about basic state changes that need to be reported in order for callstats.io to provide the best call diagnostics experience.
The WebRTC specification defines four states that change throughout the lifetime of the PeerConnection, namely signaling, ICE gathering state, ICE connection state and PeerConnection state. In this very first blog post, we describe transitions of signaling state.
Signaling states in WebRTC
As WebRTC signaling is not standardized, application developers can use their own signaling mechanism. The signaling content follows the SDP offer-answer exchange model and it is delivered to the ICE subsystem. The sequence of exchange of these messages affects the signaling state of PeerConnection.
To illustrate the process of signaling state transitions, let’s imagine a call between two users, Alice and Bob, and track the changes in their signaling states in accordance with WebRTC API calls they make.
Alice is in stable state when creating a new Peer Connection(new pc). Alice will start the session establishment by creating an offer (pc.createOffer) and setting the local description (pc.setLocalDescription) for that offer. Once the local description is successfully set, Alice moves to the state have-local-offer and sends out the SDP offer to Bob.
Bob is in stable state when he receives the SDP offer. Bob sets the remote description (pc.setRemoteDescription) using the Peer Connection and moves to the state have-remote-offer.
Bob creates an answer (pc.createAnswer) and sends the SDP answer to the Alice. Bob also sets the local description (pc.setLocalDescription) and moves to the stable state.
Alice receives the SDP answer from Bob and sets the remote description (pc.setRemoteDescription). Alice moves from the have-local-offer state to stable state.
The above scenario does not take into consideration possible intermediate states like provisional answers or offers. The diagram below shows the complete signaling states including provisional answers and offers.
Proper integration of signaling state transitions is vital in enabling callstats.io to do the proper call classification. In the next week, we will describe efforts needed to properly integrate REST API with ICE state transitions, stay tuned!
For a step-by-step instruction on integrating REST API, please have a look at our REST API documentation page.
Second diagram source: https://www.w3.org/TR/webrtc/#rtcsignalingstate-enum