·购物导航 ·专题汇总
免费注册 找回密码
openvoip  
首 页 新闻 | 行情 | 政策 | 展会 | 访谈 技 术 学院 | 协议 | 文摘 | 方案 | 培训
商 机 求购 | 供应 | 合作 | 代理 产 品 网关 话机 中继 软交换 IPPBX 服务器 >>
论坛导航 政策讨论区 | 市场讨论区 | 话务信息 | 硬件信息 | 服务社区 | 技术资料 | 招聘求职 | 更多>>  
 您的位置:首页 >> 新闻频道 >> 政策法规
中华人民共和国IP电话网关设备互通技术规范
www.OpenVoIP.cn   2007-1-22 9:31:24  来源:互联互通  作者:

    中华人民共和国通信行业标准----IP电话网关设备互通技术规范 

    前 言

本标准以《IP电话/传真业务总体技术要求》为基础,结合国内IP电话网关设备生产厂家的网关与网关之间以及网关与网守之间的实际互通测试制定的。它是IP电话网关设备研制、生产和测试的技术依据。
本标准的附录A为标准的附录。
本标准由信息产业部电信研究院提出并归口。

    1 范围

本标准规定了IP电话网关与网关之间以及网关与网守之间在通信协议上的互通要求。
本标准适用于国内IP电话网络上使用的IP电话网关设备。

    2 引用标准

下列标准包含的条文,通过在本标准中引用而构成为本标准的条文。在标准出版时,所示版本均为有效。所有标准都会被修订,使用本标准的各方应探讨使用下列标准最新版本的可能性。
ITU-T建议 H.323-1998 基于包交换的多媒体通信系统
ITU-T建议 H.225(v2)-1998 基于包交换的多媒体通信系统的信令协议和打包方法
ITU-T建议 H.245-1998 多媒体通信的控制协议
YD/T 1044-2000 IP电话/传真业务总体技术要求

     3 缩略语

RRQ:Registration Request(注册请求)
RCF:Registration Confirm(注册确认)
RRJ:Registration Reject(拒绝注册)
URQ:Unregistration Request(注销请求)
UCF:Unregistration Confirm(注销确认)
URJ:Unregistration Reject(注销拒绝)
ARQ:Admission Request(接入请求)
ACF:Admission Confirm(接入确认)
ARJ:Admission Reject(接入拒绝)
BRQ:Bandwidth Request(带宽请求)
BCF:Bandwidth Confirm(带宽确认)
BRJ:Bandwidth Reject(带宽请求拒绝)
DCF:DisengageConfirm(退出确认)
DRJ:Disengage Reject(退出拒绝)
DRQ:DisengageRequest(退出请求)
RIP:Request in Progress(进展请求)
IRQ:InfoRequest(信息查询)
IRR:InfoREquest Response(信息查询响应)
IACK:InfoRequestAck(信息查询确认)
INAK:InfoRequestNak(信息查询否认)
RAI:ResourceAvailabilityIndication(资源可用性指示)
RAC:ResourcesAvailableConfirmation(资源可用性确认)
TCS:Terminal Capacity Set(终端能力集)
TCSA:Terminal Capacity Set Acknowledge(终端能力集确认)
TCSR:Terminal Capacity Set Reject(终端能力集拒绝)
OLC:Open Logical Channel(打开逻辑通道)
OLCA:Open Logical Channel Acknowledge(打开逻辑通道确认)
OLCR:Open Logical Channel Reject(打开逻辑通道拒绝)
CLC:Close Logical Channel(关闭逻辑通道)
CLCA:Close Logical Channel Acknowledge(关闭逻辑通道确认)
CLCR:Close Logical Channel Reject(关闭逻辑通道拒绝)
ESC:End Session Command(结束会话命令)

    4 RTP协议

4.1 RTP报头格式

各Field值确定
V(版本):2 bit 版本号置2
P(填充):1 bit填充位置0
X(扩展):1 bit扩展位置0
CC(CSRC数):4 bit CSRC标识的数量,此字段填充为0,本体制不使用CSRC。
M(标志):1 bit标志位,该标志在静音后的第一个语音包时置位。静音包仅发送一个,不连续发送。
PT(净荷类型):7 bit G.723.1 4
G.729 18
Sequence number(序列号):16bit序列号,初始值为一随机数,此后以1递增,收端以此判定包丢失及恢复包顺序。
Time stamp(时戳):32bit时戳。用于标识RTP数据包中第一个字节采样时的时刻,其起始值为一随机值,以8000次/s的速率递增。
Synchronization Source(SSRC)identifiers(同步源标志):32 bit,用来标识RTP包的数据源。
Contributing Source(CSRC)identifiers(贡献源标志):每个CSRC 32 bit,0~15个CSRC序列,本体制不包含该字段。
4.2 RTCP协议
RTCP报文共有5类:RR SR SDES BYE APP。本标准只对SR和RR报文提出要求。
SR(发送报文)的格式如下:

其中的各项内容定义如下:
版本(V):2 bit协议签别,在本体制中规定为2
填充(P):1 bit在本体制中规定为0
接收报告数(RC):5 bit
在SR中包含的RR的数目,在本体制中规定不得大于1。
净荷类型(PT):8 bit
报文类型,以二进制表示。其中十进制的200代表SR。
长度(length):16 bit
报文长度,指在其后的报文长度,所以有可能为0。
发送者的同步源标志(SSRC of sender):32 bit
源同步码,用以标识此次通话。
NTP时戳(NTP timestamp):64 bit
绝对时戳。在测量环路时延时可在对方的RR报文中带回;如果发送方不具有绝对时钟的能力,则可以用通话开始时间作为时钟0点或将此域置0。(在NTP格式中,64位的前32位是从1900年1月1日0时开始到现在的以秒为单位的整数部分,后32位是此时间的小数部分)
RTP时戳(RTP timestamp):32 bit
以RTP的时戳为基准。
发送的报文数(sender's packet count):32 bit
从通话开始后发送方总共发送的RTP报文的数目。
发送的字节数(sender's octet count):32 bit
从通话开始后发送方总共发送的有效载荷的数目(以字节记)。
随后描述的是一个或多个RR报文块,在本体制中规定在SR报文中最多只能有一个RR报文块。
源标志_ n(SSRC_n):32 bit
源同步码,用以标识此RR块所从属的通话。
丢包率(fraction lost):8 bit
从上一个SR或RR报文发送后的丢包率,表现为接收方在此段时间内期待的RTP报文与所收到的RTP包数目的差值和它所期待的RTP报文的数目的比值,若为负值,置为0。详见RFC1889。
累计的包丢失数(cumulative number of packets lost):24 bit
累计的包丢失数。
接收到的扩展的最高序列号(extended highest sequence number received):32 bit
其低16位是其收到的RTP包中的sequence number的最新值。其高16位标识其收到的RTP报文的sequence number的循环的次数。
到达间隔抖动(interarrival jitter):32 bit
时延抖动。每两个RTP包的抖动可以用其RTP包中的RTP时戳和接收的时刻进行计算,计算公式如下:设
Rj代表第j个包的到达时刻,Sj代表第j个包的RTP时戳值,则第i个RTP报文与第j个RTP报文间的抖动为D(i,j):
D(i,j)=(Rj - Ri)-(Sj - Si)=(Rj - Sj)-(Ri - Si)
在生成RTCP报文时,其应当传送的时延抖动的值可用如下公式进行递推计算:
J=J+(|D(I-1,I)|-J)/16
其中,J为要传送的时延抖动值。对后一项除以16是为了消除连带噪声。
上一SR报文时戳(LSR):32 bit
收到的最近一个SR报文的NTP时戳的中间32位。
自上一SR的时间(DLSR):32 bit
在收到上一个SR报文与此次发送的报文之间的时间。以1/65536s记。如果还没有收到任何SR报文,此值置0。
RR报文的格式如下:

其中各项的功能与形式如SR中的说明。若未收到任何RTP报文,则可发送一个空的RR,即RC=0。
RTCP包发送机制:在两次RTCP报文之间,若端点没有发出任何RTP报文,则端点此次发送RR(接收报文),否则,端点发送SR(发送报文),RTCP包每秒发送一次。

    5 语音帧结构

5.1 G.723.1
IP电话可以选用G.723.1编码。G.723.1的帧长有3种情况:24字节(6.3kbit/s),20字节(5.3kbit/s)和4字节。4字节为SID(插入静音描述帧)帧,它主要用在语音的静音段,用以发送比较舒服的噪声的参数描述。这3种帧可以用任意方式混合使用。第一个八位组的最低2个比特确定了帧的长度和编码类型。在30ms的帧边界上,这两种速率可以进行任意切换,以获得最佳的音质。所有编码比特流都是从最低有效位开始传送,直至最高有效位。
G.723.1打包特征为:
a)用RTP报头的标记位的置位方法来表示该报文是静音以后第一个包,其余包的标志位置零,发送了第一个静音帧以后,在静音期间不再发送RTP包,由收端网关根据静音帧产生舒适噪音。
b)抽样频率为8000Hz。
c)帧长为30ms。
d)在一个包中,编解码器可以编解码几个连续的帧。
e)接收机必须要能连续接收0~180ms的音频数据。
5.2 G.729
这是一种8kbit/s的编码算法,该种编码抗随机比特错误的能力与抗随机突发消失帧的能力相同。在噪声较大的环境下,它能有更好的语音质量。G.729附件A算法是G.729算法降低了复杂度后的版本,两者能完全互操作,因而不必对这两种算法进行区分。
在G.729附件B中,建议声音激活检测器(VAD)和舒适噪声发生器(CNG)用于数字模拟声音和数字应用,可以和G.729、G.729附件A结合使用。G.729帧长为10个八位组(字节),静音(附件B)为2个八位组。舒适静音的格式为:

有声段帧格式为:
•一帧为10ms。
•帧长10个八位组。
•一个RT包可以放0个、1个或多个G729或G729附件A帧,后随G729附件B的有效载荷。舒适噪声帧的存在可以减小RTP载荷的长度。
•静音后的第一个有声包在RTP报头中标记位置位。
•抽样率8000Hz。
•缺省打包时间段20ms。
•编解码器可以进行单一包中连续1~10帧的编解码。
•接收方必须能接收0~200ms的用户语音数据。
5.1 其它语音编码算法
可根据实际情况增加其它语音编码算法。

    6 流程

6.1 网关注册流程
网关设备在运行初期向网守登记注册,如图1所示。

图1 网关向网守的登录流程
1)网关设备通过静态的初始配置获得网守的IP地址。
2)网关向网守发送注册请求(RRQ)消息,传送网关信息。
3)网守经过验证,将注册确认(RCF)或拒绝(RRJ)消息发送到网关。
注:网关在首次注册时应将RRQ消息中的discoverycomplete置0,其余报告其存活的RRQ消息的discoverycomplete置1。
6.2 呼叫流程
6.2.1 接入认证流程
如图2所示。

图2 接入认证流程
1)用户使用电话机拨接入码接入到网关。
2)网关采集用户的接入信息(帐号和密码),向网守发送请求用户接入认证(ARQ)消息(包含用户接入信息)。
3)网守接收到来自网关的请求用户接入认证(ARQ)消息后,检查用户合法性,确定用户权限,如果用户为合法用户,则发送接入认证通过和授权(ACF)消息发送到网关;否则,发送拒绝(ARJ)消息到网关。
4)网关若收到ACF消息,确定用户权限合法,认证通过;若收到ARJ消息,确定用户为非法用户,拒绝用户接入。
6.2.2 更改密码流程
认证通过后,卡号用户通过网关向网守进行更改密码操作,如图3所示。

图3 卡号用户更改密码流程
1)用户接入通过后,更改密码。
2)网关采集用户的更改密码信息(旧密码、新密码),向网守发送请求用户接入认证(ARQ)消息(包含用户更改密码信息)。
3)网守接收到来自网关的请求用户接入认证(ARQ)消息后,检查密码的合法性,如果密码更改成功,则发送接入认证通过和授权(ACF)消息发送到网关;否则,发送拒绝(ARJ)消息到网关。
4)网关若收到ACF消息,确定用户更改密码成功;若收到ARJ消息,则用户更改密码失败。
6.2.3 路由解析
对于一次拨号用户,用户的认证和地址解析同时完成;对于卡号用户,在认证通过后,进行地址解析,如图4所示。
1)对于卡号用户,当认证通过后,输入对方电话号码;对于一次拨号用户,输入接入码及对方电话号码。
2)网关采集用户信息对方电话号码,向网守发送请求用户接入认证(ARQ)消息(包括用户帐号、密码、对方电话号码、主叫电话号码)。
3)网守接收到来自网关的请求用户接入认证(ARQ)消息后,检查信息合法性,进行地址翻译,如果成功,则将接入认证通过和授权(ACF)消息发送到网关;否则,发送拒绝(ARJ)消息到网关。
4)网关若收到ACF消息,则地址解析成功,网关则进入呼叫流程;若收到ARJ消息,则为地址解析失败或为非法用户。

图4 用户地址解析
注:地址解析完成后,网守应在ACF消息中返回通话时长。
6.2.4 快速呼叫流程
建议采用快速呼叫建立过程(fastStart 方式),如图5所示。在无法做到的情况下,也可以采用非快速建立方式。

图5 快速呼叫流程
1)用户拨打IP电话,输入卡号密码。
2)网关1向网守发送ARQ消息,进行接入认证,其中应包含主叫号码或卡号(主叫号码采用E.164编码)。
3)网守回送ACF,接入认证通过。
4)用户输入被叫号码。
5)网关1向网守发送ARQ进行地址解析。
6)地址解析通过后,网守发送ACF。
7)网关1向被叫网关2发起呼叫建立请求“Setup”,里面包含有H.245的通道消息。
8)网关2向网关1发送“呼叫进展”(Call Proceeding)消息,里面可以包含有H.245的通道信息,也可以没有。
9)网关2同时向网守发送ARQ消息。
10)网守向网关2发送认证通过消息ACF。
11)网关2向被叫发送呼叫建立请求消息。
12)被叫振铃。
13)网关2向网关1发送Alerting消息,该消息中,可以包含H.245的通道信息,也可以不包含,网关1需要识别这两种不同情况。
14)网关1收到Alerting消息后,产生回铃音。
15)被叫摘机。
16)网关2向网关1发送“连接”(Connect)消息,里面可以包含有H.245的通道信息,也可以不包含,网关1需要识别这两种不同情况。
17)网关1收到Connect消息,接通主叫。
注:在快速呼叫过程中,网关1只有在收到Connect消息后才能开始发送媒体信息。
6.2.5 非快速呼叫流程
如图6所示。
1)用户拨打IP电话,输入卡号密码。
2)网关1向网守发送ARQ消息,进行接入认证。
3)网守回送ACF,接入认证通过。
4)用户输入被叫号码。
5)网关1向网守发送ARQ进行地址解析。
6)地址解析通过后,网守发送ACF。
7)网关1向被叫网关2发起呼叫建立请求“Setup”。
8)网关2向网关1发送“呼叫进展”(Call Proceeding)消息,里面可以包含有H.245的通道信息,也可以没有。
9)网关2同时向网守发送ARQ消息。
10)网守向网关2发送认证通过消息ACF。
11)网关2向被叫发送呼叫建立请求消息。
12)被叫振铃。
13)网关2向网关1发送Alerting消息,该消息中可以包含H.245的通道信息,也可以不包含,网关1需要识别这两种不同情况。
14)网关1收到Alerting消息后,产生回铃音。
15)被叫摘机。
16)网关2向网关1发送“连接”(Connect)消息,里面可以包含有H.245的通道信息,也可以不包含,网关1需要识别这两种不同情况,被叫开始计费(建议被叫网关在Connect消息中携带H.245地址)。
17)网关1收到Connect消息,接通主叫,主叫开始计费。

