CN113765939B - 呼叫方法、装置、设备及存储介质 - Google Patents

呼叫方法、装置、设备及存储介质 Download PDF

Info

Publication number
CN113765939B
CN113765939B CN202111227023.2A CN202111227023A CN113765939B CN 113765939 B CN113765939 B CN 113765939B CN 202111227023 A CN202111227023 A CN 202111227023A CN 113765939 B CN113765939 B CN 113765939B
Authority
CN
China
Prior art keywords
call
called
state
signaling
calling
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202111227023.2A
Other languages
English (en)
Other versions
CN113765939A (zh
Inventor
曹浩
阮良
陈丽
徐杭生
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Netease Zhiqi Technology Co Ltd
Original Assignee
Hangzhou Netease Zhiqi Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Netease Zhiqi Technology Co Ltd filed Critical Hangzhou Netease Zhiqi Technology Co Ltd
Priority to CN202111227023.2A priority Critical patent/CN113765939B/zh
Publication of CN113765939A publication Critical patent/CN113765939A/zh
Application granted granted Critical
Publication of CN113765939B publication Critical patent/CN113765939B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066Session management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10Architectures or entities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40Support for services or applications
    • H04L65/403Arrangements for multi-party communication, e.g. for conferences
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/54Presence management, e.g. monitoring or registration for receipt of user log-on information, or the connection status of the users

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Telephonic Communication Services (AREA)

Abstract

本公开的实施方式提供了一种呼叫方法、装置、设备及存储介质。该方法应用于第一服务器,包括:从呼叫设备接收呼叫指令,呼叫指令用于呼叫至少两个被呼叫设备;根据呼叫指令生成呼叫信令,并向第二服务器发送呼叫信令;获取呼叫设备和/或至少两个被呼叫设备的呼叫状态;向第二服务器发送呼叫设备和/或至少两个被呼叫设备的状态信令,状态信令用于指示对应的设备的呼叫状态。本公开实施例的方案,在多人呼叫的场景下,呼叫设备和任意一个被呼叫设备均能够获知其他设备的呼叫状态,实现了多人呼叫下的实时状态感知。

Description

呼叫方法、装置、设备及存储介质
技术领域
本公开的实施方式涉及通讯技术领域,更具体地,本公开的实施方式涉及一种呼叫方法、装置、设备及存储介质。
背景技术
本部分旨在为权利要求书中陈述的本公开的实施方式提供背景或上下文。此处的描述不因为包括在本部分中就承认是现有技术。
在移动互联网应用中,涉及到包括语音通话、视频通话、会议通话等呼叫过程。
呼叫的过程中,涉及到主动发起呼叫的呼叫方,以及接收呼叫的被呼叫方。在一个呼叫过程中,通常包括一个呼叫方和至少一个被呼叫方。当只存在一个被呼叫方时,呼叫过程为单人呼叫,当存在两个及以上被呼叫方时,呼叫过程为多人呼叫。
在单人呼叫的场景下,呼叫方和被呼叫方能够获知对方的呼叫状态,但是在多人呼叫的场景下,呼叫方以及各被呼叫方之间无法获知对方的呼叫状态。
发明内容
本公开的实施方式涉及一种呼叫方法、装置、设备及存储介质,以解决多人呼叫的场景下呼叫方以及各被呼叫方之间无法获知对方的呼叫状态的问题。
在本公开实施方式的第一方面中,提供了一种呼叫方法,应用于第一服务器,所述方法包括:
从呼叫设备接收呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备;
根据所述呼叫指令生成呼叫信令,并向第二服务器发送所述呼叫信令;
获取所述呼叫设备和/或所述至少两个被呼叫设备的呼叫状态;
向所述第二服务器发送所述呼叫设备和/或所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
在一种可能的实施方式中,所述获取所述呼叫设备和/或所述至少两个被呼叫设备的呼叫状态,包括:
根据预设时间间隔,在所述呼叫设备和所述至少两个被呼叫设备中,确定已响应的设备和未响应的设备;
获取所述已响应的设备的呼叫状态;
获取所述未响应的设备的呼叫状态。
在一种可能的实施方式中,所述获取所述已响应的设备的呼叫状态,包括:
获取所述已响应的设备的响应指令;
根据所述响应指令,获取所述已响应的设备的呼叫状态。
在一种可能的实施方式中,所述根据所述响应指令,获取所述已响应的设备的呼叫状态,包括:
根据所述呼叫设备的取消呼叫响应指令,获取所述呼叫设备的呼叫状态为取消呼叫状态;和/或,
根据所述被呼叫设备的同意呼叫响应指令,获取所述被呼叫设备的呼叫状态为同意呼叫状态;和/或,
根据所述被呼叫设备的拒绝呼叫响应指令,获取所述被呼叫设备的呼叫状态为拒绝呼叫状态。
在一种可能的实施方式中,所述未响应的设备为被呼叫设备;所述获取所述未响应的设备的呼叫状态,包括:
获取所述被呼叫设备的呼叫等待时长;
根据所述呼叫等待时长,获取所述被呼叫设备的呼叫状态。
在一种可能的实施方式中,若所述呼叫等待时长小于或等于预设时长,则确定所述被呼叫设备的呼叫状态为待接听状态;
若所述呼叫等待时长大于所述预设时长,则确定所述被呼叫设备的呼叫状态为超时取消状态。
在一种可能的实施方式中,所述被呼叫设备的呼叫状态为超时取消状态,所述方法还包括:
获取所述被呼叫设备的呼叫记录;
获取所述呼叫设备和所述至少两个被呼叫设备中除所述被呼叫设备外的其他设备的呼叫状态;
根据所述呼叫记录和所述其他设备的呼叫状态,生成更新信令;
通过所述第二服务器向所述被呼叫设备发送所述更新信令。
在一种可能的实施方式中,在所述向所述第二服务器发送所述呼叫设备和/或所述至少两个被呼叫设备的状态信令之前,包括:
针对所述任意设备,获取所述任意设备的目标设备的标识;
根据所述目标设备的标识和所述任意设备的呼叫状态,生成所述任意设备的状态信令。
在本公开实施方式的第二方面中,提供了一种呼叫方法,应用于第二服务器,所述方法包括:
从第一服务器接收呼叫信令,并分别向至少两个被呼叫设备发送所述呼叫信令;
从所述第一服务器接收呼叫设备和/或所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态;
向各设备的目标设备发送所述状态信令。
在本公开实施方式的第三方面中,提供了一种呼叫方法,应用于呼叫设备,所述方法包括:
向第一服务器发送呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备;
从第二服务器接收所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
在本公开实施方式的第四方面中,提供了一种呼叫方法,应用于被呼叫设备,所述方法包括:
从第二服务器接收呼叫信令,所述呼叫信令用于呼叫至少两个被呼叫设备;
从所述第二服务器接收呼叫设备和/或所述至少两个被呼叫设备中除所述被呼叫设备外的其他设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
在本公开实施方式的第五方面中,提供了一种呼叫装置,包括:
接收模块,用于从呼叫设备接收呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备;
第一发送模块,用于根据所述呼叫指令生成呼叫信令,并向第二服务器发送所述呼叫信令;
获取模块,用于获取所述呼叫设备和/或所述至少两个被呼叫设备的呼叫状态;
第二发送模块,用于向所述第二服务器发送所述呼叫设备和/或所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
在一种可能的实施方式中,所述获取模块具体用于:
根据预设时间间隔,在所述呼叫设备和所述至少两个被呼叫设备中,确定已响应的设备和未响应的设备;
获取所述已响应的设备的呼叫状态;
获取所述未响应的设备的呼叫状态。
在一种可能的实施方式中,所述获取模块具体用于:
获取所述已响应的设备的响应指令;
根据所述响应指令,获取所述已响应的设备的呼叫状态。
在一种可能的实施方式中,所述获取模块具体用于:
根据所述呼叫设备的取消呼叫响应指令,获取所述呼叫设备的呼叫状态为取消呼叫状态;和/或,
根据所述被呼叫设备的同意呼叫响应指令,获取所述被呼叫设备的呼叫状态为同意呼叫状态;和/或,
根据所述被呼叫设备的拒绝呼叫响应指令,获取所述被呼叫设备的呼叫状态为拒绝呼叫状态。
在一种可能的实施方式中,所述未响应的设备为被呼叫设备;所述获取模块具体用于:
获取所述被呼叫设备的呼叫等待时长;
根据所述呼叫等待时长,获取所述被呼叫设备的呼叫状态。
在一种可能的实施方式中,若所述呼叫等待时长小于或等于预设时长,则确定所述被呼叫设备的呼叫状态为待接听状态;
若所述呼叫等待时长大于所述预设时长,则确定所述被呼叫设备的呼叫状态为超时取消状态。
在一种可能的实施方式中,所述被呼叫设备的呼叫状态为超时取消状态,所述获取模块还用于:
获取所述被呼叫设备的呼叫记录;
获取所述呼叫设备和所述至少两个被呼叫设备中除所述被呼叫设备外的其他设备的呼叫状态;
根据所述呼叫记录和所述其他设备的呼叫状态,生成更新信令;
通过所述第二服务器向所述被呼叫设备发送所述更新信令。
在一种可能的实施方式中,在所述向所述第二服务器发送所述呼叫设备和/或所述至少两个被呼叫设备的状态信令之前,所述获取模块还用于:
针对所述任意设备,获取所述任意设备的目标设备的标识;
根据所述目标设备的标识和所述任意设备的呼叫状态,生成所述任意设备的状态信令。
在本公开实施方式的第六方面中,提供了一种呼叫装置,包括:
处理模块,用于从第一服务器接收呼叫信令,并分别向至少两个被呼叫设备发送所述呼叫信令;
接收模块,用于从所述第一服务器接收呼叫设备和/或所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态;
发送模块,用于向各设备的目标设备发送所述状态信令。
在本公开实施方式的第七方面中,提供了一种呼叫装置,包括:
发送模块,用于向第一服务器发送呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备;
接收模块,用于从第二服务器接收所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
在本公开实施方式的第八方面中,提供了一种呼叫装置,包括:
第一接收模块,用于从第二服务器接收呼叫信令,所述呼叫信令用于呼叫至少两个被呼叫设备;
第二接收模块,用于从所述第二服务器接收呼叫设备和/或所述至少两个被呼叫设备中除所述被呼叫设备外的其他设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
在本公开实施方式的第九方面中,提供了一种计算设备,包括:至少一个处理器和存储器;
所述存储器存储计算机执行指令;
所述至少一个处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如第一方面至第四方面任一项所述的呼叫方法。
在本公开实施方式的第十方面中,提供了一种计算机可读存储介质,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如第一方面至第四方面任一项所述的呼叫方法。
本公开实施例提供的呼叫方法、装置、设备及存储介质,在呼叫设备发起呼叫时,第一服务器从呼叫设备接收呼叫指令,该呼叫指令用于呼叫至少两个被呼叫设备。第一服务器根据呼叫指令生成呼叫信令,并通过第二服务器向这至少两个被呼叫设备发送呼叫信令,被呼叫设备接收到呼叫信令后,呼叫设备和被呼叫设备均可以对该呼叫进行响应或者不进行响应,然后第一服务器获取呼叫设备和/或至少两个被呼叫设备的呼叫状态,并向第二服务器发送呼叫设备和/或至少两个被呼叫设备的状态信令,从而向各设备指示对应的设备的呼叫状态。本公开实施例的方案,在多人呼叫的场景下,呼叫设备和任意一个被呼叫设备均能够获知其他设备的呼叫状态,实现了多人呼叫下的实时状态感知。
附图说明
通过参考附图阅读下文的详细描述,本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中,以示例性而非限制性的方式示出了本公开的若干实施方式,其中:
图1为本公开实施例提供的应用场景示意图;
图2为本公开实施例提供的呼叫方法的流程示意图一;
图3为本公开实施例提供的呼叫过程时序示意图;
图4为本公开实施例提供的待接听过程时序示意图;
图5为本公开实施例提供的超时取消过程时序示意图;
图6为本公开实施例提供的被呼叫方上线的时序示意图;
图7为本公开实施例提供的取消呼叫过程时序示意图;
图8为本公开实施例提供的同意呼叫过程时序示意图;
图9为本公开实施例提供的拒绝呼叫过程时序示意图;
图10为本公开实施例提供的呼叫状态界面示意图;
图11为本公开实施例提供的呼叫方法的流程示意图二;
图12为本公开实施例提供的呼叫方法的流程示意图三;
图13为本公开实施例提供的呼叫方法的流程示意图四;
图14为本公开实施例提供的程序产品示意图;
图15为本公开实施例提供的呼叫装置的结构示意图一;
图16为本公开实施例提供的呼叫装置的结构示意图二;
图17为本公开实施例提供的呼叫装置的结构示意图三;
图18为本公开实施例提供的呼叫装置的结构示意图四;
图19为本公开实施例提供的计算设备的结构示意图。
在附图中,相同或对应的标号表示相同或对应的部分。
具体实施方式
下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解,给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开,而并非以任何方式限制本公开的范围。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
本领域技术人员知道,本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此,本公开可以具体实现为以下形式,即:完全的硬件、完全的软件(包括固件、驻留软件、微代码等),或者硬件和软件结合的形式。
根据本公开的实施方式,提出了一种呼叫方法、装置、设备及存储介质。
附图中的任何元素数量均用于示例而非限制,以及任何命名都仅用于区分,而不具有任何限制含义。
下面参考本公开的若干代表性实施方式,详细阐释本公开的原理和精神。
发明概述
呼叫过程为呼叫设备对被呼叫设备发起呼叫的过程,呼叫过程可以嵌套于程序应用中,呼叫过程的形式例如可以包括语音通话、视频通话等等。呼叫场景包括单人呼叫场景和多人呼叫场景,单人呼叫指的是呼叫设备对一个被呼叫设备发起呼叫,多人呼叫指的是呼叫设备对至少两个被呼叫设备发起呼叫。
发明人发现,在单人呼叫场景下,呼叫方和被呼叫方能够获知对方的呼叫状态,但是在多人呼叫场景下,呼叫方以及各被呼叫方之间无法获知对方的呼叫状态。
在介绍了本公开的基本原理之后,下面具体介绍本公开的各种非限制性实施方式。
应用场景总览
首先参考图1对本公开实施例的应用场景进行介绍。
图1为本公开实施例提供的应用场景示意图,如图1所示,包括第一服务器11、第二服务器12、呼叫设备13和至少两个被呼叫设备,图1中示例了三个被呼叫设备,分别是被呼叫设备14、被呼叫设备15和被呼叫设备16。
呼叫设备13、被呼叫设备14、被呼叫设备15和被呼叫设备16均为终端设备,或客户端。呼叫设备13为发起呼叫的设备,呼叫设备13发起的呼叫可以基于呼叫设备13上的小程序或APP应用实现。当呼叫设备13发起呼叫时,第一服务器11可以接收到呼叫设备13发送的呼叫指令,该呼叫指令用于呼叫各被呼叫设备。
第二服务器12可以作为第一服务器11和呼叫设备13、第一服务器11和被呼叫设备(例如被呼叫设备14、被呼叫设备15和被呼叫设备16)之间信令传输的通道。例如,第一服务器11可以根据呼叫指令生成呼叫信令,并通过第二服务器12将呼叫信令发送给各被呼叫设备;例如,第一服务器11可以通过第二服务器12向呼叫设备和/或被呼叫设备发送状态信令,用于指示对应的设备的呼叫状态,等等。
本公开实施例中的指令为呼叫设备或被呼叫设备向第一服务器发送的指令,该指令可以是用户通过点击设备上的相应区域触发的指令。本公开实施例中涉及到的指令包括呼叫设备发送的呼叫指令、取消呼叫响应指令,以及被呼叫设备发送的同意呼叫响应指令和拒绝呼叫响应指令。第一服务器可以根据指令生成相应的信令。具体的,在生成信令之前,第一服务器可以根据指令解析相应的事件,生成指令对应的消息。由于消息不能直接被第二服务器识别,因此,第一服务器可以根据一定的信令协议对消息进行封装,生成相应的信令,从而可以被第二服务器识别。
示例性方法
下面结合图1的应用场景,参考图2来描述根据本公开示例性实施方式的呼叫方法。需要注意的是,上述应用场景仅是为了便于理解本公开的精神和原理而示出,本公开的实施方式在此方面不受任何限制。相反,本公开的实施方式可以应用于适用的任何场景。
图2为本公开实施例提供的呼叫方法的流程示意图一,该方法应用于第一服务器,如图2所示,该方法可以包括:
S21,从呼叫设备接收呼叫指令,呼叫指令用于呼叫至少两个被呼叫设备。
呼叫设备为发起呼叫的设备,一次呼叫中只有一个呼叫设备。被呼叫设备为接收呼叫的设备,一次呼叫中可以包括一个或多个被呼叫设备。本公开实施例中涉及到的是多人呼叫的场景,因此被呼叫设备的数量为至少两个。
第一服务器为呼叫应用中心,能够提供呼叫过程中的信息查询、呼叫记录保存、呼叫指令同步等应用服务。第二服务器为信令服务器,用于在呼叫设备发起呼叫时,为呼叫设备和被呼叫设备之间建立长链接通道,进行信令的转发。
当呼叫设备发起呼叫时,第一服务器接收呼叫设备发送的呼叫指令,该呼叫指令用于呼叫至少两个被呼叫设备。以呼叫设备上的某个应用程序为例,在打开该应用程序后,用户可以通过点击操作作用于呼叫设备,呼叫设备响应于用户的点击操作,发送呼叫指令。
S22,根据呼叫指令生成呼叫信令,并向第二服务器发送呼叫信令。
第一服务器在接收呼叫指令后,可以获知有呼叫事件发生。然后,第一服务器可以根据该呼叫指令生成呼叫信令。具体的,第一服务器根据呼叫指令解析呼叫事件,先生成呼叫消息。由于呼叫消息不能直接被第二服务器识别,因此,第一服务器需要对呼叫消息进行封装,生成对应的呼叫信令,然后向第二服务器发送该呼叫信令。第二服务器在接收到呼叫信令后,可以将该呼叫信令发送给各个被呼叫设备。
S23,获取呼叫设备和/或至少两个被呼叫设备的呼叫状态。
在被呼叫设备接收到呼叫信令后,被呼叫设备通过呼叫信令能够获知呼叫设备对其发起了呼叫。对于被呼叫设备而言,被呼叫设备可以响应呼叫设备发起的呼叫,也可以不响应呼叫设备发起的呼叫。对于呼叫设备而言,呼叫设备可以在发起呼叫后取消呼叫。
S24,向第二服务器发送呼叫设备和/或至少两个被呼叫设备的状态信令,状态信令用于指示对应的设备的呼叫状态。
在第一服务器获取了呼叫设备和/或被呼叫设备的呼叫状态后,生成相应的状态信令,并向第二服务器发送状态信令,通过第二服务器,将该状态信令发送给对应的目标设备,用于指示对应的设备的呼叫状态。
具体的,当状态信令为指示呼叫设备的呼叫状态的信令时,该状态信令对应的目标设备为被呼叫设备。当状态信令为指示被呼叫设备的呼叫状态的信令时,该状态信令对应的目标设备为呼叫设备和其他的被呼叫设备。以图1中的场景为例,当状态信令为指示呼叫设备13的呼叫状态的信令时,第一服务器11通过第二服务器12向被呼叫设备14、被呼叫设备15和被呼叫设备16发送该状态信令,被呼叫设备14、被呼叫设备15和被呼叫设备16根据该状态信令,可以获知呼叫设备13的呼叫状态;当状态信令为指示被呼叫设备14的呼叫状态的信令时,第一服务器11通过第二服务器12向呼叫设备13、被呼叫设备15和被呼叫设备16发送该状态信令,呼叫设备13、被呼叫设备15和被呼叫设备16根据该状态信令,可以获知被呼叫设备14的呼叫状态。
本公开实施例提供的呼叫方法,在呼叫设备发起呼叫时,第一服务器从呼叫设备接收呼叫指令,该呼叫指令用于呼叫至少两个被呼叫设备。第一服务器根据呼叫指令生成呼叫信令,并通过第二服务器向这至少两个被呼叫设备发送呼叫信令,被呼叫设备接收到呼叫信令后,呼叫设备和被呼叫设备均可以对该呼叫进行响应或者不进行响应,然后第一服务器获取呼叫设备和/或至少两个被呼叫设备的呼叫状态,并向第二服务器发送呼叫设备和/或至少两个被呼叫设备的状态信令,从而向各设备指示对应的设备的呼叫状态。本公开实施例的方案,在多人呼叫的场景下,呼叫设备和任意一个被呼叫设备均能够获知其他设备的呼叫状态,实现了多人呼叫下的实时状态感知。
下面结合附图对本公开的方案进行详细介绍。
呼叫过程
首先对呼叫设备发起呼叫的过程进行介绍。
图3为本公开实施例提供的呼叫过程时序示意图,如图3所示,包括如下步骤:
S31,呼叫设备向第一服务器发送呼叫指令。
当呼叫设备发起呼叫时,呼叫设备向第一服务器发送呼叫指令,该呼叫指令用于呼叫至少两个被呼叫设备,在图3的示例中,以至少两个被呼叫设备包括被呼叫设备A和被呼叫设备B为例。
S32,第一服务器保存呼叫记录,并根据呼叫指令生成呼叫信令。
第一服务器在接收到呼叫指令后,根据呼叫指令可以获知有呼叫设备发起了呼叫,第一服务器可以保存该呼叫记录,然后,根据呼叫指令生成呼叫信令。具体的,第一服务器在接收到呼叫指令后,对呼叫指令进行解析,首先生成呼叫消息。然后,第一服务器对呼叫消息进行封装,生成呼叫信令,呼叫信令可以被第二服务器识别。
S33,第一服务器向第二服务器发送呼叫信令。
第一服务器在生成呼叫信令后,需要通过第二服务器将呼叫信令发送给被呼叫设备,因此,第一服务器首先向第二服务器发送给呼叫信令,并指示第二服务器将呼叫信令发送给被呼叫设备。其中,呼叫信令中可以包括被呼叫设备A和被呼叫设备B的标识。第二服务器根据被呼叫设备A和被呼叫设备B的标识,获知该呼叫信令是需要发送给被呼叫设备A和被呼叫设备B的。
S34,第二服务器向被呼叫设备A和被呼叫设备B发送呼叫信令。
第二服务器在接收到呼叫信令后,向被呼叫设备A和被呼叫设备B发送呼叫信令。被呼叫设备A和被呼叫设备B在接收到呼叫信令后,根据呼叫信令可以获知呼叫设备对其发起了呼叫。被呼叫设备A和被呼叫设备B可以对呼叫设备发起的呼叫进行响应,也可以不进行响应。
然后,第一服务器可以获取呼叫设备和/或至少两个被呼叫设备的呼叫状态。具体的,第一服务器可以根据预设时间间隔,在呼叫设备和至少两个被呼叫设备中,确定已响应的设备和未响应的设备,其中,已响应的设备为通过第二服务器向第一服务器发送了响应指令的设备,未响应的设备为未通过第二服务器向第一服务器发送响应指令的设备。
在确定了已响应的设备和未响应的设备后,第一服务器可以分别获取已响应的设备的呼叫状态和未响应的设备的呼叫状态。然后,根据设备的呼叫状态生成对应的状态信令。针对呼叫设备和被呼叫设备中的任意设备而言,第一服务器在获取该任意设备的呼叫状态后,可以获取该任意设备的目标设备的标识,然后根据目标设备的标识和任意设备的呼叫状态,生成任意设备的状态信令。其中,当任意设备为呼叫设备时,对应的目标设备为各个被呼叫设备,当任意设备为某个被呼叫设备时,对应的目标设备为呼叫设备和除该被呼叫设备外的其他被呼叫设备。
状态信令是第一服务器依据一定的协议生成的,呼叫设备和被呼叫设备能够识别状态信令,并根据状态信令获知对应的设备的呼叫状态。状态信令是用于指示呼叫状态的,在状态信令中例如可以包括某个指示呼叫状态的字段。例如,当字段为00时,表示呼叫状态为同意呼叫,当字段为01时,表示呼叫状态为拒绝呼叫,当字段为10时,表示呼叫状态为待接听,当字段为11时,表示呼叫状态为超时取消,等等。第一服务器在生成状态信令后,通过第二服务器向相应的目标设备发送该状态信令。
针对未响应的设备而言,未响应的设备可以为被呼叫设备。对于未响应的被呼叫设备,第一服务器可以获取该被呼叫设备的呼叫等待时长,然后根据呼叫等待时长来获取被呼叫设备的呼叫状态。
待接听过程
图4为本公开实施例提供的待接听过程时序示意图,如图4所示,包括如下步骤:
S41,第一服务器定时轮询待接听的呼叫记录,并获取呼叫等待时长。
第一服务器定时轮询的时间间隔可以根据需要设定,例如可以设定为1s,2s或者其他适合的时间间隔,该时间间隔即为预设时间间隔。在第一服务器从呼叫设备接收呼叫指令并保存呼叫记录后,第一服务器可以记录呼叫等待时长。
S42,第一服务器根据呼叫等待时长确定未超时,生成被呼叫设备A的状态信令。
在呼叫设备发起呼叫后,第一服务器定时轮询待接听的呼叫记录。针对被呼叫设备A而言,在被呼叫设备A未对呼叫设备发起的呼叫进行响应时,第一服务器会获取呼叫等待时长,并根据呼叫等待时长判断是否超时。例如,可以设置一个预设时长,在呼叫等待时长小于或等于预设时长时,确定被呼叫设备A未超时;在呼叫等待时长大于预设时长时,确定被呼叫设备A超时。图4的示例中,第一服务器根据呼叫等待时长确定被呼叫设备A未超时,进而确定被呼叫设备A的呼叫状态为待接听状态。
在确定被呼叫设备A的呼叫状态后,根据被呼叫设备A的呼叫状态,生成被呼叫设备A的状态信令。
S43,第一服务器向第二服务器发送被呼叫设备A的状态信令。
第一服务器需要通过第二服务器向被呼叫设备A对应的目标设备发送状态信令,因此,第一服务器首先向第二服务器发送被呼叫设备A的状态信令。
S44,第二服务器向呼叫设备和被呼叫设备B发送被呼叫设备A的状态信令。
第二服务器在接收到被呼叫设备A的状态信令后,分别向呼叫设备和被呼叫设备B发送被呼叫设备A的状态信令。呼叫设备和被呼叫设备B在接收到被呼叫设备A的状态信令后,可以获知被呼叫设备A的呼叫状态为待接听状态。
图4示例了未响应的被呼叫设备A未超时时获取被呼叫设备A的呼叫状态的过程,下面结合图5介绍未响应的被呼叫设备A超时时获取被呼叫设备A的呼叫状态的过程。
超时取消过程
图5为本公开实施例提供的超时取消过程时序示意图,如图5所示,包括如下步骤:
S51,第一服务器定时轮询待接听的呼叫记录,并获取呼叫等待时长。
类似的,第一服务器定时轮询的时间间隔可以根据需要设定,例如可以设定为1s,2s或者其他适合的时间间隔。在第一服务器从呼叫设备接收呼叫指令并保存呼叫记录后,第一服务器可以记录呼叫等待时长。
S52,第一服务器根据呼叫等待时长确定超时,生成被呼叫设备A的状态信令。
在呼叫设备发起呼叫后,第一服务器定时轮询待接听的呼叫记录。针对被呼叫设备A而言,在被呼叫设备A未对呼叫设备发起的呼叫进行响应时,第一服务器会获取呼叫等待时长,并根据呼叫等待时长判断是否超时。在呼叫等待时长小于或等于预设时长时,确定被呼叫设备A未超时;在呼叫等待时长大于预设时长时,确定被呼叫设备A超时。图5的示例中,第一服务器根据呼叫等待时长确定被呼叫设备A超时,进而确定被呼叫设备A的呼叫状态为超时取消状态。
在确定被呼叫设备A的呼叫状态后,根据被呼叫设备A的呼叫状态,生成被呼叫设备A的状态信令。
S53,第一服务器向第二服务器发送被呼叫设备A的状态信令。
第一服务器需要通过第二服务器向被呼叫设备A对应的目标设备发送状态信令,因此,第一服务器首先向第二服务器发送被呼叫设备A的状态信令。
S54,第二服务器向呼叫设备和被呼叫设备B发送被呼叫设备A的状态信令。
第二服务器在接收到被呼叫设备A的状态信令后,分别向呼叫设备、被呼叫设备B发送被呼叫设备A的状态信令。呼叫设备和被呼叫设备B在接收到被呼叫设备A的状态信令后,可以获知被呼叫设备A的呼叫状态为超时取消状态。
在图5的示例中,介绍了被呼叫设备A超时取消时,第一服务器通过第二服务器向呼叫设备和被呼叫设备B指示被呼叫设备A超时取消的方案。在被呼叫设备A超时取消时,被呼叫设备A可能处于离线状态,未对呼叫设备发起的呼叫进行响应。当被呼叫设备A重新上线而呼叫过程未结束时,被呼叫设备A可以获取该呼叫记录,同时还可以获取其他设备的呼叫状态,下面将结合图6进行介绍。
被呼叫方上线过程
图6为本公开实施例提供的被呼叫方上线的时序示意图,如图6所示,包括如下步骤:
S61,第一服务器获取被呼叫设备A的呼叫记录。
被呼叫设备A的呼叫状态为超时取消状态时,被呼叫设备A可能处于离线状态。当被呼叫设备A上线后,第一服务器可以获取被呼叫设备A的呼叫记录。
具体的,由于第一服务器会在接收到呼叫设备发送的呼叫指令后,保存呼叫记录,因此,第一服务器可以查询与被呼叫设备A相关的呼叫记录。
S62,第一服务器获取呼叫设备和被呼叫设备B的呼叫状态。
在查询到被呼叫设备A的呼叫记录后,第一服务器可以获知该呼叫记录中涉及的呼叫设备和被呼叫设备,在图6的示例中即为呼叫设备和被呼叫设备B。然后,第一服务器获取呼叫设备和被呼叫设备B的呼叫状态。
S63,第一服务器根据呼叫记录、呼叫设备和被呼叫设备B的呼叫状态,生成更新信令。
第一服务器在获取呼叫设备和被呼叫设备B的呼叫状态后,可以根据该呼叫记录、呼叫设备和被呼叫设备B的呼叫状态,生成更新信令。
S64,向第二服务器发送更新信令。
第一服务器向第二服务器发送该更新信令,并指示第二服务器将该更新信令发给被呼叫设备A。
S65,第二服务器向被呼叫设备A发送更新信令。
第二服务器在接收到更新信令后,向被呼叫设备A发送更新信令。被呼叫设备A根据更新信令可以获取该呼叫记录,以及获知呼叫设备和被呼叫设备B的呼叫状态。
在上述实施例中介绍了如何获取未响应的设备的呼叫状态,下面将介绍如何获取已响应的设备的呼叫状态。
对于已响应的设备而言,已响应的设备可以向第一服务器发送响应指令,第一服务器获取已响应的设备的响应指令后,根据该响应指令,获取已响应的设备的呼叫状态,其中,已响应的设备可以为呼叫设备,也可以为被呼叫设备。
取消呼叫过程
图7为本公开实施例提供的取消呼叫过程时序示意图,如图7所示,包括如下步骤:
S71,呼叫设备向第一服务器发送取消呼叫响应指令。
图7示例的实施例中,已响应的设备为呼叫设备。呼叫设备在发起呼叫之后,又发起取消呼叫。即,呼叫设备向第一服务器发送取消呼叫响应指令。
S72,第一服务器根据取消呼叫响应指令生成呼叫设备的状态信令。
第一服务器在接收到取消呼叫响应指令后,可以获知呼叫设备取消了呼叫,然后,第一服务器对取消呼叫响应指令进行解析,生成取消呼叫响应消息。在生成取消呼叫响应消息后,由于取消呼叫响应消息不能直接被第二服务器识别,因此需要根据信令协议对取消呼叫响应消息进行封装处理,生成呼叫设备的状态信令,呼叫设备的状态信令用于指示呼叫设备的呼叫状态为取消呼叫状态。
S73,第一服务器向第二服务器发送呼叫设备的状态信令。
第一服务器在生成呼叫设备的状态信令后,向第二服务器发送呼叫设备的状态信令,指示第二服务器将呼叫设备的状态信令发送给呼叫设备对应的目标设备。
S74,第二服务器向被呼叫设备A和被呼叫设备B发送呼叫设备的状态信令。
呼叫设备对应的目标设备为被呼叫设备A和被呼叫设备B。第二服务器在接收到呼叫设备的状态信令后,分别向被呼叫设备A和被呼叫设备B发送呼叫设备的状态信令。被呼叫设备A和被呼叫设备B在获取到呼叫设备的状态信令后,可以根据呼叫设备的状态信令,获知呼叫设备的呼叫状态为取消呼叫状态。
同意呼叫过程
图8为本公开实施例提供的同意呼叫过程时序示意图,如图8所示,包括如下步骤:
S81,被呼叫设备B向第一服务器发送同意呼叫响应指令。
图8的示例中,已响应的设备为被呼叫设备B。被呼叫设备B在接收到第二服务器发送的呼叫信令后,对该呼叫信令进行响应,同意呼叫。即,被呼叫设备B向第一服务器发送同意呼叫响应指令。
S82,第一服务器根据同意呼叫响应指令生成被呼叫设备B的状态信令。
第一服务器在接收到同意呼叫响应指令后,可以获知被呼叫设备B同意接受呼叫设备发起的呼叫。然后,第一服务器对同意呼叫响应指令进行解析,生成同意呼叫响应消息。在生成同意呼叫响应消息后,由于同意呼叫响应消息不能直接被第二服务器识别,因此需要根据信令协议对同意呼叫响应消息进行封装处理,生成被呼叫设备B的状态信令,被呼叫设备B的状态信令用于指示被呼叫设备B的呼叫状态为同意呼叫状态。
S83,第一服务器向第二服务器发送被呼叫设备B的状态信令。
第一服务器在生成被呼叫设备B的状态信令后,向第二服务器发送被呼叫设备B的状态信令,指示第二服务器将被呼叫设备B的状态信令发送给被呼叫设备B对应的目标设备。
S84,第二服务器向呼叫设备和被呼叫设备A发送被呼叫设备B的状态信令。
被呼叫设备B对应的目标设备为呼叫设备和被呼叫设备A。第二服务器在接收到被呼叫设备B的状态信令后,分别向呼叫设备和被呼叫设备A发送被呼叫设备B的状态信令。呼叫设备和被呼叫设备A在获取到被呼叫设备B的状态信令后,可以根据被呼叫设备B的状态信令,获知被呼叫设备B的呼叫状态为同意呼叫状态。
图8示例了已响应的被呼叫设备B同意呼叫时获取被呼叫设备B的呼叫状态的过程,下面结合图9介绍已响应的被呼叫设备B拒绝呼叫时获取被呼叫设备B的呼叫状态的过程。
拒绝呼叫过程
图9为本公开实施例提供的拒绝呼叫过程时序示意图,如图9所示,包括如下步骤:
S91,被呼叫设备B向第一服务器发送拒绝呼叫响应指令。
图9的示例中,已响应的设备为被呼叫设备B。被呼叫设备B在接收到第二服务器发送的呼叫信令后,对该呼叫信令进行响应,拒绝呼叫。即,被呼叫设备B向第一服务器发送拒绝呼叫响应指令。
S92,第一服务器根据拒绝呼叫响应指令生成被呼叫设备B的状态信令。
第一服务器在接收到拒绝呼叫响应指令后,可以获知被呼叫设备B拒绝接受呼叫设备发起的呼叫。然后,第一服务器对拒绝呼叫响应指令进行解析,生成拒绝呼叫响应消息。在生成拒绝呼叫响应消息后,由于拒绝呼叫响应消息不能直接被第二服务器识别,因此需要根据信令协议对拒绝呼叫响应消息进行封装处理,生成被呼叫设备B的状态信令,被呼叫设备B的状态信令用于指示被呼叫设备B的呼叫状态为拒绝呼叫状态。
S93,第一服务器向第二服务器发送被呼叫设备B的状态信令。
第一服务器在生成被呼叫设备B的状态信令后,向第二服务器发送被呼叫设备B的状态信令,指示第二服务器将被呼叫设备B的状态信令发送给被呼叫设备B对应的目标设备。
S94,第二服务器向呼叫设备和被呼叫设备A发送被呼叫设备B的状态信令。
被呼叫设备B对应的目标设备为呼叫设备和被呼叫设备A。第二服务器在接收到被呼叫设备B的状态信令后,分别向呼叫设备和被呼叫设备A发送被呼叫设备B的状态信令。呼叫设备和被呼叫设备A在获取到被呼叫设备B的状态信令后,可以根据被呼叫设备B的状态信令,获知被呼叫设备B的呼叫状态为拒绝呼叫状态。
图10为本公开实施例提供的呼叫状态界面示意图,如图10所示,以被呼叫设备100的界面为例,在图10示例的多人呼叫场景中,发起呼叫的呼叫方为甲,被呼叫方包括被呼叫设备100对应的被呼叫方乙,以及被呼叫方丙和被呼叫方丁。
从被呼叫设备100的界面上可以看到,呼叫方甲发起呼叫后,被呼叫方乙和被呼叫方丙同意了呼叫,其对应的呼叫状态为同意呼叫状态,可以正常与呼叫方甲进行通话。被呼叫方丁拒绝了呼叫,其对应的呼叫状态为拒绝呼叫状态。
通过图10的示例,可以看到各呼叫方或被呼叫方均能够获知呼叫场景中的其他方的呼叫状态,实现多人呼叫场景下的呼叫状态感知。
图11为本公开实施例提供的呼叫方法的流程示意图二,该方法应用于第二服务器,如图11所示,该方法可以包括:
S111,从第一服务器接收呼叫信令,并分别向至少两个被呼叫设备发送呼叫信令。
图11示例的方法为第二服务器侧的方法,第二服务器主要用于实现呼叫设备/被呼叫设备与第一服务器之间信令的转发。呼叫设备为发起呼叫的设备,呼叫设备发起呼叫时,向第一服务器发送呼叫指令,呼叫指令用于呼叫至少两个被呼叫设备。
第一服务器在接收到呼叫设备发送的呼叫指令后,根据该呼叫指令生成呼叫信令,然后向第二服务器发送呼叫信令。第二服务器从第一服务器接收该呼叫信令后,分别向这至少两个被呼叫设备发送该呼叫信令。被呼叫设备在接收到该呼叫信令后,可以获知呼叫设备对其发起了呼叫。
对于被呼叫设备而言,被呼叫设备可以响应呼叫设备发起的呼叫,也可以不响应呼叫设备发起的呼叫。例如,当被呼叫设备响应呼叫设备发起的呼叫时,被呼叫设备可能是同意呼叫,也可能是拒绝呼叫。当被呼叫设备不响应呼叫设备发起的呼叫时,被呼叫设备可能是待接听,也可能是超时取消。
对于呼叫设备而言,呼叫设备可以在发起呼叫后取消呼叫。
S112,从第一服务器接收呼叫设备和/或至少两个被呼叫设备的状态信令,状态信令用于指示对应的设备的呼叫状态。
当被呼叫设备同意呼叫时,被呼叫设备的呼叫状态为同意呼叫状态;当被呼叫设备拒绝呼叫时,被呼叫设备的呼叫状态为拒绝呼叫状态;当被呼叫设备待接听时,被呼叫设备的呼叫状态为待接听状态;当被呼叫设备超时取消时,被呼叫设备的呼叫状态为超时取消状态;当呼叫设备取消呼叫时,呼叫设备的呼叫状态为取消呼叫状态。
在确定呼叫设备和/或被呼叫设备的呼叫状态后,第一服务器会生成对应的状态信令,该状态信令用于指示对应的设备的呼叫状态。然后,第一服务器向第二服务器发送呼叫设备和/或至少两个被呼叫设备的状态信令,通过第二服务器转发给对应的目标设备。
S113,向各设备的目标设备发送状态信令。
当状态信令为呼叫设备的状态信令时,对应的目标设备为各被呼叫设备。当状态信令为某个被呼叫设备的状态信令时,对应的目标设备为呼叫设备和各被呼叫设备中除该被呼叫设备以外的其他被呼叫设备。第二服务器在从第一服务器接收状态信令后,向对应的目标设备发送该状态信令即可。
第二服务器执行的呼叫方法的具体实现方式可参见上述实施例中的相关介绍,此处不再赘述。
图12为本公开实施例提供的呼叫方法的流程示意图三,该方法应用于呼叫设备,如图12所示,该方法可以包括:
S121,向第一服务器发送呼叫指令,呼叫指令用于呼叫至少两个被呼叫设备。
图12示例的方法为呼叫设备侧的方法,呼叫设备主要用于发起呼叫。呼叫设备发起呼叫时,向第一服务器发送呼叫指令。
第一服务器在接收到该呼叫指令后,根据呼叫指令生成呼叫信令,然后通过第二服务器分别向这至少两个被呼叫设备发送该呼叫信令。被呼叫设备在接收到呼叫信令后,获知呼叫设备对其发起了呼叫。
被呼叫设备可以响应呼叫设备发起的呼叫,也可以不响应呼叫设备发起的呼叫。例如,当被呼叫设备响应呼叫设备发起的呼叫时,被呼叫设备可能是同意呼叫,也可能是拒绝呼叫。当被呼叫设备不响应呼叫设备发起的呼叫时,被呼叫设备可能是待接听,也可能是超时取消。
当被呼叫设备同意呼叫时,其呼叫状态为同意呼叫状态;当被呼叫设备拒绝呼叫时,其呼叫状态为拒绝呼叫状态;当被呼叫设备待接听时,其呼叫状态为待接听状态;当被呼叫设备超时取消时,其呼叫状态为超时取消状态。
S122,从第二服务器接收至少两个被呼叫设备的状态信令,状态信令用于指示对应的设备的呼叫状态。
第一服务器在确定被呼叫设备的呼叫状态后,生成被呼叫设备的状态信令,然后将该状态信令发送给第二服务器。呼叫设备可以从第二服务器接收被呼叫设备的状态信令,从而根据状态信令获取对应的被呼叫设备的呼叫状态。
图13为本公开实施例提供的呼叫方法的流程示意图四,该方法应用于被呼叫设备,如图13所示,该方法可以包括:
S131,从第二服务器接收呼叫信令,呼叫信令用于呼叫至少两个被呼叫设备。
图13示例的方法为被呼叫设备侧的方法,被呼叫设备主要用于对呼叫设备发起的呼叫进行响应或不进行响应。当被呼叫设备从第二服务器接收呼叫信令后,可以获知呼叫设备对其发起了呼叫。这至少两个被呼叫设备中的任意一个被呼叫设备,可能对呼叫设备发起的呼叫进行响应,也可能不对呼叫设备发起的呼叫进行响应。呼叫设备在发起呼叫后,也可以取消呼叫。
针对任意一个被呼叫设备而言,若该被呼叫设备对呼叫设备发起的呼叫进行响应,例如同意呼叫或拒绝呼叫,则第一服务器可以确定该被呼叫设备的呼叫状态为同意呼叫状态,或者,确定该被呼叫设备的呼叫状态为拒绝呼叫状态;若该被呼叫设备对呼叫设备发起的呼叫不进行响应,第一服务器可以根据呼叫等待时长是否超过预设时长,确定该被呼叫设备的呼叫状态为待接听状态或超时取消状态。针对呼叫设备而言,若呼叫设备在发起呼叫后又取消呼叫,则第一服务器确定呼叫设备的呼叫状态为取消呼叫状态。
S132,从第二服务器接收呼叫设备和/或至少两个被呼叫设备中除被呼叫设备外的其他设备的状态信令,状态信令用于指示对应的设备的呼叫状态。
第一服务器在确定呼叫设备和/或至少两个被呼叫设备的呼叫状态后,会生成对应的状态信令,然后通过第二服务器将状态信令发送给相应的目标设备。对于任意一个被呼叫设备而言,该被呼叫设备可以获取呼叫设备的状态信令,根据呼叫设备的状态信令获取呼叫设备的呼叫状态,还可以获取其他被呼叫设备的状态信令,根据其他被呼叫设备的状态信令获取其他被呼叫设备的呼叫状态。
本公开实施例提供的呼叫方法,在呼叫设备发起呼叫时,第一服务器从呼叫设备接收呼叫指令,该呼叫指令用于呼叫至少两个被呼叫设备。第一服务器根据呼叫指令生成呼叫信令,并通过第二服务器向这至少两个被呼叫设备发送呼叫信令,被呼叫设备接收到呼叫信令后,呼叫设备和被呼叫设备均可以对该呼叫进行响应或者不进行响应,然后第一服务器获取呼叫设备和/或至少两个被呼叫设备的呼叫状态,并向第二服务器发送呼叫设备和/或至少两个被呼叫设备的状态信令,从而向各设备指示对应的设备的呼叫状态。本公开实施例的方案,在多人呼叫的场景下,呼叫设备和任意一个被呼叫设备均能够获知其他设备的呼叫状态,实现了多人呼叫下的实时状态感知。
示例性介质
在介绍了本公开示例性实施方式的方法之后,接下来,参考图14对本公开示例性实施方式的存储介质进行说明。
图14为本公开实施例提供的程序产品示意图,参考图14所示,描述了根据本公开的实施方式的用于实现上述方法的程序产品140,其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码,并可以在终端设备,例如个人电脑上运行。然而,本公开的程序产品不限于此。
所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件,或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括:具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号,其中承载了可读程序代码。这种传播的数据信号可以采用多种形式,包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。
可以以一种或多种程序设计语言的任意组合来编写用于执行本公开公开操作的程序代码,所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等,还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络,包括局域网(LAN)或广域网(WAN),连接到用户计算设备。
示例性装置
在介绍了本公开示例性实施方式的介质之后,接下来,参考图15-图18对本公开示例性实施方式的呼叫装置进行说明,用于实现上述任一方法实施例中的方法,其实现原理和技术效果类似,在此不再赘述。
图15为本公开实施例提供的呼叫装置的结构示意图一,如图15所示,该呼叫装置150包括:
接收模块151,用于从呼叫设备接收呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备;
第一发送模块152,用于根据所述呼叫指令生成呼叫信令,并向第二服务器发送所述呼叫信令;
获取模块153,用于获取所述呼叫设备和/或所述至少两个被呼叫设备的呼叫状态;
第二发送模块154,用于向所述第二服务器发送所述呼叫设备和/或所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
在一种可能的实施方式中,所述获取模块153具体用于:
根据预设时间间隔,在所述呼叫设备和所述至少两个被呼叫设备中,确定已响应的设备和未响应的设备;
获取所述已响应的设备的呼叫状态;
获取所述未响应的设备的呼叫状态。
在一种可能的实施方式中,所述获取模块153具体用于:
获取所述已响应的设备的响应指令;
根据所述响应指令,获取所述已响应的设备的呼叫状态。
在一种可能的实施方式中,所述获取模块153具体用于:
根据所述呼叫设备的取消呼叫响应指令,获取所述呼叫设备的呼叫状态为取消呼叫状态;和/或,
根据所述被呼叫设备的同意呼叫响应指令,获取所述被呼叫设备的呼叫状态为同意呼叫状态;和/或,
根据所述被呼叫设备的拒绝呼叫响应指令,获取所述被呼叫设备的呼叫状态为拒绝呼叫状态。
在一种可能的实施方式中,所述未响应的设备为被呼叫设备;所述获取模块153具体用于:
获取所述被呼叫设备的呼叫等待时长;
根据所述呼叫等待时长,获取所述被呼叫设备的呼叫状态。
在一种可能的实施方式中,若所述呼叫等待时长小于或等于预设时长,则确定所述被呼叫设备的呼叫状态为待接听状态;
若所述呼叫等待时长大于所述预设时长,则确定所述被呼叫设备的呼叫状态为超时取消状态。
在一种可能的实施方式中,所述被呼叫设备的呼叫状态为超时取消状态,所述获取模块153还用于:
获取所述被呼叫设备的呼叫记录;
获取所述呼叫设备和所述至少两个被呼叫设备中除所述被呼叫设备外的其他设备的呼叫状态;
根据所述呼叫记录和所述其他设备的呼叫状态,生成更新信令;
通过所述第二服务器向所述被呼叫设备发送所述更新信令。
在一种可能的实施方式中,在所述向所述第二服务器发送所述呼叫设备和/或所述至少两个被呼叫设备的状态信令之前,所述获取模块153还用于:
针对所述任意设备,获取所述任意设备的目标设备的标识;
根据所述目标设备的标识和所述任意设备的呼叫状态,生成所述任意设备的状态信令。
本公开实施例提供的呼叫装置,可用于执行上述方法实施例的技术方案,其实现原理和技术效果类似,此处不再赘述。
图16为本公开实施例提供的呼叫装置的结构示意图二,如图16所示,该呼叫装置160包括:
处理模块161,用于从第一服务器接收呼叫信令,并分别向至少两个被呼叫设备发送所述呼叫信令;
接收模块162,用于从所述第一服务器接收呼叫设备和/或所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态;
发送模块163,用于向各设备的目标设备发送所述状态信令。
本公开实施例提供的呼叫装置,可用于执行上述方法实施例的技术方案,其实现原理和技术效果类似,此处不再赘述。
图17为本公开实施例提供的呼叫装置的结构示意图三,如图17所示,该呼叫装置170包括:
发送模块171,用于向第一服务器发送呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备;
接收模块172,用于从第二服务器接收所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
本公开实施例提供的呼叫装置,可用于执行上述方法实施例的技术方案,其实现原理和技术效果类似,此处不再赘述。
图18为本公开实施例提供的呼叫装置的结构示意图四,如图18所示,该呼叫装置180包括:
第一接收模块181,用于从第二服务器接收呼叫信令,所述呼叫信令用于呼叫至少两个被呼叫设备;
第二接收模块182,用于从所述第二服务器接收呼叫设备和/或所述至少两个被呼叫设备中除所述被呼叫设备外的其他设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态。
本公开实施例提供的呼叫装置,可用于执行上述方法实施例的技术方案,其实现原理和技术效果类似,此处不再赘述。
示例性计算设备
在介绍了本公开示例性实施方式的方法、介质和装置之后,接下来,参考图19对本公开示例性实施方式的计算设备进行说明。
图19显示的计算设备190仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
图19为本公开实施例提供的计算设备的结构示意图,如图19所示,计算设备190以通用计算设备的形式表现。计算设备190的组件可以包括但不限于:上述至少一个处理单元191、上述至少一个存储单元192,连接不同系统组件(包括处理单元191和存储单元192)的总线193。
总线193包括数据总线、控制总线和地址总线。
存储单元192可以包括易失性存储器形式的可读介质,例如随机存取存储器(RAM)1921和/或高速缓存存储器1922,可以进一步包括非易失性存储器形式的可读介质,例如只读存储器(ROM)1923。
存储单元192还可以包括具有一组(至少一个)程序模块1924的程序/实用工具1925,这样的程序模块1924包括但不限于:操作系统、一个或者多个应用程序、其它程序模块以及程序数据,这些示例中的每一个或某种组合中可能包括网络环境的实现。
计算设备190也可以与一个或多个外部设备194(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(I/O)接口195进行。并且,计算设备190还可以通过网络适配器196与一个或者多个网络(例如局域网(LAN),广域网(WAN)和/或公共网络,例如因特网)通信。如图19所示,网络适配器196通过总线193与计算设备190的其它模块通信。应当理解,尽管图中未示出,可以结合计算设备190使用其它硬件和/或软件模块,包括但不限于:微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。
应当注意,尽管在上文详细描述中提及了呼叫装置的若干单元/模块或子单元/模块,但是这种划分仅仅是示例性的并非强制性的。实际上,根据本公开的实施方式,上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之,上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。
此外,尽管在附图中以特定顺序描述了本公开方法的操作,但是,这并非要求或者暗示必须按照该特定顺序来执行这些操作,或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地,可以省略某些步骤,将多个步骤合并为一个步骤执行,和/或将一个步骤分解为多个步骤执行。
虽然已经参考若干具体实施方式描述了本公开的精神和原理,但是应该理解,本公开并不限于所公开的具体实施方式,对各方面的划分也不意味着这些方面中的特征不能组合以进行受益,这种划分仅是为了表述的方便。本公开旨在涵盖所附权利要求的精神和范围内所包括的各种修改和等同布置。

Claims (22)

1.一种呼叫方法,其特征在于,应用于第一服务器,所述方法包括:
从呼叫设备接收呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备,所述至少两个被呼叫设备包括第一被呼叫设备;
根据所述呼叫指令生成呼叫信令,并向第二服务器发送所述呼叫信令;
获取所述至少两个被呼叫设备的呼叫状态;
向所述第二服务器发送所述至少两个被呼叫设备的状态信令,针对每一个被呼叫设备的状态信令,所述状态信令用于所述第二服务器将所述状态信令发送给所述呼叫设备和与所述状态信令对应的被呼叫设备之外的其他被呼叫设备,所述状态信令用于指示对应的设备的呼叫状态;
若所述第一被呼叫设备的呼叫状态为超时取消状态,在所述第一被呼叫设备上线且呼叫过程未结束时,所述方法还包括:
获取所述第一被呼叫设备的呼叫记录;
获取所述呼叫设备和所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的呼叫状态;
根据所述呼叫记录、呼叫设备的呼叫状态和所述其他设备的呼叫状态,生成更新信令;
通过所述第二服务器向所述第一被呼叫设备发送所述更新信令。
2.根据权利要求1所述的呼叫方法,其特征在于,所述方法,还包括:
获取所述呼叫设备的呼叫状态;
向所述第二服务器发送所述呼叫设备的状态信令;
其中,获取所述呼叫设备和所述至少两个被呼叫设备的呼叫状态,包括:
根据预设时间间隔,在所述呼叫设备和所述至少两个被呼叫设备中,确定已响应的设备和未响应的设备;
获取所述已响应的设备的呼叫状态;
获取所述未响应的设备的呼叫状态。
3.根据权利要求2所述的呼叫方法,其特征在于,所述获取所述已响应的设备的呼叫状态,包括:
获取所述已响应的设备的响应指令;
根据所述响应指令,获取所述已响应的设备的呼叫状态。
4.根据权利要求3所述的呼叫方法,其特征在于,所述根据所述响应指令,获取所述已响应的设备的呼叫状态,包括:
根据所述呼叫设备的取消呼叫响应指令,获取所述呼叫设备的呼叫状态为取消呼叫状态;
根据所述被呼叫设备的同意呼叫响应指令,获取所述被呼叫设备的呼叫状态为同意呼叫状态;和/或,根据所述被呼叫设备的拒绝呼叫响应指令,获取所述被呼叫设备的呼叫状态为拒绝呼叫状态。
5.根据权利要求2所述的呼叫方法,其特征在于,所述未响应的设备为被呼叫设备;所述获取所述未响应的设备的呼叫状态,包括:
获取所述被呼叫设备的呼叫等待时长;
根据所述呼叫等待时长,获取所述被呼叫设备的呼叫状态。
6.根据权利要求5所述的呼叫方法,其特征在于,若所述呼叫等待时长小于或等于预设时长,则确定所述被呼叫设备的呼叫状态为待接听状态;
若所述呼叫等待时长大于所述预设时长,则确定所述被呼叫设备的呼叫状态为超时取消状态。
7.根据权利要求1-6任一项所述的呼叫方法,其特征在于,在所述向所述第二服务器发送所述至少两个被呼叫设备的状态信令之前,包括:
针对任意设备,获取所述任意设备的目标设备的标识;
根据所述目标设备的标识和所述任意设备的呼叫状态,生成所述任意设备的状态信令。
8.一种呼叫方法,其特征在于,应用于第二服务器,所述方法包括:
从第一服务器接收呼叫信令,并分别向至少两个被呼叫设备发送所述呼叫信令,所述至少两个被呼叫设备包括第一被呼叫设备;
从所述第一服务器接收所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态;
针对每一个被呼叫设备的状态信令,将所述状态信令发送给所述呼叫设备和与所述状态信令对应的被呼叫设备之外的其他被呼叫设备;
若所述第一被呼叫设备的呼叫状态为超时取消状态,在所述第一被呼叫设备上线且呼叫过程未结束时,所述方法还包括:
从第一服务器接收更新信令;
向所述第一被呼叫设备发送所述更新信令;所述更新信令为所述第一服务器根据所述第一被呼叫设备的呼叫记录、呼叫设备的呼叫状态和所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的呼叫状态生成的。
9.一种呼叫方法,其特征在于,应用于呼叫设备,所述方法包括:
向第一服务器发送呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备,所述至少两个被呼叫设备包括第一被呼叫设备;所述第一服务器用于在所述第一被呼叫设备为超时取消状态,所述第一被呼叫设备上线且呼叫过程未结束时,获取所述第一被呼叫设备的呼叫记录以及所述呼叫设备和所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的呼叫状态,并根据所述呼叫记录、呼叫设备的呼叫状态和所述其他设备的呼叫状态,生成更新信令,并通过第二服务器向所述第一被呼叫设备发送所述更新信令;
从所述第二服务器接收所述至少两个被呼叫设备的状态信令,针对每一个被呼叫设备的状态信令,所述状态信令用于所述第二服务器将所述状态信令发送给所述呼叫设备和与所述状态信令对应的被呼叫设备之外的其他被呼叫设备,所述状态信令用于指示对应的设备的呼叫状态。
10.一种呼叫方法,其特征在于,应用于第一被呼叫设备,所述方法包括:
从第二服务器接收呼叫信令,所述呼叫信令用于呼叫至少两个被呼叫设备,所述至少两个被呼叫设备包括所述第一被呼叫设备;
从所述第二服务器接收所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态;
若所述第一被呼叫设备的呼叫状态为超时取消状态,在所述第一被呼叫设备上线且呼叫过程未结束时,所述方法还包括:
从所述第二服务器接收更新信令;所述更新信令为第一服务器根据所述第一被呼叫设备的呼叫记录、呼叫设备的呼叫状态和所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的呼叫状态生成的。
11.一种呼叫装置,其特征在于,包括:
接收模块,用于从呼叫设备接收呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备,所述至少两个被呼叫设备包括第一被呼叫设备;
第一发送模块,用于根据所述呼叫指令生成呼叫信令,并向第二服务器发送所述呼叫信令;
获取模块,用于获取所述至少两个被呼叫设备的呼叫状态;
第二发送模块,用于向所述第二服务器发送所述至少两个被呼叫设备的状态信令,针对每一个被呼叫设备的状态信令,所述状态信令用于所述第二服务器用于将所述状态信令发送给所述呼叫设备和与所述状态信令对应的被呼叫设备之外的其他被呼叫设备,所述状态信令用于指示对应的设备的呼叫状态;
若所述第一被呼叫设备的呼叫状态为超时取消状态,在所述第一被呼叫设备上线且呼叫过程未结束时,所述获取模块还用于:
获取所述第一被呼叫设备的呼叫记录;
获取所述呼叫设备和所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的呼叫状态;
根据所述呼叫记录、呼叫设备的呼叫状态和所述其他设备的呼叫状态,生成更新信令;
通过所述第二服务器向所述第一被呼叫设备发送所述更新信令。
12.根据权利要求11所述的呼叫装置,其特征在于,所述获取模块还用于获取所述呼叫设备的呼叫状态;
所述第二发送模块,还用于向所述第二服务器发送所述呼叫设备的状态信令;
其中,所述获取模块具体用于:
根据预设时间间隔,在所述呼叫设备和所述至少两个被呼叫设备中,确定已响应的设备和未响应的设备;
获取所述已响应的设备的呼叫状态;
获取所述未响应的设备的呼叫状态。
13.根据权利要求12所述的呼叫装置,其特征在于,所述获取模块具体用于:
获取所述已响应的设备的响应指令;
根据所述响应指令,获取所述已响应的设备的呼叫状态。
14.根据权利要求13所述的呼叫装置,其特征在于,所述获取模块具体用于:
根据所述呼叫设备的取消呼叫响应指令,获取所述呼叫设备的呼叫状态为取消呼叫状态;根据所述被呼叫设备的同意呼叫响应指令,获取所述被呼叫设备的呼叫状态为同意呼叫状态;和/或,
根据所述被呼叫设备的拒绝呼叫响应指令,获取所述被呼叫设备的呼叫状态为拒绝呼叫状态。
15.根据权利要求12所述的呼叫装置,其特征在于,所述未响应的设备为被呼叫设备;所述获取模块具体用于:
获取所述被呼叫设备的呼叫等待时长;
根据所述呼叫等待时长,获取所述被呼叫设备的呼叫状态。
16.根据权利要求15所述的呼叫装置,其特征在于,若所述呼叫等待时长小于或等于预设时长,则确定所述被呼叫设备的呼叫状态为待接听状态;
若所述呼叫等待时长大于所述预设时长,则确定所述被呼叫设备的呼叫状态为超时取消状态。
17.根据权利要求11-16任一项所述的呼叫装置,其特征在于,在所述向所述第二服务器发送所述至少两个被呼叫设备的状态信令之前,所述获取模块还用于:
针对任意设备,获取所述任意设备的目标设备的标识;
根据所述目标设备的标识和所述任意设备的呼叫状态,生成所述任意设备的状态信令。
18.一种呼叫装置,其特征在于,包括:
处理模块,用于从第一服务器接收呼叫信令,并分别向至少两个被呼叫设备发送所述呼叫信令,所述至少两个被呼叫设备包括第一被呼叫设备;
接收模块,用于从所述第一服务器接收所述至少两个被呼叫设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态;
发送模块,用于针对每一个被呼叫设备的状态信令,将所述状态信令发送给所述呼叫设备和与所述状态信令对应的被呼叫设备之外的其他被呼叫设备;
若所述第一被呼叫设备的呼叫状态为超时取消状态,在所述第一被呼叫设备上线且呼叫过程未结束时,所述接收模块,还用于:从第一服务器接收更新信令;
所述发送模块,还用于向所述第一被呼叫设备发送所述更新信令;所述更新信令为所述第一服务器根据所述第一被呼叫设备的呼叫记录、呼叫设备的呼叫状态和所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的呼叫状态生成的。
19.一种呼叫装置,其特征在于,包括:
发送模块,用于向第一服务器发送呼叫指令,所述呼叫指令用于呼叫至少两个被呼叫设备,所述至少两个被呼叫设备包括第一被呼叫设备;所述第一服务器用于在所述第一被呼叫设备为超时取消状态,所述第一被呼叫设备上线且呼叫过程未结束时,获取所述第一被呼叫设备的呼叫记录以及所述呼叫设备和所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的呼叫状态,并根据所述呼叫记录、呼叫设备的呼叫状态和所述其他设备的呼叫状态,生成更新信令,并通过第二服务器向所述第一被呼叫设备发送所述更新信令;
接收模块,用于从所述第二服务器接收所述至少两个被呼叫设备的状态信令,针对每一个被呼叫设备的状态信令,所述状态信令用于所述第二服务器将所述状态信令发送给所述呼叫设备和与所述状态信令对应的被呼叫设备之外的其他被呼叫设备,所述状态信令用于指示对应的设备的呼叫状态。
20.一种呼叫装置,其特征在于,包括:
第一接收模块,用于从第二服务器接收呼叫信令,所述呼叫信令用于呼叫至少两个被呼叫设备,所述至少两个被呼叫设备包括第一被呼叫设备;
第二接收模块,用于从所述第二服务器接收所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的状态信令,所述状态信令用于指示对应的设备的呼叫状态;
若所述第一被呼叫设备的呼叫状态为超时取消状态,在所述第一被呼叫设备上线且呼叫过程未结束时,所述第二接收模块,还用于:
从所述第二服务器接收更新信令;所述更新信令为第一服务器根据所述第一被呼叫设备的呼叫记录、呼叫设备的呼叫状态和所述至少两个被呼叫设备中除所述第一被呼叫设备外的其他设备的呼叫状态生成的。
21.一种计算设备,其特征在于,包括:至少一个处理器和存储器;
所述存储器存储计算机执行指令;
所述至少一个处理器执行所述存储器存储的计算机执行指令,使得所述至少一个处理器执行如权利要求1-10任一项所述的呼叫方法。
22.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质中存储有计算机执行指令,当处理器执行所述计算机执行指令时,实现如权利要求1-10任一项所述的呼叫方法。
CN202111227023.2A 2021-10-21 2021-10-21 呼叫方法、装置、设备及存储介质 Active CN113765939B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111227023.2A CN113765939B (zh) 2021-10-21 2021-10-21 呼叫方法、装置、设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111227023.2A CN113765939B (zh) 2021-10-21 2021-10-21 呼叫方法、装置、设备及存储介质

Publications (2)

Publication Number Publication Date
CN113765939A CN113765939A (zh) 2021-12-07
CN113765939B true CN113765939B (zh) 2023-08-01

Family

ID=78784240

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111227023.2A Active CN113765939B (zh) 2021-10-21 2021-10-21 呼叫方法、装置、设备及存储介质

Country Status (1)

Country Link
CN (1) CN113765939B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117478793A (zh) * 2022-07-22 2024-01-30 中兴通讯股份有限公司 语音通话方法、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200425660A (en) * 2002-12-31 2004-11-16 Motorola Inc Methods for affiliating endpoints with a group and determining common communication capabilities for the affiliated endpoints
CN108540432A (zh) * 2017-03-06 2018-09-14 展讯通信(上海)有限公司 多方通话中呼入被叫的方法、装置、多通终端及网络侧设备
GB201816863D0 (en) * 2018-10-16 2018-11-28 Software Hothouse Ltd System and method for hands-free advanced control of real-time data stream interactions

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010096546A1 (en) * 2009-02-18 2010-08-26 MBTE Holdings Sweden AB Telephone call scheduling and initiation system
CN102917142B (zh) * 2011-08-01 2015-11-25 上海贝尔股份有限公司 遇忙建立呼叫的方法和装置
US9986052B1 (en) * 2016-11-28 2018-05-29 Facebook, Inc. Methods and systems for notifying callee availability

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200425660A (en) * 2002-12-31 2004-11-16 Motorola Inc Methods for affiliating endpoints with a group and determining common communication capabilities for the affiliated endpoints
CN108540432A (zh) * 2017-03-06 2018-09-14 展讯通信(上海)有限公司 多方通话中呼入被叫的方法、装置、多通终端及网络侧设备
GB201816863D0 (en) * 2018-10-16 2018-11-28 Software Hothouse Ltd System and method for hands-free advanced control of real-time data stream interactions

Also Published As

Publication number Publication date
CN113765939A (zh) 2021-12-07

Similar Documents

Publication Publication Date Title
CN112492252B (zh) 通话方法及智能设备
TWI489852B (zh) 用於傳送錯誤回復之技術
US10320980B2 (en) User device detection and integration for an IVR system
US9065788B2 (en) Method, device and system for voice communication
US20090109961A1 (en) Multiple simultaneous call management using voice over internet protocol
EP2974159B1 (en) Method, device and system for voice communication
US20050021868A1 (en) Communications server method & apparatus for transacting voice, text, video and graphical data communication sessions from both wireless and wire-line networks
CN113765939B (zh) 呼叫方法、装置、设备及存储介质
CN110365931A (zh) 多方通话的控制方法及装置、电子设备、存储介质
CN113099055A (zh) 一种通信方法、系统、装置、电子设备及存储介质
WO2022257591A1 (zh) 通话切换方法、装置、终端和计算机可读存储介质
CN115801894A (zh) 通信服务系统、通信服务的实现方法、设备及存储介质
RU2670096C2 (ru) Способ и аппарат для завершения видеосвязи
US8804936B2 (en) Shared media access for real time first and third party media control
US20070070985A1 (en) System and Method for Integrating Internet Phone to Ordinary Phone
WO2022247404A1 (zh) 通话控制方法、装置、通话系统、可穿戴设备及可读介质
CN113497764B (zh) 业务路由方法、系统、计算机存储介质和电子设备
CN112291216B (zh) 通信方法、装置和电子设备
US20190089753A1 (en) Conference system and method for handling conference connection thereof
CN117641516B (zh) 一种多媒体设备智能交互控制方法及系统
CN113141292B (zh) 一种消息处理方法、装置及电子设备
JP4774884B2 (ja) ソフトフォン機能を備える通信端末
CN111899764B (zh) 音频监控方法、装置、计算机设备及存储介质
CN115150215A (zh) 家庭组播实现方法和装置、计算机存储介质、电子设备
CN116260856A (zh) 音视频通话方法和装置

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant