Q.931协议分析培训教材
3 Q.931呼叫消息流程分析步骤
本节简单介绍Q.931呼叫消息流程的分析步骤，只是提供Trace的分析方法，并不涉及如
何根据Trace判断、定位问题。因HDLCMON无法对一个呼叫进行跟踪，所以一般情况下，用HDLCMON抓取的Trace会较大，其中包括其他呼叫的流程。这里主要介绍，如何将需要的呼叫消息流程从Trace中过滤出来。
第一步：任何呼叫都包含有主被叫的电话号码或机身码，所以开始时可根据主叫的机身码或被叫的电话号码查找到SETUP消息。
? 在SETUP消息内包含有主、被叫的号码。但对主叫的呼叫消息流程来说，SETUP消
息内的主叫号码是指PS的机身码（烧在手机内的号码），被叫号码指的是被叫的电话号码（LE侧分配的号码）；而对被叫的呼叫消息流程来说，SETUP消息内的主叫号码是指主叫的电话号码，被叫号码是指被叫PS的机身码。
第二步：在SETUP消息内找到呼叫参考值，根据呼叫参考值的特点――在整个呼叫过程中对同一个接口保持不变。所以可根据该呼叫参考值将整个呼叫消息流程的各个消息提取出来。
? 正常的呼叫消息流程请参阅附录5.3。 ? 在提取分析时需注意Trace的时序关系。
第三步：根据呼叫消息流程，分析判断、定位问题及呼叫中断的原因等。
? 对一个呼叫消息流程，一般情况下在一个节点的不同接口呼叫参考值是不同的。
4 呼叫消息流程Trace的抓取
呼叫消息流程Trace(以下简称Trace)的抓取一般采用UTSTARCOM公司开发的软件
HDLCMON。本章主要介绍HDLCMON的使用方法及如何抓取相应的trace。
4.1 HDLCMON工具简介
HDLCMON是信令跟踪捕捉工具，可以对Q.931协议的信令进行跟踪捕捉。适用的节点为CSC。随着公司的发展，HDLCMON已经有几个版本，建议使用最新的版本，文件大小为54KB。
HDLCMON程序运行时将所联节点的HDLC Debug的输出开关打开，所有的呼叫信令消息以IP包的形式向外发出，端口为8010。该程序通过上层UDP协议侦听该端口从而捕获信令消息。
项目管理和技术支持部 42
Q.931协议分析培训教材
4.2 HDLCMON命令格式
命令格式如下：
HDLCMON –s –S –v –o=csc.bin 10.1.38.1 HDLCMON –s –S –v –f=csc.bin > csc.txt
前一个命令的功能是将对节点10.1.38.1的跟踪结果保存到csc.bin中，而后一个命令是将csc.bin转换成csc.txt，便于分析。
? 可以打开多个窗口，对不同节点同时运行该程序，进行跟踪。
? HDLCMON程序运行中的不恰当停止，会使节点的HDLC Debug的输出开关打开，造成所
有的呼叫信令消息以IP包的形式向外发送，造成网络网络流量激增。所以跟踪结束后，应用“Ctrl C”正常停止该程序，不要直接关闭HDLCMON的DOS窗口或其他方法不正常停止该程序。
4.3 Trace的获取
根据故障现象的不同，需跟踪分析的节点不同。所以建议获取Trace时，对呼叫需经过的所有节点进行跟踪。
项目管理和技术支持部 43
Q.931协议分析培训教材
5
5.1
呼叫消息流程Trace分析举例
根据cause的值确定呼叫中断的原因
在Q.931协议中，呼叫中断时在REL、REL COM、DISC等消息中会附带cause信息。在分析Trace时可根据该信息简单分析呼叫中断的原因。
? 各cause值的可能情况请参阅附录5.1。
? 在分析Trace时需注意cause是由那里开始发起的，即找出问题是由那个节点或终
端引起的。
下面以一个案例，来分析说明如何根据cause的值来具体分析定位问题的原因：
问题现象：
1、一个节点下的部分用户无法做被叫；
2、抓取Trace分析，被叫时用户鉴权后立即释放，cause=81。
问题分析：
Cause=81，在Q.931中的解释是：Invalid call reference value。该值表明，系统收到一个消息，但该消息指示的呼叫参考值，没有关联的一个正在进行的或激活的呼叫过程。但根据该信息无法判断问题所在及根本原因，下面来具体分析： 首先，根据SETUP消息的被叫PS机身码将整个呼叫过程的消息全部查找出来，并按照时间顺序排列，如下：
―――――――――――――――――――― LAPD: 0 C (F) I-frame (NR=5 NS=1c) Q.931: ref=0x045c SETUP Bearer cap (3) Channel Id (2)
Calling Party Number (8) 5800322 Called Party Number (12) 16377094642 > 0: ( 42) 126746241
> 02 01 38 0a 08 02 04 5c 05 04 03 80 90 a3 18 02 > e3 80 6c 08 80 35 38 30 30 33 32 32 70 0c 80 31 > 36 33 37 37 30 39 34 36 34 32 …………
LAPD: 0 C (F) I-frame (NR=13 NS=49)
Q.931: ref=0x045c SETUP-------------向channel1-6发出SETUP消息 Bearer cap (3)
项目管理和技术支持部 44
Q.931协议分析培训教材
Channel Id (2) Calling Party Number (8) 5800322 Called Party Number (12) 16377094642 > 6: ( 42) 126746241
> 02 01 92 26 08 02 04 5c 05 04 03 80 90 a3 18 02 > e3 80 6c 08 80 35 38 30 30 33 32 32 70 0c 80 31 > 36 33 37 37 30 39 34 36 34 32
LAPD: 0 R (F) I-frame (NR=4a NS=13) Q.931: ref=0x845c REL COM
Cause (2) cause=41-----------------收到由channel-6发来的cause=41的REL COM < 6: ( 13) 126746242
< 00 01 26 94 08 02 84 5c 5a 08 02 82 a9
LAPD: 0 R (F) I-frame (NR=f NS=21)
Q.931: ref=0x845c CALL PROC--------收到由channel-3发来的CALL-PROC Channel Id (4) E1=2 B-ch=18 WLL Facility2 (7) < 3: ( 25) 126746325
< 00 01 42 1e 08 02 84 5c 02 18 04 e9 82 83 12 96 < 02 07 92 9e 01 12 2e 8a 09
LAPD: 0 C (F) I-frame (NR=5 NS=1f) Q.931: ref=0x045c REL COM Cause (2) cause=16 > 0: ( 13) 126746326
> 02 01 3e 0a 08 02 04 5c 5a 08 02 82 90 …………………
LAPD: 0 C (F) I-frame (NR=16 NS=4c)
Q.931: ref=0x045c REL COM---------向channel-0\\1\\2\\4\\5\\6发出REL COM Cause (2) cause=16 > 6: ( 13) 126746326
> 02 01 98 2c 08 02 04 5c 5a 08 02 82 90
LAPD: 0 C (F) I-frame (NR=22 NS=10) Q.931: ref=0x045c INFO
WLL Facility2 (9) Authentication data
> 3: ( 21) 126746326-----------向channel-3发出INFO消息，内含鉴权码
项目管理和技术支持部 45
说明被叫用户在channel-3下
Q.931协议分析培训教材
> 02 01 20 44 08 02 04 5c 7b 96 02 09 82 3f 24 07 > e1 b1 00 00 00
LAPD: 0 R (F) I-frame (NR=4d NS=16)
Q.931: ref=0x845c REL COM-----因前面已经由ch-6收到REL COM(cause=41)，而此 Cause (2) cause=101 < 6: ( 13) 126746326
LAPD: 0 R (F) I-frame (NR=11 NS=23) Q.931: ref=0x845c INFO
WLL Facility2 (16) Authentication result=OK
< 3: ( 28) 126746337----------由ch-3收到INFO消息，鉴权成功 < 00 01 46 22 08 02 84 5c 7b 96 02 10 83 80 81 ee < d4 98 f8 7a 9d 4c 9e 01 12 2e 8a 09
LAPD: 0 C (F) I-frame (NR=24 NS=11) Q.931: ref=0x045c REL COM
Cause (2) cause=81----------向ch-3发出REL COM(cause=81),该呼叫已释放 > 3: ( 13) 126746337
> 02 01 22 48 08 02 04 5c 5a 08 02 82 d1 ―――――――――――――――――――――
由上面的呼叫流程可看出，系统在向Channel1-6发出SETUP消息后，马上收到由Channel-6发来的REL COM消息，cause=41。该消息已经导致该次呼叫被释放，而从后面的流程分析用户是在channel-3下面，但在此后的消息CALL PROC、INFO等指示的呼叫参考值所对应的呼叫已经被释放，所以在此后会收到cause=81的REL COM消息。
查Q.931协议的cause列表，Cause=41表示：Temporary failure，可能是Channel-6的故障导致该问题。检查Channel-6的传输链路，发现存在硬件故障，链路时通时不通。最后排除该传输链路故障，问题得到解决。
后又向ch-6发出REL COM(cause=16), 所以现由该
ch-6发来的REL COM（cause=101）
< 00 01 2c 9a 08 02 84 5c 5a 08 02 82 e5
5.2 GW侧设置EOC通道导致个别呼叫失败
该问题的出现原因是GW侧将连接CSC的E1链路的个别时隙设置为EOC通道，但在CSC侧相应时隙没有设置，导致呼叫占用在该B-CH时由于通道不可接受而失败。
该问题导致的错误呼叫流程如下：
――――――――――――――――――－
项目管理和技术支持部 46