一种远程监护呼叫方法及系统与流程

本发明涉及监护呼叫通信技术领域，尤其是涉及一种远程监护呼叫方法及系统。

背景技术：

在我国，养老问题是全社会关注的民生热点话题，近四十年来独生子女生育政策的实施，所形成的421/422家庭结构使得子女对老人的养老负担极大。许多独居、空巢老人突发疾病，因得不到及时救治而延误病情，甚至独居老人死亡多日而不被发现的情况也屡现报道。护理人员的短缺也是不争的事实。将智能设备引入养老领域，可以有效缓解社会的养老压力。让智能设备代替子女时时守护在老人身边，使老人得到最及时而准确的照料是本发明的初衷。随着物联网技术的发展和智能手机的普及，使这一愿望有了可实施的技术保证。

当前的智能家居中的紧急报警产品通常为一键报警，采用电池供电，仅提供一个开关信号，报到手机app中。现场情况不可知，误报、电池失效、紧急情况下找不到按钮这些情况使得产品远不能满足实际需求。一些智能手表的一键语音报警功能虽然可以提供现场语音情况，但因其语音通话走的是手机语音通道，紧急情况下也只能轮流拨打联系人，接通效率不高，无法语音留言，最主要的是需要频繁充电，从技术角度讲，只是手机的替代品。

鉴于此，提供一种老人容易操作，监护人员可以实时而准确的获得现场状况，同时又能便利老人生活起居的智能远程护理可视呼叫系统是目前所要研究的课题。

技术实现要素：

为了克服上述现有技术存在的缺陷，本发明提供了一种解决方案。

本发明的第一目的在于提供一种远程监护呼叫方法，能提供被监护人远程的、实时的声音和视频，在一般呼叫时，可以方便的进行沟通；在紧急呼叫时，能同时呼叫多个联系人，并实现一对多的通信；另外还实现了多种形式的补充通知，保证被监护人得到有效和及时的监护。

本发明的第二目的在于提供一种容易操作，监护人员可以实时而准确的获得现场状况，同时又能便利被监护人生活起居的远程监护呼叫系统。

一种远程监护呼叫方法，用于在互联网平台上，为被监护人一侧的监护设备和远程的监护人一侧的交互控制模块建立起通信连接并交互的过程，所述交互控制模块为安装在通信终端上的应用程序，所述监护设备和所述交互控制模块之间都通过服务器发起对对方的呼叫，呼叫过程是双向的，其中监护设备发起的呼叫包括一般呼叫和紧急呼叫，服务器帮助监护设备和交互控制模块建立起一对一或一对多的通信连接，所述呼叫方法的步骤包括：

步骤s1、新的监护设备上线，交互控制模块添加新的监护设备，并远程为该监护设备设置参数，设置多个交互控制模块的id作为该监护设备的联系人，选取其中的部分交互控制模块的id作为紧急呼叫联系人；

步骤s2、交互控制模块和监护设备都主动和服务器保持连接，告知自己的ip和端口号，服务器维持着一张在线交互控制模块用户和监护设备的数据链表；

步骤s3、如果交互控制模块对监护设备或者监护设备对交互控制模块发起一般呼叫，则进行步骤s4，如果监护设备对交互控制模块发起紧急呼叫，则进行步骤s5；

步骤s4、对于一般呼叫，主叫方发给服务器的报文中，类型标注为一般呼叫，包含主叫方id和被叫方id，服务器从在线的交互控制模块用户和监护设备的数据链表中找到被呼叫方id对应ip和端口号，转发该信息，被叫方应答后，服务器帮助双方建立p2p连接，建立连接后进行步骤s6；

步骤s5、对于紧急呼叫，主叫方发送给服务器的报文中，类型标注为紧急呼叫，包含主叫方id以及包含所有紧急呼叫联系人的被叫方id，服务器从在线的交互控制模块用户和监护设备的数据链表中找到所有被呼叫方id对应的ip和端口号，同时向所有紧急呼叫联系人发送紧急连接请求，收到应答后，服务器为监护设备和所有紧急呼叫联系人的交互控制模块建立一对多的p2p连接；

步骤s6、建立p2p通信连接后，监护设备将现场采集到的视/音频信息发送给交互控制模块，同时接收来自交互控制模块的音频信息，交互过程包括一对一或一对多的交互。

优选的，还包括对于未能成功建立连接的呼叫的处理过程：

服务器尝试通过第三方推送服务器推送呼叫请求到交互控制模块所在的通信终端上；如果连接尝试失败，呼叫信息无法送达，服务器记录该事件，待被呼叫方重新上线并和服务器连接后，立即通知该呼叫事件，或主叫方继续选择留言，留言信息保存在主叫方本地或服务器中，产生留言事件保存在服务器中，待被呼叫方重新上线并和服务器连接后，立即通知该留言事件。

优选的，所述服务器包含交互控制模块用户信息数据库和监护设备信息数据库；维护着一张包括ip地址、端口号在内的在线交互控制模块用户和监护设备信息数据链表。

