CN116746185A

CN116746185A - 一种呼叫处理方法、相关设备以及通信系统

Info

Publication number: CN116746185A
Application number: CN202180087694.5A
Authority: CN
Inventors: 左俊; 林宏达; 叶进洲; 郭晓龙
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2021-01-06
Filing date: 2021-01-06
Publication date: 2023-09-12
Also published as: WO2022147693A1; US20230353569A1; EP4247032A4; EP4247032A1

Abstract

本发明实施例提供了一种呼叫处理方法、相关设备以及通信系统，其能够保证主叫设备呼叫被叫设备时，被叫设备振铃时所显示的与主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息是可信的。方法包括：网络鉴权服务器接收来自主叫设备的呼叫请求消息，呼叫请求消息包括主叫用户的第一用户标识和呼叫鉴权标识；网络鉴权服务器向第一用户标识对应的企业鉴权服务器发送呼叫鉴权请求，呼叫鉴权请求包括呼叫鉴权标识；网络鉴权服务器接收来自企业鉴权服务器的呼叫鉴权成功指示，呼叫鉴权成功指示用于指示鉴权通过；网络鉴权服务器向被叫设备发送目标数据，目标数据包括主叫用户的身份信息，和/或，主叫用户所属的企业的信息。

Description

一种呼叫处理方法、相关设备以及通信系统

技术领域

本申请涉及通信领域，尤其涉及一种呼叫处理方法、相关设备以及通信系统。

背景技术

IP多媒体子系统(IP multimedia subsystem，IMS)是一种全新的多媒体业务形式，它能够满足更新颖、更多样化多媒体业务的需求。IMS是解决移动与固网融合，引入语音、数据、视频三重融合等差异化业务的重要方式。

基于IMS，企业内部的主叫用户向企业外部的被叫用户呼叫时，主叫用户可向被叫用户发送与主叫用户相关的信息，但是，与主叫用户相关的信息的可信度比较低。

发明内容

本发明实施例第一方面提供了一种呼叫处理方法、相关设备以及通信系统，其能够在运营商网络、企业、主叫用户之间建立信任安全联盟，可保证被叫设备振铃时，所显示的呼叫名片的信息是可信的。

本发明实施例第一方面提供了一种呼叫处理方法，所述方法包括：网络鉴权服务器接收来自主叫设备的呼叫请求消息，所述主叫设备为主叫用户所使用的设备，所述呼叫请求消息包括所述主叫用户的第一用户标识和呼叫鉴权标识；所述网络鉴权服务器向所述第一用户标识对应的企业鉴权服务器发送呼叫鉴权请求，所述呼叫鉴权请求包括所述呼叫鉴权标识；所述网络鉴权服务器接收来自所述企业鉴权服务器的呼叫鉴权成功指示，所述呼叫鉴权成功指示用于指示鉴权通过；所述网络鉴权服务器向被叫设备发送目标数据，所述被叫设备为被叫用户所使用的设备，所述目标数据包括所述主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息。

可见，网络鉴权服务器向被叫设备所发送的目标数据来自企业鉴权服务器和/或企业开户数据，而非主叫用户，有效保证了向被叫设备所发送的目标数据的可信性。而且主叫用户无需在运营商网络开户的情况下，即可使用运营商网络提供的呼叫被叫用户的业务，从而避免了主叫用户在运营商网络开户所导致的主叫用户上线慢，主叫用户的个人隐私信息暴露的问题。

在一个可选地实现方式中，上述呼叫鉴权成功指示用于指示呼叫鉴权通过。

基于第一方面，一种可选地实现方式中，所述呼叫鉴权成功指示包括第二用户标识，所述网络鉴权服务器向被叫设备发送目标数据包括：所述网络鉴权服务器确定所述第一用户标识和所述第二用户标识相同，即网络鉴权服务器鉴权通过，则向所述被叫设备发送目标数据。

可见，网络鉴权服务器在确定呼叫鉴权标识鉴权通过，且确定第一用户标识和第二用户标识相同，才会向被叫设备发送目标数据，从而使得网络鉴权服务器能够对鉴权通过的主叫用户执行向被叫用户进行呼叫的过程。

基于第一方面，一种可选地实现方式中，所述网络鉴权服务器向被叫设备发送目标数据包括：所述网络鉴权服务器向所述企业鉴权服务器获取所述目标数据，向所述被叫设备发送所述目标数据。

可见，本方面所示的目标数据来自企业鉴权服务器，而非主叫用户，有效保证了向被叫设备所发送的目标数据的可信性。

基于第一方面，一种可选地实现方式中，所述网络鉴权服务器向被叫设备发送目标数据包括：所述网络鉴权服务器向所述被叫设备发送所述呼叫请求消息，所述呼叫请求消息包括所述目标数据。

基于第一方面，一种可选地实现方式中，所述网络鉴权服务器向被叫设备发送目标数据包括：所述网络鉴权服务器通过媒体面设备向所述被叫设备发送所述目标数据。

基于第一方面，一种可选地实现方式中，所述网络鉴权服务器向被叫设备发送目标数据包括：所述网络鉴权服务器向所述企业鉴权服务器获取所述目标数据，对所述目标数据进行排版，向所述被叫设备发送排版后的所述目标数据。

基于第一方面，一种可选地实现方式中，所述网络鉴权服务器向被叫设备发送目标数据包括：所述网络鉴权服务器向所述企业鉴权服务器获取所述目标数据；所述网络鉴权服务器向媒体面设备发送通知信息，所述通知信息用于指示所述媒体面设备或应用服务器对所述目标数据进行排版，并向所述被叫设备发送排版后的所述目标数据。

基于第一方面，一种可选地实现方式中，所述网络鉴权服务器接收来自主叫设备的呼叫请求消息之前，所述方法还包括：所述网络鉴权服务器接收来自所述主叫设备的注册请求消息，所述注册请求消息包括所述第一用户标识和注册鉴权标识；所述网络鉴权服务器向所述第一用户标识对应的所述企业鉴权服务器发送鉴权请求，所述鉴权请求包括所述注册鉴权标识；所述网络鉴权服务器接收来自所述企业鉴权服务器的注册鉴权成功指示，所述注册鉴权成功指示用于指示所述鉴权通过；所述网络鉴权服务器获取初始数据，所述初始数据包括所述主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息。

可见，企业内部的主叫用户向企业外部的被叫用户呼叫时，先执行注册处理流程，基于该注册处理流程，以便于后续主叫用户呼叫被叫用户时，运营商网络能够直接将该初始数据发送至被叫用户，无需在呼叫的过程中生成初始数据，缩短了呼叫处理时延，提高了呼叫效率，而且能够创建信任安全联盟所示的企业鉴权主叫用户的过程。

在一个可选地实现方式中，上述注册鉴权成功指示用于指示注册鉴权通过。

基于第一方面，一种可选地实现方式中，所述注册鉴权成功指示包括第三用户标识，所述方法还包括：所述网络鉴权服务器确定所述第一用户标识和所述第三用户标识相同，则确定鉴权通过。可见，网络鉴权服务器在确定鉴权通过，且确定第一用户标识和第三用户标识相同，才会获取该初始数据，以便于后续主叫用户呼叫被叫用户时，运营商网络能够直接将该初始数据发送至被叫设备，无需在呼叫的过程中生成初始数据，缩短了呼叫处理时延，提高了呼叫效率。

基于第一方面，一种可选地实现方式中，所述网络鉴权服务器向被叫设备发送目标数据包括：若所述网络鉴权服务器确定所述呼叫鉴权标识和所述注册鉴权标识相同，则所述网络鉴权服务器确定所述目标数据为所述初始数据。

可见，网络鉴权设备确定呼叫鉴权标识和所述注册鉴权标识相同，则能够将该初始数据发送至被叫设备，无需在呼叫的过程中生成初始数据，缩短了呼叫处理时延，提高了呼叫效率。

基于第一方面，一种可选地实现方式中，所述网络鉴权服务器向被叫设备发送目标数据包括：若所述网络鉴权服务器确定所述呼叫鉴权标识和所述注册鉴权标识不相同，则所述网络鉴权服务器接收来自所述企业鉴权服务器的所述目标数据，所述目标数据和所述初始数据互不相同。

可见，网络鉴权设备确定呼叫鉴权标识和所述注册鉴权标识不相同，则需要重新向企业鉴权服务器获取目标数据，进而将该目标数据发送至被叫设备。

基于第一方面，一种可选地实现方式中，所述方法还包括：所述网络鉴权服务器接收所述企业鉴权服务器的设备证书对应的第一电子认证服务CA证书；所述网络鉴权服务器使用所述第一CA证书创建所述网络鉴权服务器和所述企业鉴权服务器之间的安全传输层协议TLS安全连接，所述网络鉴权服务器通过所述TLS安全连接与所述企业鉴权服务器进行数据交互。

可见，在网络鉴权服务器和企业鉴权服务器之间创建TLS安全连接，有效地保证网络鉴权服务器和企业鉴权服务器之间所交互的消息的安全性，提升执行本方面所示的呼叫处理方法的过程的安全性。

本发明实施例第二方面提供了一种呼叫处理方法，所述方法包括：企业鉴权服务器接收来自网络鉴权服务器的呼叫鉴权请求，所述呼叫鉴权请求包括呼叫鉴权标识；若所述企业鉴权服务器根据所述呼叫鉴权标识确定鉴权通过，则所述企业鉴权服务器向所述网络鉴权服务器发送呼叫鉴权成功指示和目标数据，所述呼叫鉴权成功指示用于指示所述呼叫鉴权标识鉴权通过，所述目标数据包括所述主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息。

本方面所示的有益效果的说明，请参加上述第一方面所示，具体不做赘述。

