一种连麦系统、方法、装置、设备及存储介质

技术领域

本公开涉及数据处理领域，尤其涉及一种连麦系统、方法、装置、设备及存储介质。

背景技术

随着直播技术的不断发展，连麦已经成为一种深受用户喜爱的娱乐方式，其中，主播之间或者主播和观众之间可通过连麦进行各种各样的连麦活动，例如连麦PK活动。

目前，连麦被邀端的用户在点击接受连麦活动邀请之后，在用户界面上加载连麦活动对应的预设控件的耗时较长，影响了用户对连麦活动的体验。

因此，如何减少用户界面上加载连麦活动对应的预设控件的耗时，提升了用户对连麦活动的体验是目前亟需解决的技术问题。

发明内容

为了解决上述技术问题或者至少部分地解决上述技术问题，本公开提供了一种连麦系统、方法、装置、设备及存储介质。

第一方面，本公开提供了一种连麦方法，所述方法应用于第一设备，所述方法包括：

在确定所述第一设备成功连接到连麦服务端后，基于所述第一设备和第二设备之间的RTC网络连接，向所述第二设备发送补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息用于触发所述第二设备向业务服务端发送针对目标连麦活动的开启请求；

当接收所述业务服务端发送的针对所述开启请求的响应消息时，在所述第一设备的用户界面上加载所述目标连麦活动对应的预设控件。

一种可选的实施方式中，所述在确定所述第一设备成功连接到连麦服务端后，基于所述第一设备和第二设备之间的RTC网络连接，向所述第二设备发送补充增强信息SEI消息之前，还包括：

接收连麦服务端发送的连麦接受通知消息；其中，所述连麦接受通知消息用于通知所述第二设备已接受连麦邀请的信息，所述连麦接受通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

第二方面，本公开提供了一种连麦方法，所述方法应用于第二设备，所述方法包括：

接收来自第一设备的补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到连麦服务端的信息，所述SEI消息是基于所述第一设备和所述第二设备之间的RTC网络连接传输的；

向业务服务端发送针对目标连麦活动的开启请求；

当接收所述业务服务端返回的所述开启请求对应的响应消息时，在所述第二设备的用户界面上加载所述目标连麦活动对应的预设控件。

一种可选的实施方式中，所述向业务服务端发送针对目标连麦活动的开启请求之前，还包括：

接收连麦服务端针对连麦接受应答请求返回的响应消息；其中，所述响应消息中携带所述第二设备成功连接到所述连麦服务端的信息。

第三方面，本公开提供了一种连麦方法，所述方法应用于连麦服务端，所述方法包括：

在接收到来自第二设备的针对第一设备的连麦接受应答请求后，分别针对所述第一设备和所述第二设备建立连麦连接关系；

在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送通知信息；其中，所述通知信息包括所述第一设备成功连接到所述连麦服务端的信息，所述通知信息用于触发所述第一设备基于所述第一设备和所述第二设备之间的RTC网络连接向所述第二设备发送SEI消息，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息用于触发所述第二设备向业务服务端针对目标连麦活动发送开启请求，所述开启请求对应的响应消息用于触发在所述第一设备和所述第二设备的用户界面上分别加载所述目标连麦活动对应的预设控件。

一种可选的实施方式中，所述在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送通知信息，包括：

在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送连麦接受通知消息；其中，所述连麦接受通知消息用于通知所述第二设备已接受连麦邀请的信息，所述连麦接受通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

一种可选的实施方式中，所述方法还包括：

在确定所述第二设备成功连接到所述连麦服务端后，向所述第二设备返回所述连麦接受应答请求对应的响应消息；其中，所述响应消息中携带所述第二设备成功连接到所述连麦服务端的信息。

第四方面，本公开提供了一种连麦系统，所述系统包括第一设备和第二设备；

所述第一设备，用于在确定自身成功连接到连麦服务端后，基于所述第一设备和所述第二设备之间的即时通信RTC网络连接，向所述第二设备发送补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息；

所述第二设备，用于在接收到所述SEI消息后，向所述业务服务端发送针对目标连麦活动的开启请求；其中，所述开启请求对应的响应消息用于触发在所述第一设备和所述第二设备的用户界面上分别加载所述目标连麦活动对应的预设控件。

一种可选的实施方式中，所述系统还包括连麦服务端；

所述连麦服务端，还用于在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送连接成功通知消息；其中，所述连接成功通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

一种可选的实施方式中，所述连麦服务端，还用于在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送连麦接受通知消息；其中，所述连麦接受通知消息用于通知所述第二设备已接受连麦邀请的信息，所述连麦接受通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

一种可选的实施方式中，所述连麦服务端，还用于在确定所述第二设备成功连接到所述连麦服务端后，向所述第二设备返回所述连麦接受应答请求对应的响应消息；其中，所述响应消息中携带所述第二设备成功连接到所述连麦服务端的信息。

一种可选的实施方式中，所述第二设备，具体用于在接收到所述SEI消息且确定自身成功连接到所述连麦服务端后，向所述业务服务端发送针对目标连麦活动的开启请求。

第五方面，本公开提供了一种连麦装置，所述装置包括：

第一发送模块，用于在确定第一设备成功连接到连麦服务端后，基于所述第一设备和第二设备之间的RTC网络连接，向所述第二设备发送补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息用于触发所述第二设备向业务服务端发送针对目标连麦活动的开启请求；

第一加载模块，用于在接收所述业务服务端发送的针对所述开启请求的响应消息时，在所述第一设备的用户界面上加载所述目标连麦活动对应的预设控件。

第六方面，本公开提供了一种连麦装置，所述装置包括：

第一接收模块，用于接收来自所述第一设备的补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息是基于所述第一设备和所述第二设备之间的RTC网络连接传输的；

第二发送模块，用于向业务服务端发送针对目标连麦活动的开启请求；

第二加载模块，用于当接收所述业务服务端返回的所述开启请求对应的响应消息时，在所述第二设备的用户界面上加载所述目标连麦活动对应的预设控件。

第七方面，本公开提供了一种连麦装置，所述装置包括：

第三发送模块，用于在接收到来自第二设备的针对第一设备的连麦接受应答请求后，分别针对所述第一设备和所述第二设备建立连麦连接关系；

