门禁设备、用户终端、用于该门禁设备的后台系统及方法与流程

本发明涉及一种楼宇/小区/住宅门禁设备装置系统，特别是涉及具有可视对讲功能的门禁设备系统。

背景技术：

目前的小区/楼宇/住宅可视对讲门禁系统基本都是采用有线连接，为每家每户通过有线接入网络或者模拟视音频信号，然后给每户提供一个专用可视对讲装置/控制器。这种系统的缺点是设备和线路必须是楼宇规划建设期间就设计安装好，而后期使用后的设备和线路老化以及损坏维修问题不断，同时由于科技进步很快，过几年原来看起来还不错的入户设备就显得跟不上时代的进步而显得陈旧和不好用。但是，如果更换这些设备和相关线路的话，小区住户和物业公司不愿承担相关昂贵的费用。

现在已经是无线互联网的时代，是人手一个甚至多个智能手机的时代。目前市面上有几个具有用不同技术方案实现的无线可视对讲门禁系统方案，比如专利申请号 201510090128.6 所述的方案，采用的是网络摄像头的方案，但该方案只涉及门禁端视音频传输（类似的还有201410730984.9），未涉及用户终端方的视音频实时传输，即只实现了单方的视音频传输。其它的解决可视对讲方案还包括采用视音频编码器将编码后的流数据推送至云服务器（201410620669.0）或者是使用SIP服务器（201610365384.6）的方案等等。又如专利申请201510028968.X，只说用户终端和门禁设备间采用标准协议实现可视对讲，实施方式中也没有任何详细说明来公开所用技术实现可视对讲功能。如果采用市面上一些有视频语音通话功能的云服务的方案（如201610201447.4）话，会有用户规模（包括门禁数量和用户终端数量）上来之后成本不可控，集成麻烦等问题。又例如201510414957.5的方案，涉及可对讲的门禁和移动终端，以及后台系统，但它没有实现可视对讲功能，而且后台系统也有诸多限制。又例如201410744548.7，只实现了用户使用移动终端呼叫门禁设备进行可视对讲功能，而不能通过门禁设备呼叫用户的移动终端。

总之，上述方案都有功能不完整、实施复杂、成本高，使用不方便，日常费用高等一系列问题，当然最主要的是都没有考虑到如果用户规模和门禁设备规模很大的时候，如何解决后台系统的性能、负载能力、设备投资和运营成本的问题。

技术实现要素：

本发明的一个目的是提供一种新的使用后台系统服务的门禁设备、具有可视对讲功能的用户终端、为门禁设备和用户终端实现可视对讲的后台系统和方法。

门禁设备包括：处理器、输出设备、输入设备、网络模块、电锁控制接口、电锁；门禁设备通过网络模块连接和登录至互联网上的后台系统；

后台系统包含：总控模块、消息处理模块、信令处理模块；总控模块处理来自门禁设备和用户终端的命令请求，并控制信令处理模块；消息处理模块提供发送/接收通知消息功能；信令处理模块为使用通话用户凭证做通话登录的设备间发起和协商信令通道，并协助两端设备建立流媒体数据传输链路；

用户终端通过网络登录和访问后台系统的服务；

通过以下方式实现门禁设备与用户终端的可视对讲：门禁设备根据输入设备的输入向后台系统发出呼叫请求，后台系统中的总控模块根据呼叫请求中的参数找到对应的用户终端，为该用户终端在信令处理模块中分配一个临时通话用户凭证（例如实施例中，可以包含用户ID和对应的登录凭证，登录凭证为随机生成，甚至用户ID也可以是动态生成的），然后通过消息处理模块发送呼叫请求消息给用户终端让它能够使用新分配的临时通话用户凭证在信令处理模块做通话登录，消息参数中包含临时通话用户凭证和主叫设备的标识；用户终端收到通话请求消息后通过消息处理模块向总控模块回应确认消息并同时发送给主叫设备；用户终端的用户确定通话开始后，用户终端通过信令处理模块向主叫设备发起可视对讲；可视对讲操作完成或者中断后用户终端从信令处理模块退出通话登录。

