CN110798457A - 一种基于sip的辅流控制方法和会议系统 - Google Patents

Abstract

本发明公开了一种基于SIP的辅流控制方法和会议系统，属于音视频通信领域。针对现有技术中存在的辅流控制协议复杂、不易分析且需要额外的控制信道和端口的问题，本发明提供了一种基于SIP的辅流控制方法，通话系统包括主叫端和被叫端，主叫端基于SIP协议与被叫端建立连接，系统任一端发送请求至另一端实现辅流共享或取消辅流共享，辅流共享过程中辅流接收端进行抢辅流动作进行辅流发送。它可以实现在通话使用SIP建立的基础上，避免引入过于庞大复杂的协议，完成可靠的辅流控制功能，不需要额外的控制通道，不需要额外的端口监听，不需要为额外的控制通道做NAT网络穿透；减少信道和端口的使用，节省系统资源。

Description

一种基于SIP的辅流控制方法和会议系统

技术领域

本发明涉及音视频通信领域，更具体地说，涉及一种基于SIP的辅流控制方法和会议系统。

背景技术

音视频通信领域，辅流共享已成为常用功能，在通话过程中，主流是音视频通信中的视频信号，辅流是视频会议中共享的信号。通话的双方都可以向对方共享辅流，共享一个屏幕或一个应用界面，但同一时刻只能有一方在共享，如果一方已在共享，另一方可以抢走共享权进行共享。

辅流的特性是同一时刻只有一个通信端可以发送辅流，另一个通信端可以抢占辅流，最终通信端之间的分享状态是一致的，即一个通信端在分享，另一个通信端一定在接收；通话两端没有一端共享时，两端都不会处于接收状态，也不会出现一个通信端在共享，另一通信端不接收的情况。在通信系统中，选取一通信端作为最终端来决定最终的状态，一般情况下，在通话两端中选取被叫端作为决定这个最终端状态的通信端，被叫端称为S端，主叫端称为C端。

业界有基于BFCP(Binary Floor Control Protocol)标准实现辅流控制，即在通话建立过程中，协商出BFCP端口，通话双方通过BFCP标准进行辅流控制，基于BFCP的辅流控制需要额外的端口，这个端口在NAT环境下需要rtpproxy配合打洞。

中国发明专利一种混合视频会议中双流的实现方法、装置和系统，申请号CN201510348773.3，公开日2017年1月11日，公开了一种混合视频会议中双流的实现方法、装置和系统。该方法包括：接收申请双流令牌请求，其中所述申请双流令牌请求是第一终端直接发送的或是第二终端发送后经视频会议系统中心控制设备MCU转发的；所述BFCP服务器根据接收到的申请双流令牌请求，判断与所述申请双流令牌请求对应的双流令牌资源是否被占用；若所述双流令牌资源未被占用，则返回双流令牌授权结果至所述第一终端或所述第二终端。本发明简化了不同协议终端的混合双流操作。该发明使用BFCP协议进行双流操作，控制较为复杂，同时BFCP协议较为复杂，在标准的浏览器上不支持，且BFCP为二进制报文，比较难打印分析问题。

发明内容

1.要解决的技术问题

针对现有技术中存在的辅流控制协议复杂、不易分析且需要额外的控制信道和端口的问题，本发明提供了一种基于SIP的辅流控制方法和会议系统，它可以实现在通话使用SIP建立的基础上，避免引入过于庞大复杂的协议，完成可靠的辅流控制功能，减少信道和端口的使用，节省系统资源。

2.技术方案

本发明的目的通过以下技术方案实现。

一种基于SIP的辅流控制方法，通话系统包括主叫端和被叫端，主叫端或被叫端基于SIP信道发送指令至另一端实现辅流共享或取消辅流共享，辅流共享状态下辅流接收端进行抢辅流动作发送辅流。因为辅流的特性，同一时间只能有一端发送辅流，另一端接收，所以在通话时，如果一端进行抢辅流动作进行辅流发送，通话另一端必然要进行辅流接收，本发明的辅流控制不受通信端主叫或被叫限制，只要保证同一时刻只有一端发送辅流，任何一端均可以实现辅流发送。

