Troubleshooting R2
- Nathaniel Halbrooks
- Kelli Higdon
Â
Â
Line Signals
For the digital version of MFC/R2 (defined in ITU-T Q.421), the digital line signals are the ABCD bits of the channel associated signaling (CAS) in timeslot 16 of an E1.Â
They represent the states of the line, and are similar to the states of an analog line. In general, only bits A and B are used. In most systems bits C and D are set to fixed values, and never change. There are some national variants where bit C or D may be used for metering pulses.
Â
Table 1.1. Forward line signals CAS bitMeaningValuesALine status1=on hook, 0=off hookBCondition1=failure, 0=normalCFixedAlways 0DFixedAlways 1 | Table 1.2. Backward line signals CAS bitMeaningValuesALine status1=on hook, 0=off hookBCondition1=seized, 0=idleCFixedAlways 0DFixedAlways 1 |   |
Â
Â
Circuit States
Below is a table describing the bit patterns and related state changes used in R2 signalling via the CAS AB bits.
Table 2 : CAS AB bits and corresponding circuit states (source: ITU-T Q.421/Table 1)
Circuit State | Forward Signal | Backward Signal |
Idle/Released | 10 | 10 |
Seize | 00 | 10 |
Seizure Acknowledged | 00 | 11 |
Answer | 00 | 01 |
Clear Back | 00 | 11 |
Clear Forward (before clear back) | 10 | 01 |
Clear Forward (after clear back) | 10 | 11 |
Blocked | 10 | 11 |
Â
 NOTES*
As you move vertically down the table columns the exclusive change of a single AB value on either the caller's or callee's end indicates transition to a new state.
The table indicates that a circuit state change occurs when the codeword from either the Forward or Backward device changes one of its AB bits.
An important note is that once in an idle state you can either transition to a seized state (indicative of a call taking place) or to a blocked state.
Actual binary values transmitted will be AB * 4 + 1 (since CD = 01 always in the nibble)
Â
Basic Call Flow
The following call scenario is based on examples in the ITU specification. This scenario demonstrates a call where the called party answers and releases the call.Â
Â
Caller Switch A [MFC/R2 signaling] Switch B Called party
<------------ Idle [0x08]-------->
 --- Off-hook --------->
<======== Dial tone ===
--- Digits ----------->
<========== Silence ===
 --- Seize [0x01]----------------->
<------------- Seize ack [0x0C]---
 --- Dialed digit 1 (I-x) -------->
<--------------- Get N+1 (A-1) ---
--- Dialed digit 2 (I-x) -------->
......
<--------------- Get N+1 (A-1) ---
--- Last dialed digit (I-x) ---->
<------ Address complete (A-3) ---
--- User w/o priority (II-1) ---->
<---- User free, charge (B-6) ---
 <========================================== Ringback tone === --- Ring signal ------->
<---------- Off-hook ---
 <---------------- Answer [0x05]---
 <====================================== Speech =========================================>
<----------- On-hook ---
<------------ Clear Back [0x0C]---
<=== Silence or tone === --- Clear forward [0x09]--------->
--- On-hook ----------->
<------------ Idle [0x08]--------> |
(source:Â Where are the signals and supervisory tones generated, and how are they used? )
NOTES*Â
In the call flow diagram above there is no transfer of the caller ID.
Around the world things may vary quite a bit from this call scenario. For example, the busy tone is shown as being generated from the caller's local switch. In some systems it is generated from the called party's local switch. The signals used for various purposes are often different. The signaling between the switches and the telephones could be by DTMF or pulse dialling on an analogue pair (FXO/FXS signalling). It could be ISDN signalling, over a BRI connection. It could be a VoIP connection. The actual signals passing between the switches and the telephone will be similar in most cases, and details do not affect the overall discussion of how MFC/R2 works.
WANPIPE: Debugging call sequences and events
First open a terminal and follow the kernel messages being printed
tail -f /var/log/messages |
Â
Tell wanpipe to print a D-channel snapshot to the kernel (do this in a separate window so you can keep an eye on kernel messages)
wanpipemon -i wg1g1 -c dpr |
Â
You will notice in your kernel messages window that you get the output
This is a snapshot of a single E1, D-channel frame which shows the ABCD bits for all channels. Â
This output is not extremely useful since it only shows us the current state of all channels at one point in time. Â
We are more interested in the change in a given channel's ABCD bits over time. Changes in the CAS bits indicate circuit state changes as shown in Table 1 above. Â
It is however good to note from this output that both the Forward and Backward machines are transmitting the value AB = 10 which tells us that both ends if the circuit are in an idle state.
Enable RBS bit change messaging for Received (Rx) and Transmitted (Tx) bits
Â
Try making an inbound call to the PBX of interest
The asterisk CLI will display the following in response to this incoming call:
Â
The kernel messages window should output something like the following (note that all activity takes place on channel 3):
Step by step, using Table 1 we can interpret the circuit state changes as follows:
NOTE*Â here we interpret the messages from RX and TX as the messages that our PBX system receives and transmits respectively (i.e. in this case RX is the Forward machine and TX is the Backward).
RX: AB = 00 | Call seized by Forward (i.e. the caller / system that's calling us) |
TX : AB = 11 | Seizure acknowledged by Backward (i.e. the callee / system being called into) |
TX: AB = 01 | Call is answered by Backward |
Â
Hangup the call from the caller end
The asterisk CLI will display the following in response to the hangup:
Â
The kernel messages window should output:
Â
Step by step, we can again use Table 1 to interpret the circuit state changes as follows:
RX: AB = 10 | Clear Forward (before clear back) by Forward, since the Backward machine was previously transmitting AB = 01 |
TX : AB = 10 | Idle by Backward |
Â
Now our link has returned to the idle state where it will stay until a new call is initiated on the line.Â
Â
Asterisk:Â OpenR2 Debugging
Check Variants
To see a list of supported MFC-R2 variants you can execute the following command from a linux shell:
Â
Inside the Asterisk CLI you can use:
Â
Monitoring Commands
To show all active channels and their present circuit state, use the following asterisk command:
Chan  Variant Max ANI Max DNIS ANI First Immediate Accept Tx CAS  Rx CAS |
*NOTE: a useful method to monitor the circuit states in real time is by issuing a watch on the above command from Linux shell:
Â
Debugging with the Asterisk CLI
You can enable OpenR2 debug messages in the asterisk CLI with the command shown below. This example demonstrates the transmission of a DNIS.
 DEBUG[7630]: chan_dahdi.c:2011 dahdi_r2_write_log: Chan 1 - Requested to make call (ANI=4579382070, DNIS=045542814540, category=National Subscriber) |
Â
Enable Call Sequence Logging
Â
To enable extremely detailed R2 signal logging place something similar to the following in your  /etc/asterisk/chan_dahdi.conf file.
Using these settings all call logs will be located in: var/log/asterisk/mfcr2/span1
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.