华为SOFTX3000下H248协议传真故障处理经验.doc

1、华为 SOFTX3000 下 H248 协议传真故障处理经验摘要：本文主要对传真业务进行了介绍，并对 h.248 协议下的各个厂家的设备之间发送传真出现的一些故障进行了总结 关键词：软交换；高速/低速传真；T38；VBD；RFC2198；EC Abstract: this paper mainly to the fax service are introduced, and the h. 248 protocol of each manufacturer of the equipment send faxes between some of the problems are summarize

2、d Key words: soft exchange; High speed/low speed fax; T38; VBD; RFC2198); ec 中图分类号：TN917.8 文献标识码：A 文章编号：2095-2104(2013) 0 引言 目前烟台的软交换设备采用的是华为的 SOFTX3000，下挂了华为、中兴、阿朗、瑞斯康达等各种厂家的 OLT 和 ONU 设备，到现在为止，芝罘区已经发生过多个以上厂家的 ONU 设备的传真不好用问题，针对这些问题，我们必须找到原因，进行处理。 1 传真业务概述 1.1 传真业务概述 传真业务是指以传递编码信息文件的形式，在传真机间提供文件的自动交

3、换和双向通信。作为 PSTN 网络中的传统业务，传真在 NGN 的发展中也被大量的开展。 1.2 传真信号： 根据传输速率的不同，可以分为高速传真和低速传真，一般低于或等于 14.4K bps 的传真为低速传真，高于 14.4Kbps 的则为高速传真。 1.3 传真编解码 在 IP 网络中的传真业务使用如下几种编解码： 透传传真：透传传真是将 Fax 的数据信号承载于 G.711 包的方式。G.711 透传传真的优点是实现简单、时延小；缺点是占用带宽大（速率固定为 64K bps） 、受网络波动影响大。在网络抖动、丢包比较严重的情况下，不适于应用。在网络质量好的情况下，推荐使用透传。透传传真可

4、用于高速传真和低速传真业务。 T.38 传真：T.38 传真是将传真的 T.30 信号转化为适用于分组网络的 T.38 包进行传输的方式。T.38 传真的优点是占用带宽小，通过冗余帧、前向校验等方法提高可靠性，受网络波动影响小；缺点是实现比较复杂。若传真经过两段 IP 网络，再经过 TDM 网络，该组网会产生较大时延，所以 T38 传真仅适用于低速传真业务。 VBD 传真：Voice-band Data。该传真业务遵循 T-REC-V.152 协议。这个业务是用 G711 编解码方式进行的。与透传业务相比，它的优点是即支持在通话协商前把传真媒体也协商出来，也支持在通话建立后按照传统的协商方式协

5、商传真媒体信息。从操作上和使用上更加灵活。VBD 传真可用于高速传真和低速传真业务。 2 传真流程分析 传真业务一般都是先建立语音通道，而传真时对通道的要求与语音通道有所不同，所以传真开始前需要进行一次通道的切换, 包括IP、Port、codec 和通道类型（audio、fax、data） 。通道的切换一般有三种方式，网关自协商、V2 流程和 V3 流程。 目前，华为的软交换系统，主要采用的 V3 流程。 本文也主要针对 V3 流程进行分析： 在 V3 流程下，软交换通过下发 MOD 消息给网关下发建立通话的命令。一般在这个命令中，会指示网关检测传真事件。 SoftX3000 给 H248 网