通过上述技术方案，实现了对用户终端使用信令处理模块进行通话的动态授权，从而大幅控制了信令处理模块的同时连接设备数和并发处理数（同时长连接数太多时，PING-PONG心跳消息处理也会消耗不小的处理器时间和网络传输资源）；也避免了当用户数量庞大时，信令处理模块需要外部数据库支持才能完成登录认证以及由此而来的一系列性能与安全性问题。这对于百万以上用户/用户终端的应用场景下效果尤其明显。实践中，根据门禁设备呼叫用户终端的使用场景，更可以对通话时长进行限制，比如限制在一至两分钟内，以防止用户对该功能的滥用。信令处理模块可以在通话完成或中断后删除该临时通话用户凭证记录，也可以是登录成功之后就让它失效不能再用来登录。

另外，信令处理模块是点对点可视对讲通讯时找到并协商连接对方的处理单元，通话双方设备的视音频流数据通道连接建立之后，两端设备间的流数据的传输就是由双方设备自己的实时流传输控制程序和协议来完成（传输也可能需要中转，但不是由信令处理模块来完成）。这种模式在可视对讲门禁的使用场景下非常有效，而且也不需要安装和使用复杂和成本高的SIP服务器以及配套昂贵的带宽资源。从流数据的传输来看，相比较于使用网络摄像头、推流至云服务器和SIP服务器等方案，此方案具有接通快、延时低、成本低的优点。

本发明的第二个目的是提供一种含有用户终端被临时授权使用可视对讲功能的门禁设备、后台系统和用户终端，其中，门禁设备接入后台系统后，使用分配给它的固定通话用户凭证在信令处理模块做通话登录；然后用户终端通过信令处理模块向门禁设备发起可视对讲。

此方案适合门禁设备数量不算很多的情况，特别是少于一万台的情况下。此技术方案的优点是实现简单，更适合系统部署和推广初期用户和门禁设备数还不算多，投入有限的情况。

本发明的第三个目的是提供一种含有门禁设备与用户终端被临时授权使用可视对讲功能的门禁设备、后台系统和用户终端，其中，门禁设备接入后台系统后，不自动在信令处理模块做通话登录；门禁设备收到被叫设备发来的确认消息后使用分配给它的固定通话用户凭证在信令处理模块做通话登录；可视对讲操作完成或中断后，门禁设备从信令处理模块退出通话登录。

而此方案通过对门禁设备采用动态登录信令处理模块进行通话的方法，进一步降低了信令处理模块的同时连接数，在门禁设备数量非常大的时候，产生的效果更明显。

本发明的第四个目的是提供一种通过上述后台系统实现点对点可视对讲功能的用户终端，其中，后台系统在为被叫设备用户终端分配临时通话用户凭证时，也为主叫设备分配第二临时通话用户凭证，并通过呼叫请求应答返回第二临时通话用户凭证给主叫设备；主叫设备收到被叫设备发来的确认消息后使用分配给它的第二临时通话用户凭证在信令处理模块做通话登录；可视对讲操作完成或中断后，主叫设备从信令处理模块退出通话登录。

此技术方案中，主叫设备可以是第二用户终端，也可以是门禁设备。通过此方案，两个用户终端通过后台系统的授权后可以进行可视对讲。实施例中，可以为住户的用户终端提供物业管理员的用户终端呼叫入口，方便住户呼叫物业管理员或反之由物业管理员呼叫住户。更复杂的实施例中，可以允许用户在好友间进行呼叫。

如果主叫设备是门禁设备时，通过此技术方案，更避免了信令处理模块对数据库检索和维护的需求，在门禁设备数量非常大时可以有效地提升信令处理模块处理连接、通话登录认证的速度和效率。

本发明的第五个目的是提供一种含有上述功能的门禁设备、后台系统和用户终端，其中，门禁设备或者用户终端之间呼叫建立完成，两端设备之间点对点数据传输通道建立起来后，直接使用该通道作为信令通道，不再通过信令处理模块来处理。主叫设备在直接通讯通道建立之后，发送通道切换信令给信令处理模块；信令处理模块收到后转发给被叫设备；并根据通话时长的限制来设定超时事件；超时事件被触发后，信令处理模块向总控模块发送处理通话超时请求；总控模块收到请求后向主叫设备和被叫设备发送强制关闭通话消息；主叫设备和被叫设备收到该消息时，如果原来的通话还在进行中，就强制停止通话，关闭点对点数据传输通道。信令处理切换至点对点数据传输通道后，如果主叫设备或被叫设备是动态进行通话登录的，就可以退出信令处理模块的通话登录，而不用等到通话完成或者中断之后，具体方法是：主叫设备在发完通道切换信令后退出通话登录，被叫设备是收到通道切换信令后退出通话登录。