基于第二方面，一种可选地实现方式中，所述企业鉴权服务器接收来自网络鉴权服务器的呼叫鉴权请求之前，所述方法还包括：所述企业鉴权服务器接收来自所述网络鉴权服务器的鉴权请求，所述鉴权请求包括注册鉴权标识；若所述企业鉴权服务器根据所述注册鉴权标识确定鉴权通过，则所述企业鉴权服务器向所述网络鉴权服务器发送注册鉴权成功指示和初始数据，所述初始数据包括所述主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息。

基于第二方面，一种可选地实现方式中，若所述呼叫鉴权标识和所述注册鉴权标识不相同，则所述企业鉴权服务器向所述网络鉴权服务器发送所述目标数据，所述目标数据和所述初始数据互不相同。

基于第二方面，一种可选地实现方式中，所述方法还包括：所述企业鉴权服务器接收所述网络鉴权服务器的设备证书对应的第二电子认证服务CA证书；所述企业鉴权服务器使用所述第二CA证书创建所述企业鉴权服务器和所述网络鉴权服务器之间的安全传输层协议TLS安全连接，所述企业鉴权服务器通过所述TLS安全连接与所述网络鉴权服务器进行数据交互。

基于第二方面，一种可选地实现方式中，所述企业鉴权服务器接收来自网络鉴权服务器的呼叫鉴权请求之后，所述方法还包括：若所述企业鉴权服务器根据所述呼叫鉴权标识确定鉴权未通过，则所述企业鉴权服务器向所述网络鉴权服务器发送鉴权无效通知信息，所述鉴权无效通知信息用于指示鉴权未通过。

基于第二方面，一种可选地实现方式中，所述企业鉴权服务器接收来自网络鉴权服务器的呼叫鉴权请求之前，所述方法还包括：所述企业鉴权服务器接收来自所述主叫设备的第一用户标识，所述第一用户标识为所述主叫用户的标识；所述企业鉴权服务器向所述主叫设备发送与所述第一用户标识对应的所述呼叫鉴权标识。

基于第二方面，一种可选地实现方式中，所述企业鉴权服务器接收来自网络鉴权服务器的鉴权请求之前，所述方法还包括：所述企业鉴权服务器接收来自所述主叫设备的第一用户标识，所述第一用户标识为所述主叫用户的标识；所述企业鉴权服务器向所述主叫设备发送与所述第一用户标识对应的所述注册鉴权标识。

本发明实施例第三方面提供了一种呼叫处理方法，所述方法包括：主叫设备从企业鉴权服务器获取主叫用户的注册鉴权标识，所述主叫设备向IMS网络发送注册请求，所述注册请求包括所述主叫用户的第一用户标识和所述注册鉴权标识；所述主叫设备接收所述IMS网络发送的鉴权成功的响应消息。

本方面所示的有益效果的说明，请参见上述第一方面所示，具体不做赘述。

基于第三方面，一种可选地实现方式中，所述主叫设备从企业鉴权服务器获取主叫用户的注册鉴权标识之前，所述方法还包括：所述主叫设备向企业鉴权服务器发送登录请求，所述登录请求包括所述第一用户标识。

本发明实施例第四方面提供了一种呼叫处理方法，所述方法包括：主叫设备向IMS网络发送呼叫请求消息，所述呼叫请求消息包括使用所述主叫设备的主叫用户的第一用户标识和呼叫鉴权标识；所述主叫设备接收来自被叫设备的呼叫响应消息，所述被叫设备为被叫用户所使用的设备；所述主叫设备根据所述呼叫响应消息接通与所述被叫设备之间的呼叫。

本发明第四方面提供了一种呼叫处理的方法，应用服务器接收来自网络鉴权服务器的主叫用户的身份信息和/或所述主叫用户所属的企业的信息；应用服务器获取呼叫名片，所述呼叫名片包括所述主叫用户的身份信息和/或所述主叫用户所属的企业的信息的呼叫名片。

基于第四方面，一种可选地实现方式中，所述应用服务器获取呼叫名片包括：所述应用服务器接收来自网络鉴权服务器的所述主叫用户身份信息、所述主叫用户所属的企业的信息以及呼叫名片的排版方式；所述应用服务器将所述主叫用户身份信息、所述主叫用户所属的企业的信息以及呼叫名片的排版方式转发给媒体面设备，所述媒体面设备用于对所述主叫用户身份信息和所述主叫用户所属的企业的信息按照所述呼叫名片的排版方式进行排版以获取呼叫名片。

基于第四方面，一种可选地实现方式中，所述应用服务器获取呼叫名片包括：所述应用服务器接收来自所述网络鉴权服务器的所述呼叫名片。

本发明实施例第五方面提供了一种网络鉴权服务器，包括相互耦合的处理器和存储器，所述存储器中存储了计算机程序代码，所述处理器调用并执行所述存储器中的计算机程序代码，使得所述处理器执行如上述第一方面任一项所述的方法。

本发明实施例第六方面提供了一种企业鉴权服务器，包括相互耦合的处理器和存储器，所述存储器中存储了计算机程序代码，所述处理器调用并执行所述存储器中的计算机程序代码，使得所述处理器执行如上述第二方面任一项所述的方法。

本方面实施例第七方面提供了一种主叫设备，包括相互耦合的处理器和存储器，所述存储器中存储了计算机程序代码，所述处理器调用并执行所述存储器中的计算机程序代码，使得所述处理器执行如上述第三方面任一项所述的方法。

本方面实施例第八方面提供了一种应用服务器，包括相互耦合的处理器和存储器，所述存储器中存储了计算机程序代码，所述处理器调用并执行所述存储器中的计算机程序代码，使得所述处理器执行如上述第四方面任一项所述的方法。

本方面实施例第九方面提供了一种通信系统，包括网络鉴权服务器以及企业鉴权服务器，所述网络鉴权服务器如上述第五方面所示，所述企业鉴权服务器如上述第六方面所示。

基于第九方面，一种可选地实现方式，所述通信系统还包括主叫设备和应用服务器，所述主叫设备如上述第七方面所示，所述应用服务器如上述第八方面所示。

附图说明

图1为本申请所提供的通信系统的一种实施例结构示例图；

图2为本申请所提供的通信系统执行开户的过程的一种实施例步骤流程图；

图3为本申请所提供的通信系统执行注册的过程的一种实施例步骤流程图；

图4为本申请所提供的通信系统执行呼叫的过程的一种实施例步骤流程图；

图5为本申请所提供的通信系统执行呼叫的过程的另一种实施例步骤流程图；

图6为本申请所提供的通信系统执行注册的过程的另一种实施例步骤流程图；

图7为本申请所提供的通信系统执行呼叫的过程的另一种实施例步骤流程图；

图8为本申请所提供的通信系统执行呼叫的过程的另一种实施例步骤流程图；

图9为本申请所提供的网络设备的一种实施例结构示例图；

图10为本申请所提供的网络设备的另一种实施例结构示例图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本申请中出现的术语“和/或”，可以是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的实施例能够以除了在这里图示或描述的内容以外的顺序实施。

本申请提供了一种呼叫处理方法，为更好的理解本申请所提供的呼叫处理方法，以下首先结合图1所示对本申请所示的方法所应用的通信系统的结构进行说明：

本实施例所示的通信系统包括依次连接的运营商管理设备111、运营商网络120以及企业网络130，本实施例对运营商网络120的具体网络类型不做限定，例如，该运营商网络120的网络类型为IMS、第三代合作伙伴计划(3rd generation partnership project，3GPP)或中国通信标准化协会(china communications standards association，CCSA)，以及未来出现的任意网络架构。以下本申请各实施例以运营商网络120为IMS为例。

以下对该运营商网络120所包括的各个网元进行说明，需明确的是，本实施例对各个网元类型的说明为可选地示例性，不做限定。

本实施例所示的运营商网络120包括网络鉴权服务器121，本实施例所示的网络鉴权服务器还可称之为第三方账号管理(thirdparty account management，TAM)设备。

网络鉴权服务器121连接有网元122、网元123以及网元124，其中，网元122集成有多媒体资源功能控制器(multimedia resource function controller，MRFC)以及多媒体资源功能处理器(multimedia resource function processor，MRFP)。网元123为应用服务器(application server，AS)。网元124集成有查询-呼叫会话控制功能(interrogating-call session control function，I-CSCF)以及服务-呼叫会话控制功能(serving-call session control function，S-CSCF)。其中，网元可以称为设备。

网元124连接有网元125以及网元126，其中，该网元125为互通会话边界控制器(interconnect-session border controller，I-SBC)，该网元126集成有接入会话边界控制器(access-session border controller，A-SBC)以及代理-呼叫会话控制功能(proxy-call session control function，P-CSCF)。

以下对本实施例所示的企业网络130的结构进行说明，需明确的是，本实施例对该企业网络130的说明为可选地示例，不做限定。

该企业网络130具体包括企业鉴权服务器131、企业接入代理设备132以及主叫终端133，其中，企业鉴权服务器131分别与网络鉴权服务器121、企业接入代理设备132以及主叫终端133连接。该企业接入代理设备132与网元125或网元126连接，该主叫终端133与网元126连接。

其中，该主叫终端133可为智能终端、计算机中的任一设备。该主叫终端内置IMS软件开发工具包(software development kit，SDK)，以实现本申请所示的呼叫处理流程。

基于图1所示的通信系统，以下对该通信系统执行呼叫处理方法的各个实施例进行说明，为更好的理解本申请所示的各个实施例，首先对本申请所示的呼叫处理方案所要实现的目的进行概述性说明：

