CN116260856A - 音视频通话方法和装置 - Google Patents

Abstract

本公开提供了音视频通话方法和装置，涉及人工智能领域，尤其涉及互联网医疗领域。具体实现方案为：响应于接收到不同账号的登录请求，记录每个账号的设备信息；根据每个账号的设备信息为每个账号建立通信链路，其中，所述通信链路包括信令链路和/或轮询链路；响应于接收到主叫方呼叫被叫方的请求，检测所述被叫方的通话状态；若所述被叫方的通话状态为空闲，则通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求；响应于检测到所述被叫方接听，更新所述主叫方和所述被叫方的通话状态为忙碌。该实施方式兼容了市面上WEB和移动端通用的视频通话能力，保证通话请求的及时送达，提升了通话成功率。

Description

音视频通话方法和装置

技术领域

本公开涉及人工智能领域，尤其涉及互联网医疗领域，具体为一种音视频通话方法和装置。

背景技术

现有的智能终端产品，可以关注长者居家健康管理，实现亲人远程关怀等，所以视频通话能力是必不可少的。业务的发展初期，只需要以轮询的方式与医生WEB端进行通信，随着业务的不断发展，医生端新增了iOS与Android双端App。智能终端产品需要同时支持与WEB、iOS、Android三端的医生端进行视频通话。医生三端的通话状态需要同步。

目前轮询的方式虽然可以满足业务，但极其耗损性能，在通话状态请求中有大半是无用的，严重浪费服务器端和客户端的资源。

目前App视频通话功能大部分都非采用轮询技术，无法与智能终端产品进行互通，导致智能终端产品拓展业务受到阻碍。智能终端产品需要打开对应的页面，才能轮询到呼叫请求，否则，无法及时收到被叫请求，极其容易错过医生的随访问诊。

发明内容

本公开提供了一种音视频通话方法、装置、设备、存储介质以及计算机程序产品。

根据本公开的第一方面，提供了一种音视频通话方法，包括：响应于接收到不同账号的登录请求，记录每个账号的设备信息；根据每个账号的设备信息为每个账号建立通信链路，其中，所述通信链路包括信令链路和/或轮询链路；响应于接收到主叫方呼叫被叫方的请求，检测所述被叫方的通话状态；若所述被叫方的通话状态为空闲，则通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求；响应于检测到所述被叫方接听，更新所述主叫方和所述被叫方的通话状态为忙碌。

根据本公开的第二方面，提供了一种音视频通话装置，包括：登录单元，被配置成响应于接收到不同账号的登录请求，记录每个账号的设备信息；建立单元，被配置成根据每个账号的设备信息为每个账号建立通信链路，其中，所述通信链路包括信令链路和/或轮询链路；状态检测单元，被配置成响应于接收到主叫方呼叫被叫方的请求，检测所述被叫方的通话状态；呼叫单元，被配置成若所述被叫方的通话状态为空闲，则通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求；状态更新单元，被配置成响应于检测到所述被叫方接听，更新所述主叫方和所述被叫方的通话状态为忙碌

根据本公开的第三方面，提供了一种用于音视频通话的电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面中任一项所述的方法。

根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面中任一项所述的方法。

根据本公开的第五方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现第一方面中任一项所述的方法。

本公开的实施例提供的音视频通话方法和装置，支持信令(APP端)与轮询(WEB端)两种通话能力，可根据医生端的形态动态切换通话方式。既给医生端双端App的性能及体验提供了保障，也同时兼容了医生WEB端的视频能力。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是本公开的一个实施例可以应用于其中的示例性系统架构图；

图2是根据本公开的音视频通话方法的一个实施例的流程图；

图3a-3c是根据本公开的音视频通话方法的一个应用场景的示意图；

图4是根据本公开的音视频通话方法的又一个实施例的流程图；

图5是根据本公开的音视频通话装置的一个实施例的结构示意图；

