(1/13) At the recent Astricon, Dan Jenkins gave an interesting overview of #WebRTC. He also indicated that this only touches the surface of WebRTC. I feel that the audience who is well versed in SIP, will be interested in knowing that WebRTC is unSIP.
(2/13) Typical SIP deployments follow trapezoidal connection model. Signal flows from A to her server which routes to B’s server and is finally forwarded to B; barring middlebox traversal issues, media flows directly between A and B. By necessity A has to have a server. #WebRTC
(3/13) #WebRTC is different. First of all there is no requirement that A need to have her own server. Though media flow follows a similar pattern, signal flow is different - A sends initiation request to B’s server which forwards it to B. It is a triangular connection model.
(4/13) It is true that #WebRTC has not standardized any signaling protocol; to compensate for this, it allows B’s server to dynamically download the control procedure to A’s client.
(5/13) #WebRTC’s use of the triangular connection model and dynamic download of control procedure gives us the freedom to offer innovative UI/UX and to devise new features without worrying about compatibility issues.
(6/13) Whereas we straddled SIP with the requirement of backwards compatibility with 2500 set, the starting point for #WebRTC client is a screen-based device that can present a rich interface. So there is no excuse if a WebRTC app does not offer context-specific and rich UI/UX.
(7/13) Yes, one can use any library, including JsSIP. But don’t select a library first. Start with a well defined UI/UX and then select a library that will provide the desired effect. #WebRTC
(8/13) Next let us consider user identity. In the SIP world, the identity is SIP URI. We are free to define in #WebRTC world. My advice is to use a web-based id mechanism - like OpenID, OAuth, IndieAuth or Web ID.
(9/13) This will allow B’s server to authenticate A without involving A’s server. Remember A may not have a server to begin with. Note that there is no need to universal deployment of STIR/SHAKEN.
(10/13) SIP also got rid of the notion of calls and went with sessions. But it is in name only. SIP’s contemporaneous alternative H.323 has a concept called session which survives even if no media is flowing presently. As a practical matter SIP gave up on that structure. #WebRTC
(11/13) #WebRTC brings back that notion: A first establishes a signaling connection with B’s server before establishing the media connection. Similarly your control procedure can close the media connection and keep the signaling connection alive.
(12/13) This gives rise to lots of innovative approaches to even traditional features. For example, there is no need for Hold and Music on Hold. Just close the media session and when ready, the resuming party can indicate it on the signaling connection. #WebRTC
(13/13) So go and build amazing solutions based on #WebRTC.
(Promo) A shameless plug: register for a free account at mystoop.chat and explore. You will see many examples of different UI/UX ideas by tweaking Context types. We use custom signaling procedure since we needed the freedom to introduce new UI components. #WebRTC
