I expected that I had ducked around the landmine with that question, but evidently I hit a tripwire and all of a sudden we were in a back-and-forth smack down.
“The Web does not need SIP.”
“SIP gives us a standard method of interoperability.”
“Web sites only need browser operability.”
“SIP is the best solution for federation.”
“The website is it’s own federation.”
For what it is worth, here is my opinion, delineated to its essence.
- Federation takes place on the web via DNS. SIP has URIs that may prove to be of value in some cases, but by and large, WebRTC on the website can be totally self contained, and it is right to value innovation over federation.
- Reality Check? Not every website is going to have an app for every mobile device. It’s a bad idea at many levels, anyway. The browser can be the client, but when it is not, a direct soft client relationship to every WebRTC web site is impractical. Additionally, life on the web is particularly asynchronous; therefore the data channel to SMS and e-mail gateways makes sense.
- In most use cases, SIP adoption by websites is probably a bad idea. The one exception is with retail call center opportunities, and even these could probably be better served by being event-driven in the use of SIP as a gateway to call center personnel.
- As usual, policy may yet dictate that websites support some kind of recording or other public emergency service requirement. That will hopefully not be the case, but SIP will become a requirement if it is.
Following the discussion, I suggested to Phil Edholm that he include a session on Federation and a session on Discovery. Another important thing to think about is that WebRTC will eventually be the better solution for Google Ad Words, and it will probably lead to more peer-to-peer solutions.
I have no doubt that this discussion is going to lead to evangelical-like conversations, and I look forward to hearing more thoughts on the matter.
Edited by Stefania Viscusi