图6是适于用来实现本公开的实施例的电子设备的计算机系统的结构示意图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

图1示出了可以应用本公开的音视频通话方法或音视频通话装置的实施例的示例性系统架构100。

如图1所示，系统架构100可以包括终端设备101、102、103和服务器104。网络用以在终端设备101、102、103和服务器104之间提供通信链路的介质。网络可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

终端设备101、102、103之间可以通过服务器104交互，以进行音视频通话等。终端设备101、102、103上可以安装有各种通讯客户端应用，例如远程医疗类应用、网页浏览器应用、购物类应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等。

终端设备101、102、103可以是硬件，也可以是软件。当终端设备101、102、103为硬件时，可以是具有显示屏并且支持网页浏览的各种电子设备，包括但不限于智能音箱、智能手机、平板电脑、电子书阅读器、MP3播放器(Moving Picture Experts Group Audio LayerIII，动态影像专家压缩标准音频层面3)、MP4(Moving Picture Experts Group AudioLayer IV，动态影像专家压缩标准音频层面4)播放器、膝上型便携计算机和台式计算机等等。当终端设备101、102、103为软件时，可以安装在上述所列举的电子设备中。其可以实现成多个软件或软件模块(例如用来提供分布式服务)，也可以实现成单个软件或软件模块。在此不做具体限定。

在远程医疗应用场景下，终端设备101可以是智能音箱，作为患者端。终端设备103和104可以是PC或者智能手机，作为医生端。其中PC不能安装APP，只能通过WEB端以轮询的方式与智能音箱通信。智能手机上可以安装APP，可通过信令的方式与智能音箱通信。

服务器104可以是提供各种服务的服务器，例如对终端设备101、102、103的音视频通话提供支持的后台通信服务器。后台通信服务器可以对接收到的主叫方的音视频通话请求、主叫方、被叫方的设备信息等数据进行分析，确定采用哪种通信链路与被叫方通话，然后通过最优的通信链路将通话请求发送给被叫方。

需要说明的是，服务器可以是硬件，也可以是软件。当服务器为硬件时，可以实现成多个服务器组成的分布式服务器集群，也可以实现成单个服务器。当服务器为软件时，可以实现成多个软件或软件模块(例如用来提供分布式服务的多个软件或软件模块)，也可以实现成单个软件或软件模块。在此不做具体限定。服务器也可以为分布式系统的服务器，或者是结合了区块链的服务器。服务器也可以是云服务器，或者是带人工智能技术的智能云计算服务器或智能云主机。

需要说明的是，本公开的实施例所提供的音视频通话方法一般由服务器104执行，相应地，音视频通话装置一般设置于服务器104中。

应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。

继续参考图2，示出了根据本公开的音视频通话方法的一个实施例的流程200。该音视频通话方法，包括以下步骤：

步骤201，响应于接收到不同账号的登录请求，记录每个账号的设备信息。

在本实施例中，音视频通话方法运行于其上的电子设备(例如图1所示的服务器)可以通过有线连接方式或者无线连接方式接收用户的登录请求。用户可通过不同的设备，例如，PC、智能手机、智能音箱登录到服务器。同一用户可通过同一账号在不同设备上登录，例如，医生可以在手机上通过用于视频通话的APP登录服务器，也可以通过WEB浏览器登录服务器。患者可以通过智能音箱登录服务器。登录请求可包括设备信息，例如，设备型号、可支持的视频通话APP、WEB浏览器等信息。

步骤202，根据每个账号的设备信息为每个账号建立通信链路。

在本实施例中，其中，通信链路包括信令链路和/或轮询链路。信令链路供APP使用，包括IM(即时通信)信令、RTC(实时通信)。轮询链路供WEB端使用，包括RTC(实时通信)，通过发送HTTP请求来实现视频通话。信令链路、轮询链路的建立过程为现有技术，因此不再赘述。

