I am trying to use WebRTC to implement browser to browser communication.
I want to allow communication between two browsers running on two different computers in the same LAN.
Can somebody confirm is this possible and if so, how.
I tried looking up the demos and seems they all have examples for application running in the same page. But I would like to connect to a peer computer using some IP address.
Regards
I have just solved your problem using https://github.com/feross/simple-peer
Yes, it is possible to create a Peer to pear connection using PEERJS. PeerJS simplifies WebRTC peer-to-peer data, video. PeerJS wraps the browser's WebRTC implementation to provide a complete, configurable, and easy-to-use peer-to-peer connection API within a LAN Network. PEERJS
Related
Is there a way to stream a video and audio on a website just to the clients, using a camera installed on the server - for instance, like youtube does ?
I've started reading webrtc, but if I use webrtc I should create a stun/turn server and other things, which for one way stream I think is not necessary (this is just my understanding of the things..) because I don't need anything from the clients, literally, neither their video, or audio..
So is there a way to achieve this using html5, streaming just in one direction:
server (camera) -> clients
Is there something about this out there, or should I stick with webrtc ?
I'm going to explain a possible solution for this scenario, there might be others, but I hope mine gives you a rough idea of how you could do it and a start point to explore more about the amazing possibilities of WebRTC. Please let me know if something is not understood.
So, WebRTC is a free, open project that provides browsers and mobile applications with Real-Time Communications (RTC) capabilities via simple APIs. Sweet, that is: WebRTC has a quite good browser support (not in every browser though, Safari just started supporting it a month ago with Safari 11). But in this case we want to use WebRTC in the server side. At the end of the day we can still think about peer-to-peer real time communication, where one of our peers is the server.
I don't know if you are familiar with Node.js, but I recommend you to write your Server app with it (<3 Javascript!):
There are a few libraries that wrap WebRTC functionality to be used in the server side, like node-webrtc and node-rtc-peer-connection.
But I recommend you to to take a look at electron-werbrtc, since
the others might be using deprecated methods or be incomplete.
electron-webrtc runs a headless Electron client in the background to
use Chromium's built-in WebRTC implementation. So with it you should
be able to access the Camera in your server and create a stream to be
served to the other peer (the browser).
All above would be the WebRTC related tasks, in this case: streaming video peer(server)-to-peer(browser).
Now, let's talk about signaling process, stun and turn.
Signaling: imagine now a scenario peer-to-peer with 2 browsers, they want to establish a direct connection and stream video and audio between each other. But they don't know each other, like if I don't know your home address, I can't send you a letter. So they need a service that helps them know each other, so they can have the other's IP. This should be done by what is called "a signaling server". If somehow you know the other peer IP, you wouldn't need a signaling server.
STUN/TURN: the scheme above works perfectly in a local area network where each peer has its own IP address and there are no firewalls and routers between them. But otherwise, you can have peers behind a NAT or firewalls, and then your signaling server won't be able to make both peers to discover themselves. If you have peers behind a NAT, you'll need a STUN server, and if you have peers behind firewalls you'll need a TURN server. This is a bit simplified, but I just want you to have the general picture of when you might need STUN/TURN servers.
To better understand Signaling, STUN and TURN, there is a very graphic article that explains them perfectly.
Now, for your scenario:
I think you prob don't need STUN/TURN servers and also you prob don't need to implement the signaling process, because the browsers that are supposed to receive the stream from the server will know that server address, right? So they can establish a WebRTC connection with it.
EDIT: it is likely that you will need to implement some sort of handshake between the server and the clients (browsers), so this will be the signaling process. This is not part of WebRTC and this is why you need to implement it yourself. As I said, it is the way 2 peers can discover each other, but they also exchange information as their local media conditions, like codecs, resolutions they can handle, etc. For your case, your signaling server could be hosted in the same server you use to strea: you can build a small node.js app that runs there and that manages all the signaling process easily, it is not a big deal. I recommend you to read this article, and specially the section "How can I build a signaling service?". In general all WebRTC articles from that site are very helpful.
Does this make sense to you? I think with it you can start digging a little bit more and see if with this is enough or you need to implement more stuff. Hope it helps!
We develop local multiplayer games in AIR+AS3+Flex environment. We use the p2plocal library, which based on the RTMFP protocol. We found the following error at the testing:
it seems there is a limit of the nodes numbers. Around about 16 nodes, errors appear in the RTMFP network. For example: if there are 15 nodes in the network already, and a new one joined to it, some older node dont see the new one and "vica versa". Over 16 nodes, the RTMFP newtwork is inaccurate: some nodes dont see some others without any logic.
Is this a problem of the RTMFP? Or maybe a Windows socket limit? Or..?
Anyone has any idea?
RTMFP is UDP based for P2P communication and is highly dependant on network (may not work reliably).
Test your RTMFP capabilities with these tools:
http://cc.rtmfp.net/
http://blog.yoz.sk/2010/07/rtmfp-connection-tester/
To develop a solution that works reliably for most users, a RTMP relay server can be used.
I am trying to test sip capabilities of firewalls using webrtc. However I noticed using the servers needed for webrtc (stun turn websockets etc.) will give me a false positive in that it won’t catch nuanced issues with the ALGs. For reference this is being done from a chrome app so I can’t just run a native sip stack in the browser.
My Question: can I leverage webrtc to just send sip(invite, options, register) and not use any other methods that would get around the firewall?
Your question doesn't make sense because WebRTC doesn't use SIP - SIP is a signaling protocol, and WebRTC doesn't do signaling. What that means is that SIP can be used to establish a WebRTC connection, but they are mutually exclusive.
SIP is sent over a data connection, like a hard line from a phone to a PBX or a websocket from a browser to a server.
It is possible to set up a WebRTC connection using out of band mechanisms, but then that wouldn't be SIP.
Actually there might be a way around that.
Use the signalling server to to do any sort of preconfigurations you might want to do before setting up the peer connection. This would allow you to specify codecs and resolution of the feed as a SessionDescription before hand or even check if the other peer is capable of WebRTC or not.
I'd recommend Socket.io =D
I'm planning to realize the following project and would be thankful if somebody could verfy my approach!
I want to establish a fully bidirectional wireless realtime communication between a smartphone (cross platform) and a embedded microcontroller running a webserver.
The webserver should provide data of the connected hardware in realtime e.g. temerature.
The smartphone should render these on screen and you should be able to configure the hardware e.g led color with the smartphone and save the config to the embedded webserver.
My first guess was to use HTML5 websockets but they aren't available on all platforms so I got inspired by XBMC, which uses JSON-RPC.
Just imagine a car stero system with bluetooth connected to a µC with webserver and wifi dongle.
My plan is to implement a webapp on the webserver which lets serves the purpose mentioned above. But the tricky part is to get the user to establish a bluetooth connection to the stereosystem because i looked up similar questions which say you can't access stuff like bluetooth on the smartphone with HTML5.
long story short, this is the current idea:
hardware -> µC -> webserver -> HTML5 Webapp-> WIFI -> Smartphone
communication via JSON RCP.
I would be highly thankful if somesone could give a statement to said idea and planned implementation because I never done this before!
Thanks guys!
We at muzzley, have developed a framework to simplify this process. We provide a way for your browser applications to communicate with smartphones. In the side of the smartphone you have widgets that are already done (gamepad, drawpad, switch, swipe, others) or you can build your own html based widget.
(disclaimer: i work for this project)
Most of the work is already done for what you want to do :)
Quick start here:
http://www.muzzley.com/documentation/quick-start.html
You can pull from github several examples here:
https://github.com/muzzley/muzzley-demos/
Lib for browser:
http://www.muzzley.com/documentation/libraries/javascript.html
I hope it helps.
Best
I think your first instinct was probably right. Have you looked at socket.io for node? It's essentially a shiv which ensures that you can use websocket functionality in virtually any combination of device and browser (see list of supported transport mechanisms and browsers here).
It should allow you to avoid bluetooth altogether.
I want my web application to communicate with a serial device on a host machine (e.g. a card reader). I don't want to use the ActiveX/COM route. Is there something in HTML5 websockets that could help me?
Complete code example for a serial-to-WebSocket gateway is here:
https://github.com/oberstet/Autobahn/tree/master/demo/serial2ws
This is based on Autobahn WebSockets .. and is possible because Autobahn is based on Twisted, and Twisted has support for serial, XMPP, ... many things.
Disclaimer: I'm author of Autobahn.
Yes, Web Sockets could help.
Take a look at this, it is using web sockets for a micro-controller: http://blaisejarrett.com/websockets/