此方案利用了点对点通讯中的数据传输通道来给主被叫设备进行信令交换通讯。它进一步减少了信令处理模块的通讯流量和处理负载，并大幅减少了并发连接数和连接占用的时间，而且信令传输更快和更直接。注：通话过程中，两端设备仍然需要使用信令进行通讯协商，尤其是在网络连接情况变化较频繁的时候。

本发明的第六个目的是提供一种含有上述功能的门禁设备、后台系统和用户终端，其中，门禁设备呼叫用户终端过程中，如果用户终端用户决定给访客开锁，用户终端发送开锁请求给总控模块，总控模块验证并记录至日志后，通过消息处理模块定向发送开锁消息给门禁设备；门禁设备接收并校验该开锁消息之后，就给电锁控制接口发送开锁命令；电锁打开后，门禁设备又会通过消息处理模块发送电锁已开启消息给用户终端的用户和总控模块。

此方案通过由总控模块进行验证和记录来防止用户终端直接控制门禁设备的身份伪造以及缺乏记录的安全隐患。同时，因为采用异步消息传递的机制，更适合门禁设备和用户终端大规模部署的场合。

本发明的第七个目的是提供一种含有上述功能的门禁设备、后台系统和用户终端，其中，当门禁设备呼叫用户终端时，带有摄像头输入设备的门禁设备在发呼叫请求给后台系统前，将摄像头拍下的访客照片以大比例有损压缩方式生成的照片文件上传到后台系统；后台系统在发送通话请求消息给用户终端时，通话请求消息的参数中包括了已上传照片文件的信息；用户终端接收到通话请求消息后，解析出照片文件的信息，并在背景线程中下载照片文件；照片下载完成后，显示在用户终端上的接听界面中；接听界面中显示的信息还包括小区信息，门禁设备信息，界面中用户可以选择的操作包括：通话、挂断、开锁；用户终端的用户根据接听界面显示的信息，不需要进行通话就可以决定是否开锁。

此方案可以方便用户在熟悉访客时迅速为其开锁，节省用户的时间和无线网络通讯流量。

通过信令处理模块完成两个设备间可视对讲连接建立和协商功能，可以通过另外的转发服务器实现这两个设备间数据包的中转，也可以通过点对点直接通讯方式（见图1的虚线28），如果不成功再使用中转。

针对不同的实施例，消息处理模块包括可以实现消息发布/订阅功能的后台系统中的程序模块、服务、应用容器、虚拟机、服务器主机、集群或者调用系统外部实现此功能系统的接口代码。

同样的，针对不同的实施例，信令处理模块包括可以实现信令处理功能的后台系统中的程序模块、服务、应用容器、虚拟机、服务器主机、集群或者调用系统外部实现此功能系统的接口代码。

同样的，针对不同的实施例，总控模块包括可以实现本系统的总控功能的后台系统中的程序模块、服务、应用容器、虚拟机、服务器主机、集群。

针对不同的实施例，门禁设备可以有不同类型的输入设备和输出设备，比如可以使用触摸显示屏作为人机交互输入输出界面，也可以使用非触摸屏作为显示输出设备，而用数字键盘作为输入设备。视音频输入设备一般在实施例中，可以使用内置摄像头和麦克风；在某些特殊的实施例中，也可以没有摄像头，而只实现语音对讲功能；门禁设备上的程序可以自动根据设备有的媒体输入模块传输合适的数据流。为提高用户使用体验，音频输入/输出也可以作为人机交互操作的输入/输出方式。输入设备也可以只是设备面板上的按钮，比如别墅门口的门禁设备，可以只有呼叫、取消按钮。输出设备也可以不使用显示屏，而只用声音和提示灯来做输出提示。

针对不同的实施例，用户终端包括：带有网络连接的智能手机、平板电脑、台式机、笔记本电脑、车载设备、智能电视等通用或专用智能设备通过安装运行客户端软件来访问后台系统的服务，或者通过浏览器开启带有客户端程序的网页来访问后台系统的服务，在第三方客户端软件内嵌浏览器模块中运行的代码访问后台系统的服务，在嵌入式智能设备中运行程序访问后台系统的服务。