第一确定模块，用于在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送通知信息；其中，所述通知信息包括所述第一设备成功连接到所述连麦服务端的信息，所述通知信息用于触发所述第一设备基于所述第一设备和所述第二设备之间的RTC网络连接向所述第二设备发送SEI消息，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息用于触发所述第二设备向业务服务端针对目标连麦活动发送开启请求，所述开启请求对应的响应消息用于触发在所述第一设备和所述第二设备的用户界面上分别加载所述目标连麦活动对应的预设控件。

第八方面，本公开提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有指令，当所述指令在计算机设备上运行时，使得所述计算机设备实现上述的方法。

第九方面，本公开提供了一种设备，包括：存储器，处理器，及存储在所述存储器上的计算机程序，所述处理器执行所述计算机程序时，实现上述的方法。

第十方面，本公开提供了一种计算机程序产品，所述计算机程序产品包括计算机程序/指令，所述计算机程序/指令被处理器执行时实现上述的方法。

本公开实施例提供的技术方案与现有技术相比至少具有如下优点：

本公开实施例提供了一种连麦方法，第一设备在确定自身成功连接到连麦服务端后，基于第一设备和第二设备之间的RTC网络连接，向第二设备发送SEI消息；其中，SEI消息中携带第一设备成功连接到连麦服务端的信息。第二设备在接收到SEI消息后，向业务服务端发送针对目标连麦活动的开启请求；其中，开启请求对应的响应消息用于触发在用户界面上加载目标连麦活动对应的预设控件。可见，本公开实施例中，第二设备只需收到第一设备发送的携带第一设备成功连接到连麦服务端的信息的SEI消息，就可以向业务服务端发送目标连麦活动的开启请求，使第二设备提前了开启请求的时机，降低了在用户界面上加载连麦活动对应的预设控件的耗时。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

为了更清楚地说明本公开实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，对于本领域普通技术人员而言，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为一种网络直播的连麦方式中的数据交互示意图；

图2为本公开实施例提供的一种连麦系统中的信令交互图；

图3为本公开实施例提供的一种连麦界面示意图；

图4为本公开实施例提供的另一种连麦系统中的信令交互图；

图5为本公开实施例提供的一种连麦方法流程图；

图6为本公开实施例提供的另一种连麦方法流程图；

图7为本公开实施例提供的又一种连麦方法流程图；

图8为本公开实施例提供的一种连麦装置的结构示意图；

图9为本公开实施例提供的另一种连麦装置的结构示意图；

图10为本公开实施例提供的又一种连麦装置的结构示意图；

图11为本公开实施例提供的一种连麦设备的结构示意图。

具体实施方式

为了能够更清楚地理解本公开的上述目的、特征和优点，下面将对本公开的方案进行进一步描述。需要说明的是，在不冲突的情况下，本公开的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本公开，但本公开还可以采用其他不同于在此描述的方式来实施；显然，说明书中的实施例只是本公开的一部分实施例，而不是全部的实施例。

随着直播技术的不断发展，连麦活动已经成为一种深受用户喜爱的娱乐方式，其中，连麦活动是连麦邀请端和连麦被邀端以类似音视频电话的方式，实现实时通信互动，并在双方的用户界面(User Interface，UI)上显示加载某个活动对应的控件的互动玩法。其中，连麦邀请端可以是连麦活动中主动发起连麦活动邀请的用户所在客户端，连麦被邀端可以是连麦活动中被邀请进行连麦活动的用户所在客户端。具体的，连麦邀请端和连麦被邀端通过实时音视频通话进行各种各样的连麦活动，例如连麦PK活动。实际应用中，主播之间可通过实时音视频通话进行连麦PK活动，其中，连麦PK活动是显示两个主播营收情况的互动玩法。

目前，连麦活动中包括音视频建联和业务建联，通过音视频建联实现连麦邀请端和连麦被邀端的连麦，在连麦邀请端和连麦被邀端的连麦基础上可进一步实现业务建联。以两个主播之间进行的连麦活动为例，如图1所示，为一种网络直播的连麦活动的数据交互示意图。连麦邀请端(主播A)通过连麦服务端向连麦被邀端(主播B)发送连麦活动请求(invite消息)，主播B在接收到来自连麦服务端的连麦活动请求(invite消息)之后，针对连麦活动请求触发连麦活动接受操作，主播B向RTC(即时通信，Real-Time Communication)服务端推送音视频流；在主播B开启合流后，可从RTC服务端拉取到主播A的首帧，音视频建联完成。

实际应用中，在上述音视频建联过程中，针对主播A，通过连麦服务端向主播B发送连麦邀请请求(invite消息)，并在接收到连麦服务端返回连麦邀请请求对应的响应消息时，开始向RTC服务端发送加入连麦房间请求(rtc_join_channel消息)，以请求加入连麦虚拟房间，主播A可通过连麦虚拟房间的房间号等信息进入RTC服务端对应的连麦虚拟房间。针对主播B，主播B在接收到来自连麦服务端的连麦邀请请求(invite消息)之后，开始向RTC服务端发送加入连麦房间请求(rtc_join_channel消息)，以请求加入连麦虚拟房间，主播B也可通过连麦虚拟房间的房间号等信息进入RTC服务端对应的连麦虚拟房间，这样主播A和主播B之间就建立RTC网络连接。

在业务建联过程，主播A和主播B分别通过网络请求的方式向连麦服务端发送连接请求(业务join_channel消息)，该连接请求用于使连主播A和主播B分别与连麦服务端建立连接；连麦服务端还向主播B返回reply响应消息，该reply响应消息中携带主播B已经与连麦服务端成功建立连接的信息；且连麦服务端还需要向主播B发送确认消息(enter消息)，该确认消息中携带主播A已经与连麦服务端成功建立连接的信息。只有主播B接收到enter消息后，主播B才能向业务服务端发送针对连麦活动的开启请求，进一步的，业务服务端可分别向主播A和主播B发送加载连麦活动对应的预设控件的响应消息，这样才能实现主播A和主播B的用户界面上显示的连麦活动对应的预设控件的加载。其中，连麦活动的开启请求用于请求加入连麦活动的业务服务端，如连麦PK活动的业务服务端。

在上述主播A和主播B实现连麦活动的过程中，主播B在点击接受连麦活动邀请之后，不仅触发主播B向连麦服务端发送业务join_channel消息，使主播B通过网络请求的方式与连麦服务端建立连接；还要触发主播A向连麦服务端发送业务join_channel消息，使主播A通过网络请求的方式与连麦服务端建立连接；只有主播A与连麦服务端成功建立连接后，连麦服务端才向主播B发送触发主播B向业务服务端发送针对连麦活动的开启请求的enter消息；可见，主播B在点击接受连麦邀请之后，在用户界面上加载连麦活动对应的预设控件耗时较长，影响主播A和主播B对连麦活动体验。