本申请所示的呼叫处理方法，主叫用户在对被叫用户进行呼叫的时候，可向被叫用户发送呼叫名片，被叫用户所使用的被叫设备在振铃的时候，即可显示该呼叫名片。该呼叫名片包括与主叫用户相关的信息，和/或，该呼叫名片包括与主叫用户所属的企业相关的信息，对呼叫名片的具体内容不做限定。本申请能够保证在主叫用户呼叫被叫用户的过程中，向被叫用户发送的该呼叫名片是可信的，避免被叫用户接收到不可信的数据。

为保证主叫用户向被叫用户所发送的呼叫名片的可信性，则本申请所示的呼叫处理方法能够创建信任安全联盟，该信任安全联盟是指，运营商网络鉴权企业，企业鉴权主叫用户(可以理解，该主叫用户为该企业的员工)，可见，若企业被运营商网络鉴权通过，主叫用户被企业鉴权通过，那么，运营商网络可信任来自企业的数据，企业可信任来自主叫用户的数据，运营商网络基于可信任的来自企业的数据即可构造可信任的呼叫名片，从而保证运营商网络向被叫用户所发送的呼叫名片的可信性。

需明确的是，上述对信任安全联盟所包括的对象的说明为可选地示例，不做限定，例如，该信任安全联盟还可指，运营商网络鉴权第三方网络，第三方网络鉴权企业，企业鉴权主叫用户，其中，该第三方网络可为企业租用的用于执行呼叫相关业务的网络，例如，该第三方网络可为软件即服务(software-as-a-service SaaS)平台。可见，若第三方网络被运营商网络鉴权通过，企业被第三方网络鉴权通过，主叫用户被企业鉴权通过，那么，运营商网络可信任来自第三方网络的数据，第三方网络可信任来自企业的数据，企业可信任来自主叫用户的数据，运营商网络基于可信任的来自第三方网络的数据即可构造可信任的呼叫名片，从而保证运营商网络向被叫用户所发送的呼叫名片的可信性。

下述各个实施例以信任安全联盟是指运营商网络鉴权企业，企业鉴权主叫用户为例进行说明：

实施例一

本实施例说明基于图1所示的通信系统，对企业开户的过程进行说明，通过本实施例所示的企业开户的过程，能够创建信任安全联盟所示的运营商网络鉴权企业的过程，具体参见图2所示，其中，图2为本申请所提供的通信系统执行开户的过程的一种实施例步骤流程图。

步骤201、运营商管理设备接收来自企业的开户申请资料。

本实施例中，在企业确定需要基于上述信任安全联盟向被叫用户发送可信任的呼叫名片的情况下，企业预先在运营商处开户，开户的过程是指企业到运营商营业厅申请鉴权，提交企业的开户申请资料，运营商运营人员核实后通过鉴权，在运营商管理设备内开通企业账户。

本实施例对开户申请资料不做限定，只要运营商运营人员能够基于该开户申请资料对该企业是否可信任进行鉴权即可。

步骤202、运营商管理设备向网络鉴权服务器发送企业开户数据。

运营商运营人员通过运营商管理设备向网络鉴权服务器发送企业开户数据，该企业开户数据可包括如下所示的一项或多项：

企业认证的域名、企业鉴权服务器的设备证书对应的第一电子认证服务(certificate authority，CA)证书、企业可信信息、企业签约的业务信息、呼叫名片的排版方式、企业的初始过滤准则(initial filter criteria，iFC)信息等。

其中，企业可信信息可为企业名称、企业商标(LOGO)、与企业相关的图片、与企业相关的音频、或与企业相关的视频等。企业签约的业务信息可为企业默认的呼叫权限，该默认的呼叫权限可为企业内的员工具有内呼的权限或企业外呼的权限，企业内呼的权限是指企业内员工之间的呼入和呼出，企业外呼的权限为企业内部的员工和企业外部的人员之间的呼入和呼出。iFC信息可为iFC模板标识(ID)或iFC内容，iFC模板ID与iFC内容对应，即在获取到iFC模板ID的情况下，即可获取到对应的iFC内容，iFC内容用于运营商网络触发对应的业务，例如，补充业务、智能业务、彩铃业务、彩振业务等。

该呼叫名片的排版方式是指，所生成的呼叫名片中，所述主叫用户的身份信息的显示方式以及显示位置，和/或，所述主叫用户所属的企业的信息的显示方式以及显示位置。

其中，主叫用户所属的企业的信息可为如下所示的一项或多项：

企业名称、企业LOGO、与企业相关的图片、与企业相关的音频或与企业相关的视频。

主叫用户的身份信息可为如下所示的一项或多项：

主叫用户的名称、工号、头像、主叫用户的职位信息等，其中，该主叫用户的名称可为主叫用户的姓名，也可为主叫用户的昵称等，具体在本实施例中不做限定。

可见，基于该呼叫名片的排版方式，即可确认企业名称、企业LOGO、与企业相关的图片、与企业相关的音频、与企业相关的视频、主叫用户的名称、工号、头像等信息，在呼叫名片中的显示方式以及显示位置。在生成呼叫名片的过程中，即可将企业相关信息和主叫用户相关信息，按照呼叫名片的排版方式进行排版以获取该呼叫名片。

步骤203、企业鉴权服务器配置预设呼叫信息。

本实施例中，企业在运营商网络的鉴权通过后，企业在企业鉴权服务器输入配置指令，企业鉴权服务器即可根据配置指令进行预设呼叫信息的配置，该预设呼叫信息可包括如下所示的一项或多项：

网络鉴权服务器的设备证书对应的第一CA证书、企业内部的员工的用户标识(User ID)与外呼号码的对应关系、企业内部的员工的呼叫权限。

针对企业内部的员工的呼叫权限，可针对不同的员工配置不同的呼叫权限，例如，员工A仅具有与企业内部的员工之间的内呼和外呼的权限，又如，员工B具有与企业外部的被叫用户之间的内呼和外部的权限等，具体不做限定。

实施例二

本实施例说明基于图1所示的通信系统，企业内部的主叫用户为向企业外部的被叫用户呼叫时，先执行注册处理流程，基于该注册处理流程，将包括主叫用户的身份信息和/或主叫用户所属的企业的信息的初始数据，按照呼叫名片的排版方式进行排版以获取初始呼叫名片，以便于后续主叫用户呼叫被叫用户时，运营商网络能够直接将该初始呼叫名片发送至被叫用户，无需在呼叫的过程中获取该初始呼叫名片，节省了呼叫过程中运营商网络与企业鉴权服务器之间所交互的信息量，缩短了呼叫接续时延，提高了呼叫效率，而且基于本实施例所示的方法，能够创建信任安全联盟所示的企业鉴权主叫用户的过程，具体参见图3所示，其中，图3为本申请所提供的通信系统执行注册的过程的一种实施例步骤流程图。

步骤301、主叫设备向企业鉴权服务器发送登录请求。

本实施例所示的主叫设备可为主叫终端或企业接入代理设备。该主叫终端可运行企业应用程序(APP)，该主叫终端通过该企业APP能够实现本申请所示的呼叫处理方法中，由主叫设备执行的流程。

主叫用户对企业外部的被叫用户进行呼叫时，可通过主叫设备向企业鉴权服务器发送该登录请求，该登录请求包括该主叫用户的第一用户标识。

本实施例所示的第一用户标识(也可称之为UserID)可为该主叫用户的邮箱地址，例如，zhangsan@xxx.com。本实施例所示的第一用户标识有别于运营商网络现有的E.164号码，可见，该第一用户标识对运营商网络而言属于异构标识，本申请所示的主叫用户向被叫用户进行呼叫的过程，所使用的不是E.164号码，而是本实施例所提供的作为异构标识的第一用户标识(即主叫用户的邮箱地址)。

步骤302、主叫设备接收来自企业鉴权服务器的注册鉴权标识。

本实施例所示的企业鉴权服务器接收到该第一用户标识，即可为该第一用户标识分配注册鉴权标识，该注册鉴权标识用于注册至运营商网络。

本实施例对注册鉴权标识不做限定，本实施例以该注册鉴权标识为令牌(token)为例进行示例性说明。

步骤303、主叫设备向S-CSCF发送注册请求。

其中，所述注册请求包括所述主叫用户的第一用户标识和所述注册鉴权标识。

本实施例所示的注册请求为会话发起协议(session initiation protocol，SIP)注册(REGISTER)消息，该注册请求需要携带主叫用户的第一用户标识和所述注册鉴权标识。

以下对本实施例所示的SIP REGISTER消息进行说明：

本实施例所示的该SIP REGISTER消息所使用的SIP用户标识格式可为<UserID>@<固定域名>。

本实施例所示的第一用户标识UserID以zhangsan@xxx.com为例，本示例通过SIP用户标识用于携带第一用户标识，该SIP用户标识可为zhangsan@xxx.com@2b.ims.<operator>.com，其中，2b.ims.<operator>.com为运营商网络为基于异构标识(即第一用户标识)接入运营商网络的统一定义的固定域名。

因SIP协议所规定的消息中不能够包括两个“@”，则主叫设备可对UserID(如zhangsan@xxx.com)中的“@”进行转义，本实施例对转义的具体规则的说明为可选地示例，不做限定，例如，主叫设备将UserID中的“@”转义为“％40”。

本实施例所示的token可使用基于64个可打印字符来表示二进制数据(Base64)的编码格式,该token可通过授权(Authorization)头域和扩展的鉴权方式(如Bearer)携带,如消息格式可为：Authorization:Bearer<Base64(<token>)>。

例如，该SIP REGISTER消息具体可为如下所示：

SIP REGISTER:2b.ims.<operator>.com

From/To:SIP zhangsan％40xxx.com@2b.ims.<operator>.com

Authorization:Bearer<Base64(<token>)>

以下对主叫设备向S-CSCF发送注册请求的过程进行说明：