如果一个账号通过APP登录，则为它建立信令链路。如果一个账号通过WEB浏览器登录，则为它建立轮询链路。同一个账号可以同时在APP和WEB浏览器登录，因此可以同时建立信令链路和轮询链路。

步骤203，响应于接收到主叫方呼叫被叫方的请求，检测被叫方的通话状态。

在本实施例中，服务器维护不同账号的通话状态，初始时是空闲状态，接听通话后转成忙碌状态。如果是忙碌状态即占线中，则不能再接听别人的呼叫。需要等通话结束转成空闲状态才能接听其它人的呼叫。

步骤204，若被叫方的通话状态为空闲，则通过与主叫方的通信链路匹配的被叫方的通信链路向被叫方发送请求。

在本实施例中，空闲状态才能接听。由于被叫方可能建了多条通信链路，因此可以从中选择最优的通信链路发送呼叫请求。最优的通信链路是与主叫方的通信链路匹配的，例如，主叫方的通信链路如果是轮询链路，则选择被叫方的轮询链路。主叫方的通信链路如果是信令链路，则选择被叫方的信令链路。如果被叫方没有与主叫方相同的通信链路，也可以选择不同的通信链路。

步骤205，响应于检测到被叫方接听，更新主叫方和被叫方的通话状态为忙碌。

在本实施例中，被叫方通过轮询或信令接收到呼叫请求，选择接听，同时更新主叫方和被叫方的通话状态为忙碌。当被叫方多端(WEB端、APP端)同时在线时，除接听端以外的终端自动取消呼叫。

本公开的上述实施例提供的方法，兼容了市面上WEB和移动端通用的视频通话能力，相对于现有只支持单一视频通话能力的产品，更有竞争力。同时视频通话还做到了即使App被Kill、即使信令断链，也可以保证通话请求的及时送达，一定程度上提升了通话成功率。在专属医生的医生随访患者、患者问诊医生的业务场景中，通话成功率尤为重要。一定程度上为今后的业务发展奠定了基础。

在本实施例的一些可选的实现方式中，所述根据每个账号的设备信息为每个账号建立通信链路，包括：对于通过Android设备和iOS设备登录的账号，建立信令链路。Android设备和iOS设备可以通过APP进行视频通话，因此可以建立信令链路，通过IM信令+RTC的方式进行视频通话，具体过程如图3a所示。这样改造的智能音箱可以支持APP进行视频通话，节省服务器端和客户端的资源。也可避免用户没有打开WEB视频通话页面而导致无法接通视频电话。

在本实施例的一些可选的实现方式中，所述根据每个账号的设备信息为每个账号建立通信链路，包括：对于通过个人计算机登录的账号，建立轮询链路。个人计算机(PC)不能安装APP，因此只能通过WEB端进行视频通信，所以需要建立轮询链路，通过轮询RTC进行视频通话，具体过程如图3b所示。这样可以保留智能音箱原有的视频通话方式，防止不同版本的智能音箱不能互通。

在本实施例的一些可选的实现方式中，所述通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求，包括：若所述主叫方的通信链路为信令链路，则通过信令链路向所述被叫方发送所述请求。使用相同的通信链路进行视频通话，不需要进行转换，减少了时延。

在本实施例的一些可选的实现方式中，所述通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求，包括：若所述主叫方的通信链路为轮询链路，则通过轮询链路向所述被叫方发送所述请求。使用相同的通信链路进行视频通话，不需要进行转换，减少了时延。

在本实施例的一些可选的实现方式中，所述通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求，包括：若所述主叫方的通信链路为轮询链路和信令链路，则分别通过轮询链路和信令链路向所述被叫方发送所述请求。通过2条链路分别进行呼叫，可以提高呼叫成功率。

在本实施例的一些可选的实现方式中，所述方法还包括：响应于检测到所述被叫方接听了其中一条链路，取消另一条链路上的所述请求。可以减少资源的占用。