为此，本公开实施例提供了一种连麦系统，参考图2，为本公开实施例提供的一种连麦系统中的信令交互图，其中，第一设备和第二设备的音视频建联过程参考上文描述的内容，其中，第一设备可以对应于连麦邀请端，也可以对应于连麦被邀端，第二设备与第一设备具有对应关系，以下假设第一设备对应于连麦邀请端，例如，主播A，第二设备对应于连麦被邀端，例如，主播B。第一设备和第二设备在业务建联过程，第一设备在确定自身成功连接到连麦服务端后，基于第一设备和第二设备之间的RTC网络连接，第一设备向第二设备发送SEI消息，其中，SEI消息携带第一设备成功连接到连麦服务端的信息；第二设备在收到SEI消息后，就可以向业务服务端发送目标连麦活动的开启请求，业务服务端可分别向第一设备和第二设备发送加载连麦活动对应的预设控件的响应消息，进一步的，实现第一设备和第二设备的用户界面上连麦活动对应的预设控件的加载。

可见，本公开实施例中，第二设备只需收到第一设备发送的携带第一设备成功连接到连麦服务端的信息的SEI消息，该SEI消息就可以触发第二设备向业务服务端发送目标连麦活动的开启请求，使第二设备提前了开启请求的时机，降低了在用户界面上加载连麦活动对应的预设控件的耗时，也就是说，在第二设备的用户在接受连麦邀请后，减少等待在用户界面上加载连麦活动对应的预设控件的时间，提升用户的连麦体验。

基于此，本公开实施例提供了一种连麦系统，该连麦系统包括第一设备和第二设备；

所述第一设备，用于在确定自身成功连接到连麦服务端后，基于所述第一设备和所述第二设备之间的即时通信RTC网络连接，向所述第二设备发送补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息；

所述第二设备，用于在接收到所述SEI消息后，向所述业务服务端发送针对目标连麦活动的开启请求；其中，所述开启请求对应的响应消息用于触发在所述第一设备和所述第二设备的用户界面上分别加载所述目标连麦活动对应的预设控件。

本公开实施例中，第一设备可以对应于连麦邀请端，也可以对应于连麦被邀端，第二设备与第一设备具有对应关系，假设第一设备对应于连麦邀请端，则第二设备对应于连麦被邀端，假设第一设备对应于连麦被邀端，则第二设备对应于连麦邀请端。以下假设第一设备对应于连麦邀请端，第一设备通过连麦服务端向第二设备发送连麦活动请求后，第一设备和第二设备分别向RTC(即时通信)服务端发送加入连麦房间请求(rtc_join_channel消息)，以请求加入连麦虚拟房间，双方通过连麦虚拟房间的房间号等信息进入RTC服务端的连麦虚拟房间，这样第一设备和第二设备之间就建立了RTC网络连接。基于第一设备和第二设备之间建立的RTC网络连接，第一设备通过将视频码流传输至第二设备，实现视频画面的直播，具体的，第一设备对应的视频帧以视频码流的形式传输。

本公开实施例中，SEI(Supplemental enhancement information，补充增强信息)属于码流范畴，它提供了向视频码流中加入额外信息的方法，SEI可以对视频码流进行补充。本公开实施例中，SEI消息中携带第一设备成功连接到连麦服务端的信息；其中，SEI消息与视频码流一起传递，各个视频帧都有对应的SEI消息。

一种可选的实施方式中，第一设备确定自身成功连接到连麦服务端后，基于第一设备和第二设备之间的RTC网络连接，向第二设备发送第一设备成功连接到连麦服务端的SEI消息；第一设备通过将视频码流传输至第二设备的过程中，该SEI消息可随着视频码流一起传递，具体的，该SEI消息可携带在预设的视频帧中。

本公开实施例中，第二设备在接收到SEI消息后，向业务服务端发送针对目标连麦活动的开启请求；该开启请求用于请求开启目标连麦活动的请求。具体的，第二设备在接收到通过视频码流传递的SEI消息后，可确定第一设备成功连接到连麦服务端，此时，该SEI消息可以用于触发第二设备向业务服务端发送开启目标连麦活动的请求，业务服务端针对该开启请求向第二设备发送对应的响应消息，该响应消息用于触发在第二设备的用户界面上加载目标连麦活动对应的预设控件。

其中，连麦活动是第一设备和第二设备以类似音视频电话的方式，实现实时通信互动，并在双方的用户界面(User Interface，UI)上显示加载某个活动对应的控件的互动玩法。目标连麦活动是第一设备与第二设备针对特定的连麦活动进行的互动玩法。例如主播之间通过实时音视频通话进行连麦PK活动，其中，连麦PK活动是显示两个主播营收情况的互动玩法。预设控件是在用户界面上提前预设的显示加载目标连麦活动的功能组件，例如，连麦PK活动中在用户界面上显示血条加载的组件。

如图2所示，针对第一设备，第一设备的用户界面上加载目标连麦活动对应的预设控件的时长是第一设备开启合流的时间至第一设备收到加载目标连麦活动对应的预设控件的响应消息的时间之间对应的时长；其中，第一设备开启合流的时间对应于第一设备接收连麦活动接受响应消息的时间。针对第二设备，第二设备的用户界面上加载目标连麦活动对应的预设控件的时长是第二设备开启合流的时间至第二设备收到加载目标连麦活动对应的预设控件的响应消息的时间之间对应的时长；其中，第二设备开启合流的时间对应于第二设备接收连麦接受消息的时间。

本公开实施例中，第二设备在点击接受连麦活动邀请之后，不需要触发第二设备向连麦服务端发送业务join_channel消息，使第二设备通过网络请求的方式与连麦服务端建立连接；也不需要触发第一设备向连麦服务端发送业务join_channel消息，使第一设备通过网络请求的方式与连麦服务端建立连接；更不需要触发连麦服务端向第二设备发送enter消息。