本发明的主要设计思想是通过后台系统中，总控模块给要进行通话的已接入系统的门禁设备和用户终端只在需要进行通话的时候才分配临时通话用户凭证或才允许登录信令处理模块（亦即通话登录），以这样的方式来减少信令处理模块的的同时连接设备数。另外，此方法也避免了信令处理模块处理和维护大规模用户登录数据库的麻烦，速度和安全性都得到很大的提高。通过这样的设计，还解决了用户数量和门禁设备数量大量增长后信令处理模块的负载能力不足的问题。特别是当消息处理模块为消息处理服务器集群、信令处理模块为信令处理服务器集群，而且总控模块是为每个小区门禁使用独立的应用容器并运行在云技术的平台上，那么本发明将实现一个支持海量用户终端用户和很多小区门禁设备同时在线和可视对讲的系统。

附图说明

附图用来提供对本发明技术方案的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明的技术方案，并不构成对本发明技术方案的限制。

图1是可视对讲门禁设备和后台系统、用户终端间构成和通讯关系示意图；

图2是图1所示门禁设备的内部组成；

图3是支持规模化用户和多个小区的本发明的实施例一；

图4是图2门禁设备的实施例一；

图5是图4所示门禁设备实现示例进行可视对讲功能实现功能的流程图；

图6是图3所示用户终端客户端APP软件实现示例处理消息监听服务的流程图；

图7是图3所示用户终端客户端APP软件实现示例中可视对讲功能的流程图；

图8是所示用户终端和门禁设备实现示例中进行点对点通讯时信令消息处理的基础流程；

图9是图3所示实现示例中门禁设备与后台系统和用户终端进行呼叫的典型通讯示意图（注：图9中的消息通过消息处理模块来发送和接收）；

图10是图3所示实现示例中用户终端对门禁设备进行远程开锁的通讯示意图；

图11是图3所示用户终端客户端APP软件实现示例的组成；

图12是两个用户终端及后台系统之间进行点对点可视对讲时的通讯关系示意图；

图13是实施例中信令处理模块服务程序的启动/终止流程；

图14是实施例中信令处理模块信令处理端口的连接握手（通话登录）处理流程。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚明白，下文中将结合附图对本发明的实施例进行详细说明。需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。

图1为本发明所述门禁设备、用户终端和后台系统之通讯关系示意图。图2为本发明所述门禁设备构成示意图。

在如图3所示的本发明之实施例中：

门禁设备10：可以是放在楼栋单元门，也可以是在围墙或小区大门或者车库门，一个小区可能有多个；其中的门禁设备10，可以是楼宇单元门禁设备，也可以是围墙门禁设备、小区大门门禁设备和车库门禁设备等；门禁设备可以有多个，如图3中的10.1、10.2、10.3；每个门禁设备包含（见图4）：处理器100、触摸显示屏101、摄像头102、麦克风103、网络模块107、电锁控制接口110、扬声器111、电锁120；门禁设备通过WLAN或者LAN接入局域网并通过路由器11接入互联网（见图3），并访问后台系统20的服务。

后台系统20包含：总控模块25、消息处理模块24、信令处理模块22；图3的实施例中：

总控模块25以总控云平台的形式实现，每个小区有独立和隔离的运行实例运行在总控云平台的应用容器中，各小区门禁设备对总控云平台的访问会被路由至该小区对应的应用容器中；

消息处理模块24以消息发布/订阅服务器集群的形式实现，这些消息发布/订阅服务器实现了：针对无线网络设备优化的双向协议型消息发布/订阅/推送服务，集群中服务器均无单点故障；新加入的服务器会被自动发现和识别并加入集群，具有单台服务器能够处理百万级别数量长连接的能力；

信令处理模块22以信令处理服务器集群的形式实现，这些信令处理服务器实现了：简化的点对点通讯信令处理服务（使用一个简化版的类SIP协议），集群中服务器均无单点故障；新加入的服务器会被自动发现和识别并加入集群；

媒体处理模块23和转发处理模块21都是本实施例中所经优选方案新增，分别以媒体服务器（集群）和转发服务器（集群）的形式实现；

媒体处理模块23接收门禁设备10拍摄并上传的压缩照片文件并供门禁设备10呼叫的用户终端30下载使用；

当两个要进行通话的设备经信令处理模块22的信令协商完成后发现无法进行点对点数据直连，就会经由转发处理模块21来中转两个设备间的数据包。