优选的，所述监护设备和交互控制模块之间的远程视/音频数据传输按如下方法进行：

发送方上设置第一级存储池，在接收方设置第二级存储池和第三级存储池；

发送方将每一帧视/音频数据拆分成长度固定的多个数据包，并在每个数据包上增设包括时间戳和序列号在内的标记信息；

接收方接收到数据包后，根据数据包的序列号存储到第二级存储池指定排序位置；如果有漏包的，则请求发送方通过第一级存储池发送对应标识的数据包；

接收方将第二级存储池已排好序的数据包转存至第三级存储池，解包后重新装载组合成视/音频数据帧。

优选的，所述远程视/音频数据传输方法还包括：

接收方设置一标志池，和第二级存储池的每个单元对应；

定时遍历标志池，查看是否有漏包，如果有向发送方请求重发指定序列号的数据包。

优选的，所述远程视/音频数据传输方法还包括：

接收方获取第一帧视音频数据时计算发送方和接收方的系统时间差；

第二级存储池的大小由缓存的时间决定，存储池越大，越有充分时间请求重发漏包，但同时实时通信的延时也大，缓存的时间设置为100-500ms；

接收方收到数据后，通过数据包的时间戳信息控制缓存时间。

优选的，所述监护设备或所述交互控制模块登录所述服务器的过程包括：

监护设备/交互控制模块启动后，通过udp通信方式与服务器通信连接；服务器核对对方的id和密码后登录服务器，在服务器的协助下，监护设备/交互控制模块判断自己的nat类型，并上报给服务器；服务器核查对方是否有离线信息，如果有，则补发离线信息；监护设备/交互控制模块进入正常通信状态，维持心跳长连接；

交互控制模块除了以上过程外，还包括向推送服务器注册获取token，并向服务器上报token的过程。

一种远程监护呼叫系统，包括监护设备、服务器和交互控制模块，所述交互控制模块为安装在通信终端上的应用程序，其特征在于，所述监护设备、服务器和交互控制模块三者之间都基于互联网通信，当所述监护设备发起对交互控制模块的一般呼叫或紧急呼叫时，所述服务器为双方建立一对一或一对多的通信连接；当所述交互控制模块发起对监护设备的一般呼叫时，所述服务器为双方建立一对一的通信连接，其中：

所述监护设备包括：主控单元和都与主控单元相连的呼叫触发接口、语音交互单元和通信单元；呼叫触发接口包括用于发起紧急呼叫或一般呼叫的触发装置；语音交互单元用于采集监护设备周围的语音信息，播放来自交互控制模块的语音信息；通信单元用于在互联网中传输信息；主控单元协调和控制其他各单元的工作，用于音频编解码、通信报文组织和解析、数据存储及通信控制；

所述交互控制模块：通过所述服务器和所述监护设备建立通信连接；发起对监护设备的呼叫请求；对来自监护设备的紧急呼叫和一般呼叫做出不同的提示和响应；

所述服务器：用于实现所述监护设备和所述交互控制模块之间的通信，为监护设备和交互控制模块建立包括p2p对等连接在内的通信连接。

优选的，所述监护设备还包含视频信息采集单元，所述主控单元还设有视频编码和传输功能；所述视频采集单元还可以包含电机部分，用于控制视频采集的区域，当不工作时，自动转向盲区。

优选的，所述触发装置进一步包括：语音识别模块、显示控制面板、紧急拉拽开关中的一种或多种，被监护者通过语音、紧急拉拽开关或显示控制面板发起紧急呼叫或一般呼叫。

优选的，所述监护设备的通信单元包括：有线网络端口、无线wifi模块、手机模块中的一种或多种，所述手机模块作为modem使用。

优选的，所述监护设备的主控单元还包括zigbee模块，监护设备通过zigbee模块和周边区域内的其他智能装置互联互动，用于被监护者活动状态的监护。

与现有技术相比，本发明具有以下优点：

1、利用语音识别技术、视音频编解码及远距离传输技术等技术，为独居老人和长期瘫痪在床的病人提供了一种远程、智能的监护系统及呼叫方法，使被监护人在紧急情况下可以获得救助，在平常状态下可以随时和子女及护理人员进行沟通，特别适合居家养老和社区养老，对缓解我国日益严重的养老负担大有裨益。

2、在服务器的协助下，采用p2p对等网络方式在监护设备和交互控制模块之间建立直接连接，不需要通过服务器转发，减轻了服务器的负荷，有利于系统在监护设备和交互控制模块数量较多时维持稳定通信。

3、当服务器无法送达信息给监护设备或交互控制模块时，可将该信息暂时保存到服务器的数据库中，当收到对方的登录请求或心跳请求后，再补发，可防止重要信息的遗漏。

4、监护设备采用语音识别技术，便利老人操控；另外设有紧急拉拽开关，有利于在紧急情况下快速启动呼叫功能。

5、监护设备可通过zigbee接口接收家中其他区域传感器发送的信息，对老人的活动情况作出统计和判断，在发生异常时触发报警通知，实现对老人的全方位监护。

6、采用自定义的远程视音频传输方法，与没有出错重传机制的rtp/rtcp传输相比，该传输方法可以实现出错重发，还可以实现传输数据格式的自定义以及传输数据的加密，更具有实用性。

附图说明

图1为本发明远程监护呼叫方法的流程图；

图2为监护设备首次登陆及参数设置流程图；

图3为监护设备的登录过程流程图；

图4为交互控制模块的登录过程流程图；

图5为监护设备的视频编码流程图；

图6为监护设备的音频编码流程图；

图7为监护设备的音频解码流程图；

图8为实时视频、音频数据传输流程图；

图9为远程录像播放功能流程图；

图10为紧急呼叫事件整体功能流程图；

图11本发明的系统结构示意图；

图12为监护设备各智能部件结构示意图；

图13为监护设备硬件原理框图；

图14为交互控制模块的功能结构框图；

图15为自定义远程视音频传输的原理示意图；

图16为自定义远程视音频传输的流程示意图。

图中标注：1、主控制器，2、第一麦克风，3、语音识别模块，4、显示控制面板，5、扬声器，6、摄像头，7、电机，8、zigbee模块，9、外部存储器，10、wifi模块，11、以太网模块，12、手机模块，13、紧急拉拽开关，14、第二麦克风。

具体实施方式

为使本领域的技术人员更好地理解本发明的技术方案，下面结合附图对本发明提供的一种远程监控方法及智能养老远程监护呼叫系统进行详细描述。

一种远程监护呼叫方法，用于在互联网平台上，为被监护人一侧的监护设备和远程的监护人一侧的交互控制模块建立起通信连接并交互的过程，交互控制模块为安装在通信终端上的应用程序，监护设备和交互控制模块之间都通过服务器发起对对方的呼叫，其中监护设备发起的呼叫分为一般呼叫和紧急呼叫，服务器帮助监护设备和交互控制模块建立起一对一或一对多的通信连接，呼叫方法的具体步骤包括：

步骤s1、新的监护设备上线，交互控制模块添加新的监护设备，并远程为该监护设备设置参数，设置多个交互控制模块的id作为该监护设备的联系人，选取其中的部分交互控制模块的id作为紧急呼叫联系人；

步骤s2、交互控制模块和监护设备都主动和服务器保持连接，告知自己的ip和端口号，服务器维持着一张在线交互控制模块用户和监护设备的数据链表；

步骤s3、如果交互控制模块对监护设备发起一般呼叫或监护设备对交互控制模块发起一般呼叫，则进行步骤s4，如果监护设备对交互控制模块发起紧急呼叫，则进行步骤s5；

步骤s4、对于一般呼叫，主叫方发给服务器的报文中，类型标注为一般呼叫，包含主叫方id和被叫方id，服务器从在线的交互控制模块用户和监护设备的数据链表中找到被呼叫方id对应ip和端口号，转发该信息，被叫方应答后，服务器帮助双方建立p2p连接，建立连接后进行步骤s6；

步骤s5、对于紧急呼叫，主叫方发送给服务器的报文中，类型标注为紧急呼叫，包含主叫方id以及包含所有紧急呼叫联系人的被叫方id，服务器从在线的交互控制模块用户和监护设备的数据链表中找到所有被呼叫方id对应的ip和端口号，同时向所有紧急呼叫联系人发送紧急连接请求，收到应答后，服务器为监护设备和所有紧急呼叫联系人的交互控制模块建立一对多的p2p连接；

步骤s6、建立p2p通信连接后，监护设备将现场采集到的视/音频信息发送给交互控制模块，同时接收来自交互控制模块的音频信息，交互过程包括一对一或一对多的交互。

另外，远程监护呼叫方法还包括对于未能成功建立连接的呼叫的处理过程：

服务器尝试通过第三方推送服务器推送呼叫请求到交互控制模块所在的通信终端上；如果连接尝试失败，呼叫信息无法送达，服务器记录该事件，待被呼叫方重新上线并和服务器连接后，立即通知该呼叫事件，或主叫方继续选择留言，留言信息保存在主叫方本地或服务器中，产生留言事件保存在服务器中，待被呼叫方重新上线并和服务器连接后，立即通知该留言事件。

交互控制模块的载体通信终端包括手机、平板电脑等，为方便理解，交互控制模块表述为手机app，以下说明中的“设备”指监护设备。

具体地，远程监护呼叫方法分以下几个过程进行解析：

(一)、设备首次登陆及参数设置流程；

(二)、设备的登录过程；

(三)、交互控制模块登录过程；

(四)、设备的视频采集、音频采集和播放流程；

(五)、视频和音频数据的远距离实时传输过程；

(六)、远程录音/像播放(即留言)功能的实现流程；

(七)、呼叫事件整体功能实现过程。

各个过程具体如下：

(一)、设备首次登陆及参数设置流程

如图2所示，过程如下：

首先，在手机app上添加新设备，如果设备采用wifi通信，需要给设备设置wifi密码，使设备能连接网络。