参见图1所示，以主叫设备为主叫终端133为例，主叫终端133向网元126(具体地为P-CSCF)发送该注册请求，P-CSCF再转发该注册请求至网元124(具体为I-CSCF)，I-CSCF再转发该注册请求至S-CSCF，其中，P-CSCF和I-CSCF按照SIP用户注册的标准流程(参见3GPP TS 24.229)处理SIP REGISTER消息后转发给S-CSCF。

步骤304、S-CSCF向网络鉴权服务器发送第一用户标识和注册鉴权标识。

S-CSCF判断注册请求使用Bearer的鉴权方式时，向网络鉴权服务器发送第一用户标识和注册鉴权标识，以请求网络鉴权服务器利用注册鉴权标识对主叫用户进行鉴权。

本实施例所示的S-CSCF通过超文本传输安全协议(hyper text transfer protocol over secure socket layer，HTTPS)请求消息向网络鉴权服务器发送第一用户标识和注册鉴权标识，该HTTPS请求消息可为如下所示：

HTTPS POST统一资源标识符(uniform resource identifier，URI)＝TAMBaseRealm/zhangsan％40xxx.com@2b.ims.<operator>.com/open-authorize{“token”}

其中，消息中的“TAMBaseRealm”用于指示网络鉴权服务器对本消息执行本实施例所示的注册流程，“zhangsan％40xxx.com”为第一用户标识，“token”为注册鉴权标识。

步骤305、网络鉴权服务器向企业鉴权服务器发送鉴权请求。

本实施例所示的网络鉴权服务器接收到该第一用户标识的情况下，即可根据该第一用户标识确定出对应的企业鉴权服务器。

由上述示例可知，本实施例所示的第一用户标识为用户的邮箱地址(例如，zhangsan@xxx.com)，则网络鉴权服务器即可在第一用户标识中获得企业域名(例如xxx.com)。网络鉴权服务器根据该企业域名即可查询出企业鉴权服务器的地址。

具体地，由上述所示可知，网络鉴权服务器从S-CSCF接收到的第一用户标识为zhangsan％40xxx.com，本步骤所示的网络鉴权服务器在根据第一用户标识确定对应的企业鉴权服务器的过程中，企业鉴权服务器对被转义的第一用户标识(zhangsan％40xxx.com)进行恢复以获取到恢复转义后的第一用户标识(zhangsan@xxx.com)。可见，网络鉴权服务器即可根据恢复转义后的第一用户标识查询出对应的企业鉴权服务器的地址。

本实施例所示的网络鉴权服务器向所述企业鉴权服务器所发送的鉴权请求包括注册鉴权标识。

可选地，本实施例所示可通过HTTPS发送所述鉴权请求。

本实施例中，为保证网络鉴权服务器和企业鉴权服务器之间所交互的消息的安全性，提升执行本申请所示的呼叫处理方法的过程的安全性，则本实施例所示的网络鉴权服务器和企业鉴权服务器之间可创建传输层安全性协议(transport layer security，TLS)安全连接，基于该TLS连接，有效地保证了网络鉴权服务器和企业鉴权服务器之间所交互的消息的安全性。

以下对网络鉴权服务器和企业鉴权服务器之间创建TLS安全连接的过程进行示例性说明：

网络鉴权服务器接收企业鉴权服务器的设备证书对应的第一CA证书，企业鉴权服务器接收网络鉴权服务器的设备证书对应的第二CA证书，具体地，本实施例所示的第一CA证书可为实施例一中，由运营商管理设备向网络鉴权服务器发送的。

所述网络鉴权服务器使用所述第一CA证书，所述企业鉴权服务器使用所述第二CA证书，创建所述企业鉴权服务器和所述网络鉴权服务器之间的TLS安全连接，以保障网络鉴权服务器和企业鉴权服务器之间所交互的消息的安全性。

例如，该鉴权请求可为如下所示：

HTTPS GET URI＝BaseRealm/zhangsan％40xxx.com@2b.ims.<operator>.com/token

其中，消息中的“token”为注册鉴权标识。

步骤306、企业鉴权服务器判断注册鉴权标识是否有效，若否，则执行步骤307，若是，则执行步骤308。

本实施例所示的注册鉴权标识为token，则企业鉴权服务器即可判断该token是否位于有效期内，该有效期可为绝对有效期，例如，该有效期的起始时刻为A1，该有效期的终止时刻为A2，该A1时刻和A2时刻可为任意互不相同的两个时刻。若企业鉴权服务器判断出该token位于该有效期内，则企业鉴权服务器确定该token有效，若企业鉴权服务器判断出该token位于该有效期之外，则企业鉴权服务器确定该token无效。

又如，该有效期可为剩余有效时长，可见，若注册鉴权标识对应的剩余有效时长还有剩余时间，则企业鉴权服务器判断该token有效，若注册鉴权标识对应的剩余有效时长已无剩余时间，则企业鉴权服务器判断该token失效。

步骤307、企业鉴权服务器向网络鉴权服务器发送鉴权标识无效通知。

具体地，本实施例所示的企业鉴权服务器通过该TLS安全连接，向网络鉴权服务器发送该鉴权标识无效通知，该鉴权标识无效通知用于指示该注册鉴权标识(token)无效。网络鉴权服务器接收到该鉴权标识无效通知的情况下，则不再执行与主叫用户注册的相关流程。

步骤308、企业鉴权服务器向网络鉴权服务器发送鉴权成功指示。

本实施例所示的鉴权成功指示包括鉴权标识有效通知，该鉴权标识有效通知用于指示该注册鉴权标识(token)有效。

本实施例所示的鉴权成功指示还包括第三用户标识，具体地，企业鉴权服务器预先创建不同的用户标识和不同的鉴权标识的对应关系，在企业鉴权服务器确定该注册鉴权标识有效的情况下，企业鉴权服务器即可将该有效的注册鉴权标识对应的第三用户标识发送至网络鉴权服务器。

可选地，本实施例所示的企业鉴权服务器可通过HTTPS协议发送所述鉴权成功指示。

本实施例所示的鉴权成功指示可为如下所示：

HTTPS 200{“tokenTimeout”:“XXX”,“employeeName”:“zhangsan”,“employeeAyatarUri”:“http:123.123.123234.JPG”“employeeId”:“123234”,“calloutRight”:“true”}

其中，“tokenTimeout”:“XXX”用于指示注册鉴权标识的有效期，“employeeName”: “zhangsan”是指主叫用户的名称是zhangsan，“employeeAyatarUri”:“http:123.123.123234.JPG”可指，主叫用户的头像的下载地址，需明确的是，该鉴权成功指示包括主叫用户的头像的下载地址为例，在其他示例中，还可包括其他信息，具体不做限定，“calloutRight”:“true”是指，该主叫用户具有外呼的权限。

步骤309、网络鉴权服务器向应用服务器发送初始数据。

本实施例中，在网络鉴权服务器确定主叫用户通过鉴权的情况下，网络鉴权服务器即可将已获取到的初始数据向应用服务器发送。

本实施例所述的初始数据包括所述主叫用户的身份信息以及所述主叫用户所属的企业的信息。其中，所述主叫用户的身份信息来自所述企业鉴权服务器。

以下对网络鉴权服务器获取主叫用户所属的企业的信息的可选方式进行说明：

方式1：

因在实施例一所示的企业开户的阶段，经由步骤202所示，网络鉴权服务器已接收到来自运营商管理设备的企业开户数据，则本实施例中，网络鉴权服务器即可确定与该企业鉴权服务器对应的企业开户数据，以确定企业开户数据中的部分或全部信息为主叫用户所属的企业的信息。

方式2：

本方式所示的网络鉴权服务器从企业鉴权服务器接收主叫用户所属的企业的信息。

本实施例所示的企业鉴权服务器可在实施例一所示的企业开户阶段，获取该主叫用户所属的企业的信息，企业鉴权服务器也可预先存储该主叫用户所属的企业的信息，并在企业鉴权服务器判断注册鉴权标识有效的情况下，向网络鉴权服务器发送该主叫用户所属的企业的信息。

本实施例所示的网络鉴权服务器确定主叫用户通过鉴权的方式有可选地两种：

方式1：

所述网络鉴权服务器确定通过鉴权的条件有两个，一个条件是根据已接收到鉴权标识有效通知。另一个条件是该网络鉴权服务器确定第一用户标识和第三用户标识相同。

本实施例所示的所述初始数据用于应用服务器触发主叫用户对被叫用户的呼叫，其中，该主叫用户的用户数据包括但不限于：呼叫权限、对外号码、主叫用户的名称等(相关的消息遵循3GPP标准协议29.562)。

方式2：

所述网络鉴权服务器向企业鉴权服务器发送的鉴权请求同时包括所述第一用户标识，所述企业鉴权服务器在判断所述注册鉴权标识有效且所述第一用户标识和所述第三用户标识相同，则向网络鉴权服务器发送注册鉴权成功指示。

以下对网络鉴权服务器向应用服务器发送初始数据的具体过程进行说明：

首先，网络鉴权服务器判断主叫用户通过鉴权时，缓存主叫用户的身份信息，并向S-CSCF返回鉴权成功响应，该鉴权成功响应包括该token的有效期。

本实施例所示的鉴权标识有效通知可为HTTPS 200消息，对具体消息类型的说明为可选地示例，不做限定。

例如，该HTTPS 200可为：HTTPS 200{“tokenTimeOut”:“XXX”}，其中，“tokenTimeout”:“XXX”用于指示注册鉴权标识的有效期。

其次，S-CSCF与网络鉴权服务器交互完成主叫用户注册至运营商网络，S-CSCF从网络鉴权服务器下载iFC信息(相关的消息遵循3GPP标准协议29.562)。

再次，S-CSCF通过P-CSCF向主叫设备返回注册成功响应，所述注册成功响应用于指示所述主叫用户已成功注册至运营商网络。

再次，S-CSCF根据iFC信息向应用服务器发送第三方注册请求。