注：此实施例中，门禁设备10接入总控模块25后，使用其固定通话用户凭证自动在信令处理模块22做通话登录。

图4 是门禁设备的实施例一，其中使用触摸显示屏做显示输出和交互输入；使用摄像头和麦克风做视音频输入，扬声器做音频输出。

图5 是门禁设备10实现示例中进行可视对讲、远程开锁功能实现的流程图。

访客在门禁设备10上通过触摸显示屏101上的输入面板输入需要拜访的房间号（即图5中的步骤S001）。（图5的步骤S002）输入房间号过程中内置摄像头102将抓拍的照片以有损压缩的方式压缩成低分辨率照片文件上传至媒体处理模块23（即图5中的步骤S003）。访客输入完房间号码进行呼叫后，门禁设备10将要访问的房间号码以及上传的照片文件信息作为参数向总控模块25发出呼叫命令（即图5的步骤S004）。

总控模块25接收到呼叫请求后校验门禁设备的有效性并检索门牌号码对应的住户信息；根据检索出的住户信息和用户终端登录表，找到应该连接的用户终端；向信令处理模块22发送新增一个临时通话用户凭证（默认有效时长2分钟）的命令，信令处理模块22收到命令后在临时通话用户表中添加新的记录；通过消息处理模块24向要呼叫的用户终端30发送呼叫请求消息；向门禁设备10返回呼叫请求应答。注：本实施例中信令处理模块22收到临时通话用户凭证第一次成功登录，就会自动将此凭证废止掉，不能用作再次登录。

门禁设备10在图5的步骤S005收到呼叫请求应答后（注：对于使用临时通话用户凭证方式进行通话登录的主叫设备，可以在这个呼叫请求应答中取得第二临时通话用户凭证）。然后进入下一步骤S006，更新屏幕显示状态，提示呼叫已经确认，在等待对方应答。

如图 6所示流程图，用户终端上的客户端APP软件，后台消息监听服务350（见图11）在步骤S103接收到消息处理模块24发来的呼叫请求消息后，在步骤S104会唤醒设备（如果设备当时处于待机锁屏状态），并传递消息给客户端APP主操作进程300（见图8）。

如图 7所示流程图，步骤S200先校验该消息是否有效，如果不通过则直接到步骤S250退出，校验通过后步骤S201解析出消息包中的数据，步骤S202检查是否需要下载照片，如果是，步骤S203就先启动一个后台线程去从媒体服务器24下载消息包中的图片文件列表所指的文件；然后用户终端30在步骤S204通过消息处理模块24回应确认消息给总控模块25，同时发给门禁设备10；门禁设备10收到确认消息，更新呼叫状态显示为已振铃（即图5步骤S011）。然后用户终端30在步骤S205弹出显示有来自所住小区楼栋门禁设备10的呼叫信息。

步骤S205弹出的窗口（即图11的接听界面306）中可以立即显示的是小区/楼栋的信息，然后在步骤S206播放提示音或者开启震动提示用户。如果步骤S207判断图片有下载完成的，就在弹出窗口中按顺序逐一显示出来（即步骤S208），都加载完毕的话就定格在最后一幅图片。

这样住户就可以看到是谁通过门禁设备要跟自己通话，并决定是否要跟对方通话。如果住户已经通过照片确认访客身份，也可以直接在界面上按下开锁按钮而不需要进行视音频通话过程。

如果住户决定要跟访客通话（可以根据自己的需要视频通话还是语音通话，默认是只开启语音）后，进入步骤S209，住户用户终端的APP通过消息队列服务器24向总控模块25发送已接听消息（即步骤S210），然后使用的临时通话用户凭证在信令处理模块22做通话登录。通话登录完成后，通过信令处理模块22向门禁设备10发送通话建立消息（即步骤S211）。

