Audio alerts and call/ringing option (skype like)

Hi,
I am building an app where user can have a one on one video connection. Most probably I will use https://tokbox.com/ for the WebRTC connection.

Do you know if its possible to have a call/ring option implemented in the browser? Something what we are used to from using skype or just the normal phone. It should ring when one user is calling the other. So far it’s just joining a stream and waiting for the other to join.

Maybe it’s possible with a notification that plays a sound and a button for joining the stream? What do you think?

I saw this packages:
Pushing notifications from server:

And playing a sound:

2 Likes

no ideas??? maybe just some thoughts…

yes, it’s possible. I’d suggest creating a simple chat application first. Upon an outgoing chat, start looping a sound. When the peer responds, stop the sound. I recommend this package for the websocket chats : https://github.com/YuukanOO/streamy ( this can also become your “signalling server” as you go to do WebRTC )
Then, once that’s all working, start diving into WebRTC, and figure out the appropriate event where the sound should be played. One of the first steps in creating a WebRTC connection is a simple websocket chat style message. You can play the phone ringing sound on that event, so it’s not too different conceptually to playing a sound in a simple chat application. The event flow and order of WebRTC is extremely complicated and really difficult to get right, so that’s why I recommend to just do it in a simple app, then start to add complexity. There is a great Meteor resource here for WebRTC video and audio call here: https://github.com/srtucker22/quasar , https://quasar.meteor.com/#/ .

2 Likes

Thanks @looshi,

I am currently diving into the process you suggested. Sounds very reasonable. The streamy package is pretty complex. The benefit of using the websocket option is because of the ability to push directly to the user right? Speed wise this is not really needed (Pub/Sub works for me) but a good point for the WebRTC option I think.

I’m currently interested on implementing a voice chat between 2-4 users (the same like you but without video). I’m still researching which is the best solution for me.

First, I am wondering which is the best solution in the present. WebRTC or RMTP/HLS (flash)? WebRTC is the future but all majority of webcam sites are using RTMP right now (which supports all desktop browsers). We can compare the two technologies in terms of supported browsers:

WebRTC: Supported desktop browsers are Opera, Firefox and Chrome. It can work on Explorer and Safari (desktop) using plugins (the good ones are not open source, like Temasys ones). It works also on Android but not in iOS (you need a native app). Since it’s a peer to peer connection without a streaming media server it’s useful for one-to-one (I think there are solutions for broadcasting).

RTMP/HLS: You can try it using nginx with the rtmp module. Supports all desktop browsers (flash). It doesn’t support mobile browsers but you can use HLS for Android / iOS devices (I don’t know if is needed to be a native app for iOS). You need a streaming media server and you can broadcast one-to-many.

In my case, I’ll prefer to use WebRTC. But I don’t know if is better to use a third party solution like peerJs/quasar/somewebrtcpackage or implement it for my needs (like rocketchat). A good page with many webrtc examples and demos is https://www.webrtc-experiment.com/.

But I am not wondering to use a payment service like tokbox (seems like wowza). Why are you considering to use tokbox?

I am not familiar with RTMP/HLS. I just went directly to WebRTC.
The reason why I consider to use tokbox is the quality. After following this tutorial I was disappointed about the quality and went for some professional services. I am working on an professional web coaching app and the quality of the stream (video and audio) should at least be as good as skype. And if the number of participant in the stream is 3 or more I can use the tokbox server, so the client does not need to have n connections, but only one to the server. The big downside of tokbox is the pricing. You pay about $0.60 per hour for 2 participants (+$0.30 for every additional person/hour). With a freemium business model this can sum up to a lot of money.

I will definitely look closer at quaser or other direct implementation from your link before finally choosing tokbox.