可见，本公开实施例中，第二设备只需收到第一设备发送的携带第一设备成功连接到连麦服务端的信息的SEI消息，就可以向业务服务端发送目标连麦活动的开启请求，使第二设备提前了开启请求的时机，降低了在用户界面上加载连麦活动对应的预设控件的耗时，也就是说，在第二设备的用户在接受连麦邀请后，减少第一设备的用户和第二设备的用户分别等待在用户界面上加载连麦活动对应的预设控件的时间，提升用户的连麦体验。

为了便于对第一设备和第二设备进行的连麦活动进行了解，以下通过主播A和主播B建立的目标连麦活动是连麦PK活动为例做进一步的说明。如图2所示，假设主播A通过连麦服务端向主播B发送连麦PK活动请求后，主播A与主播B之间建立RTC网络连接；主播A确定自身成功连接到连麦服务端后，可基于主播A与主播B之间建立RTC网络连接,向主播B发送主播A成功连接到连麦服务端的SEI消息。主播B在接收到该SEI消息后，主播B就可以向业务服务端发送开启连麦PK活动的请求，业务服务端针对该开启请求向主播B发送对应的响应消息，该响应消息用于触发在用户界面上加载连麦PK活动对应的血条。

如图2所示，对于主播A而言，主播A的用户界面上加载连麦PK活动对应的血条的时长，是指主播A开启合流的时间(即如下图3所示的连麦界面开始显示的时间)至主播A收到加载连麦PK活动对应的血条的响应消息的时间(即连麦界面上显示血条的时间)之间的时长；其中，主播A开启合流的时间，对应于主播A接收连麦PK活动接受响应消息的时间。对于主播B而言，主播B的用户界面上加载连麦PK活动对应的血条的时长，是指主播B开启合流的时间(即点击接受连麦PK活动控件的时间)至主播B收到加载连麦PK活动对应的血条的响应消息的时间(即连麦界面上显示血条的时间)之间对应的时长；其中，主播B开启合流的时间对应于主播B接收连麦PK活动接受消息的时间。

其中，图3为本公开实施例提供的一种连麦界面示意图，如图3所示，主播A和主播B进行连麦PK活动，业务服务端针对开启请求向主播A和主播B发送对应的响应消息，主播A和主播B的用户界面上会显示血条加载情况，此时两个主播的用户界面上均开始加载血条。实际应用中，该用户界面上还可以显示主播的直播状态、主播的用户名(例如C)、观众的发表评论等(例如主播好漂亮等)。

可见，本公开实施例中，在上述主播A和主播B实现连麦活动的过程中，主播B在点击接受连麦活动邀请之后，不需要触发主播B向连麦服务端发送业务join_channel消息，使主播B通过网络请求的方式与连麦服务端建立连接；也不需要触发主播A向连麦服务端发送业务join_channel消息，使主播A通过网络请求的方式与连麦服务端建立连接；更不需要触发连麦服务端向主播B发送enter消息。本公开实施例中，主播B收到主播A发送的SEI消息，就可以向业务服务端发送连麦PK活动的开启请求，业务服务端可向主播A和主播B发送加载连麦PK活动对应的血条的响应消息，进一步的，实现主播A和主播B的用户界面上的血条加载。这样极大的减少了主播A和主播B等待在用户界面上加载血条的时间，提升用户的连麦体验。

目前，由于主播A和主播B分别需要通过网络请求的方式向连麦服务端发送连接请求(业务join_channel消息)，使连主播A和主播B分别与连麦服务端建立连接。这样的方式中，通过网络请求的方式去处理业务join_channel，会增加主播A和主播B的目标连麦活动对应的预设控件的加载耗时，影响用户对目标连麦活动的体验。

为此，本公开实施例提供的连麦系统需要针对上述内容进行功能优化，本公开实施例还提供了另一种连麦系统，该连麦系统中包括连麦服务端、第一设备和第二设备。连麦服务端在接收到来自所述第二设备的连麦接受应答请求后，分别针对第一设备和第二设备建立连麦连接关系。具体的，主播B触发连麦接收操作后，连麦服务端接收主播B发送的连麦接受消息(reply请求)，其中，该连麦接受消息用于表明主播B已接受连麦活动的邀请；连麦服务端直接分别处理主播A与连麦服务端建立连接的业务join_channel和主播B与连麦服务端建立连接的业务join_channel，这样的方式中，不需要主播A和主播B分别通过网络请求的方式向连麦服务端发送业务join_channel，减少了主播A和主播B分别与连麦服务端建立连接的耗时，相应的，也使主播A和主播B的用户界面上显示的连麦活动对应的预设控件的加载耗时减少，提升用户对连麦活动的体验。

实际应用中，假设主播A因为网络因素等导致的没有收到主播A与连麦服务端连接成功通知消息，主播B就向业务服务端发送目标连麦活动的开启请求，此时，主播A的用户界面上是无法显示加载预设控件的状态，这样会影响主播A对目标连麦活动体验。

为此，本公开提供了一种可选的实施方式，连麦服务端还用于在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送连接成功通知消息；其中，所述连接成功通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。参考图4，为本公开实施例提供的另一种连麦系统中的信令交互图。在主播A与连麦服务端成功建立连接后，连麦服务端向主播A发送的连接成功通知消息，该连接成功通知消息中携带主播A与连麦服务端成功建立连接的信息，其中，该接成功通知消息用于使主播A知道自身已经成功与连麦服务端建立连接，避免主播A的用户界面上加载预设控件的显示状态出现错乱的问题。假设主播B向业务服务端发送目标连麦活动的开启请求，由于主播A已经成功与连麦服务端建立连接，在业务服务端向主播B发送开启请求对应的响应消息时，主播A的用户界面上会显示加载预设控件的状态，提高了主播A的连麦活动体验。

另一种可选的实施方式中，连麦服务端还用于在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送连麦接受通知消息；其中，所述连麦接受通知消息用于将所述第二设备已接受连麦邀请的信息通知至第一设备，所述连麦接受通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。参考图4，在主播A与连麦服务端建立连接后，连麦服务端向主播A发送连麦接受通知消息，该连麦接受通知消息用于向主播A通知主播B已接受目标连麦活动邀请，且该连麦接受通知消息中携带主播A成功连接到连麦服务端的信息，其用于通知主播A已经成功与连麦服务端建立连接。这样可使主播B向业务服务端发送目标连麦活动的开启请求，业务服务端向主播B发送开启请求对应的响应消息时，主播A的用户界面上会显示加载预设控件的状态，提高了主播A的连麦活动体验。

