首页> 中国专利> 一种Q.931呼叫信令安全保障机制的选择方法

一种Q.931呼叫信令安全保障机制的选择方法

摘要

本发明公开了一种Q.931呼叫信令安全保障机制的选择方法,通过将主、被叫终端的安全机制列表保存在各自的网守上,待有接入请求后通过被叫终端的网守比较主叫与被叫终端的安全机制列表选择出一种公共的安全协议,发给主叫终端建立安全通道保护Q.931呼叫信令的安全。与现有技术相比,使用本发明提出的方法,在H.323多媒体通信系统中,无需预先配置Q.931呼叫信令的安全保障机制,只需经过动态协商就可以选择共有的安全协议建立Q.931呼叫信令的安全通道。

著录项

  • 公开/公告号CN1767528A

    专利类型发明专利

  • 公开/公告日2006-05-03

    原文格式PDF

  • 申请/专利权人 中兴通讯股份有限公司;

    申请/专利号CN200410086143.5

  • 发明设计人 崔莉;李远威;芦东昕;

    申请日2004-10-27

  • 分类号H04L29/06(20060101);H04L9/00(20060101);

  • 代理机构11259 北京金硕果知识产权代理事务所;

  • 代理人张玫

  • 地址 518057 广东省深圳市南山区高新技术产业园科技南路中兴通讯大厦法律部

  • 入库时间 2023-12-17 17:08:02

法律信息

  • 法律状态公告日

    法律状态信息

    法律状态

  • 2009-06-17

    授权

    授权

  • 2006-06-28

    实质审查的生效

    实质审查的生效

  • 2006-05-03

    公开

    公开

说明书

技术领域

本发明涉及一种安全机制协商方法,尤其涉及在ITU-T H.323多媒体通信系统中两终端间协商选择Q.931呼叫信令安全保障机制的方法。

背景技术

根据ITU-T H.235标准规定,对H.323多媒体通信系统中各信道提供安全保障可以使用以下两种方法:一是选用自上而下信令层层嵌套选择的方式,即媒体流信道安全保障机制的选择在H.245信道中协商完成,H.245信道安全保障机制的选择在呼叫信道中协商完成。二是采用外部安全协议如IPSEC、TLS等来保护呼叫信道、H.245信道、媒体流信道的安全。但ITU-T H.235标准中未说明如何协商选择呼叫信道的安全保障机制的方法,只是举例说明在建立呼叫前呼叫双方已预先知道对方(此处可以是终端也可以是网守)所支持的安全协议(IPSEC或TLS),并预先配置好双方共同支持的保护Q.931呼叫信令的安全协议。

这种在建立呼叫前预先知道、预先配置保护Q.931信令的安全协议的方法,其缺点是:这种方法仅适用于节点规模较小的H.323系统。在规模较大的H.323系统中,用户需要和不同的用户进行通信,甚至和以前没有任何接触的用户进行通信,他不可能预先知道所有用户的安全配置,预先配置的策略是不现实的。

发明内容

本发明就是为了克服现有的H.323多媒体通信系统中Q.931呼叫信令的安全保障机制需要预先配置的缺陷,提出一种在H.323多媒体通信系统中两终端间协商选择Q.931呼叫信令安全保障机制的方法。

一种Q.931呼叫信令安全保障机制的选择方法,包括下列步骤:

第一步、主叫终端与被叫终端将自身的安全机制列表发送给各自的网守;

第二步、网守收到各自终端的安全机制列表后保存到本地;

第三步、主叫终端发起接入请求,主叫终端网守收到请求后判断主叫终端网守与被叫终端的网守是否同一网守,如果是则继续,否则执行第五步;

第四步、网守比较主叫与被叫终端的安全机制列表,若存在共同支持的安全协议,则选择其中的一种,并将选择的安全协议种类发送给主叫终端;否则回复接入拒绝信令给主叫终端;执行第八步;

第五步、主叫终端网守将主叫终端的安全机制列表逐级转发至被叫终端网守;

第六步、被叫终端网守比较主叫与被叫终端的安全机制列表,若存在共同支持的安全协议,则选择其中的一种,并将选择的安全协议种类逐级转发至主叫终端网守;否则回复定位拒绝信令给主叫终端网守;

第七步、若主叫终端网守收到选择的安全协议种类,则将之发送给主叫终端,否则回复接入拒绝信令给主叫终端;

第八步、若主叫终端收到选择的安全协议种类信息,则用该公共安全协议建立主叫终端与被叫终端间的安全通道,否则结束。

本发明提出的方法,通过将终端的安全机制列表保存在各自的网守上,待有接入请求后通过被叫终端的网守比较主叫与被叫终端的安全机制列表选择出一种公共的安全协议,建立安全通道保护Q.931呼叫信令的安全。与现有技术相比,使用本发明提出的方法,在H.323多媒体通信系统中,无需预先配置Q.931呼叫信令的安全保障机制,只需经过动态协商就可以选择共有的安全协议建立Q.931呼叫信令的安全通道。在H.323系统中还存在一个终端和多个终端同时通信的情况,这与两终端间直接呼叫场景在RAS信令中的区别仅体现在接入请求(ARQ-Admissions Request)信令,而此协商选择Q.931呼叫信令安全保障机制的方法所涉及的信令为关守请求(GRQ-Gatekeeper Request)或者注册请求(RRQ-Registration Request)信令,因此本发明也同样适用于一个终端和多个终端同时通信的情况。

附图说明

图1是本发明提出方法的流程图;

图2是本发明的一个具体实施例的信令流程图。

具体实施方式

下面结合附图和实施例对本发明提出的方法作进一步详细说明。

图1是本发明提出方法的流程图,如图1所示,本发明提出的方法包括:

第一步、主叫终端与被叫终端将自身的安全机制列表发送给各自的网守;

第二步、网守收到各自终端的安全机制列表后保存到本地;

第三步、主叫终端发起接入请求(ARQ-Admissions Request),主叫终端网守收到请求后判断主叫终端网守与被叫终端的网守是否同一网守,如果是则继续,否则执行第五步;

第四步、网守比较主叫与被叫终端的安全机制列表,若存在共同支持的安全协议,则选择其中的一种,并将选择的安全协议种类发送给主叫终端;否则回复接入拒绝(ARJ-Admissions Reject)信令给主叫终端;执行第八步;

第五步、主叫终端网守将主叫终端的安全机制列表逐级转发至被叫终端网守;

第六步、被叫终端网守比较主叫与被叫终端的安全机制列表,若存在共同支持的安全协议,则选择其中的一种,并将选择的安全协议种类逐级转发至主叫终端网守;否则回复定位拒绝(LRJ-Location Reject)信令给主叫终端网守;

第七步、若主叫终端网守收到选择的安全协议种类,则将之发送给主叫终端,否则回复ARJ信令给主叫终端;

第八步、若主叫终端收到选择的安全协议种类信息,则用该公共安全协议建立主叫终端与被叫终端间的安全通道,用于保护Q.931呼叫信令的安全,否则结束。

图2是本发明的一个具体实施例的信令流程图。在这个实施例中,主叫终端与被叫终端是不同网守处注册的两终端,主叫终端为A,被叫终端为B,网守A、网守B是分别与终端A、终端B直接相连的网守。网守C是网守A的上级网守,网守D是网守B的上级网守。假设终端A支持的安全协议和安全协议的等级分别为:安全协议TLS,其安全等级为0.1级;安全协议IPSEC,其安全等级为0.2级;终端B支持的安全协议和安全协议的等级为:安全协议TLS,其安全等级为0.1级。如图2所示,结合本发明提出的方法:

1、终端A与终端B将自身的安全机制列表发送给各自的网守。终端A使用GRQ信令某一字段携带自己支持的安全协议及这些安全协议的等级(在此假定TLS安全等级为0.1,IPSEC安全等级为0.2)等相关参数发送给网守A,同理,终端B将自己支持的安全协议及这些安全协议的等级(在此假定TLS安全等级为0.1)等相关参数发送给网守B。本实施例使用GRQ信令的nonStandardData字段携带安全机制列表,nonStandardData字段格式及填写内容如下:

选用nonStandardData字段的GRQ信令格式如下(其它字段均省略):

GatekeeperRequest∷=SEQUENCE-(GRQ)

{

       ........

       nonStandardData         NonStandardParameter,

}

其中nonStandardData字段格式如下:

NonStandardParameter∷=SEQUENCE

{

      nonStandardIdentifier  NonStandardIdentifier,

      data                        OCTET STRING

}在nonStandardData字段的data成员中填写终端支持的安全协议(TLS,IPSEC等)及这些安全协议的等级。

终端也可以使用RRQ信令的某一字段携带自己支持的安全机制列表,本实施例仍然使用nonStandardData字段携带,nonStandardData字段的填写规则与GRQ信令的nonStandardData字段填写规则完全一样。

2、网守A收到终端A支持的安全机制列表(TLS,安全等级0.1;IPSEC,安全等级0.2)后保存在本地,并给终端A回应关守确认(GCF-GatekeeperConfirmation)信令。网守B收到终端B支持的安全机制列表(TLS,安全等级0.1)后保存在本地并保存在本地,并给终端B回应GCF信令。

3、终端A向网守A发起RRQ信令,网守A回应注册确认(RCF-RegistrationConfirmation)信令,终端A完成在网守A的注册过程;同理,终端B完成在网守B的注册过程。

4、网守A收到终端A发起的ARQ信令后,向下一个直接相邻的网守C发送定位请求(LRQ-Location Request)信令,并在LRQ信令中携带本地保存的终端A的安全机制列表(TLS,安全等级0.1;IPSEC,安全等级0.2),依此类推,终端A的安全机制列表被逐级转发至网守B。

5、网守B收到的终端A的安全机制列表(TLS,安全等级0.1;IPSEC,安全等级0.2)与本地保存的终端B的安全机制列表(TLS,安全等级0.1)做比较,选择TLS作为终端A和终端B之间保障Q.931呼叫信令的安全协议。并使用位置确认(LCF-Location Confirmation)信令携带TLS发送到网守D,依次类推,TLS将被逐级转发回网守A。

6、网守A收到保障Q.931呼叫信令的TLS安全协议后,使用接入确认(ACF-Admissions Confirm)信令的某一字段携带TLS发送给终端A,本实施例采用nonStandardData字段携带TLS发送给终端A;

AdmissionConfirm∷=SEQUENCE-(ACF)

{

     ........

     nonStandardData            NonStandardParameter,

}

其中nonStandardData字段格式如下:

NonStandardParameter∷=SEQUENCE

  {

    nonStandardIdentifier    NonStandardIdentifier,

    data                      OCTET STRING

  }在nonStandardData字段的data成员中填写,终端A和终端B之间共有的保障Q.931呼叫信令的TLS安全协议。

7、终端A收到ACF信令后,使用TLS在终端A和终端B之间建立安全通道,用于保护Q.931呼叫信令的安全。至此完成了Q.931呼叫信令安全保障机制选择过程。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号