Recording

From Bizfon Wiki

The PBX 2.0 supports several ways of recording calls:

• It is able to record selected calls to the file system. Those files are recorded in compress format using the GSM codec at 13.2 kbit/s (approximately 100 KB per minute).
• Alternatively, calls can be sent to a real-time recording station. This is done using a standard SIP call. By using the SIP standard, the PBX can be connected to a large number of recording devices, including soft phones for listening in or recording solutions that support SIP.
• The user may also initiate a recording by pressing the record button on the phone.

The user-initiated recording, which was supported in the 1.x version, does currently not support the sending if the WAV file. Because such files can get large, we are currently investigating alternative ways of providing recording information.

In order to control the location for the recording, check out the setting "Record Location" in the system administrator menu.

Recording to File

When recording to a file, the PBX needs to know the location where to place the file. The WAV file itself contains only the recorded conversation; there is no ancillary information (caller-ID, IP-Addresses etc.) embedded in the WAV file. However, by using variables in the recording file name, you may provide information:

• "$r" is replaced with the recording directory, which is "recordings". This directory is relative to the working directory of the PBX. This directory also contains other recordings, for example mailbox messages. If you use another directory, you must first create that directory before using it. The directory path must always be relative to the working directory of the PBX.
• "$i" is used to indicate the direction of the call. The PBX substitutes an "i" for incoming calls, and a "o" for outgoing calls.
• "$u" is being replaces with the canonical (primary) name of the extension. Depending on the direction of the call, this could be calling or called party number. Details explained below.
• "$n" is replaced with the calling party number. Depending on the direction of the call, this could be calling or called party number. Details explained below.
• "$m" is replaced with the domain name.
• "$d" is replaced with the date of the call in the format "20071220" (no spaces or dashes in between).
• "$t" is replaced with the time if the call in the format "134349" (no spaces or dashes in between).
• "$$" is replaced with a single "$" symbol.

The default recording name is "$r/$d/$t-$i-$u-$n.wav". If the directory that results from the replacement does not exist, the PBX will automatically generate it. This makes it possible to sort the recordings into directories for every day. If you are running multiple domains, then you can use "$r/$m/$d/$t-$i-$u-$n.wav" as the recording name. This will create the recorded files under each domain name.

Explanation for $u and $n

Let's try to explain the behavior of $u and $n at the domain level 'recording' settings. The 'record location' is set to "$r/$d/$t-$i-$u-$n.wav". The recorded files will be created under <pbx-install-dir>/recordings/<date> directory.

Let's use 2 extensions(601 and 604) for this purpose.

Case 1: When "Incoming calls from extension" is set to "yes"

• 601 calling 604 produces 095404-i-604-601.wav

File:In rec.gif

Case 2: “Outgoing calls to internal numbers” is set to "yes"

• 601 calling 604 produces 102019-o-601-604.wav

File:Out rec.gif

As you can see in Case 1, $u output represented called party and $n the calling party. But in the Case 2, $u output represented calling party and $n the called party.

Recording to a SIP URI

When you specify a recording name with a sip scheme (e.g. "sip:record@192.168.1.2"), the PBX will initiate a call to that location. The other side of the call can either accept the call or it can send an error code if it does not wish to record this call. In this case, the associated resources for the recording call are released.

If the call connects, the PBX will encode the data in the selected codec type. Please be aware that in any case, the PBX must decode the monitored media streams, because otherwise it would not be able to mix the two streams together. This might mean a significant increase in CPU load that you should keep in mind.