随后，设备侧主动连接服务器，服务器核对设备id和出厂密码，如果验证通过，则设备添加成功，app继续为设备远程设置参数，其中，参数中最关键的是该设备关联的app用户列表以及紧急联系人列表，参数设置完毕，发送给设备侧并保存。

随后，进入正常工作状态，用心跳和服务器保持连接，同时上报最新状态。

补充说明如下：

对于流程中的步骤“手机app给设备设置wifi密码，使设备能连接网络”，新出厂的设备要连接网络，需要指定wifi网络，并且设置wifi密码，设备没有输入接口，只能通过手机app给它设置参数，具体实现方法可采用：1)设备启动时wifi模块10默认进入ap状态，作为路由器，供手机app接入，其网络名称和密码是固定的，手机app在添加新设备的状态下，自动搜索该网络，成功连接后，就可以通信了，这时就可以给设备设置它需要登录的wifi名称和密码；2)采用“一键wifi设置”，通过手机app发送广播命令，利用广播报文中的长度信息(由于报文内容全部被加密，只有该信息可以被解析)发送信息，需要一组广播报文才能拼凑出一个完整的wifi名称和密码信息，设备侧监听广播信息，从中解析出自己需要的信息；3)通过设备网络接口直接插上网线连接路由器，这时设备会自动获取ip和端口，并连接服务器，连上后就可以通过手机app给设备选择wifi源和密码了。

手机app为设备远程设置参数，设备参数中最关键的是联系人列表，即手机app用户列表，每个联系人信息包括联系人的id、便于识别的昵称，在设置单个联系人后，再选择其中的若干联系人为紧急呼叫联系人。对于面板按钮或紧急开关触发的设备联系人只需要设置这些信息即可。下面介绍以语音识别作为呼叫触发接口的设备如何进行联系人的设置，以及如何触发呼叫。

在语音识别作为触发接口的设备中，除了录入联系人的id和昵称外，还需要录入一段呼叫该联系人的录音，比如“呼叫xxx”，前面增加“呼叫”，是为了识别操作，也是为了增加音节数，否则容易误判。另外在使用中，发出指令时需要先加设备名称，例如“智管家，呼叫xxx”，其中“智管家”为设备名称，不能缺少，因为设备一直在监听声音并和设备名称比较，如果符合，再进行后面的比较，否则不判断。设备名称也是通过语音学习获得的，可以自己设定。紧急呼叫设置除了选择若干联系人外，还需要录入紧急呼叫标志语音，比如“救命”、“来人啊”等，紧急情况下呼叫时也需要说“智管家，救命”这样的格式。以上参数设置都是通过手机app远程设置，确认更改后，按照通信规约远程发送，建立p2p连接后，设备和手机app直接通信，到设备侧保存，手机app可以随时远程查看设置内容和更改设置内容。

手机app和设备都通过心跳维持和服务器的连接，因为一段时间没有心跳，该链接将被运营商强行关闭。

(二)、设备侧的登录过程

设备上电后，或断开连接重新登录的过程如图3所示，包括：

设备上电启动；设备通过udp通信方式与服务器通信连接；服务器核对监护设备的id和密码后登录服务器，当需要切换网络时服务器判断监护设备的nat类型；服务器核查该监护设备是否有离线信息，如果有，则补发离线信息；设备进入正常通信状态。

关于图3中的内容，补充说明如下：

1.步骤“ppp脚本的拨号上网”只有在通信使用手机模块12时才会有，手机模块作为modem(调制解调器)使用。

2.步骤“设备侧的nat类型判断”是为了p2p防火墙的突破做准备。

2.1)首先说明一下为什么需要p2p，即实现设备和手机app的直接连接。因为视频和音频数据如果都通过服务器转发的话，服务器的负荷相当大，特别是系统中设备和手机app数量较多时，服务器不堪重负。所以在大数据量通信时，比如视频、音频、参数设置和读取时，需要为设备和手机app建立直接的连接(p2p)。

2.2)其次说明一下p2p的连接为什么需要实现防火墙的突破。因为网络上的设备一般都在路由器的后面(手机公网虽然看不到物理上的路由器，但实际由是运营商提供的路由器服务，所有到达手机app上的数据先要经过运营商路由器防火墙的过滤：nat外部无法直接访问nat内部，必须要nat内部先访问外部的ip和端口，下次从该外部的ip和端口发出的数据才可能被允许穿透nat，即俗称的打洞过程)，受路由器防火墙的保护。路由器有四种nat类型：全圆锥、限制圆锥、端口限制圆锥、对称型。那么装置和手机app的连接会有16种nat组合方式，每种组合方式要实现p2p连接所采取的方案是不同的。所以需要先判断p2p两端的nat类型。

3.离线信息是指当服务器无法送达信息给设备或手机app时，将该信息暂时保存到服务器的数据库中，当收到对方的登录请求或心跳请求后，再补发，防止重要信息的遗漏。

(三)、交互控制模块登录过程

如图4所示，包括：

交互控制模块启动；交互控制模块通过udp通信方式与服务器通信连接；服务器核对交互控制模块的id和密码后登录服务器；交互控制模块向推送服务器注册自己，获取当前通信终端的交互控制模块的token；交互控制模块向服务器上报token，当需要切换网络时服务器判断监护设备的nat类型；服务器核查该交互控制模块是否有离线信息，如果有，则补发离线信息；交互控制模块进入正常通信状态。

补充说明如下：

对于向推送服务器获取app的token的步骤，app的token的作用为：手机app一般只有在前台时才工作，当退出前台任务后，app被系统杀死，不再工作，无法再和服务器通信，这时需要系统服务商(苹果或谷歌)提供推送通知，手机才能收到发给该app的通知信息。token就是推送服务器推送给指定手机中指定app的凭证。一般手机安装某个app后，该app的token不会改变，除非重新安装；但用户可能通过不同的手机登录，不同手机同一个app的token是不一样的，所以每次登录都重新上报一次token。当服务器要给某个app用户发送信息时，发现该app用户不在线，即app没有工作，但手机可能仍然开机，只能将该信息发送给推送服务器，具体根据数据库中的最近一次的记录，选择苹果或谷歌推送服务器，并附上目标token，于是推送服务器根据该token，将信息发送给指定手机的指定app。

(四)、设备的视频采集、音频采集和播放流程

设备的视频采集、音频采集和播放流程分别见图5、6、7。

如图5所示，视频采集过程包括：vi模块通过摄像头6捕获视频图像，对其做剪切、缩放、镜像等处理，根据参数设置输出不同分辨率的图像数据；vpss模块接收vi模块和解码模块发送过来的图像，对图像进行去噪、图像增强、锐化等处理；编码模块接收vi模块捕获并经vpss处理后输出的图像数据，叠加用户通过region模块设置的osd图像，添加时间信息，然后按不同协议进行编码并输出相应码流。

如图6所示，音频采集过程包括：ai模块捕获音频数据，然后aenc模块支持按多种音频协议对其进行编码，最后输出音频码流；

如图7所示，音频播放过程包括：接收到的音频码流直接送给adec模块，adec模块支持解码多种不同的音频格式码流，解码后数据送给ao模块即可播放声音。

(五)、视频和音频数据的远距离实时传输过程

现有的实时视音频传输一般采用rtp+rtcp传输协议，录像的远程播放一般再增加一个rtsp协议(暂停、快进、后退的控制)。该技术方案实现比较简单，调用现有的库文件来实现，只需要输入端将编码后的数据流交给接口；输出端直接从接口取出，进行解码即可，过程就完全不用控制。但该协议的最大缺点是没有出错重传的机制，另外传输的数据流格式要求是标准的。不利于数据的保密和数据的自定义处理。

我们没有采用此种方式，设备和交互控制模块之间采用最基础的udp通信方式，采用自定义协议实现视频和音频数据的远距离实时传输，由于udp不保证数据传输的可靠性，可能会有错帧(帧顺序颠倒)和漏帧的情况。因为是实时通信，几乎不能有延时，所以需要在极短的时间内判断错帧还是漏帧，是错帧需要重新排序，是漏帧需要请求对方重新发送。视频和音频数据的远距离实时传输的具体过程如图8所示，包括：

设备的码流依次经过压缩、编码、加时间戳、同步信息、加密、打包、放入设备存储池的过程后，通过udp通信方式传输到交互控制模块存储池，经过排序后，交互控制模块判断传输的码流是否有漏帧，若有，则请求设备补发，设备从发送存储池中查找该包数据，如果存在则补发，否则，将排序后的数据包经过解密、解码后，进入可播放状态。

其中，自定义视音频传输协议的核心部分内容涉及一种自定义的远程视音频传输方法，其原理和流程如图15、16所示，具体说明如下：

s11：发送方上设置第一级存储池，在接收方设置第二级存储池和第三级存储池；

s12：发送方将每一帧视/音频数据拆分成长度固定的多个数据包，并在每个数据包上增设包括时间戳和序列号在内的标记信息；

s13：接收方接收到数据包后，根据数据包的序列号存储到第二级存储池指定排序位置；如果有漏包的，则请求发送方通过第一级存储池发送对应标识的数据包；

s14：接收方将第二级存储池已排好序的数据包转存至第三级存储池，解包后重新装载组合成视/音频数据帧。

视音频数据最终解码并播放，由于经过了接收方第二、三级的数据缓存，平滑了数据传输的峰谷，使画面和音质更加流畅。

本发明的远程视音频传输方法，当数据传输过程中出现数据包丢失或次序混乱的问题时，可以在最短的时间内恢复数据，第二级存储池的大小由缓存的时间决定，存储池越大，越有充分时间请求重发漏包，但同时实时通信的延时也越大，缓存的时间设置为100-500ms。由于实现了出错重传机制，画面和声音基本不会有马赛克和卡顿现象。同时接收方的数据缓存，使播放效果更加流畅。

