Best Way Of Active Calls / Live Calls Monitoring

Dear,
Experts, I am a bit confused about the Active Calls / Live Calls Monitoring System of Asterisk, I saw & worked in many ways in my first project I make AGI & updates it in a database, 2nd I did shell scripts 3rd I have done by PHP AMI, which is best practice or a good way to get information about live calls in asterisk

I need this info for the live calls

Search:

Called Number || CallerID || Originator ID || Originator IP || Terminator IP || Trunk ID || Codec || Duration || Status

Please help me with your important feedback & experience. Thank you in advance.

I believe the best way to get the live information, would be to listen for events using AMI, using those events to update a datastore (SQL DB, MongoDB, Redis cache etc) whenever a new event is received.

Then using the stored data to create whatever display you’d like.

If you just want the call data when the call ends, you can use CDR records generated by Asterisk. These can be stored by Asterisk directly in a database supported by ODBC on the Asterisk server.

Another option for live call status viewing / Heads Up Display modes…

When admin viewer is logged in to your website, start up a websocket-via-PJSIP connection to Asterisk using client-side in-browser Javascript by way of WebRTC toolkits like sipML5 or jsSIP, and then push interesting things to the client from the PBX server using MessageSend() application.

PROs:

  • Only active when admin is viewing.
  • No database event store required.
  • More fine-grained control over what info you push to client.
  • Extends to general dialing tool for browser-based calls.
  • Avoids overhead of AMI.

CONs:

  • Securing connections can be hard to get right.
  • New frameworks to learn.
  • Silo’d development potential - not compatible with more generic interfaces.
1 Like

What exactly is the “admin viewer” in this setup?

If you want to know about line status, I assume subscribing to them on the client side would be a lot easier, as it would use the features built-in to Asterisk already, most SIP libraries should support the SUBSCRIBE method anyways.

If you want “random” browsers to register on Asterisk, as SIP users that are not actual phone users, it’s certainly a way to go. However, restricting them from doing anything, and not accidentally opening up for calls when changing the dialplan, will just be an extra QA step for eternity.

In my opinion, a web application that is NOT a softphone, should NEVER have direct access to Asterisk. But you could, of cause, create your middleware using WEBRTC instead of AMI, however, since the clients does NOT connect to Asterisk directly, the overhead of AMI is almost nothing. You just have a single persistent connection between your middleware and Asterisk, listening for interesting events.

Good question. Per OP:

…so whomever is looking at that info could be considered some level of “admin viewer”. Maybe “ops viewer” is better term…

Good point. Audio streams are not exactly part of OP – although the second half of the title “/ Live Calls Monitoring” was a little muddling. Unless there is need to patch in the audio eg. ChanSpy() style, then WEBRTC soft phone is probably too much stuff.

Besides AMI, another extremely loosely coupled approach is with CEL into database backend, which can provide all but one of the OP’s requested columns (the exception being Duration which can be calculated on-the-fly from the most recent CEL record on the call.)

Also a PRO for CEL would be the ability to add a “temporal rewind” feature – probably more easily than AMI – to let the “ops viewer” look at what the Active Calls were at some point in the past.

Try a look at ARI as well.

1 Like

If you store the history of events received through AMI, wouldn’t you be able to do the same when? As far as I’ve understood CEL it’s just the same events AMI throws out, reformatted, and sent to another location.

And for call duration, you can just use CDR records you write to a database, if you can’t be bothered calculating it yourself. :wink:

As for ARI isn’t that mainly for interacting with the call from an external application?

Either way, you would still not want your webapplication to connect directly to Asterisk from the client browser, some sort of middleware should be put in between to filter the requests and responses for sensitive information.

You can send CEL (or CDR) output to AMI.

Another distinction is that CEL (and CDR) are read-only, but AMI (and ARI) can be read/write.

Also CEL (and CDR) provide multiple different database backends in stock Asterisk, but AMI (and ARI) need third-party applications to persist data.

Agreed, in layers.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.