在本文中，我将在测试和实施阶段分享我对WebRTC技术和Kurento媒体服务器的经验。 我将告诉您我遇到了什么问题以及如何解决它们。 我不会谈论如何从头开始开发应用程序，但会提供许多有用的链接。 我相信我的故事对将要使用WebRTC的人很有用。
引言
由我们公司开发的医学信息系统（MIS）已经发展成为具有许多微服务，消息总线，移动客户端等的大型企业项目。 系统的某些部分必须提供给第三方组织进行开发和支持，因为它们不是我们的个人资料。
远程医疗服务就是此类MIS模块之一。 没有开发视频会议和使用WebRTC的经验，并且已下达订单。 但是一段时间后，由于各种情况，该公司停止了支持视频会议。 如果没有支持，此服务将被禁用，并在存储库中“积聚灰尘”。
现在该复兴这种微服务了。 决定尝试自行重启远程医疗。 我们的公司已经成长，更多的专家出现了-有可能而且有必要掌握新的发展主题。 我以前从未参与过视频传输，但是了解和研究WebRTC等有前途的技术非常有趣。
以下是有关WebRTC技术和Kurento服务器的一些非常有用的链接，这些链接一开始对我有帮助：
开始使用
任务很简单：还原现有的视频会议系统，盘点之前已经完成的工作，并在必要时根据用户的意愿对其进行修改。 在虚拟机和真实计算机上的首次测试成功。 但是在客户端上部署系统带来了很多麻烦。
让我提醒您，客户已经拥有一个医疗信息系统（MIS），涵盖了许多任务：从电子队列，医生的工作场所，文档管理和PACS到医疗设备管理子系统。
当需要开发视频会议功能以在诊断中心的医务人员（以下简称DC）和远程患者之间进行通信时，设置了两个先决条件：
所有会议都应记录并存储在服务器上。
除浏览器（大多数情况下已预先安装）外，患者不应在其设备上安装任何其他程序。
WebRTC可从浏览器运行，而无需其他程序或插件。 Kurento可以记录通过它的所有内容。 此外，该媒体服务器还具有大量现成的库，可通过Java和JavaScript使用其API，从而极大地简化了开发。
服务器部分的开发，或者甚至它的基础，甚至在我开始执行任务之前，就已经由客户转移到外包公司，再转移到第三方公司。 因此，有一个“管理服务器”（CSS）–一个现成的服务器库，我可以将其实现。
交互的一般想法最初看起来像这样：
但是在进一步的工作过程中，整个系统已经改变并且变得更加复杂。
第一次复苏经验
在虚拟机和多台“实时”计算机上的测试网络中部署后，进行了许多测试和实验-一切运行正常。 因此，现在是时候引入一个真正的，有效的网络了。
为了进行测试，指派了一名负责任的受害人，以医生和他的工作场所的形式来帮助我。 通过远程医疗微服务的第二次呼叫崩溃了！
很好，这是在Beta测试期间发生的，除了我和一位对冒险感到满意的医生之外，没人能看到这一点。
很难理解为什么发生了什么以及为什么没有建立连接。 WebRTC没有显示任何故障-它只是等待信号出现。 不知不觉中，以某种方式进行调试非常困难：服务器部分运行良好，Kurento在日志中保持沉默，客户端在等待流，但是什么也没有发生。
哈伯帮助（赞美他）：
不幸的是，我以前不知道这些工具。
在分析日志数据并监视连接状态之后，很明显服务器端脚本和客户端脚本都对WebRTC系统中的事件缺乏反应。 在哪里得到这些事件？
kurento服务器开发人员为使用WebRTC提供了一个非常方便的JavaScript库：kurento-utils.js。
要快速启动，只需创建一个对象：
new kurentoUtils.WebRtcPeer.WebRtcPeerRecvonly(options, callback());
并且为了访问事件，有必要重新定义库的内部方法。 我尽可能简化了代码以使其更加清晰：
讲证书
由于本文是关于我的经验的，因此我将分享有关现代浏览器对安全性非常严格的信息。 如果资源具有自签名证书，则即使有特殊权限，浏览器也会禁止访问计算机外围设备。
您可以在Internet上的免费资源上创建证书，然后配置供其使用的本地网络，也可以下载Firefox 65或更高版本。在此版本中，只需单击按钮，我同意存在自签名证书以及访问摄像头和麦克风的风险。
这种方式对我来说似乎更容易。
第二次测试（已经小心）
在我看来，当下一次检查中见到我时，医生会竞选爆米花的。 他显然很喜欢看着我与现代技术作斗争。
实际上，此系统更新不是发行版，因为我没有修复任何问题，甚至都不知道问题的原因。 我再说一遍，在办公室里一切都很好。 该代码对生成WebRTC和Kurento的所有事件增加了反应，我已经联系到了所有事件，所有这些都在日志中进行了详细介绍。 我什至将日志放在单独的文件中，以免与IIA中的主要日志混淆。
我们与热心的医生和客户系统管理员一起尝试了该系统。 他们甚至没有测试，即“受折磨”。 我们以所有可能的方式和所有可用的设备创建了视频会议。 这场比赛涉及其他医生和远程办公室的部分员工。
最主要的不是检查系统（它不起作用），而是收集尽可能多的数据。 结果，发现：
- 创建视频会议的尝试中约有80％成功。
- 使用ICE候选者进行IPv6的某些连接不起作用。
- 在5家移动运营商中，只有2家在运营。
事实证明一切都很简单-仅在Google上就远远不够
对收集到的信息的分析表明，来自Google的通过TURN服务器的连接不稳定。 它们的负担很大，或者对于刚刚开始学习该技术的人来说，这只是一个演示服务器。 但事实是：非常频繁的失败。 需要您自己的TURN / STUN服务器！
失败的第二个原因是IPv6.local地址。 kurento服务器不接受具有这些地址的ICE候选人。 很好的是，在发送所有ICE候选人之前，请先检查一下我的代码，然后我才过滤掉IPv6.local。
移动运营商的问题再次通过其TURN / STUN服务器得以解决。
在五分之三的移动运营商中，NAT是对称的，WebRTC无法突破。 可在此处找到更多详细信息：
对称NAT可怕吗？可惜的是，我的个人手机可以在没有受到对称保护的运营商的SIM卡上工作。 因此，我的初步测试没有发现这个问题。
TURN / STUN服务器
选择resiprocate-turn-server软件包作为其服务器。
他们很久没有选择-它位于标准的ubuntu存储库中-易于安装和自动更新。 但是，使用帐户进行连接并不是很方便：登录名和密码仅从文件中获取，这就是为什么必须制作其他实用程序或脚本从主服务器的数据库中导出的原因。
目前，该文件是手工生成的，并且帐户通过一个简单的密码池进行分配。 授权是通过MIS主服务器实现的，因此安全性不会受到损害。 但是整个系统的整体结构看起来很丑陋。 重现这一时刻的计划。
客户第三次
我更正了代码，安装并配置了TURN / STUN服务器，开发了一个密码池，并在视频会议开始时将其分发给客户端，并且在更新生产服务器之后，我去了一位我已经认识的医生。
有效！ 万岁！ 所有会议都可以在所有设备和所有模式下成功进行：个人帐户中的患者可以致电医生，接待期间的治疗师可以致电功能诊断医生进行进一步咨询，医生本人可以安排来自全市不同分支机构的多用户视频会议。
我们已经从痛苦的经验中汲取了教训，我们进行了精心的测试，并人工创建了紧急情况。 从本文的主题出发，我强调需要设置连接等待时间的限制。 WebRTC和Kurento一起在等待广播无限长地开始，并希望视频字节即将过去。 我必须将计时器设置为10秒钟，如果字节永不到达，则会给管理服务器造成错误。
毕竟改进
最后，该系统运行正常且运行良好。 最初的评论来自该领域的用户。 随即出现了对设计，附加功能和其他进一步开发计划的大量希望和建议。 工作开始焕发新的活力！
现在，整个系统拓扑如下所示：
结果：
最后，我想说以下几点：
首先，WebRTC是一项很有前途的优秀技术，但是很难对其进行测试和调试。 在开始开发之前，必须部署具有客户端可能具有的各种连接的网络。 通过浏览器信息窗口进行调试并不是一个非常方便的工具。
其次，赞美哈布鲁！ 在从事该项目时，我发现了有关此资源的很多信息。 本文中的所有链接均指向该链接。
决定将远程医疗视频会议项目留给我们组织支持和开发；我们不会将其外包。 将来，还有很多工作要做：
一切
我确信，我的经验不仅对WebRTC + Kurento下的开发人员有用，对于那些将开始实施同样复杂的项目的开发人员也很有用。 在尽可能接近实际的条件下更加关注测试。
并考虑到微服务支持团队可能突然“消失”的风险-这是一件非常令人意外和不愉快的事情。