[Asterisk-Dev] Using Asterisk to record calls NOT passing through Asterisk

[Benjamin on Asterisk Mailing Lists]

On Sun, 12 Sep 2004 15:11:24 +0200, Andreas Sikkema <h323 at ramdyne.nl> wrote:
> Hmm, so you'd effectively be developing the Ethereal SIP support all
> over again (and large chunks of Ethereal itself)? I'd put the money in
> improving (in some way) the codec support in Ethereal.

Thanks for mentioning this.

However, does Ethereal have the capability to record all SIP calls
between a SIP softswitch (specified by IP address) and any SIP phone
in a local LAN (specified by network address) on a 24/7 basis, then
keep all those calls organised by SIP phone and date alongside CDRs
(to be matched up with the CDRs from the softswitch)?

And if it does that, then how much of a configure and forget stand-by
server solution is this? It would seem to me that Ethereal is more of
an interactive tool that you use when you want to check something out,
but not necessarily as a server running all the time in the background
with all the management infrastructure a server solution should have.

> Asterisk is a PBX, not a packet sniffer

Read the source code. Every single file starts with "Asterisk -- A
telephony toolkit for Linux".

So, all I am suggesting is to use Asterisk as a *toolkit*. If Ethereal
has already got the low level stuff to capture SIP traffic
selectively, all the better. That means, it will be less work to write
a module for Asterisk because it could use Ethereal services to
capture the data.

The benefit is that Asterisk provides the management framework that a
24/7 capturing system will require. Let me give you some examples.

- the Asterisk console would show what streams are being recorded
- Asterisk would be able to generate CDRs for all the recorded calls
- Asterisk could provide the means to listen to the recorded calls
using a phone that dials in to the Asterisk server, provide a PIN
number and call reference via DTMF, then listen to the call.

Finally, there is the marketing aspect.

Let's assume we get the job and the customer will sponsor the work to
tweak Ethereal into doing what they want to do including the above
management functions. It will be an Ethereal based solution which will
be considered a clutch because Ethereal is known as a system admin
tool.

On the other hand, if we have a module for Asterisk that does the job,
even if it ultimately uses Ethereal for the capturing of data, then it
will be an open source telephony solution which will be considered a
proper tool for the job even if the fact that it is open source will
raise eybrows here and there.

But that is precisely what we want, isn't it?! We want people to talk
about Asterisk. We want those IT decision makers to tell other IT
decision makers "We are using Asterisk for call logging and we do that
in a way that it is not part of the communications path". We want
those other IT decision makers to reply "Uh, I didn't realise Asterisk
could do that, I thought it was just a PBX".

The more we get Asterisk out there and people talk about it, the more
likely we will eventually be in the position to snatch deployment jobs
from the likes of Avaya and Cisco.

Mind you, this is how Unix made its way into the data centre. I
remember very well when Unix was considered a toy system, unproven and
untrusted. It was the small things that nobody wanted to spend a lot
of money on that Unix was allowed to handle and gradually the decision
makers felt comfortable with Unix until finally it replaced the
mainframe OSes of the time.

It shall be no different with Asterisk and other open source telephony
platforms.

Thus, the question remains ... Who would be interested in writing a
module for Asterisk that does the job and integrates with other
services provided by Asterisk, how much time and effort would that be?
Using the above mentioned services built in to Ethereal would of
course be OK.

-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.