虽然R2有许多不足，面临淘汰，但由于过去的广泛应用，现在我们仍然经常会在与其他厂家PBX的互通中用到，把本人实际的应用结合公司相关学习资料在这里做一个简单的小结，有不足的地方还请各位指点。
 
一、           常见故障现象
2.1 现象一：通过R2可以打通电话，但每次通话每隔一个固定的时间段（如1分钟或半分钟分钟就会断）。
分析：时钟或者线路问题，确认时钟没有问题后，可以尝试重新连接E1线路、重做BNC头或者更换线缆（板卡）。
 
2.2 现象二：M6000走R2信令，打电话不稳定，有时通有时不通。
分析：通常是没有设置外时钟，添加即可。
 
二、 R2 debug 应用示例
2.1 记发器信令（debug r2 mfc）原理及应用
 可以通过debug r2 mfc信息判断R2在一次正常的通话过程中的主叫号码和被叫号码，如主叫8924拨打被叫8930：
下面是网关做被叫时的正常debug r2 mfc信息，VG2000与VGM6000走R2时记发器信令交互的一个示例：
Debug  R2 mfc
Tx:(E1[0] ts[5])  0 x 9 x 3 x 3 x 1 x 0 x 0 x 2
                                      被叫号码                                
                         x 1 x 0 x 9 x 3 x 2 x 1 x 0 x 0 x 2 x F x 3 x
                          KA          主叫号码   号码全 KD
Rx:(E1[0] ts[5])  1 x 1 x 1 x 1 x 1 x 1 x 1 x 6 x 1 x 1 x
                        发KA和主叫号码
                           1 x 1 x 1 x 1 x 1 x 1 x 1 x   3     x     1     x
                                                  转至B信道   示闲                                             
详解：vg2000做主叫时先发出被叫号码，每发出一位都会收到对端程控交换机回应的后向信令1，表示已经收到前向信令，准备接收下一位。对端程控交换机会判断是否已经收齐被叫号码，如果收到了最后一位，就回应后向信令6表示要求对方发送主叫号码。然后，vg2000开始一位一位发出主叫号码，同样程控会每收到一位就回应后向1，vg2000发完主叫号码后，再发出前向f，表示送完主叫，后向3表示转到B信令。后向信令具体含义可参见此表：
A 组信号
A 组信号内容
1
2
3
4
5
6
A1 ：发下一位
A2 ：由第一位发起
A3 ：转至 B 信道
A4 ：机键拥塞
A5 ：空号
A6 ：发 KA 和主叫用户号码
    由此可以判断上面debug信息的被叫号码是8930，主叫号码是8924。
对 R2 的继发器信令交互过程清楚了，我们就可以从交互过程中出现的异常信息来判断一些故障了：
Debug R2 mfc应用示例：
例一：通过r2打pbx的电话送6XXX的号码在送了第1位号码后回复了5的代码，这个表示是空号的意思，那么就要在pbx上面确认的规则看是否能识别6开头的被叫；
 
例二：客户的M6000接PBX走R2信令，现在从M6000到PBX打不通，收集了debug r2 mfc，发现我们发送了一位被叫号码后对方要求送主叫，送完主叫对方PBX就回信令“ 3” ，表示收号结束，所以PBX实际上只收了一位被叫号码，当然不通了，那么就可以让客户检查PBX的配置，不是我们M6000的问题。
 
例三：debug看号码送了4位后对方从R2回来一个“3”收号结束，后面就回“4”了表示拥塞，就可让PBX方去处理了。
 
例四：Tx:(E1[0] ts[6])  0x 9 x3 x 3 x 1x  0x 0 x 2 x F x 3 x
Rx:(E1[0] ts[6])  1 x 1 x 1 x 1 x 1 x 1 x 1 x 6 x  3 x 1 x
受话端要求发送主叫信息而发话端不具备发送能力的情况
Tx:(E1[0] ts[7])  0 x 9 x 3 x 3 x 1 x 0 x 0 x 2 x 3 x
Rx:(E1[0] ts[7])  1 x 1 x 1 x 1 x 1 x 1 x 1 x 3 x 1 x
发话端具备发送主叫信息能力而受话端不要求发送的情况
 
 
2.2 线路信令（debug r2 all）原理及应用
  Debug r2 all主要用来查看线路信令交互的过程，如下例中红色部分所示，从PBX往Vg2000打
2d19h: VM ==> R2: 0x3    (E1[0]  ts[20])           //PBX占用通道20
2d19h: R2_BW_begin     event: LINE_SIG  state: IDLE
2d19h: R2 ==> MSP: open MFC    (E1[0] ts[20])
2d19h: R2_BW_end       event: LINE_SIG  state: IDLE ==> ASSIGN_MFC
 
2d19h: MSP ==> R2: Open MFC success    (E1[0] ts[20])
2d19h: R2_BW_begin     event: OPEN_MFC_SUCC  state: ASSIGN_MFC
2d19h: R2 ==> VM: 0xf    (E1[0]  ts[20])          //VG2000回复占用确认
2d19h: R2_BW_end       event: OPEN_MFC_SUCC  state: ASSIGN_MFC ==> MFC
 
