By Venkatesh D
Here is a topic, which is already discussed in breadths and depths by many WebRTC evangelists and enthusiasts. This blog tries to add a different dimension over many basic principles of WebRTC Signaling.
There are many discussed, proposed and preferred application signaling schemes like SIP over WebSockets, XHR, XMPP, signaling over data channel etc.
This brings us to a forum to evaluate what next could be on the WebRTC signaling layer.
Supple Signaling Layer
Has it benefited the WebRTC application developers? Yes, it certainly has given an open space for many developers to build their proprietary signaling framework/layer, each providing its own merits and demerits.
Some more thoughts, which trigger further questions -
What if SIP was considered a defacto application level stack for VoIP on all platforms, just like TCP/IP? It enables every device to be a VoIP terminal, facilitating browsers too to use platform services efficiently. If not platforms, what if SIP was made a part of browsers and still is making use of VP8/9 codecs for video?
The intent of this entire blog is to push for a common WebRTC application signaling standard for voice, video and data over IP across all platforms, devices or browsers, so that, the end user receives maximum benefit out of the latest and happening technologies!
As we know, the team that introduced WebRTC, kept open the WebRTC Signaling layer free for application developers to choose their convenient and efficient signaling scheme. The focus was only to make the WebRTC core i.e., make the media layer strong and consistent. The reasons for such an architecture being, the challenges that may arise because of stateless web page reloads or a developer preferring to have a custom signaling scheme, which is suitable for the use case in context.
The current W3C version of WebRTC is based on JSEP. Microsoft also has a proposition called as CU-RTC-Web. Each has its own merits and demerits. However, these become the core of WebRTC and, hopefully, all the key players will converge with a common standard to resolve "interoperability" issues and move forward with a common standard platform.
The current W3C version of WebRTC is based on JSEP. Microsoft also has a proposition called as CU-RTC-Web. Each has its own merits and demerits. However, these become the core of WebRTC and, hopefully, all the key players will converge with a common standard to resolve "interoperability" issues and move forward with a common standard platform.
There are many discussed, proposed and preferred application signaling schemes like SIP over WebSockets, XHR, XMPP, signaling over data channel etc.
This brings us to a forum to evaluate what next could be on the WebRTC signaling layer.
Supple Signaling Layer
Has it benefited the WebRTC application developers? Yes, it certainly has given an open space for many developers to build their proprietary signaling framework/layer, each providing its own merits and demerits.
What does it lead to?
SIP, on the other hand is an established, well adapted signaling standard for VoIP. Hence, many SIP-based VoIP service providers co-exist with least to nil interoperability issues, making the end users use the services without worrying much about interoperability.
For WebRTC to be in the same state of existence and adoption in future, it needs to have a defined minimum common standard, accepted and followed by all the WebRTC service vendors. This should give complete liberty to the end users to choose the required WebRTC service provider, but, still be able to connect with a user who is subscribed with a different WebRTC service provider. However, backing the principle of developer independence on signaling, there can be extensions on top of the signaling standard that a WebRTC service provider can build. These extensions will be confined to their restricted user base and would not intervene in the basic WebRTC signaling across all the vendors or service providers.
The above roadmap gives a win-win situation to both the worlds - developers/service providers as well as end users. It also helps with quicker adoption and establishes clearer boundaries among signaling standards makers, WebRTC service providers and end consumers. Though fragmented through extensions, the core standard signaling still unites all players, resolving the interoperability issues. As the signaling layer standard receives widespread acceptance and adoption, the issues leading to network traversals, security, performance etc. start to diminish soon. As WebRTC bundles audio, video and data in a session, addition of a common signaling layer standard exposes humongous forms of features, services and applications for the end user.
It is good that the media core, with its signaling across browser makers, is getting stabilized, as driven by W3C. This gives a solid platform on which, a common application signaling of some form can be standardized, just like SIP or SIP itself.
- Fragmented user base - The end users will be confined to a limited set of key service providers in the future. Though WebRTC is open and free, it may not reach every true end user based on the same philosophy. To make accessibility of WebRTC seamless across user base, some percentage of application signaling should also be standardized in a way that every service provider follows it. This helps the end user to easily switch between service providers seamlessly.
- Interoperability challenges - Absence of a standard signaling layer leads to fewer monopolized service providers, and hence, fragmented user bases. Each user base is isolated through the respective WebRTC service provider. Though the media backbone of every user base is the same WebRTC, they will not be able to reach each other across the service provider’s borders because of signaling interoperability challenges between the service providers. The language spoken to carry WebRTC by each WebRTC vendor is different and thus, it is tough to understand the reciprocation between them. This further drives to a possible solution, making it work through federation.
- Federation possibilities – As WebRTC service providers evolve and gain a significant subscribers’ share, there will be multiple large pools of customers held by each service provider. Each pool enjoys the services provided by the respective service provider, but, may not proliferate with users belonging to another service provider. Hence, this pushes the service providers to evolve as a federation to expose/exchange their services mutually with other service providers, so that, a user belonging to one WebRTC service provider can also access services from another service provider.
For WebRTC to be in the same state of existence and adoption in future, it needs to have a defined minimum common standard, accepted and followed by all the WebRTC service vendors. This should give complete liberty to the end users to choose the required WebRTC service provider, but, still be able to connect with a user who is subscribed with a different WebRTC service provider. However, backing the principle of developer independence on signaling, there can be extensions on top of the signaling standard that a WebRTC service provider can build. These extensions will be confined to their restricted user base and would not intervene in the basic WebRTC signaling across all the vendors or service providers.
The above roadmap gives a win-win situation to both the worlds - developers/service providers as well as end users. It also helps with quicker adoption and establishes clearer boundaries among signaling standards makers, WebRTC service providers and end consumers. Though fragmented through extensions, the core standard signaling still unites all players, resolving the interoperability issues. As the signaling layer standard receives widespread acceptance and adoption, the issues leading to network traversals, security, performance etc. start to diminish soon. As WebRTC bundles audio, video and data in a session, addition of a common signaling layer standard exposes humongous forms of features, services and applications for the end user.
It is good that the media core, with its signaling across browser makers, is getting stabilized, as driven by W3C. This gives a solid platform on which, a common application signaling of some form can be standardized, just like SIP or SIP itself.
Some more thoughts, which trigger further questions -
What if SIP was considered a defacto application level stack for VoIP on all platforms, just like TCP/IP? It enables every device to be a VoIP terminal, facilitating browsers too to use platform services efficiently. If not platforms, what if SIP was made a part of browsers and still is making use of VP8/9 codecs for video?
The intent of this entire blog is to push for a common WebRTC application signaling standard for voice, video and data over IP across all platforms, devices or browsers, so that, the end user receives maximum benefit out of the latest and happening technologies!
No comments:
Post a Comment