更进一步的，系统请求辅流共享通话系统主叫端或被叫端发送指令请求共享，指令内容包括指令序列和共享状态，接收端接收到指令后根据指令序列值的优先级选择执行或丢弃，执行后回复指令序列和状态；系统取消辅流共享时辅流发送端发送指令结束共享，指令内容包括指令序列和请求状态，辅流接收端收到指令后回复确认。

更进一步的，辅流共享状态下辅流接收端进行抢辅流动作发送辅流，辅流接收端发送指令请求抢辅流，指令内容包括指令序列和请求状态，辅流发送端接收到指令确认后转为接收辅流，原辅流接收端发送辅流。

更进一步的，辅流发送端在共享状态下关闭分享或者由辅流接收端进行抢辅流动作。因为辅流的特性，通话两端不存在同时分享的情况，所以在辅流发送端共享状态下，辅流发送端可以自己结束共享，或者由辅流接收端操作抢辅流；辅流的关闭由辅流发送端发起指令。

更进一步的，主叫端指令中请求方法包括请求共享、释放共享或共享状态，本发明定义协议报文share-request为请求共享，表示C端向S端请求开启共享；share-release为释放共享，表示C端向S端请求释放共享；share-status为共享状态，表示S端主动向C端推状态，share-status一般是S端上层的行为触发的，如果是C端触发的，使用相应直接携带状态，不需要S端主动推。

更进一步的，被叫端状态码包括主叫端共享、被叫端共享和当前无共享，本发明定义协议报文被叫端状态码为c、s或n，c代表c_share即主叫端C端在分享；s代表s_share即被叫端S端在分享，n代表no_share即当前没有分享状态。

更进一步的，指令序列的值为自然数，指令序列值根据指令的不同变化，指令序列值确定指令优先级。一般来说，指令序列值为32位整数；指令序列用来处理网络波动导致的命令乱序，指令的优先级根据指令序列值确定，如可以定义指令序列值大的指令优先级高于指令序列值小的指令，例如被叫端在先接收第一条指令的指令序列值为2，当前收到指令的指令序列值为3，因为3大于2，即执行当前收到的指令内容，如当前收到指令的指令序列为1，因为1小于2，即丢弃当前收到指令。

更进一步的，系统协议为JSON或XML形式。JSON明文可读，是一种数据结构化的表示；通信时也可以用XML等格式表示，在表达相同的数据时，XML所使用的报文大小比JSON稍大些，JSON更轻量化。

更进一步的，辅流共享时被叫端有多个。本发明复用SIP信道进行辅流控制，在通话时被叫端数量可以有多个，系统是多方通话时辅流的逻辑不变，通话系统中同一时间只有一个端口发送辅流，有端口发送辅流必然有端口在接收辅流，发送结束同时接收也结束。

一种会议系统，使用所述的一种基于SIP的辅流控制方法，所述会议系统有多个终端，任一终端开始辅流共享时，其余终端自动为接收状态。在会议系统中使用本发明基于SIP的辅流控制方法，会议层逻辑联动，一个终端在进行辅流发送，其他终端自动变为辅流接收状态，同一时间只有一个终端进行辅流发送，辅流接收端进行抢辅流动作进行辅流发送，辅流被抢后原辅流发送端变为辅流接收端。

本发明基于辅流控制业务需要，在辅流发送和接收上复用了SIP信道，自定义一种能够达到辅流控制状态最终一致的机制，不需要建立额外的控制信道，不需要引入额外的复杂的BFCP协议，控制时采用明文传输，明文指令更简洁、直观，便于在出现错误时的排查和分析，支持SIP协商的端都可以快速的支持该协议。减少了系统的信道和端口，节省了系统资源的使用。

3.有益效果

相比于现有技术，本发明的优点在于：