具体地：发送方将一帧数据拆分成长度固定的多个数据包(udp协议在发送时遇到长数据，会自动拆分成多个数据包，在接收侧重新排序组合，如果中间错了一个数据包，则整帧数据全部丢掉，不吐给接收方。仅仅因为一个数据包而损失了整帧数据，为了避免这样的情况发生，拆分的工作还是由自己来完成)，并给每个数据包增加时间戳和序列号信息。在数据发送的同时将数据保存到第一级存储池中。

接收方收到数据包后，根据数据包的序号存储到第二级存储池的指定单元中(已经起到了排序的作用)。同时为加速遍历，另外设置一个标志池，和该存储池的每个单元一一对应。定时遍历标志池，查看是否有漏包，如果有向发送方请求重发漏包(指定序列号)；接收方收到该请求后查询第一级存储池，如果数据存在，则补发。

第二级存储池的大小由缓存的时间决定，存储池越大，则有充分的时间请求重发漏包；但同时实时通信的延时也会越大。所以一般以缓存300ms为宜，再大图像就会有明显的滞后感。缓存时间通过数据包中的时间戳信息控制，由于该信息是发送方提供的，而解析和使用是接收方，所以需要统一收发双方的时间系统，解决方法是在获取第一帧数据时计算两套系统的时间差值。

当第二级存储池溢出时(所存储的数据量大于300ms)，溢出的数据会转存到第三级存储池，进入到该存储池的数据没有再次修正和补发的机会。将该存储池中的数据包解包，根据规约重新组合成一帧帧的数据，进入解码和播放的环节。

前两级存储池是为了解决udp通信的漏发和排序问题，最后一级存储池是为了将数据包重新装载成数据帧。三级存储池的类型为均为堆(fifo)，储满后循环使用。

本发明的远程视音频传输方法，解决了因传输中的错帧和漏帧导致画面出现马赛克、声音出现卡顿的问题。除此之外，自定义协议对所传视音频数据的格式并没有要求，可以实现对传输数据的加密以及传输内容的自定义。

(六)、远程录音/像播放(即留言)功能的实现流程

和实时视音频的传输过程一样，我们没有采用现有的协议，而是采用基于udp的自定义方式实现。远程录音/像播放功能的实现流程如图9所示，用于在手机app侧播放存储在设备侧的录像文件，本发明的留言功能也是以这种方式实现的。远程录音/像播放功能和实时传输的侧重点不同：实时传输的漏码重发需要在非常短的时间内完成，否则就会有明显的延时。而录像文件的播放对此要求不严格，于是存储池可以做的大些，有充分的时间请求漏码重发；远程录像播放增加了暂停、快进、后退的处理。从流程中可以看到，录像文件是加密的，如有需要可以做个性化处理，只允许特定用户查看，例如看之前要求输入用户密码，这样对保护隐私有利。

(七)呼叫事件整体功能实现过程

本系统的服务器存有所有手机app用户信息数据库和监护设备信息数据库，维护着一张包括ip地址、端口号在内的在线手机app用户和监护设备信息数据链表。平常状态下设备和手机app之间通过服务器交互信息；当设备和手机需要大数据量通信的时候，比如建立视频通话、语音通话、手机对设备进行远程参数设置、手机读取设备数据等情况下，服务器帮助监护设备和手机侧建立p2p通道，让二者可以直接通信，减轻服务器通信负担。

图10展示了紧急呼叫下整体功能实现过程，说明如下。

通信连接的建立过程：

当被监护者发起紧急呼叫后，设备根据所设参数找到对应的多个紧急联系人，获得对应的app用户id。设备随后给服务器发送紧急呼叫请求，请求中包含多个app联系人id，服务器在app在线app用户列表中遍历搜索这些app用户id，获取其对应的ip地址和端口号，向其发送紧急呼叫请求，其中部分的app用户进行了确认应答，服务器根据双方的nat类型，为设备和app用户建立一对多的p2p连接。即使对于不在线的手机app用户，也会通过消息推送，告知app用户；如果消息推送失败，服务器作为离线事件保存，待该用户上线后，第一时间通知对方。这样处理可以有效的保证被监护者的紧急呼叫得到有效的回应。

多个紧急呼叫联系人和被监护者的视频通话过程：

在通信连接建立后，app用户有权操控设备侧摄像头所连接的电机，查看被监护者的状态，设备将采集到的视频、音频数据经编码处理后远程传输到手机app侧(同时传输给多个联系人)，手机app将此视频、音频数据流进行解码和播放；与此同时，多个联系人的手机app将音频数据编码处理后远程传输到设备侧，设备侧将此音频数据流进行解码和播放。由于手机app联系人的通话是半双工的，即平常处于受话状态，只有需要送话时才通过按钮通话，所以在设备这一侧不会造成语音混乱。如此实现了多个紧急联系人和被监护者之间的视频通话

当多个联系人陆续全部退出后，摄像头返回盲区，紧急呼叫全过程结束。

另外，设备侧会自动产生并保存一个紧急呼叫全过程的录像文件，包含设备侧采集到的视频，以及语音的双向交互数据。手机app侧如果有取证的需要，也可以手动录像，保存到手机app中，录像的内容和设备侧一致。

