Tzafrir has committed some documentation to his branch for RTP Monitoring:

Asterisk RTP Monitoring

This document describes using the Monitoring To RTP feature of Asterisk. Note that this feature is still work in progress.

"RTP Monitoring" adds an extra backend to the current Monitor (recording) code: rather than recoding calls to files, send them as RTP streams over the network to a resording server. The RTP streams are proided with extra meta-data through dummy SIP INVITE (at the beginning) and BYE (in the end of the call) messages.

Usage

RTP monitoring is configured through monitor.conf (a file currently only used for this feature). See a sample/reference file in the configs directory.

In order for recording to work, 'rtp_server' under [general]' must be set. Set it to the server to which you wish to send recordings.

In order for calls to be recorded you also need to:

1. Set the channel to be monitored. Use one of the following:

- An explicit Monitor(wav) in the dialplan. Note that the value used here ('wav') will actually be ignored.
- Set(AUTO_MONITOR=wav) in the dialplan. As before, the actual value will be ignored.
- setvar = AUTO_MONITOR=wav in the channel configuration (sip.conf, iax.conf, chan_dahdi.conf, maybe others).

2. (If not a DAHDI channel) set a unique port offset in the variable RTP_PORT_OFFSET . This should be unique for the run-time.

The requirement for RTP_PORT_OFFSET is ugly and should hopefully be removed soon.

There are two RTP streams per recorded channel (one for rx and one for tx). At the moment the rx stream is sent to port 9000+RTP_PORT_OFFSET and the tx stream is sent to port 11000+RTP_PORT_OFFSET (the numbers 9000 and 11000 can be modified in monitor.conf).

Oreka / Orecx

Support for recording the produced streams of this plugin has been added in recent SVN versions (try using at least rev. 641) of orkaudio. In order to use it, add the following line inside the tag in /etc/orkaudio/config.xml

<DahdiIntercept>yes</DahdiIntercept>

I hope it will be renamed to something along the lines of 'AsteriskIntercept' as the code should not have anything DAHDI-specific.

Wireshark

The generated streams can be shown in wireshark. Either capture in it directly or capture in tcpdump:

tcpdump -s 0 -w recordings.cap #add custom filter here

In Wireshark use Statistics => RTP => Show All Streams

This opens a window in which each stream is shown (there are two such streams per recorded channel).

Testing

The following can be used to generate a call without any other channels about in the system:

In extensions.conf:

[rtp-monitor]
exten => genrec,1,Answer
exten => genrec,n,Set(AUTO_MONITOR=wav)
exten => genrec,n,Set(RTP_PORT_OFFSET=23)
exten => genrec,n,Dial(Local/answer-rec@rtp-monitor/n)
exten => genrec,n,Hangup

exten => answer-rec,1,Answer
exten => answer-rec,n,Set(AUTO_MONITOR=wav)
exten => answer-rec,n,Set(RTP_PORT_OFFSET=29)
exten => answer-rec,n,Playback(demo-thanks)
exten => answer-rec,n,Hangup

And now generate a call with:

asterisk -rx 'channel originate Local/genrec@rtp-monitor/n application Echo'

Bugs

Many. Did I mention work in progress?

• The fact that you have to set RTP_PORT_OFFSET for channels.

• It takes restarting Asterisk or so to re-read monitor.conf.

• Starting a monitoring with Monitor() can crash Asterisk. Didn't look into it yet.

• In a normal Hangup, the channel's CDR gets destroyed before the channel's monitors are destroyed. Which means that the CDR data is not availalable when we send the BYE. This was not the case in 1.4. There is an ugly and very partial workaround in the code for that.

Comments (Click to post)

Name:
Subject:
Website:
Message: