中继语音网关采用PRI和PBX对接案例

中继语音网关采用PRI和PBX对接案例

一、组网需求：

无

二、组网图:

三、配置步骤：

用户采用“用户语音网关”下挂的电话拨打PSTN电话，返回忙音；“用户语音网关”下挂的电话之间互相拨打没有问题。

1.首先查看了中继语音网关配置信息，关键配置如下：

........

controller e1 0

pri-set timeslot-list 1-31                  //配置E1采用PRI，时隙为1-31

!

........

interface Ethernet0

ip address 202.97.134.181 255.255.255.240      //以太网口地址

!

........

interface Serial0:15                           //默认配置，不需要修改

isdn service speech

isdn service audio

........

voice-setup

!

dial-program

substitute incoming-call called 1000         //将IP侧呼入的呼叫信息中的被叫采用“rule 1000”进行变换

substitute incoming-call calling 1001         //将IP侧呼入的呼叫信息中的主叫采用“rule 1001”进行变换

!

entity 1 pots                                //配置pots实体，占用数字中继线路，“.T”代表一位或者一位以上的任意号码

match-template .T

line 0:15

!

number-substitute 1000       //配置号码变换规则“rule 1000”，将86开头的号码变为0开头的号码（即用0替换86）

rule 0 ^86. 0.

!

number-substitute 1001       //配置号码变换规则“rule 1001”，将0351开头的号码变为0891开头的号码（即用0891替换0351）

rule 0 ^0351. 0891.

!

........

ip route-static 0.0.0.0 0.0.0.0 202.97.134.177 preference 60

!

........

2.故障调试信息及分析

初步怀疑是中继语音网关和PBX之间的数字中继配合问题。分析配置，因为目前客户的需求只需要从IP呼叫PSTN侧，所以只要pots实体配置没有问题的话，呼叫路由肯定没有问题。

在中继语音网关上获取以下调试信息：

debug voice ipp all        //IP侧的呼叫、调试信息，可以获取H323的相关信息

debug voice dpl all        //dial-plan的调试信息，可以获取实体匹配、号码变换等相关信息

debug isdn q931          //数字中继侧q931三层调试信息               

debug isdn cc            //数字中继和呼叫模块交互的调试信息

具体调试信息及分析如下：

IPP_SOK [SYS]: ASYN_ACCEPT received, socketid=260

IPP_SOK [SYS]: Accept a H.225 Socket, sockid = 329

IPP_SOK [SYS]: ASYN_READ received, socketid=329

IPP_SOK [SYS]: Asyn Socket Read Event Received, socket_id=329, socket_type=1, ip_struct=0x03d77524

IPP_225 [ -1]: receive Setup msg, crv=38644, src=210.52.58.13

called=8613701170871, caller=03515600165,FacilityLen=0

//从IP侧接收到了setup消息，可以从中获取主、被叫号码信息

IPP_225 [ -1]: Setup msg, faststart=TRUE, tunnel=TRUE, h245=NONE

IPP_225 [ -1]: Send CallProceeding Msg when receive Setup Msg

IPP_VCC [ -1]: Send IPCallOut Msg when receive Setup Msg

//IPP给底层VCC模块发送IPCallOut消息

DPL_SUBST: [MultTabMainProc]Found suitable substitute rule:

szInputFormat:^0351. >> szOutputFormat:0891.

DPL_SUBST: [MultTabMainProc]The user number have been substituted

successfully. Origin Number is 03515600165, Substituted

Number is 08915600165

//匹配主叫号码变换模板，并对主叫号码进行了变换（rule 1001）

DPL_SUBST: [MultTabMainProc]Found suitable substitute rule:

szInputFormat:^86. >> szOutputFormat:0.

DPL_SUBST: [MultTabMainProc]The user number have been substituted

successfully. Origin Number is 8613701170871,

Substituted Number is 013701170871