实际应用中，连麦服务端还用于在确定所述第二设备成功连接到所述连麦服务端后，向所述第二设备返回所述连麦接受应答请求对应的响应消息；其中，所述响应消息中携带所述第二设备成功连接到所述连麦服务端的信息。参考图4，连麦服务端接收到主播B发送的主播B已接受连麦活动邀请的消息后，连麦服务端直接处理主播B与连麦服务端建立连接的业务join_channel，在主播B与连麦服务端建立连接后，向主播B返回主播B已经成功与连麦服务端建立连接的响应消息(reply响应)，以使主播B知道自身已经成功与连麦服务端建立连接。这样可使业务服务端向主播B发送开启请求对应的响应消息时，主播B的用户界面上会显示加载预设控件的状态，提高了主播B的连麦活动体验。

一种可选的实施方式中，第二设备在接收到SEI消息且确定自身成功连接到连麦服务端后，向业务服务端发送针对目标连麦活动的开启请求。参考图4，主播B在接收到主播A成功连接到连麦服务端的SEI消息后，且确定主播B已经与连麦服务端成功建立连接后，主播B向业务服务端发送开启目标连麦活动的请求，业务服务端针对该开启请求向主播B发送用于触发在用户界面上加载目标连麦活动对应的预设控件的响应消息。

具体的，主播B在接收到SEI消息后，且接收到连麦服务端向主播B返回reply响应消息后，主播B向业务服务端发送开启目标连麦活动的请求；其中，该reply响应消息中包括主播B已经与连麦服务端成功建立连接的消息。这样使主播B知道主播A和主播B均已经成功与连麦服务端建立连接后，主播B才向业务服务端发送连麦活动的开启请求时，保证了业务服务端向主播B发送开启请求对应的响应消息时，主播A和主播B的用户界面上会显示加载预设控件的状态，提高了主播A和主播B的连麦活动体验。

基于上述实施例中的连麦系统，本公开提供了一种连麦方法，应用于第一设备，其中，第一设备可以对应于连麦邀请端，也可以对应于连麦被邀端，以下假设第一设备对应于连麦邀请端，参考图5，为本公开实施例提供的一种连麦方法流程图，所述方法包括：

S501：第一设备在确定所述第一设备成功连接到连麦服务端后，基于所述第一设备和第二设备之间的RTC网络连接，向所述第二设备发送补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息用于触发所述第二设备向业务服务端发送针对目标连麦活动的开启请求；

本公开实施例中，第一设备通过连麦服务端向第二设备发送连麦活动请求后，第一设备和第二设备之间建立RTC网络连接。第一设备确定自身成功连接到连麦服务端后，基于第一设备和第二设备之间的RTC网络连接，向第二设备发送第一设备成功连接到连麦服务端的SEI消息；在第一设备通过将视频码流传输至第二设备的过程中，该SEI消息可随着视频码流一起传递，具体的，该SEI消息可携带在预设的视频帧中。实际应用中，该SEI消息可以用于触发第二设备向业务服务端发送开启目标连麦活动的请求。

S502：第一设备在接收所述业务服务端发送的针对所述开启请求的响应消息时，在所述第一设备的用户界面上加载所述目标连麦活动对应的预设控件。

本公开实施例中，业务服务端针对开启请求向第一设备发送对应的响应消息，该响应消息用于触发在第一设备的用户界面上加载目标连麦活动对应的预设控件。针对第一设备，第一设备的用户界面上加载目标连麦活动对应的预设控件的时长是第一设备开启合流的时间至第一设备收到加载目标连麦活动对应的预设控件的响应消息的时间之间对应的时长；其中，第一设备开启合流的时间对应于第一设备接收连麦活动接受响应消息的时间。

本公开实施例中，第一设备不需要向连麦服务端发送业务join_channel消息，使第一设备通过网络请求的方式与连麦服务端建立连接；第一设备只需向第二设备发送的携带第一设备成功连接到连麦服务端的信息的SEI消息，该SEI消息就可以触发第二设备向业务服务端发送开启目标连麦活动的请求。这样不仅提前了开启请求的时机，降低了在第一设备的用户界面上加载目标连麦活动对应的预设控件的耗时，也就是说，减少第一设备的用户等待在用户界面上加载目标连麦活动对应的预设控件的时间，提升第一设备对应的用户的连麦体验。

为了便于对第一设备进行的目标连麦活动进行了解，基于上述主播A和主播B建立目标连麦活动为连麦PK活动为例做进一步的说明。如图2所示，主播A收到连麦服务端发送的携带主播A成功连接到连麦服务端的reply消息后，开启合流，并基于主播A与主播B之间建立RTC网络连接,向主播B发送主播A成功连接到连麦服务端的SEI消息，该SEI消息用于触发开启连麦PK活动的请求；业务服务端针对该开启请求向主播A发送对应的响应消息，该响应消息用于触发在主播A的用户界面上加载连麦PK活动对应的血条。如图2所示，主播A的用户界面上加载连麦PK活动对应的血条的时长是主播A开启合流的时间至主播A收到加载连麦PK活动对应的血条的响应消息的时间之间对应的时长。

可见，本公开实施例中，在主播A开启合流后，由于不需要触发主播A向连麦服务端发送业务join_channel消息，使主播A通过网络请求的方式与连麦服务端建立连接；只需主播A向主播B发送主播A成功连接到连麦服务端的SEI消息后，就可以触发开启连麦PK活动的请求，即提前了开启请求的时机，这样极大的减少了主播A等待在用户界面上加载血条的时间，提升主播A的连麦体验。

实际应用中，假设主播A因为网络因素等导致的没有收到主播A与连麦服务端连接成功通知消息，主播B就向业务服务端发送目标连麦活动的开启请求，此时，主播A的用户界面上是无法显示加载预设控件的状态，这样会影响主播A对目标连麦活动体验。

为此，本公开提供了一种可选的实施方式，在确定所述第一设备成功连接到连麦服务端后，基于所述第一设备和第二设备之间的RTC网络连接，向所述第二设备发送补充增强信息SEI消息之前第一设备接收连麦服务端发送的连接成功通知消息；其中，所述连接成功通知消息中携带所述第一设备成功连接到连麦服务端的信息。