如图8 所示的信令处理基础流程，门禁设备10接收到经信令处理模块22转发的通话建立消息后（即步骤S310），立即先回复通话接受消息（即步骤S311），准备好视音频设备SDP做发起用（即S312），然后再发送发起信令消息（即S313）。在图5的步骤S212和S213，用户终端30收到通话接受消息，会把界面切换至通话界面（即图8中的通话界面303），然后执行后续的S214、S215、S216等步骤。然后门禁设备10和用户终端30之间经过信令处理模块22传递节点信令包协商最有效的直接连接方式。详细来说，用户终端30收到门禁设备10发来的发起信令（在步骤S303），就准备好应答SDP（注意跟门禁设备通话时用户终端默认只传语音，用户需要的时候可以再增加视频流），然后回应给门禁设备10应答信令消息（即步骤S304）；而门禁设备10收到应答信令后（即步骤S301），向用户终端30发送自己的节点信息（即步骤S302）；如果收到的是节点信令，就进行节点信令包的处理（即步骤S305、S306）；节点信令包可能会有多个；如果某一方节点因为网络问题需要重新进行信令协商，会给对方发送通话协商消息，对方收到后再重新回应发起信令消息以及节点信令消息继续后续处理（即步骤S320、S321）。门禁设备10处理信令消息的地方请看图5的步骤S007、S008。门禁设备10和用户终端30上的点对点通讯处理模块根据两端的网络节点连接情况决定两个设备节点之间是采用点对点直接连接通讯还是中间使用转发服务器进行数据包的转发。用户终端30和门禁设备10收到对方的流数据传过来之后开始对讲通话（即步骤S330、S331）。流数据通讯链路建立后，两端的程序采用SRTP、SCTP协议实现流数据的实时传输控制。图9是实施例中的典型通讯示意图，以上步骤可以结合图9进行理解。

住户在确认好访客身份后，决定是否给访客开锁。点完开锁按钮后，在步骤S220设备向总控模块25发出开锁请求（可以参看图10的通讯示意图）。

总控模块25收到开锁确认请求后，校验请求有效性合法性。确认有效后记录在日志中，并通过消息处理模块24向门禁设备10发出开锁消息。

门禁设备10接收到开锁消息后（即步骤S009），进入步骤S010，经校验有效后门禁设备10内置的电锁控制接口110发送解锁命令；电锁120打开后，门禁设备10又会通过消息处理模块24发送电锁已开启消息给用户终端30和总控模块25。没有校验通过则不做任何后续处理。

住户按完开锁按钮后，仍然可以继续和访客进行通话。如果要结束通话，需要按下结束通话按钮。这时（即图7步骤S230）住户用户终端30向消息处理模块24发送通话结束通知消息（通知总控模块25）；并向信令处理模块22发送退出通话登录命令（即图7步骤S231），信令处理模块22收到后结束已建立的流数据通讯链路并让用户终端30退出登录。

这时，门禁设备10会收到用户终端30通话关闭的信令消息。门禁设备10关闭通话画面显示（即步骤S341），停止摄像头录像，关闭麦克风（即步骤S342）。

另外，信令处理模块22上有监控进程定期检查是否有过期失效的通话连接，如有，将强制断开其连接。

客户端APP消息监听服务是在用户终端运行的后台服务，即使客户端的主进程界面没有开启或被系统误杀掉也可以持续运行。在实施例中，它的流程图如图6所示，会在服务启动时先连接至消息队列服务器集群（即步骤S100），连接成功后，订阅需要接收的消息（即步骤S101）。由于用户的用户终端在无线网络环境下会经常出现断网的情况，所以客户端APP消息监听服务有做断网后自动重连的处理，即步骤S110和S111。

图11 是实施例中用户终端客户端APP的组成示意图。309部分为展示/交互层，通话界面303和接听界面306在之前已经介绍过。

310部分为逻辑控制层，涉及网络通讯、数据处理、加解密、签名、多媒体设备管理和编解码，蓝牙通讯处理等功能。这部分的功能基本上门禁设备10上的软件也都会涉及到，相关的代码可以在门禁设备的软件进行重用。

320部分为数据存储层，涉及本地加密数据库的访问，缓存文件的处理，配置文件的访问。这部分的一些代码也可以重用于门禁设备的软件上。

图12是两个用户终端之间进行点对点可视通话时的通讯关系图。根据上面所述的实现方法，不难实现此呼叫模式下的程序处理，这里就不再细述。

对于使用浏览器实现的用户终端，可以使用带有WebRTC支持的浏览器运行JavaScript写的客户端程序来访问后台系统的服务。本实施例中所实现的点对点可视对讲使用的是与WebRTC兼容的技术和协议，因此，通过浏览器而不需要复杂的底层代码编写也可以很简单地实现此功能。熟悉Web前端代码的技术人员在对WebRTC、WebSocket等技术也了解，并理解信令处理模块的通话登录机制后，应该不难实现出使用浏览器的用户终端。

