MFCR2 Configuration

Asterisk Configuration

A good way to start the configuration of an R2 system for use with Asterisk is to run the normal Sangoma configuration script

In the interactive prompt select E&M wink as the switch type.  This will set the appropriate settings in /etc/wanpipe/wanpipe1.conf  for out of the box use.

Example Dahdi Config File Snippets

The following snippet show examples of the two Dahdi configuration files which must be manually created to use OpenR2 with Asterisk.  
All the parameters listed below are further explained in the next section of this page.  Full A102 sample config files can be found in the quick-configuration section.

Example chan_dahdi.conf

Example dahdi/system.conf

Configure chan_dahdi.conf

Below is a detailed explanation of all the settings which can be configured through the use of the /etc/asterisk/chan_dahdi.conf file. 
All of this information has been taken from the default chan_dahdi.conf sample file that comes with any asterisk source install of which the verbatim snippet is linked to above.

 An example /etc/asterisk/chan_dahdi.conf file is shown here:

Mandatory parameters in chan_dahdi.conf include:

mfcr2_variant
mfcr2_max_ani 
mfcr2_max_dnis

IT IS RECOMMENDED that you leave the default values (leaving it commented with ';') for the other parameters unless you have problems or you have been instructed to change some parameter. 
OpenR2 library uses the mfcr2_variant parameter to try to determine the best defaults for your country, also refer to the OpenR2 package directory doc/asterisk/ where you can find sample configurations for some countries. 
If you want to contribute your configs for a particular country send them to the e-mail of the primary OpenR2 developer that you can find in the AUTHORS file of the OpenR2 package. 

MFC/R2 variant

This depends on the OpenR2 supported variants.  A list of values can be found by executing the openr2 command r2test -l
Some valid values are: 
ar (Argentina) 
br (Brazil) 
mx (Mexico)
ph (Philippines)
itu (per ITU spec)

Max ANI

Max DNIS

Get ANI before DNIS

Determine whether or not to get the ANI before getting DNIS.  Some telcos require ANI first some others do not care.

Caller Category to send

Possible values include:
national_subscriber
national_priority_subscriber
international_subscriber
international_priority_subscriber
collect_call

Usually national_subscriber works just fine.  You can also change this setting from the dialplan by setting the variable MFCR2_CATEGORY (remember to set _MFCR2_CATEGORY from originating channels).
MFCR2_CATEGORY will also be a variable available in your context on incoming calls set to the value received from the far end.

Call logging directory

Logging is stored at the Asterisk logging directory specified in asterisk.conf plus mfcr2/<whatever you put here>. 
If you specify 'span1' here and asterisk.conf has as logging directory /var/log/asterisk then the full path to your MFC/R2 call logs will be /var/log/asterisk/mfcr2/span1 (the directory will be automatically created if not present already)
This logging can be enabled with:

Call logging enable

Determine whether or not to drop call files into mfcr2_logdir (as mentioned above):

Log levels

all,error,warning,debug,notice,cas,mf,stack,nothing 

error,warning,debug and notice are self-descriptive, cas is for logging ABCD CAS tx and rx.  mf is for logging of the Multi Frequency tones.
stack is for very verbose output of the channel and context call stack, which is only useful if you are debugging a crash or want to learn how the library works. 
The stack logging will be only enabled if the openr2 library was compiled with -DOR2_TRACE_STACKS.  
You can mix up values like

to log just errors, debug and multi frequency messages.  all is a special value to log all the activity.
nothing is a clean-up value in case you don't want to log any activity for a channel or group of channels.
BE AWARE that the level of output logged will ALSO depend on the value you have in logger.conf.  
If you disable output in logger.conf then it does not matter you specify all here; nothing will be logged, so logger.conf has the last word on what is going to be logged.

MF timeout in milliseconds

MFC/R2 value in milliseconds for the MF timeout. 
Any negative value means 'default', smaller values than 500ms are not recommended and can cause malfunctioning. 
If you experience protocol error due to MF timeout try incrementing this value in 500ms steps 

Metering pulse time out

Metering pulses are sent by some telcos for some R2 variants during a call presumably for billing purposes to indicate costs, however this pulses use the same signal that is used to indicate call hangup.  
Therefore a timeout is sometimes required to distinguish between a "real" hangup and a billing pulse that should not last more than 500ms.  
If you experience call drops some minutes after being established, try setting a value of some ms here. Values greater than 500ms are not recommended. 
BE AWARE that choosing the proper protocol mfcr2_variant parameter implicitly sets a good recommended value for this timer.  
Use this parameter only when you *really* want to override the default, otherwise just comment out this value or put a -1. 
Any negative value means 'default'.

Brazil special calling party category for collect calls (llamadas por cobrar)

Instead of using the operator (as in Mexico). The R2 spec in Brazil says a special GB tone should be used to reject collect calls. 
If you want to ALLOW collect calls specify 'yes', if you want to BLOCK collect calls then say 'no'. Default is to block collect calls (see also 'mfcr2_double_answer').

Immediate accept

This feature allows to skip the use of Group B/II signals and go directly to the accepted state for incoming calls.