对于一般呼叫的实现过程，将图10中的a、b、c、d联系人替换为1个联系人，是很容易替换得到的。另外紧急情况下的监护设备和多个手机app之间的视音频传输仍按照图15所示的方式进行，监护设备会同时向多个手机app的ip地址和端口号发送视音频数据，并对来自不同app的重发请求做出应答，如此维护多个通道的连接，过程采用了多线程技术。

呼叫过程是双向的，即手机app也可发起对监护设备的呼叫，手机app在系统中也是用唯一的id来表示，所以呼叫原理和监护设备发起的呼叫是一样的，只是手机app只能发起一对一的普通呼叫，而没有紧急呼叫功能。另外同理，服务器也可以为监护设备之间搭建通道，使被监护设备之间也可以相互发起呼叫，可用于被监护老人之间的互助。

除了用呼叫建立直接的通信外，还可以采用留言功能，记录一段录音/录像，产生一个事件通知对方读取，通知信息中包含该段录音/录像的识别信息。接收方收到该条通知后，即可以通过远程播放的方式实现留言的读取。

实施例

一种远程监护呼叫系统，本系统是远程监护呼叫方法的一种应用，其呼叫方法按照远程监护呼叫方法实施。需要指出的是，远程监护呼叫方法的保护范围是由所附权利要求书限定的，还可以应用在其他场景中，并不限于本实施例。

本实施例中，系统具体为一种智能养老远程监护呼叫系统，主要用于居家养老及瘫痪病人的照顾护理。老人可以通过它随时方便的和远方的子女、监护人员保持联系；紧急情况下可及时获得救助。被监护的老人通过语音控制或面板开关触发呼叫功能，紧急情况下也可以触发紧急拉拽开关13。呼叫功能分为同时呼叫多个联系人的“紧急呼叫”和呼叫单个联系人的“一般呼叫”，在没有应答的情况下可以语音留言。交互控制模块应答呼叫后，可以进行视频通话，允许多人同时接入，查看情况，与被监护人沟通；交互控制模块也可以主动联系老人，在老人语音应答后接通视频和语音通道。

除了紧急求助和一般的护理通话外，监护系统还可以用来统计和记录老人的活动情况。例如，可在家中其他区域，比如厕所、厨房或客厅，设置几个人体感应传感器，当老人经过时，进行检测并且统计，这些信息会通过zigbee模块8发送给监护设备，监护设备负责记录时间、区域并统计，当发现老人活动异常时，比如夜间频上厕所、白天没有活动迹象等，都会触发告警提示，发送给指定的主要联系人。另外监护系统还可以作为智能家居的控制端，通过zigbee小无线连接家中其他智能设备，配合语音识别功能，实现区域内智能设备的互动控制，例如夜灯的控制、家用电器的开关，便利老人的生活起居。

如图11所示，本系统包括监护设备、服务器和交互控制模块，三者之间采用互联网通信，服务器作为连接监护设备和交互控制模块的桥梁，同时也可以为监护设备和交互控制模块建立起对等连接(p2p)的通道。监护设备和交互控制模块都主动和服务器维持心跳连接，都上报自己的当前状态、最新事件信息，在需要大数据通信时，服务器帮助监护设备和交互控制模块建立对等通信连接。交互控制模块的载体包括手机、平板电脑等，本实施例中，交互控制模块为手机中的app。

监护设备各智能部件结构如图12所示。本实施例中的监护设备为一种固定装置，一般安装于被监护者的床头或室内其他区域，在本实施例中的“设备”都指监护设备。监护设备包括：呼叫触发接口、语音交互单元、主控单元和通信单元。

其中呼叫触发接口包括：语音识别模块3、显示控制面板4、紧急拉拽开关13。语音识别模块3接有第二麦克风14，用于在使用语音识别时语音的输入。语音识别模块3负责解析用户语音命令表达的意图。语音识别功能包括两种实现方式：一种是通过语音识别模块3的dsp芯片对比当前的语音命令信号特征和之前录入的语音命令信号特征，如果匹配，请求确认，获得确认后执行命令；另一种方式是主控制器1把语音命令直接数字化后发送给服务器，服务器接入专门的语音识别云服务器，解析后获取用户意图，请求确认，获得确认后执行命令。显示控制面板4上设有控制按钮和显示屏，除了语音控制外，用户还可以通过显示控制面板4上的按钮来完成命令输入，比如呼叫用户或应答用户等。紧急拉拽开关13一般用于发起紧急呼叫，也可以通过交互控制模块远程设置时间阀值，根据拉拽时间的长短区分紧急呼叫或一般呼叫。

语音交互单元包括：第一麦克风2、扬声器5、摄像头6。电机7作为摄像头6云台的一部分，连接摄像头6并控制摄像头6的转动，除了扩大可视范围外，还符合保护老人隐私的需求，摄像头6在不通话的时候转向盲区，只有在视频通话允许接入，或紧急报警后的若干时间内才被允许手机端操控。