在本实施例的一些可选的实现方式中，所述方法还包括：响应于检测到所述被叫方拒接了其中一条链路，结束所有链路上的视频通话。可以避免对被叫方的骚扰并减少资源的占用。

在本实施例的一些可选的实现方式中，所述方法还包括：响应于检测到所述被叫方拒接，更新所述主叫方和所述被叫方的通话状态为空闲。拒接后切换成空闲状态，则释放链路资源，可以给其它用户使用。

在本实施例的一些可选的实现方式中，所述方法还包括：响应于在所述被叫方未接听时检测到所述主叫方取消呼叫，结束视频通话并更新所述主叫方和所述被叫方的通话状态为空闲。取消呼叫后切换成空闲状态，则释放链路资源，可以给其它用户使用。

在本实施例的一些可选的实现方式中，所述方法还包括：响应于在所述被叫方接听后检测到所述主叫方或被叫方挂断视频，结束视频通话并更新所述主叫方和所述被叫方的通话状态为空闲。通话结束后切换成空闲状态，则释放链路资源，可以给其它用户使用。

继续参见图3a-3c，图3a-3c是根据本实施例的音视频通话方法的应用场景的一个示意图。图3a为信令音视频通话方法的应用场景，图3b为轮询音视频通话方法的应用场景，图3c为被叫方离线被拉起的应用场景，在不同的图中，相同的标号不代表相同的步骤。图3a所示的信令音视频通话的具体流程如下：

1、初始化：信令初始化，保证通信链路为建联状态。同时，服务端会记录登陆设备的信息，方便视频通话各个状态下进行设备管理。

2、发起视频通话请求：

201，主叫方呼叫被叫方，查询通话状态；

202，如果被叫方为空闲状态，根据双方具体链路情况，采取最优联路发送呼叫请求。

203，如果被叫方不在线，会触发拉起方案(如图3c所示)，拉起后，信令会自动建联，可正常接收呼叫请求。如被叫方多端同时在线，会同时接收到呼叫请求，一定概率上增加了接听的概率。

204，通过IM信令+RTC信令发起呼叫，创建房间邀请被叫。

205，如果被叫未操作或主叫未取消呼叫而超时，则返回空闲状态。

206，如果主叫取消呼叫，则返回空闲状态，并取消已申请的房间。

呼叫过程中涉及的IM信令+RTC信令，以及WebRTC均为现有技术，因此不再赘述。

3、接听视频通话：

301，被叫方通过信令接收到呼叫请求，选择接听，同时更新主叫方和被叫方的通话状态为忙碌。

302，登录RTC视频通话账户，当被叫方多端同时在线时，除接听端以外的终端自动取消呼叫。

303，如果被叫或主叫任一方挂断通话，则退出RTC视频通话账户，不再向被叫推送流量。

304，更新主叫方和被叫方的通话状态为空闲。

305，中断IM信令，释放房间。

4、拒接视频通话：

401，被叫方接收到呼叫请求，选择拒接。

402，更新主叫方和被叫方的通话状态为空闲。当被叫方多端同时在线时，全部端设备都结束视频通话。

5、取消呼叫：在被叫方为接起视频通话时，主叫方取消呼叫，同时更新主叫方和被叫方的通话状态为空闲。当被叫方多端同时在线时，全部端设备都结束视频通话。

6、挂断视频：当被叫方和主叫方任何一方挂断视频时，主叫方和被叫方的通话状态设置为空闲。

图3b所示的轮询音视频通话的具体流程如下：

1、初始化：开启轮询，保证通信链路为建联状态。同时，服务端会记录登陆设备的信息，方便视频通话各个状态下进行设备管理。

2、发起视频通话请求：

201，主叫方呼叫被叫方，查询通话状态；

202，如果被叫方为空闲状态，根据双方具体链路情况，采取最优联路发送呼叫请求，返回房间ID和令牌(token)。

203，如果被叫为忙碌状态，则创建通话记录。

3、接听视频通话：