再次，应用服务器根据第三方注册请求从网络鉴权服务器下载所述初始数据。

步骤310、应用服务器获取初始呼叫名片。

本实施例所示的初始呼叫名片为初始数据按照呼叫名片的排版方式进行排版所形成的名片信息。

所述呼叫名片的排版方式、所述主叫用户的身份信息以及所述主叫用户所属的企业的信息的具体说明，请详见实施例一所示，具体在本实施例中不做赘述。

以下对本实施例所示的应用服务器获取该初始呼叫名片的几种可选地方式进行示例性说明：

方式1：

应用服务器接收来自网络鉴权服务器的所述主叫用户身份信息、主叫用户所属的企业的信息以及呼叫名片的排版方式，并将主叫用户身份信息、主叫用户所属的企业的信息以及呼叫名片的排版方式转发给媒体面设备(如图1所示的网元122)。

所述媒体面设备即可对主叫用户身份信息和主叫用户所属的企业的信息按照呼叫名片的排版方式进行排版以获取初始呼叫名片。

本实施例所示的主叫用户的身份信息可为如下所示的一项或多项：

主叫用户的姓名、主叫用户的头像、主叫用户的工号、主叫用户的呼叫权限、主叫用户对应的对外号码、主叫用户的呼叫意图等。其中，该对外号码为主叫用户的E.164号码。

该呼叫意图用于指示主叫用户呼叫被叫用户的意图的概述，具体在本实施例所示的方法应用至不同的场景下，该呼叫意图有所不同，具体在本实施例中不做限定。例如，若主叫用户所属的企业为房产公司，则该呼叫意图可为：“推荐A楼盘的待出售信息”。

若本实施例所述的主叫用户的身份信息不包括该主叫用户的呼叫权限，则网络鉴权服务器可确定该主叫用户对应的呼叫权限为企业默认的呼叫权限，对默认的呼叫权限的说明，请详见实施例一所示，具体在本实施例中不做赘述。

本实施例所示的主叫用户所属的企业的信息可为如下所示的一项或多项：

企业可信信息、企业签约的业务信息、呼叫名片的排版方式、或企业的iFC信息，对各信息的具体说明请参见实施例一的所示，具体不做赘述。

媒体面设备将已生成的初始呼叫名片发送至文件服务器进行存储，并将初始呼叫名片的存储地址发送给应用服务器。

可选地，在其他示例中，也可由应用服务器直接对主叫用户身份信息和主叫用户所属的企业的信息按照呼叫名片的排版方式进行排版以获取初始呼叫名片，所述应用服务器将已生成的初始呼叫名片发送至文件服务器进行存储，并本地记录该初始呼叫名片的存储地址。

方式2：

本方式中，网络鉴权服务器获取所述主叫用户身份信息、主叫用户所属的企业的信息以及呼叫名片的排版方式，并按照呼叫名片的排版方式对主叫用户身份信息和主叫用户所属的企业的信息进行排版以生成初始呼叫名片。

本实施例所示的网络鉴权服务器获取呼叫名片的排版方式的具体过程，可参见上述所示的网络鉴权服务器获取所述主叫用户所属的企业的信息的过程，具体不做赘述。

网络鉴权服务器向应用服务器发送该初始呼叫名片方式可为，网络鉴权服务器将所述初始呼叫名片存储至文件服务器，网络鉴权服务器将初始呼叫名片的存储地址发送给应用服务器，所述应用服务器即可根据该地址从文件服务器下载该初始呼叫名片。

采用本实施例所示的方法，企业内部的主叫用户向企业外部的被叫用户呼叫时，先执行注册处理流程，基于该注册处理流程，将包括主叫用户的身份信息和/或主叫用户所属的企业的信息的初始数据，按照呼叫名片的排版方式进行排版以获取初始呼叫名片，以便于后续主叫用户呼叫被叫用户时，运营商网络能够直接将该初始呼叫名片发送至被叫用户，无需在呼叫的过程中生成呼叫名片，缩短了呼叫处理时延，提高了呼叫效率，而且基于本实施例所示的方法，能够创建信任安全联盟所示的企业鉴权主叫用户的过程。

而且本实施例所示的方法，主叫用户无需在运营商网络开户的情况下，即可使用运营商网络提供的呼叫被叫用户的业务，可见，本实施例所示的方法，主叫用户能够在免开户的情况下实现对被叫用户的呼叫，解决企业租用运营商网络存在的企业员工(即主叫用户)开户问题，从而避免了主叫用户在运营商网络开户所导致的主叫用户上线慢，主叫用户的个人隐私信息暴露的问题。

实施例三

本实施例说明基于图3所示的方法，在主叫用户已注册至运营商网络的情况下，主叫用户如何使用主叫设备实现对被叫用户的呼叫。具体参见图4所示，其中，图4为本申请所提供的通信系统执行呼叫的一种实施例步骤流程图。

步骤401、主叫设备向S-CSCF发送第一呼叫请求消息。

在主叫用户确定需要呼叫被叫用户时，所述主叫用户即可通过该主叫设备向S-CSCF发送第一呼叫请求消息，以触发主叫用户对被叫用户的呼叫。

所述第一呼叫请求消息可为SIP INVITE消息，该SIP INVITE消息包括所述主叫用户的第一用户标识和呼叫鉴权标识，对第一用户标识和呼叫鉴权标识的说明，请参见实施例二所示的对主叫用户的用户标识和注册鉴权标识的说明，具体不做赘述。

以下对主叫设备向S-CSCF发送第一呼叫请求消息的过程进行说明：

主叫设备向P-CSCF发送该SIP INVITE消息，P-CSCF按照SIP用户始发呼叫的标准流程(参见3GPP TS 24.229和3GPP TS 26.114)处理该SIP INVITE消息后转发给S-CSCF。

本实施例所示的SIP INVITE消息的格式示例可参见如下所示：

INVITE tel:+86139XXXXXXXXX

From：<sip：zhangsan％40xxx.com@2b.ims.<operator>.com>

To：<tel:+86139XXXXXXXXX>

Authorization:Bearer<Base64(<token>)>

其中，“+86139XXXXXXXXX”为被叫用户的号码，对SIP INVITE消息其他内容的说明，请参见实施例二所示，具体在实施例中不做赘述。

步骤402、S-CSCF判断呼叫鉴权标识满足第一预设条件时，执行步骤403，S-CSCF判断呼叫鉴权标识满足第二预设条件时，执行步骤404，S-CSCF判断呼叫鉴权标识满足第三预设条件时，执行步骤408。

若所述S-CSCF判断呼叫鉴权标识和目标鉴权标识相同，且所述目标鉴权标识已失效，确定该呼叫鉴权标识满足该第一预设条件。该目标鉴权标识为所述S-CSCF在实施例二所示的注册阶段所缓存的注册鉴权标识，或为主叫用户前一次呼叫中所使用的鉴权标识。

若所述S-CSCF判断呼叫鉴权标识和目标鉴权标识相同，且所述目标鉴权标识有效，确定该呼叫鉴权标识满足该第二预设条件。

若所述S-CSCF判断呼叫鉴权标识和目标鉴权标识不相同，则所述S-CSCF判断该呼叫鉴权标识为未在注册阶段存储至S-CSCF上的注册鉴权标识，或该呼叫鉴权标识未在主叫用户前一次呼叫中所使用的鉴权标识，所述S-CSCF确定该呼叫鉴权标识满足该第三预设条件。

步骤403、S-CSCF拒绝第一呼叫请求消息所请求的呼叫。

在所述S-CSCF拒绝第一呼叫请求消息所请求的呼叫的情况下，所述主叫用户无法基于该第一呼叫请求消息实现对被叫用户的呼叫。

步骤404、S-CSCF向应用服务器发送第一呼叫请求消息。

具体地，S-CSCF在注册阶段，已创建主叫用户的第一用户标识和iFC的对应关系，本实施例所示的第一用户标识为实施例二所示的主叫用户注册阶段所示的用户标识，对iFC的具体说明，请详见实施例二所示，具体不做赘述。

本实施例所示的S-CSCF根据iFC信息发送第一呼叫请求消息给应用服务器。

步骤405、应用服务器判断主叫用户具有外呼权限，则将修改后的第一呼叫请求消息转发给S-CSCF。

在主叫用户注册至运营商网络的情况下，应用服务器创建主叫用户的第一用户标识和呼叫权限的对应关系，可见，在应用服务器接收到主叫用户的第一用户标识的情况下，即可确定对应的呼叫权限，本实施例以与主叫用户的第一用户标识对应的呼叫权限包括外呼权限为例进行示例性说明。

以下对应用服务器修改第一呼叫请求消息的方式进行示例性说明：

应用服务器可将第一呼叫请求消息的From头域增加Display Name参数，Display Name参数的取值为企业的名称和主叫用户的名称，可选地，Display Name参数的取值还可追加主叫用户的工号等信息。

应用服务器还可将第一呼叫请求消息的From和(P-Asserted-Identity，PAI)头域中的主叫用户的用户标识变更为主叫用户的对外号码。

步骤406、S-CSCF将第一呼叫请求消息发送给被叫设备。

具体地，S-CSCF将第一呼叫请求消息转发至被叫设备所属的运营商网络，被叫设备所属的运营商网络再将该第一呼叫请求消息发送给被叫设备。

本实施例所示的第一呼叫请求消息包括最新呼叫名片的存储地址，所述最新呼叫名片可为实施例二所示的初始呼叫名片，或主叫用户前一次呼叫所生成的呼叫名片。

步骤407、被叫设备显示最新呼叫名片。

运营商网络向被叫设备发送最新呼叫名片。

例如，在被叫设备振铃的过程中，若被叫设备支持视频通话功能，则应用服务器控制媒体面设备向被叫设备发送彩像格式的最新呼叫名片。