本发明基于SIP信道，复用了现有需要使用的SIP信道，不需要额外的控制通道，不需要额外的端口监听，不需要为额外的控制通道做NAT网络穿透；与现有技术基于BFCP协议的辅流控制方法相比，BFCP协议需要建立基于BFCP协议的控制通道，BFCP方案通信双方在通道的建立过程中，需要协商BFCP端口。通信过程中使用通道的减少降低了系统资源的使用，包括系统的通道资源和端口资源，提高了系统的运行速度，增加了系统的灵活性，例如在一个会议系统中，一共有65536个端口，端口数是固定的，节省的端口可以用于其他软件实现更多的功能。本发明采用明文传输，支持SIP协商的端都可以快速支持该协议。

本发明基于SIP的辅流控制方法能保证最终状态的一致性，因为通话双方的辅流状态是有限的几种组合，一端分享，另一端必然在接收，无分享，必然无接收，这种状态是严格的，不会出现一端分享，另一端不在接收状态，或无分享，另一端处于接收状态，这就是要要求最终双端的状态组合是正确的。

附图说明

图1为本发明主叫端开/关辅流流程图；

图2为本发明被叫端开/关辅流流程图；

图3为本发明主叫端请求辅流发送后被叫端请求抢流流程图；

图4为本发明被叫端请求辅流发送后主叫端请求抢流流程图；

图5为本发明会议系统结构图。

具体实施方式

下面结合说明书附图和具体的实施例，对本发明作详细描述。

实施例1

本实施例一种通信系统，所述系统包括通信端A和通信端B，A和B在进行音视频通话，A为主叫端，B为被叫端。通话时A端需要向B端演示数据，如共享屏幕或PPT，演示时通过辅流向B端共享，即产生第二路视频流，视频流为A向B演示的内容；此时若B也想向A演示数据，直接执行共享操作，此时辅流共享方向有A向B转为由B向A，此过程称为辅流抢占，当B演示结束执行结束共享。

所述系统通话时使用JSON作为本辅流控制协议载体，每个报文以'\0’收尾，使用SIP INFO方式传输控制报文，JSON即JavaScript Object Notation,是一种轻量级的数据交换格式，JSON明文可读，是一种数据结构化的表示。系统通信时也可以用XML等格式表示，在表达相同的数据时，XML所使用的报文大小比JSON稍大，使用JSON更轻量化。

协议层分C-S，以被叫端S的状态为主。用于保证最终只有一个分享状态，应用层只分local-share、remote-share和no-share，即本地分享、远端分享和无分享状态，协议层逻辑与辅流控制相同，通话端在分享状态下可以自已关闭分享，或者接收端抢辅流后接收端开始分享，不管是通话端分享还是接收端分享，同一时间只有一端分享，一端接收，也不会出现通话端在分享，接收端不接收的状态。本实施例辅流基于SIP信道传输，SIP信道保证了辅流控制的可靠性。

本实施例通信系统基于SIP的辅流控制协议报文头部字段中各字段如下：

method：请求方法，值包括为share Request，C向S请求开启分享；share Release，C向S请求释放分享；share Status；S主动向C推状态，一般是S上层的行为触发的，如果是C触发的，使用响应直接携带状态，不需要S主动推；

c_cseq：主叫端指令序列，client command sequence的简写c-cseq，值为32位整数，c的cseq，如果s收到更小的c-cseq，不执行动作，返回最新的状态。

s_cseq：被叫端指令序列，server command sequence的简写s-cseq，值为32位整数，s的cseq，如果c收到更小的s-cseq，丢弃收到的小s-cseq状态；

share_state：分享状态码，值为c/s/n，表示当前是c-share、s-share或no-share；

所述通信系统在通话过程中有四种状态：