301，被叫方通过轮询接收到呼叫请求，选择接听，会同时更新主叫方和被叫方的通话状态为忙碌。当被叫方多端同时在线时，除接听端以外的终端自动取消呼叫。

302，主叫方轮询房间状态，服务器返回房间状态。

303，根据房间状态登录RTC视频通话账户，同时更新主叫方和被叫方的通话状态为忙碌。当被叫方多端同时在线时，除接听端以外的终端自动取消呼叫。

304，主叫方或被叫方中任一方挂断通话，则退出RTC视频通话账户，不再向被叫推送流量，同时更新主叫方和被叫方的通话状态为空闲。

4、拒接视频通话：

401，主叫方取消呼叫或超时，则同时更新主叫方和被叫方的通话状态为空闲。

402，被叫方接收到呼叫请求，选择拒接，同时更新主叫方和被叫方的通话状态为空闲。当被叫方多端同时在线时，全部端设备都结束视频通话。

该方案可以应用于互联网医疗技术中。主要为医生(WEB端、Android App、iOSApp)和用户(智能音箱端)提供音视频能力，方便医生更好的随访客户，也方便客户更好的问诊医生。用户角度，可以从专属医生页面，选择自己想要问诊的医生，发起视频请求，用户层面无需手动选择链路形态，会直接匹配合适的视频通话能力链路。当医生未接听时，用户可以选择取消呼叫。当医生接听后，用户可以选择挂断、开关麦克风、开关摄像头；从医生角度，可以从患者管理列表中，选择想要问诊的患者，发起视频通话请求，医生同样也可以在患者未接听时，选择取消呼叫。在患者接听后，可以选择挂断、开关麦克风、开关摄像头。医生呼叫患者时，患者如果存在多端登陆，患者多端都可以同时收到医生的视频邀请，当患者的其中一个终端设备接听，那么患者其他的终端设备全部自动关闭待接听页面。当患者的其中一个终端设备拒接，那么患者的全部终端设备全部自动关闭待接听页面。

如果不使用该技术，智能音箱端只能与医生WEB端进行视频通话，无法与医生移动端App进行视频通话。在医带患的业务模式中，无疑是阻碍了业务发展的脚步；如果不使用该技术，也无法实现同时进行多端呼叫、更无法实现多终端的通话状态管理。如果不是使用该技术，会使医生的门槛变高、会使医患之间的沟通成本变高，一定程度上影响业务的发展。

进一步参考图4，其示出了音视频通话方法的又一个实施例的流程400。该音视频通话方法的流程400，包括以下步骤：

步骤401，响应于接收到不同账号的登录请求，记录每个账号的设备信息。

步骤402，根据每个账号的设备信息为每个账号建立通信链路。

步骤403，响应于接收到主叫方呼叫被叫方的请求，检测被叫方的通话状态。

步骤401-403与步骤201-203基本相同，因此不再赘述。

步骤404，若被叫方的通话状态为离线，则触发唤起视频通话页面的流程，建立被叫方的通信链路。

在本实施例中，如果一个账号没有登录到服务器，则认为该账号离线。本申请提供了一种唤起被叫方的方法，如图3c所示。

步骤405，通过被叫方的通信链路向被叫方发送请求。

步骤406，响应于检测到被叫方接听，更新主叫方和被叫方的通话状态为忙碌。

步骤405-406与步骤204-205基本相同，因此不再赘述。

图3c所示的被拉起方案的具体流程如下：

101，医生端与小度端均建立医生端与服务端的长连接。

102，医生端根据小度端(被叫方)的账号(cuid)拨打视频通话。

103，服务端在数据库中查询被叫方的状态，如果cuid曾经注册过，则cuid会保存在数据库中，注册时还获取了设备信息，例如设备型号、版本信息等。如果在数据库中查询不到cuid，则说明被叫方不是合法身份，不能唤起被叫方。根据被叫方的cuid还可以知道被叫方的设备的版本号，从而确定对唤起功能的支持情况。