参考上述图4，在主播A与连麦服务端成功建立连接后，主播A接收连麦服务端向主播A发送的连接成功通知消息，该连接成功通知消息中携带主播A与连麦服务端成功建立连接的信息，其中，该接成功通知消息用于使主播A知道自身已经成功与连麦服务端建立连接，避免主播A的用户界面上加载预设控件的显示状态出现错乱的问题。此时，假设主播B向业务服务端发送目标连麦活动的开启请求，由于主播A已经成功与连麦服务端建立连接，在业务服务端向主播A发送开启请求对应的响应消息时，主播A的用户界面上会显示加载预设控件的状态，提高了主播A的连麦活动体验。

另一种可选的实施方式中，所述在确定所述第一设备成功连接到连麦服务端后，基于所述第一设备和第二设备之间的RTC网络连接，向所述第二设备发送补充增强信息SEI消息之前，还包括：第一设备接收连麦服务端发送的连麦接受通知消息；其中，所述连麦接受通知消息用于通知所述第二设备已接受连麦邀请的信息，所述连麦接受通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

参考上述图4，在主播A与连麦服务端建立连接后，主播A接收连麦服务端向主播A发送连麦接受通知消息，该连麦接受通知消息用于向主播A通知主播B已接受目标连麦活动邀请，且该连麦接受通知消息中携带主播A成功连接到连麦服务端的信息，其用于通知主播A已经成功与连麦服务端建立连接。这样可使主播B向业务服务端发送目标连麦活动的开启请求，业务服务端向主播B发送开启请求对应的响应消息时，主播A的用户界面上会显示加载预设控件的状态，提高了主播A的连麦活动体验。

基于上述系统实施例，本公开还提供了一种连麦方法，应用于第二设备，其中，第二设备可以对应于连麦邀请端，也可以对应于连麦被邀端，第二设备与第一设备具有对应关系，假设第一设备对应于连麦邀请端，则第二设备对应于连麦被邀端，假设第一设备对应于连麦被邀端，则第二设备对应于连麦邀请端。参考图6，为本公开实施例提供的又一种连麦方法流程图，所述方法包括：

S601：第二设备接收来自所述第一设备的补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到连麦服务端的信息，所述SEI消息是基于所述第一设备和所述第二设备之间的RTC网络连接传输的。

本公开实施例中，第一设备在通过连麦服务端向第二设备发送连麦活动请求后，第一设备和第二设备之间建立RTC网络连接。基于第一设备和第二设备之间的RTC网络连接，第二设备接收携带第一设备成功连接到连麦服务端的信息的SEI消息；在第一设备通过将视频码流传输至第二设备的过程中，该SEI消息可随着视频码流一起传递，具体的，该SEI消息可携带在预设的视频帧中。

S602：第二设备向所述业务服务端发送针对目标连麦活动的开启请求。

实际应用中，上述SEI消息可以用于触发第二设备向业务服务端发送开启目标连麦活动的请求。

S603：当第二设备接收所述业务服务端返回的所述开启请求对应的响应消息时，在所述第二设备的用户界面上加载所述目标连麦活动对应的预设控件。

本公开实施例中，业务服务端针对开启请求向第二设备发送对应的响应消息，该响应消息用于触发在第二设备的用户界面上加载目标连麦活动对应的预设控件。其中，第二设备的用户界面上加载目标连麦活动对应的预设控件的时长是第二设备开启合流的时间至第二设备收到加载目标连麦活动对应的预设控件的响应消息的时间之间对应的时长；其中，第二设备开启合流的时间对应于第二设备接收连麦接受消息的时间。

本公开实施例中，第二设备不需要向连麦服务端发送业务join_channel消息，使第二设备通过网络请求的方式与连麦服务端建立连接；第二设备只需接收携带第一设备成功连接到连麦服务端的信息的SEI消息，就可以触发第二设备向业务服务端发送开启目标连麦活动的请求。这样不仅提前了开启请求的时机，降低了在第二设备的用户界面上加载目标连麦活动对应的预设控件的耗时，也就是说，减少第二设备的用户等待在用户界面上加载目标连麦活动对应的预设控件的时间，提升第二设备对应的用户的连麦体验。

为了便于对第二设备进行的目标连麦活动进行了解，基于上述主播A和主播B建立目标连麦活动为连麦PK活动为例做进一步的说明。如图2所示，主播A触发接收连麦接收操作后，开启合流；基于主播A与主播B之间建立RTC网络连接,主播B接收主播A发送的主播A成功连接到连麦服务端的SEI消息，该SEI消息用于触发主播B开启连麦PK活动的请求；业务服务端针对该开启请求向主播B发送对应的响应消息，该响应消息用于触发在主播B的用户界面上加载连麦PK活动对应的血条。如图2所示，主播B的用户界面上加载连麦PK活动对应的血条的时长是主播B开启合流的时间至主播B收到加载连麦PK活动对应的血条的响应消息的时间之间对应的时长。

可见，本公开实施例中，在主播B开启合流后，由于不需要触发主播B向连麦服务端发送业务join_channel消息，使主播B通过网络请求的方式与连麦服务端建立连接；只需主播B接收主播A向主播B发送的携带主播A成功连接到连麦服务端的信息的SEI消息后，就可以触发主播B开启连麦PK活动的请求，即提前了主播B开启连麦PK请求的时机，这样极大的减少了主播B等待在用户界面上加载血条的时间，提升主播B的连麦体验。

一种可选的实施方式中，所述向所述业务服务端发送针对目标连麦活动的开启请求之前，第二设备接收连麦服务端针对连麦接受应答请求返回的响应消息；其中，所述响应消息中携带所述第二设备成功连接到所述业务服务端的信息。

参考上述图4，主播B接受连麦活动请求后，向连麦服务端发送连麦接受消息(reply请求)，连麦服务端直接处理主播B与连麦服务端建立连接的业务join_channel，在主播B与连麦服务端建立连接后，主播B接收连麦服务端返回的主播B已经成功与连麦服务端建立连接的响应消息(reply响应)，使主播B知道自身已经成功与连麦服务端建立连接。这样可使业务服务端向主播B发送开启请求对应的响应消息时，主播B的用户界面上会显示加载预设控件的状态，提高了主播B的连麦活动体验。

目前，由于主播A和主播B分别需要通过网络请求的方式向连麦服务端发送连接请求(业务join_channel消息)，使连主播A和主播B分别与连麦服务端建立连接。这样的方式中，主播A和主播B需要通过网络请求的方式去处理业务join_channel，会增加主播A和主播B的目标连麦活动对应的预设控件的加载耗时，影响用户对目标连麦活动的体验。

