路径: 主页 > GB > 第59页 > GB 33473-2016 | 标准编号 | GB 33473-2016 (GB33473-2016) | | 中文名称 | 即时通信业务HI接口总体技术要求 | | 英文名称 | General technical requirements of handover interface for instant communication services | | 行业 | 国家标准 | | 中标分类 | M19 | | 国际标准分类 | 33.030 | | 字数估计 | 13,172 | | 发布日期 | 2016-12-30 | | 实施日期 | 2017-01-01 | | 标准依据 | 国家标准公告2016年第27号 | | 发布机构 | 中华人民共和国国家质量监督检验检疫总局、中国国家标准化管理委员会 | GB 33473-2016
General technical requirements of handover interfacefor instant communication services
ICS 33.030
M19
中华人民共和国国家标准
即时通信业务HI接口总体技术要求
2016-12-30发布
2017-01-01实施
中华人民共和国国家质量监督检验检疫总局
中国国家标准化管理委员会发布
目次
前言 Ⅰ
1 范围 1
2 规范性引用文件 1
3 术语、定义和缩略语 1
4 基本要求 3
4.1 HI接口的基本原则 3
4.2 功能要求 3
5 网络架构 3
6 标识 4
6.1 目标标识 4
6.2 通信标识 4
6.3 请求标识 5
6.4 IRI序列号 5
6.5 会话子序列号 5
6.6 RD记录序号 5
6.7 CC记录序号 5
6.8 留存数据查询结果批次标识 6
7 HI接口要求 6
7.1 HI1接口要求 6
7.2 HI2接口要求 6
7.3 HI3接口要求 7
8 安全要求 8
8.1 认证要求 8
8.2 机密性要求 8
8.3 完整性要求 8
8.4 递交网络 8
附录A(规范性附录) FTP协议使用要求 9
A.1 配置设置 9
A.2 基本要求 9
A.3 FTP定时器及阈值 9
前言
本标准的全部技术内容为强制性。
本标准按照GB/T 1.1-2009给出的规则起草。
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。
本标准由中华人民共和国工业和信息化部提出。
本标准由全国通信标准化技术委员会(SAC/TC485)归口。
本标准起草单位:中国信息通信研究院。
本标准主要起草人:林美玉、姜建、吴宏建、杨彬、张远晶、吴韶鸿。
即时通信业务HI接口总体技术要求
1 范围
本标准规定了基于IP网络提供的即时通信业务 HI接口的基本要求、网络架构、标识、HI接口要
求和安全要求。
本标准适用于基于IP网络提供的即时通信业务。
2 规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仅注日期的版本适用于本文
件。凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件。
IETFRFC3325 对于会话初始协议(SIP)在可信任网络用于尚待证实的识辨私自扩展[Private
3 术语、定义和缩略语
3.1 术语和定义
下列术语和定义适用于本文件。
3.1.1
提供具有点对点、点对多点通信特征业务的服务提供商。
3.1.2
依托即时通信服务提供商提供的相关业务。
注:例如网络多媒体会话业务等。
3.1.3
网络多媒体会话业务 IPmultimediaservice
依托IP数据网,提供的点对点、点对多点实时多媒体会话业务,包括语音、视频通信等。
3.1.4
递交接口 handoverinterface
即时通信服务提供商提供的技术接口,也称为HI接口,包括HI1、HI2和HI3三个接口。
3.1.5
递交网关中处理HI1接口的功能模块。
3.1.6
中介功能模块 medicationfunction
递交网关中处理HI2和HI3接口的功能模块。
3.1.7
出于维护、测试和保护HI接口的目的,在HI2接口上发送的信息。
3.1.8
目标用户使用即时通信业务的相关信息,包括通信相关信息(如失败的通信连接尝试)、业务相关信
息(如用户进行的业务管理)和位置信息等。
3.1.9
除目标相关信息外,即时通信业务中目标用户与其他用户或网元之间交互的信息。
注:例如网络多媒体会话业务内容等。
3.1.10
留存数据 retaineddata
即时通信服务提供商在其网络内留存的与特定业务相关的数据。留存数据通常包括业务使用数
据、用户数据、设备数据、递交网关数据和计费数据等。
3.1.11
与递交网关相连,收集递交结果并对递交结果进行处理的设备。
3.1.12
从网络侧发起会话建立请求开始到本次会话结束的过程。
3.1.13
永久性标识 permanentidentity
从用户申请某种业务到注销此种业务过程中,能够在即时通信服务提供商的该业务中唯一标识一
个用户并且不会变更的标识。
注:例如用户注册时,即时通信业务提供商分配给用户的内部标识,在该用户注销之前,该标识不能够被再次分配
给其他用户使用。
3.1.14
临时性标识 temporaryidentity
能够在一段时间内暂时在即时通信服务提供商的某种业务中唯一标识一个用户并且允许变更的
标识。
注:例如即时通信业务允许用户绑定或解绑定手机号码,在绑定期内则该手机号码能够作为该用户的临时性标识,
用户可根据需要随时变更绑定的手机号码。
3.1.15
群 group
使用同一即时通信业务应用的多个用户进行临时或永久会话所使用的逻辑组。
3.2 缩略语
下列缩略语适用于本文件。
GWID 递交网关标识(GatewayIdentifier)
IP 国际互联网协议(InternetProtocol)
MF 中介功能模块(MediationFunction)
SSH 安全外壳(SecureShel)
SvP 服务提供商(ServiceProvider)
4 基本要求
4.1 HI接口的基本原则
HI接口应遵循国家相关法律法规的要求。非目标用户间的通信活动,不应触发递交功能。
不允许任何人和设备访问即时通信服务提供商(以下简称SvP)域内的敏感数据,包括LEMF的配
置信息、LEMF与递交网关之间的证书和认证参数、目标信息、SvP域内的留存数据等。在SvP网络
内,应采用必要的措施保证相关敏感数据的安全,例如加密存储等。
SvP向用户提供的业务,均应支持HI接口功能;但对于SvP尚未提供的业务以及SvP现有业务流
程中未获取的信息,并不需要通过额外的流程获取后提供。如果SvP拥有本标准规定之外的对LEA
有用的信息,可以通过相关的扩展信息字段上报。
HI接口包括HI1、HI2、HI3接口,三个接口的功能以及传递的消息内容完全不同,且应相互独立。
通信过程中,若SvP网络参与加密过程,则SvP应递交解密后的通信内容。如果加密不是由SvP
网络提供且SvP无法获取密钥,则SvP不需要解密。
若两个目标用户相互通信,则这两个目标的递交结果应分别处理上报。
随着技术的发展和需求的更新,HI接口应可扩展。
4.2 功能要求
HI接口应支持实时(准实时)递交功能,即实时(准实时)地将目标用户的活动过程与通信内容通过
HI接口递交至LEMF。HI接口应支持针对SvP域留存的数据进行查询并将查询结果递交给LEMF。
SvP通过HI接口递交的内容包括:目标相关信息(IRI)、传输相关信息(TRI)、通信内容(CC)和留
存数据(RD)等。此外,SvP应通过HI接口的指令获得递交的相关信息,包括目标标识、递交结束时间、
LEMF的地址等。
5 网络架构
图1给出了递交接口的网络架构图。
SvP域包括网元、留存数据库和递交网关,其中网元包括提供服务的所有相关业务服务器。考虑到
各SvP的网络组网形式各异,可提供的业务形式也各不相同,为方便管理,要求各SvP采用递交网关方
式集中提供递交接口,不采用每个网元单独提供递交接口的方式。递交网关包括管理功能模块 AF、
IRI中介功能模块和CC/RD的中介功能模块。留存数据库、网元和递交网关之间的接口为SvP内部网
络接口。
SvP通过HI接口与执法递交设施LEMF之间进行交互。
本标准仅规定递交网关提供的HI接口的要求,内部网络接口的要求不在本标准范围之内。
HI接口包括HI1、HI2、HI3接口三个接口。其中,HI1为管理接口,用于LEMF和递交网关之间
传递管理指令;HI2接口为目标相关信息上报接口,用于递交网关向LEMF递交IRI消息、故障告警和
心跳等维护类的TRI消息;HI3接口为通信内容和留存数据上报接口,用于递交网关向LEMF递交CC
和留存数据。
图1 递交接口架构图
6 标识
6.1 目标标识
目标标识用于在SvP域内识别特定目标,例如用户账号、内部标识等。
临时性目标标识不能用于激活目标用户的递交功能,考虑到大部分的永久性标识并非是公开的用
户标识,如果LEA不知道用户的永久性标识,需要先通过 HI接口使用临时性标识查询对应的永久性
标识,再使用永久性标识激活目标用户。
6.2 通信标识
通信标识(CID)用来区分目标的不同会话活动过程,并用于在同一个会话活动过程中关联 HI2的
IRI报告和HI3的CC内容。CID由递交网关产生。
CID由SvP标识(SvPID)、递交网关标识(GWID)和通信标识码(CIN)组成。
SvP标识用于唯一标识一个SvP的一个业务产品,由LEMF负责为每个SvP的业务产品进行分
配。SvP标识为8位定长字符串。
递交网关标识(GWID)用于分别标识主备递交网关,由SvP负责分配,为1位字符串。
通信标识码CIN用于在SvP一个业务产品的同一个递交网关内唯一标识一次目标的通信会话。
在一次会话过程中的所有递交结果都应使用相同的CIN。如果同一个目标在同一个SvP当中有两个
或更多的通信会话,每一个会话的CIN应不一样。如果两个或多个目标参与了同一次通信会话,递交
网关应为不同的目标分配相同的CIN值。
与会话相关的IRI和CC应携带CIN。满足下面三个条件的IRI消息可以不携带CIN:IRI本身与
任何目标用户的通信会话都没有关系;IRI本身与任何的CC都没有关系;IRI本身与任何其他的IRI都
没有关系。
根据具体的业务流程不同,当系统故障或意外发生的时候,同一个会话过程中的IRI-REPORT可
能产生在IRI-BEGIN消息之前,也可能产生在IRI-END消息之后,这样的IRI-REPORT也应分配同
一个通信会话中与其他HI2和HI3接口相同的CIN。
CIN的取值为0~232-1之间的数字,从0开始顺序循环编号。
6.3 请求标识
请求标识用来关联HI1接口、HI2接口的请求消息和响应消息之间的对应关系,以及关联 HI1接
口的留存数据查询请求消息和HI3接口留存数据查询结果之间的对应关系。所有消息的请求标识均
由消息的发送方产生。每类TRI消息的请求标识要求单独编号。
请求标识的取值为0~232-1之间的数字,从0开始顺序循环编号。
6.4 IRI序列号
IRI序列号用于检查HI2接口的IRI消息是否丢失。IRI序列号由递交网关产生。IRI序列号的
取值为0~264-1之间的数字,在递交网关到LEMF的一个 HI2接口连接(通信双方IP层的IP地址、
传输层端口、传输层协议确定一条连接)内,从0开始顺序循环编号。
对于会话无关的业务,IRI序列号还用于HI2接口的IRI消息和HI3接口的通信内容的关联。
6.5 会话子序列号
会话子序列号用于在一次通信会话过程中对上报的IRI消息进行标识,可用于检查一次会话过程
中IRI是否丢失。会话子序列号均由递交网关产生。
会话子序列号的取值为0~232-1之间的数字。当目标开始一个新的通信会话时,会话子序列号
从0开始顺序编号。
6.6 RD记录序号
在一次留存数据查询过程中用于标识所查询到的每一条记录。RD记录序号由递交网关产生。
RD记录序号取值为1~232-1之间的数字,所有记录按照生成的时间顺序从1开始顺序编号。当
记录序号取值为“0”时表示没有查询到记录。
6.7 CC记录序号
当通信内容通过SFTP方式递交时,在一次递交的通信内容ZIP压缩包内所有的通信内容都通过
CC记录序号标识。记录序号由递交网关产生。
CC记录序号取值为1~232-1之间的数字。ZIP压缩包内的通信内容可能是一个文件,也可能是
一条会话相关的文本消息。所有通信内容按照生成的时间顺序排序后从1开始顺序编号。
6.8 留存数据查询结果批次标识
当留存数据采用分批递交方式时,该标识用来标识每个具体的批次,具体定义见附录A.2。
7 HI接口要求
7.1 HI1接口要求
HI1接口是双向的。LEMF通过HI1接口发送递交指令,如激活、去激活等,并从HI1接口接收指
令响应信息。
对于IRI和CC的实时(准实时)的递交,需要向SvP提供如下信息:
a) 目标标识信息,用于标识被激活用户或所查询的用户;
b) 请求标识,用于标识LEMF请求消息和递交网关响应消息之间的对应关系;
c) 激活结束时间;
d) LEMFHI2地址,用于标识SvP上报IRI时所使用的LEMFHI2接口的IP地址和端口;
e) LEMFHI3地址,用于标识SvP上报CC时所使用的LEMFHI3接口的IP地址和端口;
f) 所需的其他信息。
对于留存数据的递交,需要向SvP提供如下信息:
a) 请求的优先级;
b) 查询条件,例如查询特定时间段内指定用户的特定类型的留存数据;
c) LEMFHI3地址,用于标识SvP上报留存数据时所使用的LEMFHI3接口的IP地址和端口;
d) 返回最大的记录数;
e) 分批次递交时,每批次返回的最大记录数;
f) 所需的其他信息。
7.2 HI2接口要求
7.2.1 HI2接口功能
7.2.1.1 综述
HI2接口用于递交网关向LEMF递交IRI消息以及故障告警和心跳等维护类的TRI消息。
7.2.1.2 IRI消息
目标用户通信过程相关信息都应通过IRI消息上报。HI2接口应按照IRI产生的时间和顺序依次
递交。
即时通信业务IRI消息包括以下四种类型:
---IRI-BEGIN,产生于通信请求的第一个事件,用于打开IRI事务;
---IRI-END,产生于通信结束或通信请求结束的时候,用于关闭IRI事务;
---IRI-CONTINUE,产生于一个IRI事务中的任何时刻;
---IRI-REPORT,用于会话无关的事件等。
对于会话开始的第一个事件通过IRI-BEGIN上报,会话的最后一个事件通过IRI-END上报,会话
中的其他事件通过IRI-CONTINUE上报,非会话类的事件通过IRI-REPORT上报。
针对网络多媒体会话业务,如果通信控制信令是SIP和 H.323协议,则可以选择映射成本标准规
定的合适IRI事件并通过IRI-REPORT类型递交,也可以递交原始信令并选择合适的IRI类型上报;
优先选择递交原始信令。如果通信控制信令采用除了SIP和H.323协议之外的其他协议,则目标用户
的相关活动过程应映射成本标准定义的合适IRI事件,并通过IRI-REPORT类型递交。本标准定义的
网络多媒体会话业务IRI事件包括:呼叫开始事件、呼叫振铃/回铃事件、呼叫应答事件、呼叫释放事件、
业务事件、业务操作事件。
7.2.1.3 TRI消息
TRI消息包括心跳请求、心跳响应、告警、选项协商请求、选项协商响应、选项协商结束、测试PDU、
填充PDU、信息报告等消息。
其中:
---心跳消息用于在递交网关和LEMF之间检查HI2接口的连接是否正常;
---告警消息用于递交网关向LEMF指示SvP域内相关设备或递交过程产生的告警事件;
---选项协商消息用来在递交网关与LEMF之间协商双方所支持的 TRI消息和能力,如填充
PDU等;
---测试PDU是接口测试数据包,用于确保递交网关和LEMF之间的 HI接口功能正确,测试
PDU采取端到端发送方式;
---填充PDU是一些流量填充包,包本身无具体含义,只用来改变数据流量的速率,以防止非法
用户对数据流量模型的分析;填充PDU由递交网关生成,发送到LEMF后由LEMF删除,填
充PDU需要包含SvP标识和递交网关标识,内容方面没有限制,但是原则上不允许传有意义
的内容,尤其是不允许传敏感信息;
---信息报告用于递交网关向LEMF指示SvP域内相关操作结果的报告,以及SvP域需要向
LEMF提供的其他补充信息。
递交网关应支持心跳、告警、选项协商、信息报告、测试PDU等TRI消息,可选支持填充PDU等
TRI消息。通过选项协商可确定对端支持的可选TRI消息。
7.2.2 HI2接口协议
HI2接口应采用安全可靠的、通用的机制实现递交网关与LEMF之间的消息交互,并采用加密机
制对通信交换的信息进行加密。例如可采用TCP协议完成HI2接口消息的交互,网络层采用IPsec机
制,应用层采用满足国家商用密码管理的相关要求的加密算法。
7.3 HI3接口要求
7.3.1 HI3接口功能
递交网关通过HI3接口向LEMF递交CC和留存数据。
HI3递交的CC包括实时多媒体通信内容、会话相关的消息(含文本消息)和目标用户发送或接收
的文件(含图片、音视频、视频文件等)等。
留存数据为留存数据查询结果文件。
7.3.2 HI3接口协议
对于不同的递交数据可采用不同的数据递交机制。对于实时多媒体业务CC的递交,应采用实时
性强且通用的协议,例如SIP协议;而对于非实时多媒体业务CC的递交以及留存数据的递交,应采用
适合文件传送的协议来递交,例如FTP协议。
为保证递交内容的机密性,递交的通信过程应采用加密机制。例如,对于SIP协议可采用IPSec进
行加密;对于FTP协议,可采用SFTP机制对传送的内容进行加密。
当采用SIP协议时,应遵循IETFRFC3261及IETFRFC3325等要求,也可根据需要对SIP协议
进行简化。当采用FTP协议递交时,FTP协议的相关要求见附录A。
8 安全要求
8.1 认证要求
HI接口应采用适当的机制确保HI接口通信双方的身份认证。除了应用层的双向认证之外,底层
在建立过程也可以采用底层协议已有的双向认证机制。例如如果应用层是SIP协议或是基于TCP协
议扩展的协议,可采用基于IPSec的双向认证机制;如果应用层是FTP协议则可以采用基于SSH的双
向认证机制。
递交网关和LEMF双方需要配置对方的合法地址池,只允许接收来自合法地址池的数据包。
认证过程中所采用的算法应满足国家商用密码管理的相关要求。
8.2 机密性要求
为保证HI接口递交数据的安全性,HI接口数据应进行加密。所采用的加密算法应满足国家商用
密码管理的相关要求。
8.3 完整性要求
完整性是指传输数据的任何修改和损坏都应被立即发现,保证递交内容的准确性。HI接口都应采
用相应的机制保证接口上传送数据的完整性。可利用现有协议的完整性保护机制保证 HI接口数据的
完整性,例如SSH和IPSec等。
8.4 递交网络
无论是在SvP域内还是在递交接口,递交的数据都应通过专用网络递交。递交网关与SvP网内的
其他网元之间应保证相对的安全隔离。递交网关不得直接连接互联网。
附 录 A
(规范性附录)
FTP协议使用要求
A.1 配置设置
使用FTP协议时,递交网关为FTP客户端,LEMF为FTP服务器端。FTP的相关配置参数应设
置如下:
---传输模式(Transmissionmode):流模式,即数据以字节流的方式传送;
---数据结构(Structure):采用文件结构;
---文件类型(Type):二进制文件类型,即数据发送形式为一个连续的比特流;
---文件格式(Format):不可打印;
---工作方式:被动模式。
A.2 基本要求
LEMF应为不同的递交网关配置不同的CC递交目录、留存数据递交目录。递交网关上传文件时,
上传的各类ZIP文件应增加后缀.tmp。当文件传输完毕后,递交网关将ZIP文件的.tmp后缀去掉。
数据文件的发送需支持配置时间阈值及流量阈值。具体要求见A.3。
通过FTP方式递交的场景有两种:准实时递交CC和递交留存数据。递交内容均以ZIP压缩文件
的形式递交。
当递交CC时,递交的ZIP文件命名方式为“CC-YYYYMMDDhhmmss-nnnn.zip”;
当递交留存数据时,递交的ZIP文件命名方式为“RD-rrrrrrrrrr.zip”。当留存数据采用分批递交方
式时,每个批次会产生一个ZIP文件,每个批次的ZIP文件的命名方式为“RD-rrrrrrrrrr-N.zip”。
各字段含义如下:
---YYYYMMDDhhmmss:表示生成zip文件的日期和时间,由12个ASCII数字组成;YYYY表
示年份,MM表示月份,DD表示日期,hh表示小时,mm表示分钟,ss表示秒;
---nnnn:4个ACSII数字,用于区分同一时刻生成的不同CCZIP文件;
---rrrrrrrrrr:10个ASCII字符,表示HI接口留存数据查询请求消息中携带的请求标识(请求位
数不足时,前面用0填充);
---N:留存数据查询结果的批次标识,除了最后一个批次的ZIP文件外,其他批次的N 取值为数
字,从1开始,按文件生成的时间顺序递增编号,最后一个批次的ZIP文件名的N 取值为“end”。
LEMF指示可分批递交时,分批递交机制才可使用。
......
|