Accept on offer

You most likely dont need this feature. Default is yes. 
When this is set to yes, all calls that are offered (incoming calls) for which DNIS is valid (exists in extensions.conf) and also pass collect call validation will be accepted with a Group B tone (either call with charge or not, depending on mfcr2_charge_calls).
With this set to 'no' then the call will NOT be accepted on offered and the call will start its execution in extensions.conf without being accepted until the channel is answered (either with Answer() or any other application resulting in the channel being answered).
This can be set to 'no' if your telco or PBX needs the hangup cause to be set accurately.  
When this option is set to 'no' you must explicitly accept the call with DAHDIAcceptR2Call or implicitly through the Answer() application.

Skip request of calling party category and ANI

You need openr2 >= 1.2.0 to use this feature

Enable Tone Definitions File

WARNING: advanced users only as it allows you custom define tone definitions used in the protocol! 
This parameter is commented by default because YOU DON'T NEED IT UNLESS YOU REALLY UNDERSTAND MFC/R2! 
READ COMMENTS on doc/r2proto.conf in the openr2 package for more info.

Brazil hangup

Brazil use a special signal to force the release of the line (hangup) from the backward perspective. 
When mfcr2_forced_release=no, the normal clear back signal will be sent on hangup, which is OK for most mfcr2 variants except for the Brazilian variant where the central will leave the line up for several seconds (30, 60).  
This is sometimes is not what people really want. When mfcr2_forced_release=yes, a different ; signal will be sent to hangup the call indicating that the line should be released immediately.

Toggle 'report accept call with charge'

Whether or not report to the other end 'accept call with charge'.  This setting has no effect with most telcos and is usually is safe.  
Leave the default (yes), but once in a while when interconnecting with old PBXs this may be useful. 
Concretely this affects the Group B signal used to accept calls.   
The application DAHDIAcceptR2Call can also be used to decide this in the dial plan in a per-call basis instead of doing it here for all calls. 

Configure /etc/dahdi/system.conf

Configuring a span for use with OpenR2 must be done in the /etc/dahdi/system.conf file using the span parameter.

An example dahdi/system.conf is shown here:

Lines 1 (span) and 2 (cas) are the most important as they are uniquely specified for an R2 signalling application.

The span parameter is composed of the following elements:

NOTE*: For the purposes of R2 lines, feel free to ignore anything beyond the <coding> value.

Refers to an integer number that represents the span number. In our example we were configuring span 1.

Refers to an integer that determines if the far end (whatever you have connected on the other side) will provide
the clock signal and if it will be used as the master source of clock timing. If you are connected to the PSTN (your telco)
most likely you need to set this to a number greater than 0, depending on how many spans you have. For example,
if you have 2 spans connected to the PSTN one of those spans should be set with <timing source> to 1 and the 
other to 2, marking them as the first master clock source and second master clock source respectively. If you have the
span connected to some legacy PBX, probably the legacy PBX expects to receive clocking from the PSTN, but since 
is not connected to the PSTN but to your box, you must provide clock to the PBX, in this case you set this value to 0.

This example states that span 1 will provide the clock to whatever is connected to the other end. Be aware that
the dahdi/system.conf sample file clearly states that incorrect timing sync may cause clicks/noise in the
audio, poor quality or failed faxes and unreliable modem operation among other nasty issues.

This is an integer between 0 and 7 which determines the transmission level of the span.  
You can choose that value depending on the table provided in the sample DAHDI configuration file:

These determine low level signaling and formatting of E1 frames. 
For the sake of R2 signaling you will use CAS and hdb3 respectively.

After configuring the span parameter we need to configure each channel of the span with the proper signaling.
To do this we set the cas parameter.  
Normally, the CAS span will have all of its channels with CAS signaling (also known as user signaling).

This snippet states that the range of channels from x to y (integer values) will report CAS bits. The :1101 is the initial position
of the CAS bits (also known as ABCD bits) which are used by R2 to signal line state (see the R2 troubleshooting section for details). 
The 1101 signal means “Blocked” in R2, which means that when the hardware wakes
up for the first time it is not able to receive calls (Asterisk or any other software using R2 will later
change this bits to 1001, which means IDLE, or ready to make calls).

This parameter has been a bit controversial since some people do not set it while others
do. The channel 16 (probably better said, timeslot 16) is used to carry the multiplexed CAS bits
for the other E1 channels. In our experience the bits are well received whether or not you set
dchan=16, but setting it helps to clear any previous signaling the channel could have been on. I
recommend setting it unless you have problems when executing “dahdi_cfg”. Some versions of
ztcfg will not accept a CAS span with dchan=16 and will refuse to configure the channels, just
remove that parameter to fix it.

Wanpipe Configuration

As shown in the quick-configuration section a good way to start the configuration of an R2 system for use with Asterisk is to run the normal Sangoma configuration script:

In the interactive prompt select E&M wink as the switch type.  This will set the appropriate settings in /etc/wanpipe/wanpipe1.conf.
The most important setting are the following:

Example wanpipe Config File