在后台系统的实施例中，使用CoreOS搭建了云平台。CoreOS是经过精简的Linux操作系统，主要用于使用容器技术的云平台，很适合应用在本发明运用云平台技术的实施上。

信令处理模块22和转发处理模块21因为会涉及到大量的网络IO操作，最好是配备很好的IO处理性能和多处理器性能的操作系统和实体服务器，所以选用了FreeBSD作为信令服务器和转发服务器的操作系统。转发服务器的话，只要安装配置好支持RFC-5766（TURN协议）和RFC-5389（STUN协议）的服务器软件即可使用。

信令处理模块22则是基于WebSocket传输协议开发一个类似SIP协议的简化版本（媒体协商使用SDP协议进行描述）并实现对临时通话用户凭证的有效管理，开发工具可以使用Node.js，但对于用户规模大的情况，最好是使用Erlang或者Go。

具体实施例中，信令处理模块22可以通过管理端口来接收和处理主控模块25的命令，用信令处理端口来接收和处理来自门禁设备10和用户终端30的通话登录和信令传输。管理端口可以使用CA证书技术来对接入的总控模块进行双向身份认证，防止攻击者伪造身份，也可以只对特定IP地址或网段接受连接。总控模块25分配/生成临时通话用户凭证时，采用的是与HTTP协议的摘要（Digest）认证类似的计算方式，下面所描述的认证校验也参考了HTTP的摘要认证处理方式。如图13的流程图所示，信令处理模块22以系统服务方式启动，完成数据和通讯端口初始化后就等待总控模块25的命令和门禁设备10与用户终端30的通话登录。为方便理解固定和临时通话用户凭证的不同处理方式，及其带来的好处，图14展示了实施例中信令处理端口的握手处理（即通话登录）流程。

因为使用的是WebSocket协议，门禁设备10和用户终端30可以在打开连接的参数中加入通话用户凭证的参数，临时通话用户凭证就会包括通话用户ID、随机数等由总控模块25生成给设备的值，固定通话用户凭证就只有固定通话用户ID。根据连接HTTP请求头中的Authorization值可以判断是否为二次握手请求。如果不是，进入步骤S600，对连接参数中的通话用户凭证数据进行提取。如果不是临时通话用户，进入步骤S601，查询固定通话用户ID是否在固定通话用户表中。如果不在固定通话用户表中，进入步骤S610直接返回403状态码拒绝访问。如果固定通话用户ID正确，需要做二次握手，在步骤S602信令处理模块计算出二次握手需要的随机数，然后在步骤S603将随机数以401状态码参数返回给连接设备。连接设备收到401状态码后，使用用户名、密码、收到的随机数计算出响应码，并加入到HTTP请求头信息的Authorization数据中，然后发送请求给信令处理端口进行二次握手。信令处理端口收到二次握手请求后，在步骤S604提取认证相关参数，进入步骤S605然后进行计算，如果计算结果与收到的响应码相同，则认证成功，进入步骤S608，设置连接的有效期，进入步骤S609并返回状态码101，握手成功，通话登录完成。如果响应码不同，则进入步骤S611，返回403状态码，拒绝访问。信令处理端口如果发现通话用户ID是临时通话用户，进入步骤S606，校验临时通话用户凭证以及连接设备根据凭证中的随机数计算出的响应码是否跟自己的计算结果相同。如果计算结果不符，直接返回403状态码拒绝访问（即步骤S610），否则就进入步骤S607更新临时通话用户凭证记录，让该凭证不能再继续用于登录。然后进入步骤S608，设置连接有效期（根据最长允许的通话时间）；进入步骤S609返回101状态码，握手成功，通话登录完成。

由此可见，临时通话用户凭证在信令处理模块22的使用，不但避免了对数据库的访问，而且通话登录认证过程中不需要做二次握手，通话登录的速度大幅提高，同时还大大提高了通话登录认证的安全性。如果门禁设备10也使用临时通话用户凭证方式进行通话登录，那么信令处理模块可以完全不需要数据库（指数据做持久化的数据库）的访问。

本领域的技术人员应该明白，上述的本发明实施例所提供的装置的各组成部分，以及方法中的各步骤，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上。可选地，它们可以用计算装置可执行的程序代码来实现。从而，可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上仅为本发明之较佳实施例，但其并不限制本发明的实施范围，即不偏离本发明的权利要求所作之等同变化与修饰，仍应属于本发明之保护范围。