虽然R2有许多不足，面临淘汰，但由于过去的广泛应用，现在我们仍然经常会在与其他厂家PBX的互通中用到，把本人实际的应用结合公司相关学习资料在这里做一个简单的小结，有不足的地方还请各位指点。<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

一、           常见故障现象

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就回信令“<?xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />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

红色信令部分含义参考此表

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" /> 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端配合查找定位。