又如，在被叫设备振铃的过程中，若被叫设备不支持视频通话功能，被叫设备显示最新呼叫名片，该最新呼叫名片为第一呼叫请求消息所携带的Display Name参数的内容。

可选地，运营商网络将最新呼叫名片的存储地址推送至被叫设备，被叫设备根据最新呼叫名片的存储地址下载该最新呼叫名片。

例如，在被叫设备振铃的过程中，若被叫设备支持视频通话功能，则所述被叫设备显示彩像格式的最新呼叫名片。

步骤408、S-CSCF向网络鉴权服务器发送第二呼叫请求消息。

本实施例中，若所述S-CSCF判断该呼叫鉴权标识满足该第三预设条件的情况下，S-CSCF判断第二呼叫请求消息使用Bearer的鉴权方式时，例如，第二呼叫请求消息包括Authorization:Bearer<Base64(<token>)>，所述S-CSCF向网络鉴权服务器发送包括第一用户标识和呼叫鉴权标识的第二呼叫请求消息，以请求网络鉴权服务器利用呼叫鉴权标识对主叫用户进行鉴权。

步骤409、网络鉴权服务器向企业鉴权服务器发送呼叫鉴权请求。

本实施例所示的网络鉴权服务器向企业鉴权服务器发送该呼叫鉴权请求的过程，请参见实施例二的步骤305所示的网络鉴权服务器向企业鉴权服务器发送的鉴权请求的过程，具体不做赘述。

本实施例所示的呼叫鉴权请求用于主叫用户实现对被叫用户的呼叫。

步骤410、企业鉴权服务器判断呼叫鉴权标识是否有效，若否，则执行步骤411，若是，则执行步骤412。

本实施例所示的步骤410的具体执行过程，请参见实施例二的步骤306所示的企业鉴权服务器判断注册鉴权标识是否有效的过程，具体不做赘述。

步骤411、企业鉴权服务器向网络鉴权服务器发送呼叫鉴权标识无效通知。

具体地，本实施例所示的企业鉴权服务器通过TLS安全连接，向网络鉴权服务器发送该呼叫鉴权标识无效通知，该呼叫鉴权标识无效通知用于指示该呼叫鉴权标识无效。网络鉴权服务器接收到该呼叫鉴权标识无效通知的情况下，则不再执行主叫用户呼叫被叫用户的相关流程。

步骤412、企业鉴权服务器向网络鉴权服务器发送呼叫鉴权成功指示。

本实施例所示的呼叫鉴权成功指示包括呼叫鉴权标识有效通知，该呼叫鉴权标识有效通知用于指示呼叫鉴权标识有效。

本实施例所示的企业鉴权服务器发送呼叫鉴权成功指示的过程，请参见步骤308所示的企业鉴权服务器向网络鉴权服务器发送呼叫鉴权成功指示的过程，具体在本实施例中不做赘述。

本实施例所示的呼叫鉴权成功指示还包括第二用户标识，在企业鉴权服务器确定该呼叫鉴权标识有效的情况下，企业鉴权服务器即可将该有效的呼叫鉴权标识对应的第二用户标识发送至网络鉴权服务器。

步骤413、网络鉴权服务器向应用服务器发送目标数据。

本实施例中，在网络鉴权服务器确定主叫用户通过鉴权的情况下，网络鉴权服务器即可将已获取到的目标数据向应用服务器发送。

本实施例所述的目标数据包括所述主叫用户的身份信息以及所述主叫用户所属的企业的信息。其中，所述主叫用户的身份信息来自所述企业鉴权服务器。本实施例所示对网络鉴权服务器获取主叫用户所属的企业的信息的过程，请详见实施例二的步骤309所示，具体不做赘述。

方式1：

所述网络鉴权服务器确定通过鉴权的条件有两个，一个条件是根据已接收到呼叫鉴权标识有效通知。另一个条件是该网络鉴权服务器确定第一用户标识和第二用户标识相同。

方式2：

所述网络鉴权服务器向企业鉴权服务器发送的鉴权请求同时包括所述第一用户标识，所述企业鉴权服务器在判断所述呼叫鉴权标识有效且所述第一用户标识和所述第二用户标识相同，则向网络鉴权服务器发送呼叫鉴权成功指示。

本实施例所示对网络鉴权服务器向应用服务器发送目标数据的具体过程，请参见实施例三的步骤309所示的网络鉴权服务器向应用服务器发送初始数据的过程，具体不做赘述。

步骤414、网络鉴权服务器向应用服务器发送变更通知信息。

本实施例所示的变更通知信息用于指示所述网络鉴权服务器已存储的目标数据出现变更。

步骤415、应用服务器获取目标呼叫名片。

本实施例中，在应用服务器根据变更通知信息确定主叫用户的目标数据出现变更的情况下，应用服务器即可获取变更后的主叫用户的目标数据(相关的消息遵循3GPP标准协议29.562)。

本实施例所示的目标呼叫名片为目标数据按照呼叫名片的排版方式进行排版所形成的名片信息，其中，目标数据包括所述主叫用户的身份信息以及所述主叫用户所属的企业的信息。

所述呼叫名片的排版方式以及目标数据的具体说明，请参见实施例二的步骤310所示，具体在本实施例中不做赘述。

对本实施例所示的应用服务器获取该目标呼叫名片的几种可选地方式，请参见上述步骤310所示的获取初始呼叫名片的说明，具体不做赘述。

步骤416、S-CSCF向应用服务器发送第二呼叫请求消息。

步骤417、应用服务器判断主叫用户具有外呼权限，则将修改后的第二呼叫请求消息转发给S-CSCF。

步骤418、S-CSCF将第二呼叫请求消息发送给被叫设备。

本实施例所示的步骤416至步骤418的执行过程的说明，请详见步骤404至步骤406所示，具体不做赘述。

步骤419、被叫设备显示目标呼叫名片。

本实施例所示的被叫设备显示目标呼叫名片的过程，请参见步骤407所示的被叫设备显示最新呼叫名片的过程，具体不做赘述。

本实施例中，在运营商网络、企业、企业员工(主叫用户)之间建立信任安全联盟，可保证被叫设备振铃时，所显示的呼叫名片的信息是可信的，而且呼叫名片满足呼叫名片的排版方式，以保证呼叫名片所呈现的各项信息能够符合企业定制的需求，且呼叫名片的风格统一。

在呼叫处理的过程中，因主叫用户无需直接在运营商网络开户，则避免主叫用户的个人隐私信息在运营商处暴露，而且在对被叫用户进行呼叫的过程中，呼叫名片所显示的信息也可不涉及主叫用户的个人隐私信息，有效地保证了主叫用户的个人隐私信息的安全。

本实施例所示的被叫设备所显示的呼叫名片所包括的各个信息全部来自企业鉴权服务器和/或企业开户数据，而非主叫用户，如果呼叫名片存在造假的问题，则可以基于信任安全联盟形成的信任链进行溯源和追责。

实施例四

本实施例所示主叫用户在对被叫用户进行呼叫的过程中，主叫用户无需预先注册至运营商网络，以下结合图5所示对主叫用户无需预先注册至运营商网络的情况下，对主叫用户呼叫被叫用户的过程进行说明：

步骤501、主叫设备向S-CSCF发送第三呼叫请求消息。

在主叫用户确定需要呼叫被叫用户时，所述主叫用户即可通过该主叫设备向S-CSCF发送第三呼叫请求消息，以触发主叫用户对被叫用户的呼叫。

所述第三呼叫请求消息可为SIP INVITE消息，该SIP INVITE消息包括所述主叫用户的第一用户标识和呼叫鉴权标识，对第一用户标识和呼叫鉴权标识的说明，请参见实施例三所示的对主叫用户的第一用户标识和呼叫鉴权标识的说明，具体不做赘述。

步骤502、S-CSCF向应用服务器发送第三呼叫请求消息。

本实施例中，若S-CSCF确定该第三呼叫请求消息所包括的呼叫鉴权标识与主叫用户前一次呼叫中所使用的目标鉴权标识不相同，而且S-CSCF判断第三呼叫请求消息使用Bearer的鉴权方式时，所述S-CSCF向网络鉴权服务器发送包括第一用户标识和呼叫鉴权标识的第三呼叫请求消息，以请求网络鉴权服务器利用呼叫鉴权标识对主叫用户进行鉴权。对Bearer的鉴权方式的具体说明，请详见实施例三所示，具体不做赘述。

步骤503、网络鉴权服务器向企业鉴权服务器发送呼叫鉴权请求。

本实施例所示的网络鉴权服务器向企业鉴权服务器发送该呼叫鉴权请求的过程，请参见实施例三的步骤409所示，具体不做赘述。

步骤504、企业鉴权服务器判断呼叫鉴权标识是否有效，若否，则执行步骤505，若是，则执行步骤506。

本实施例所示的步骤504的具体执行过程，请参见实施例三的步骤410所示，具体不做赘述。

步骤505、企业鉴权服务器向网络鉴权服务器发送呼叫鉴权标识无效通知。

步骤506、企业鉴权服务器向网络鉴权服务器发送呼叫鉴权成功指示。

步骤507、网络鉴权服务器向应用服务器发送目标数据。

本实施例所示的步骤505至步骤507的具体执行过程，请详见实施例三所示的步骤411至步骤413所示，具体执行过程不做赘述。

步骤508、应用服务器获取目标呼叫名片。

本实施例中，应用服务器从网络鉴权服务器获取目标数据。本实施例所示的目标呼叫名片为目标数据按照呼叫名片的排版方式进行排版所形成的名片信息，其中，目标数据包括所述主叫用户的身份信息以及所述主叫用户所属的企业的信息，对所述目标数据的具体说明，请参见实施例三所示，具体不做赘述。