主控单元包括：主控制器1、zigbee模块8、外部存储器9。主控制器1是系统的核心部件，和其他各单元都有连接，具体参见图12，主控制器1协调控制各单元的工作，实现视频采集、音频采集和播放、通信报文组织和解析、数据存储、电机转动控制等功能。zigbee模块8负责和家中其他智能单元如传感器通信，统计老人的活动情况，发现异常时触发报警事件，通知到手机app。外部存储器9包含用于存储录音/录像文件的tf卡。

通信单元包括：wifi模块10、以太网模块11、手机模块12。一般情况下使用wifi模块10或以太网模块11，在没有宽带接入的环境下可以选用手机模块12，手机模块12目前为4g模块，作为modem使用。

具体的，监护设备硬件原理框图如图13所示，本实施例中，主控制器1采用华为海思hi35xx系列芯片，具体采用hi3518e芯片，该芯片采用arm9架构，可运行linux操作系统，内置ddr2内存，省去了外置ddr的布线麻烦，视频编码格式为h264，编码能力720p@25fps，由于采用硬件编码，可以释放运算能力用作其他方面的处理。摄像头6的镜头芯片采用ov9712，也可采用其他芯片，如ar0130。外部存储器9包括flash存储器、大容量tf卡和参数存储器。flash存储器采用w25q128(128mbit)，通过spi接口和hi3518e连接。参数存储器采用e2prom，通过i2c接口连接hi3518e。大容量tf卡用于存储视、音频数据、历史数据、事件记录等信息，通过sdio接口连接hi3518e，用于存储视频和音频资料。hi3518e只有一个usb2.0(host)接口，所以当同时连接wifi模块10和手机模块12时，需要用hub芯片扩充。以太网模块11的以太网收发芯片采用smsc8710，网线接口采用网络滤波器hr601680进行隔离。hi3518e通过功放芯片hxj8002连接扬声器5。电机7控制中，电机7的驱动采用达林顿驱动管uln2803。摄像头6中夜视切换模块包括光敏电阻、红外灯和双滤镜(ir-cut)切换驱动器三部分，光敏电阻用于感知光线强弱，红外灯用于夜视照明。zigbee模块8有多种芯片可以选择，和hi3518e的接口一般是串口uart、spi等。

其他的，摄像头6有自动夜视切换功能，夜间无需开灯，便可查看被监护者的情况。电机7转动的位置有记忆功能，参数中设置盲区、工作区一、工作区二等等，这样就可以快速定位摄像头6的视角，而不需要反复调整。当视频通话结束后镜头自动转向盲区。有利于保护监护者的隐私。

本系统的手机中设有监护应用程序(app)，手机内的app的功能模块如图14所示：

包含设备列表单元块；实时通话请求、告警推送；用户和所有关联设备交互的历史信息记录列表；用户相关信息。

其中，设备列表单元块除了显示各设备当前状态为在线或离线，设备的添加和删除操作外，还可以对列表中的每个设备做如下操作：保存在设备侧的监护设备远程参数的设置，包含语音识别命令设置、自动报警条件设置、设备联系人清单设置、安全密码设置、网络设置及其他设置；保存在app中的监护设备本地参数的设置，包含设备图片设置、昵称设置、访问密码设置；向设备发起视频通话、语音通话；远程查看设备侧数据记录(事件、视频录像、留言信息)，记录有未读信息提示。

其中，实时通话请求、告警推送是指当重要的实时信息到来时，app显示告警提示框或推送的通知，并通过震动和铃声，提醒app用户注意查看。重要信息的内容包括：紧急求助、通话请求、留言信息、重要事件。

其中，用户和所有关联设备交互的历史信息记录列表用来记录设备发来的通话请求及告警推送过的所有内容，按照未读优先、最近发生的事件优先的排列顺序显示，点击可查看详情。例如，点击某监护设备发来的某条历史留言记录，即可接听留言内容。

其中，用户相关信息包括用户的注册、登录信息，用户参数设置和显示信息，包含app用户头像设置、昵称设置、访问密码设置、注册信息修改等。

本系统的服务器存有所有手机app用户信息数据库和监护设备信息数据库，维护着一张包括ip地址、端口号在内的在线手机app用户和监护设备信息数据链表。平常状态下监护设备和手机app之间通过服务器交互信息；当监护设备和手机需要大数据量通信的时候，比如建立视频通话、语音通话、手机对设备进行远程参数设置、手机读取设备数据等情况下，服务器帮助监护设备和手机侧建立p2p通道，让二者可以直接通信，减轻服务器通信负担。

另外在手机app不在线的情况下，服务器会通过推送服务器把信息推送到手机，如果推送失败，服务器会记录该信息，当手机app上线后，服务器会第一时间以离线事件的方式通知对方，保证信息的送达率。

本系统监护呼叫的实施采用本申请提出的远程监护呼叫方法，前文已详细的说明，这里不再累述。

以上仅为阐述本发明核心内容的说明，需要指出的是，本发明的保护范围是由所附权利要求书限定的，本领域的一般技术人员可以很容易理解本发明的基本构思并进行一定的变化或更改。凡在本发明的基本构思和原则之内，任何修改、替换或改进等，均应属于本发明的保护范围之内。