//匹配了被叫号码变换模板，并对被叫号码进行了变换（rule 1000）

DPL_SRCH: [GetEntity]The matched entity list:

1

DPL_INTF: Get entity 1 successfully!

//匹配了对应的实体（entity 1 pots）

Serial0:15 

CC<-RCV: ISDN_CONN_REQ

CallID=0xffff UserID=0x1d PortID=0x1865d04 ServiceType=0x1 Channel=0x2 IsCompleted=0x1 Cause=0x00 CallingNum=08915600165 CalledNum=013701170871

//RCV模块给CC模块发送connect require消息

Serial0:15 

CC->Q931: PRIM_SETUP_REQ

CCIndex=0xa L3Index=0xffff PortID=0x1865d04 CES=0x1  *SN_COM=a1 *bearer=04 03 80 90 a3 *chan_id=18 03 a1 83 81 *calling_n=6c 0c 80 30 38 39 31 35 36 30 30 31 36 35 *called_n=70 0d 80 30 31 33 37 30 31 31 37 30 38 37 31 *low_l=7c 03 80 90 a3 *h_lay=7d 02 80 81

//CC模块给ISDN的Q931三层模块发送setup require消息，红色部分为主、被叫号码

Serial0:15

U->N   DL_I_DATA_REQ  CES = 1

cr= 02 00 0b SETUP  *sn_com=a1 *bearer=04 03 80 90 a3 *chan_id=18 03 a1 83 81 *calling_n=6c 0c 80 30 38 39 31 35 36 30 30 31 36 35 *called_n=70 0d 80 30 31 33 37 30 31 31 37 30 38 37 31 *low_l=7c 03 80 90 a3 *h_lay=7d 02 80 81

//用户侧（VG8020）User给网络侧（PBX）Network发送了setup消息，红色部分为号码

Serial0:15

N->U   DL_I_DATA_IND  CES = 1

cr= 02 80 0b STATUS  *cause=08 03 82 e4 7d (Invalid information element contents) *call_state=14 01 01

//网络侧（PBX）给用户侧（VG8020）发送了状态消息：无效的信息单元

Serial0:15 

CC<-Q931: PRIM_STATUS_IND

CCIndex=0xa L3Index=0xd PortID=0x1865d04 CES=0x1 *cause=08 03 82 e4 7d *call_state=14 01 01

//ISDN的三层Q931模块将状态信息反馈给CC模块

Serial0:15 

CC->RCV: ISDN_STATUS_IND Info=INFO_CAUSE

CallID=0xa UserID=0x1d PortID=0x1865d04 ServiceType=0x0 Channel=0x0 IsCompleted=0x0 Cause=0x64

//CC模块和上层RCV模块交互状态消息

Serial0:15

N->U   DL_I_DATA_IND  CES = 1

cr= 02 80 0b CALL_PROC  *chan_id=18 03 a9 83 81

//网络侧（PBX）给用户侧（VG8020）发送了call_proceeding消息

Serial0:15 

CC<-Q931: PRIM_PROCEEDING_IND

CCIndex=0xa L3Index=0xd PortID=0x1865d04 CES=0x1 *chan_id=18 03 a9 83 81

Serial0:15 

CC->RCV: ISDN_STATUS_IND Info=INFO_CHANNELID

CallID=0xa UserID=0x1d PortID=0x1865d04 ServiceType=0x0 Channel=0x2 IsCompleted=0x0 Cause=0x00

Serial0:15

N->U   DL_I_DATA_IND  CES = 1

cr= 02 80 0b DISC  *cause=08 02 82 9f (Normal, unspecified) *prog_ind=1e 02 82 88

//网络侧（PBX）给用户侧（VG8020）发送了disconnect消息，原因值为“正常”断开

Serial0:15 

CC<-Q931: PRIM_DISCONNECT_IND

CCIndex=0xa L3Index=0xd PortID=0x1865d04 CES=0x1 *cause=08 02 82 9f *prog_ind=1e 02 82 88