为此，本公开还提供了一种连麦方法，应用于连麦服务端，参考图7，为本公开实施例提供的又一种连麦方法流程图，所述方法包括：

S701：连麦服务端在接收到来自第二设备的针对第一设备的连麦接受应答请求后，分别针对所述第一设备和所述第二设备建立连麦连接关系。

具体的，第二设备(主播B)触发连麦接收操作后，连麦服务端接收主播B发送的连麦接受消息(reply请求)，其中，该连麦接受消息用于表明主播B已接受连麦活动的请求；连麦服务端直接分别处理第一设备(主播A)与连麦服务端建立连接的业务join_channel和第二设备(主播B)与连麦服务端建立连接的业务join_channel，这样的方式中，不需要主播A和主播B分别通过网络请求的方式向连麦服务端发送业务join_channel，减少了主播A和主播B分别与连麦服务端建立连接的耗时，相应的，也使主播A和主播B的用户界面上显示的连麦活动对应的预设控件的加载耗时减少，提升用户对连麦活动的体验。

S702：连麦服务端在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送通知信息；其中，所述通知信息包括所述第一设备成功连接到所述连麦服务端的信息，所述通知信息用于触发所述第一设备基于所述第一设备和所述第二设备之间的RTC网络连接向所述第二设备发送SEI消息，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息用于触发所述第二设备向业务服务端针对目标连麦活动发送开启请求，所述开启请求对应的响应消息用于触发在所述第一设备和所述第二设备的用户界面上分别加载所述目标连麦活动对应的预设控件。

本公开实施例中，在主播A与连麦服务端成功建立连接后，连麦服务端向主播A发送通知信息，该通知信息中包括主播A与连麦服务端成功建立连接的信息，其中，该通知信息用于使主播A知道自身已经成功与连麦服务端建立连接，避免主播A的用户界面上加载预设控件的显示状态出现错乱的问题。该通知信息还用于触发主播A基于主播A和主播B之间的RTC网络连接向主播B发送SEI消息，SEI消息中携带主播A成功连接到连麦服务端的信息；其中，主播A通过将视频码流传输至主播B，实现视频画面的直播，SEI消息与视频码流一起传递，各个视频帧都有对应的SEI消息。

实际应用中，主播B在接收到通过视频码流传递的SEI消息后，可确定主播A成功连接到连麦服务端，此时，该SEI消息可以用于触发主播B向业务服务端发送开启目标连麦活动的请求，业务服务端针对该开启请求向主播A和主播B发送对应的响应消息，该响应消息用于触发在主播A和主播B的用户界面上加载目标连麦活动对应的预设控件。

本公开实施例中，连麦服务端直接分别处理第一设备与连麦服务端建立连接的业务join_channel和第二设备与连麦服务端建立连接的业务join_channel，这样的方式中，第二设备在点击接受连麦活动邀请之后，不需要第一设备和第二设备分别通过网络请求的方式向连麦服务端发送业务join_channel，第二设备只需收到第一设备发送的携带第一设备成功连接到连麦服务端的信息的SEI消息，就可以向业务服务端发送目标连麦活动的开启请求，使第二设备提前了开启请求的时机，降低了在用户界面上加载连麦活动对应的预设控件的耗时，也就是说，在第二设备的用户在接受连麦邀请后，减少等待在用户界面上加载连麦活动对应的预设控件的时间，提升用户的连麦体验。

实际应用中，假设主播A因为网络因素等导致的没有收到主播A与连麦服务端连接成功通知消息，主播B就向业务服务端发送目标连麦活动的开启请求，此时，主播A的用户界面上是无法显示加载预设控件的状态，这样会影响主播A对目标连麦活动体验。

为此，本公开提供了一种可选的实施方式，连麦服务端在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送通知信息，包括：在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送连接成功通知消息；其中，所述连接成功通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

参考上述图4，在主播A与连麦服务端成功建立连接后，连麦服务端向主播A发送的通知信息。具体的，连麦服务端向主播A发送连接成功通知消息，其中，该接成功通知消息用于使主播A知道自身已经成功与连麦服务端建立连接，避免主播A的用户界面上加载预设控件的显示状态出现错乱的问题。此时，假设主播B向业务服务端发送目标连麦活动的开启请求，由于主播A已经成功与连麦服务端建立连接，在业务服务端向主播A发送开启请求对应的响应消息时，主播A的用户界面上会显示加载预设控件的状态，提高了主播A的连麦活动体验。

另一种可选的实施方式，在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送通知信息，包括：在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送所述连麦接受通知消息；其中，所述连麦接受通知消息用于通知所述第二设备已接受连麦邀请的信息，所述连麦接受通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

参考上述图4，在主播A与连麦服务端建立连接后，连麦服务端向主播A发送连麦接受通知消息，该连麦接受通知消息用于向主播A通知主播B已接受目标连麦活动邀请，且该连麦接受通知消息中携带主播A成功连接到连麦服务端的信息，其用于通知主播A已经成功与连麦服务端建立连接。这样可使主播B向业务服务端发送目标连麦活动的开启请求，业务服务端向主播A发送开启请求对应的响应消息时，主播A的用户界面上会显示加载预设控件的状态，提高了主播A的连麦活动体验。

一种可选的实施方式，在确定所述第二设备成功连接到所述连麦服务端后，向所述第二设备返回所述连麦接受应答请求对应的响应消息；其中，所述响应消息中携带所述第二设备成功连接到所述连麦服务端的信息。

参考上述图4，连麦服务端接收到主播B发送的主播B已接受连麦活动邀请的消息后，连麦服务端直接处理主播B与连麦服务端建立连接的业务join_channel，在主播B与连麦服务端建立连接后，向主播B返回主播B已经成功与连麦服务端建立连接的响应消息(reply响应)，以使主播B知道自身已经成功与连麦服务端建立连接。这样可使业务服务端向主播B发送开启请求对应的响应消息时，主播B的用户界面上会显示加载预设控件的状态，提高了主播B的连麦活动体验。

与上述系统和方法实施例基于同一个发明构思，本公开还提供了一种连麦装置，参考图8，为本公开实施例提供的一种连麦装置的结构示意图，所述装置应用于第一设备，所述装置包括：

第一发送模块801，用于在确定第一设备成功连接到连麦服务端后，基于所述第一设备和第二设备之间的RTC网络连接，向所述第二设备发送补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息用于触发所述第二设备向业务服务端发送针对目标连麦活动的开启请求；