104，如果被叫方空闲，则RTC向被叫方发送邀请。如果不空闲，则结束呼叫请求。

105，检测被叫方是否在线。

106，如果被叫方在线，则小度端直接打开视频通话待接听页面。

107，检测被叫方账号是否在数据库中，如果不在则无法拉起。

108，如果被叫方账号在数据库中，则根据被叫方设备的版本号决定能否被拉起。一种情况是完全支持唤起功能，则唤起被叫方后可以直接打开视频页面。另一种情况是部分支持唤起功能，虽然可以让被叫方登录到服务器并建立轮询链路，但是不能直接进入视频页面，而是需要被叫方手动打开视频页面。

109，如果能被拉起，则检查是否已经签署过授权协议，如果没有签署则弹出协议界面，如果已经签署则打开视频通话待接听页面。拉起过程还需要被叫方的授权，如果之前授权过，则可直接建立长链接，否则需要被叫方签署协议，允许离线时被唤起。如果被叫方不签署该协议，则无法实现唤起功能。

从图4中可以看出，与图2对应的实施例相比，本实施例中的音视频通话方法的流程400体现了将离线的被叫方唤起的过程，即使用户离线，也会被唤起接听视频，从而保证通话请求及时送达，提升了通话成功率。

进一步参考图5，作为对上述各图所示方法的实现，本公开提供了一种音视频通话装置的一个实施例，该装置实施例与图2所示的方法实施例相对应，该装置具体可以应用于各种电子设备中。

如图5所示，本实施例的音视频通话装置500包括：登录单元501、建立单元502、状态检测单元503、呼叫单元504和状态更新单元505。其中，登录单元501，被配置成响应于接收到不同账号的登录请求，记录每个账号的设备信息；建立单元502，被配置成根据每个账号的设备信息为每个账号建立通信链路，其中，所述通信链路包括信令链路和/或轮询链路；状态检测单元503，被配置成响应于接收到主叫方呼叫被叫方的请求，检测所述被叫方的通话状态；呼叫单元504，被配置成若所述被叫方的通话状态为空闲，则通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求；状态更新单元505，被配置成响应于检测到所述被叫方接听，更新所述主叫方和所述被叫方的通话状态为忙碌。

在本实施例中，音视频通话装置500的登录单元501、建立单元502、状态检测单元503、呼叫单元504和状态更新单元505的具体处理可以参考图2对应实施例中的步骤201、步骤202、步骤203、步骤204和步骤205。

在本实施例的一些可选的实现方式中，装置500还包括唤起单元(附图中未示出)，被配置成：若所述被叫方的通话状态为离线，则触发唤起视频通话页面的流程，建立所述被叫方的通信链路。

在本实施例的一些可选的实现方式中，建立单元502进一步被配置成：对于通过Android设备和iOS设备登录的账号，建立信令链路。

在本实施例的一些可选的实现方式中，建立单元502进一步被配置成：对于通过个人计算机登录的账号，建立轮询链路。

在本实施例的一些可选的实现方式中，建立单元502进一步被配置成：若所述主叫方的通信链路为信令链路，则通过信令链路向所述被叫方发送所述请求。

在本实施例的一些可选的实现方式中，呼叫单元504进一步被配置成：若所述主叫方的通信链路为轮询链路，则通过轮询链路向所述被叫方发送所述请求。

在本实施例的一些可选的实现方式中，呼叫单元504进一步被配置成：若所述主叫方的通信链路为轮询链路和信令链路，则分别通过轮询链路和信令链路向所述被叫方发送所述请求。

在本实施例的一些可选的实现方式中，状态更新单元505进一步被配置为：响应于检测到所述被叫方接听了其中一条链路，取消另一条链路上的所述请求。

在本实施例的一些可选的实现方式中，状态更新单元505进一步被配置为：响应于检测到所述被叫方拒接了其中一条链路，结束所有链路上的视频通话。

