8

I would like to build a service that allows a user to listen to a call live from their browser.

I have some experience with Asterisk and this seems to be flexible enough to do what I have described.

Node.js sounds good because it is purported to handle concurrency well, and, I like JavaScript.

In the browser I figure that the HTML5 audio tag, since it handles playing from a streaming source, would be fine to play the sound.

A colleague of mine worked together a demo of this concept using Icecast, but was not able to finish it. There were also significant latency isssues.

My question is this:

How should I go about getting started on this?

Any help is appreciated!

Update:

I found a presentation discussing implementing SIP on top of WebSockets via a SIP proxy on the backend:

http://sip-on-the-web.aliax.net/

Once I have this up and running, the next step would be implementing the streaming. It seems like I should be able to proxy the audio output that would normally go to the sip client, through a secondary server that then streams it to the browser. I wonder why this couldn't be done all in memory? Then there is no need to write and read the file as the call proceeds.

Jonathan
  • 5,495
  • 4
  • 38
  • 53

5 Answers5

8

If you're willing to wait for Asterisk 11, we're currently working on implementing support for WebSockets directly in Asterisk. More on it here:

Asterisk 11 WebRTC/RTCWeb Support

I'll just quote Kevin here, since he summarizes it better then I can:

"Today, the in-progress development branches have support for the WebSocket transport protocol (used for communicating signaling messages between the browser and Asterisk), SIP over WebSocket (currently being standardized by the IETF) and ICE/STUN/TURN (media handling mechanisms for NAT traversal and connection setup security). In addition, there’s a new Jingle/Google Talk/Google Voice channel driver, and we plan to support Jingle over WebSocket as well. At this point, we don’t have a quite complete solution (a new Canary build of the Google Chrome browser is needed with a few small changes), but each of the pieces has been tested and we’re anxious to see it all work together. We’d like to thank Iñaki and José from the SIP-on-the-Web project for providing us their JavaScript SIP stack to use during our testing, and we’ll probably be testing with the PhonoSDK as well for Jingle support."

Matt Jordan
  • 2,899
  • 1
  • 27
  • 29
2

This seems a nice guide

Remote call-center solution using Node.js

loganfsmyth
  • 156,129
  • 30
  • 331
  • 251
almypal
  • 6,612
  • 4
  • 25
  • 25
  • Thanks for posting, but I have seen that already. It doesn't go into the browser streaming side, it just uses Phono, which is flash-based. – Jonathan Feb 08 '12 at 18:23
1

I've built a similar solution here. In this post I'm talking a little about it: http://www.igorescobar.com/blog/2014/08/13/working-with-asterisk-and-node-js/

I built a call center solution using Node.js (Express/Socket.io), Javascript, HTML5 and CSS3.

Igor Escobar
  • 1,047
  • 1
  • 12
  • 13
0

I think trying to stream an audio file while it is being recorded will have extreme latency issues that you will not be able to get around. If you want to get real-time listening to a phone conversation I would suggest looking into Phono. It is a JQuery plugin that turns your web browser into a phone. Then you would just have the listener conferenced in to the conversation with it on mute.

Kevin Junghans
  • 17,475
  • 4
  • 45
  • 62
  • I have seen Phono before. It looks nice, but, as I understand it: you have to use the Phono service and the plugin is actually using flash. I don't need to access the user's mic, which is why I believe they are using flash, so streaming to the audio tag, if possible, seems like it would work. – Jonathan Feb 08 '12 at 16:28
  • Streaming may work if you can accept the latency issues. It will never be real-time. I believe you need a communications channel open for real-time listening. You may want to look into other browser based SIP phones like this one [http://www.mizu-voip.com/Products/WebPhone.aspx]. – Kevin Junghans Feb 08 '12 at 18:01
  • If I can access sockets in the browser, why can't I implement a sudo-sip client using a direct socket to the server? I am sure that is not a trivial task, but, I wonder if it is possible? – Jonathan Feb 08 '12 at 18:13
  • Websockets won't work to do it: `NOTE: This interface does not allow for raw access to the underlying network. For example, this interface could not be used to implement an IRC client without proxying messages through a custom server.` a la http://dev.w3.org/html5/websockets/ – Jonathan Feb 08 '12 at 18:22
  • 1
    This note does not preclude websockets. It just means that you would have to develop the "custom server" that would act as the middleware. The problem with websockets is that is a very new standard and not implemented in all web servers. The next release of IIS will have websocket support. Or you can use a service like Pusher [http://pusher.com/]. You are correct; putting a SIP stack on would not be trivial. I would start with one of the open source SIP implementations. – Kevin Junghans Feb 08 '12 at 19:04
  • Agreed. If you see the edit on my question, I posted a link to a presentation someone put together regarding this idea. Also, I found a similar implementation on Github. Will add it to the question too. – Jonathan Feb 08 '12 at 20:02
0

If you don't mind the latency (caused by buffering of the Icecast stream), Asterisk is able to stream to Icecast (configure Asterisk's Ices application).

If you can't tolerate the latency, you'll need a browser-based SIP client. Unfortunately, there's not many of them that aren't locked to someone else's phone system. You might try red5phone (http://code.google.com/p/red5phone/) but that requires that you set up a Red5 server.

joat
  • 129
  • 6