状态一：主叫端C端请求开辅流分享，分享结束主叫端请求关辅流。如图1所示，C端基于SIP信道发送通话请求与S端建立通话，S端收到通话请求后回复，C端确认已建立通话。C端发送共享请求，报文内容为C端的指令序列值和请求方法，此时C端的指令序列为1，请求方法为请求共享share Request，S端收到请求后回复S端的指令序列和分享状态码，当前状态S端指令序列为1，分享状态码为“C”，表示C端在共享c-share，C端辅流发送，S端辅流接收。演示结束，C端取消共享，发送取消共享请求，报文内容中指令序列为2，请求方法为释放分享share Release，C向S发送命令请求的指令序列，用来处理网络波动导致的命令乱序，S收到C的命令请求，如果该值与本地记录的值大，记住这个值，并处理命令，S收到一个比本地所记录的值更小，忽略这个请求，不执行动作，返回S最新的状态。此时S端收到的指令序列为2，大于本地记录的值1，S端执行接收到的命令请求，执行后S端回复S端的指令序列2和分享状态码n，表示无共享状态no-share，C端和S端都停止发送和接收辅流。

状态二：被叫端S端请求开辅流分享，分享结束被叫端S端请求关辅流。如图2所示，C端基于SIP信道发送通话请求与S端建立通话，S端收到通话请求后回复，C端确认已建立通话。此时S端发送共享请求，报文内容为S端的指令序列和分享状态码，S端的指令序列为1，分享状态码为s，表示S端在共享s-share，C端接收到请求回复确认，C端开始辅流接收，此时S端进行共享演示，S端开始辅流发送。演示结束，S端取消共享，发送取消共享请求，报文内容为S端的指令序列和分享状态码，S端的指令序列为2，分享状态码为n，表示无共享状态no-share，此时C端接收到S端发出的指令序列为2，大于之前收到的指令序列1，回复确认执行当前指令，当前无共享状态，C端和S端都停止发送和接收辅流。

状态三：主叫端C端请求辅流发送后被叫端S端请求抢流，分享结束被叫端S端请求关辅流。如图3所示，C端基于SIP信道发送通话请求与S端建立通话，S端收到通话请求后回复，C端确认已建立通话。C端发送共享请求，报文内容为C端的指令序列值和请求方法，此时C端的指令序列为1，请求方法为请求共享share Request，S端收到C端指令序列后回复S端的指令序列和分享状态码，当前状态S端指令序列为1，分享状态码为“C”，表示C端在共享c-share，C端辅流发送，S端辅流接收。此时S端需要演示，进行抢辅流动作，S端发送共享请求，报文内容为S端的指令序列和分享状态码，S端的指令序列为2，分享状态码为s，S端的指令序列值2大于之前收到的指令序列值1，C端回复确认执行当前指令，C端开始辅流接收，当前状态为S端在共享s-share，S端开始辅流方发送。演示结束，S端取消共享，发送取消共享请求，报文内容为S端的指令序列和分享状态码，S端的指令序列为2，分享状态码为n，表示无共享状态no-share，C端接回复确认执行当前指令，当前无共享状态，C端和S端都停止发送和接收辅流。

状态四：被叫端S端请求辅流发送后主叫端C端请求抢流，分享结束主叫端C端请求关辅流。如图4所示，C端基于SIP信道发送通话请求与S端建立通话，S端收到通话请求后回复，C端确认已建立通话。此时S端发送共享请求，报文内容为S端的指令序列和分享状态码，S端的指令序列为1，分享状态码为s，表示S端在共享s-share，C端接收到请求回复确认，C端开始辅流接收，此时S端进行共享演示，S端开始辅流发送。此时C端需要演示共享，抢辅流共享，C端向S端发送指令请求，报文内容为C端的指令序列值和请求方法，此时C端的指令序列为1，请求方法为请求共享share Request，S端收到请求后回复S端的指令序列和分享状态码，当前状态S端指令序列为2，分享状态码为“C”，表示C端在共享c-share，C端辅流发送，S端辅流接收。演示结束，C端取消共享，发送取消共享请求，报文内容中指令序列为2，请求方法为释放分享share Release，此时C端的指令序列值2大于本地记录的指令序列值1，S端执行接收到的命令请求，执行后S端回复S端的指令序列3和分享状态码n，表示无共享状态no-share，C端和S端都停止发送和接收辅流。