Serial0:15 

CC->RCV: ISDN_STATUS_IND Info=INFO_CAUSE

CallID=0xa UserID=0x1d PortID=0x1865d04 ServiceType=0x0 Channel=0x0 IsCompleted=0x0 Cause=0x1f

Serial0:15 

CC->RCV: ISDN_STATUS_IND Info=INFO_PROGRESS

CallID=0xa UserID=0x1d PortID=0x1865d04 ServiceType=0x0 Channel=0x0 IsCompleted=0x0 Cause=0x08

Serial0:15 

CC->RCV: ISDN_DISC_IND

CallID=0xa UserID=0x1d PortID=0x1865d04 ServiceType=0x0 Channel=0x0 IsCompleted=0x0 Cause=0x1f

Serial0:15 

CC<-RCV: ISDN_DISC_RES

CallID=0xffff UserID=0x1d PortID=0x1865d04 ServiceType=0x0 Channel=0x0 IsCompleted=0x0 Cause=0x00

Serial0:15 

CC->Q931: PRIM_RELEASE_REQ

CCIndex=0xa L3Index=0xd PortID=0x1865d04 CES=0x1 *cause=08 02 80 90

Serial0:15

U->N   DL_I_DATA_REQ  CES = 1

cr= 02 00 0b REL  *cause=08 02 80 90 (Normal call clearing)

//用户侧（VG8020）给网络侧（PBX）发送了release消息，原因值为“正常”拆线

IPP_VCC [ -1]: Receive CCRelease Msg,FacilityLen=0

IPP_225 [65535]: Send ReleaseComplete Msg when receive CCRelease Msg, cause=255

IPP_SOK [SYS]: delete Asyn socket, socket_id = 329

IPP_SOK [SYS]: Close Asyn Socket, socket_id = 329 , socket_type = 1

//IP侧释放TCP连接的socket

Serial0:15

N->U   DL_I_DATA_IND  CES = 1

cr= 02 80 0b REL_COM 

//网络侧（PBX）给用户侧（VG8020）发送了release_complete消息，释放完成

Serial0:15 

CC<-Q931: PRIM_RELEASE_CFM

CCIndex=0xa L3Index=0xd PortID=0x1865d04 CES=0x1

IPP_C&C [65535]: IPCCB is released

//IPP模块释放ccb（call control block）——呼叫控制块

从整个调试信息来看，感觉故障原因是由于网络侧接收到了setup消息以后，返回了：

Invalid information element contents——无效的信息单元内容

我们都知道，此时网络侧只是接收了setup消息，而setup消息中主要包含的是主、被叫号码的信息（包括具体号码、号码类别等），既然网络侧无法识别，于是联系现场工程师咨询了PBX供应商——铁通，结果被告知“不知道”，而且原有Cisco的路由器+板卡是可以工作正常的。没办法，只能让工程师反馈了Cisco原有的配置：

interface Serial0:15
no ip address
ip mroute-cache
no snmp trap link-status
isdn switch-type primary-net5       //表明采用的PRI是dss1（而非qsig），我司默认配置
isdn overlap-receiving T302 2000
isdn not-end-to-end 64
isdn incoming-voice modem
isdn guard-timer 1000 on-expiry accept
isdn map address .* plan isdn type subscriber          //配置了编码方案和号码类型
isdn calling-number 08914543567
isdn T306 50000
isdn T310 60000
isdn send-alerting                            发送回铃音，我司默认配置
isdn negotiate-bchan
isdn bchan-number-order ascending
isdn sending-complete            //发送“主叫号码发送完毕”消息，我司默认配置
fair-queue 64 256 0
no cdp enable
!

咋一看，吓了一跳，怎么配置这么多东西！再仔细一看，入我法眼的也就注释部分，除了我司默认配置已经包含的以外，最主要的就是：

isdn map address .* plan isdn type subscriber

猜测应该是配置了ISDN地址（即ISDN号码）的编码方案为isdn，而号码类型为subscriber。

=====================================================================

小常识：在ISDN呼叫接续过程的主/被叫号码信息元中，包含号码类型与编码方案属性。从语音网关发出的呼叫，呼叫属性中将携带语音实体所附带的号码类型与编码方案属性。号码类型和编码方案属性值遵循ITU-T Q.931标准。（具体配置可以参考《VG语音网关操作手册》）

号码类型包括：abbreviated | international | national | network | reserved | subscriber | unknown

编码方案包括：data | isdn | national | private | reserved | telex | unknown

缺省情况下，语音实体的主/被叫号码的号码类型和编码方案均为unknown。

=====================================================================

于是参考Cisco的配置，修改了我司VG8020的语音网关的配置，增加配置如下：

entity 1 pots

match-template .T

line 0:15

type-number called subscriber

type-number calling subscriber

plan-numbering called isdn

plan-numbering calling isdn

//注意，配置ISDN的主被叫号码类型和编码方案需要在实体视图下进行配置

然后再次进行了呼叫，发现还是无法接续成功，难道是我司VG和Cisco的标准不一样？或者是少了部分参数没有配置？没办法，只能再次获取调试信息，结果发现了如下问题：

Serial0:15

U->N   DL_I_DATA_REQ  CES = 1

cr= 02 00 05 SETUP  *sn_com=a1 *bearer=04 03 80 90 a3 *chan_id=18 03 a1 83 81 *calling_n=6c 0c 80 30 33 35 31 35 36 30 30 31 36 35 *called_n=70 0d 80 30 31 33 37 30 31 31 37 30 38 37 31 *low_l=7c 03 80 90 a3 *h_lay=7d 02 80 81

Serial0:15

N->U   DL_I_DATA_IND  CES = 1

cr= 02 80 05 STATUS  *cause=08 03 82 e4 7d (Invalid information element contents) *call_state=14 01 01

细心的工程师就会发现，此调试信息和前面的故障信息基本上是一样的，换句话说，修改了配置以后没有任何改善，而仔细观察红色部分，这里的“80”是16进制的表示，代表的是号码的编码方案和号码类型均为“unknown”，即VG语音网关的缺省值（具体的分析方法请参考05-12-08发过的《关于号码类型和编码方案》），也就是说，虽然增加了配置，但是并没有修改任何参数。没办法，只能咨询研发的兄弟，结果得到了令人无比郁闷的答复：

目前虽然支持此配置，但是配置不生效

3.解决方案

没办法，只能让研发兄弟给出了临时测试版本，经过测试没有问题，也证明了就是因为主、被叫号码的编码方案和号码类型不匹配导致。而正常的呼叫调试信息如下：

Serial0:15

U->N   DL_I_DATA_REQ  CES = 1

cr= 02 00 09 SETUP  *sn_com=a1 *bearer=04 03 80 90 a3 *chan_id=18 03 a1 83 81 *calling_n=6c 0c c1 30 38 39 31 35 36 30 30 31 36 35 *called_n=70 0d c1 30 31 33 37 30 31 31 37 30 38 37 31

//这里是参数正常修改以后的值“c1”，表示编码方案为isdn，而号码类型为subscriber

4.总结

希望此案例能够对让大家对数字中继的PRI呼叫流程有一个粗略的认识，并且能够分析简单的调试信息。实际情况中，我们需要收集相关的信息并且具体分析，另外需要提醒大家的是，因为数字中继设备一般涉及到和PBX厂商或者是一些运营商的程控交换机进行对接，所以需要双方的配合才能实现，此案例中如果没有Cisco原有的配置进行参考的话，我们还是需要工程师协调铁通的相关人员，从而了解有关数字中继的相关数据配置。只有保持网络侧和用户侧的参数一致，才能对接成功。

四、配置关键点：

无