2d19h: MSP ==> R2: BW regSig    (E1[0] ts[20])
2d19h: code = 0x39  '9'                           //开始发送号码，同debug r2 mfc
2d19h: R2_BW_begin     event: RECV_FORWARD  state: MFC
2d19h: R2_BW: (E1[0] ts[20]) receive called number not over!
 
2d19h: R2 ==> MSP: BW regSig    (E1[0] ts[20])
2d19h: code = 0x31  '1'                           //后向信号，请求发下一位，同debug r2 mfc
2d19h: R2_BW_end       event: RECV_FORWARD  state: MFC ==> MFC
 
2d19h: MSP ==> R2: BW regSig    (E1[0] ts[20])  
2d19h: code = 0xff  'silence'                     // R2信令中要求的信令间的间隔停顿
2d19h: R2_BW_begin     event: RECV_FORWARD  state: MFC
2d19h: R2 ==> MSP: BW regSig    (E1[0] ts[20])
2d19h: code = 0xff  'silence'                      
2d19h: R2_BW_end       event: RECV_FORWARD  state: MFC ==> MFC
中间送号部分内容与上类似，在此略去。。。。。。。。。。。。。。。。。。。
2d19h: MSP ==> R2: BW regSig    (E1[0] ts[20])
2d19h: code = 0x32  '2'
2d19h: No ring buffer, 5 messages lost     // 在送号码的过程日志的buffer不够打印不出消息
 
2d19h: MSP ==> R2: BW regSig    (E1[0] ts[20])
2d19h: No ring buffer, 5 messages lost
 
 
2d19h: ACC ==> R2: ACM   (E1[0] ts[20] sgId[20])
2d19h: ACC ==> R2: ANM   (E1[0] ts[20] sgId[20])
2d19h: R2_BW_begin     event: CALL_SETUP  state: WAIT_ANS
2d19h: R2 ==> VM: 0x7    (E1[0]  ts[20])     // 被叫摘机应答
2d19h: R2_BW_end       event: CALL_SETUP  state: WAIT_ANS ==> ANSWERED
 
2d19h: VM ==> R2: 0xb    (E1[0]  ts[20])     // 前向拆线
2d19h: R2_BW_begin     event: LINE_SIG  state: ANSWERED
2d19h: R2 ==> VM: 0xb    (E1[0]  ts[20])     // 被叫挂机，空闲
2d19h: R2 ==> ACC: REL    (E1[0] ts[20] sgId[20])
2d19h: R2_BW_end       event: LINE_SIG  state: ANSWERED ==> IDLE
红色信令部分含义参考此表
Af 码表示发话交换局状态的前向信号：   
    Af=0，主叫摘机（占用）状态，
    Af=1，主叫挂机（拆线）状态。
Bf 码表示故障状态的前向信号：
       Bf=0， 表示正常状态。
       Bf=1， 表示故障状态。
Ab 码表示被叫用户挂机状态的后向信号：
   Ab=0，表示被叫用户 摘机状态，
   Ab=1，表示被叫用户挂   机（后向拆线）状态。
Bb码表示受话局状态的后向信号：
    Bb=0， 表示示闲态，
    Bb=1， 表示占线或闭塞状态。
    再来一个只有信令交互的例子:
R2 ==> VM: 0x3  (E1[0] ts[4])     // 占用（ 00 11 ）
VM ==> R2: 0xf  (E1[0] ts[4])     // 占用确认（ 11 11 ）
VM ==> R2: 0x7  (E1[0] ts[4])    // 应答 （ 01 11 ）
R2 ==> VM: 0xb  (E1[0] ts[4])    // 前向拆线（ 10 11 ）
VM ==> R2: 0xb  (E1[0] ts[4])    // 空闲 （ 10 11 ）
注：根据我国线路信令标准，对于不使用的码位采用全 1 填充，我公司网关仅使用前两位。
 
Debug r2 all 应用示例：
例一：通过debug看到我方发送出了线路信令（0x3），而对方收不到我们发送的线路信令（0x3），则极有可能是两者对连的E1线路出现了问题，但我们这边通过show r2-config 0 0 看到我们这边的R2线路应该是处于同步状态（May 21 17:06:28.916: E1 line: synchronous），由于E1的两根线中，只要接收线正常，E1状态就显示为同步，因此可以推断分析我们这边的线路接收线路是正常的，而PBX一侧的接收线路出现了故障（有可能就是线松了），导致消息送不过去

例二：根据抓回来的信息，看到我们很多时隙都有收到如下的误码（因为上述线路信令只能使用前两位，后两位都用1填充，换算后前向信令只可能是0x3或0xb，后向信令只可能是0x7，0xb，0xf）：
Jun 25 11:00:13: VM ==> R2: 0xa (E1[0] ts[9])
Jun 25 11:00:40: VM ==> R2: 0x9 (E1[0] ts[22])
R2 信令对于线路误码很敏感，正是线路误码导致的呼叫断线。
出现误码最常见原因是时钟不同步。如果经过替换确认我们的板卡没有问题，就可以认为线路上出现了问题，需要PBX端配合查找定位。