图6 非快速呼叫流程
18)网关之间进行能力交换。
19)打开逻辑通道。
注:在非快速连接中,不再作主从判决,约定主叫为主,被叫为从。若在Connect消息后,H.245能力交换或打开逻辑通道失败,网关可将DRQ消息的terminalCause置为establishedFailed,网守可以根据它不对用户进行计费。
6.2.6 快速呼叫与非快速呼叫转换
如果在呼叫建立过程中,网关1直至connect消息仍没有得到对方网关对快速呼叫能力的支持的响应,则在connect消息之后转向非快速呼叫,进行H.245的能力交换并开启H.245通道,如图7所示。

图7 快速呼叫向非快速呼叫的转换流程
6.3 呼叫释放流程
呼叫释放应采用互不控方式,分3种情况:
1)主叫用户先挂机;
2)被叫用户先挂机;
3)网络故障引起的释放。
当计费采集点收到以下3类消息的时候,开始进行停止计费处理。
1)收到PSTN网侧来的REL消息;
2)收到IP网侧发来的Release Complete消息;
3)收到底侧发来的网络故障消息。
6.3.1 呼叫释放流程
以主叫用户先挂机为例。主叫用户挂机的呼叫释放流程如图8所示,其中电话1为主叫用户,电话2为被叫用户。
1)主叫挂机。
2)如果已打开H.245通道,则网关之间要先关闭逻辑通道。
3)如果已打开H.245通道,则关闭逻辑通道后,网关间互送End Session Command。
4)网关1向网关2发送Release complete消息。
5)网关2挂断被叫。
6)网关1向网守发送DRQ。
7)网守向网关1发送DCF。
8)网关2向网守发送DRQ。

图8 拆线流程
9)网守向网关发送DCF。
注:6、7、8、9的顺序无严格要求。
6.3.2 网络故障引起的呼叫释放流程
在通话过程中,由于网络故障会导致至少其中的一个网关不能收到对方发来的RTCP包。如果网关检测到在1min内仍未收到对方网关的RTCP包,则作如图9所示的呼叫释放流程(拆线过程可由任一网关发起,下面以网关1发起拆线为例)。

图9 网络拆线流程
1)网关1发拆线消息,挂掉主叫。
2)如果已打开H.245通道,则网关之间要先关闭逻辑通道。
3)如果已打开H.245通道,则关闭逻辑通道后,网关间互送End Session Command。
4)网关1向网关2发送Release complete消息。
5)网关2挂断被叫。
6)网关1向网守发送DRQ。
7)网守向网关1发送DCF。
8)网关2向网守发送DRQ。
9)网守向网关发送DCF。
注:6、7、8、9的顺序无严格要求。

    7 RAS消息内容及需要确定的具体参数