步骤509、S-CSCF向应用服务器发送第三呼叫请求消息。

步骤510、应用服务器判断主叫用户具有外呼权限，则将修改后的第三呼叫请求消息转发给S-CSCF。

步骤511、S-CSCF将第三呼叫请求消息发送给被叫设备。

步骤512、被叫设备显示目标呼叫名片。

本实施例所示的步骤509至步骤512之间的执行过程的说明，请详见实施例三所示的步骤416至步骤419所示，具体执行过程不做赘述。

本实施例中，主叫用户在对被叫用户进行呼叫的过程中，主叫用户无需预先注册至运营商网络，避免在主叫用户呼叫被叫用户的过程中，需要预先进行注册的步骤，提高了主叫用户呼叫被叫用户的效率，同时减少了注册相关资源的消耗。

而且在运营商网络、企业、企业员工(主叫用户)之间建立信任安全联盟，可保证被叫设备振铃时，所显示的呼叫名片的信息是可信的，而且呼叫名片满足呼叫名片的排版方式，以保证呼叫名片所呈现的各项信息能够符合企业定制的需求，且呼叫名片的风格统一。

实施例五

在实施例二至实施例四中，运营商网络以IMS网络为例，本实施例中，对运营商网络的具体网络类型不做限定，例如，本实施例所示的运营商网络可适用于任意架构的电信网络，具体网络类型在本实施例中不做限定。

本实施例说明企业内部的主叫用户向企业外部的被叫用户呼叫时，先执行注册处理流程，基于该注册处理流程，将包括主叫用户的身份信息和/或主叫用户所属的企业的信息的初始数据，按照呼叫名片的排版方式进行排版以获取初始呼叫名片，以便于后续主叫用户呼叫被叫用户时，运营商网络能够直接将该初始呼叫名片发送至被叫用户，无需在呼叫的过程中获取该初始呼叫名片，节省了呼叫过程中运营商网络与企业鉴权服务器之间所交互的信息量，缩短了呼叫接续时延，提高了呼叫效率，而且基于本实施例所示的方法，能够创建信任安全联盟所示的企业鉴权主叫用户的过程，具体参见图6所示，其中，图6为本申请所提供的通信系统执行注册的过程的另一种实施例步骤流程图。

步骤601、主叫设备向企业鉴权服务器发送登录请求。

步骤602、主叫设备接收来自企业鉴权服务器的注册鉴权标识。

本实施例所示的步骤601至步骤602的执行过程的说明，请详见实施例二的步骤301至步骤302所示，具体不做赘述。

步骤603、主叫设备向运营商网络发送注册请求。

本实施例所示的注册请求的具体说明，请详见实施例二的步骤303所示，具体不做赘述。

步骤604、运营商网络向企业鉴权服务器发送鉴权请求。

本实施例所示的鉴权请求的具体说明，请详见实施例二的步骤305所示，具体不做赘述。

本实施例所示的运营商网络根据注册请求向企业鉴权服务器发送鉴权请求的具体过程的说明，请参见实施例二的步骤303至步骤305所示，本实施例对运营商网络执行的具体网元不做限定。

步骤605、企业鉴权服务器判断注册鉴权标识是否有效，若否，则执行步骤606，若是，则执行步骤607。

步骤606、企业鉴权服务器向运营商网络发送鉴权标识无效通知。

步骤607、企业鉴权服务器向运营商网络发送注册鉴权成功指示。

本实施例所示的步骤605至步骤607的执行过程的说明，请详见步骤306至步骤308所示，具体执行过程不做赘述。

步骤608、运营商网络获取初始呼叫名片。

本实施例所示的运营商网络获取初始呼叫名片的过程，请参见步骤309至步骤310所示，本实施例对运营商网络执行的具体网元不做限定。

实施例六

本实施例所示的运营商网络的具体类型的说明，请详见实施例五所示，具体在本实施例中不做赘述，本实施例说明基于图6所示的方法，在主叫用户已注册至运营商网络的情况下，主叫用户如何使用主叫设备实现对被叫用户的呼叫。具体参见图7所示，其中，图7为本申请所提供的通信系统执行呼叫的另一种实施例步骤流程图。

步骤701、主叫设备向运营商网络发送第一呼叫请求消息。

对第一呼叫请求消息的具体说明，请详见实施例三所示的步骤401所示，具体不做赘述。

步骤702、运营商网络判断呼叫鉴权标识满足第一预设条件时，执行步骤703，运营商网络判断呼叫鉴权标识满足第二预设条件时，执行步骤704，运营商网络判断呼叫鉴权标识满足第三预设条件时，执行步骤706。

本实施例所示的运营商网络执行步骤702的具体过程的说明，请详见实施例三所示的步骤402所示，具体执行过程不做赘述。

步骤703、运营商网络拒绝第一呼叫请求消息所请求的呼叫。

本实施例所示的运营商网络拒绝第一呼叫请求消息所请求的呼叫的具体过程的说明，请详见实施例三的步骤403所示，本实施例对运营商网络执行的具体网元不做限定。

步骤704、运营商网络将第一呼叫请求消息发送给被叫设备。

本实施例所示的运营商网络执行步骤704的具体过程的说明，请详见实施例三所示的步骤404至步骤406所示，具体执行过程不做赘述，本实施例对运营商网络执行的具体网元不做限定。

步骤705、被叫设备显示最新呼叫名片。

本实施例所示的步骤704的执行过程的说明，请详见实施例三所示的步骤407所示，具体执行过程不做赘述。

步骤706、运营商网络向企业鉴权服务器发送呼叫鉴权请求。

本实施例所示的步骤706的执行过程的说明，请详见实施例三所示的步骤408至步骤409所示，具体执行过程不做赘述。

步骤707、企业鉴权服务器判断呼叫鉴权标识是否有效，若否，则执行步骤708，若是，则执行步骤709。

步骤708、企业鉴权服务器向运营商网络发送呼叫鉴权标识无效通知。

步骤709、企业鉴权服务器向运营商网络发送呼叫鉴权成功指示。

步骤710、运营商网络将第二呼叫请求消息发送给被叫设备。

本实施例所示的步骤707至步骤710的执行过程的说明，请详见步骤410至步骤418所示，具体不做赘述，本实施例对运营商网络执行的具体网元不做限定。

步骤711、被叫设备显示目标呼叫名片。

本实施例所示的步骤711的执行过程的说明，请详见步骤419所示，具体不做赘述。

实施例七

本实施例所示的运营商网络的具体类型的说明，请详见实施例五所示，具体在本实施例中不做赘述，本实施例所示主叫用户在对被叫用户进行呼叫的过程中，主叫用户无需预先注册至运营商网络，以下结合图8所示对主叫用户无需预先注册至运营商网络的情况下，对主叫用户呼叫被叫用户的过程进行说明：

步骤801、主叫设备向运营商网络发送第三呼叫请求消息。

步骤802、运营商网络向企业鉴权服务器发送呼叫鉴权请求。

本实施例所示的步骤801至步骤802的执行过程的说明，请详见实施例四所示的步骤501至步骤503所示，具体不做赘述，本实施例对运营商网络执行的具体网元不做限定。

步骤803、企业鉴权服务器判断呼叫鉴权标识是否有效，若否，则执行步骤804，若是，则执行步骤805。

步骤804、企业鉴权服务器向运营商网络发送呼叫鉴权标识无效通知。

步骤805、企业鉴权服务器向运营商网络发送呼叫鉴权成功指示。

本实施例所示的步骤803至步骤805的执行过程的说明，请详见实施例四所示的步骤504至步骤506所示，具体不做赘述，本实施例对运营商网络执行的具体网元不做限定。

步骤806、运营商网络获取目标呼叫名片。

本实施例所示的步骤806的执行过程的说明，请详见实施例四所示的步骤507至步骤508所示，具体不做赘述，本实施例对运营商网络执行的具体网元不做限定。

步骤807、运营商网络将第三呼叫请求消息发送给被叫设备。

本实施例所示的步骤807的执行过程的说明，请详见实施例四所示的步骤509至步骤511所示，具体不做赘述，本实施例对运营商网络执行的具体网元不做限定。

步骤808、被叫设备显示目标呼叫名片。

本实施例所示的步骤808的执行过程的说明，请详见步骤512所示，具体不做赘述。

本实施例所示的实施例五至实施例七所示的有益效果的说明，请参见实施例二至实施例四所示，具体不做赘述。

实施例八

本实施例结合图9所示对执行上述呼叫处理方法的网络设备的结构进行说明：

网络设备900具体包括：处理单元901和收发单元902，其中，处理单元901与收发单元902连接。

若本实施例所示的网络设备900为网络鉴权服务器，则处理单元901用于执行实施例二至实施例四中，任一实施例中由网络鉴权服务器执行的处理功能，收发单元902用于执行实施例二至实施例四中，任一实施例中由网络鉴权服务器执行的收发功能。

若本实施例所示的网络设备900为企业鉴权服务器，则处理单元901用于执行实施例二至实施例八中，任一实施例中由企业鉴权服务器执行的处理功能，收发单元902用于执行实施例二至实施例八中，任一实施例中由企业鉴权服务器执行的收发功能。

若本实施例所示的网络设备900为S-CSCF，则处理单元901用于执行实施例二至实施例四中，任一实施例中由S-CSCF执行的处理功能，收发单元902用于执行实施例二至实施例四中，任一实施例中由S-CSCF执行的收发功能。

若本实施例所示的网络设备900为应用服务器，则处理单元901用于执行实施例二至实施例四中，任一实施例中由应用服务器执行的处理功能，收发单元902用于执行实施例二至实施例四中，任一实施例中由应用服务器执行的收发功能。