在本实施例的一些可选的实现方式中，状态更新单元505进一步被配置为：响应于检测到所述被叫方拒接，更新所述主叫方和所述被叫方的通话状态为空闲。

在本实施例的一些可选的实现方式中，状态更新单元505进一步被配置为：响应于在所述被叫方未接听时检测到所述主叫方取消呼叫，结束视频通话并更新所述主叫方和所述被叫方的通话状态为空闲。

在本实施例的一些可选的实现方式中，状态更新单元505进一步被配置为：响应于在所述被叫方接听后检测到所述主叫方或被叫方挂断视频，结束视频通话并更新所述主叫方和所述被叫方的通话状态为空闲。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

一种电子设备，包括：至少一个处理器；以及与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行流程200或400所述的方法。

一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行流程200或400所述的方法。

一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现流程200或400所述的方法。

图6示出了可以用来实施本公开的实施例的示例电子设备600的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图6所示，设备600包括计算单元601，其可以根据存储在只读存储器(ROM)602中的计算机程序或者从存储单元608加载到随机访问存储器(RAM)603中的计算机程序，来执行各种适当的动作和处理。在RAM 603中，还可存储设备600操作所需的各种程序和数据。计算单元601、ROM 602以及RAM 603通过总线604彼此相连。输入/输出(I/O)接口605也连接至总线604。

设备600中的多个部件连接至I/O接口605，包括：输入单元606，例如键盘、鼠标等；输出单元607，例如各种类型的显示器、扬声器等；存储单元608，例如磁盘、光盘等；以及通信单元609，例如网卡、调制解调器、无线通信收发机等。通信单元609允许设备600通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元601可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元601的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元601执行上文所描述的各个方法和处理，例如音视频通话方法。例如，在一些实施例中，音视频通话方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元608。在一些实施例中，计算机程序的部分或者全部可以经由ROM 602和/或通信单元609而被载入和/或安装到设备600上。当计算机程序加载到RAM 603并由计算单元601执行时，可以执行上文描述的音视频通话方法的一个或多个步骤。备选地，在其他实施例中，计算单元601可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行音视频通话方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本发公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (27)

1.一种音视频通话方法，包括：

响应于接收到不同账号的登录请求，记录每个账号的设备信息；

根据每个账号的设备信息为每个账号建立通信链路，其中，所述通信链路包括信令链路和/或轮询链路；

响应于接收到主叫方呼叫被叫方的请求，检测所述被叫方的通话状态；

若所述被叫方的通话状态为空闲，则通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求；

响应于检测到所述被叫方接听，更新所述主叫方和所述被叫方的通话状态为忙碌。

2.根据权利要求1所述的方法，其中，所述方法还包括：

若所述被叫方的通话状态为离线，则触发唤起视频通话页面的流程，建立所述被叫方的通信链路。

3.根据权利要求1所述的方法，其中，所述根据每个账号的设备信息为每个账号建立通信链路，包括：

对于通过Android设备和iOS设备登录的账号，建立信令链路。

4.根据权利要求1所述的方法，其中，所述根据每个账号的设备信息为每个账号建立通信链路，包括：

对于通过个人计算机登录的账号，建立轮询链路。

5.根据权利要求1所述的方法，其中，所述通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求，包括：

若所述主叫方的通信链路为信令链路，则通过信令链路向所述被叫方发送所述请求。

6.根据权利要求1所述的方法，其中，所述通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求，包括：

若所述主叫方的通信链路为轮询链路，则通过轮询链路向所述被叫方发送所述请求。

7.根据权利要求1所述的方法，其中，所述通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求，包括：

若所述主叫方的通信链路为轮询链路和信令链路，则分别通过轮询链路和信令链路向所述被叫方发送所述请求。

8.根据权利要求7所述的方法，其中，所述方法还包括：