本实施例通话系统的辅流基于SIP协议控制，基于SIP信道，辅流复用了SIP信道传输，系统不需要额外的控制通道和额外的端口监听。基于本实施例基础上增加信道还可以实现丢包重传、快速重传或重复包处理。

实施例2

本实施例与实施例1基本相同，不同之处在于，本实施例为一种会议系统，如图5所示，所述系统有三个终端，分别为终端A、终端B和终端C；各终端通过会议系统中服务器控制，当会议中某一终端需要进行辅流分享时，本实施例与实施例1相同，基于SIP信道进行辅流控制，控制协议指令和辅流控制逻辑与实施例1相同，如当终端A发送辅流时，终端B和终端C进行辅流接收状态，同一时间只有一个终端进行辅流发送，终端B或终端C在接收辅流时可以抢辅流转为发送辅流，当终端B或终端C抢辅流进行辅流发送后，终端A从发送辅流状态变成接收辅流状态。

以上示意性地对本发明创造及其实施方式进行了描述，该描述没有限制性，在不背离本发明的精神或者基本特征的情况下，能够以其他的具体形式实现本发明。附图中所示的也只是本发明创造的实施方式之一，实际的结构并不局限于此，权利要求中的任何附图标记不应限制所涉及的权利要求。所以，如果本领域的普通技术人员受其启示，在不脱离本创造宗旨的情况下，不经创造性的设计出与该技术方案相似的结构方式及实施例，均应属于本专利的保护范围。此外，“包括”一词不排除其他元件或步骤，在元件前的“一个”一词不排除包括“多个”该元件。产品权利要求中陈述的多个元件也可以由一个元件通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。

Claims (10)

1.一种基于SIP的辅流控制方法，其特征在于，通话系统包括主叫端和被叫端，主叫端或被叫端基于SIP信道发送指令至另一端实现辅流共享或取消辅流共享，辅流共享状态下辅流接收端进行抢辅流动作发送辅流。

2.根据权利要求1所述的一种基于SIP的辅流控制方法，其特征在于，系统请求辅流共享通话系统主叫端或被叫端发送指令请求共享，指令内容包括指令序列和共享状态，接收端接收到指令后根据指令序列值的优先级选择执行或丢弃，执行后回复指令序列和状态；系统取消辅流共享时辅流发送端发送指令结束共享，指令内容包括指令序列和请求状态，辅流接收端收到指令后回复确认。

3.根据权利要求2所述的一种基于SIP的辅流控制方法，其特征在于，辅流共享状态下辅流接收端进行抢辅流动作发送辅流，辅流接收端发送指令请求抢辅流，指令内容包括指令序列和请求状态，辅流发送端接收到指令确认后转为接收辅流，原辅流接收端发送辅流。

4.根据权利要求3所述的一种基于SIP的辅流控制方法，其特征在于，辅流发送端在共享状态下关闭分享或者由辅流接收端进行抢辅流动作。

5.根据权利要求3所述的一种基于SIP的辅流控制方法，其特征在于，主叫端指令中请求方法包括请求共享、释放共享或共享状态。

6.根据权利要求3所述的一种基于SIP的辅流控制方法，其特征在于，被叫端状态码包括主叫端共享、被叫端共享和当前无共享。

7.根据权利要求3所述的一种基于SIP的辅流控制方法，其特征在于，指令序列的值为自然数，指令序列值根据指令的不同变化，指令序列值确定指令优先级。

8.根据权利要求4或5或6或7所述的一种基于SIP的辅流控制方法，其特征在于，系统协议为JSON或XML形式。

9.根据权利要求8所述的一种基于SIP的辅流控制方法，其特征在于，辅流共享时被叫端有多个。

10.一种会议系统，使用任一如权利要求1-9所述的一种基于SIP的辅流控制方法，其特征在于，所述会议系统有多个终端，任一终端开始辅流共享时，其余终端自动为接收状态。

Images