I was following THIS tutorial in order to implement video calling using WebRTC. The example allows people of the same group to communicate using video or audio and it works well. I was wondering if you could Video call people who are on different pages of the same website without having to be on the specific 'video call page' only?
What is the way to allow incoming calls even when you are not joined in a group? I believe it must be a group request (Sending a request to join from Person A to Person B). Is this possible using WebRTC?
WebRtc is not based on "who is connected to what page".
The connections only happen through your signalling server logic. This means that any webrtc peerconnection can connect to anyother peerconnection as long as your signalling server relays the connection startup logic(SDPs and Ice candidates).
The webpage is only a way to display the media that you have, the javascript you wrote will run on any page you want.
Related
I am wondering what is suitable for my case, using espeasy or Tasmota. I know espeasy is using http requests and Tasmota is using mqtt.
I want to control my sonoff devices by a raspberry pi that is acting as a home automation hub, and it in turn send updates and receives commands from AWSIoT platform. For interacting with AWSIoT platform, it uses mqtt.
What are the pros and cons of using either? and will it cause problems if I control several sonoff devices with http, while using mqtt for AWSIoT? or better use mqtt for all AWSIoT and sonoff?
I am not an expert on the topic but have tried a few things and got some insight for you on why to prefer MQTT over HTTP.
Security. Remember that the 'S' in IOT stands for security. Joking aside. I have not seen an option for encryption (HTTPS) of the HTTP-traffic for tasmota. (May the internet correct me if I am wrong) So choosing HTTP means your user/password (which are not a requirement but should totally be used) are transfered via URL query parameters as plain text. MQTT has built-in mechanisms for encrypting the traffic. I haven't been able to get that working in my network but I'm trying.
Flexibility/Reliability. With MQTT/Tasmota you have the ability to implement automations that do not rely on your home automation hub by having your devices publish MQTT-messages directly to each other for interaction. For example if you would like to implement an emergency off button that turns multiple devices off you do not want that to rely on your home automation server. Doing this with HTTP 'could' be done too but requires all users/passwords of all the devices to reside not only in your home automation hub but also on other single devices.
Networking. Adding new devices to your hub should be as easy as possible. In matters of HTTP your home automation hub has to know how to find your devices via IP-addresses or domain names since it has to resolve a URL. When using MQTT you just connect your tasmota devices to your broker and use their topic in the home automation hub. The devices do not even need to have a static IP or reachable domain name of mDNS name of any sort. That's in an essence what makes pub/sub for IOT so interesting in the first place.
Existing support. Before building your own home automation solution be sure to check out home assistant (my favorite) or any of the other home automation solutions if they fit your need. Do not reinvent the wheel. A tipp for home assistant: Do not use MQTT auto discovery in combination with tasmota. This is the only thing that has not worked out for me. Manually registering devices works reliably.
Hope that helps. If you still prefer HTTP checkout the app "Tasmota control".
Which tools/servers etc would be needed? Is there any articles or something that I could read along and follow to help me create the functionality?
Let's assume that your chat application is a web app. You could integrate it with asterisk through a library suporting sip (e.g. sip.js) working on top of WebRTC. In WebRTC, the sources and sinks of media streams come or go to audio (or video) tags that have attributes as muted (see HTML Audio/Video DOM muted Property) than can be managed by the app to simulate PTT. The PTT can be implemented with a button in the app, with a keystroke or even with an USB HID device depending on how much do you enjoy struggling with external access to browsers (I certainly do).
There are alternatives involving some kind of third party control (AMI, for example), that would take advantage that ConfBridge can be controlled to mute participants on the fly. It all depends on the specific requirements.
You can't do real push-to-talk using asterisk/sip.
Just becuase sip connect sequence take 0.5-1second usually.
Best option is use your own custom app which will maintain sip session(send sip ping every few sec) upto X(for example 1minute) second after last message, not send rtp if user not pressed key(but you still need send keapalive rtp to maintain NAT).
After knowing about some great features of WebRTC, I thought of using WebRTC one to one audio/video calls in my web application. The web application is for many organizations/entities of a category who can register and keep recording several records daily for their internal working and about their clients. The clients of these individual organizations/entities also have access to the web application to access their details.
The purpose of using WebRTC is for communication between clients and organizations. Also for daily inquires by new people to these organizations about products and services.
While going through articles on google etc. I found broadcasting or one to many calls requires very high bandwidth to users if we don't make use of Media Server.
So what is the case for one to one calls?
Will it affect the performance of web application or bring any critical situation if several users are making audio/video calls(one to one) to each other simultaneously as a routine?
The number of users will be very large and users will be recording daily several entries as their routine work. But still it is manageable and application will be running smoothly but I am not sure about the new concept WebRTC. Will it require a very high hosting plan? Is using WebRTC for current scenario suitable or advisable?
WebRTC by its nature is Peer-to-Peer. Meaning that the streaming data is handled CLIENT side. All decoding, encoding, ICE candidate gathering/negotiation, and media encrypting/transmitting will happen on the client side and not on server side. So, you will be providing the pages, client side JS, and some data exchange(session negotiation signalling) but all in all, it is not a huge amount of work. It should be easily handled without having to worry about your host machine being over worked.
All that said, here are the only a performance concerns that would POSSIBLY affect your hosting server.
Signalling session startup, negotiations, and tare down. This is very minimal(only some json data at the beginning of a session). This should not be too much of a burden but you should be aware that if 1000 sessions start at the same time, you will have a queue of messages to direct to the needed parties. How you determine the parties, forward the messages, and what work you do server side could all affect performance. If written smartly(how to store sessions, how to forward messages, etc.) should not be a terrible burden.This could easily done with SignalR since you are on ASP.NET or you could use a separate one running Node.js(or the same box, does not matter) if you so desired.
RTP TURN relay if needed. This will probably be through a different server(or the same one as your hosting server if you want). For SOME connections, a TURN server is needed and any production ready WebRTC solution should take this into account. Here is a good open source turn server. Bandwidth usage here could be very high as RTP packets are sent to this server and the forwarded to the peer in the connection.
If you are recording the streams, you may have increased hosting traffic depending on how you implement it. Firefox supports client side recording of the streams but Chrome does not(they say it is in the works currently). You could use existing JS libraries to record the feeds client side and then push them anywhere you want. You could also push all the data through a MediaServer that will mux, demux, and forward the data to be recorded anywhere you like. Janus-Gateway videoroom is a good lightweight example of a mediaserver.
Client side is a different story.
There are higher level concerns in the Javascript. If you use one of the recording JS libraries, this is especially evident as they do canvas captures numerous times a second which are a heavy hit and would degrade the user experience.
CPU utilization by the browser will increase as the quality of the video being streamed increases. This is rather obvious as HD video frames take more CPU power to encode/decode than SD frames.
Client side bandwidth usage can also be an issue. Chrome and Firefox try to modify the bitrate of each video/audio feed dynamically but the video Bitrate can go all the way up to 2 Mbps. You can cap this in Chrome( by adding an attribute in the SDP) but not in Firefox(last I checked) as of yet.
I need to stream several "channels" (by channels I'm thinking of radio channels, so playlists might be more appropriate) of queued MP3 files to around 200 clients over the internet from a Windows 2008 R2 / IIS 7 web server. Encryption of the stream is not a requirement.
I need some way to ensure each client can only stream one channel at a time. I was thinking of restricting by IP address, and would welcome any suggestions on how I might go about this, or if there may be a better way.
For my clients I assume I'd need a player on the client end that could facilitate "logging in". Ideally I would be able to stream to windows xp/7/8, mac and android clients.
I would need to be able to log in remotely and control each channel / playlist from a finite list of MP3 files hosted on the web server.
I'm wondering if there any off the shelf products that I could use to do this. If not, I'm stuck on what would be the best way to go about this.
I've briefly read up on shoutcast, auto dj, streamcast and ice cast, but I don't have any experience with these solutions, and can't find any information about how to implement the security requirements I have (limiting access to one stream per client / ip address).
IP addresses do not uniquely identify users. There are plenty of situations where NAT comes into play, and you can have hundreds of users all behind the same public IP address.
What you need to do is have another method for identifying users. Assuming you don't want to require accounts, you can use a session ID.
Basically, you assign an ID with a cookie to a browser. When the user clicks a link to launch their audio player, the session ID is passed in the URL to the stream. With this method, it doesn't matter if the browser itself or a separate audio player is used to play the stream. It is up to the streaming server to then accept or reject the request.
It is common to accept any new request and disconnect the old when a new stream starts. Icecast doesn't support this sort of thing natively, but it does provide an API of sorts with the admin interface that you can use from your own scripts to get this behavior.
Alternatively, I have written a server called AudioPump that provides similar functionality. It isn't generally available yet, but please contact me at brad#audiopump.co if you're interested.
Suppose there is a server producing events continuously. That server has clients accessing it via their browsers, which must receive every event produced. If the server sends the events directly to each client, after a number of clients it will certainly exhaust its bandwidth. Are there technologies that allow using your own clients as peers for the distribution of those events?
you sayed your clients are browsers, so the server cannot talk to the clients. but you can ask the server with AJAX, if there are new events. This technique is called long polling, see http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery
Try http://socket.io/. It allows you to very easily target specific client (browser), specific group of clients (room) or everyone connected and push data to them so that frontend JS can then handle it.
Don't know your backend technology, but it ties in very nicely with node.js.