RAS消息是网关和网守之间的注册(Registration)、接入认证(Admission)和状态查询(Status)协议。网关发送访问消息的RequestSeqNum的最高位为0,网守发送的询问消息的RequestSeqNum的最高位为1。
7.1 接入认证、地址解析和修改密码消息
7.1.1 ARQ(Admission Request)
ARQ是网关向网守发送的用户接入认证/地址解析/修改密码请求消息。在非标准参数中我们添加了2项,第一为主叫控制方式,适用于主叫号码用户,第二为卡号控制方式,对应于它分为3步,step1用于接入认证,step2用于地址解析,step3用于卡号用户在线修改密码。
表1 ARQ消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
CallType M(0,pointTopoint)
CallModel O
EndpointIdentifier M(采用RCF消息内的EndpointIdentifier)
DestinationInfo O
DestCallSignalAddress O
DestExtraCallInfo O
SrcInfo M(主叫认证时为主叫号码)
SrcCallSignalAddress O
BandWidth M(100bit/s的倍数)
CallReferenceValue M
NonStandardData M
CallServices O
ConferenceID M
ActiveMC M(为False)
AnswerCall M(主叫为False,被叫为True)
CanMapAlias O
CallIdentifier O(全局唯一的标志,与Q.931消息中UUIE的CallIdentifier一致)
SrcAlternatives O
DestAlternatives O
GatekeeperIdentifier O
Token O
CrptoToken O
IntegrityCheckValue O
TranspotQOS O
WillSupplyUUIEs O
ARQ“非标准数据”(NotStandardData)域中增加相应的参数
主叫控制方式
参数 M/O 类型 描述
CallerControl M SEQUENCE
卡号控制方式——step1
CardNumber M IA5STRING(SIZE(1..128))(FROM ("0123456789#*,")) 卡号
Password M OCTETSTRING(SIZE(1..32)) 密码,采用MD5加密
UserName O OCTETSTRING(SIZE(1..32)) 用户名
卡号控制方式——step2(无任何参数)
参数 M/O 类型 描述
Step2 M SEQUENCE
卡号控制方式——step3(修改密码)
参数 M/O 类型 描述
Newpassword M OCTETSTRING(SIZE(1..32) 新密码值,采用MD5算法加密
7.1.2 ACF(Admission Confirm)
网守对ARQ的确认回答,对于卡号用户,还需要给出用户余额或最长通话时长。
表2 ACF消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
BandWidth M(100bit/s的倍数)
CallModel O
DestCallSignalAddress O
IrrFrequency O(可用于指明IRR的发送间隔,应<10s)
NonStandardData O
DestinationInfo O
DestExtraCallInfo O
DestinationType O
RemoteExtensionAddress O
AlternateEndpoint O
Token O
CrptoToken O
IntegrityCheckValue O
TranspotQos O
WillRepondToIRR O(若置TRUE,表明网守可对IRR消息做确认或拒绝回答,若置为FALSE,则不对IRR消息作回答,即使IRR的needResponse置为TRUE)
UuiesRequested O(当RRQ消息中的WillSupplyUuies为False时该项必为False,如果RRQ消息中的WillSupplyUuies为True时该项任意)
ACF“非标准数据”(NonStandardData)域中增加相应的参数
分两种情况:一为主叫控制;一为卡号控制。在卡号控制方式下分三步,第一步为接入认证用,返回途额信息;第二步,返回通话时长;第三步是对密码修改的确认。
主叫控制
参数 M/O 类型 描述
CallerControl O SEQUENCE
卡号控制方式——step1
参数 M/O 类型 描述
RemainMoney O INTEGER(0..4294967295) 余额,单位:分
卡号控制方式——step2
参数 M/O 类型 描述
RemainTime O INTEGER(0..4294967295) 最长通话时长,单位:s
卡号控制方式——step3
参数 M/O 类型 描述
PasswordChang O SEQUENCE
7.1.3 ARJ(Admission Reject)
网守对ARQ的拒绝回答,并给出拒绝原因。
表3 ARJ消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
RejectReason M
NonStandardData O
AlternateGatekeeper O
AltGKisPermanent O
Token O
CrptoToken O
IntegrityCheckValue O
AR“非标准数据”(NonStandardData)域中增加相应的参数
参数 M/O 类型 描述
ErrorReason O ARJsErrorReason Radius拒绝原因:
(0) 用户信息不合法(卡号长度不够等)
(1) 用户不存在
(2) 用户密码错误
(3) 系统错误
(4) 卡号用户已在线
(5) 主叫用户已被暂停
(6) 备用
(7) 非本地用户不能修改密码
(8) 用户余额不足
7.2 网关注册消息
7.2.1 RRQ(Registration Request)
网关向网守的注册登记请求消息,网关必须定期(小于RCF的timetolive确定的时间)向网守发送RRQ消息,以表明网关仍然存活,具体的超时和重发次数要求见RAS消息的定时器及重发次数。消息内容见表4。
网关在首次注册时应将RRQ消息中的discoverycomplete置0,其余报告其存活RRQ消息的discoverycomplete置1。
表4 RRQ消息内容
参 数 必备(M)/任选(O)
RequestSeqNum M
ProtocolIdentifier M
NonStandardData O
DiscoveryComplete M(第一次为False以后各次为True)
CallSignalAddress M
RasAddress M
TerminalType M
TerminalAlias O
GatekeeperIdentifier O
EndpointVendor M
AlternateEndpoints O
TimeToLive O(不大于为30s)
Tokens O
CryptoTokens O
IntegrityCheckValue O
KeepAlive O
EndpointIdentifier O
WillSupplyUUIEs O(该项为False时:IRQ与ACF中的UuiesRequested必为False;
该项为True时:IRQ与ACF中的UuiesRequested任意)
7.2.2 RCF(Registration Confirm)
网守对RRQ消息的确认回答。消息内容见表5。
表5 RCF消息内容
参 数 必备(M)/任选(O)
RequestSeqNum M
ProtocolIdentifier M
NonStandardData O
CallSignalAddress M
TerminalAlias O
GatekeeperIdentifier O
EndpointIdentifier M
AlternateGatekeeper O
TimeToLive O(小于等于RRQ消息中的TimeToLive值)
Tokens O
CryptoTokens O
IntegrityCheckValue O
WillRespondToIRR O(该值为False时网关收到IRQ时回的IRR消息中的NeedResponse必为False;
该值为True时网关收到IRQ时回的IRR消息中的NeedResponse任意)
PreGrantedARQ O
7.2.3 RRJ(Registration Reject)
网守RRQ消息的拒绝回答。
表6 网守发送的RRJ消息内容
参 数 必备(M)/任选(O)
RequestSeqNum M
ProtocolIdentifier M
NonStandardData O
RejectReason M
GatekeeperIdentifier O
AlternateGatekeeper O
AltGKisPermanent O
TimeToLive O
Tokens O
CryptoTokens O
IntegrityCheckValue O
7.3 呼叫脱离消息
7.3.1 DRQ(DisengageRequest)
网关与网守之间的呼叫脱离请求命令。当该命令由网关发起时,本消息应同时传递计费信息。计费信息放在“非标准数据”(NonStandardData)中。若是网守向网关发送DRQ消息,该消息不包含计费信息,并且网关必须回应DCF。
表7 DRQ消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
EndpointIdentifier M(采用RCF消息的EndpointIdentifier)
ConferenceID M(与主叫网关的MAC地址和时间信息有关的随机数)
CallReferenceValue M
DisengageReason M
NonStandardData O
CallIdentifier O
GatekeeperIdentifier O
Token O
CrptoToken O
IntegrityCheckValue O
AnsweredCall O
DRQ“非标准数据”(NonStandardData)域中增加相应的参数
参数 M/O 类型 描述
SrcCallSignalAddress M TransportAddress 主叫网关地址
DestCallSignalAddress M TransportAddress 被叫网关地址
AcctStartTime M INTEGER(0..4294967295) 计费开始时间,单位:绝对秒,以1970年1月1日0点1分0秒开始
AcctSessionTime M INTEGER(0..4294967295) 通话时长,单位为s
ServiceType M DRQsServiceType 呼叫方式:
(0) 电话
(1) IP传真
InBytes O INTEGER(0..4294967295) 入字节数
OutBytes O INTEGER(0..4294967295) 出字节数
EnCodecType O AudioCapability 编码方式
DeCodecType O AudioCapability 解码方式
TerminationCause M DRQsTerminationCause 呼叫终止原因
(0) 主叫挂断
(1) 被叫挂断
(2) 网络异常中断
(3) 呼叫建立失败
7.3.2 DCF(DisengageConfirm)
对DRQ的确认回答。
表8 DCF消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
NonStandardData O
Token O
CrptoToken O
IntegrityCheckValue O
7.3.3 DRJ(Disengage Reject)
网守对DRQ的拒绝回答,并给出拒绝原因。
表9 DRJ消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
RejectReason M
NonStandardData O
AlternateGatekeeper O
AltGKisPermanent O
Token O
CrptoToken O
IntegrityCheckValue O
7.4 状态消息
7.4.1 IRQ
网守向网关发的询问某一话路或所有话路的状态请求消息。若callReferenceValue为0,则网关需要在同一条IRR消息中报告所有呼叫的状态信息。CallReferenceVale为0的IRQ的发达间隔应大于10s。
表10 IRQ消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
CallReferenceValue M
NonStandardData O
ReplyAddress O
CallIdentifier O
Tokens O
CrptoTokens O
IntegrityCheckValue O
UuiesRequest O(网守可以要求网关报告需要的Q.931消息,若ARQ消息的willSupplyUUIEs置为TRUE,则网关必须报告,若为FALSE,在网关可以不报告)
7.4.2 IRR
网关根据ACF命令设定的间隔或IRQ请求向网守发送的状态消息。
表11 IRR消息的主要内容
参 数 必备(M)/任选(O)
NonStandardData O
RequestSeqNum M
EndpointType M
EndpointIdentifier M
RasAddress M
CallSignalAddress M
EndpointAlias O
PerCallInfo M
Tokens O
CrptoTokens O
IntegrityCheckValue O
NeedResponce O(该项为False时:不用应答;
该项为True时:需应答)
7.4.3 IACK
对IRR的证实消息。
表12 IACK消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
NonStandardData O
Tokens O
CrptoTokens O
IntegrityCheckValue O
7.4.4 INAK
对IRR的拒绝消息。
表13 INAK消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
NonStandardData O
NakReason M
AlternateGatekeeper O
AltGKisPermanent M
Tokens O
CrptoTokens O
IntegrityCheckValue O
7.5 网关资源报告消息
7.5.1 RAI
网关向网守发送的资源可利用性报告。
表14 RAI消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
ProtocolIdentifier M
NonStandardData O
EndpointIdentifier M
Protocols M
AlmostOutOfResources M
Token O
CrptoToken O
IntegrityCheckValue O
7.5.2 RAC
网守对RAC的确认消息。
表15 RAC消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
ProtocolIdentifier M
NonStandardData O
Token O
CrptoToken00000 O
IntegrityCheckValue O
7.6 RAS的请求进展消息(RIP)
RIP消息是当终端收到一个请求消息后,如果判断在相应的超时(timeout)时间内不能及时返回回答消息,则该终端可通过发送RIP消息以延长对方等待时间,这个等待时间由RIP消息的delay域决定。对端在timeout加delay的时间内若没有收到回应则作超时处理。
表16 RIP消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
NonStandardData O
Token O
CrptoToken O
IntegrityCheckValue O
Delay M(以ms为单位)
7.7 带宽管理消息
7.7.1 BRQ
网关与网守之间的带宽改变的请求的消息,当网守具备带宽管理能力时,则带宽管理消息是有实用意义的。由于ARQ消息的bandwidth所取的值总是大于每一话路实际占用的带宽,因此为了能使网守掌握网关的带宽利用情况,网关应根据实际带宽利用情况利用BRQ消息改变带宽,以便释放多余的带宽或请求增加带宽。若是利用BRQ消息增加带宽,则网关必须等待网守的确认。
表17 BRQ消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
EndpointIdentifier M
ConferenceID M
CallreferenceValue M
CallType O
BandWidth M
NonStandardData O
CallIdentifier O(全局唯一的标志,与Q.931消息中的UUIE的CallIdentifier一致)
GatekeeperIdentifier O
Token O
CrptoToken O
IntegrityCheckValue O
AnsweredCall O
7.7.2 BCF
网关或PC与网守之间的带宽改变的确认的消息。
表18 BCF消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
BandWidth M
NonStandardData O
Token O
CrptoToken O
IntegrityCheckValue O
7.7.3 BRJ
网关或PC与网守之间的带宽改变的拒绝的消息。
表19 BRJ消息的主要内容
参 数 必备(M)/任选(O)
RequestSeqNum M
RejectReason M
AllowedBandWidth M
NonStandardData O
AlternateGatekeeper O
AltGKisPermanent O
Token O
CrptoToken O
IntegrityCheckValue O
7.8 注销消息
7.8.1 URQ(Unregistration Request)
URQ消息用于网关和网守之间登记的注销。
表20 URQ消息内容
参 数 必备(M)/任选(O)
RequestSeqNum M
NonStandardData O
EndpointAlias O
EndpointIdentifier O
AlternateEndpoints O
GatekeeperIdentifier O
Tokens O
CryptoTokens O
IntegrityCheckValue O
Reason O
7.8.2 UCF(Unregistration Confirm)
网关或网守对URQ消息的确认回答。
表21 UCF消息内容
参 数 必备(M)/任选(O)
RequestSeqNum M
NonStandardData O
Tokens O
CryptoTokens O
IntegrityCheckValue O
7.8.3 URJ(Unregistration Reject)
网关或网守对URQ消息的拒绝回答。
表22 URJ消息内容
参 数 必备(M)/任选(O)
RequestSeqNum M
RejectReason M
NonStandardData O
AlternateGatekeeper O
AltGKispermanent O
Tokens O
CryptoTokens O
IntegrityCheckValue O
7.9 对ARQ中Password的加密描述
采用算法 MD5算法。
MD5算法中需要两个输入值,一串无须定长的字符串,一个对称密钥,计算后得出一串16位长的字符串。公式如下:
Result=MD5(string1,key)
具体应用中,string1取值ARQ中的卡号,加密方和解密方的key必须一样。
加密过程
用原密码P同MD5的结果Result按位异或,得出加密后的密码P',公式如下:
P'[0]=P[0] xor Result[0];
P'[1]=P[1] xor Result[1];
……
P'[strlen(P)-1]=P[strlen(P)-1] xor Result [strlen(P)-1]
解密过程
用加密后的密码P'同MD5的结果Result按位异或,得出密码P",公式如下:
P"[0]=P'[0] xor Result[0];
P"[1]=P'[1] xor Result[1];
……
P"[strlen(P)-n]=P'[strlen(P)-n] xor Result [strlen(P)-n]
直到P"[n]为结束符为止。
得到的密码P"即为原密码P。
7.10 Q.931消息的UUIE部分
Q.931消息中交换的电话号码信息,以Q.931消息的域内消息为主。
7.10.1 Setup-UUIE
信息单元 M/O 描述
ProtocolIdentifier M 必填
h245Address O 可选
SourceAddress O 填写主叫号码或卡号,对于卡号用户还需要填写卡号(可选)
SourceInfo M 主叫信息
DestinationAddress O 被叫号码(可选)
DestCallSignalAddress O 被叫网关IP地址(可选)
ActiveMC M False
ConferenceID M 与MAC和时间信息有关的随机数
ConferenceGoal M Creat
FastStart O 对于快速中短波叫,必填
7.10.2 CallProceeding-UUIE
信息单元 M/O 描述
ProtocolIdentifier M 必填
DestinationInfo M 必填
h245Address O 对于快速呼叫不填,对于非快速呼叫可选
CallIdentifier O 如选用,则与RAS消息中的callIdentifier一致
FastStart O 对于非快速呼叫不填,对于快速呼叫可选
7.10.3 Alerting-UUIE
信息单元 M/O 描述
ProtocolIdentifier M 必填
DestinationInfo M 必填
h245Address O 对于快速呼叫不填,对于非快速呼叫可选。
CallIdentifier O 如选用,则与RAS消息中的callIdentifier一致
FastStart O 对于非快速呼叫不填,对于快速呼叫可选。
7.10.4 Connect-UUIE
信息单元 M/O 描述
ProtocolIdentifier M 必填
DestinationInfo M 必填
h245Address O 快速呼叫不填,非快速呼叫可选。
ConferenceID M 对应Setup消息中的ConferenceID
CallIdentifier O 如选用,则与RAS消息中的callIdentifier一致
FastStart O 非快速呼叫不填,快速呼叫可选。
7.10.5 ReleaseComplete-UUIE
信息单元 M/O 描述 测试情况
ProtocolIdentifier M 必填
CallIdentifier O 如选用,则与RAS消息中的callIdentifier一致

    8 RAS消息的定时器和重发次数

表23规定了各RAS消息对应的定时器值和重发次数
表23 RAS消息对应的定时器值和重发次数
RAS消息 定时器值(s) 重发次数
RRQ1 3 2
URQ 3 1
ARQ 3 1
IRQ 3 1
IRR2 5 2
DRQ 3 6
RAI 3 2

1 RRQ消息发送周期应小于RCF消息中的存活时间(time-to-live-10)。
2 此处的定时器值规定的是网关首先向网守发IRR消息情况下(其发送周期根据ACF消息的irrFrequency确定,若网守在规定的时间内没收到IRR包,则发IRQ包查询,若网关没回应,网守拆线),网守应在此定时器值时间范围内回以IACK证实消息或INAK拒绝消息,否则出现超时。

9 Q.931消息的定时器和重发次数
表24规定了各Q.931消息对应的定时器值和重发次数。
表24 Q.931消息对应的定时器值和重发次数
定时器名称 定时器值(s)
Steup定时器1 4
Establishment定时器2 ≤60(市话),90(长话),120(国际)

1 Setup定时器值是指主叫网关送出Setup消息后等待被叫网关回送ALERTING或CALL PROCEEDING或CONNECT或RELEASE COMPLETE或其它消息时间。
2 Establishment定时器值指主叫网关收到ALERTING消息等待被叫网关回送CONNECT消息的时间或主叫网关中断此次呼叫而送出RELEASE COMPLETE消息的时间。

10 互通中需注意的其它问题
1)可以将ACF里的被叫号码作为Q.931消息里的真正的被叫号码。
2)每个RRQ消息都应有timeToLive这一项。
3)在非快速呼叫里,应在收到OLC ACK后打开RTP通道。
4)网守发送IRQ项网关讯问某一话路状态时,若网关已无该话路的呼叫参考值,则网关回空的IRR。
5)发送端的语音增益
有待于进一步研究。
6)接收端的语音增益
有待于进一步研究。

