But we already have webRTC, why SIP? It's standardized, mature and more basic protocol. Ofc WebRTC is based on SIP, but with who knows how many additional layers.
But we already have webRTC, why SIP? It's standardized, mature and more basic protocol. Ofc WebRTC is based on SIP, but with who knows how many additional layers.
URIs are hosted/registered directly on user's computer, so for example it's not possible to take advantage of javascript/css
This doesn't follow either. If I host a webpage on my personal computer, I can host the js/css in exactly the same way.
Good point and I agree, but it solves problem of direct communication between users (NAT traversal). It would be great if SIP had plain and simple GET method (without need for session/dialog).
> This doesn't follow either. If I host a webpage on my personal computer, I can host the js/css in exactly the same way.
How can I get your js/css from outside, if you are behind NAT? STUN? NAT traversal is already part of standard SIP infrastructure.
Sorry on stubbornness, just trying to brainstorm a little.
> How can I get your js/css from outside, if you are behind NAT?
The same way you get the HTML, whatever approach is used.
I don't think it's impossible to build a system involving distributing "advertisements" saying how to reach systems on a distributed hash table, then using either ports opened through UPNP on home routers or a "supernode" collection of STUN servers to communicate to home systems. There are three big downsides to this which are probably why we've not seen one yet:
- no way to monetise it if it's truly distributed and open source => reduced incentive to build and maintain
- no central party to fight spam and abuse => system will drown in spam and abuse
- necessarily broadcasts an association between home IP address and person => vulnerable to privacy problems and DOS attacks