6、关下发的指令如下： !/1 T=370279443C=18PR=0,MF=A1MOMO=SR,RV=OFF,RG=OFF,tdmc/ec=ON,E=369107212ctyp/dtone,al/*,SG,MF=A100000018MOMO=SR,RV=OFF,RG=OFF,Lv=0 c=IN IP4 - m=audio - RTP/AVP 8 a=ptime:20 ,Rv=0 c=IN IP4 160.30.19.138 m=audio 28596 RTP/AVP 8 a=ptime:20 传真通道的切换，是从网关检测到传真信号开始的。网关通过检测到的信号来辨别当前用户发起的是高速传真还是低速

7、传真，用不同的信号上报给软交换。 网关检测到的高速传真信号： 对于 H248 协议，网关给软交换一般是上报如下三种事件之一：ctype/dtonedtt=ANSBAR 、ctype/dtonedtt= ANSAMBAR 、ctype/dtonedtt= ANSAM 。 高速传真时，网关上报给 SoftX3000 传真事件的 H248 协议描述： MEGACO/1:2944 Transaction=12558 Context=10000 Notify=User1 ObservedEvents=2005 20020401T09151800 : ctyp/dtone dtt= ANSAM 对于高速

8、Modem 业务，网关检测到的信号也是上面描述的信号，所以从网络上是无法区分高速传真和高速 Modem，只能统一当作高速 Modem处理。 低速传真设备所在的网关设备先检测到 ANS，定时器超时前，又检测到 v21flag 信号：网关通过 H248 向软交换上报 v21flag 事件。 低速传真时，网关上报给 SoftX3000 传真事件的 H248 协议描述： MEGACO/1:2944 Transaction=12558 Context=10000 Notify=User1 ObservedEvents=2005 20020401T09151800 : ctyp/dtone dtt=V21

9、flag 注意：有些网关会先上报 ANS，然后在上报 V21flag，软交换默认是不对 ANS 事件进行处理，按照低速传真处理。 3 传真不通的故障原因分析 3.1 高速传真和低速传真协商不成功问题 曾处理过一起传真故障，一用户使用的传真机，无法发送任何传真。处理过程： 目前，华为软交换系统，通过回声抑制 EC（ECHO CONTROL）功能实现， 在数据业务中，如果对回声不加任何处理，信号可能会失真或者丢失，从而导致数据业务失败。为了避免回声对通信造成影响，各个网关均支持 EC（ECHO CONTROL）功能。 在传真业务中，EC 开关是否打开有如下原则：高速传真关闭；低速传真打开。华为软交

10、换对高速传真都是下发 EC 为 OFF，对于低速传真，使用参数控制是否打开 EC 处理措施： 软交换上 MOD MGW 时将 UCATT=NOEC-0 改成 UCATT=NOEC-1，传真可正常使用，因一般传真机都支持高速和低速两种模式，该故障很少见，故此参数一般不做修改。 3.2 软交换不支持 VBD 传真，导致协商不成功 故障现象：中兴的 9806H 接入设备上下挂的电话与贝尔的 7353 设备下挂电话之间发送传真不通。 做信令跟踪发现： SS 下发 calltype=DATA 后，中兴设备回复说支持 vbd=yes，PT 值为100， 而贝尔的设备恢复 PT 值为 96，二者因为协商不成

11、功，导致不能正常接续。 经查询各种专业资料，并反复验证，发现导致该故障的根本原因是：中兴设备设置了采用 VBD 方式编解码，而贝尔的设备不采用 VBD 方式编解码。其实关键原因还在于华为的软交换系统不支持 VBD 传真方式。 解决措施： 鉴于以上原因，通过在软交换上修改 MGW 参数，屏蔽掉 VBD 模式后，将 LISTOFCODEC=G711A_VBD-1 3.3 不同厂家设备 RFC2198 参数不匹配导致协商不成功 故障现象：华为的 5616 接入设备上下挂的电话和贝尔的 7353 下挂电话之间发送传真不通。 做信令跟踪发现： 华为 5616 设备启动了 RFC2198 模式，而 735

12、3 设备没有响应导致传真失败。 分析处理： 所谓的 RFC2198（RTP Payload for Redundant Audio Data）用于冗余音频数据的 RTP 负载格式。 RFC2198 协议规定两媒体网关之间可以以冗余方式传递 RTP 净荷，以减少 RTP 包的丢包率。当支持 RFC2198 时，媒体网关会将同一内容的 RTP净荷打包成主用数据包与冗余数据包，然后同时发送到 IP 承载网，接受端媒体网关根据数据包中的“时间戳”信息决定取舍。 目前，华为的 5616 设备默认开关是打开的。 解决措施： 在 5616 上，将 RFC2198 参数关闭： fax-modem parame

13、ters rfc2198-start-mode disableRfc2198SmartStartup 3.4 关于 T38 传真问题 日前，我华为软交换 ADD MGW 时，编解码列表没有去除 T38，就是说软交换支持协商 T38 传真.但是因为我们现在采用的 IP 接入设备种类繁多，有一些设备默认设置不支持 T38 传真，需要手工修改，这样如果软交换设置支持的话，在传真协商的时候用采用 T38 去协商，导致协商不成功。所以我们一般设置成不支持 T38. 但是这种情况下，如果用户使用的是 T38 传真的时候，可能会因为软交换不支持导致协商失败，所以需要打开修改编解码列表，LISTOFCODEC=T38-1,传真收发成功。 参考文献： 1 华为技术有限公司 SOFTX3000 业务类-传真&modem-维护指导手册 2009-10-20 2 华为技术有限公司 SoftX3000 产品文档 V300R010C05 2010-10-25