点击进入论坛交流

点击:( 编辑:筱文 )
 ■ 用户评论/[查看所有评论] [已有评论: ]
 ■ 请您注意
· 您发表的内容需要经过管理员审核才能被其他人看见
· 尊重网上道德,遵守中华人民共和国的各项法规
· 承担一切因您的行为导致的直接或间接民事或刑事责任
· 此留言板管理人员有权保留或删除留言中的任意内容
· 参与本留言即表明您已经阅读并接受上述条款
· 评论仅代表评论者个人观点,请您理性判断,慎重对待
网络通讯服务网 版权与免责声明:

凡本网注明“来源: 网络通讯服务网 ”的所有作品,版权均属于 网络通讯服务网 ,未经本网授权不得转载、摘编或利用其它方式使用上述作品。已经本网授权使用作品的,应在授权范围内使用,并注明“来源: 网络通讯服务网 ”。违反上述声明者,本网将追究其相关法律责任。
凡本网注明“来源:XXX(非 网络通讯服务网 )”的作品,均转载自其它媒体,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。
如因作品内容、版权和其它问题需要同本网联系的,请在30日内进行。
关于本站 | 联系我们 | 版权声明 | 本站导航 | 纯文字版 | RSS新闻订阅 | 信息发布 | Alexa权威统计
CopyRight © 2005 Tel:(+86)0371-60239922 Email:[email protected] 点击免费咨询
网络通讯服务网 版权所有 豫ICP备05023816号 公安互联网备案