若本实施例所示的网络设备900为主叫设备，则处理单元901用于执行实施例二至实施例八中，任一实施例中由主叫设备执行的处理功能，收发单元902用于执行实施例二至实施例八中，任一实施例中由主叫设备执行的收发功能。

若本实施例所示的网络设备900为运营商网络，则处理单元901用于执行实施例五至实施例七中，任一实施例中由运营商网络执行的处理功能，收发单元902用于执行实施例五至实施例七中，任一实施例中由运营商网络执行的收发功能。

实施例九

本实施例结合图10所示，从实体硬件角度，对执行上述呼叫处理方法的网络设备的结构进行说明：

网络设备1000具体包括：处理器1001、存储器1002、总线1003、收发器1004以及网络接口1006。

具体的，存储器1002可以包括以易失性和/或非易失性存储器形式的计算机存储媒体，如只读存储器和/或随机存取存储器。存储器1002可以存储操作系统、应用程序、其他程序模块、可执行代码和程序数据。

收发器1004可以用于向网络设备输入命令和信息，该收发器1004可以通过总线1003连接至处理器1001。收发器1004还可以用于网络设备输出信息，例如所选定的占位服务器和/或占位虚拟机。

网络设备可以通过网络接口1006连接到通信网络中，在联网环境下，网络设备中存储的计算机执行指令可以存储在远程存储设备中，而不限于在本地存储。

当网络设备中的处理器1001执行存储器1002中存储的可执行代码或应用程序时，网络设备可以执行以上方法实施例中的任一侧的方法操作，具体执行过程参见上述方法实施例，在此不再赘述。

以上所述，以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims

一种呼叫处理方法，其特征在于，所述方法包括：

网络鉴权服务器接收来自主叫设备的呼叫请求消息，所述主叫设备为主叫用户所使用的设备，所述呼叫请求消息包括所述主叫用户的第一用户标识和呼叫鉴权标识；

所述网络鉴权服务器向所述第一用户标识对应的企业鉴权服务器发送呼叫鉴权请求，所述呼叫鉴权请求包括所述呼叫鉴权标识；

所述网络鉴权服务器接收来自所述企业鉴权服务器的呼叫鉴权成功指示，所述呼叫鉴权成功指示用于指示鉴权通过；

所述网络鉴权服务器向被叫设备发送目标数据，所述被叫设备为被叫用户所使用的设备，所述目标数据包括所述主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息。
根据权利要求1所述的方法，其特征在于，所述呼叫鉴权成功指示包括第二用户标识，所述网络鉴权服务器向被叫设备发送目标数据包括：

所述网络鉴权服务器确定所述第一用户标识和所述第二用户标识相同，向所述被叫设备发送所述目标数据。
根据权利要求1所述的方法，其特征在于，所述网络鉴权服务器向被叫设备发送目标数据包括：

所述网络鉴权服务器向所述企业鉴权服务器获取所述目标数据，向所述被叫设备发送所述目标数据。
根据权利要求1所述的方法，其特征在于，所述网络鉴权服务器向被叫设备发送目标数据包括：

所述网络鉴权服务器向所述被叫设备发送所述呼叫请求消息，所述呼叫请求消息包括所述目标数据。
根据权利要求1所述的方法，其特征在于，所述网络鉴权服务器向被叫设备发送目标数据包括：

所述网络鉴权服务器通过媒体面设备向所述被叫设备发送所述目标数据。
根据权利要求1至5任一项所述的方法，其特征在于，所述网络鉴权服务器向被叫设备发送目标数据包括：

所述网络鉴权服务器向所述企业鉴权服务器获取所述目标数据，对所述目标数据进行排版，向所述被叫设备发送排版后的所述目标数据。
根据权利要求1至5任一项所述的方法，其特征在于，所述网络鉴权服务器向被叫设备发送目标数据包括：

所述网络鉴权服务器向所述企业鉴权服务器获取所述目标数据；

所述网络鉴权服务器向媒体面设备发送通知信息，所述通知信息用于指示所述媒体面设备或应用服务器对所述目标数据进行排版，并向所述被叫设备发送排版后的所述目标数据。
根据权利要求1至7任一项所述的方法，其特征在于，所述网络鉴权服务器接收来自主叫设备的呼叫请求消息之前，所述方法还包括：

所述网络鉴权服务器接收来自所述主叫设备的注册请求消息，所述注册请求消息包括所述第一用户标识和注册鉴权标识；

所述网络鉴权服务器向所述第一用户标识对应的所述企业鉴权服务器发送鉴权请求，所述鉴权请求包括所述注册鉴权标识；

所述网络鉴权服务器接收来自所述企业鉴权服务器的注册鉴权成功指示，所述注册鉴权成功指示用于指示鉴权通过；

所述网络鉴权服务器获取初始数据，所述初始数据包括所述主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息。
根据权利要求8所述的方法，其特征在于，所述注册鉴权成功指示包括第三用户标识，所述方法还包括：

所述网络鉴权服务器确定所述第一用户标识和所述第三用户标识相同，则确定鉴权通过。
根据权利要求8所述的方法，其特征在于，所述网络鉴权服务器向被叫设备发送目标数据包括：

若所述网络鉴权服务器确定所述呼叫鉴权标识和所述注册鉴权标识相同，则所述网络鉴权服务器确定所述目标数据为所述初始数据。
根据权利要求8所述的方法，其特征在于，所述网络鉴权服务器向被叫设备发送目标数据包括：

若所述网络鉴权服务器确定所述呼叫鉴权标识和所述注册鉴权标识不相同，则所述网络鉴权服务器接收来自所述企业鉴权服务器的所述目标数据，所述目标数据和所述初始数据互不相同。
根据权利要求1至11任一项所述的方法，其特征在于，所述方法还包括：

所述网络鉴权服务器接收所述企业鉴权服务器的设备证书对应的第一电子认证服务CA证书；

所述网络鉴权服务器使用所述第一CA证书创建所述网络鉴权服务器和所述企业鉴权服务器之间的安全传输层协议TLS安全连接，所述网络鉴权服务器通过所述TLS安全连接与所述企业鉴权服务器进行数据交互。
一种呼叫处理方法，其特征在于，所述方法包括：

企业鉴权服务器接收来自网络鉴权服务器的呼叫鉴权请求，所述呼叫鉴权请求包括呼叫鉴权标识；

若所述企业鉴权服务器根据所述呼叫鉴权标识确定鉴权通过，则所述企业鉴权服务器向所述网络鉴权服务器发送呼叫鉴权成功指示和目标数据，所述呼叫鉴权成功指示用于指示鉴权通过，所述目标数据包括所述主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息。
根据权利要求13所述的方法，其特征在于，所述企业鉴权服务器接收来自网络鉴权服务器的呼叫鉴权请求之前，所述方法还包括：

所述企业鉴权服务器接收来自所述网络鉴权服务器的鉴权请求，所述鉴权请求包括注册鉴权标识；

若所述企业鉴权服务器根据所述注册鉴权标识确定鉴权通过，则所述企业鉴权服务器向所述网络鉴权服务器发送注册鉴权成功指示和初始数据，所述注册鉴权成功指示用于指示鉴权通过，所述初始数据包括所述主叫用户的身份信息，和/或，所述主叫用户所属的企业的信息。
根据权利要求14所述的方法，其特征在于，若所述呼叫鉴权标识和所述注册鉴权标识不相同，则所述企业鉴权服务器向所述网络鉴权服务器发送所述目标数据，所述目标数据和所述初始数据互不相同。
根据权利要求13至15任一项所述的方法，其特征在于，所述方法还包括：

所述企业鉴权服务器接收所述网络鉴权服务器的设备证书对应的第二电子认证服务CA证书；

所述企业鉴权服务器使用所述第二CA证书创建所述企业鉴权服务器和所述网络鉴权服务器之间的安全传输层协议TLS安全连接，所述企业鉴权服务器通过所述TLS安全连接与所述网络鉴权服务器进行数据交互。
根据权利要求13至16任一项所述的方法，其特征在于，所述企业鉴权服务器接收来自网络鉴权服务器的呼叫鉴权请求之后，所述方法还包括：

若所述企业鉴权服务器根据所述呼叫鉴权标识确定鉴权未通过，则所述企业鉴权服务器向所述网络鉴权服务器发送鉴权无效通知信息，所述鉴权无效通知信息用于指示鉴权未通过。
根据权利要求13至17任一项所述的方法，其特征在于，所述企业鉴权服务器接收来自网络鉴权服务器的呼叫鉴权请求之前，所述方法还包括：

所述企业鉴权服务器接收来自所述主叫设备的第一用户标识，所述第一用户标识为所述主叫用户的标识；

所述企业鉴权服务器向所述主叫设备发送与所述第一用户标识对应的所述呼叫鉴权标识。
根据权利要求13至17任一项所述的方法，其特征在于，所述企业鉴权服务器接收来自网络鉴权服务器的鉴权请求之前，所述方法还包括：

所述企业鉴权服务器接收来自所述主叫设备的第一用户标识，所述第一用户标识为所述主叫用户的标识；

所述企业鉴权服务器向所述主叫设备发送与所述第一用户标识对应的所述注册鉴权标识。
一种网络鉴权服务器，其特征在于，包括相互耦合的处理器和存储器，所述存储器中存储了计算机程序代码，所述处理器调用并执行所述存储器中的计算机程序代码，使得所述处理器执行如权利要求1-12任一项所述的方法。
一种企业鉴权服务器，其特征在于，包括相互耦合的处理器和存储器，所述存储器中存储了计算机程序代码，所述处理器调用并执行所述存储器中的计算机程序代码，使得所述处理器执行如权利要求13-19任一项所述的方法。
一种通信系统，其特征在于，包括网络鉴权服务器以及企业鉴权服务器，所述网络鉴权服务器如权利要求20所述，所述企业鉴权服务器如权利要求21所述。