响应于检测到所述被叫方接听了其中一条链路，取消另一条链路上的所述请求。

9.根据权利要求7所述的方法，其中，所述方法还包括：

响应于检测到所述被叫方拒接了其中一条链路，结束所有链路上的视频通话。

10.根据权利要求1所述的方法，其中，所述方法还包括：

响应于检测到所述被叫方拒接，更新所述主叫方和所述被叫方的通话状态为空闲。

11.根据权利要求1所述的方法，其中，所述方法还包括：

响应于在所述被叫方未接听时检测到所述主叫方取消呼叫，结束视频通话并更新所述主叫方和所述被叫方的通话状态为空闲。

12.根据权利要求1所述的方法，其中，所述方法还包括：

响应于在所述被叫方接听后检测到所述主叫方或被叫方挂断视频，结束视频通话并更新所述主叫方和所述被叫方的通话状态为空闲。

13.一种音视频通话装置，包括：

登录单元，被配置成响应于接收到不同账号的登录请求，记录每个账号的设备信息；

建立单元，被配置成根据每个账号的设备信息为每个账号建立通信链路，其中，所述通信链路包括信令链路和/或轮询链路；

状态检测单元，被配置成响应于接收到主叫方呼叫被叫方的请求，检测所述被叫方的通话状态；

呼叫单元，被配置成若所述被叫方的通话状态为空闲，则通过与所述主叫方的通信链路匹配的所述被叫方的通信链路向所述被叫方发送所述请求；

状态更新单元，被配置成响应于检测到所述被叫方接听，更新所述主叫方和所述被叫方的通话状态为忙碌。

14.根据权利要求13所述的装置，其中，所述装置还包括唤起单元，被配置成：

若所述被叫方的通话状态为离线，则触发唤起视频通话页面的流程，建立所述被叫方的通信链路。

15.根据权利要求13所述的装置，其中，所述建立单元进一步被配置成：

对于通过Android设备和iOS设备登录的账号，建立信令链路。

16.根据权利要求13所述的装置，其中，所述建立单元进一步被配置成：

对于通过个人计算机登录的账号，建立轮询链路。

17.根据权利要求13所述的装置，其中，所述建立单元进一步被配置成：

若所述主叫方的通信链路为信令链路，则通过信令链路向所述被叫方发送所述请求。

18.根据权利要求13所述的装置，其中，所述呼叫单元进一步被配置成：

若所述主叫方的通信链路为轮询链路，则通过轮询链路向所述被叫方发送所述请求。

19.根据权利要求13所述的装置，其中，所述呼叫单元进一步被配置成：

若所述主叫方的通信链路为轮询链路和信令链路，则分别通过轮询链路和信令链路向所述被叫方发送所述请求。

20.根据权利要求19所述的装置，其中，所述状态更新单元进一步被配置为：

响应于检测到所述被叫方接听了其中一条链路，取消另一条链路上的所述请求。

21.根据权利要求19所述的装置，其中，所述状态更新单元进一步被配置为：

响应于检测到所述被叫方拒接了其中一条链路，结束所有链路上的视频通话。

22.根据权利要求13所述的装置，其中，所述状态更新单元进一步被配置为：

响应于检测到所述被叫方拒接，更新所述主叫方和所述被叫方的通话状态为空闲。

23.根据权利要求13所述的装置，其中，所述状态更新单元进一步被配置为：

响应于在所述被叫方未接听时检测到所述主叫方取消呼叫，结束视频通话并更新所述主叫方和所述被叫方的通话状态为空闲。

24.根据权利要求13所述的装置，其中，所述状态更新单元进一步被配置为：

响应于在所述被叫方接听后检测到所述主叫方或被叫方挂断视频，结束视频通话并更新所述主叫方和所述被叫方的通话状态为空闲。

25.一种用于音视频通话的电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-12中任一项所述的方法。

26.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-12中任一项所述的方法。

27.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-12中任一项所述的方法。

Images