第一加载模块802，用于在接收所述业务服务端发送的针对所述开启请求的响应消息时，在所述第一设备的用户界面上加载所述目标连麦活动对应的预设控件。

一种可选的实施方式中，所述装置还包括：

第二接收模块，用于接收连麦服务端发送的连麦接受通知消息；其中，所述连麦接受通知消息用于通知所述第二设备已接受连麦邀请的信息，所述连麦接受通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

本公开实施例中，第一设备不需要向连麦服务端发送业务join_channel消息，使第一设备通过网络请求的方式与连麦服务端建立连接；第一设备只需向第二设备发送的携带第一设备成功连接到连麦服务端的信息的SEI消息，该SEI消息就可以触发第二设备向业务服务端发送开启目标连麦活动的请求。这样提前了开启请求的时机，降低了在第一设备的用户界面上加载目标连麦活动对应的预设控件的耗时，也就是说，减少第一设备的用户等待在用户界面上加载目标连麦活动对应的预设控件的时间，提升第一设备对应的用户的连麦体验。

与上述系统和方法实施例基于同一个发明构思，本公开还提供了一种连麦装置，参考图9，为本公开实施例提供的另一种连麦装置的结构示意图，所述装置应用于第二设备，所述装置包括：

第一接收模块901，用于接收来自所述第一设备的补充增强信息SEI消息；其中，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息是基于所述第一设备和所述第二设备之间的RTC网络连接传输的；

第二发送模块902，用于向业务服务端发送针对目标连麦活动的开启请求；

第二加载模块903，用于当接收所述业务服务端返回的所述开启请求对应的响应消息时，在所述第二设备的用户界面上加载所述目标连麦活动对应的预设控件。

一种可选的实施方式中，所述装置还包括：

第三接收模块，用于接收连麦服务端针对连麦接受应答请求返回的响应消息；其中，所述响应消息中携带所述第二设备成功连接到所述连麦服务端的信息。

本公开实施例中，第二设备不需要向连麦服务端发送业务join_channel消息，使第二设备通过网络请求的方式与连麦服务端建立连接；第二设备只需接收携带第一设备成功连接到连麦服务端的信息的SEI消息，就可以触发第二设备向业务服务端发送开启目标连麦活动的请求。这样提前了开启请求的时机，降低了在第二设备的用户界面上加载目标连麦活动对应的预设控件的耗时，也就是说，减少第二设备的用户等待在用户界面上加载目标连麦活动对应的预设控件的时间，提升第二设备对应的用户的连麦体验。

与上述系统和方法实施例基于同一个发明构思，本公开还提供了一种连麦装置，参考图10，为本公开实施例提供的又一种连麦装置的结构示意图，所述装置应用于连麦服务端，所述装置包括：

第三发送模块1001，用于在接收到来自第二设备的针对第一设备的连麦接受应答请求后，分别针对所述第一设备和所述第二设备建立连麦连接关系；

第一确定模块1002，用于在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送通知信息；其中，所述通知信息包括所述第一设备成功连接到所述连麦服务端的信息，所述通知信息用于触发所述第一设备基于所述第一设备和所述第二设备之间的RTC网络连接向所述第二设备发送SEI消息，所述SEI消息中携带所述第一设备成功连接到所述连麦服务端的信息，所述SEI消息用于触发所述第二设备向业务服务端针对目标连麦活动发送开启请求，所述开启请求对应的响应消息用于触发在所述第一设备和所述第二设备的用户界面上分别加载所述目标连麦活动对应的预设控件。

一种可选的实施方式中，所述第一确定模块还包括：

第一发送单元，用于在确定所述第一设备成功连接到所述连麦服务端后，向所述第一设备发送所述连麦接受通知消息；其中，所述连麦接受通知消息用于通知所述第二设备已接受连麦邀请的信息，所述连麦接受通知消息中携带所述第一设备成功连接到所述连麦服务端的信息。

一种可选的实施方式中，所述装置还包括：

返回模块，用于在确定所述第二设备成功连接到所述连麦服务端后，向所述第二设备返回所述连麦接受应答请求对应的响应消息；其中，所述响应消息中携带所述第二设备成功连接到所述连麦服务端的信息。

本公开实施例中，连麦服务端直接分别处理第一设备与连麦服务端建立连接的业务join_channel和第二设备与连麦服务端建立连接的业务join_channel，这样的方式中，不需要第一设备和第二设备分别通过网络请求的方式向连麦服务端发送业务join_channel，减少了第一设备和第二设备分别与连麦服务端建立连接的耗时，相应的，也使第一设备和第二设备的用户界面上显示的连麦活动对应的预设控件的加载耗时减少，提升用户对连麦活动的体验。

除了上述方法和装置以外，本公开实施例还提供了一种计算机可读存储介质，计算机可读存储介质中存储有指令，当所述指令在终端设备上运行时，使得所述终端设备实现本公开实施例所述的连麦方法。

本公开实施例还提供了一种计算机程序产品，包括计算机程序/指令，该计算机程序/指令被处理器执行时实现本公开实施例所述的连麦方法。

另外，本公开实施例还提供了一种连麦设备，参见图11所示，可以包括：

处理器1101、存储器1102、输入装置1103和输出装置1104。连麦设备中的处理器1101的数量可以一个或多个，图11中以一个处理器为例。在本公开的一些实施例中，处理器1101、存储器1102、输入装置1103和输出装置1104可通过总线或其它方式连接，其中，图11中以通过总线连接为例。

存储器1102可用于存储软件程序以及模块，处理器1101通过运行存储在存储器1102的软件程序以及模块，从而执行连麦设备的各种功能应用以及数据处理。存储器1102可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序等。此外，存储器1102可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他易失性固态存储器件。输入装置1103可用于接收输入的数字或字符信息，以及产生与连麦设备的用户设置以及功能控制有关的信号输入。

具体在本实施例中，处理器1101会按照如下的指令，将一个或一个以上的应用程序的进程对应的可执行文件加载到存储器1102中，并由处理器1101来运行存储在存储器1102中的应用程序，从而实现上述连麦设备的各种功能。

需要说明的是，在本文中，诸如“第一”和“第二”等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上所述仅是本公开的具体实施方式，使本领域技术人员能够理解或实现本公开。对这些实施例的多种修改对本领域的技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本公开的精神或范围的情况下，在其它实施例中实现。因此，本公开将不会被限制于本文所述的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。